数据库(七),读写分离到CQRS

读写分离

当一个公司业务不断扩展,用户量大量增加,原来使用的数据库很可能就撑不住了。那么可以

  • Scale-in,扩充硬件的性能,但是很可能用户量继续增长,增加的性能很快就吃光了。

  • 读写分离:数据库撑不住了,无非就是读写量过大,特别是有一些复杂的查询比如最近24小时最热门的产品等。需要很复杂的SQL语句,运行起来当然是慢。

但是为了读写分离,需要把数据库拆分为master库和Slave库,

市面上主要的关系数据库都支持数据复制功能,所以可以把一个数据库拆分为Master和Slave两种角色,写操作在主上,由Master服务器向其他Slave服务器进行同步。

读操作以及数据分析等离线操作都在Slave服务器上进行。

我们知道互联网的很多应用都是读的,这样有多个Slave可以负载分担一下,又可以保证数据的可用性和正确性。

数据库(七),读写分离到CQRS_第1张图片
image.png

但是相应的原有的应用代码也需要修改,必须改为写数据用master库,读数据的时候使用slave库,就相当于重写了。

复杂查询

但是就算重写了代码,发现性能还是无法得到明显的提升,原因仍然是使用了太多复杂的查询,比如说有很多表在联接,在数据库(四),数据库组成部分里面我们都说过,联接非常消耗性能。

那么我们可不可以单独用一张表来存放过去24小时的热门产品啊,这样只需要使用简单的SQL就能搞定。

也就是说,一套单一的数据库表对报表、搜索、事务等不同的行为是不适当的。

现在的表是为了新增、修改数据而设计的,对复杂查询不适合。

但是我们还需要考虑这个查询库如何更新的问题,还就是可能不是实时更新,我们能否忍受这种延迟的问题。

CQRS

能否忍受延迟的问题需要从业务上来看,比如过去24小时热门的极品,一点点过时的信息没有太大的影响,只要求最终一致即可。

我们可以使用CQRS(Command Query Responsibility Segregation),也就是增删改的命令与查询责任分离

数据库(七),读写分离到CQRS_第2张图片
image.png

在CQRS中,强调的是读(Query)写(Command)分离,因为用户读到的数据通常是过时的,那么为什么还需要从数据库读一遍呢,可以直接建立一个读数据源。可以是Cache,可以是XML、JSON等。

那之前提到的怎么更新的问题怎么解决?可以使用Event,也就是事件,比如某个产品卖出去了,可以发布一个事件,修改原有的Read Model。

这样就通过事件机制把同步变成了异步。

最后,这种方法最好只在复杂查询中用,原来的简单查询依然在关系型数据库里面取。为什么呢?因为引入一种新的技术需要付出代价,比如同步变异步了,还需要事件机制,我们不能只看到新技术的优点,而看不到缺点了。

数据库(七),读写分离到CQRS_第3张图片
image.png

主要参考

从读写分离到CQRS,张大胖是如何解决性能问题的?

你可能感兴趣的:(数据库(七),读写分离到CQRS)