2. 压力测试场景特点：高并发下的流量特征、延迟敏感度、资源争抢对A/B测试的影响
压力测试场景与常规线上流量存在本质差异。高并发、高吞吐、资源争抢的极端条件会放大A/B测试中的噪声、偏差与统计陷阱。理解这些特征，是设计可靠分流方案的前提。
2.1 高并发下的流量特征
压力测试的流量模型通常呈现以下特征：
- 突发性（Burst）：流量在短时间内急剧上升，形成“尖峰”，而非平滑递增。
- 均匀性（Uniform）：测试工具常以固定速率或泊松过程生成请求，缺乏真实用户行为的自相似性。
- 无状态性（Stateless）：大量请求不携带有效的用户会话或Cookie，导致分流标识（User-ID、Device-ID）缺失或重复。
- 长尾效应（Long-tail）：部分慢请求或超时请求在队列中堆积，影响后续分流的实时性。
关键影响：突发流量可能导致分流决策模块（如一致性哈希环）在短时间内被大量重复计算，引发CPU毛刺；无状态请求则可能使分流层退化为随机分配，破坏实验分组的稳定性。
2.2 延迟敏感度与分流开销
在压力测试中，每一微秒的额外延迟都可能被放大。A/B分流本身会引入以下开销：
| 开销类型 | 来源 | 压力场景下的影响 |
|---|---|---|
| 计算开销 | 哈希计算、实验分组匹配 | 高并发下CPU争抢，分组延迟从μs级升至ms级 |
| 存储开销 | Redis/本地缓存读取实验配置 | 缓存穿透导致DB压力，分流降级为默认组 |
| 网络开销 | 远程配置中心拉取、日志上报 | 连接池耗尽，分流决策阻塞 |
| 序列化开销 | 请求上下文解析、分流标签注入 | 大对象GC频繁，STW暂停影响分流一致性 |
实践建议：在压力测试前，对分流模块进行预热（Warm-up），确保哈希环、实验配置缓存已加载；同时将分流日志上报改为异步批量写入，避免同步阻塞。
2.3 资源争抢对A/B测试的影响
资源争抢是压力测试中最隐蔽的干扰因素。当多个实验组共享同一资源池时，会出现以下问题：
- CPU 时间片争抢：实验组A的请求占用更多CPU，导致实验组B的请求排队，人为制造延迟差异。
- 内存/GC 干扰：某实验组触发频繁Full GC，影响同节点上所有分组的响应时间，造成“组间污染”。
- 连接池/线程池争抢：实验组A耗尽数据库连接池，实验组B的请求被拒绝或超时，破坏分流公平性。
- 缓存击穿：高并发下某实验组的缓存失效，导致大量请求穿透至DB，拖慢所有分组。
避坑提示：不要在压力测试中仅依赖“平均延迟”指标。资源争抢往往导致延迟分布偏斜（如P99飙升而P50正常），此时应使用分位数指标（P50/P90/P99）对比实验组，并监控系统级资源（CPU、内存、连接数）的组间均衡性。
2.4 压力测试下的分流架构要点
下图展示了压力测试场景下A/B分流的关键组件与数据流，重点突出高并发下的瓶颈点与优化方向。
2.5 压力测试场景下的分流策略调整
针对上述特征，压力测试场景下的A/B分流需要做出以下调整：
| 常规场景策略 | 压力测试场景调整 | 原因 |
|---|---|---|
| 基于用户ID的一致性哈希 | 降级为基于请求ID的随机哈希 + 本地缓存 | 无状态请求多，避免远程调用增加延迟 |
| 实时拉取实验配置 | 预热加载 + 本地快照 + 异步刷新 | 避免配置中心成为瓶颈 |
| 同步日志上报 | 异步批量上报 + 采样率动态调整 | 减少IO争抢，防止日志阻塞分流 |
| 共享线程池处理所有分组 | 按实验组隔离线程池或使用独立协程 | 防止某组资源耗尽影响其他组 |
| 依赖全局缓存 | 按实验组分片缓存 + 本地缓存兜底 | 避免缓存击穿波及所有分组 |
核心原则：压力测试下的A/B分流，首要目标是保证分流决策的低延迟与分组隔离性，其次才是分组均匀性。在极端情况下，允许少量流量落入默认组，也不应让分流模块成为系统瓶颈。