Kafka生产者详解

一，Kafka生产者的执行过程

生产者客户端由两个线程协调运行，这两个线程分别为主线程和Sender线程（发送线程）：
（1）在主线程中由KafkaProducer创建消息，然后通过可能的拦截器、序列化器和分区器的作用之后缓存到消息累加器（RecordAccumulator，也称消息收集器）中。
（2） Sender线程负责从RecordAccumulator中获取消息并将其发送到Kafka中。

我们从创建一个KafkaProducer对象开始，它将创建一个ProducerRecord对象。这个对象是Kafka中的一个核心类，它代表生产者发送到Kafka服务器端的一个消息对象，即一个Key-Value的键值对。
在ProducerRecord对象中，包含如下信息：
（1）Kafka服务器端的主题名称（Topic Name）。
（2）Topic中可选的分区号。
（3）时间戳。
（4）其他Key-Value键值对。

ProducerRecord创建成功后，需要经过拦截器、序列化器将其转换为字节数组，这样它们才能够在网络上传输，然后消息到达分区器。分区器的作用是根据发送过程中指定的有效的分区号，将ProducerRecord发送到该分区；如果没有指定Topic中的分区号，则会根据Key进行Hash运算，将ProducerRecord映射到一个对应的分区。
ProducerRecord默认采用当前的时间，用户也在创建ProducerRecord的时候提供一个时间戳。

Kafka最终使用的时间戳取决于Topic的配置，而Topic时间戳的配置主要有以下两种：
（1）CreateTime表示使用生产者产生的时间戳作为Kafka最终的时间戳。
（2） LogAppendTime表示生产者记录中的时间戳在将消息添加到其日志中时，将由Kafka Broker重写。
ProducerRecord在经过主线程后，最终由发送线程发送到Kafka服务器端。Kafka Broker在收到消息时会返回一个响应，如果写入成功，则返回一个RecordMetaData对象，它包含主题和分区信息，以及记录在分区里的偏移量，上面两种时间戳类型也会返回给用户。如果写入失败，则返回一个错误。生产者在收到错误之后会尝试重新发送消息，几次之后如果还是写入失败，就返回错误消息。

二、创建基本的消息生产者

要在Kafka消息集群中写入消息，首先需要创建一个生产者对象。Kafka生产者有三个必选的属性：

1，bootstrap.servers

该属性指定Kafka集群中Broker的地址列表，其地址的格式为host:port，如果有多个Broker地址，可以用逗号进行分隔。当然，该地址列表中不需要包含所有Broker，因为Kafka会将整个集群的元信息和配置信息存储在ZooKeeper中，生产者会从给定的Broker中，通过ZooKeeper查找到其他Kafka Broker地址信息。在生产环境中，建议至少要提供两个Broker地址信息，这样做的目的是支持容错。一旦其中一个Broker出现了宕机，生产者仍然能够通过另一个Broker连接到Kafka集群上。

2，key.serializer

发送到Kafka的消息需要经过序列化后，才能实现正常发送与转发。生产者将要发送的消息通过序列化器进行序列化后，生成一个key/value的值，并发送到Broker。当创建Kafka生产者的时候，生产者需要知道采用何种方式把消息（即Java对象）转换为字节数组。因此通过生产者端的参数key.serializer就是这一项配置的工作。它必须实现org.apache.kafka.common.serialization.Serializer接口，然后生产者会使用这个类把键对象序列化为字节数组。

3，value.serializer

value.serializer与key.serializer一样，用于指定的类会将值序列化。

示例代码：

01  Properties props = new Properties();
02  props.put("bootstrap.servers", "kafka101:9092");
03  props.put("acks", "all");
04
05  props.put("retries", 0);
06  props.put("batch.size", 16384);
07  props.put("linger.ms", 1);
08  props.put("buffer.memory", 33554432);
09
10  props.put("key.serializer",
11            "org.apache.kafka.common.serialization.StringSerializer");
12  props.put("value.serializer",
13            "org.apache.kafka.common.serialization.StringSerializer");
14
15  Producer<String, String> producer = new KafkaProducer<String, String>(props)

第05行～第08行代码不是必需的，如果没有配置这些参数，将会采用默认的参数值

三、发送自定义消息对象

Kafka生产者发送的消息必须经过序列化。实现序列化可以简单地总结为两步，第一步继承序列化Serializer接口；第二步实现接口方法，将指定类型序列化成byte[]，或者将byte[]反序列化成指定数据类型。接下来，我们来实现序列化/反序列化方式。
实现Java对象的序列化有很多不同的方式。这里我们介绍基于FastJson的序列化方式。Fastjson是一个Java库，可以将Java对象转换为JSON格式，当然它也可以将JSON字符串转换为Java对象，加入以下依赖。

01  
02      com.alibaba</groupId>
03      fastjson</artifactId>
04      1.2.68</version>
05  </dependency>

