EventSourcing竞争条件

Question

这是一篇很好的文章,描述了它是什么ES以及如何处理它.

那里的一切都很好,但一个图像困扰着我.这里是

据我所知,在基于事件的分布式系统中,我们只能实现最终的一致性.无论如何......我们如何确保我们不会预订更多座位？如果有许多并发请求,这尤其是一个问题.

可能会发生n个聚合使用相同数量的预留席位填充,并且所有这些聚合实例都允许预留.

Answer 1

有几种方法可以处理这种情况。

首先，事件流会将当前版本作为最后添加的事件的版本。这意味着如果事件流不是加载时的版本，您将无法或不应该能够保留事件流。由于第一次写入会导致事件流的版本增加，因此第二次写入将不被允许。由于事件本身不是发出的，而是事件源的结果，因此我们在您的示例中不会有竞争条件的类型。

好吧，如果您的命令是在队列后面处理的，那么任何失败都应该重试。如果无法处理请求，您将进入正常的“对不起，Dave。恐怕我不能这样做”场景，让用户知道他们应该尝试其他方法。

另一种选择是通过对某些表行发出更新来开始处理，以序列化对聚合的任何调用。可能不是最优雅的，但它确实会导致系统范围内的处理阻塞。

我想，在很大程度上，当涉及到事务处理时，人们不能真正信任读取存储。

希望有帮助:)