cqrs - 事件存储和乐观并发

Question

Greg Young 在他关于 CQRS 的文档中的 "Building an event storage"部分，当将事件写入事件存储时，他检查了乐观并发。我真的不明白他为什么要检查，谁能用一个具体的例子向我解释。

Answer 1

I do not really get why he made that check, can anyone explain to me with a concrete example.

事件存储应该是持久的，从某种意义上说，一旦您编写了一个事件，它就会对每次后续读取可见。所以数据库中的每个 Action 都应该是一个追加。一个有用的心智模型是考虑一个单向链表。

如果数据库将支持多个具有写访问权限的执行线程，那么您将面临“丢失更新”问题。绘制为链表，这可能如下所示:

Thread(1) [... <- 69726c3e <- /x.tail] = get(/x)
Thread(2) [... <- 69726c3e <- /x.tail] = get(/x)
Thread(1) set(/x, [ ... <- 69726c3e <- 709726c3 <- /x.tail])
Thread(2) set(/x, [ ... <- 69726c3e <- 83b97195 <- /x.tail])

thread(2) 写入的历史记录不包括 thread(1) 记录的 event:709726c3。因此“丢失更新”。

在通用数据库中，您通常使用事务来管理它:幕后的某些魔法会跟踪您所有的数据依赖关系，如果在您尝试提交事务时不满足前提条件，则您的所有工作都会被拒绝。

但是事件存储不需要支持一般情况的所有自由度——禁止编辑存储在数据库中的事件，改变事件之间的依赖关系也是如此。

更改的唯一可变部分 - 这是我们用新值替换覆盖旧值的唯一地方 - 是我们更改时 /x.tail

Thread(1) [... <- 69726c3e <- /x.tail] = get(/x)
Thread(2) [... <- 69726c3e <- /x.tail] = get(/x)
Thread(1) set(/x, [ ... <- 69726c3e <- 709726c3 <- /x.tail])
Thread(2) set(/x, [ ... <- 69726c3e <- 83b97195 <- /x.tail])

这里的问题很简单，Thread(2) 认为 6 <- /x.tail是真的，并用丢失事件 7 的值替换它。如果我们从 set 更改我们的写入到 compare-and-set ...

Thread(1) [... <- 69726c3e <- /x.tail] = get(/x)
Thread(2) [... <- 69726c3e <- /x.tail] = get(/x)
Thread(1) compare-and-set(/x, 69726c3e <- /x.tail, [ ... <- 69726c3e <- 709726c3 <- /x.tail])
Thread(2) compare-and-set(/x, 69726c3e <- /x.tail, [ ... <- 69726c3e <- 83b97195 <- /x.tail]) // FAILS

然后数据存储可以检测到冲突并拒绝无效写入。

当然，如果数据存储看到线程的 Action 顺序不同，那么
失败的命令可能会改变

Thread(1) [... <- 69726c3e <- /x.tail] = get(/x)
Thread(2) [... <- 69726c3e <- /x.tail] = get(/x)
Thread(2) compare-and-set(/x, 69726c3e <- /x.tail, [ ... <- 69726c3e <- 83b97195 <- /x.tail])
Thread(1) compare-and-set(/x, 69726c3e <- /x.tail, [ ... <- 69726c3e <- 709726c3 <- /x.tail]) // FAILS

更简单地说，其中 set为我们提供“最后一位作者获胜”的语义， compare-and-set给我们“第一个作者获胜”，这消除了丢失更新的担忧。