四、生产者的消息发送模式

Kafka生产者的消息发送主要有三种模式：发后即忘（fire-and-forget）、同步模式（sync）及异步模式（async）。

1，发后即忘：

只管向Kafka中发送消息而并不用关心消息是否正确到达。在大多数情况下，这种发送方式没有什么问题，不过在某些时候（比如发生不可重试异常时）会造成消息的丢失。这种发送方式的性能最高，可靠性也最差。EmployeeProducer就是采用的这种模式。

2，同步模式：

要实现同步的发送方式，可以利用返回的Future对象的阻塞等待Kafka的响应即可实现，直到消息发送成功。如果发生异常，就需要捕获异常并交由外层逻辑处理。改造一下之前的EmployeeProducer代码，使用同步模式将消息发送到Kafka服务器端。

3，异步模式：

为了在异步发送消息的同时能够对异常情况进行处理，生产者提供了回调支持。一般在send()方法中指定一个Callback的回调函数，Kafka在返回响应时调用该函数来实现异步的发送确认。改造一下之前的EmployeeProducer生产者代码，使用异步模式将消息发送到Kafka服务器端。

五、生产者分区机制

Kafka消息系统为什么要进行Topic的分区呢？我们都知道Kafka的主题Topic是由分区组成的，而将Topic进行分区的主要目的就是提供负载均衡和容错的能力，以及实现系统的高伸缩性和高可用性。Kafka的消息组织方式实际上是三层结构：主题—分区—消息。主题下的每条消息只会保存在某一个分区中，而不会在多个分区中保存多份。在创建Topic的时候可以指定每个分区的副本数，用于支持分区中消息的容错。
不同的分区能够放置在Kafka集群中不同的节点上，而生产者和消费者在产生消息和消费消息的时候，也都是针对分区进行的，这样每个节点的机器都能独立执行各自分区的读写请求处理，并且还可以通过添加新的Kafka节点来增加整体系统的吞吐量。

常见的分区策略：
（1）默认分区策略（org.apache.kafka.clients.producer.internals.DefaultPartitioner）。
（2）轮询分区策略（org.apache.kafka.clients.producer.RoundRobinPartitioner）。
如果key值为null，并且使用了默认的分区器，Kafka会根据轮询（Random Robin）策略将消息均匀地分布到各个分区上。
（3）黏性分区策略（org.apache.kafka.clients.producer.UniformStickyPartitioner）。
黏性分区策略就像黏住这个分区一样，只要这个分区没有被填满，就会尽可能地坚持使用该分区。这种策略首先会选择单个分区发送所有无key的消息，一旦这个分区已填满，黏性分区策略就会随机选择另一个分区。通过查看源码，可以得到黏性分区策略是通过org.apache.kafka.clients.producer. internals.StickyPartitionCache来实现的。
（4）散列分区策略。
如果键值不为null，并且使用了默认的分区器，Kafka会对键进行散列，然后根据散列值把消息映射到对应的分区上。
（5）自定义分区策略。前面提到Kafka生产者的分区策略都实现了接口org.apache.kafka.clients. producer.Partitioner，用户可以根据需要对数据使用不一样的分区策略，只需要实现该接口即可。用户创建了自定义分区策略后，只需要在生产者的Properties中指定ProducerConfig.PARTITIONER_CLASS_CONFIG参数即可。

六、生产者压缩机制

Kafka发送消息的时候，可以在生产者端和Broker端进行消息的压缩。在一般情况下，建议采用的压缩机制是：生产者端负责压缩；Broker端负责保持；消费者端负责解压。Kafka采用这样的压缩机制，主要是节约CPU的时间去换磁盘存储的空间，以及网络I/O的传输量。这样的做法可以以较小的CPU开销带来更少的磁盘占用或更少的网络I/O传输。

七、生产者拦截器

在KafkaProducer的主线程中可以创建一个或多个ProducerInterceptors（拦截器）。拦截器是从Kafka 0.10版本中引入的，在生产者端和消费者端均可设置，拦截器主要用于实现生产者端和消费者端的定制化控制逻辑。对生产者而言，拦截器需要实现org.apache.kafka.clients.producer.ProducerInterceptor接口。

ProducerInterceptor中的方法：

01   package org.apache.kafka.clients.producer;
02
03   import org.apache.kafka.common.Configurable;
04
05   public interface ProducerInterceptor<K, V> extends Configurable {
06
07       public ProducerRecord<K, V> onSend(ProducerRecord<K, V> record);
08
09       public void onAcknowledgement(RecordMetadata metadata, Exceptionexception);
10
11       public void close();
12   }

