我有一个关于 CQRS 范式的一般问题。
我知道 CommandBus 和 EventBus 将域模型与我们的查询端数据存储区分开，最终一致性的优点，以及能够对查询端的存储进行非规范化以优化读取等。这一切听起来都很棒。
但我想知道，当我开始扩展 Query 端负责更新 Query 数据存储的组件数量时，它们是否不会开始相互竞争以执行更新？
换句话说，如果我们尝试为 EventBus 使用 pub/sub 模型，并且对于特定的事件类型有很多不同的订阅者，他们会不会开始相互竞争更新各种非规范化数据？这不会让我们和 CQRS 之前的情况一样吗？
正如我所听到的那样，听起来 CQRS 应该完全消除这种争用，但这只是一种理想，实际上我们只是真正将其最小化吗？我觉得我可能会在这里遗漏一些东西，但不能指望它。
这完全取决于您如何设计基础架构。严格来说，CQRS 本身并没有说明 Query 模型是如何更新的。使用事件只是您拥有的选项之一。CQRS 也没有提及处理争用。它只是一种架构模式，让您有更多的选择和选择来处理诸如并发之类的事情。在“常规”架构中，例如分层架构，您通常根本没有这些选项。
如果您在多台机器上扩展了您的命令处理组件，您可以假设它们可以产生比单个事件处理组件可以处理的更多的事件。这不一定是件坏事。这可能只是意味着查询模型将在高峰时间以稍大的延迟进行更新。如果这对您来说是个问题，那么您也应该考虑扩展查询模型。
事件处理程序组件本身不会相互竞争。他们可以安全地并行处理事件。但是，如果您将系统设计为使它们都更新相同的数据存储，那么您的数据存储可能会成为瓶颈。设置集群或将查询模型完全划分到不同的数据源可能是您问题的解决方案。
但请注意不要过早优化。在你有数据证明它对你的具体情况有帮助之前，不要扩大规模。基于 CQRS 的架构允许您做出很多选择。您需要做的就是在正确的时间做出正确的选择。
到目前为止，在我参与的应用程序中，我还没有遇到过 Query 模型成为瓶颈的情况。其中一些应用程序每天产生超过 1 亿个事件。