【悟思维】项目架构决定性能？优秀的架构胜过一万次的调优

这个问题很容易理解，一个单节点（一台应用服务器+一台数据库服务器）的系统架构，任凭你使出浑身解数来调优也不可能让系统达到百万级并发，别说百万级了，上万并发都不可能。不说其他的，在一个性能相对不错的物理机上，mysql最多也就能承载3500-4500的QPS，你说你能调优调到上万并发？？在目前来看如果不借助于其他组件或者其他技术手段是不太可能的。

首先大家要明白一个最底层的逻辑，所有的性能问题归根结底绝大多数都是要解决IO的读写性能问题。

我们在线程模型上面孜孜不倦的追求，从BIO到NIO，再到reactor，最后到proactor，对这些模型的追求本质上就是不断对IO性能的追求。

那IO又分为读IO和写IO，在单节点上，高并发上来之后，请求直接通过tomcat打到mysql上达到3500qps左右的时候，mysql就会报警了，这时候怎么办？

打到mysql上的请求无非就是读和写，所以我们分两种情况来处理：

• 一是解决读IO的问题，如何解决？最直接的就是我们把热点数据直接放内存里（走逻辑io），不走mysql了（走mysql实际是到磁盘去拿数据的，走的是物理IO），所以我们大名鼎鼎的redis就派上用场了。绝大部分热点数据都存放在redis，高并发时候，读IO绝大部分都走redis了，这样就减轻了mysql的负担。
• 二是解决写IO的问题，当大量的写需求到达mysql的时候，如果我们在mysql前面加上消息队列相关组件，让写请求先进队列，然后再通过队列慢慢依次的来对mysql进行写操作，那么这样不就减轻了mysql的写请求IO了吗？

所以我们的架构就从单一架构（比如说是tomcat+mysql）变成了（tomcat+mq+redis+mysql）的架构，这两种架构的性能有着天壤之别。因为mq和redis分别解决了高并发时的读写问题，这才是影响性能的根本因素。那么第二种架构还有很多的优化空间，比如我们继续给他增加多级缓存，redis再做集群，mq也做集群，甚至tomcat，mysql都做集群，那么这个系统将会变的非常庞大，也更加的复杂，但是带来的效果却是显而易见的，达到百万并发，千万并发甚至亿级并发都是有可能的。

源码级系统调优参考文档：https://docs.qq.com/doc/DQnVueFhibEF4eEha