从压测到降本：服务端、数据库与缓存的协同优化实战

周末把压测报告整理完，我盯着那份成本账单看了很久。一台2C8G的云主机跑着我们的核心API服务，数据库是4C16G的RDS，Redis是1G的标准版实例，一个月的总成本其实不算高，但如果我们能用压测数据证明“1C4G就能扛住日常流量”，一年省下来的钱够给团队加好几顿好的。

这就是压测真正有价值的地方——它不仅告诉你系统能不能撑住流量洪峰，更告诉你每一分钱花在哪个环节，哪些配置是性能过剩，哪些瓶颈其实是被钱堆出来的。这篇文章我会把自己从压测方案设计、工具选型、瓶颈定位到成本优化的完整过程拆开来讲，重点落在服务端、数据库、缓存三者如何协同优化，以及预算敏感时的取舍逻辑。适合正在做性能调优、准备大促备战、或者单纯想把云成本打下来的后台开发同学参考。

1. 项目背景与压测目标拆解

1.1 为什么要做压测，不只是为了应付流量洪峰

压测最容易被人误解为“大促前夕才做的事”。我见过不少团队，平时接口响应100ms说“还行”，结果活动页面一上线，数据库连接数直接打满，Redis缓存穿透把后端拖垮，用户在App上转圈三分钟，最后只能紧急扩容加机器。这种被动救火的代价，远比系统性做一次压测要高得多。

从另一个角度看，压测也是成本优化的前置条件。没有压测数据，你说“这台2C8G的服务器够用了”是拍脑袋；有了压测报告，你能明确说出“在3000 QPS的流量下，当前配置CPU使用率65%，内存峰值2.1G，带宽占用40MB/s，可以缩容到2C4G”。云厂商的账单是按配置收费的，你多租的那部分性能如果常年闲置，就是在给机房交冤枉钱。所以这次压测的核心目标有两个：一是找出系统在容量边界上的真实表现，二是把服务和资源的最佳匹配关系摸清楚。

1.2 这次压测要回答的三个核心问题

落地之前先明确问题，否则压测容易变成“为了压测而压测”。我给自己定了三个必须回答的问题：

第一个问题，系统当前的真实容量边界在哪。具体就是指在保证P95延迟不超过500ms的前提下，服务端、数据库、缓存分别能承受多大的QPS。注意这里是三个要素各自的能力，不是混在一起看，因为瓶颈点可能只出在其中某一层。

第二个问题，瓶颈到底在哪一层。服务端CPU飙升、数据库慢查询暴增、缓存命中率低于80%，这三类问题的优化思路完全不同。如果连瓶颈在哪一层都没定位清楚就动手优化，大概率是白忙活。

第三个问题，满足业务要求的最小资源配比是什么。这个问题的答案直接指导成本优化——哪些资源可以降配，哪些性能参数值得调，哪些冗余是必须保留的。单纯说“加机器”不是优化，找到“不用加机器也能扛住”的方案才是优化。

2. 压测方案设计与工具选型

2.1 工具选型：JMeter、Sob、内部自研工具怎么选

压测工具的选择直接决定整个压测过程的效率和结果的可靠度。目前市面上的主流方案有JMeter、Sob（单机压测工具，基于Go开发）、wrk、Gatling，以及各大云厂商自带的压测服务。

JMeter核心优势是生态成熟、上手容易、GUI界面直观，适合团队协作和测试人员使用。不过它在高并发下有一个比较明显的短板：单机压测时，JMeter本身会占用不少资源，当压测目标服务的QPS达到几千甚至上万时，JMeter所在的机器可能先扛不住了。这会导致压测结果失真——不是你服务不行，而是压测工具已经成为了瓶颈。

Sob这类工具的优势在于无GUI、纯命令行、基于协程，单机可以轻松产生几万QPS的压力。我用它做接口级压测比较多，配置脚本也简单，一个yaml文件搞定。wrk适合快速验证单个接口的性能，但它只能发HTTP请求，无法做复杂的业务场景串联。选型时我给的建议是：如果你要模拟接近真实的用户行为链路（比如登录、加购物车、下单、支付），JMeter或Gatling更合适；如果你只是要压测某个核心接口的极限QPS，用Sob或wrk效率更高。

2.2 压测脚本设计：控制好QPS、并发线程和Ramp-Up

压测脚本不是随便填几个数字就能跑，参数设计不合理会导致结果完全没有参考意义。这中间最关键的几个参数是持续时长、并发线程数、Ramp-Up时间和压力模型。

