架构模式 CQRS
本文我们聊聊 CQRS 这种架构模式。
CQRS 是用来解决什么问题的？
我们先看一个场景。
系统中的数据模型是按照实体以及关系进行设计的是吧。
例如电商系统，包含订单、用户、商品等等数据。
数据的变更操作、查询操作，都是基于这一套数据模型的。
但是，实际场景下的查询需求是多种多样。
例如这3类人群：
- 商家
- 买家用户
- 电商运营人员
他们的数据视角是不同的，各自的关注角度不同，需要查询的数据就完全不同。
但数据模型是一套啊，怎么办？
是不是就需要做数据关联、构建临时数据集合等等复杂的操作啊。
基于一种数据模型，来实现 N 种视角的查询，既别扭又麻烦。
CQRS 是怎么解决的呢？
CQRS 的全称是：
Command Query Responsibility Segregation
意思是 命令查询职责隔离。
命令是指 插入、修改、删除，就是更改数据的动作。
隔离之后，结构就变成了这样：
所以，CQRS 会有两个数据模型，一个命令模型，一个查询模型（可以有多个）。
命令模型的数据变更后，需要同步给查询模型。
这样做的核心目的就是：
让数据查询可以放飞自我。
各种复杂的查询操作再也不用基于单一死板的存储结构了。
命令模型数据同步过来之后，查询模型可以根据自己的想法来重新组织数据结构，从而实现想怎么查就怎么查，简单高效。
这样就解决了以前单一数据模型带来的查询尴尬场面。
这看起来不就是变成2个微服务吗？
并不是的，微服务的划分是基于业务领域的，不同的领域才划分为不同的微服务。
但 CQRS 中的命令模型、查询模型，它们还是属于同一领域的，查询模型不能脱离命令模型，它们是紧耦合的。
所以 CQRS 并不是两个独立的微服务。
那么 CQRS 如何同步数据呢？
这是没有限定的，你可以使用同步更新。
也可以异步更新，例如使用 MQ。
这种方式用的比较多，因为它的可靠性、扩展性都很好，只是会有短暂的数据不一致。
CQRS 看起来很像缓存啊？
是有些类似，但查询模型并不是单纯的用来提升查询性能的数据镜像。
查询模型的本质是用于创建多样化的数据展现形式。每一种形式适用于某类用户的需求。
CQRS 的查询模型可以使用不同的技术实现，例如有些使用关系数据库，有些使用 Redis ……
CQRS 把数据变更、查询分离之后，为查询带来了最大化的自由，同时呢，也大幅提升了这两方面的工作效率，相较于之前整合在一起，分开后负载压力肯定会减轻。这也是 CQRS 带来的性能优势。
CQRS 有什么不足？
凡事都有两面性，很明显，CQRS带来了复杂性。
之前一体的时候，只有一个数据模型，一套技术。
使用 CQRS 之后，至少就要有 2 个模型，使用的技术也会增加。
还要保持数据的同步，开发维护的任务自然更重了。
还有数据一致性的问题，如果使用同步方式，一致性强，但跨数据源的实时同步可不容易，写入性能必然下降，失败的概率也会增加。
如果使用异步方式，那就要考虑数据延迟问题，在需要立即看到变化结果的场景就不能使用了。
小结一下，CQRS 把数据的变更和查询拆开了，有各自的数据模型。
命令模型负责数据的变更，并把最新数据同步给命令模型。
命令模型根据自己的想法来安排数据，想怎么用就怎么用。
好处是可以让查询更加自由，更快的满足多变的业务需求。
坏处是增加了架构的复杂度，还有数据同步带来的问题。
我们可以根据自己的实际情况来抉择。