写在前面：我之前在一家电商公司，大促前老板问"系统能扛多少QPS"，整个技术团队面面相觑，谁也说不准。后来硬着头皮上线，结果流量一冲上来，数据库先挂了，Redis也扛不住了，整个系统雪崩。那次事故之后，我才真正理解全链路压测的重要性。不做压测就上线，跟盲人摸象没什么区别。今天把全链路压测从理论到实战完整讲一遍，这个话题在面试中也是高频考点。

---

一、为什么需要全链路压测？

1.1 大促前的灵魂拷问

双十一、618、年货节……每到这些节点，技术团队最怕的问题就是：

老板问：系统最大能扛多少QPS？
技术负责人：呃……大概……应该……可能……
老板问：那今年目标QPS是去年的3倍，能扛住吗？
技术负责人：……（内心崩溃）

说实话，不做压测就上线，等于闭着眼睛过马路。你可能运气好没出事，但一旦出事就是P0级故障。

1.2 生活类比：新车碰撞测试

新车出厂前，为什么要做碰撞测试？你不撞一下，怎么知道安不安全？

全链路压测就是系统的"碰撞测试"——在流量洪峰到来之前，先模拟真实流量打一遍，看看系统哪里会先扛不住。

• 不做压测：上线后发现问题，用户受损，紧急扩容，手忙脚乱
• 做了压测：提前发现瓶颈，提前优化，上线后稳如老狗

1.3 只压单个服务 vs 全链路压测

对比维度	单服务压测	全链路压测
压测范围	单个接口/服务	整条业务链路
发现问题	只能发现单点瓶颈	能发现链路级瓶颈
真实度	低（缺少上下游依赖）	高（模拟真实调用链）
实施难度	简单	复杂
数据一致性	不涉及	需要考虑数据隔离
典型工具	JMeter单接口	JMeter+流量录制+影子环境

我见过太多团队只做单服务压测，结果每个服务单独看都没问题，串起来一压就挂。为什么？因为瓶颈往往不在单个服务，而在服务间的依赖——数据库连接池打满、Redis热点Key、MQ消息堆积……这些问题只有全链路压测才能暴露。

---

二、压测核心指标

2.1 核心指标一览

指标	全称	含义	计算方式
QPS	Queries Per Second	每秒处理请求数	总请求数 / 压测时间（秒）
TPS	Transactions Per Second	每秒处理事务数	总事务数 / 压测时间（秒）
RT	Response Time	响应时间	从请求发出到收到响应的时间
P50	50th Percentile	50%的请求响应时间低于此值	按响应时间排序，取第50%位置的值
P90	90th Percentile	90%的请求响应时间低于此值	按响应时间排序，取第90%位置的值
P99	99th Percentile	99%的请求响应时间低于此值	按响应时间排序，取第99%位置的值
P999	99.9th Percentile	99.9%的请求响应时间低于此值	按响应时间排序，取第99.9%位置的值
错误率	Error Rate	请求失败的比例	失败请求数 / 总请求数 × 100%
并发用户数	Concurrent Users	同时发起请求的用户数	正在处理的请求数（非累计）

2.2 为什么看P99而不是平均值？

举个极端的例子：100个请求中，99个耗时10ms，1个耗时10000ms。

• 平均值：(99×10 + 1×10000) / 100 = 109.9ms（看起来还行）
• P99：10000ms（真相大白）

平均值会被极端值拉偏，而P99能真实反映最差情况下的用户体验。线上监控我们一般看P99，压测报告也是P99最有参考价值。

2.3 资源利用率指标

资源	关注指标	告警阈值建议
CPU	使用率	> 70%需要关注，> 85%需要优化
内存	使用率 / GC频率	老年代使用率 > 80%需要关注
网络	带宽利用率 / 连接数	带宽 > 70%需要关注
磁盘IO	IOPS / IO等待时间	IO等待 > 20%需要关注
数据库连接池	活跃连接数 / 等待队列	活跃连接 > 80%需要关注
线程池	活跃线程数 / 队列积压	队列积压持续增长需要关注

---

三、压测环境搭建

3.1 三种压测环境对比