接口中的三个方法：
（1）onSend。
该方法将在KafkaProducer.send方法的主线程中执行。KafkaProducer确保在消息被序列化以前，调用ProducerInterceptor.onSend方法。用户可以在该方法中对消息进行操作，但最好不要修改消息所属的Topic和分区，否则会影响目标分区的计算。
（2）onAcknowledgement。
该方法会在消息被确认应答之前或消息发送失败时调用。如果生产者采用的是异步发送机制，该方法通常是在生产者回调逻辑触发之前被调用的。需要注意的是，该方法运行在生产者的I/O线程中，因此不要在该方法中放入很重的逻辑，否则会影响生产者的消息发送性能。
（3）close。
关闭拦截器之前，可以将一些资源清理工作放在close方法中。
需要注意的是，如果指定了多个连接器，生产者将按照指定顺序调用它们。如果拦截器中出现了异常，生产者会将异常的错误信息记录到错误日志中，而不是向上传递。

八、生产者的参数配置

1，acks

这个参数控制了发送消息的耐用性，用于指定分区中必须有多少个副本成功接收到消息，之后生产者才会认为这条消息写入是成功的，即生产者需要leader确认请求完成之前接收的应答数。通过查看ProducerConfig的源码可以看出acks参数的本质其实就是一个字符串。

acks参数有三种类型的值。
1）acks=1。
这是acks参数的默认值。Kafka的生产者将消息发送到Kafka的Broker服务器端。只要Topic分区中的Leader成功写入消息，就算该消息成功发送。这时候，生产者就会收到Kafka服务器端Broker的成功确认信息，说明发送成功。
如果在生产者写入消息的过程中，Leader分区所在的Broker出现了宕机，将会造成消息无法正常写入。在重新选举Leader的过程中，生产者Producer会受到一个服务器端返回的错误信息。生产者为了支持容错，避免消息的丢失，会尝试重新发送该消息。直至消息成功写入Leader分区。
这里需要注意的是，如果消息已经成功写入Leader所在的分区，但还未同步至其他Follower分区的时候，如果Leader分区所在的Broker出现了宕机，这时候会造成写入Leader分区的消息丢失。所以在这种参数值的设置下，消息是可能丢失的。
2）acks=0。
在这种参数设置下，Kafka的生产者不需要等待任何服务器端的响应，所以这时Kafka集群可以达到最大的吞吐量。如果消息从生产者发送到写入Kafka消息系统的过程中出现异常，比如Broker宕机，生产者将不会得到任何反馈信息，也不会重发消息，导致消息丢失。
3）acks=-1或acks=all。
在这种参数设置下，Kafka集群将达到最高的可靠性。生产者发送完消息后，需要等待Leader分区和所有Follower分区都成功写入消息后，才返回给生产者一个成功写入消息的应答响应。

2，buffer.memory

Kafka生产者的Sender线程在将消息发送到Kafka服务器端之前，会把消息缓存到内存中，这个参数就决定了消息缓存的内存大小，其默认值是32MB。如果生产者产生消息的速度大于将消息发送到服务器端的速度，那么生产者将会被阻塞，并最终导致生产者抛出一个RecordTooLargeException的异常。
在实际的生产环境下，应该根据实际情况进行测试最终决定buffer.memory参数值的大小。

（1） batch.size。

当Kafka客户端将多个消息发送到同一个分区的时候，生产者为了减少客户端与服务器端的请求交互，会尝试将消息批量打包在一起，进行统一发送，这样有助于提升客户端和服务器端的性能。该配置的默认批次大小（以字节为单位）是16 384字节。如果消息的内存大小大于该参数的配置，将不会进行批量打包的过程。
通过提升batch.size的大小，可以允许更多数据缓冲在分区中，那么一次请求服务器端所发送出去的数据量就更多了，这样吞吐量可能会有所提升。但是这样会造成大量内存的浪费。反过来如果减小batch.size的大小，则会系统地降低吞吐量。如果将batch.size设置为0，则批处理机制被禁用。所以需要在这里按照生产环境的发消息速率，调节不同的batch.size大小，从而设置一个最合理的参数。

（2）compression.type。

该参数指定给到Topic中数据的压缩类型，其有效值的设置可以是标准的压缩方式，例如，‘gzip’、‘snappy’、‘lz4’、‘zstd’，同时该参数也可以是’uncompressed’，在这种设置下，消息数将不会被压缩。

（3）client.id。

当生产者向服务器端发送请求时，传递给服务器端ID字符串。通过这个ID字符串，Kafka服务器端就可以追踪请求的资源，其本质就是将生产者及其请求的资源进行逻辑上的隔离。

（4）connections.max.idle.ms。

当生产者不再往服务器端发送消息时，这个参数用来决定关闭生产者连接的时间阈值，其默认值是9min。

（5） linger.ms。

