HDUO Lab

标签： SSL

  • Kafka 集群 P99 飙升至 3000ms：强制开启 SSL 击穿零拷贝引发的 ISR 频繁收缩与雪崩

    近期处理了一起非常典型的 Kafka 核心集群生产事故：业务反馈生产耗时 P99 从平时的 10ms 突增至 3000ms 以上，消费端出现大面积堆积。排查发现，集群的 Under Replicated Partitions (URP) 指标狂飙，Controller 频繁进行 Leader 选举。

    最终结论直接抛出：这是一起因“安全合规”要求，盲目在 Broker 间以及所有 Client 强制开启 SSL/TLS 加密，导致 Linux底层的 sendfile（零拷贝）机制彻底失效，叠加某下游业务重放海量历史数据引发 PageCache 穿透，最终打满 CPU 且耗尽内存带宽的惨案。Follower 无法在 replica.lag.time.max.ms 内完成数据同步，导致 ISR 疯狂收缩与扩散，进而引发集群级雪崩。

    安全合规当然要做，但在没有经过基准压测的情况下，用一纸行政命令违背底层的 I/O 物理规律，除了给系统带来毁灭性打击外毫无意义。今天把底层的调用链剖开，看看零拷贝是怎么被干碎的。

    现场还原：被击穿的 I/O 与失控的 ISR

    接到告警时，监控面板上的数据已经可以用“惨烈”来形容：

    1. CPU 指标异常：平时 usr 利用率不到 15% 的 Broker 节点，usr 飙升至 85%，sys 飙到 15%，Context Switches（上下文切换）激增。

    2. URP 指标报警：kafka.server:type=ReplicaManager,name=UnderReplicatedPartitions 从 0 飙升到数百。

    3. Broker 日志刷屏：大量的 ISR 踢出与拉入日志，Zookeeper 会话出现超时。

    [202X-XX-XX 14:12:05,123] INFO [Partition topic-user-event-4 broker=1] Shrinking ISR from 1,2,3 to 1. (kafka.cluster.Partition)
[202X-XX-XX 14:12:18,456] INFO [Partition topic-user-event-4 broker=1] Expanding ISR from 1 to 1,2. (kafka.cluster.Partition)

    更致命的是，为了保证数据不丢失，该集群配置了强一致性参数 acks=all 以及 min.insync.replicas=2。当 ISR 缩减到只剩 Leader（1 个副本）时，Producer 瞬间收到了海量的 NotEnoughReplicasException 报错，整个业务写入链路直接被掐断。

    底层原理解析：当 SSL 遇到 Kafka

    为什么开个 SSL 能把集群干趴下？这要从 Kafka 引以为傲的高吞吐内核设计——零拷贝（Zero-Copy） 说起。

    1. 正常状态下的数据流转（sendfile）

    在未开启 SSL（PLAINTEXT）时，Consumer（包括作为特殊 Consumer 的 Follower 副本）向 Broker 发起 Fetch 请求，Broker 直接利用 Linux 操作系统的 sendfile 系统调用。

    数据流转路径：磁盘 -> DMA Copy -> OS PageCache -> DMA Copy -> 网卡 Buffer。 整个过程没有任何数据被拷贝到用户态空间（User Space），CPU 的参与度极低，只负责下发指令和管理文件描述符。

    可以通过 strace 命令清晰地看到高频的 sendfile 调用：

    # 跟踪 kafka 进程的系统调用统计
strace -f -p $(pgrep -f kafka) -e trace=sendfile,read,write -c

