读写分离后，性能居然提升100%了呀

欢迎大家来到IT世界,在知识的湖畔探索吧!

今天来聊一个简单但重要的问题。最近自己搭建了一个项目玩一下，跑起来也是挺顺溜的，但是，在做压测的时候，发现接口的性能出现瓶颈，最后发现慢动作出现在MySQL.

这可咋办呢？索引也优化了，连接池也用上了，Redis缓存命中率也符合预期。然而，所有的请求都集中在一台主MySQL上，压测的时候，还是挺吃力的，那就来试试读写分离吧。

欢迎大家来到IT世界,在知识的湖畔探索吧!

一. 主从复制逻辑

数据库一主多从，是很经典的结构，对于数据库的容灾、可扩展性和高可用性，都是有好处的。一主多从，依赖于主从复制，下面是主从复制的逻辑图，一起来看看：

主从复制后，可以认为，从库和主库的内容是”一致”的，这里指的是最终一致性。 对读实时性要求不高的业务场景中，读写分离是没有问题的，数据会最终一致。

然而，必须要说的是，由于主从复制需要时间，向主库写入数据后，如果直接从从库读取，可能读不到最新的值。所以，具体读主库还是从库，取决于业务场景。

主从复制后，就可以开心地进行读写分离了。具体来说就是，让所有的写请求调度到主库，让大量读请求调度到从库。读写分离的逻辑图如下，非常直观且易懂：

二. 读写分离效果

在实际测试中，将大量的读请求调度到从库，在主库上留下写请求和少量的读请求，可以看到，读写分离后，主库上的少量读请求耗时立即明显下降且稳定：

而且，实际也发现，调读到从库上后，大量读请求的耗时也有下降。自然地，主库上的写请求的性能也提升了近100%。读写分离的好处，可见一斑。爽爽哒！

对于应用服务来说，也可做读写分离。比如某服务提供读和写的接口，主调方可做读写分离，这样就能针对读和写进行不同的伸缩策略，提升了扩展的弹性。

这篇文章的内容很简单，关键在于理解主从复制的过程，以及读写分离的原理。而且，对于软件开发人员来说，动手实践是极好的学习方式。实践之后，体会了过程，看到了结果，知识和技能就是自己的了。一起加油吧。

来源：https://mp.weixin..com/s/6ZjgUwoQcLjc62PhU0fBdQ