后端架构师三步调优，服务器吞吐量翻倍

　　去年春天，我盯着阿里云华北2区的一组ECS实例监控看——32核128G的r7实例，QPS卡在840上下抖动，CPU软中断持续占满两个核心，Redis连接池超时报警每分钟响三回。这组服务跑的是订单履约中台，日均调用量1.2亿次，用的Spring Boot 2.7.18 + MyBatis Plus 3.5.3 + ShardingSphere-JDBC 5.1.2，数据库是MySQL 8.0.33主从集群，读写分离配置里硬编码了3个从库IP。

　　第一步调优：把ShardingSphere-JDBC的SQL路由缓存从默认的1000条扩到16384条——这个数字不是拍的，是我们在压测时发现SQL指纹碰撞率从7.3%跌到0.09%才定下来的。紧接着干掉自研的“兜底重试拦截器”，它在上游Nginx timeout为3秒时，会偷偷发起第二次全链路重试，导致瞬时流量被放大2.4倍。上线后第37分钟，QPS跳到1160，但凌晨2点突然崩了：线程堆栈显示217个Thread处于BLOCKED状态，全堵在HikariCP的getConnection()里——原来我们忘了调Connection Timeout，它死等30秒才抛异常。

　　第二步换掉了Jackson的ObjectMapper全局单例。这事真没人提过——它默认开启FAIL_ON_UNKNOWN_PROPERTIES，每次反序列化JSON都要反射校验字段名，光这一项就吃掉11.2%的CPU时间。我们切到Jackson 2.15.2 + @JsonAutoDetect(fieldVisibility = JsonAutoDetect.Visibility.ANY)，又给每个微服务进程配了独立ObjectMapper实例（非static），并加了@JsonIgnoreProperties(ignoreUnknown = true)。实测单请求平均耗时降了28ms。但第二天支付回调接口开始丢数据：查日志发现Alipay SDK返回的notify_url响应体里混着Windows-1252编码的特殊字符，而新ObjectMapper没配CharsetDetector——这是我自己漏掉的坑，花了6小时回滚补编码识别逻辑。

　　第三步最狠：把Netty的EventLoopGroup线程数从CPU×2硬改成了CPU×1.4——就是12个，不是16个。很多人不敢动这个，怕吞吐掉，可我们抓包发现超过30%的ChannelActive事件发生在同一毫秒级窗口，线程争抢严重。调整后TCP重传率从0.8%压到0.17%，GC Young GC频率少了41%。不过这招只适用于IO密集型场景；上个月给另一个团队复刻时，他们那套计算密集型推荐引擎反而QPS掉了19%，因为他们用的是ForkJoinPool做实时特征工程，Netty线程缩得太紧，特征计算队列积压了2.7秒——新技术真不是万能膏药，得看血管里流的是啥血。

文章配图，仅供参考

　　吞吐量翻倍了，但慢SQL还剩37条没动。

　　要不要下周拉DBA一起啃下那条关联6张表、执行计划走了4层嵌套循环的报表查询？

（编辑：站长网）

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