最全记一次性能优化，单台4核8G机器支撑5万QPS！，2024年最新阿里开发7年大牛

网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。

需要这份系统化的资料的朋友，可以戳这里获取

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！

首先大家要明确的一点是，脱离需求谈优化都是耍流氓，所以有谁跟你说在xx机器上实现了百万并发，基本上可以认为是不懂装懂了，单纯的并发数完全是无意义的。其次，我们优化之前必须要有一个目标，需要优化到什么程度，没有明确目标的优化是不可控的。再然后，我们必须明确的找出性能瓶颈在哪里，而不能漫无目的的一通乱搞。

需求描述

这个项目是我在上家公司负责一个单独的模块，本来是集成在主站代码中的，后来因为并发太大，为了防止出现问题后拖累主站服务，所有由我一个人负责拆分出来。对这个模块的拆分要求是，压力测试QPS不能低于3万，数据库负责不能超过50%，服务器负载不能超过70%, 单次请求时长不能超过70ms，错误率不能超过5%。

环境的配置如下:
服务器：4核8G内存，centos7系统，ssd硬盘
数据库：Mysql5.7，最大连接数800
缓存: redis, 1G容量。
以上环境都是购买自腾讯云的服务。
压测工具：locust，使用腾讯的弹性伸缩实现分布式的压测。

需求描述如下：
用户进入首页，从数据库中查询是否有合适的弹窗配置，如果没有，则继续等待下一次请求、如果有合适的配置，则返回给前端。这里开始则有多个条件分支，如果用户点击了弹窗，则记录用户点击，并且在配置的时间内不再返回配置，如果用户未点击，则24小时后继续返回本次配置，如果用户点击了，但是后续没有配置了，则接着等待下一次。

重点分析

根据需求，我们知道了有几个重要的点，1、需要找出合适用户的弹窗配置，2、需要记录用户下一次返回配置的时间并记录到数据库中，3、需要记录用户对返回的配置执行了什么操作并记录到数据库中。

现在我也找了很多测试的朋友，做了一个分享技术的交流群，共享了很多我们收集的技术文档和视频教程。
如果你不想再体验自学时找不到资源，没人解答问题，坚持几天便放弃的感受
可以加入我们一起交流。而且还有很多在自动化，性能，安全，测试开发等等方面有一定建树的技术大牛
分享他们的经验，还会分享很多直播讲座和技术沙龙
可以免费学习！划重点！开源的！！！
qq群号：310357728【暗号：csdn999】

调优

我们可以看到，上述三个重点都存在数据库的操作，不只有读库，还有写库操作。从这里我们可以看到如果不加缓存的话，所有的请求都压到数据库，势必会占满全部连接数，出现拒绝访问的错误，同时因为sql执行过慢，导致请求无法及时返回。所以，我们首先要做的就是讲写库操作剥离开来，提升每一次请求响应速度，优化数据库连接。整个系统的架构图如下：

将写库操作放到一个先进先出的消息队列中来做，为了减少复杂度，使用了redis的list来做这个消息队列。

然后进行压测，结果如下：
QPS在6000左右502错误大幅上升至30%，服务器cpu在60%-70%之间来回跳动，数据库连接数被占满tcp连接数为6000左右，很明显，问题还是出在数据库，经过排查sql语句，查询到原因就是找出合适用户的配置操作时每次请求都要读取数据库所导致的连接数被用完。因为我们的连接数只有800，一旦请求过多，势必会导致数据库瓶颈。好了，问题找到了，我们继续优化，更新的架构如下

我们将全部的配置都加载到缓存中，只有在缓存中没有配置的时候才会去读取数据库。

接下来我们再次压测，结果如下：
QPS压到2万左右的时候就上不去了，服务器cpu在60%-80%之间跳动，数据库连接数为300个左右，每秒tpc连接数为1.5万左右。

这个问题是困扰我比较久的一个问题，因为我们可以看到，我们2万的QPS，但是tcp连接数却并没有达到2万，我猜测，tcp连接数就是引发瓶颈的问题，但是因为什么原因所引发的暂时无法找出来。

这个时候猜测，既然是无法建立tcp连接，是否有可能是服务器限制了socket连接数，验证猜测，我们看一下，在终端输入ulimit -n命令，显示的结果为65535，看到这里，觉得socket连接数并不是限制我们的原因，为了验证猜测，将socket连接数调大为100001.

再次进行压测，结果如下：

QPS压到2.2万左右的时候就上不去了，服务器cpu在60%-80%之间跳动，数据库连接数为300个左右，每秒tpc连接数为1.7万左右。

虽然有一点提升，但是并没有实质性的变化，接下来的几天时间，我发现都无法找到优化的方案，那几天确实很难受，找不出来优化的方案，过了几天，再次将问题梳理了一遍，发现，虽然socket连接数足够，但是并没有全部被用上，猜测，每次请求过后，tcp连接并没有立即被释放，导致socket无法重用。经过查找资料，找到了问题所在:

tcp链接在经过四次握手结束连接后并不会立即释放，而是处于timewait状态，会等待一段时间，以防止客户端后续的数据未被接收。

好了，问题找到了，我们要接着优化，首先想到的就是调整tcp链接结束后等待时间，但是linux并没有提供这一内核参数的调整，如果要改，必须要自己重新编译内核，幸好还有另一个参数net.ipv4.tcp_max_tw_buckets， timewait 的数量，默认是 180000。我们调整为6000，然后打开timewait快速回收，和开启重用，完整的参数优化如下

网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。

需要这份系统化的资料的朋友，可以戳这里获取

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！

cb)**

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！