在线活动的Azure事件中心/服务总线吞吐量

如何解决在线活动的Azure事件中心/服务总线吞吐量

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

我认为这是很少的问题；

1. 当有很多并行拍卖（针对itemA，B，C等的拍卖）时，每次拍卖创建不同的队列是不可行的。但随后将出价推到一个队列中也会遇到瓶颈。

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

我想知道是否可以使用eventhub对此模型进行建模？最终，应该有一层可以尽快发布投标，并且有几名工人按顺序对这些投标采取行动（并将其转发给其他子系统）

有没有人试图解决类似的用例？我们当前的出价效果基准就像（目前每秒不到200个出价）

解决方法

事件集线器保证从分区读取时事件的顺序，尽管不能从不同分区读取事件。假设您将给定拍卖的事件发送到单个分区，则可以满足您的订购需求。

我要提到的另一件事是在这种竞争情况下对公平的期望。事件中心分区将保留与代理接收它们的顺序有关的顺序。由于网络延迟或需要重试的暂时性故障，这可能与用户提交出价的预期顺序不一致。