引用计数的 Pub/Sub 系统

Question

我正在寻找一种方法来设计我的系统，该系统由多个发布者、多个渠道和多个订阅者组成，所有这些都可以轻松地进行唯一标识。 我需要以尽可能低的延迟向两个方向发送消息。但是，如果订阅者死了，他订阅的消息不应该被丢弃，当它重新上线时，它应该会收到所有待处理的消息。由于我在使用低规格服务器的同时处理非常多的消息（经常每秒发生 1000 条消息），这意味着始终保留所有消息的列表不是一种选择。

我正在考虑消息的引用计数/列表是否是一个可行的选择。发布消息时，会使用该特定频道的订阅者列表对其进行初始化，当订阅者收到消息时，将从列表中删除订阅者。如果列表为空，则删除消息。

现在，如果订阅者在没有取消订阅的情况下死亡，消息将不会被删除，因为丢失的订阅者列表不为空。当它重新上线时，它将能够接收所有待处理消息的列表，因为它使用与死实例相同的 ID 进行标识。

可能需要让消息/订阅者超时，例如，如果订阅者 10 分钟不活动，则包含它的所有列表条目都将被清除。

这是个好主意，我是否忘记了该系统可能出现的问题？有没有任何系统已经这样做了？ RabbitMQ 和类似的 PubSub 系统似乎没有这个 - 如果没有，我猜 redis 是要走的路？

Answer 1

我可以想象为消息生命周期的目的管理引用计数。就正常服务操作期间的消息和内存管理而言，这听起来很合理。当然，超时为死服务的引用提供补丁。

但是，就运行状况监控和服务恢复问题而言，这是另一回事。

我目前在这里看到的危险是状态管理。想象一个服务是有状态的订阅者（即有一个状态机），它从初始状态（I）驱动到某个状态（S）。每条消息在不同的状态下被不同地处理。现在想象您的服务终止并重新启动。同时存储一些消息，在服务重新上线后，将它们发送给它。然而，Service 以错误的状态（I 而不是 S）接收它们并出现意外行为。

您能否将服务恢复到崩溃时的确切状态？在实践中，这非常困难，因为即使在状态机方法中，服务也有副作用/与全局状态等进行通信。

归根结底，引用计数在管理消息方面似乎是合理的，但将其与运行状况监控混合会导致许多复杂性问题。