在用户场景中，对于正在进行的拍卖，可能有许多用户出价需要按照到达顺序进行处理。在我的测试中，自然的选择是使用支持FIFO的ServiceBus队列。
在我看来，这个问题很少；
-
当有很多平行拍卖(拍卖项目A、B、C等(时，我们认为在每次拍卖中创建不同的队列是不可行的。但是，将出价推到一个队列中也会遇到瓶颈。
-
主题不保证先进先出。但根据这一点，使用SupportOrdering可以工作(尚待测试(。
我想知道eventhub是否可以用于对此场景进行建模？在一天结束时，应该有一个层尽快发布投标，并且有几个工人按照顺序对这些投标采取行动(并将其转发到其他子系统(
有没有人尝试过处理类似的用例？我们目前的投标性能基线是这样的(目前每秒不到200个投标(
事件中心保证从分区读取时事件的顺序，但不保证从不同分区读取事件。假设您将给定拍卖的事件发送到单个分区，那么您的订购需求就会得到满足。
我想提到的另一件事是，在这种竞争场景中，对公平的期望。事件中心分区将保留与代理接收它们的顺序有关的顺序。这可能与用户由于网络延迟或需要重试的短暂故障而提交投标的感知顺序不一致。