对比维度	生产环境压测	影子环境压测	仿真环境压测
真实性	最高	较高	中等
风险	最高（可能影响线上用户）	较低	无
成本	最低（复用生产环境）	较高（需要独立资源）	中等
数据隔离	需要严格隔离	天然隔离	天然隔离
适用场景	大促前最终验证	日常压测	功能验证阶段
典型代表	淘宝全链路压测	公司内部影子环境	Docker/K8s仿真环境

3.2 影子环境搭建方案

影子环境是全链路压测的主流方案，核心思想是：搭建一套和生产环境结构完全一致的环境，但数据完全隔离。

┌──────────────────────────────────────────────┐
│              流量入口（Nginx/网关）              │
│  通过特殊Header（如 X-Pressure-Test: true）    │
│  区分压测流量和正常流量                          │
└──────────────┬───────────────────────────────┘
               │
    ┌──────────┼──────────┐
    │          │          │
    ▼          ▼          ▼
┌───────┐ ┌───────┐ ┌───────┐
│生产库  │ │影子库  │ │影子库  │
│MySQL  │ │MySQL  │ │Redis  │
│(主库)  │ │(从库)  │ │(独立)  │
└───────┘ └───────┘ └───────┘
    │          │          │
    ▼          ▼          ▼
┌───────┐ ┌───────┐ ┌───────┐
│生产MQ  │ │影子MQ  │ │影子MQ  │
│Kafka  │ │Kafka  │ │RocketMQ│
│(正式)  │ │(独立)  │ │(独立)  │
└───────┘ └───────┘ └───────┘

影子数据库：使用生产库的从库，或者独立搭建一个结构一致的数据库。压测数据写入影子库，不影响生产数据。

影子缓存：独立的Redis实例，压测流量读写影子Redis，避免污染生产缓存。

影子MQ：独立的Topic或独立的MQ实例，压测消息发到影子Topic，避免消费端处理压测消息。

3.3 流量标记与路由

通过特殊Header区分压测流量，在网关层做路由：

/**
 * 压测流量识别与路由过滤器
 * 在网关层识别压测流量，路由到影子环境
 */
@Component
public class PressureTestFilter implements GlobalFilter, Ordered {

    private static final String PRESSURE_TEST_HEADER = "X-Pressure-Test";
    private static final String PRESSURE_TEST_FLAG = "true";

    @Override
    public Mono<Void> filter(ServerWebExchange exchange,
                              GatewayFilterChain chain) {
        // 检查请求Header中是否携带压测标记
        String pressureTestFlag = exchange.getRequest()
            .getHeaders().getFirst(PRESSURE_TEST_HEADER);

        if (PRESSURE_TEST_FLAG.equalsIgnoreCase(pressureTestFlag)) {
            // 压测流量：设置上下文标记，后续服务据此路由到影子环境
            ServerHttpRequest request = exchange.getRequest()
                .mutate()
                .header("X-Shadow-Env", "true")
                .build();

            // 将压测标记放入ThreadLocal，方便后续使用
            PressureTestContext.mark(true);

            return chain.filter(exchange.mutate().request(request).build());
        }

        // 正常流量：直接放行
        return chain.filter(exchange);
    }

    @Override
    public int getOrder() {
        return -10; // 优先级最高，在所有过滤器之前执行
    }
}

/**
 * 压测上下文工具类
 * 基于ThreadLocal传递压测标记
 */
public class PressureTestContext {

    private static final ThreadLocal<Boolean> CONTEXT =
        ThreadLocal.withInitial(() -> false);

    public static void mark(boolean isPressureTest) {
        CONTEXT.set(isPressureTest);
    }

    public static boolean isPressureTest() {
        return CONTEXT.get();
    }

    public static void clear() {
        CONTEXT.remove();
    }
}

---

四、流量回放与构造

4.1 线上流量录制与回放

JVM-Sandbox-Repeater是阿里巴巴开源的流量录制回放工具，核心思路是：线上真实流量录制下来，在压测环境中回放。

流量录制回放流程：

1. 生产环境：JVM-Sandbox-Repeater Agent拦截请求
   ↓
