1.1 压力测试概述
压力测试（Stress Testing）是实时计算系统上线前必须完成的关键验证环节。它通过模拟远超正常业务量的负载，观察系统在极限状态下的行为表现，从而提前暴露资源瓶颈、稳定性缺陷和架构短板。在 Flink 实时计算场景中，压力测试直接决定了作业能否在生产环境承受 7×24 小时的高吞吐、低延迟运行。
1.1.1 压力测试定义
压力测试是一种破坏性测试手段：持续向被测系统施加递增负载，直至系统达到性能拐点或崩溃，并记录该过程中的各项指标变化。其核心关注点不是“系统能处理多少”，而是“系统在超出能力后如何失效”。
关键特征： 负载递增 → 突破阈值 → 观察失效模式 → 定位瓶颈
1.1.2 压力测试目的
在 Flink 实时计算项目中，压力测试主要达成以下五个目标：
- 确定系统极限容量 —— 找到作业在给定资源下的最大稳定吞吐量（TPS/QPS）
- 暴露资源瓶颈 —— 识别 CPU、内存、网络、磁盘 I/O 中率先达到饱和的组件
- 验证弹性伸缩能力 —— 测试 Flink 作业在负载突增时能否自动或手动扩缩容
- 检查数据准确性 —— 高压力下是否存在数据丢失、乱序、重复或状态不一致
- 评估恢复能力 —— 系统过载崩溃后，重启恢复的速度和状态一致性保障
1.1.3 压力测试在实时计算中的重要性
实时计算与离线批处理有本质区别：数据是持续流入的，延迟要求通常是秒级甚至毫秒级。一旦压力测试不充分，生产环境可能出现以下灾难性后果：
| 风险场景 | 后果 | 压力测试可提前发现 |
|---|---|---|
| 双十一/大促流量洪峰 | 作业背压飙升，延迟从 100ms 暴涨到 30s | 背压阈值、Checkpoint 超时 |
| Kafka 分区重平衡 | 消费暂停，数据堆积，状态快照失败 | Rebalance 期间吞吐下降幅度 |
| 状态后端 RocksDB 写放大 | 磁盘 I/O 打满，GC 频繁，作业崩溃 | RocksDB 写入吞吐与 compaction 行为 |
| 网络带宽不足 | Shuffle 阶段数据阻塞，Task 超时失败 | 网络吞吐上限与序列化开销 |
经验教训： 某头部电商 Flink 作业上线前未做压力测试，大促当天背压从 0 飙升至 100%，Checkpoint 连续超时 12 次，最终导致 15 分钟数据断流。事后复盘发现，仅需在测试环境模拟 2 倍峰值流量即可提前暴露该问题。
1.1.4 压力测试与性能测试的区别
很多团队容易混淆这两个概念，但它们在目标、方法和关注指标上有本质差异：
| 对比维度 | 性能测试 | 压力测试 |
|---|---|---|
| 核心目标 | 测量系统在正常负载下的响应时间、吞吐量 | 发现系统在极限负载下的失效点和恢复能力 |
| 负载特征 | 稳定负载，通常为预估峰值的 60%~80% | 递增负载，从 80% 一直加到 200% 以上 |
| 关注指标 | P99 延迟、平均吞吐、资源利用率 | 背压百分比、Checkpoint 失败率、OOM 频率 |
| 测试时长 | 短周期（10~30 分钟） | 长周期（1~24 小时），包含持续高压阶段 |
| 期望结果 | 所有指标在可接受范围内 | 明确系统的安全边界和失效模式 |
| Flink 典型场景 | 调优并行度、序列化方式、状态后端 | 验证反压机制、Checkpoint 稳定性、故障恢复 |
实践建议： 在 Flink 作业开发流程中，先做性能测试确定基线，再做压力测试探索边界。两者互补，缺一不可。
1.1.5 压力测试核心流程
下图展示了 Flink 实时计算压力测试的完整执行流程，从环境准备到结果分析共六个阶段：
1.1.6 压力测试关键指标
在 Flink 压力测试过程中，以下指标必须持续采集并记录：
- 背压百分比（Backpressure %） —— 每个 Task 的反压状态，超过 80% 即为危险信号
- Checkpoint 时长与成功率 —— 压力增大时 Checkpoint 是否超时或失败
- 端到端延迟（End-to-End Latency） —— 从数据进入 Source 到 Sink 输出的总耗时
- 吞吐量（Records/s 或 Bytes/s） —— 系统实际处理速率
- GC 暂停时间与频率 —— Full GC 次数和单次暂停时长
- RocksDB 读写延迟 —— 状态后端的 L0->L1 compaction 频率
- 网络吞吐与序列化开销 —— Shuffle 阶段的网络传输速率
推荐工具组合： Flink Web UI（实时背压 + Checkpoint）+ Prometheus + Grafana（历史趋势）+ 自定义 Metrics Reporter（业务级指标）。