kafka生产者你不得不知的那些事儿

浅浅的花香味﹌ 2023-10-10 20:34 3阅读 0赞

### 前言 ###

kafka生产者作为消息发送中很重要的一环，这里面可是大有文章，你知道生产者消息发送的流程吗？知道消息是如何发往哪个分区的吗？如何保证生产者消息的可靠性吗？如何保证消息发送的顺序吗？如果对于这些问题还比较模糊的话，那么很有必要看看这篇文章了，本文主要是基于kafka3.x版本讲解。

### 生产者流程 ###

kafka生产者最重要的就是消息发送的整个流程，我们来看下究竟是怎么一回事把。

在消息发送的过程中，涉及到了两个线程——`main` 线程和 `Sender` 线程。在 `main` 线程中创建了一个双端队列 `RecordAccumulator`。`main` 线程将消息发送给 `RecordAccumulator`，`Sender` 线程不断从 `RecordAccumulator` 中拉取消息发送到 `Kafka Broker`。

![format_png][]

1.  在主线程中由 `kafkaProducer` 创建消息，然后通过可能的拦截器、序列化器和分区器的作用之后缓存到消息累加器（`RecordAccumulator`, 也称为消息收集器）中。

*  **拦截器**： 可以用来在消息发送前做一些准备工作，比如按照某个规则过滤不符合要求的消息、修改消息的内容等，也可以用来在发送回调逻辑前做一些定制化的需求，比如统计类工作。
 *  **序列化器：** 用于在网络传输中将数据序列化为字节流进行传输，保证数据不会丢失。
 *  **分区器：** 用于按照一定的规则将数据分发到不同的kafka broker节点中

1.  `Sender` 线程负责从 `RecordAccumulator` 获取消息并将其发送到 `Kafka` 中。

*  `RecordAccumulator` 主要用来缓存消息以便 `Sender` 线程可以批量发送，进而减少网络传输的资源消耗以提升性能。
 *  `RecordAccumulator` 缓存的大小可以通过生产者客户端参数 `buffer.memory` 配置，默认值为 `33554432B` ，即 `32M`。
 *  主线程中发送过来的消息都会被迫加到 `RecordAccumulator` 的某个双端队列（ `Deque` ）中，`RecordAccumulator` 内部为每个分区都维护了一个双端队列，即 `Deque<ProducerBatch>`, 消息写入缓存时，追加到双端队列的尾部。
 *  `Sender` 读取消息时，从双端队列的头部读取。`ProducerBatch` 是指一个消息批次；与此同时，会将较小的 `ProducerBatch` 凑成一个较大 `ProducerBatch` ，也可以减少网络请求的次数以提升整体的吞吐量。`ProducerBatch` 大小可以通过`batch.size` 控制，默认`16kb`。
 *  `Sender` 线程会在有数据积累到`batch.size`,默认16kb，或者如果数据迟迟未达到`batch.size`，`Sender`线程等待`linger.ms`设置的时间到了之后就会获取数据。`linger.ms`单位`ms`，默认值是`0ms`，表示没有延迟。

1.  `Sender` 从 `RecordAccumulator` 获取缓存的消息之后，会将数据封装成网络请求`<Node,Request>` 的形式，这样就可以将 `Request` 请求发往各个 `Node` 了。
2.  请求在从 `sender` 线程发往 `Kafka` 之前还会保存到 `InFlightRequests` 中，它的主要作用是缓存了已经发出去但还没有收到服务端响应的请求。`InFlightRequests`默认每个分区下最多缓存5个请求，可以通过配置参数为`max.in.flight.request.per. connection`修改。
3.  请求`Request`通过通道`Selector`发送到`kafka`节点。
4.  发送后，需要等待kafka的应答机制，取决于配置项`acks`.

*  0：生产者发送过来的数据，不需要等待数据落盘就应答。
 *  1：生产者发送过来的数据，`Leader` 收到数据后应答。
 *  \-1（all）：生产者发送过来的数据，Leader和副本节点收齐数据后应答。默认值是-1，-1 和all 是等价的。

1.  `Request`请求接受到kafka的响应结果，如果成功的话，从`InFlightRequests` 清除请求，否则的话需要进行重发操作，可以通过配置项`retries`决定，当消息发送出现错误的时候，系统会重发消息。`retries`表示重试次数。默认是 int 最大值，`2147483647`。
2.  清理消息累加器`RecordAccumulator` 中的数据。

### 生产者重要参数 ###

现在我们来看看kafka生产者中常用且关键的配置参数。

1.  `bootstrap.servers`