2. 录制：将请求参数、调用链路、返回结果记录下来
   ↓
3. 存储：保存到文件或数据库
   ↓
4. 压测环境：读取录制数据
   ↓
5. 回放：按照录制时的顺序和并发度，向压测环境发送请求

流量回放的好处是压测流量最接近真实场景。但要注意，回放时需要处理时间敏感的数据（如验证码、时间戳），避免回放失败。

4.2 压测工具对比

工具	类型	优势	劣势	适用场景
JMeter	Java GUI	功能全面、插件丰富、社区大	GUI模式性能差、资源消耗大	复杂场景压测
Gatling	Scala DSL	脚本化、性能好、报告漂亮	学习曲线较陡	持续集成压测
wrk	C + Lua	极致性能、轻量级	功能简单、不支持复杂场景	单接口极限压测
Locust	Python	代码灵活、分布式支持好	Python性能瓶颈	需要编程灵活性的场景

4.3 流量模型设计

压测不能随便造流量，需要模拟真实的业务场景：

真实流量模型设计：

1. 读写比例：
   - 电商场景：读80% / 写20%
   - 社交场景：读70% / 写30%
   - 金融场景：读50% / 写50%

2. 热点数据分布（80/20法则）：
   - 20%的商品承载80%的流量
   - 需要构造热点SKU数据

3. 业务场景比例：
   - 浏览商品：60%
   - 加入购物车：15%
   - 下单：10%
   - 支付：8%
   - 查询订单：5%
   - 退款：2%

JMeter中通过线程组比例来模拟：

<!-- JMeter线程组配置示例 -->
<!-- 浏览商品线程组：占总流量的60% -->
<ThreadGroup guiclass="ThreadGroupGui" testclass="ThreadGroup">
    <stringProp name="ThreadGroup.num_threads">600</stringProp>
    <stringProp name="ThreadGroup.ramp_time">60</stringProp>
</ThreadGroup>

<!-- 下单线程组：占总流量的10% -->
<ThreadGroup guiclass="ThreadGroupGui" testclass="ThreadGroup">
    <stringProp name="ThreadGroup.num_threads">100</stringProp>
    <stringProp name="ThreadGroup.ramp_time">60</stringProp>
</ThreadGroup>

---

五、全链路压测实施流程

5.1 压测计划制定

压测不是上来就加压，需要先做好计划：

/**
 * 压测计划模板
 */
public class PressureTestPlan {

    // 1. 压测目标
    private String targetQps = "50000";          // 目标QPS
    private String targetResponseTime = "200ms";  // 目标P99响应时间
    private String targetErrorRate = "0.1%";      // 目标错误率

    // 2. 压测场景
    private List<String> scenarios = Arrays.asList(
        "正常购物流程（浏览→加购→下单→支付）",
        "秒杀场景（瞬时高并发下单）",
        "查询场景（订单查询、商品搜索）"
    );

    // 3. 压测策略
    private String strategy = "阶梯加压";

    // 4. 压测持续时间
    private String duration = "2小时";

    // 5. 参与方
    private List<String> participants = Arrays.asList(
        "网关组", "订单组", "库存组", "支付组",
        "DBA组", "运维组", "测试组"
    );
}

5.2 压测执行：阶梯加压

压测执行采用"阶梯加压"策略：

QPS
    │
    │                          ┌────────────── 峰值保持
    │                    ┌─────┘
    │              ┌─────┘
    │        ┌─────┘
    │  ┌─────┘
    │──┘
    └────────────────────────────────────────── 时间
    T0  T1  T2  T3  T4  T5  T6  T7  T8

    T0-T1: 基准测试（目标QPS的10%）
    T1-T2: 加压到30%
    T2-T3: 加压到50%
    T3-T4: 加压到70%
    T4-T5: 加压到100%（目标QPS）
    T5-T6: 峰值保持（持续30分钟）
    T6-T7: 降压到50%
    T7-T8: 降压到0%（恢复）

5.3 数据采集：Prometheus + Grafana

压测期间需要实时监控系统各项指标：

