数据库读写分离时,主从延时导致数据不一致的解决方案

By | 2021年1月4日

数据库读写分离时,主从延时导致数据不一致的解决方案

引入主从架构,数据读写分离,目的是为了解决业务快速发展,请求量变大,并发量变大,从而引发的数据库的读瓶颈。不过当引入新一个架构解决问题时,势必会带来另外一个问题,数据库读写分离之后,主从延迟从而导致数据不一致的情况。

数据库系统架构

主备架构

公司业务发展的前期,由于数据访问量小,这时我们可以直接采用单库的架构,承载所有的访问请求。不过因为存在单点的问题。若数据库出现故障,这段期间业务将会不可用。

image-20210104084506829

这时我们可以增加一个备库,实时同步主库的数据

image-20210104084845254

一旦主库出了故障,通过人工的方式,手动地将主机下线,将备机改为主机来继续提供服务。这种架构,部署维护简单,业务开发也无需任何改造。不过缺点也很明显,备库只有在主库有问题的时候才会被启用,存在一定的资源浪费的情况。

主从架构

随着业务发展,请求量不断变大,数据量也不断变大,业务变得更加复杂,很快数据将会到达瓶颈。

由于大多数业务都是读多写少,所以数据库读时最容易成为系统瓶颈。

这时候我们可以采用以下方案提高读的性能:增加从实例,主从同步,数据读写分离。

image-20210104085117055

这个架构与主备区别不大,主要区别在于主从架构下,从库与主库一样,时刻需要干活,主库提供写服务,从库只提供读服务。

如果后续读的压力还是太大,我们还可以增加从库的数量,水平扩充读的能力。

虽然主从架构帮我们解决读的瓶颈,但是由于主从之间需要数据同步,这自然就存在一定延时。在这延时窗口期内,从库的读只能读到旧数据。

延时解决方案

1.数据同步写入从库

主从数据同步方案,一般都是采用的异步方式同步给备库。我们可以将其修改为同步方案,主从同步完成,主库上的写才能返回。

  1. 业务系统发起写操作,数据写主库;
  2. 写请求需要等待主从同步完成才能返回;
  3. 数据读从库,主从同步完成就能读到最新数据。

这种方案,我们只需要修改数据库之间同步配置即可,业务层无需修改,相对简单。但随着从库的数据增加,由于主库写需要等待主从完成,写请求的时延将会增加,吞吐量将会降低。

2.缓存路由方法

image-20210104085809701

  1. 写请求发往主库,同时缓存记录操作的 key,缓存的失效时间设置为主从的延时;

  2. 读请求首先判断缓存是否存在:

    • 若存在,代表刚发生过写操作,读请求操作主库;
    • 若不存在,代表近期没发生写操作,读请求操作从库。

这种方案相对中间件的方案成本较低,但是又引入一个缓存组件,所有读写之间就又多了一步缓存操作,整体复杂度变高,业务开发也变得复杂。

发表评论

电子邮件地址不会被公开。 必填项已用*标注