持续时长这一点我踩过坑。最初压测时设了1分钟，结果CPU曲线刚拉起来就到时间了，数据根本不稳定。后来我把每次压测的持续时间定为5分钟起步，前2分钟用来让系统进入稳定状态，中间2分钟取有效数据，最后1分钟观察资源释放情况。这个习惯后来帮我发现了不少“启动即崩溃”和“内存泄漏”的隐蔽问题。

并发线程数和Ramp-Up的配合也很重要。JMeter里线程组设置100并发，Ramp-Up设成10秒，那JMeter会在这10秒内逐步把100个线程拉起，而不是一瞬间全部压上去。这样做的好处是可以模拟真实业务中的流量渐变，也能帮我们观察系统从低负载到高负载过渡时的表现。如果一上来就全量施加压力，系统可能会在初始几秒内出现假性故障，导致误判。

2.3 监控配套：压测不做监控等于白测

压测过程中如果没有监控，你只能从最终结果里看到“接口失败率95%”，但完全不知道是CPU先崩的、内存先爆的，还是数据库连接池被耗尽。所以在压测脚本启动之前，我建议先把监控体系布置好，至少覆盖以下四层。

第一层是机器指标监控，包括CPU、内存、磁盘IO、网络带宽，这一层用Prometheus加Node Exporter就能覆盖。第二层是应用层监控，包括JVM的堆内存使用、GC频率、线程池活跃线程数、接口耗时分布，这一层可以用Actuator加Micrometer暴露到Prometheus。第三层是数据库监控，重点看连接数、慢查询数量、InnoDB的行锁等待次数、Buffer Pool命中率，这一层可以借助MySQL自带的Performance Schema或Percona Toolkit。第四层是缓存监控，Redis的命中率、内存使用率、键过期淘汰数量，用Redis自带的INFO命令就能拿到关键指标。

我这次的实战就是在这四层监控都就位后，才开始正式跑压测脚本。实际使用中，观察监控面板上的指标变化往往比盯着压测工具的进度条更有价值，因为瓶颈出现时，监控指标通常比压测工具报错要早几秒钟。记住这个时间差，能帮你在压测过程中就能大致圈定瓶颈范围。

3. 压测过程记录与瓶颈定位

3.1 第一层：服务端CPU飙高与GC毛刺

第一轮压测我直接用Sob对核心订单查询接口施加压力，目标QPS设置为2000，持续五分钟。前30秒一切正常，但从第40秒开始，服务端的CPU使用率从35%一路飙升到90%以上，其中有一个特别明显的规律：CPU曲线并不是平稳上升，而是呈现一种“锯齿状”的波动。每个波峰的间隔大概在15秒左右，这个规律引起了我对GC的怀疑。

我拉出JVM的GC日志一看，Young GC每5秒一次，Full GC在压测开始后1分20秒出现了一次，紧接着1分35秒又出现一次。这就是典型的GC毛刺问题。Full GC发生时会触发Stop-The-World，所有业务线程都暂停执行，外部表现就是接口响应时间突然从80ms跳到2000ms。进一步排查堆内存配置，发现-Xmx只设置了512MB，但订单查询接口一次会加载不少业务对象，堆内存根本不够用。

这个问题表面是配置不合理，本质是代码和配置的匹配度不高。我调整了JVM参数，把堆内存调大到1GB，同时开启G1垃圾回收器，并设置-XX:MaxGCPauseMillis=100。优化后重新压测，Full GC不再出现，Young GC频率从每5秒一次降到了每20秒一次，接口P95延迟从800ms稳定到了200ms。服务端CPU使用率虽然还是偏高，但至少GC不再是拖后腿的主要因素。

3.2 第二层：数据库慢查询与连接数打满

服务端的问题初步解决后，我把QPS继续往上加，来到3000。这时监控面板开始报警——数据库连接数持续攀升，接口报错中出现大量“Connection pool exhausted”异常。我赶紧看数据库的连接状态，活跃连接数已经达到了200，而连接池最大配置是150。

接下来排查是哪些SQL在拖后腿。我开启慢查询日志，阈值设置为300ms，发现有两个SQL频繁出现。第一个是订单列表查询，WHERE条件里用了user_id和order_time，但表上只有一个user_id的单列索引，导致order_time范围过滤时只能全表扫描。这个表有80万行数据，每次查询扫描20万行，耗时在800ms左右，完全没有利用到索引的特性。

