CQRS 架构

CQRS 是一个读写分离的架构思想,全称是:Command Query Responsibility Segregation,即命令查询职责分离,表示在架构层面,将一个系统分为写入(命令)和查询两部分。一个命令表示一种意图,表示命令系统做什么修改,命令的执行结果通常不需要返回;一个查询表示向系统查询数据并返回。读写两边可以用不同的架构实现,方便实现 CQ 两端的分别优化。

CQRS 架构

CQRS 架构里通常读、写操作的是不同的存储系统,两个存储系统之间通过事件消息来进行同步。因为同步有一定延迟,所以 CQRS 的一致性模型是最终一致性。CQRS 架构适用于什么场景呢?

  1. 应用的读模型和写模型差别比较大。
  2. 单一的存储模型无法同时满足高性能的读和写需求。

在机票搜索业务中,因为机票报价数据量特别大,因此需要做数据库的分库分表。站在机票代理商角度看,应该以代理商维度分库,因为代理商操作报价的时候只修改自己的报价,代理商侧有读也有写,写操作(修改报价) QPS 不高,但每次操作的数据量很大。而站在用户角度看,应该以航线维度分库,因为用户关注的是搜索的航线的全部代理商报价。

针对这样两种完全不同的读写需求,非常适合使用 CQRS 架构来解决,采用两套 DB 来存储报价数据:一套以代理商维度分库,一套以航线维度分库。两者之间的数据同步,可以采用应用层发变更消息解决,也可以通过 Canal 监听 binlog 进行同步。变更消息一般发送到分布式消息队列里(比如 RocketMQ、Kafka),支持流量削峰,方便扩展。

CQRS(Command Query Responsibility Segration)架构,大家应该不会陌生了。简单的说,就是一个系统,从架构上把它拆分为两部分:命令处理(写请求)+查询处理(读请求)。然后读写两边可以用不同的架构实现,以实现CQ两端(即Command Side,简称C端;Query Side,简称Q端)的分别优化。CQRS作为一个读写分离思想的架构,在数据存储方面,没有做过多的约束。所以,我觉得CQRS可以有不同层次的实现,比如: 1.CQ两端数据库共享,CQ两端只是在上层代码上分离;这种做法,带来的好处是可以让我们的代码读写分离,更好维护,且没有CQ两端的数据一致性问题,因为是共享一个数据库的。我个人认为,这种架构很实用,既兼顾了数据的强一致性,又能让代码好维护。 2.CQ两端数据库和上层代码都分离,然后Q的数据由C端同步过来,一般是通过Domain Event进行同步。同步方式有两种,同步或异步,如果需要CQ两端的强一致性,则需要用同步;如果能接受CQ两端数据的最终一致性,则可以使用异步。采用这种方式的架构,个人觉得,C端应该采用Event Sourcing(简称ES)模式才有意义,否则就是自己给自己找麻烦。因为这样做你会发现会出现冗余数据,同样的数据,在C端的db中有,而在Q端的db中也有。和上面第一种做法相比,我想不到什么好处。而采用ES,则所有C端的最新数据全部用Domain Event表达即可;而要查询显示用的数据,则从Q端的ReadDB(关系型数据库)查询即可。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值