用于在线拍卖的 Azure 事件中心/服务总线吞吐量

Question

在用户场景中，对于正在进行的拍卖，可能有许多用户出价需要按照到达的顺序进行处理。在我的测试中，自然的选择是正确使用支持 FIFO 的 ServiceBus 队列。

据我所知，这个问题很少；

1. 当有很多并行拍卖（物品 A、B、C 等的拍卖）时，每次拍卖创建不同的队列是不可行的。但随后将出价推送到单个队列也会有瓶颈。

2. 主题不保证 FIFO。但根据this，使用 SupportOrdering 可以工作（尚未测试）。

我想知道是否可以使用 eventhub 来模拟这种情况？归根结底，应该有一个层尽快发布出价，并且有几个工人按顺序对这些出价采取行动（并将它们转发到其他子系统）

有没有人尝试过处理类似的用例？我们当前的出价绩效基准是（目前低于每秒 200 个出价）

Answer 1

事件中心在从分区读取事件时保证事件的顺序，但不会从不同分区读取事件。假设您将给定拍卖的事件发送到单个分区，您的订购需求将得到满足。

我想提及的另外一件事是在这种竞争场景中对公平的期望。事件中心分区将保留与代理接收它们的顺序有关的顺序。由于网络延迟或需要重试的瞬时故障，这可能与用户提交投标的感知顺序不一致。