生产者连接集群所需的 broker 地 址 清 单 。 例 如`hadoop102:9092,hadoop103:9092,hadoop104:9092`，可以设置 1 个或者多个，中间用逗号隔开。注意这里并非需要所有的 broker 地址，因为生产者从给定的 `broker`里查找到其他 `broker` 信息。

1.  `key.serializer` **和** `value.serializer`

指定发送消息的 key 和 value 的序列化类型。一定要写全类名。

1.  `buffer.memory`

`RecordAccumulator` 缓冲区总大小，默认 32m。

1.  `batch.size`

缓冲区一批数据最大值，默认 16k。适当增加该值，可以提高吞吐量，但是如果该值设置太大，会导致数据传输延迟增加。

1.  `linger.ms`

如果数据迟迟未达到 `batch.size`，kafka等待这个时间之后就会发送数据。单位 ms，默认值是 0ms，表示没有延迟。生产环境建议该值大小为 `5-100ms` 之间。

1.  `max.request.size`

这个参数用来限制生产者客户端能发送的消息的最大值，默认值为 1048576B ，即 lMB 一般情况下，这个默认值就可以满足大多数的应用场景了。

1.  `compression.type`

这个参数用来指定消息的压缩方式，默认值为“`none` "，即默认情况下，消息不会被压缩。该参数还可以配置为 "`gzip`"，"`snappy`" 和 "`lz4`"。对消息进行压缩可以极大地减少网络传输、降低网络 I/O，从而提高整体的性能 。消息压缩是一种以时间换空间的优化方式，如果对时延有一定的要求，则不推荐对消息进行压缩；

1.  `acks`

`acks`的值为0，1和-1或者all。

*  0表示`Producer` 往集群发送数据不需要等到集群的返回，不确保消息发送成功。安全性最低但是效率最高。
 *  1表示`Producer` 往集群发送数据只要 `Leader` 成功写入消息就可以发送下一条，只确保 `Leader` 接收成功。
 *  \-1 或 all表示`Producer` 往集群发送数据需要所有的 `ISR Follower` 都完成从 `Leader` 的同步才会发送下一条，确保Leader `发送`成功和所有的副本都成功接收。安全性最高，但是效率最低。

1.  `max.in.flight.requests.per.connection`

允许最多没有返回 ack 的次数，默认为 5，开启幂等性要保证该值是 1-5 的数字。

1.  `retries`**和**`retry.backoff.ms`

当消息发送出现错误的时候，系统会重发消息。`retries`表示重试次数。在kafka3.4.0默认是 int 最大值，`2147483647`。如果设置了重试，还想保证消息的有序性，需要设置`max.in.flight.requests.per.connection`=1否则在重试此失败消息的时候，其他的消息可能发送成功了。另外`retry.backoff.ms`控制两次重试之间的时间间隔，默认是 100ms。

更多kafka生产者的配置可以查阅官网`https://kafka.apache.org/documentation/#producerconfigs`。

### 生产者发送消息API ###

#### 生产者发送demo ####

通常情况下，生产者发送消息分为以下4个步骤:

（1）配置生产者客户端参数及创建相应的生产者实例

（2）构建待发送的消息

（3）发送消息

（4）关闭生产者实例

我们直接上代码。

1.  **引入maven依赖**

xml

复制代码

`<dependency> <groupId>org.apache.kafka</groupId> <artifactId>kafka-clients</artifactId> <version>3.3.0</version> </dependency>`

1.  **核心发送逻辑**

java

复制代码

`public static void main(String[] args) { // 1. 创建 kafka 生产者的配置对象 Properties properties = new Properties(); // 2. 给 kafka 配置对象添加配置信息：bootstrap.servers properties.put(ProducerConfig.BOOTSTRAP_SERVERS_CONFIG, "localhost:9092"); // key,value 序列化（必须）：key.serializer，value.serializer properties.put(ProducerConfig.KEY_SERIALIZER_CLASS_CONFIG, "org.apache.kafka.common.serialization.StringSerializer"); properties.put(ProducerConfig.VALUE_SERIALIZER_CLASS_CONFIG, "org.apache.kafka.common.serialization.StringSerializer"); // 3. 创建 kafka 生产者对象 KafkaProducer<String, String> kafkaProducer = new KafkaProducer<String, String>(properties); // 4. 调用 send 方法,发送消息 for (int i = 0; i < 5; i++) { kafkaProducer.send(new ProducerRecord<>("first", Integer.toString(i), "hello " + i)); } // 5. 关闭资源 kafkaProducer.close(); }`

