domain-driven-design - 在 CQRS 中同步查询端数据 - 不会仍然存在争用吗？

Question

我有一个关于 CQRS 范式的一般性问题。

我知道 CommandBus 和 EventBus 会将域模型与我们的查询端数据存储、最终一致性的优点以及能够对查询端的存储进行非规范化以优化读取等分离。这一切听起来都很棒。

但我想知道，当我开始扩展负责更新 Query 数据存储的 Query 端组件的数量时，它们是否不会开始相互竞争以执行更新？

换句话说，如果我们尝试为 EventBus 使用 pub/sub 模型，并且对于特定的事件类型有很多不同的订阅者，他们是否会因为更新各种非规范化数据而开始相互竞争？这不会让我们和 CQRS 之前一样吗？

正如我所听到的解释，听起来 CQRS 应该完全消除这种争论，但这只是一个理想，而实际上我们只是真正将其最小化？我觉得我可能在这里遗漏了一些东西，但不能指望它。

Answer 1

这完全取决于您如何设计基础设施。严格来说，CQRS 本身并没有说明如何更新 Query 模型。使用事件只是您拥有的选项之一。 CQRS 也没有说明如何处理争用。这只是一种架构模式，它为您提供了更多选项和选择来处理并发等问题。在“常规”架构中，例如分层架构，您通常根本没有这些选项。

如果您在多台机器上扩展了命令处理组件，您可以假设它们可以产生比单个事件处理组件可以处理的更多的事件。这不一定是坏事。这可能只是意味着 Query 模型将在高峰时间以稍大的延迟更新。如果这对您来说是个问题，那么您也应该考虑扩展查询模型。

Event Handler 组件本身不会相互竞争。他们可以安全地并行处理事件。但是，如果您将系统设计为让它们都更新同一个数据存储，则您的数据存储可能是瓶颈。设置集群或将查询模型完全划分到不同的数据源可能是您问题的解决方案。

但是，请注意不要过早地优化。在您有数据证明它对您的特定情况有所帮助之前，请勿扩展。基于 CQRS 的架构允许您做出很多选择。您需要做的就是在正确的时间做出正确的选择。

到目前为止，在我参与的应用程序中，我还没有遇到 Query 模型成为瓶颈的情况。其中一些应用程序每天产生超过 1 亿个事件。