# Prometheus监控指标采集配置
# 采集维度：
# 1. 应用层：QPS、响应时间、错误率、线程池状态
# 2. 中间件层：Redis命中率、MQ消息堆积、连接池使用率
# 3. 系统层：CPU、内存、网络、磁盘IO
# 4. 数据库层：慢SQL、连接数、锁等待、TPS

# Grafana大盘配置：
# - 实时QPS曲线（按服务维度）
# - 响应时间百分位图（P50/P90/P99/P999）
# - 错误率趋势
# - JVM GC频率和耗时
# - 数据库连接池使用率
# - Redis内存使用率和命中率

5.4 瓶颈分析

压测数据收集后，需要逐层分析瓶颈：

层级	常见瓶颈	分析方法
应用层	线程池满、GC频繁、锁竞争	JProfiler / Arthas / GC日志
缓存层	热点Key、缓存击穿、网络延迟	Redis监控 / CAT链路追踪
数据库层	慢SQL、连接池满、锁等待	慢SQL日志 / SHOW PROCESSLIST
MQ层	消息堆积、消费延迟	MQ监控面板
网络层	带宽打满、连接数耗尽	iftop / netstat
OS层	CPU 100%、内存不足、IO等待	top / iostat / vmstat

5.5 容量评估报告

压测完成后，输出容量评估报告：

/**
 * 容量评估报告模板
 */
public class CapacityReport {

    // 系统基本信息
    private String systemName = "电商交易系统";
    private String testDate = "2024-01-15";
    private String testEnv = "影子环境（与生产1:1配置）";

    // 压测结果
    private int maxQps = 52000;              // 系统最大QPS
    private String p99ResponseTime = "186ms"; // P99响应时间
    private String errorRate = "0.08%";      // 错误率

    // 瓶颈点分析
    private List<String> bottlenecks = Arrays.asList(
        "数据库连接池在QPS>40000时出现等待",
        "Redis热点Key（商品详情）在QPS>45000时出现延迟",
        "订单服务GC频率在QPS>48000时明显增加"
    );

    // 优化建议
    private List<String> suggestions = Arrays.asList(
        "数据库连接池从100扩到200",
        "商品详情增加本地缓存",
        "订单服务JVM堆内存从4G扩到8G",
        "增加一台订单服务实例（水平扩容）"
    );

    // 安全容量评估
    private int safetyQps = 52000 * 80 / 100; // 安全系数0.8 = 41600
}

---

六、压测中的技术难点

6.1 数据隔离：压测数据不污染生产数据

这是全链路压测最核心的难题。压测流量会写入数据库，如果不做隔离，生产数据就废了。

解决方案：

/**
 * 基于MyBatis拦截器的数据隔离方案
 * 压测流量自动路由到影子表
 */
@Intercepts({
    @Signature(type = Executor.class, method = "update",
        args = {MappedStatement.class, Object.class})
})
public class ShadowTableInterceptor implements Interceptor {

    // 影子表后缀
    private static final String SHADOW_SUFFIX = "_shadow";

    @Override
    public Object intercept(Invocation invocation) throws Throwable {
        // 判断是否为压测流量
        if (PressureTestContext.isPressureTest()) {
            MappedStatement ms = (MappedStatement) invocation.getArgs()[0];
            // 将SQL中的表名替换为影子表名
            // 例如：t_order → t_order_shadow
            String shadowSql = convertToShadowSql(ms.getSqlSource());
            // 执行影子表SQL
            return executeShadowSql(shadowSql, invocation.getArgs()[1]);
        }
        // 正常流量，执行原始SQL
        return invocation.proceed();
    }

    private String convertToShadowSql(SqlSource sqlSource) {
        // 解析原始SQL，将表名添加影子后缀
        // 实际项目中可以使用Druid的SQL解析器来做
        String originalSql = parseSql(sqlSource);
        return originalSql.replaceAll(
            "t_order(?!_shadow)", "t_order" + SHADOW_SUFFIX);
    }
}

6.2 缓存击穿：压测流量打到数据库

压测流量如果绕过缓存直接打到数据库，数据库会瞬间被压垮。

/**
 * 防缓存击穿的布隆过滤器 + 空值缓存方案
 */
