CQRS是什么？



CQRS(Command and Query Responsibility Segregation)是一种与传统的DDD实现不同的模式，将写与读区分开。CQRS适用于DDD的原因在于查询本身不应当影响领域建模



CQRS 主要包含两大概念，一个是读写分离(command & query)，一个是事件源(event sourcing)，事件源不是必须项



读写分离定义：



1、如果一个方法修改了对象的状态，就是一个命令，不应该返回数据。比如创建资源的时候，不应该返回资源id

2、如果一个方法返回了数据，该方法就是一个查询，不应该直接或间接的修改对象的状态。比如有些系统在查询中实现了懒删除



CQRS期望解决的问题：



类似懒删除这种导致的数据不一致，难以排查的问题

使用同一个领域对象来进行数据读写可能会遇到资源竞争的情况。所以经常要处理锁的问题，在写入数据的时候，需要加锁，读取数据的时候需要判断是否允许脏读。这样使得系统的逻辑性和复杂性增加，并会影响系统的吞吐量。

对于复杂的业务场景，查询通常不只是通过领域对象构成，比如商品需要从opensearch中查询。

像数据层面做读写分离，缓存一样，读db和写db通常也是分离的。需要有一种结构和这种场景映射



CQRS解决了什么问题（与传统架构对比优势）？



command bus:接受写请求，分发给commandhandle

command handle：将领域事件保存到event store，同时publish消息到event bus

event bus: 分发给不同event handle

event handle： 将对象的变更更新到query数据库



扩展性



传统架构，各个组件之间是强依赖，都是对象之间直接方法调用；而CQRS架构，则是事件驱动的思想；从微观的聚合根层面，传统架构是应用层通过过程式的代码协调多个聚合根一次性以事务的方式完成整个业务操作。而CQRS架构，则是以Saga的思想，通过事件驱动的方式，最终实现多个聚合根的交互。另外，CQRS架构的CQ两端也是通过事件的方式异步进行数据同步，也是事件驱动的一种体现。上升到架构层面，那前者就是SOA的思想，后者是EDA的思想。SOA是一个服务调用另一个服务完成服务之间的交互，服务之间紧耦合；EDA是一个组件订阅另一个组件的事件消息，根据事件信息更新组件自己的状态，所以EDA架构，每个组件都不会依赖其他的组件；组件之间仅仅通过topic产生关联，耦合性非常低。



可用性



可用性，无论是传统架构还是CQRS架构，都可以做到高可用，只要我们做到让我们的系统中每个节点都无单点即可。但是，相比之下，我觉得CQRS架构在可用性方面，我们可以有更多的回避余地和选择空间。



传统架构，因为读写没有分离，所以可用性要把读写合在一起综合考虑，难度会比较更大。基于同步调用、SOA思想的系统的实现成本是非常昂贵的。



而在CQRS架构下，因为CQRS架构把读和写分离了，所以可用性相当于被隔离在了两个部分去考虑。我们只需要考虑C端如何解决写的可用性，Q端如何解决读的可用性即可。C端解决可用性，我觉得是更加容易的，因为C端是消息驱动的。我们要做任何数据修改时，都会发送Command到分布式消息队列，然后后端消费者处理Command->产生领域事件->持久化事件->发布事件到分布式消息队列->最后事件被Q端消费。这个链路是消息驱动的。相比传统架构的直接服务方法调用，可用性要高很多。因为就算我们处理Command的后端消费者暂时挂了，也不会影响前端Controller发送Command，Controller依然可用。从这个角度来说，CQRS架构在数据修改上可用性要更高。不过你可能会说，要是分布式消息队列挂了呢？呵呵，对，这确实也是有可能的。但是一般分布式消息队列属于中间件，一般中间件都具有很高的可用性（支持集群和主备切换），所以相比我们的应用来说，可用性要高很多。另外，因为命令是先发送到分布式消息队列，这样就能充分利用分布式消息队列的优势：异步化、拉模式、削峰填谷、基于队列的水平扩展。这些特性可以保证即便前端Controller在高峰时瞬间发送大量的Command过来，也不会导致后端处理Command的应用挂掉，因为我们是根据自己的消费能力拉取Command。这点也是CQRS C端在可用性方面的优势，其实本质也是分布式消息队列带来的优势。所以，从这里我们可以体会到EDA架构（事件驱动架构）是非常有价值的，这个架构也体现了我们目前比较流行的Reactive Programming（响应式编程）的思想。



性能、伸缩性



传统架构，瓶颈通常在底层数据库。然后我们一般的做法是，对于读：通常使用缓存就可以解决大部分查询问题；对于写：办法也有很多，比如分库分表，或者使用NoSQL，等等。



传统架构一次数据修改的步骤是：



1）从DB取出数据到内存；

2）内存修改数据；

3）更新数据回DB。总共涉及到2次数据库IO。



然后CQRS架构，CQ两端加起来所用的时间肯定比传统架构要多，最多有3次数据库IO，



1）持久化命令；

2）持久化事件；

3）根据事件更新读库。

