原创：猿天地（微信公众号 ID：cxytiandi），欢送分享，转载请保留出处。
读写拆散是什么？读写拆散的作用就不讲了，如果有不理解的同学能够本人去搜寻材料进行理解。或者查看我之前的文章读写拆散。
一开始的场景必定都基于主库去做增删改查的操作，等前面压力缓缓上来后才会思考加数据库的从节点，通过读写拆散的形式来进步查问的性能。
首先读写拆散默认查问都是走从节点的。
从咱们的应用习惯或者业务的场景来说，查问的场景是大于增删改的。所以咱们会在须要走主库进行数据操作的业务场景下，手动去管制这条 Sql 要去主库执行，这个管制的逻辑能够本人写，也能够利用框架自带的性能实现，就不细讲了。
比方咱们定义一个注解 @Master 用于标记此办法走主库操作，而后通过 Aspect 能够去切换数据源。这其实是很常见的实现形式，如果说你一开始就有从节点，就标准了这么做是没问题的，如果是前面新增了从节点要开始做读写拆散，这么做是存在问题的。
一旦这么做的话，对于增删改的操作没有问题，对于查的操作可能会有问题。这个问题不是说有 Bug，而是有一些体验上的问题可能会导致 Bug。大家都晓得主从架构其实是存在数据提早的问题，只有有提早那么就有可能呈现问题。
某些业务场景下，你新增了一条数据，而后会马上跳到详情去，此时如果数据有提早，到详情的时候去查问从节点，就查不到刚刚新增的数据，会存在这样的问题。
解决办法就是把所有业务场景都整顿下，而后让测试整体回归一遍，将须要走主库操作的查询方法都加上 @Master 注解，就不会有问题了。
看似没有任何问题，其实大家疏忽了一点就是工夫老本问题。要整顿业务场景，要整体回归测试，这些都是要花工夫的，工夫就是最大的老本。
所以咱们在前期做读写拆散的时候，基本上不会采纳下面的形式去实现，因为业务性能越多，老本越高。
真正的做法是反着来，无论实现任何新性能，咱们都要思考的点就是如何让影响最小？如何不影响之前的逻辑？
办法就是所有的老逻辑都不动，默认还是走主库，然而咱们程序中曾经做了读写拆散的性能，默认查问就是会走从库的，所以第一步就是要将所有查问的 Sql 都发往主库，能够通过 Aspect 实现。
做完了下面这一步就能够间接上线了，因为所有的操作还是走的主库，跟以前没有任何区别，不会影响任何老的逻辑。
当初就要思考哪些查问能够走从库了，然而这个动作能够缓缓做，能够缓缓梳理。这样就会比拟轻松了，每个迭代咱们能够梳理几个走从库的查问，间接加个 @Slave 的注解让它强制走从库，这个场景咱们梳理过，验证过是没问题的。就这样缓缓的整顿，直到所有老逻辑都梳理完。
好的思路可能保障稳定性和易用性，如果有播种那就点个赞呗！
对于作者 ：尹吉欢，简略的技术爱好者，《Spring Cloud 微服务 - 全栈技术与案例解析》,《Spring Cloud 微服务 入门 实战与进阶》作者, 公众号 猿天地 发起人。