Here是一篇很好的文章，描述了什么是 ES以及如何处理它。
那里一切都很好，但有一张照片让我很困扰。这里是
我知道在分布式基于事件的系统中，我们只能实现最终的一致性。无论如何......我们如何确保我们不会预订比可用座位更多的座位？如果有许多并发请求，这尤其是一个问题。
可能会发生 n 个聚合填充相同数量的预留座位，并且所有这些聚合实例都允许预留。
最佳答案
I understand that in distributes event-based systems we are able to achieve eventual consistency only, anyway ... How to do not allow to book more seats than we have? Especially in terms of many concurrent requests?
在记录簿确认写入成功之前，所有事件对于运行它们的命令都是私有(private)的。所以我们根本不分享事件，也不向调用者报告，不知道我们版本的“接下来发生的事情”已被记录簿接受。
事件的写入类似于聚合历史中尾指针的比较和交换。如果在我们运行时另一个命令更改了尾指针，我们的交换失败，我们必须减轻/重试/失败。
在实践中，这通常通过让记录簿的写入命令包括写入的预期位置来实现。 (例如:ES-ExpectedVersion 在 GES 中)。
如果预期位置在错误的位置，则记录簿将拒绝写入。将位置视为 RDBMS 中表中的唯一键，您的想法是正确的。
这实际上意味着对事件流的写入实际上是一致的——记录簿仅在您写入的位置正确时才允许写入，这意味着自您复制历史以来该位置没有改变加载已写入。
命令通常直接从记录簿中读取事件流，而不是最终一致的读取模型。
It may happen that n-AggregateRoots will be populated with the same amount of reserved seats, it means having validation in the reserve method won't help, though. Then n-AggregateRoots will emit the event of successful reservation.
每一点状态都需要由单个聚合根来监督。您可以运行该根的 n 个不同副本，所有副本都竞争写入相同的历史记录，但是比较和交换操作将只允许一个获胜者，这确保了“该”聚合具有单个内部一致的历史记录。
关于domain-driven-design - EventSourcing 竞争条件，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/40608698/