事件溯源乐观并发

Question

我试图理解事件溯源的乐观并发的想法。 通常，乐观并发旨在用于更新。 然而，在事件溯源的情况下，我们从不更新——只插入。

假设我们有 3 个事件要插入到数据库中。 我们检查当前聚合版本是否与预期相同，然后执行插入。 但是，聚合可能在版本检查之后但在插入之前更新。 为了解决这个问题，我们需要在事务中加入版本检查和插入语句，从而获得独占锁。

所以问题是，如果我们使用锁，为什么它仍然被称为乐观并发？ 我错过了什么吗？

Answer 1

所以问题是，如果我们使用锁，为什么它仍然被称为乐观并发？ 我错过了什么吗？

“悲观”并发

LOCK
read
compute
write
UNLOCK

“乐观”并发

read
compute
COMPARE_AND_SWAP

我们打赌在我们工作时不会出现冲突写入的“乐观主义”。 如果我们输了那个赌注，那么 COMPARE_AND_SWAP 就会失败，我们必须重新开始（或放弃）。 这本质上给了我们“先写者胜”的冲突解决方案。

请注意，乐观并发策略会限制您的存储设计：您需要有一个有效的比较和交换操作可用。

Answer 2

在事件溯源中，系统最终是一致的，因此如果有对实体的并发写入，一旦所有节点都收到了实体的所有事件，它们就会聚合到相同的 state。

如果您将事件存储在数据库中，则不需要锁定任何东西来存储它们。 事件 stream 是 WORM 并且只能追加。 只需添加记录的事件。

您犯的错误是假设“我们检查当前聚合版本是否与预期相同，然后进行插入。” 写入新事件的节点根据之前看到的事件检查自己的内部 state，如果它可以写入一个事件，它就会写入它。 然后所有节点读取事件 stream 并收敛到正确的 state。