最终一致性 - Axon 冲突解决程序

Question

我正在开发一个PoC，以评估 Axon 框架在新应用程序开发中的使用情况。

我担心的是与 CQRS 模式的最终一致性，因为一致性是我们的要求。

有很多关于此主题的文章和线程，因此如果我创建重复的线程，我深表歉意。

Axon 提供了一个冲突解决程序，但我不确定它是如何工作的。

我在一个开源项目上找到了一个例子。

该解决方案将聚合的版本存储在事件存储和读取模型中。然后客户端将从读取的模型中读取版本。如果我有不同的读取模型，会出现版本冲突吗？

Axon如何解决这些冲突？

谢谢

Answer 1

在我们深入探讨 Axon 如何处理一致性之前，我想在 CQRS 作为概念的背景下指出一些事情。

关于一致性与 CQRS 的结合存在很多误解。最终一致性的概念适用于您在应用程序中定义的不同模型之间。例如，命令模型最近可能更改了状态，但查询模型尚未反映该状态。查询模型最终与命令模型保持一致。但是，该查询模型中的信息本身仍然是一致的。

更重要的是，这使您能够围绕一致性重要的地方和可以放松的地方做出有意识的选择。通常，命令模型做出的决策中一致性很重要。您需要确保每个决定都是根据最近变化的相关知识做出的。这就是聚合的目的。聚合将始终做出与其状态一致的决策。

我建议阅读反应性原则文档 [1]，即第五节 [2]。

然后是轴突。Axon 非常严格地实现了 DDD 和 CQRS 的概念。一致性在聚合中是神圣的。例如，使用事件溯源时，可以保证具有聚合流的事件是基于包含该流中所有先前事件的状态生成的。换句话说，流中的事件号 9 是在了解事件号 0 到 8 的情况下创建的。有保证。

当事件发布时，这并不意味着任何预测都已经是最新的。这可能需要几毫秒。这里放宽一致性允许我们扩展我们的系统。唯一的缺点是用户可能执行命令、执行查询但看不到结果。这实际上在系统中比您想象的要常见得多。有很多方法可以防止这个问题的发生。实时更新用户界面是解决此问题的有效方法。那么哪个用户进行了更改就不再重要了；他们几乎立即就看到了。

反过来可能会带来挑战。用户通过查询观察系统状态。这可能（并且始终会，即使没有 CQRS）提供过时的数据；当用户观看数据时，数据可能已被更改。用户决定做出改变。然而，与此同时，信息已经发生了变化。该其他更改可能是这样的：如果用户知道，它就永远不会提交该命令。

在 Axon 中，您可以使用冲突解决程序来检测这些“看不见的”并行操作。您可以使用传入事件中的“聚合序列”并将其与投影一起存储。如果用户操作导致针对该聚合的命令，则将聚合序列作为预期聚合版本传递。如果实际聚合的版本与此不匹配（因为它同时已更改），您需要确定这是否有问题。参考指南 [3] 中有一个简短的解释。

我希望这对 CQRS 和 Axon 背景下的一致性有所启发。

[1] https://principles.reactive.foundation

[2] https://principles.reactive.foundation/principles/tailor-consistency.html

[3] https://docs.axoniq.io/reference-guide/axon-framework/axon-framework-commands/modeling/conflict-resolution