@Service
public class ProductCacheService {

    @Autowired
    private RedisTemplate<String, Object> redisTemplate;
    @Autowired
    private BloomFilter<Long> bloomFilter;
    @Autowired
    private ProductMapper productMapper;

    /**
     * 获取商品信息（防缓存击穿）
     * 压测场景下尤其重要
     */
    public Product getProduct(Long productId) {
        String key = "product:" + productId;

        // 1. 先查布隆过滤器，不存在直接返回
        if (!bloomFilter.mightContain(productId)) {
            return null;
        }

        // 2. 查Redis缓存
        Product product = (Product) redisTemplate
            .opsForValue().get(key);
        if (product != null) {
            return product;
        }

        // 3. 缓存未命中，加锁查数据库（防止大量并发打到DB）
        synchronized (this) {
            // 双重检查
            product = (Product) redisTemplate
                .opsForValue().get(key);
            if (product != null) {
                return product;
            }

            // 查数据库
            product = productMapper.selectById(productId);

            if (product != null) {
                // 写入缓存，设置随机过期时间防止雪崩
                int expire = 3600 + ThreadLocalRandom.current()
                    .nextInt(600);
                redisTemplate.opsForValue().set(
                    key, product, expire, TimeUnit.SECONDS);
            } else {
                // 空值缓存，防止缓存穿透
                redisTemplate.opsForValue().set(
                    key, new Product(), 300, TimeUnit.SECONDS);
            }
        }

        return product;
    }
}

6.3 数据库连接池打满

压测时QPS很高，如果连接池不够大，请求会排队等待：

# HikariCP连接池压测配置
spring:
  datasource:
    hikari:
      maximum-pool-size: 200        # 最大连接数（压测时需要调大）
      minimum-idle: 50              # 最小空闲连接
      connection-timeout: 3000     # 连接超时时间（ms）
      idle-timeout: 600000         # 空闲连接超时时间（ms）
      max-lifetime: 1800000        # 连接最大存活时间（ms）
      leak-detection-threshold: 5000  # 连接泄漏检测阈值

踩坑提醒：连接池不是越大越好。 连接数过多会导致数据库的上下文切换开销增加，反而降低性能。一般建议连接池大小 = (CPU核心数 * 2) + 有效磁盘数。MySQL一般200-500个连接就足够了。

6.4 限流熔断策略验证

压测是验证限流熔断策略是否有效的最佳时机：

/**
 * Sentinel限流配置（压测验证）
 */
@Configuration
public class SentinelConfig {

    @PostConstruct
    public void initRules() {
        // 订单创建接口限流：QPS不超过500
        List<FlowRule> rules = new ArrayList<>();
        FlowRule orderRule = new FlowRule("createOrder");
        orderRule.setCount(500);
        orderRule.setGrade(RuleConstant.FLOW_GRADE_QPS);
        orderRule.setLimitApp("default");
        rules.add(orderRule);

        // 库存扣减接口限流：QPS不超过1000
        FlowRule stockRule = new FlowRule("deductStock");
        stockRule.setCount(1000);
        stockRule.setGrade(RuleConstant.FLOW_GRADE_QPS);
        rules.add(stockRule);

        FlowRuleManager.loadRules(rules);

        // 降级规则：错误率超过30%时熔断10秒
        List<DegradeRule> degradeRules = new ArrayList<>();
        DegradeRule degradeRule = new DegradeRule("createOrder");
        degradeRule.setGrade(CircuitBreakerStrategy.ERROR_RATIO);
        degradeRule.setCount(0.3);  // 错误率阈值30%
        degradeRule.setTimeWindow(10); // 熔断时长10秒
        degradeRules.add(degradeRule);

        DegradeRuleManager.loadRules(degradeRules);
    }
}

6.5 分布式ID生成压力

压测时大量并发请求需要生成分布式ID，ID生成服务本身也可能成为瓶颈：

/**
 * Leaf号段模式双Buffer优化（压测场景）
 * 预加载两个号段Buffer，交替使用
 */
@Service
public class SegmentIdService {

