在 HappyFunPizzaCorp 中，我们有一个 POS 系统，它生成两个事件：new_order事件和payment事件。这两个事件都包含一个用于交叉引用的披萨order_id键。
两个事件都被发送到一个交换器TheExchange。new_order事件总是在payment事件之前发出。
我们是一个非常繁忙的地方，例如每秒销售 100000 个比萨饼，因此不能选择串行处理所有记录。
所以问题是我们如何并行处理我们的工作负载，同时仍然保证在同一个披萨的事件new_order之前处理事件？payment
具有多个消费者的简单队列是行不通的。我们得到消费者之间的循环行为，因此事件可能与同一个披萨payment的事件同时处理。new_order
另一种解决方案是使用分片交换并将order_id用作分片键。虽然这听起来不错，但我们现在在队列之间有了一些内在的并行性，我们的消费者如何连接？我们可以有一组预定义的队列来防止由于重新分片而导致消息之间的重新分片和并行性。但是如果我们有多个消费者实例，他们如何决定使用哪些队列来消费数据。最重要的是，我们希望自动扩展我们的消费者。
我们当前的解决方案是使用共识协议（通过 zookeeper 的 raft/paxos）来确定每个消费者进程应该服务的队列数量和队列。我们在系统中有一个预设的（大量）分片队列，它们不应该改变。队列的消费者是排他的（最多提供一次交付保证），他们通过共识协议协调哪些队列应该由谁服务。
虽然这个设置似乎可以工作，但它似乎过于复杂，我想知道是否有我们缺少的参考解决方案。