Parallel processing 在按顺序处理事件时，如何实现可用性？ 目标

我希望实现事件的弹性处理，并且仍然按照事件到达的顺序处理它们

描述 侦听器任务侦听多个客户端的事件，将它们包装在消息中并将它们放入队列中。事件处理程序任务从队列中读取并处理事件。必须按顺序处理单个客户端的事件；不同客户端的事件可以无序处理。一个简单的解决办法是：

在

队列[client\u id%N]

中创建N个队列、侦听器队列事件。每个队列都有一个从中读取的事件处理程序

<>这是可行的，但我也必须考虑事件处理程序失败的情况。我可以想出两种方法来处理这个问题：

在队列的读者中进行领导选举-每个队列一次选举

使用RabbitMQ的确认功能（或其他MQ系统中的等效功能）-每个队列都有多个事件处理程序。事件处理程序将消息出列，并在完成处理后发回确认消息

问题量表 每秒大约有5K个事件，事件的大小为50-200字节。队列中的消息可能是1000个事件的集群，以减少MQ开销。这意味着支持选项2并每秒处理数十条消息的MQ系统可以工作

问题:

---

我可以执行选项2吗？还是队列中会有太多争用？是否支持使用确认？有没有更好的方法来实现这样的设计？我可以将事件集群发送到事件处理程序，并在发送下一个数据块之前等待确认，但我认为使用MQ可能不会像以前那样重新发明轮子。

我以前使用过RabbitMQ，但无法确认它是否支持在成功处理第一条消息时仅发送下一条消息的场景，我将把这部分留给对该工具有更好了解的其他人

对于具有任何通用服务/消息总线的实现：

借助以下技术，每个事件源的队列有助于解决问题：

• 有一个处理程序池（每个队列，或者如果事件相同，通常可以从所有队列处理），当一个处理程序失败时，我们还有许多其他处理程序，我们可以实例化尽可能多或尽可能少的处理程序以满足需求
• 在处理程序处理事件时，应锁定每个队列，以保持处理事件的顺序
• 锁定的队列应该有一个超时，以便自动解锁并恢复最后一个事件（已锁定），以防处理程序拾取事件并在处理该事件时失败
• 处理事件的处理程序在完成后解锁队列并删除它刚刚完成处理的事件

该技术部分是一个peek锁，但会锁定整个队列，而不仅仅是一个事件

---

通过这种方法，您不会获得更多的吞吐量，可能会获得更多的稳定性和故障恢复能力，这主要是因为队列的锁定。更好的方法是考虑如何消除对消息顺序的依赖，并允许处理程序以任何顺序选择这些消息，同时仍能实现所需的业务逻辑（可能会有所帮助）。

首先，我坚信按顺序处理请求的最有效方法是由单个处理程序处理它们。因此，解决方案应该提供一个“亲和性”，因此每个客户机都应该绑定到一个处理程序（正如您在“简单”解决方案中所描述的）。我们只需要创建一个调度例程，它既高效又兼容处理程序崩溃

如何实现亲缘关系？如果必须关闭处理程序，如何重新分配关联

作为一项关键措施，我将限制处理程序队列的长度，并在一个大的“传入”队列中保持异常负载：

客户端->侦听器->（大传入队列）->负载平衡器->处理程序队列->处理程序
\________ 另一种方法是在卡夫卡中使用。卡夫卡可以根据标识符对主题进行分区，并在分区内保持顺序。因此，在这种情况下，最好按
客户机id
进行分区。然后，Kafka通过重新划分主题来管理客户端之间的负载

另请参见：
我认为您需要一个单一的、特定于任务的队列。我不知道你的MQ系统是否支持这样的东西。每个客户机使用一个队列的另一种选择是，它取决于您的MQ系统，队列的成本有多高，所以它也可以工作。如果我是你，我会写一个自动测试来测量。你检查过ZeroMQ和nanomsg吗？它们也是很好的MQ系统，但工作方式与RabbitMQ不同。@inf3rno，我没有使用MQ系统，但我正在考虑使用它。我将选择一个具有所需功能的系统。另请参见
clients -> listener -> (big incoming queue) -> load balancer -> handler queues -> handlers 
                                                    \________<-__system events_<-____/