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

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

数据库系统架构

主备架构

公司业务发展的前期，由于数据访问量小，这时我们可以直接采用单库的架构，承载所有的访问请求。不过因为存在单点的问题。若数据库出现故障，这段期间业务将会不可用。这时我们可以增加一个备库，实时同步主库的数据一旦主库出了故障，通过人工的方式，手动地将主机下线，将备机改为主机来继续提供服务。这种架构，部署维护简单，业务开发也无需任何改造。不过缺点也很明显，备库只有在主库有问题的时候才会被启用，存在一定的资源浪费的情况。

主从架构

随着业务发展，请求量不断变大，数据量也不断变大，业务变得更加复杂，很快数据将会到达瓶颈。由于大多数业务都是读多写少，所以数据库读时最容易成为系统瓶颈。这时候我们可以采用以下方案提高读的性能：增加从实例，主从同步，数据读写分离。这个架构与主备区别不大，主要区别在于主从架构下，从库与主库一样，时刻需要干活，主库提供写服务，从库只提供读服务。如果后续读的压力还是太大，我们还可以增加从库的数量，水平扩充读的能力。虽然主从架构帮我们解决读的瓶颈，但是由于主从之间需要数据同步，这自然就存在一定延时。在这延时窗口期内，从库的读只能读到旧数据。

延时解决方案

1.数据同步写入从库

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

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

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

2.缓存路由方法

写请求发往主库，同时缓存记录操作的 key，缓存的失效时间设置为主从的延时；
读请求首先判断缓存是否存在：
- 若存在，代表刚发生过写操作，读请求操作主库；
- 若不存在，代表近期没发生写操作，读请求操作从库。

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