    // 双Buffer
    private AtomicLong currentId = new AtomicLong(0);
    private AtomicLong maxId = new AtomicLong(0);
    private volatile boolean isLoading = false;

    /**
     * 获取下一个ID
     * 如果当前号段用完，异步加载下一个号段
     */
    public Long nextId() {
        long id = currentId.incrementAndGet();
        if (id > maxId.get()) {
            synchronized (this) {
                // 双重检查
                if (currentId.get() > maxId.get()) {
                    // 从数据库加载新号段（步长1000）
                    Segment segment = loadSegment();
                    currentId.set(segment.getMinId());
                    maxId.set(segment.getMaxId());
                    id = currentId.incrementAndGet();
                }
            }
        }
        return id;
    }

    /**
     * 预加载下一个号段（异步）
     */
    @Scheduled(fixedRate = 5000)
    public void prefetchSegment() {
        // 当当前号段使用超过80%时，提前加载下一个号段
        long used = currentId.get();
        long total = maxId.get();
        if (used > total * 0.8 && !isLoading) {
            isLoading = true;
            CompletableFuture.runAsync(() -> {
                loadSegment();
                isLoading = false;
            });
        }
    }
}

---

七、容量评估模型

7.1 理论容量计算

容量评估的核心公式：

理论容量 = 资源总量 / 单请求资源消耗

举例：
- 服务器：8台，每台4核8G
- 单请求CPU消耗：2ms
- 单请求内存消耗：512KB

理论QPS = 8台 × 4核 × (1000ms / 2ms) = 16000 QPS
理论内存容量 = 8台 × 8G / 512KB = 131072 并发连接

7.2 安全容量评估

理论容量是极限值，线上不能按极限来，需要留安全余量：

安全容量 = 理论容量 × 安全系数

安全系数通常取 0.7 ~ 0.8：
- 0.7：保守型（金融、支付场景）
- 0.8：一般型（电商、社交场景）

举例：
理论QPS = 16000
安全系数 = 0.8
安全QPS = 16000 × 0.8 = 12800

建议线上QPS不超过12800，超过这个值就需要扩容

7.3 容量评估报告模板

评估项	数值	说明
系统最大QPS	52000	压测实测值
安全容量QPS	41600	理论容量 × 0.8
P99响应时间	186ms	在安全容量下
P999响应时间	520ms	在安全容量下
错误率	0.08%	在安全容量下
主要瓶颈	数据库连接池	QPS>40000时出现等待
扩容建议	增加2台订单服务实例	预计可提升至65000 QPS

---

八、踩坑指南

8.1 压测流量打到下游第三方系统

踩坑提醒：压测流量打到第三方支付/短信接口，后果很严重！ 我见过一个团队压测时忘了做流量隔离，结果压测流量打到了支付宝的沙箱环境，虽然没打到生产，但还是被支付宝那边投诉了。

解决方案：

• 压测环境下，所有外部调用替换为Mock
• 在HTTP客户端层面做拦截，压测流量直接返回Mock数据
• 维护一份外部接口的Mock配置表

/**
 * 压测环境外部调用Mock拦截器
 */
@Component
public class MockInterceptor implements ClientHttpRequestInterceptor {

    @Override
    public ClientHttpResponse intercept(
            HttpRequest request, byte[] body,
            ClientHttpRequestExecution execution) {

        // 压测流量直接返回Mock响应
        if (PressureTestContext.isPressureTest()) {
            return new MockClientHttpResponse(
                "{\"code\":\"SUCCESS\",\"msg\":\"mock\"}",
                HttpStatus.OK);
        }

        // 正常流量走真实调用
        return execution.execute(request, body);
    }
}

8.2 数据库被压测数据撑爆

踩坑提醒：压测数据如果不做清理，磁盘会被撑爆。 压测几个小时就可能产生几千万条数据，如果不及时清理，数据库磁盘空间很快就会用完。

解决方案：

• 压测结束后自动清理影子表数据
• 设置影子表的自动过期策略
• 监控磁盘空间，设置告警阈值

8.3 压测工具本身的性能瓶颈

踩坑提醒：JMeter在并发很高时，它自己先扛不住了。 JMeter的GUI模式非常消耗资源，1000并发以上建议用非GUI模式运行。

