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

读写分离是什么？读写分离的作用就不讲了，如果有不了解的同学可以自己去搜索资料进行了解。或者查看我之前的文章读写分离。

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

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

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

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

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

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

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

所以我们在后期做读写分离的时候，基本上不会采用上面的方式去实现，因为业务功能越多，成本越高。

真正的做法是反着来，无论实现任何新功能，我们都要考虑的点就是如何让影响最小？如何不影响之前的逻辑？

方法就是所有的老逻辑都不动，默认还是走主库，但是我们程序中已经做了读写分离的功能，默认查询就是会走从库的，所以第一步就是要将所有查询的Sql都发往主库，可以通过Aspect实现。

做完了上面这一步就可以直接上线了，因为所有的操作还是走的主库，跟以前没有任何区别，不会影响任何老的逻辑。

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