由 dawei 某电商系统在大促前遭遇瓶颈：单台应用服务器吞吐量仅800 QPS，响应延迟飙升至1.2秒。后端架构师未急于扩容，而是聚焦三个可量化、易落地的调优点，两周内将QPS稳定提升至1700+，延迟降至450ms以下。
第一步是连接池与数据库访问重构。原应用使用HikariCP默认配置（最大连接数20），但实际业务存在大量短时并发查询，导致连接争抢严重。将连接池最大值动态设为CPU核心数×4，并启用connection-timeout和validation-timeout机制；同时将高频单表查询从MyBatis的XML拼接改为预编译+参数绑定，并为WHERE字段添加复合索引。这使DB平均RT从95ms降至22ms，线程阻塞率下降76%。
第二步是缓存策略精细化升级。旧版Redis仅对全量商品做LRU缓存，命中率仅41%。改为三级缓存架构：本地Caffeine缓存热点SKU（TTL 30s），Redis集群缓存基础属性（带逻辑过期标记），MySQL兜底。关键读接口增加布隆过滤器拦截无效key请求，并将库存校验等强一致性操作拆分为“查缓存+异步校验”双阶段。缓存整体命中率跃升至89%，DB压力降低三分之二。
AI做图，仅供参考
第三步是异步化与线程模型优化。将订单创建中的短信通知、积分更新、日志归档等非核心路径全部下沉至RabbitMQ，应用层只保留主流程事务；同时将Tomcat默认同步阻塞IO切换为基于Netty的WebFlux响应式栈，并按业务权重划分线程池：IO密集型任务用弹性线程池（core=8, max=32），CPU密集型限定为CPU核心数。此举释放了35%的主线程资源，吞吐量曲线变得平滑且无尖刺。
三次调整均通过压测验证：每次上线后观测5分钟内99分位延迟变化与GC频率。所有改动无需修改业务逻辑，仅依赖配置优化与组件替换。最终单机资源利用率更均衡，横向扩容成本延后三个月，更重要的是——团队建立了“指标驱动调优”的闭环习惯：从监控发现毛刺，到定位根因，再到小步验证，每一步都可追踪、可回滚、可复用。