3

是否有一种标准设计模式可以用来按顺序使用队列中的消息,但具有高可用性?

当然,我可以按帐号最后一位数字将负载分成单独的队列(顺序仅对每个帐户很重要),这给了我可扩展性,但是如果主机处理以“2”结尾的帐号失败,例如,我需要一些东西拿起那个负载。

我认为这种处理有一个标准模式。不幸的是,我无法使消息具有幂等性,因为队列源是由第三方集成造成的。

任何想法都非常感谢。

4

1 回答 1

1

即使这是几天前的事情,也不得不回答一个带有“幂等”一词的问题。不要认为这里一定有设计模式,但我有一个方法。

正如您建议的那样,我会使用单独的工作队列以可扩展的方式处理消息。一个脑残的简单排序阅读器将从第三方队列中读取并将消息发送到适当的工作队列。

工作队列

高可用性部分将与工作队列读取器一起提供。这些中的每一个都有一个好友队列阅读器。每个队列读取器都会定期向其伙伴发送心跳消息。如果好友没有收到消息(或一定数量的消息),它将:

  1. 开始处理它现在死去的伙伴的队列以及它自己的队列
  2. 通知系统管理员有关死队列阅读器的信息

为了防止两个读者打到同一个队列,当一个死队列被复活时,它会先和它的好友重新建立心跳。一旦伙伴确认它不再处理恢复队列阅读器的原始队列上的消息,恢复的阅读器将再次开始其工作。

队列故障转移

您可以通过增加组中好友的数量来获得更多冗余,或者让队列阅读器在其原始好友死亡时建立一个新好友,但这会在阅读器死亡或返回时增加更多复杂性。

一种方法是为每个队列设置一个令牌。读取器只有在拥有令牌时才能读取队列。每个读者将开始拥有一个令牌,并向所有其他读者广播心跳。心跳将包括阅读器当前正在处理的队列的所有令牌。这将为所有读者提供整个系统的图片,而无需集中授权。当读者注意到某个令牌在某个时间范围内没有被广播时,它会在以下情况下认领该令牌:

  1. 在幸存的读者中拥有最少数量的令牌
  2. 或者在平局的情况下,在令牌数量最少的幸存读者中具有最低的 ID#。

一旦它认领了令牌,它将开始处理队列,并向系统管理员发送通知。

当阅读器重新上线时,它将收听心跳并重建其系统图像。然后它将确定哪个阅读器具有:

  1. 最多代币
  2. 或者在平局的情况下,ID最高的读者#

复活的读者将在其他读者的列表中声明最后一个令牌。一旦其他读取器确认声明并且不再处理由令牌表示的队列,恢复的读取器将再次开始处理队列。

这种方法的一个可能的优点是不需要一对一的读取器到队列的关系。它允许您创建任意数量的有意义的队列,并找到相应数量的可以处理负载的阅读器。

于 2015-05-17T20:00:45.047 回答