当某些消息可能由于灾难而丢失时，检测从哪里开始重播消息

Question

我有一个向多个订阅者发送消息的发布者应用程序。每条消息都被分配一个递增的序列号。假设 A、B 和 C 是三个订阅者，Publisher 已将消息编号 1 发送给 A，将 2,3,4,7 发送给 B，将 5,6 发送给 C。

消息编号 x 将发送给 A、B 还是 C 订阅者是消息的某些不可变属性（不是编号）的函数，即消息编号 7 被路由到 B，因为它可能与符号以开头的股票有关'b'。

发布者有一个映射，其中包含发送给每个订阅者的最大序列号。目前的地图将如下所示：

{"A" -> 1, "B" ->7, "C" ->6}

此时我们不知道这些消息是否成功传递给各自的订阅者。但是，保证消息将按顺序传递。

如果我们遇到需要重启发布者的灾难，我们需要重播可能已经丢失给订阅者的消息。

重要提示：为了向订阅者重播消息，发布者需要向另一个上游服务器发送重播请求，并且它没有持久存储之前看到的所有消息。所以这里的发布者更像是一个路由器。从上游服务器重播消息是有成本的，所以我想尽量减少需要重播的消息数量。

我使用的当前算法是找到每个订阅者收到的最大消息序列。假设我们返回如下内容：

{"A"->1, "B" ->7, "C" ->6}

当前算法只是假设我们需要从订阅者恢复的最小消息数（在本例中为 1）重播。而实际上，只有在这种情况下，我们才需要担心数量大于 7 的消息。

我可以在发布者端定期保存每个订阅者发送的最高消息数的映射。

所以我可以每 5 分钟保存一次地图的状态。如果重新启动后我看到所有订阅者都收到了高于上次保存值的消息号，我可以从最大恢复的序列号（在本例中为 7）重播。这减少了要重播的消息数量。

我认为这个问题可能有一个标准算法，但是网络搜索并没有产生任何有用的东西。如果有人可以向我指出非常有用的相关算法。

请假设：

• 保存发送给每个订阅者的每个消息号不是一种选择。
• 订阅者可以很好地处理重复消息，因此我们希望在重播超过所需消息方面犯错。

Answer 1

我认为这不需要特定的算法，但您拥有的是特定的用例。我在 Kafka 中看到过类似的用例，每个用例都有一个单独的设置。您的问题的答案归结为订阅者如何阅读消息的问题。

是否所有订阅者在收到更新后都会更新同一个数据库（或执行相同的操作）？在这种情况下，您可以将最新消息（7）发送给其中一位订阅者。

或者每个订阅者在收到消息后都执行自己的操作？然后你需要重播每个订阅者的最新消息。{"A"->1, "B" ->7, "C" ->6}