1.  **消息对象**`ProducerRecord`

kafka发送时主要构造出`ProducerRecord`对象，包含发送的主题，partition，key，value等。

java

复制代码

`public class ProducerRecord<K, V> { private final String topic; private final Integer partition; private final Headers headers; private final K key; private final V value; private final Long timestamp; }`

#### 三种发送模式 ####

kafka提供了3种发送消息的模式，发后即忘，同步发送和异步发送，我们直接上代码。

1.  **发后即忘(** `fire-and-forget` **）**

发后即忘，它只管往 Kafka 发送，并不关心消息是否正确到达。 在大多数情况下，这种发送方式没有问题。 不过在某些时候（比如发生不可重试异常时）会造成消息的丢失。 这种发送方式的性能最高，可靠性最差。

java

复制代码

`Future<RecordMetadata> send = producer.send(rcd);`

1.  **同步发送（** `sync` \*\*\*\*）

只需在上面种发送方式的基础上，再调用一下 get()方法即可，该方法时阻塞的。

java

复制代码

`// 同步发送 kafkaProducer.send(new ProducerRecord<>("first","kafka" + i)).get();`

1.  **带回调异步发送（** `async` \*\*\*\*）

回调函数会在 `producer` 收到 `ack` 时调用，为异步调用，该方法有两个参数，分别是 `RecordMetadata` 和`Exception`，如果 `Exception` 为 `null`，说明消息发送成功，如果 `Exception` 不为 `null`，说明消息发送失败。

注意：消息发送失败会自动重试，不需要我们在回调函数中手动重试。

java

复制代码

`for (int i = 0; i < 5; i++) { kafkaProducer.send(new ProducerRecord<>("first", Integer.toString(i), "hello " + i), new Callback() { @Override public void onCompletion(RecordMetadata metadata, Exception exception) { if (exception == null) { // 没有异常,输出信息到控制台 System.out.println(" 主题： " + metadata.topic() + "->" + "分区：" + metadata.partition()); } else { // 出现异常打印 exception.printStackTrace(); } } }); }`

### 生产者发送核心机制 ###

#### 生产者分区机制 ####

![format_png 1][]

kafka设计上存在分区的，它有下面两个好处：

*  **便于合理使用存储资源**，每个`Partition`在一个`Broker`上存储，可以把海量的数据按照分区切割成一块一块数据存储在多台`Broker`上。合理控制分区的任务，可以实现负载均衡的效果。
 *  **提高并行度和吞吐量**，生产者可以以分区为单位发送数据；消费者可以以分区为单位进行消费数据。

**那究竟生产者是按照什么样的策略发往到不同的分区呢？**

根据生产者的发送流程，其中会经过分区器，默认情况下是使用`DefaultPartitioner`，具体逻辑如下：

1.  按指定分区发送

`kafka`发送消息的时候构造消息对象`ProducerRecord`，可以传入指定的`partition`, 那么消息就会发送这个指定的分区。例如partition=0，所有数据写入分区0。

java

复制代码

`// 发送消息到0号分区 kafkaProducer.send(new ProducerRecord<>("first", 0, Integer.toString(i), "hello " + i));`

1.  没有指明`partition`值但有`key`的情况下，将`key`的`hash`值与`topic`的`partition`数进行取余得到`partition`值；

例如：`key1`的`hash`值=5， `key2`的`hash`值=6 ，`topic`的`partition`数=2，那么`key1` 对应的`value1`写入1号分区，`key2`对应的`value2`写入0号分区。

1.  既没有`partition`值又没有`key`值的情况下，Kafka采用`Sticky Partition`（黏性分区器），会随机选择一个分区，并尽可能一直使用该分区，待该分区的`batch`已满或者已完成，`Kafka`再随机一个分区进行使用（和上一次的分区不同）。

例如：第一次随机选择0号分区，等0号分区当前批次满了（默认16k）或者`linger.ms`设置的时间到， `Kafka`再随机一个分区进行使用（如果还是0会继续随机)。

1.  自定义分区器

如果默认的分区规则不满足需求，我们也可以自定义一个分区器。比如我们实现一个分区器实现，发送过来的数据中如果包含 `alvin`，就发往 0 号分区，不包含 `alvin`，就发往 1 号分区。

*  实现分区器接口`Partitioner`

java

复制代码

