背压

适用场景：生产者 send() 偶发阻塞或抛 TimeoutException、缓冲区占用持续走高，需要定位瓶颈并调优 Producer 配置。 前置知识：Kafka 基本概念（topic / partition / broker / ACK）、生产者-消费者模型、Java 线程安全基础。 一、为什么生产者需要缓冲区 消息在 send() 之后去了哪里？为什么缓冲区会满、线程会阻塞？本文从双线程模型出发，逐层拆解 Kafka Producer 的缓冲、批量与背压机制。 Kafka 生产者并不会在代码调用 send() 时立刻把消息发到网络，而是先将消息放入一块内存缓冲区，攒够一批再发。这是批量（batching）的核心思想。 为什么要这样做？核心原因是网络 I/O 的成本。如果每条消息都单独发一次网络请求，开销巨大；如果把多条消息攒成一批，用一次请求发送，网络效率大幅提升。 类比理解：去邮局寄 1000 封信，每写好一封就单独发一辆车（1000 次发车），远不如把信攒够一车再发车（1 次发车）。Kafka 生产者选择的是后者。 但批量设计引入了一个关键问题：缓冲区大小有限。如果放入速度持续快于取出速度，缓冲区迟早会被填满。填满之后，新的 send() 调用会阻塞，直到缓冲区有空间——或者超时报错。理解这个问题，需要深入生产者的内部架构。 二、双线程模型 Kafka 生产者内部有两条并行的工作线：调用线程和 Sender 线程。 下图展示了完整的双线程架构。上半部分是调用线程的流水线，下半部分是 Sender 后台线程的数据通路，中间的 RecordAccumulator 是两者共享的缓冲桥梁。注意上半部分画的是多个调用线程——它们可以共享同一个 KafkaProducer 实例（详见本节末尾）： 调用线程（calling thread） 调用线程就是你的应用代码所在的线程（下称"调用线程"）。当调用 producer.send(record) 时，消息依次经过以下流水线： Interceptors（拦截器）：可对消息做修改或过滤，大多数场景不使用 Serializer（序列化器）：将业务对象序列化为字节数组 Partitioner（分区器）：决定消息发往哪个 partition RecordAccumulator（缓冲区）：将消息追加到对应 partition 的批次中 这一步完成后，send() 方法就返回了（异步），调用线程可以继续处理后续逻辑。 Sender 线程（唯一的后台线程） 一个单独的后台线程不停从缓冲区取出"已就绪"的批次，通过 NetworkClient 发给 Kafka Broker。这个线程随 KafkaProducer 实例创建时启动，随 close() 终止。 ...