第二个SQL更隐蔽，是一个分页查询。LIMIT 100000, 20这种写法在MySQL里意味着即使你只需要20条数据，MySQL也要先把前10万条读出来再丢弃，性能开销非常大。这个场景更适合用游标分页或延迟关联优化。我给第一个SQL建了联合索引(user_id, order_time)，并把第二个SQL改成了延迟关联写法——先查询主键ID，再关联回原表取完整数据。改造后，这两个SQL的执行时间都降到了50ms以内，数据库连接数也回落到了100左右。

3.3 第三层：缓存命中率低与缓存穿透

数据库优化后压测继续，我把QPS加到4000，这时发现响应时间虽然没崩溃，但曲线出现了一些毛刺。我看Redis的监控，命中率只有62%，这个数字在核心接口上明显偏低。进一步追查原因，发现有三个问题叠加。

第一个问题是缓存过期策略设置不当。订单详情的缓存过期时间我设置了统一的5分钟，这意味着所有订单都会集中在5分钟后集体过期，造成缓存雪崩。压力一上来，所有请求同时打到数据库，数据库压力暴涨。我把过期时间改成了“基础时间加随机偏移”，比如300秒加0到300秒之间的随机值，把过期时间打散，避免大量Key同时失效。

第二个问题是热点Key问题。某些爆款商品的订单详情被大量请求，但它的缓存只有一个Key，Redis单线程在读取大Value时会产生阻塞。我把热点Key做了多副本拆分，在Key后面加上随机后缀，分散到多个键上。虽然这会引入一点数据一致性的复杂度，但对热点场景的收益非常明显。

第三个问题是缓存穿透。恶意请求或者查询不存在的订单ID时，缓存和数据库都没有数据，请求会直接打到数据库。我采用了布隆过滤器方案，在查询缓存前先查布隆过滤器，过滤掉不存在的数据请求。这三个问题处理完之后，缓存命中率从62%提升到了91%，接口的整体吞吐能力明显增强。

4. 协同优化：服务端、数据库、缓存一起调

4.1 服务端优化：从代码到JVM再到容器

很多人优化服务端时只盯着代码，忽视了JVM和容器层面的配合。我这次在压测中最大的体会是：这三层必须作为一个整体来优化。

代码层面，我发现订单详情接口中存在重复查询问题——同一个订单信息，业务里在多个方法中分别查询了一次。我加了统一的数据访问层，用本地缓存（Caffeine）在请求内做了二级缓存，把数据库查询次数直接降了一半。另外一个代码层面的优化是减少了不必要的对象创建，把循环里的字符串拼接改成了StringBuilder，降低Young GC的压力。

JVM层面的优化我在前文已经提到过，堆内存、GC算法、以及关键的MaxGCPauseMillis参数设定。这里补充一个细节：G1并不适合所有场景，如果你服务的特点是堆内存很大（超过8GB）、有明显的长周期大对象，那G1合适；如果是小堆、低延迟、无涉及大对象的场景，ZGC或者Parallel GC可能表现更好。没有银弹，压测数据会告诉你哪个参数更适合你。

容器层面的优化主要体现在线程池配置。我们默认用的是Tomcat的200线程上限，这个数字听起来很大，但如果每个线程都在等数据库返回，200个线程也只能支撑200个并发请求。我用压测数据反推了合理线程数——公式是线程数 = 每秒请求数 * 平均响应时间。当QPS为2000、平均响应时间为100ms时，需要的线程数约为200。但考虑到数据库等待、网络开销，我最终把线程池设为400，并配置了等待队列，让服务端能平滑应对流量波动。

4.2 数据库优化：索引、慢查询和连接池

数据库层面的优化是压测里见效最快、收益最明显的环节。我总结了一条核心原则：先看慢查询日志，再决定怎么建索引。没有慢查询日志的数据库优化都是盲人摸象。

这次压测我们定位到的慢查询集中在三类场景。一类是范围查询的索引失效——之前提到的(user_id, order_time)联合索引，如果你把order_time条件写在user_id前面，索引就会失效，这是SQL写法的问题，跟索引设计没关系。另一类是深分页问题，用延迟关联解决。还有一类是隐式类型转换，字符串字段和数字比较时，MySQL会放弃索引，这个坑比较隐蔽，需要你用EXPLAIN看执行计划才能发现。