`/** * 1. 实现接口 Partitioner * 2. 实现 3 个方法:partition,close,configure * 3. 编写 partition 方法,返回分区号 */ public class MyPartitioner implements Partitioner { @Override public int partition(String topic, Object key, byte[] keyBytes, Object value, byte[] valueBytes, Cluster cluster) { // 获取消息 String msgValue = value.toString(); // 创建 partition int partition; // 判断消息是否包含 alvin if (msgValue.contains("alvin")){ partition = 0; }else { partition = 1; } // 返回分区号 return partition; } @Override public void close() { } @Override public void configure(Map<String, ?> configs) { } }`

*  配置分区器

java

复制代码

`// 添加自定义分区器 properties.put(ProducerConfig.PARTITIONER_CLASS_CONFIG, "com.alvin.kafka.producer.MyPartitioner"); // 发送消息 略~~`

#### 如何提高生产者吞吐量？ ####

对比着前面kafka生产者的发送流程，kafka生产者提供的一些配置参数可以有助于提高生产者的吞吐量。

<table> 
 <thead> 
  <tr> 
   <th><strong>参数名称</strong></th> 
   <th><strong>描述</strong></th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td><code>buffer.memory</code></td> 
   <td><code>RecordAccumulator</code> 缓冲区总大小，默认 32m。适当增加该值，可以提高吞吐量。</td> 
  </tr> 
  <tr> 
   <td><code>batch.size</code></td> 
   <td>缓冲区一批数据最大值，默认 16k。适当增加该值，可以提高吞吐量，但是如果该值设置太大，会导致数据传输延迟增加。</td> 
  </tr> 
  <tr> 
   <td><code>linger.ms</code></td> 
   <td>如果数据迟迟未达到 <code>batch.size</code>，<code>sender</code>线程等待 <code>linger.time</code>之后就会发送数据。单位 ms，默认值是 0ms，表示没有延迟。生产环境建议该值大小为 <code>5-100ms</code> 之间。</td> 
  </tr> 
  <tr> 
   <td><code>compression.type</code></td> 
   <td>指定消息的压缩方式，默认值为“<code>none</code> "，即默认情况下，消息不会被压缩。该参数还可以配置为 "<code>gzip</code>"，"<code>snappy</code>" 和 "<code>lz4</code>"。对消息进行压缩可以极大地减少网络传输、降低网络 I/O，从而提高整体的性能 。</td> 
  </tr> 
 </tbody> 
</table>

#### 如何保证生产者消息的可靠性？ ####

为了保证消息发送的可靠性，`kafka` 在 `producer` 里面提供了消息确认机制。我们可以通过配置来决 定消息发送到对应分区的几个副本才算消息发送成功。可以在定义 `producer` 时通过 `acks` 参数指定。

*  acks=0

生产者发送过来的数据，不需要等数据落盘应答。

![format_png 2][]

*  acks=1（默认值）

生产者发送过来的数据，`Leader`收到数据后应答。

![format_png 3][]

*  acks=-1或者all

生产者发送过来的数据，`Leader`和`ISR`队列里面的所有节点收齐数据后应答。

> `ISR` 概念：（同步副本）。每个分区的 `leader` 会维护一个 `ISR` 列表，`ISR` 列表里面就是 `follower` 副本 的 `Borker` 编 号 ， 只 有 跟 得 上 `Leader` 的 `follower` 副 本 才 能 加 入 到 `ISR` 里 面 ， 这 个 是 通 过 `replica.lag.time.max.ms` =30000（默认值）参数配置的，只有 `ISR` 里的成员才有被选为 `leader` 的可能。

![format_png 4][]

**如果**`Leader`**收到数据，所有**`Follower`**都开始同步数据，但有一个**`Follower` **，因为某种故障，迟迟不能与**`Leader`**进行同步，那这个问题怎么解决呢？**

`Leader`维护了一个动态的`in-sync replica set`（`ISR`），意为和`Leader`保持同步的`Follower+Leader`集合`(leader：0，isr:0,1,2)`。如果`Follower`长时间未向`Leader`发送通信请求或同步数据，则该`Follower`将被踢出`ISR`。该时间阈值由`replica.lag.time.max.ms`参数设定，默认`30s`。

**小结：数据完全可靠条件 =** `ACK`**级别设置为-1 + 分区副本大于等于2 + ISR里应答的最小副本数量大于等于2。**

*  `acks=0`，生产者发送过来数据就不管了，可靠性差，效率高；
 *  `acks=1`，生产者发送过来数据`Leader`应答，可靠性中等，效率中等；
 *  `acks=-1或者all`，生产者发送过来数据`Leader`和`ISR`队列里面所有`Follwer`应答，可靠性高，效率低；

