后期数据库主从架构的痛点，真的痛

原创：猿天地（微信公众号ID：cxytiandi），欢迎分享，转载请保留出处。

读写分离是什么？读写分离的做用就不讲了，若是有不了解的同窗能够本身去搜索资料进行了解。或者查看我以前的文章读写分离。

一开始的场景确定都基于主库去作增删改查的操做，等后面压力慢慢上来后才会考虑加数据库的从节点，经过读写分离的方式来提升查询的性能。

首先读写分离默认查询都是走从节点的。

从咱们的使用习惯或者业务的场景来讲，查询的场景是大于增删改的。因此咱们会在须要走主库进行数据操做的业务场景下，手动去控制这条Sql要去主库执行，这个控制的逻辑能够本身写，也能够利用框架自带的功能实现，就不细讲了。

好比咱们定义一个注解 @Master 用于标记此方法走主库操做，而后经过Aspect能够去切换数据源。这实际上是很常见的实现方式，若是说你一开始就有从节点，就规范了这么作是没问题的，若是是后面新增了从节点要开始作读写分离，这么作是存在问题的。

一旦这么作的话，对于增删改的操做没有问题，对于查的操做可能会有问题。这个问题不是说有Bug，而是有一些体验上的问题可能会致使Bug。你们都知道主从架构实际上是存在数据延迟的问题，只要有延迟那么就有可能出现问题。

某些业务场景下，你新增了一条数据，而后会立刻跳到详情去，此时若是数据有延迟，到详情的时候去查询从节点，就查不到刚刚新增的数据，会存在这样的问题。

解决办法就是把全部业务场景都整理下，而后让测试总体回归一遍，将须要走主库操做的查询方法都加上 @Master 注解，就不会有问题了。

看似没有任何问题，其实你们忽略了一点就是时间成本问题。要整理业务场景，要总体回归测试，这些都是要花时间的，时间就是最大的成本。

因此咱们在后期作读写分离的时候，基本上不会采用上面的方式去实现，由于业务功能越多，成本越高。

真正的作法是反着来，不管实现任何新功能，咱们都要考虑的点就是如何让影响最小？如何不影响以前的逻辑？

方法就是全部的老逻辑都不动，默认仍是走主库，可是咱们程序中已经作了读写分离的功能，默认查询就是会走从库的，因此第一步就是要将全部查询的Sql都发往主库，能够经过Aspect实现。

作完了上面这一步就能够直接上线了，由于全部的操做仍是走的主库，跟之前没有任何区别，不会影响任何老的逻辑。

如今就要考虑哪些查询能够走从库了，可是这个动做能够慢慢作，能够慢慢梳理。这样就会比较轻松了，每一个迭代咱们能够梳理几个走从库的查询，直接加个 @Slave 的注解让它强制走从库，这个场景咱们梳理过，验证过是没问题的。就这样慢慢的整理，直到全部老逻辑都梳理完。

好的思路可以保证稳定性和易用性，若是有收获那就点个赞呗！

关于做者：尹吉欢，简单的技术爱好者，《Spring Cloud微服务-全栈技术与案例解析》, 《Spring Cloud微服务 入门 实战与进阶》做者, 公众号猿天地发起人。