2024年记一次性能优化，单台4核8G机器支撑5万QPS！，2024年最新独家发布

本文链接：https://blog.csdn.net/2401_84563734/article/details/138509197

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

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

现在我也找了很多测试的朋友，做了一个分享技术的交流群，共享了很多我们收集的技术文档和视频教程。
如果你不想再体验自学时找不到资源，没人解答问题，坚持几天便放弃的感受
可以加入我们一起交流。而且还有很多在自动化，性能，安全，测试开发等等方面有一定建树的技术大牛
分享他们的经验，还会分享很多直播讲座和技术沙龙
可以免费学习！划重点！开源的！！！
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快速回收，和开启重用，完整的参数优化如下

#timewait 的数量，默认是 180000。
net.ipv4.tcp_max_tw_buckets = 6000

net.ipv4.ip_local_port_range = 1024 65000

#启用 timewait 快速回收。
net.ipv4.tcp_tw_recycle = 1

#开启重用。允许将 TIME-WAIT sockets 重新用于新的 TCP 连接。
net.ipv4.tcp_tw_reuse = 1

我们再次压测，结果显示：
QPS5万，服务器cpu70%,数据库连接正常，tcp连接正常，响应时间平均为60ms，错误率为0%。