Here是一篇不错的文章，它描述了什么是ES以及如何处理它。
那里一切都很好，但是一张照片困扰着我。这里是
我了解在基于事件的分布式系统中，我们只能实现最终的一致性。无论如何...我们如何确保预订的座位不多于可用数量？如果存在许多并发请求，则尤其是一个问题。
可能会发生n个聚合都填充了相同数量的预留席位，并且所有这些聚合实例都允许保留。
最佳答案
所有事件对运行它们的命令都是私有(private)的，直到记录簿确认成功写入为止。因此，我们根本不会共享事件，也不会向调用者报告，而不会知道我们的“接下来发生的事情”版本已被记录簿接受。
事件的写入类似于聚合历史记录中尾指针的比较和交换。如果在运行时另一个命令更改了尾指针，则交换失败，我们必须缓解/重试/失败。
实际上，这通常是通过使对记录簿的写命令包括写的预期位置来实现的。 (例如:GES中的ES-ExpectedVersion)。
如果期望的位置在错误的位置，则记录簿将拒绝写入。将位置视为RDBMS表中的唯一键，您便有了正确的想法。
这实际上意味着对事件流的写入实际上是一致的-记录簿仅在您写入的位置正确时才允许写入，这意味着自您复制历史记录以来该位置未发生变化装写了。
命令通常直接从记录簿中读取事件流，而不是最终保持一致的读取模型。
状态的每一位都需要由单个聚合根进行监督。您可以运行该根目录的n个不同副本，所有副本都竞争写入同一历史记录，但是比较和交换操作将只允许一个获胜者，这确保了“该”聚合具有单个内部一致的历史记录。
关于domain-driven-design - 赛事采购比赛条件，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/40608698/