EventStoreDB 是否在消费者端提供通过事件键进行消息排序的功能？
Use*_*yen 1 event-sourcing eventstoredb
我一直在探索 EventStoreDB 并试图了解更多有关消费者端消息排序的信息。请在此处阅读有关persistent订阅以及Pinned消费者策略的信息。
我有一个场景，其中库存更新被推送到 eventstore，并且库存事件中不同的唯一 inventoryId 创建不同的流。
我们有多个具有相同consumerGroup名称的消费者来读取这些库存事件。我们正在使用启用的固定持久订阅ResolveLinkTos。
我的问题：
- 来自特定流的每条消息是否总是发送到 ConsumerGroup 的同一个消费者实例？
- 如果上述问题的答案是肯定的，那么来自该特定流的每条消息是否都会按照事件摄取的顺序到达特定的消费者实例？
该文档有一个警告，即不保证使用持久订阅进行有序消息处理。如果适用，任何策略都会以最大努力级别的排序保证来传递消息。
造成这种情况的原因有几个，其中一些是：
- 在消费者组之间传播消息会导致非线性检查点提交。这意味着某些消息可以在其他消息之前被处理。
- 持久订阅尝试缓冲消息，但当客户端发生超时时，整个缓冲区将被重新传递，这最终可能会破坏处理顺序
- 内置的重试策略本质上可以随时破坏消息顺序
大多数基于事件日志的代理（如果不是全部的话）甚至不会尝试保证跨多个消费者的有序消息传递。我经常听到“但是 Kafka 做到了”，忽略了 Kafka 将消息从一个分区传递到一组中最多一个消费者的事实。由于完全相同的问题，多个消费者之间的一个分区没有负载平衡。话虽这么说，EventStoreDB 仍然不是一个代理，而是一个事件数据库。
所以，答案如下：
来自特定流的每条消息是否总是发送到消费者组的同一个消费者实例？
不。它可能在大多数情况下都有效，但最终会崩溃。
来自该特定流的每条消息是否会按照事件摄取的顺序到达特定的消费者实例？
大多数情况下，是的，但同样，如果重试消息，您可能会在上一条消息被确认之前收到下一条消息。
总体而言，对未在服务器上预先分区的消息进行负载平衡有序处理并不是一件容易的任务。最多，如果检查点在某个时刻无法持续存在，并且消费者重新启动，您会重新发送消息。