由 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全量缓存，缓存失效时引发“雪崩式”回源。改为分级缓存：热点SKU（Top 5%）启用本地Caffeine（TTL=30s）+ Redis双层，中长尾商品仅存Redis（TTL=2h），并加入布隆过滤器拦截无效ID请求。缓存命中率从68%跃升至93%，DB查询压力减少55%。
第三步是异步化与线程模型优化。原同步处理订单创建后的通知、积分更新、日志写入等操作，占用了Web容器线程池60%以上。引入RabbitMQ解耦耗时任务，并将Spring MVC的Servlet容器线程池（tomcat.max-threads=200）拆分为IO线程池（专管HTTP连接）与业务线程池（处理非阻塞逻辑）。Web线程池仅保留50个，其余任务移交独立调度池，平均请求排队时间从180ms归零。
AI模拟效果图，仅供参考
三项调整均无代码重写，仅通过配置优化、SQL治理与组件替换完成。上线后监控显示：CPU利用率平稳在65%左右（原峰值92%），GC频率降低40%，错误率趋近于0。关键在于拒绝“大而全”的优化幻想，从可观测数据出发，每个改动都对应明确指标验证——当吞吐翻倍不再依赖硬件堆砌，而是源于对链路每个环节的精准施力。