这篇文章主要讲解了“数据库读写分离的坑有哪些”，文中的讲解内容简单清晰，易于学习与理解，下面请大家跟着小编的思路慢慢深入，一起来研究和学习“数据库读写分离的坑有哪些”吧！
前言
事情是这样的，刚入职的时候接到了这样的一个业务需求：
每个支付通道支付失败的时候都会返回特定的错误码，业务内部需要将通道特定的错误码转义成内部的错误码，这样对外就可以统一返回我们自己的错误码。
这个需求其实不难，当时设计的系统架构如下：
新增规则的流程简单分为三步：
业务人员通过管理后台新增映射规则
数据库新增、修改这条映射规则
删除缓存
这里之所以增加缓存，是因为这个场景每次支付都需要使用，使用缓存可以避免每次都去数据库读取，增加读取速度。
后续支付请求业务流程如下：
数据库读写分离-用户操作
当缓存内映射规则不存在的时候，将会查询数据库，然后加载到缓存中。如果缓存内映射规则已存在，将会直接使用缓存内映射规则。
这个业务流程其实比较简单，当时在测试环境测试也没问题，后续发布线上环境的却碰到奇怪的问题。
「新增规则之后，一段时间内，映射规则并没有生效。查看日志发现，查询数据库的时候，没有数据。」
这就很奇怪了，日志显示新增是成功，但是查询却没有数据。但是过了一段时间，再次查询却又有了数据。
走查了下代码，发现并没有什么问题，第二天上班的时候请教了一下同事，才知道问题的原因：
原来线上的数据库采用主从架构，数据读写分离，数据查询走的是从库。数据写入都是直接操作主库，后续再同步到从库。
「由于数据库同步存在延时，这就导致数据同步的这段时间，主从数据将会不一致，从库无法查询到最新的数据。」
如果你之前的数据库系统架构是单库或者主备结构，当你第一次转到数据读写分离架构，这个坑大概率也会踩到。
数据库系统架构发展
下面我们首先了解一下数据库系统架构，最后再来看下如何解决主从同步延时的导致数据不一致。
主备架构
业务发展的前期，数据访问量小，这时我们可以直接采用单库的架构。
不过我们一般不使用的上面的架构，因为存在单点的问题。若数据库出现故障，这段期间业务将会不可用。我们除了等待重启，其他没什么解决办法。
所以我们会增加一个备库，实时同步主库的数据。
主备架构
一旦「主库」出了故障，通过人工的方式，手动的将「主机」踢下线，将「备机」改为「主机」来继续提供服务。
这种架构，部署维护简单，业务开发也无需任何改造。
不过缺点也很明显，备库只有在主库有问题的时候才会被启用，存在一定的资源浪费的情况。
主从架构
随着业务发展，请求量不断变大，数据量也不断变大，业务变得更加复杂，很快数据将会到达瓶颈。
由于大多数业务都是读多写少，所以数据库读的最容易成为系统瓶颈。
这时候我们可以提高读的性能，这时我们的可以采用的方案，增加从实例，主从同步，数据读写分离。
可以看到这个架构与主备没什么区别，主要区别在于主从架构下，从库与主库一样，时刻需要干活，主库提供写服务，从库只提供读服务。
如果后续读的压力还是太大，我们还可以增加从库的数量，水平扩充读的能力。
虽然主从架构帮我们解决读的瓶颈，但是由于主从之间需要数据同步，这天然就存在一定延时。
