我有一个发布者应用程序，可以将消息发送给多个订阅者。每个消息都分配有一个递增的序列号。假设A，B和C是三个订阅者，发布者已将消息编号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）中重播。这样可以减少重播的消息数量。
我认为可能存在解决此问题的标准算法，但是网络搜索没有产生任何有用的信息。如果有人可以指出我相关的算法，那将非常有用。
请假设：
答案 0 :(得分：0)
我认为这不需要特定的算法，但是您拥有的是特定的用例。我在Kafka中看到过类似的用例，每个用例都有一个单独的设置。您问题的答案归结为以下问题：订户如何阅读消息。
所有订户在收到更新后是否都更新相同的DB（或执行相同的操作）？在这种情况下，您可以将最新消息（7）发送给其中一个订阅者。
还是每个订户都在收到消息后执行自己的动作？然后，您需要重播每个订户的最新消息。{"A"->1, "B" ->7, "C" ->6}