% time     seconds  usecs/call     calls    errors syscall
------ ----------- ----------- --------- --------- ----------------
 98.15    4.521012          52     86942           sendfile
  1.02    0.047101          10      4710           write
  0.83    0.038102           9      4233           read

    2. 开启 SSL 后的数据流转（零拷贝失效）

    SSL/TLS 属于应用层的加密协议。要对数据进行加密，内核态的 PageCache 就无能为力了，数据必须被读取到用户态的 JVM 内存中进行加密运算。

    此时 sendfile 退化为 read + write 的组合。 数据流转路径变成了：磁盘 -> DMA Copy -> OS PageCache -> CPU Copy -> User Space (JVM 堆外/堆内) -> CPU 执行加密算法 -> CPU Copy -> Socket Buffer -> DMA Copy -> 网卡 Buffer。

    上下文切换从 2 次增加到 4 次，数据拷贝次数增加，最要命的是 CPU 变成了密集型加密工人。结合当时的 strace 抓包，sendfile 的调用次数直接归零，取而代之的是暴涨的 read 和 write。

    3. 压死骆驼的最后一根稻草：历史数据回溯

    如果仅仅是开启 SSL，在常态流量下 CPU 也许还能扛住。但恰巧排查过程中发现，某大数据团队上线了一个新任务，从头消费（auto.offset.reset=earliest）一个高达数 TB 的核心 Topic。

    这种冷读行为导致了严重的 PageCache 污染与穿透。 Broker 不得不从物理磁盘读取冷数据，拉入 PageCache，再 Copy 到用户态进行 SSL 加密。磁盘 I/O 等待（iowait）、CPU 资源耗尽、内存带宽打满三管齐下。Broker 的网络线程池（num.network.threads）被这些沉重的处理逻辑长时间阻塞。

    故障传播链：ISR 机制引发的血案

    底层 I/O 阻塞后，Kafka 内核的分布式状态机开始崩溃，形成经典的雪崩链：

    1. Follower 同步延迟：Follower 向 Leader 发送的 FetchRequest 被积压在 Leader 的网络请求队列中。

    2. 触发 ISR 剔除：Leader 发现 Follower 超过 replica.lag.time.max.ms（默认 30000ms）没有成功拉取数据，认为 Follower 挂了，将其移出 ISR 列表。

    3. Zookeeper 冲击：Leader 将新的 ISR 状态写入 Zookeeper，频繁的元数据更新让 Zookeeper 的负载飙升。

    4. 业务断流：由于 min.insync.replicas=2，ISR 只剩 1 时，Leader 拒绝接收新的 Produce 请求。

    5. Leader 选举风暴：极端情况下，Broker 自身的 GC 停顿或 CPU 饥饿导致与 ZK 的 Session Timeout，Controller 认为 Broker 宕机，开始进行大规模的 Leader 切换，整个集群进入瘫痪状态。

    破局与防御性架构落地

    解决这个问题，不能头痛医头去改大 replica.lag.time.max.ms（这只会掩盖问题），必须从架构和配置层面进行隔离。

    1. 剥离内部 SSL，回归零拷贝 坚决摒弃“一刀切”的加密策略。将 Kafka 部署在安全的 VPC 内，配置多 Listener。Broker 间复制（内部流量）绝对禁止使用 SSL，保障 Follower 同步时的零拷贝效率。外部不可信网络接入时才走 SSL Listener。

    # 监听器隔离：内网明文，外网加密
listeners=INTERNAL://0.0.0.0:9092,EXTERNAL_SSL://0.0.0.0:9093
# 强制规定内部 Broker 通信必须走明文
security.inter.broker.protocol=PLAINTEXT
listener.security.protocol.map=INTERNAL:PLAINTEXT,EXTERNAL_SSL:SSL

    2. 物理资源隔离与 Quota 限流 针对重放历史数据的“野蛮”消费者，必须在 Kafka 层面实施配额（Quota）限制，防止单个 Consumer 耗尽 Broker 的网络带宽和 CPU。

    # 限制特定 Client-ID 的拉取速率 (例如限制为 50MB/s)
bin/kafka-configs.sh --bootstrap-server localhost:9092 \
  --alter --add-config 'consumer_byte_rate=52428800' \
  --entity-type clients --entity-name bad_consumer_client

    3. 内核参数调优防御 为了缓解偶尔的网络抖动导致的 ISR 频繁变动，适当微调相关参数，但不要偏离合理区间：

    • replica.lag.time.max.ms：结合网络 P99 延迟，可适当从 30s 调至 45s-60s。

    • num.network.threads 和 num.io.threads：在开启不可避免的 SSL 节点上，根据 CPU 核数增加处理线程，避免请求队列阻塞。

    排查清单：Kafka 性能骤降同类问题速查

    如果遇到类似 P99 飙升、URP 报警的问题，直接按以下清单排查：

    1. 查零拷贝状态：执行 strace -p -e trace=sendfile,read,write -c，如果 sendfile 占比极低且 read/write 极高，立刻检查是否有 SSL 开启或某些拦截器组件强制将数据读入了 User Space。

    2. 查 PageCache 命中率：通过 iostat -xdm 1 观察磁盘的 rMB/s。如果读磁盘的吞吐量极高，说明发生了冷读穿透，立刻通过 kafka-consumer-groups.sh 定位是哪个 Group 在重放历史数据。

    3. 查网络/IO线程阻塞：查看 JMX 指标 kafka.network:type=RequestMetrics,name=RequestQueueTimeMs。如果队列等待时间过长，说明 Broker 处理线程池已经打满。

    4. 查 ISR 震荡日志：在 server.log 中 grep "Shrinking ISR"。如果伴随频繁变动，且写入端出现 NotEnoughReplicasException，先检查集群级别的网络连通性及 Broker 负载，切勿盲目通过脚本强行 Reassign Partitions，那只会加重 IO 负担。