连接池这块，我们最初配置的是最大连接数150，后来通过监控发现，正常情况下活跃连接只有30到50个，150的配置意味着有100个连接是多余的。连接数和数据库实例的内存直接相关——每个MySQL连接会分配一定的内存，连接数越多，内存占用越高。把最大连接数从150降到80之后，RDS的可用内存增加了，某种程度也算降低了内存消耗。连接池的核心参数里，initialSize、maxActive、maxWait这三个值要结合压测结果动态调整。maxWait不宜设置太长，否则请求排队时间过长；也不宜太短，否则流量尖峰时会把请求直接打回。

4.3 缓存优化：淘汰策略、热Key拆分与一致性

缓存这块是压测中暴露问题最多的部分，但也是最容易产生“立竿见影”优化效果的部分。先从Redis的淘汰策略说起。默认的maxmemory-policy如果是noeviction，当内存满时，写入操作会直接报错，这在生产环境是致命的。跑压测时我特意把内存占满观察Redis的表现，发现配置的是allkeys-lru，这意味着当内存满时Redis会优先淘汰最久没被访问的Key，这个策略在大多数业务场景是合理的。但如果你有某些Key不想被淘汰，比如配置信息、白名单等，可以用volatile-lru加过期时间的组合——只淘汰设置过期时间的键，不淘汰永久键。

热Key拆分我在这篇文章前面已经提过了，这里补充一个细节。拆分为多个副本之后，你需要考虑缓存更新的问题。如果一次更新只修改了一个副本Key，那用户请求到其他副本时还是会读到旧数据。我采用的方案是：更新时遍历所有副本批量删除，让请求重新回源加载，这样能保证最终一致性，比逐副本刷新要简单可靠。

缓存一致性是大多数团队绕不开的坑。我们熟悉的Cache-Aside模式和更新数据库后直接删缓存的方式，在高并发下存在一个窗口期——旧缓存被删除后，新请求发现缓存为空，回源数据库拿到的可能是旧数据（如果此时数据库还没更新完成），然后旧数据又被写进缓存，缓存就一直是旧的了。针对这个场景，我采用了延迟双删策略：先删缓存，更新数据库后，再隔几百毫秒删一次缓存，确保回源的旧数据不会留在缓存里。相比引入消息队列做异步刷新，这个方案实现成本低，适合大多数中小团队。

5. 成本敏感点分析与降本动作

5.1 压测算成本账：一份MySQL账单的启示

压测做完之后，我顺手把三个核心依赖的成本账单拉出来算了笔账。服务端最核心的订单查询服务，每月固定支出是一台2C8G云主机，按包年价格折算大概每月500元左右；数据库是RDS MySQL 4C16G，每月约1300元；缓存Redis标准版1G，每月约200元。月总成本约2000元，光看数字不算夸张。

但当我用压测数据重新评估时，发现了明显的成本浪费点。日常峰值QPS其实只有1000左右，压测数据显示，服务端在2C4G的配置下就能稳定扛住1000 QPS，CPU使用率在70%左右；数据库流量主要靠缓存扛，正常读数据库的QPS不到200，4C16G的规格明显过大——2C8G就足够；Redis 1G的内存，实际使用量只有400MB，但标准版的计费方式是固定的，不会因为用得少吃回扣。

5.2 降本动作：缩容、降配、策略调整

结合压测数据，我做了三个降本动作。第一个是服务端从2C8G缩到2C4G，因为压测数据显示4G内存对当前业务场景绰绰有余，高峰期可用内存还剩2.2G。这一步每月节省约150元。

第二个是数据库降配，从4C16G降到2C8G。这里需要解释一下为什么数据库规格可以降——因为缓存优化之后，数据库的真实压力已经大幅下降。压测数据里QPS 4000时数据库最高才处理了约300个读请求，2C8G在应对这个量级时CPU使用率不过50%。降到2C8G之后，每月节省约800元。

第三个是缓存策略调整。Redis标准版实例没办法动态调节内存大小，但可以从”标准版“切到”集群版“或”性能型“，用更低的成本获得同等的内存容量。由于业务是单Key的场景，改用集群版收益不大，最终我的选择是保持标准版不变，但在代码层面把一些不常用的缓存Key的过期时间缩短，降低内存峰值，让已有的1G内存能更高效地利用。后来发现业务里有些缓存Key设置的TTL是24小时，但实际有效时间只有2小时，这些Key白白占着Redis内存。调整后Redis峰值内存从700MB降到了450MB，虽然账单没变，但为未来扩容省了空间。

5.3 成本优化的原则：不能为了省钱牺牲SLA