为什么说最多？因为持久化命令这一步不是必须的，有一种场景是不需要持久化命令的。CQRS架构中持久化命令的目的是为了做幂等处理，即我们要防止同一个命令被处理两次。那哪一种场景下可以不需要持久化命令呢？就是当命令时在创建聚合根时，可以不需要持久化命令，因为创建聚合根所产生的事件的版本号总是为1，所以我们在持久化事件时根据事件版本号就能检测到这种重复。



另外，上面再谈到数据一致性时提到，传统架构会使用事务来保证数据的强一致性；如果事务越复杂，那一次事务锁的表就越多，锁是系统伸缩性的大敌；而CQRS架构，一个命令只会修改一个聚合根，如果要修改多个聚合根，则通过Saga来实现。从而绕过了复杂事务的问题，通过最终一致性的思路做到了最大的并行和最少的并发，从而整体上提高系统的吞吐能力。



所以，总体来说，性能瓶颈方面，两种架构都能克服。而只要克服了性能瓶颈，那伸缩性就不是问题了（当然，这里我没有考虑数据丢失而带来的系统不可用的问题。这个问题是所有架构都无法回避的问题，唯一的解决办法就是数据冗余，这里不做展开了）。两者的瓶颈都在数据的持久化上，但是传统的架构因为大部分系统都是要存储数据到关系型数据库，所以只能自己采用分库分表的方案。而CQRS架构，如果我们只关注C端的瓶颈，由于C端要保存的东西很简单，就是命令和事件；如果你信的过一些成熟的NoSQL（我觉得使用文档性数据库如MongoDB这种比较适合存储命令和事件），且你也有足够的能力和经验去运维它们，那可以考虑使用NoSQL来持久化。如果你觉得NoSQL靠不住或者没办法完全掌控，那可以使用关系型数据库。但这样你也要付出努力，比如需要自己负责分库分表来保存命令和事件，因为命令和事件的数据量都是很大的。不过目前一些云服务如阿里云，已经提供了DRDS这种直接支持分库分表的数据库存储方案，极大的简化了我们存储命令和事件的成本。就我个人而言，我觉得我还是会采用分库分表的方案，原因很简单：确保数据可靠落地、成熟、可控，而且支持这种只读数据的落地，框架内置要支持分库分表也不是什么难事。所以，通过这个对比我们知道传统架构，我们必须使用分库分表（除非阿里这种高大上可以使用OceanBase）；而CQRS架构，可以带给我们更多选择空间。因为持久化命令和事件是很简单的，它们都是不可修改的只读数据，且对kv存储友好，也可以选择文档型NoSQL，C端永远是新增数据，而没有修改或删除数据。最后，就是关于Q端的瓶颈，如果你Q端也是使用关系型数据库，那和传统架构一样，该怎么优化就怎么优化。而CQRS架构允许你使用其他的架构来实现Q，所以优化手段相对更多。



CQRS有什么缺点（与传统架构对比劣势）？



数据一致性



传统架构，数据一般是强一致性的，我们通常会使用数据库事务保证一次操作的所有数据修改都在一个数据库事务里，从而保证了数据的强一致性。在分布式的场景，我们也同样希望数据的强一致性，就是使用分布式事务。但是众所周知，分布式事务的难度、成本是非常高的，而且采用分布式事务的系统的吞吐量都会比较低，系统的可用性也会比较低。所以，很多时候，我们也会放弃数据的强一致性，而采用最终一致性；从CAP定理的角度来说，就是放弃一致性，选择可用性。



CQRS架构，则完全秉持最终一致性的理念。这种架构基于一个很重要的假设，就是用户看到的数据总是旧的。对于一个多用户操作的系统，这种现象很普遍。比如秒杀的场景，当你下单前，也许界面上你看到的商品数量是有的，但是当你下单的时候，系统提示商品卖完了。其实我们只要仔细想想，也确实如此。因为我们在界面上看到的数据是从数据库取出来的，一旦显示到界面上，就不会变了。但是很可能其他人已经修改了数据库中的数据。这种现象在大部分系统中，尤其是高并发的WEB系统，尤其常见。



所以，基于这样的假设，我们知道，即便我们的系统做到了数据的强一致性，用户还是很可能会看到旧的数据。所以，这就给我们设计架构提供了一个新的思路。我们能否这样做：我们只需要确保系统的一切添加、删除、修改操作所基于的数据是最新的，而查询的数据不必是最新的。这样就很自然的引出了CQRS架构了。C端数据保持最新、做到数据强一致；Q端数据不必最新，通过C端的事件异步更新即可。所以，基于这个思路，我们开始思考，如何具体的去实现CQ两端。看到这里，也许你还有一个疑问，就是为何C端的数据是必须要最新的？这个其实很容易理解，因为你要修改数据，那你可能会有一些修改的业务规则判断，如果你基于的数据不是最新的，那意味着判断就失去意义或者说不准确，所以基于老的数据所做的修改是没有意义的。



引用



CQRS和Event Sourcing模式

团队开发框架实战—CQRS架构

经典的应用系统结构、CQRS与事件溯源

DDD 中的那些模式 — CQRS

DDD CQRS架构和传统架构的优缺点比较





欢迎大家关注我的公众号



-半亩房顶