在生产环境中，`acks=0`很少使用；`acks=1`，一般用于传输普通日志，允许丢个别数据；`acks=-1`，一般用于传输和钱相关的数据，对可靠性要求比较高的场景。

#### 如何保证消息只发送一次？ ####

kafka作为分布式消息系统，难免会出现重复消息或者丢消息的情况，会存在3种数据传递语义。

*  **最多一次（At Most Once）**

ack级别设置为0, 可以保证数据不重复，但是不能保证数据不丢失, 所以叫做最多一次。

*  **至少一次（At Least Once）**

ack级别设置为-1 + 分区副本大于等于2 + `ISR`里应答的最小副本数量大于等于2可能会出现至少一次的消息。比如下图中在发送过程Leader节点宕机，消息就会重试，就有可能出现消息的重复。

![format_png 5][]

`At Least Once`可以保证数据不丢失，但是不能保证数据不重复。

*  **精确一次（Exactly Once）**

对于一些非常重要的信息，比如和钱相关的数据，要求数据既不能重复也不丢失。这在kafka中可以通过**幂等性和事务**的特性实现。

**精确一次（Exactly Once） = 幂等性 + 至少一次（ ack=-1 + 分区副本数>=2 + ISR最小副本数量>=2） 。**

幂等性，简单来说，就是一个操作重复做，每次的结果都一样。开启幂等性功能，参数`enable.idempotence` 设置为 true即可，在3.x版本中默认情况下也是true。具体实现原理如下：

1.  每一个 `producer` 在初始化时会生成一个 `producer_id`，并为每个目标 `partition` 维护一个“序列号”。
2.  `producer` 每发送一条消息，会将<`producer_id`,分区>对应的“序列号”加 1。
3.  `broker` 服务端端会为每一对`<producer_id,分区>`维护一个序列号，对于每收到的一条消息，会判断服务端 的 `SN_old` 和接收到的消息中的 `SN_new` 进行对比：

*   *  如果 `SN_OLD+1` = `SN_NEW`，正常情况
     *  如果`SN_old+1`>`SN_new`，说明是重复写入的数据，直接丢弃
     *  如果 `SN_old+1`<`SN_new`，说明中间有数据尚未写入，或者是发生了乱序，或者是数据丢失，将抛出严重异常：`OutOfOrderSequenceException`。

#### 如何保证生产者消息的顺序？ ####

根据前面的生产者发送流程可以知道，要想保证消息投递的顺序性：

1.  首先要保证单分区，因为单分区内是有序的，多分区，分区与分区间无序。
2.  kafka在1.x版本之前保证数据单分区有序，条件如下：

*  `max.in.flight.requests.per.connection=1`

1.  kafka在1.x及以后版本保证数据单分区有序，条件如下：

*  未开启幂等性，`max.in.flight.requests.per.connection`需要设置为1。
 *  开启幂等性，`max.in.flight.requests.per.connection`需要设置小于等于5。

因为在kafka1.x以后，启用幂等后，kafka服务端会缓存`producer`发来的最近5个`request`的元数据，故无论如何，都可以保证最近5个`request`的数据都是有序的。

![format_png 6][]

### 总结 ###

本文总结了kafka生产者整个消息发送的流程，只有明白了这个流程以后，那么我们对于一些生产者消息发送的一些问题才有更加深刻的理解。

作者：JAVA旭阳  
链接：https://juejin.cn/post/7236007825733451833

[format_png]: https://img-blog.csdnimg.cn/img_convert/1dc7ca7e8a0f977618e9f7f56656e6cb.webp?x-oss-process=image/format,png
[format_png 1]: https://img-blog.csdnimg.cn/img_convert/31bb81b0a85837ee46fc22f884aa51bd.webp?x-oss-process=image/format,png
[format_png 2]: https://img-blog.csdnimg.cn/img_convert/463390a74527489cea6283ef7a03c744.webp?x-oss-process=image/format,png
[format_png 3]: https://img-blog.csdnimg.cn/img_convert/0a5be3c408534cd57b5cf457377cd84b.webp?x-oss-process=image/format,png
[format_png 4]: https://img-blog.csdnimg.cn/img_convert/7ed0ef38f062f59828f24b9254be59db.webp?x-oss-process=image/format,png
[format_png 5]: https://img-blog.csdnimg.cn/img_convert/de86a83479fc62c752b95f9d4c6cda15.webp?x-oss-process=image/format,png
[format_png 6]: https://img-blog.csdnimg.cn/img_convert/3f6e70dcf4155d75fe722a9e60a68818.webp?x-oss-process=image/format,png