简介

CQRS中文意思为命令于查询职责分离，我们可以将其了解成读写分离的思想。分为两个部分 业务侧和数据侧，业务侧主要执行的就是数据的写操作，而数据侧主要执行的就是数据的读操作。当然两侧的数据库可以是不同的。目前最为常用的CQRS思想方式为事件驱动。CQRS模型也是未来微服务形态的一个趋势。

模型解析

执行流程为下：

（业务侧）

1.客户端发送Command指令。

2.服务找到处理Command对应的处理器。

3. 将事件加入到事件总线中

4.将对应的事件数据持久化到数据库。

（数据侧）

1.从事件总线中获取对应更改的事件。

2.和读数据库中的数据实体进行比较，然后更新数据库信息。

解决方案

目前比较成熟的方案为：kafka + flink + axon 来实现CQRS。

方案流程：

业务侧：
在前端调用接口后，业务侧完成对应的业务操作，发送事件消息到kafka中，并将事件消息通过axon持久化到数据库中，为此业务侧的任务就完成了。(事件消息就是写操作)

数据侧：

1.flink监听kafka中的事件消息，在监听到对应的事件消息后会到数据库中查询对应的事件数据。 

2.执行数据清洗：

• 将事件中的数据填到主题模型中，也就是将脏数据转换为对应指定的数据。
• 将主题模型的数据转换为持久化模型。
• 将持久化模型sink到数据库中。

为什么要使用axon将事件数据进行持久化？

在kafka中的消息的数据是不能进行修改的，如果此时业务侧因为网络问题导致事件数据有误，在数据侧就会获取错误的数据，这明显是不合适的。所以在数据侧我们获取事件数据的最终来源为数据库，kafka中的事件消息最为驱动。（kafka主要的作用就是解耦合）

在flink中为什么要将主题模型转换为持久化模型？

因为持久化的数据库可能有多个，对应的数据库字段类型有所不同，所以需要在做一个持久化模型。

*相比于MVC，CQRS框架的优势在哪里？

1. 通过将读取和写入操作分开，可以针对每种类型的操作优化数据存储。

2.由于读取和写入操作是分离的，因此可以根据需要灵活地改变任一端的数据模型或实现，而不会直接影响到另一端。

3.事件溯源，系统的状态不是直接存储的，而是通过一系列不可变的事件来重建。这为审计、回滚和调试提供了强大的工具。