解决方案：

• JMeter使用非GUI模式：jmeter -n -t test.jmx -l result.jtl
• 高并发场景用分布式JMeter（Master-Slave模式）
• 极致性能场景用wrk或Gatling

8.4 压测结果的可重复性

踩坑提醒：同样的压测脚本，两次跑出来的结果可能差很多。 这是因为系统状态（JIT编译、缓存预热、GC）会影响性能。

解决方案：

• 每次压测前先"预热"系统（跑几轮低QPS让JIT编译完成）
• 固定压测环境配置，避免变量干扰
• 多次压测取平均值，排除异常值

---

九、问题与解答

Q1：全链路压测和单接口压测有什么本质区别？

A： 本质区别在于"真实性"。单接口压测只关注一个接口的性能，就像体检只查了一项指标。全链路压测模拟的是真实的业务场景，多个接口串联调用，能暴露出服务间依赖的问题——比如数据库连接池被多个服务争抢、Redis热点Key被多个服务同时访问、MQ消息在某个服务消费不过来。这些问题单接口压测根本发现不了。

Q2：压测时怎么保证不污染生产数据？

A： 核心思路是"流量标记 + 数据隔离"。在网关层给压测流量打上特殊标记（如Header），然后在整个调用链中透传这个标记。数据层通过影子表（表名加后缀）、影子库（独立从库）、影子缓存（独立Redis实例）、影子MQ（独立Topic）来实现数据隔离。代码层面通过MyBatis拦截器自动将SQL路由到影子表，对业务代码零侵入。

Q3：压测报告里的P99响应时间，多少算合格？

A： 这取决于业务场景。一般来说：用户直接操作（如下单、支付）P99 < 500ms算合格，P99 < 200ms算优秀；后台操作（如报表查询）P99 < 3s算合格；实时性要求高的场景（如秒杀）P99 < 100ms。但更重要的是和压测前的基线对比，看优化前后的变化趋势，而不是追求一个绝对值。

---

十、面试高频考点汇总

考点1：什么是全链路压测？和普通压测有什么区别？

答： 全链路压测是在一套和生产环境结构一致的影子环境中，模拟真实的业务流量模型，对整条业务链路进行压力测试。和普通压测的区别在于：普通压测只关注单个接口或服务，而全链路压测关注整条调用链的性能表现。全链路压测能暴露服务间依赖的瓶颈问题，如数据库连接池争抢、缓存一致性、消息堆积等，这些问题在单接口压测中无法发现。

考点2：压测环境有哪几种？各有什么优缺点？

答： 主要有三种：生产环境压测（直接在生产环境压测，真实性最高但风险最大，需要严格的数据隔离和流量标记）；影子环境压测（搭建一套独立环境，结构一致但数据隔离，风险较低但成本较高）；仿真环境压测（Docker/K8s搭建的轻量环境，成本最低但真实性也最低）。大厂一般采用影子环境压测为主，生产环境压测为辅的方案。

考点3：P50/P90/P99/P999分别代表什么？为什么看P99而不是平均值？

答： P50表示50%的请求响应时间低于此值，P90表示90%的请求响应时间低于此值，以此类推。看P99而不是平均值是因为平均值会被极端值拉偏——比如100个请求中99个10ms、1个10000ms，平均值是109.9ms看起来还行，但P99是10000ms暴露了真实问题。P99更能反映最差情况下的用户体验。

考点4：全链路压测中如何做数据隔离？

答： 数据隔离是全链路压测的核心难题。方案是在网关层给压测流量打上特殊标记（HTTP Header），然后在调用链中透传。数据层通过影子表（MyBatis拦截器自动路由）、影子库（独立数据库实例）、影子缓存（独立Redis）、影子MQ（独立Topic）实现隔离。外部调用（支付、短信等）通过Mock拦截器返回模拟数据，避免压测流量打到第三方系统。

考点5：容量评估的安全系数为什么是0.7-0.8？

