cwa*_*ash 3 domain-driven-design cqrs event-sourcing axon
我对CQRS范式有一般性的疑问.
据我所知,CommandBus和EventBus将域模型与我们的查询端数据存储区分离,最终一致性的优点,以及能够在查询端对存储进行非规范化以优化读取等等.这听起来都很棒.
但我想知道,当我开始扩展查询端负责更新Query数据存储区的组件数量时,如果他们不会开始相互竞争以执行更新？
换句话说,如果我们尝试将一个发布/订阅模型用于EventBus,并且特定事件类型有很多不同的订阅者,那么他们是否会因更新各种非规范化数据而开始相互竞争？难道这不会像我们在CQRS之前那样把我们放在同一条船上吗？
正如我听到它解释的那样,听起来CQRS应该一起消除这种争论,但这只是一种理想,实际上我们只是真正地将它最小化了吗？我觉得我可能会在这里丢失一些东西,但不能把手指放在上面.
All*_*ard 10
这一切都取决于您如何设计基础设施.严格地说,CQRS本身并没有说明如何更新查询模型.使用事件只是您拥有的选项之一.CQRS也没有说明如何处理争用.它只是一种架构模式,为您提供更多选项和选择来处理并发等事务.在"常规"体系结构中,例如分层体系结构,您通常根本没有这些选项.
如果您在多台计算机上扩展了命令处理组件,则可以假设它们可以生成比单个事件处理组件可以处理的事件更多的事件.这不一定是坏事.这可能仅意味着查询模型将在高峰时间以稍微更大的延迟进行更新.如果这对您来说是个问题,那么您应该考虑扩展查询模型.
事件处理程序组件本身不会相互竞争.他们可以安全地并行处理事件.但是,如果您将系统设计为使它们全部更新同一数据存储,则数据存储可能成为瓶颈.设置群集或将查询模型完全划分为不同的数据源可以解决您的问题.
但要注意不要过早地优化.在得到数据证明它对您的具体情况有所帮助之前,请不要扩展.基于CQRS的架构允许您做出很多选择.您需要做的就是在正确的时间做出正确的选择.
到目前为止,在我参与的应用程序中,我没有遇到查询模型是瓶颈的情况.其中一些应用程序每天产生超过1亿个事件.