老大说了，即使你是女程序员，这性能调优你也得拿下！

浅浅的花香味﹌ 2023-02-15 07:58 3阅读 0赞

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

这个问题很容易理解，一个单节点（一台应用服务器+一台数据库服务器）的系统架构，任凭你使出浑身解数来调优也不可能让系统达到百万级并发，别说百万级了，上万并发都不可能。不说其他的，在一个性能相对不错的物理机上，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://smartan123.github.io/book/?file=001-%E6%80%A7%E8%83%BD%E4%BC%98%E5%8C%96/001-%E6%80%A7%E8%83%BD%E4%BC%98%E5%8C%96%E9%9D%A2%E8%AF%95%E9%A2%98%E9%9B%86%E9%94%A6][https_smartan123.github.io_book_file_001-_E6_80_A7_E8_83_BD_E4_BC_98_E5_8C_96_001-_E6_80_A7_E8_83_BD_E4_BC_98_E5_8C_96_E9_9D_A2_E8_AF_95_E9_A2_98_E9_9B_86_E9_94_A6]

[https_smartan123.github.io_book_file_001-_E6_80_A7_E8_83_BD_E4_BC_98_E5_8C_96_001-_E6_80_A7_E8_83_BD_E4_BC_98_E5_8C_96_E9_9D_A2_E8_AF_95_E9_A2_98_E9_9B_86_E9_94_A6]: https://smartan123.github.io/book/?file=001-%E6%80%A7%E8%83%BD%E4%BC%98%E5%8C%96/001-%E6%80%A7%E8%83%BD%E4%BC%98%E5%8C%96%E9%9D%A2%E8%AF%95%E9%A2%98%E9%9B%86%E9%94%A6