答： 安全系数0.7-0.8意味着线上QPS只用到理论容量的70%-80%，留20%-30%的余量。原因有三：一是线上流量有突发波动的可能，需要余量来应对；二是系统运行过程中会有GC、线程调度等额外开销，理论容量是理想值；三是留有余量才能从容处理异常情况（如某台机器宕机、网络抖动）。金融场景取0.7更保守，电商场景取0.8即可。

---

十一、模拟面试官提问

场景题1：老板说今年双十一QPS目标是去年的5倍，你作为技术负责人怎么规划？

参考答案：

分四步走。第一步，容量评估：基于去年的压测数据和今年的增长目标，计算需要的安全容量。第二步，全链路压测：在影子环境中进行阶梯加压测试，验证系统在目标QPS下的表现。第三步，瓶颈优化：根据压测结果，逐层分析瓶颈（应用层、缓存层、数据库层、网络层），针对性优化。第四步，预案准备：制定限流降级预案、扩容预案、回滚预案，确保大促当天有Plan B。整个过程中，压测至少做3轮以上，每轮优化后重新验证。

场景题2：压测发现数据库连接池在QPS超过40000时打满，你怎么排查和优化？

参考答案：

首先确认连接池大小是否合理——当前连接池大小是多少？数据库最大连接数是多少？如果连接池本身就小，先扩连接池。如果连接池已经很大了还是打满，说明有连接泄漏或者慢SQL占用连接。排查方向：一是看慢SQL日志，有没有执行时间超过1秒的SQL；二是看有没有长事务占用连接不释放；三是看连接泄漏检测有没有告警。优化方案：慢SQL加索引或改写SQL，长事务拆分，连接泄漏修复。如果以上都没问题，考虑水平拆分数据库或引入读写分离。

场景题3：压测时发现Redis的某个Key在QPS超过30000时延迟飙升，怎么处理？

参考答案：

这是典型的热点Key问题。排查步骤：先确认是哪个Key（通过Redis的MONITOR命令或慢日志），然后分析这个Key的数据类型和大小。如果是大Key（Value超过10KB），考虑拆分。解决方案有几种：一是本地缓存，在应用层用Caffeine做一级缓存，减轻Redis压力；二是Key拆分，把一个热点Key拆成多个Key分散到不同Redis节点；三是请求合并，相同Key的请求在短时间内只查一次Redis。如果Redis集群本身是瓶颈，考虑扩容或升级配置。

场景题4：如何设计一个自动化压测平台，支持日常回归压测？

参考答案：

自动化压测平台需要几个核心模块：一是流量构造模块，支持从线上录制流量或配置流量模型；二是压测执行模块，集成JMeter/Gatling/wrk，支持分布式执行；三是监控采集模块，集成Prometheus采集系统指标，实时展示Grafana大盘；四是报告生成模块，自动生成压测报告（QPS、响应时间、错误率、瓶颈分析）；五是告警模块，压测过程中指标异常自动告警。整个平台通过CI/CD集成，每次发布前自动触发压测，压测通过才能上线。

场景题5：压测结果和线上真实表现差距很大，可能是什么原因？

参考答案：

差距大的常见原因有五个：一是流量模型不真实，压测流量和线上真实流量的读写比例、热点分布不一致；二是数据量级不同，压测环境的数据量可能远小于生产环境，导致缓存命中率差异大；三是JIT和缓存预热，线上JVM经过长时间运行JIT编译已经完成，压测环境刚开始跑性能偏低；四是网络环境差异，压测机和压测环境之间的网络延迟和线上用户到服务器的延迟不同；五是压测工具本身的瓶颈，JMeter在高并发下自身消耗大量资源，导致压出的QPS不准确。解决思路是尽量让压测环境接近生产环境，压测前充分预热，多次压测取稳定值。

---

互动话题

你在项目中做过全链路压测吗？遇到过什么有趣（或痛苦）的问题？欢迎在评论区交流：

• 你们公司的压测环境是怎么搭建的？用的影子环境还是其他方案？
• 压测中遇到过最奇葩的瓶颈是什么？
• 你们压测工具用的什么？JMeter还是其他？

---

参考资料

• JVM-Sandbox-Repeater - 阿里巴巴开源的流量录制回放工具