图解Kafka消息发送者核心参数与工作机制

掌握一到两门java主流中间件，是敲开BAT等大厂必备的技能，送给大家一个Java中间件学习路线，助力大家实现职场的蜕变。java中间件进阶路线(三本电子书、12个免费专栏)

本文将从Kafka Producer的配置属性为突破口，结合源码深入提炼出Kafka Producer的工作机制，方便大家更好使用Kafka Producer，并且胸有成竹的进行性能调优。

将Kafka Producer相关的参数分成如下几个类型：

常规参数
工作原理(性能相关)参数(图解)

本文会结合图解方式，重点阐述与Kafka生产者运作机制密切相关的参数。

1、常规参数

为了更好的使用Kafka Producer，首先介绍一下几个基本参数。

bootstrap.servers
配置Kafka broker的服务器地址列表，多个用英文逗号分开，可以不必写全，Kafka内部有自动感知Kafka broker的机制。
client.dns.lookup
客户端寻找bootstrap地址的方式，支持如下两种方式：
resolve_canonical_bootstrap_servers_only
这种方式，会依据bootstrap.servers提供的主机名(hostname)，根据主机上的名称服务返回其IP地址的数组(InetAddress.getAllByName)，然后依次获取inetAddress.getCanonicalHostName()，再建立tcp连接。
一个主机可配置多个网卡，如果启用该功能，应该可以有效利用多网卡的优势，降低Broker的网络端负载压力。
use_all_dns_ips
这种方式会直接使用bootstrap.servers中提供的hostname、port创建tcp连接，默认选项。
compression.type
消息的压缩算法，目前可选值：none、gzip、snappy、lz4、zstd，默认不压缩，建议与Kafka服务器配置的一样，当然Kafka服务端可以配置的压缩类型为 producer，即采用与发送方配置的压缩类型。发送方与Broker 服务器采用相同的压缩类型，可有效避免在Broker服务端进行消息的压缩与解压缩，大大降低Broker的CPU使用压力。
client.id
客户端ID，如果不设置默认为producer-递增，强烈建议设置该值，尽量包含ip,port,pid。
send.buffer.bytes
网络通道(TCP)的发送缓存区大小，默认为128K。
receive.buffer.bytes
网络通道(TCP)的接收缓存区大小，默认为32K。
reconnect.backoff.ms
重新建立链接的等待时长，默认为50ms，属于底层网络参数，基本无需关注。
reconnect.backoff.max.ms
重新建立链接的最大等待时长，默认为1s，连续两次对同一个连接建立重连，等待时间会在reconnect.backoff.ms的初始值上成指数级递增，但超过max后，将不再指数级递增。
key.serializer
消息key的序列化策略，为org.apache.kafka.common.serialization接口的实现类。
value.serializer
消息体的序列化策略
partitioner.class
消息发送队列负载算法，其默 DefaultPartitioner，路由算法如下：
如果指定了 key ，则使用 key 的 hashcode 与分区数取模。
如果未指定 key，则轮询所有的分区。
interceptor.classes
拦截器列表，kafka运行在消息真正发送到broker之前对消息进行拦截加工。
enable.idempotence
是否开启发送端的幂等，这个机制后续会重点剖析其实现原理，默认为false。
transaction.timeout.ms
事务协调器等待客户端的事务状态反馈的最大超时时间，默认为60s。
transactional.id
事务id,用于在一个事务中唯一标识一个客户端。

2、工作原理相关参数

2.1 核心参数一览

工作机制相关参数，涉及到消息发送是如何工作的，本节首先将罗列参数，做简单说明，然后再给出运作图，进一步阐述其工作机制。

