如何使用事件采购按字段管理并发性

Question

我是事件外包的新手，所以这可能是一个非常无能的问题，所以请容忍我：

我们有一个事件源，cqrs系统，与cassandra的持久。我们有一个序列/版本号来处理聚合上的冲突修改。

我们需要一个管理界面的readmodel，它需要从几个有界上下文中显示相当多的细节，并使其可通过rest api进行编辑。

在这个readmodel中处理并发的最佳实践是什么？想法如下：

1)如果有一个干净的readmodel，包括所有相关的数据，我们可以通过一个请求获得，那就太好了。这就提出了一个问题:当多个字段可以独立编辑时，我们如何实际创建这个readmodel来保证我们处理所有字段的序列？我们是否可以为每个字段添加一个序列号，并以某种方式处理它，但这将完全扰乱我们的readmodel。

2)我们可以让每个字段都有一个readmodel，这在理论上会让一切变得简单，但也会创建很多请求，这通常很愚蠢，但很容易管理。

3)我们可以创建一个与readmodel分离的顺序表，并以这种方式跟踪通用序列和每个字段的序列，并在必要时使用它来编写新的readmodel。

任何想法。

Answer 1

我们使用严格的事件排序，每个事件都有一个聚合版本作为元数据。我们还有一个单线程投影。这保证了不会有重写。

问题出现在这种系统的可扩展性上，到目前为止，我们还没有达到这种方法的极限，但这一天可能会到来。Daniel建议将聚合版本与read模型保持在一起是有意义的，但同样，当扩展时，它将失败，假设您将需要竞争的消费者，将尝试同时更新您的模型。

正如我们所知，订购是竞争消费者的问题，所以我真的没有现成的答案。如果同一字段的并发更新的可能性是真实的(而不是假设的)，我也会考虑字段级读取模型和UI组合。

Answer 2

在基于CQRS ES的系统中，假设您/用户不直接编辑读取模型。读取模型是事件流中所有相关事件的结果，即投影。因此，读取模型会因命令导致的事件而发生变化。

为了在该场景中处理并发，我倾向于使用针对读取模型存储的版本号。当您形成一个命令时，它应该包括用于为命令提供上下文的读取模型表的版本。

然后，您可以检查正在引发的事件是否具有正确的数字。如果不是，您可以抛出并发异常。或者，您可以创建并发解析器服务。这将检查由于您的命令是问题而发生的事件是否真的冲突。

如果你想更多地了解事件源系统中的并发管理，你可以查看这篇文章：

Handling Concurrency Conflicts in a CQRS and Event Sourced System

希望这能有所帮助。