成本优化最大的坑就是只看账单不看系统健康度。缩容降配之前，必须要有足够的压测数据支撑，否则一旦流量突增，你就只能眼睁睁看着资源被耗尽。我给自己的原则有两个。

第一，容量冗余控制在30%到50%之间。也就是说，如果你的日常峰值QPS是1000，那建议选择的配置至少要能扛住1300到1500 QPS。这样既不会浪费太多成本，也能应对短期的流量波动。压测报告里QPS 1500时CPU使用率如果已经超过80%，这个配置就不建议再降了。

第二，该用的弹性能力不要省。云厂商提供的按量付费（postpaid）实例核心优势是可以随时扩缩容，适合那些流量波动大的业务。如果业务有明显的波峰波谷，比如每天晚高峰流量是白天的5倍，那固定包年的方式反而会浪费大量成本。我算过一笔账：把包年实例改成按量付费，并在晚高峰前自动扩容、之后自动缩容，某些场景下总成本能降低到原来的60%。但如果业务流量恒定，按量付费反而更贵，所以使用的前提是要用数据来判断流量曲线。

6. 常见问题与排查技巧实录

6.1 压测过程中频繁超时

症状是压测一开始，接口超时率直接飙到30%，但服务器CPU、内存都正常。这种现象最常出现在数据库连接池没有预热的情况下——服务端启动时连接池是空的，压测一上量，数据库连接池在瞬间涌入大量连接请求，需要频繁创建新连接，而MySQL的max_user_connections和max_connections限制可能把请求挡在外面。解决方案是提前开启连接池预热，或者在生产环境压测前，先用低并发预热十分钟。

超时问题还有一类是应用层线程池满了。Tomcat默认的accept-count是100，如果队列满了请求就会直接拒绝。遇到这种问题，先确认线程池和队列参数的设置是否符合压测模型，不要一看到超时就急着加线程数——线程太多了，反而会增加CPU上下文切换的开销。

6.2 Redis连接超时和命令阻塞

压测时Redis出现“READONLY You can't write against a read only replica”的错误，这是因为我误把读写分离架构下的只读副本接到了会产生写操作的流程上。这类错误一般有两种解法：把写操作挂到主实例上，或者在代码层面对读写操作做路由。如果你的架构没做读写分离，出现了连接超时，优先看Redis的慢日志，看有没有执行KEYS *、SMEMBERS这类O(N)命令，生产环境禁用此类命令是基本要求。

6.3 压测结果不稳定，同一脚本跑两次数据差异很大

这通常是“脏环境”导致的。第一次压测后，Tomcat的连接池、数据库连接池、Redis里缓存了部分数据，第二次跑压测时这些资源都还是热的，结果自然不同。我建议每次压测前重置系统的状态：重启应用服务使缓存清空、连接池重建，同时确定压测时间段内没有其他任务在跑。如果排除了环境问题，那就要怀疑是不是线程数设置太小，导致压测工具自身的线程被阻塞，产生的压力不够稳定。

6.4 数据库死锁和锁等待

压测时数据库出现死锁，错误信息显示在订单表和库存表之间发生了循环等待。这是典型的并发事务更新顺序不一致导致的死锁。解决方向是让所有事务按照相同的顺序更新资源——比如先更新订单表再更新库存表，同时缩短事务执行时间，事务内不做远程调用和慢查询，减少锁的持有时间。压测数据中关于锁等待时间的监控（Innodb_row_lock_waits）能帮你快速定位到具体是哪个表在频繁被锁。

6.5 压测工具本身成为瓶颈

Sob和JMeter这类工具单机压测能力有限，如果你压测的目标QPS超过了1万，建议采用分布式压测——多台压力机同时施压，每台机器分担一部分QPS。但从成本角度考虑，我更推荐先优化压测场景，只对核心接口做极限压测，对非核心接口做中等压力验证，避免为了压测而消耗太多的资源。

我用下面这个表格整理常见的压测和优化问题，方便后续排查：

我个人在实际操作中最大的体会是：压测不是一次性任务，而应该是一个持续迭代的过程。每次业务发布、配置变更、代码重构之后，至少跑一轮轻量级的回归压测，确保系统行为和上次压测时保持一致。价格敏感期做成本优化的时候，也要用压测数据做”安全边界“验证——压测报告里的那些曲线和指标，是你和运维、老板沟通时的最好证据。所以，与其等到线上告警再去救火，不如把压测作为开发流程里的一部分，越早做，系统越稳，成本也越省。