buffer.memory
用于设置一个生产者(KafkaProducer)中缓存池的内存大小，默认为32M。
max.block.ms
当消息发送者申请空闲内存时，如果可用内存不足的等待时长，默认为60s，如果在指定时间内未申请到内存，消息发送端会直接报TimeoutException,这个时间包含了发送端用于查找元信息的时间。
retries
重试次数，Kafka Sender线程从缓存区尝试发送到Broker端的重试次数，默认为Integer.MAX_VALUE，为了避免无限重试，只针对可恢复的异常,例如Leader选举中这种异常就是可恢复的，重试最终是能解决问题的。
acks
用来定义消息“已提交”的条件(标准)，就是 Broker 端向客户端承偌已提交的条件，可选值如下：
0
表示生产者不关心该条消息在 broker 端的处理结果，只要调用 KafkaProducer 的 send 方法返回后即认为成功，显然这种方式是最不安全的，因为 Broker 端可能压根都没有收到该条消息或存储失败。
all 或 -1
表示消息不仅需要 Leader 节点已存储该消息，并且要求其副本（准确的来说是 ISR 中的节点）全部存储才认为已提交，才向客户端返回提交成功。这是最严格的持久化保障，当然性能也最低。
1
表示消息只需要写入 Leader 节点后就可以向客户端返回提交成功。
batch.size
在消息发送端Kafka引入了批的概念，发送到服务端的消息通常不是一条一条发送，而是一批一批发送，该值用于设置每一个批次的内存大小,一个批次对应源码层级为ProducerBatch对象，默认为16K。
linger.ms
该参数与batch.size配合使用。Kafka希望一个批次一个批次去发送到Broker，应用程序往KafkaProducer中发送一条消息，首先会进入到内部缓冲区，具体是会进入到某一个批次中(ProducerBatch),等待该批次堆满后一次发送到Broker，这样能提高消息的吞吐量，但其消息发送的延迟也会相应提高，试想一下，如果在某一个时间端，应用端发送到broker的消息太少，不足以填满一个批次，那岂不是消息一直无法发送到Broker端吗？

为了解决该问题，linger.ms参数应运而生。它的作用是控制在缓存区中未积满时来控制消息发送线程的行为。如果linger.ms 设置为 0表示立即发送，如果设置为大于0，则消息发送线程会等待这个值后才会向broker发送。有点类似于 TCP 领域的 Nagle 算法。
delivery.timeout.ms
消息在客户端缓存中的过期时间，在Kafka的消息发送模型中，消息先进入到消息发送端的双端缓存队列中，然后单独一个线程将缓存区中的消息发送到Broker，该参数控制在双端队列中的过期时间，默认为120s，从进入双端队列开始计时，超过该值后会返回超时异常(TimeoutException)。
request.timeout.ms
请求的超时时间，主要是Kafka消息发送线程(Sender)与Broker端的网络通讯的请求超时时间。
max.request.size
Send线程一次发送的最大字节数量，也就是Send线程向服务端一次消息发送请求的最大传输数据，默认为1M。
max.in.flight.requests.per.connection
设置每一个客户端与服务端连接，在应用层一个通道的积压消息数量，默认为5，有点类似Netty用高低水位线控制发送缓冲区中积压的多少，避免内存溢出。

2.2 图解工作原理

上面的核心参数在表述上可能不够直观，接下来我想简单通过两张图阐述一下Kafka消息发送相关的核心原理。

首先，我们来看一下消息发送者相关的数据结构：

Kafka的每一个消息发送者，也就是KafkaProducer对象内部会有一块缓存区，其总大小由buffer.memory指定，默认为32M，但内存的组织会按照topic+parition构建双端队列，队列中的每一个元素为一个ProducerBatch对象，表示一个消息发送批次，但发送线程将消息发送到Broker端时，一次可以包含多个批次。一次允许发送的消息总大小受max.request.size控制，默认为1M。

在了解了核心数据结构后，我们再看一下各个核心参数在消息发送的各个阶段是如何工作的。

2.3 性能优化

从Kafka Producer 的工作原理来看，在客户端所谓的性能优化，其实就是延迟、吞吐率、数据完整性的一个权衡。在具体的实践中通常可以调整的参数主要如下：

acks 这个只能是根据业务的特点，对数据丢失的容忍度，通常该参数在实践过程中遇到性能瓶颈后，调整该参数的可能性几乎没有，因为需要牺牲数据的完整性，此举并不是一个好的方案。
batch.size 与 linger.ms
通常可以适当修改batch.size与linger.ms的值，特别是linger.ms值，牺牲一定的延时，方便更多数据进入到Batch，从而提高Sender线程一次发送的数据大小，提高带宽，显著提高吞吐率，但牺牲延时。当然如果是想提高响应延迟，则采取的手段则恰恰相反。
buffer.memory、max.request.size
如果需要进一步提高吞吐量，可以适当提高buffer.memory的大小，让客户端能缓存更多数据，并且调高max.request.size，进一步提高单次消息发送的消息量。

从工作原理图中要得到上述的方式并不难，但我们有没有办法正确的评估到底是需要调整batch.size，还是要调整uffer.memory呢？

有没有科学的指导，如何判断一个客户端当前的瓶颈到底在什么地方，如何针对性的进行调优呢？请持续关注本公众号，该部分将在下一篇文章中与大家详细剖析，我们下期再会。

好了，本文就介绍到这里了，三连(关注、点赞、留言)是对我最大的鼓励，当然可以加笔者微信：dingwpmz，共同交流探讨。

最后分享笔者一个硬核的RocketMQ电子书，您将获得千亿级消息流转的运维经验。