algorithm - 当某些消息可能因灾难而丢失时，检测从何处开始重播消息

Question

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

消息编号 x 是否会发送给 A、B 或 C 订阅者是消息的某些不可变属性(不是数字)的函数，即消息编号 7 被路由到 B，因为它可能与代码以开头的股票有关'b'。

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

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

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

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

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

我目前使用的算法是找到每个订阅者收到的最大消息序列。假设我们得到类似的东西:

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

当前算法仅假设我们需要从订阅者恢复的最小消息数(在本例中为 1)开始重放。而实际上我们只需要在这种情况下担心数量大于 7 的消息。

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

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

我认为这个问题可能有一个标准算法，但网络搜索没有找到任何有用的东西。如果有人能指出相关算法，那将非常有用。

请假设:

• 保存发送给每个订阅者的每个消息编号不是一种选择。
• 订阅者可以很好地处理重复的消息，因此我们希望避免重播超过要求的消息。

Answer 1

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

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

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