三步走，QPS从5k飙到10k，架构师秘籍在此

发布时间：2026-10-09 05:18:22 所属栏目：系统来源：DaWei

导读：我上周二晚上十一点四十七把 wrk 的并发从两百调到八百，Nginx 1.24 后面的订单接口 QPS 卡在五千一百六十三，P99 飘到二点三秒，架构师老周站在我工位旁边，把烟按灭在易拉罐上，说“这三步走绝对稳，先加缓存，再分库，最后上 Kafk

我上周二晚上十一点四十七把 wrk 的并发从两百调到八百，Nginx 1.24 后面的订单接口 QPS 卡在五千一百六十三，P99 飘到二点三秒，架构师老周站在我工位旁边，把烟按灭在易拉罐上，说“这三步走绝对稳，先加缓存，再分库，最后上 Kafka，QPS 不上万我名字倒着写”。

文章配图，仅供参考

我差点信了。
别吹三步走，先看监控面板
我周三凌晨两点零六打开 Grafana，看 Prometheus 里那台 Nginx 1.24 的 QPS 曲线，五千一百六十三的平线像被尺子压过，502 从每分钟零次跳到三百四十七次。连接队列的 `net.core.somaxconn` 还是 128，`worker_connections` 是 1024，`ulimit -n` 我忘了改，只有 1024。这秘籍根本不管你的慢查询长什么样，他居然把连接池从两百改到五百就喊胜利，结果 MySQL 8.0 的 `max_connections` 打到 480，HikariCP 开始报连接超时。SQL 里 `order_id` 缺索引那条跑了一点八秒，每天出现六百多次，慢查询日志里 `t_yh_ksjl_bak` 这张拼音缩写备份表还被定时任务全表扫，一次扫九十三万行。
加缓存之前，先查慢查询
我上个月十七号在预发环境用 arthas 看 JDK 17 的 GC，Full GC 每十二秒一次，每次停一点四秒。Redis 7.0 里 `qps:tmp:aaa` 这个临时 key 没有 TTL，内存碎片率一点八，我把 Pipeline 从关调成开，批量两百条，QPS 从五千一百六十三涨到八千四百零二，P99 掉到七百九十毫秒。可 502 还在，因为 Kafka 消费者那边线程池只有四，积压了二十七万条，扩容到十六个线程后 504 从每分钟一百二十次降到零。这简直是把压测当算命，不看队列深度就喊扩容。
连接池调大，QPS未必翻倍
昨天下午四点二十，我把 HikariCP 的 `maximumPoolSize` 从两百改成三百，MySQL 8.0 的 `max_connections` 跟着改到六百，QPS 只从八千四百零二爬到八千七百一十五，GC 停顿反倒从一点四秒涨到二点一秒，JDK 17 的 ZGC 也没救回来。原因是每个请求在 SQL 里做了七次查询，其中三次是 `select from t_yh_ksjl_bak where user_id=?`，索引是 `idx_user_created`，但查询只带 `user_id`，左前缀没吃到。我把这条 SQL 改成带 `created_at` 范围，QPS 跳到九千六百三十，连接池调大根本没用，少一次查询才管用。
压到一万，靠的是少做事
我把 Nginx 1.24 的 `keepalive_timeout` 从 75 改成 15，`proxy_http_version` 设成 1.1，`proxy_set_header Connection ""`，前端长连接从百分之三十升到百分之八十二，TIME_WAIT 从一万九千掉到三千一。Kafka 生产端加 `linger.ms=20`，批量大小调到 128KB，Prometheus 里 QPS 曲线摸到一万零四十七，P99 是四百一十八毫秒，502 和 504 都压到个位数。我二零一九年做电商订单自动化脚本时，MySQL 5.7 加 Redis 2.8，单机 QPS 只有一千二，堆六台机器才到四千。现在一台 Nginx 1.24 加两台应用节点，JDK 17 加 MySQL 8.0，QPS 一万，绝不是靠什么三步走秘籍，是先把慢查询、连接池、GC、队列深度全摊在 Grafana 上，一个一个删。老周那套三步走绝对只覆盖了加缓存、分库、上 Kafka，没写 `net.core.somaxconn` 和 `ulimit`。我把 wrk 的并发重新降到五百，QPS 停在九千七百四十二，Grafana 上那条线还在抖

（编辑：站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!

三步走，QPS从5k飙到10k	系统优化与容器编排：8
客户端协同下的容器部