该参数决定消息在由生产者发送到服务器端之前，在客户端延长发送的时间。通过这样的延时发送机制，可以将多个消息组合成一个批处理进行统一发送。从本质上讲，该参数与之前提到过的batch.size参数类似。合理设置batch.size参数和linger.ms参数，将很好地利用Kafka批处理机制。把linger.ms设置得太小了，比如默认就是0ms，或者设置为5ms，那可能导致Batch虽然设置了32KB，但是经常是还没凑够32KB的数据，5ms之后就直接强制Batch将数据发送出去，这会导致你的Batch形同虚设，一直凑不满数据。

（6）max.block.ms。

该配置控制KafkaProducer.send()和KafkaProducer.partitionsFor()将消息阻塞多长时间。此外也可能是因为缓冲区已满或元数据不可用，导致这些方法被阻止。在用户提供的序列化程序或分区器中的锁定不会计入此超时，其默认值为60 000ms。

（7） max.request.size。

Kafka生产者能发送消息的最大值，默认值为1MB。此设置将限制生产者的单个请求中发送的消息批次数，以避免发送过大的请求。这个参数涉及其他一些相关参数，比如服务器Broker端的message.max.bytes参数，如果message.max.bytes参数设置为10，而max. request.size设置为20，这时候就可以造成生产者报错。

（8） retries和retry.backoff.ms。

如果生产者出现了异常，或者消息没有成功写入Kafka的服务器端，生产者可以配置重试的参数值，通过生产者端的内部重试机制来执行恢复，并不是直接将异常抛出。如果重试达到设定次数，生产者才会放弃重试并抛出异常。retries参数的默认值是0。同时，生产者的重试还与retry.backoff.ms参数有关，该参数用来设定两次重试之间的时间间隔，其默认值是100ms，从而避免无效的频繁重试。在配置retries参数和retry.backoff.ms参数之前，可以设定总重试时间要大于异常恢复时间，最好先估算一下异常恢复时间，避免生产者过早放弃重试。

（9）receive.buffer.bytes。

这个参数用来设置socket接收消息缓冲区的大小，该缓存区大小的默认值32KB。如果将其值设置为-1，则使用操作系统的默认值。

（10）send.buffer.bytes。

这个参数用来设置socket发送消息缓冲区的大小，默认值为128KB。与receive.buffer.bytes参数一样，如果将其值设置为-1，则使用操作系统的默认值。

（11）request.timeout.ms。

消息由生产者发出后，该参数用于决定生产者等待请求响应的最长时间，其默认值为40s。如果响应的时间超过了该参数的设置，客户端将按照重试策略进行重试。注意，这个参数值需要比Broker端的参数replica.lag.time.max.ms值要大，这样可以减少因客户端重试引起的消息重复的概率。

（12） reconnect.backoff.max.ms。

该参数表示Kafka客户端重连的最大时间。每次连接失败，重连时间都会成指数级增加，每次增加的时间会存在20%的随机浮动，以避免连接风暴。

（13）reconnect.backoff.ms。

该参数表示Kafka客户端每次重连时候的间隔时间。

（14）delivery.timeout.ms。

当生产者调用send方法后，该参数用于指定客户端等待发送成功或失败报告时，客户端等待时间的上限。时间上限包括：
　1） 一条消息在发送前的延时时间。
　2） 生产者等待服务器端Broker确认信息的等待时间。
　3） 失败时的重试时间。

（15）partitioner.class。

该参数表示一个实现了org.apache.kafka.clients.producer.Partitioner接口的类。Kafka将使用这个类进行分区操作，其默认值是org.apache.kafka.clients.producer.internals.DefaultPartitioner。通过实现这个接口，可以实现自定义分区。

（16） transaction.timeout.ms。

该参数表示生产者主动终止当前正在进行的操作之前，Kafka等待操作状态更新的最大时间，其默认值是1min。如果该值大于Broker中max.transaction.timeout.ms的设置，则请求失败，并报"InvalidTransactionTimeout"错误。

（17） transactional.id。

在事务传递过程中该参数用于表示某个事务的ID。这样可以保证跨多个生产者会话时语义的可靠性。因为它允许客户端保证在开始任何新事务之前使用相同的Transactional Id的事务来完成。

（18） max.in.flight.requests.per.connection。

该参数表示在消息被阻塞前，每个客户端上发送的未应答请求的最大数量，其默认值是5。注意，如果该参数值设置大于1，并且消息发送失败，则由于客户端的重试增加消息重新排序的风险。

（19） metadata.max.age.ms。

该参数表示当超过这个时间间隔时，系统就会更新元信息，其默认值5min。Kafka的元数据信息由ZooKeeper维护，包含Topic信息、副本信息、分区信息、Broker信息。

（20）metadata.max.idle.ms。

当Topic处于空闲状态时，该参数用于控制生产者抓取Topic元信息的时间。

文章来源：《Kafka进阶》 作者：赵渝强

文章内容仅供学习交流，如有侵犯，联系删除哦！