本文转载自微信公众号《猿世界》，作者尹继焕。转载本文请联系元天地公众号。什么是读写分离？读写分离的作用就不说了。有不懂的同学可以自行搜索资料。初始场景必须基于主数据库进行增删改查操作。压力逐渐上升后，会考虑增加数据库从节点，通过读写分离来提高查询性能。首先，读写分离默认查询是去从节点。从我们的使用习惯或者业务场景来看，查询场景比增删改查更大。所以在需要主库进行数据操作的业务场景下，我们会手动控制这个Sql去主库执行。这个控件的逻辑可以自己写，也可以使用框架自带的函数来实现，就不赘述了。比如我们定义一个注解@Master来标记这个方法为主库操作，然后通过Aspect来切换数据源。这实际上是一个非常常见的实现。如果一开始就有slave节点，标准化是没有问题的。如果后面添加了新的slave节点，开始读写分离，这个就有问题了。.这样一来，增删改查操作就没有问题了，但是查询操作就可能有问题了。这个问题不是说有bug，而是有一些经验问题可能会导致bug。大家都知道主从架构其实存在数据延迟的问题。只要有延迟，就可能有问题。在某些业务场景下，如果你新增一条数据，会立即跳转到详情。这时候如果数据延迟了，你去明细的时候就找不到新添加的数据了。问题。解决方法是把所有的业务场景梳理一遍，然后整体返回测试，在需要经过主数据库操作的查询方法上加上@Master注解，这样就不会出问题了。看似没有问题，但其实大家都忽略了时间和成本的问题。业务场景的整理和整体的回归测试都需要时间，而时间是最大的成本。所以后期我们在做读写分离的时候，基本不会使用上面的方式来实现，因为业务功能越多，成本越高。真正的方法是反过来做。无论实现什么新功能，我们要考虑的一点是如何将影响降到最低？如何不影响之前的逻辑？方法是保持所有旧逻辑不变，默认使用主库，但是我们的程序已经实现了读写分离的功能，默认查询会去从库，所以第一步是将所有查询Sql发送到主库，可以通过Aspect实现。完成上面这一步后，就可以直接上线了，因为所有的操作还是去主库，和之前没有什么区别，不会影响到任何老逻辑。现在我们要考虑哪些查询可以从库中去，但是这个动作可以慢慢来，慢慢整理。这将使它更容易。在每次迭代中，我们可以整理出几个从库中去的查询，直接加上@Slave注解强制从库中去。我们已经梳理了这个场景，验证没有问题。慢慢梳理，直到所有的旧逻辑都梳理完。好的想法可以确保稳定性和易用性。如果你有收获，请点个赞！作者简介：尹继焕，单纯技术爱好者，《Spring Cloud 微服务-全栈技术与案例解析》、《Spring Cloud 微服务 入门 实战与进阶》、公众号元天地作者
