1. 课程导论：ACK机制在Kafka生产端的重要性、尾延迟概念与合规压测目标
1.1 ACK机制：Kafka生产端可靠性的基石
在Kafka分布式消息系统中，生产者（Producer）的ACK（Acknowledgment，确认应答）配置决定了消息从生产到被服务端确认的持久化策略。ACK参数直接决定了消息投递的可靠性与延迟之间的平衡点，是生产端性能调优与合规压测的核心控制变量。
| ACK配置值 | 行为描述 | 可靠性等级 | 典型延迟特征 |
|---|---|---|---|
acks=0 |
生产者发送后不等待任何确认，立即认为发送成功 | 最低（可能丢消息） | 极低（纯网络发送耗时） |
acks=1 |
等待Leader副本写入本地日志后确认，不等待Follower同步 | 中等（Leader宕机可能丢消息） | 较低（单次磁盘写入延迟） |
acks=all（或-1） |
等待Leader及所有ISR（In-Sync Replicas）内Follower全部写入后确认 | 最高（严格不丢消息） | 较高（等待多副本同步） |
关键认知： ACK配置不是简单的“选哪个更好”，而是业务对数据一致性与端到端延迟的权衡决策。在金融、交易、日志审计等合规场景中，
acks=all通常是强制要求。
1.2 尾延迟（Tail Latency）概念解析
尾延迟是指在一组请求中，排在分布尾部的那些请求所经历的延迟。在Kafka生产端压测中，我们通常关注P99（99百分位）、P99.9（99.9百分位）甚至P99.99的延迟指标。
- 平均延迟（Avg Latency）：容易被少数极快请求拉低，掩盖慢请求问题。
- P50（中位数延迟）：反映典型体验，但对极端慢速不敏感。
- P99 / P99.9 / P99.99：反映系统在压力下的长尾表现，是合规压测的核心观测指标。
常见误区： 很多团队只关注平均延迟，认为“平均5ms”就是性能达标。但在合规场景中，如果P99.9延迟高达500ms甚至超时，意味着每1000笔交易中就有1笔出现严重延迟，这在金融级SLA中是不可接受的。
1.3 合规压测的目标与范围
合规压测（Compliance Load Testing）不同于常规的性能压测，它要求系统在长时间、高压力、多异常场景下，仍然满足预先定义的SLA（服务等级协议）与合规指标。
压测核心目标
- 验证ACK配置的正确性：确认生产者在
acks=all配置下，消息不丢失、不重复（Exactly-Once语义）。 - 量化尾延迟边界：测量不同ACK配置下的P99/P99.9延迟，确认是否在业务SLA阈值内。
- 评估系统弹性：在Broker宕机、网络抖动、磁盘故障等注入场景下，尾延迟是否仍可控。
- 建立基准基线：为生产环境提供可复现的压测基线，用于后续版本回归对比。
压测范围界定
| 维度 | 包含内容 | 不包含内容（后续章节覆盖） |
|---|---|---|
| 生产者配置 | acks、batch.size、linger.ms、compression.type |
消费者端消费延迟、Rebalance影响 |
| 压测指标 | 吞吐量（TPS）、P50/P99/P99.9延迟、错误率 | 磁盘IOPS、网络带宽利用率（系统级指标） |
| 故障场景 | 单Broker宕机、Leader选举、网络分区 | 全集群宕机、跨机房容灾 |
| 数据规模 | 单条消息1KB~1MB，Topic分区数3~100 | 超大消息（>10MB）与无限堆积场景 |
课程前置提示： 本课程所有压测均基于Kafka 3.x版本，使用Java生产者客户端与开源压测工具（如kafka-producer-perf-test、自定义压测框架）。建议学员提前搭建至少3节点Kafka集群环境，并熟悉基本的Linux性能观测命令（如
iostat、sar、top）。