CQRS模型解析
简介
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.事件溯源，系统的状态不是直接存储的，而是通过一系列不可变的事件来重建。这为审计、回滚和调试提供了强大的工具。