中后期数据库查询主从关系构架的困扰，确实痛

原創：猿乾坤（微信公众平台ID：cxytiandi），热烈欢迎共享，转截请保存来源。

读写分离是啥？读写分离的功效也不讲了，如果有不了解的同学们能够自身去检索材料开展掌握。或是查询我以前的文章内容读写分离。

一开始的情景毫无疑问都根据主库去做增删的实际操作，等后边工作压力渐渐地上去后才会考虑到加数据库查询的从连接点，根据读写分离的方法来提升查看的特性。

最先读写分离默认设置查看全是走从连接点的。

从大家的应用习惯性或是业务流程的情景而言，查看的情景是超过删改改的。因此大家会在必须走主库开展数据信息实际操作的业务场景下，手动式去操纵这一条Sql要去主库实行，这一操纵的逻辑性能够自身写，还可以运用架构内置的作用完成，也不细讲了。

例如大家界定一个注释 @Master 用以标识此方式 走主库实际操作，随后根据Aspect能够去转换数据库。这实际上是很普遍的完成方法，假如说你一开始就会有从连接点，就标准了那么做是没什么问题的，如果是后边增加了从连接点要逐渐做读写分离，那么做是存在的问题的。

一旦那么做得话，针对删改改的实际操作没有问题，针对查的实际操作很有可能会有什么问题。这个问题不是说有Bug，只是有一些感受上的难题很有可能会造成 Bug。大家都了解主从关系构架实际上是存有数据信息延迟时间的难题，只需有延迟时间那麼就会有很有可能发生难题。

一些业务场景下，你增加了一条数据信息，随后会立刻跳到详细信息去，这时假如数据信息有延迟时间，到详细信息的情况下去查看从连接点，就查不出刚增加的数据信息，会存有那样的难题。

解决方案便是把全部业务场景都梳理下，随后让检测总体重归一遍，将必须走主库实际操作的如何查询都再加上 @Master 注释，就不容易有什么问题了。

看起来沒有一切难题，实际上大伙儿忽视了一点便是经济成本难题。要梳理业务场景，要总体回归测试，这种全是要花时间的，时间就是较大的成本费。

因此我们在中后期做读写分离的情况下，大部分不容易选用上边的方法去完成，由于业务流程作用越多，成本费越高。

真真正正的作法是反着来，不管完成一切新作用，我们都要考虑到的点便是怎么让危害最少？怎样不危害以前的逻辑性？

方式 便是全部的老逻辑性都没动，默认设置或是走主库，可是大家程序流程中早已干了读写分离的作用，默认设置查看便是会走从库的，因此第一步便是要将全部查看的Sql都寄往主库，能够根据Aspect完成。

做完了上边这一步就可以立即上线，由于全部的实际操作或是走的主库，跟之前沒有一切差别，不容易危害一切老的逻辑性。

如今就需要考虑到什么查看能够走从库了，可是这一姿势能够渐渐地做，能够渐渐地整理。那样便会较为轻轻松松了，每一个迭代更新我们可以整理好多个走从库的查看，立即加个 @Slave 的注释让它强制性走从库，这一情景大家整理过，认证过是没什么问题的。就是这样渐渐地的梳理，直至全部老逻辑性都整理完。

好的构思可以确保可靠性和便捷性，如果有获得那么就点个赞呗！

有关创作者：尹吉欢，简易的技术爱好者，《Spring Cloud微服务-全栈技术与案例解析》, 《Spring Cloud微服务 入门 实战与进阶》创作者, 微信公众号猿乾坤发起者。