Kafka（二）【文件存储机制生产者】

一、Kafka 文件存储机制

二、Kafka 生产者

1、生产者消息发送流程

1.1、发送原理

2、异步发送 API

2.1、普通异步发送

案例演示

2.2、带回调函数的异步发送

2.3、同步发送 API

3、生产者分区

3.1、分区的好处

3.2、生产者发送消息的分区策略

（1）默认的分区器 DefaultPartitioner

3.3、自定义分区器

1）需求

2）实现步骤

4、生产经验

4.1、生产者如何提高吞吐量

4.2、数据可靠性

4.3、数据去重

4.3.1、数据传递语义

4.3.2、幂等性

4.3.3、生产者事务

4.4、数据有序

4.5、数据乱序

一、Kafka 文件存储机制

Kafka中消息是以 topic 进行分类的，生产者生产消息，消费者消费消息，都是面向topic的。

topic 只是逻辑上的概念，而 partition 是物理上的概念。每个partition对应于一个log文件，该 log 文件中存储的就是 producer 生产的数据。Producer生产的数据会被不断追加到该 log 文件末端，且每条数据都有自己的 offset 。消费者组中的每个消费者，都会实时记录自己消费到了哪个offset，以便出错恢复时，从上次的位置继续消费。

由于生产者生产的消息会不断追加到log文件末尾，为防止log文件过大导致数据定位效率低下，Kafka采取了分片和索引机制，将每个 partition 分为多个 segment 。每个 segment 对应两个文件 ——“.index”文件和“.log”文件（一个存储当前文件的索引范围，一个存储真正的数据）。这些文件位于一个文件夹下，该文件夹的命名规则为：topic名称+分区序号。例如，like 这个 topic 有三个分区，则其对应的文件夹为 like-0,like-1,like-2：

00000000000000000000.index
00000000000000000000.log
00000000000000170410.index
00000000000000170410.log
00000000000000239430.index
00000000000000239430.log

这种存储规则很像我们 Spark Shuffle 阶段产生的文件的存储规则，顺便回忆一下 Spark 的 Shuffle 阶段：

Shuffle 过程中每个 Map 任务会产生两个文件，即数据文件和索引文件。其中，数据文件是存储当前 Map 任务的输出结果，而索引文件中则存储了数据文件中的数据的分区信息。下一个阶段的 Reduce 任务就是根据索引文件来获取属于自己处理的那个分区的数据。

其实 Spark 常见的有两种 Shuffle 策略：HashShuffle 和 SortShuffle ，但是这属于 Spark 调优的内容了，现在不必深究。

二、Kafka 生产者

1、生产者消息发送流程

我们知道，Kafka 的三大组成部分：Producer、Broker、Consumer。接下来我们要学习的部分就是 Kafka 的生产者是如何把数据发送给 Kafka 集群（Broker）的。

1.1、发送原理

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

main 线程：

拦截器是可选的（一般用 flume 的拦截器，配置更简单）
序列化器（用的是Kafka自己的序列化器，而不是Java的Serializable，因为Java的序列化器太繁重）
分区器（决定数据往哪个分区存储）
RecordAccumulator 默认 32MB（内存），分区器会把数据发送到这里，一个分区会创建一个队列，方便数据管理（都是在内存中完成的），队列中每份数据的大小（batch.size）默认是16K

sender线程：

只有数据积累到 batch.size 之后，sender 才会发送数据，默认16K
如果队列中的一份数据迟迟满不了（达不到 batch.size），sender 会等待 linger.ms 后发送这份数据，默认是 0ms
NetworkClient：我们发送数据的请求会被放到一个队列（InFlightRequests 队列，通过源码可以看到其底层数据结构Map<String, Deque<ClientRequest>> 以 broker 为 key，队列中放的是一个个发送请求）中去，当第一个请求发出后未得到响应仍然会继续发送第二个请求，但是这个队列的大小默认是 5，也就是说，如果五个请求都发出去后且都没有得到响应，那么就不可以再发出请求，因为默认每个 broker 最多缓存5个请求。
Sender线程通过Selector把上面的请求和数据一起发送到Kafka集群，当数据发送到Kafka集群后，Kafka集群会进行副本的复制并返回对应的acks信息。acks有三种应答级别，分别是ACK=0、ACK=1和ACK=all或ACK=-1（默认级别）。
ACK=0：生产者在消息发送后不会等待来自服务器的任何确认。这意味着生产者无法知道消息是否成功存储在Kafka集群中。这个级别提供了最高的吞吐量，但在可靠性方面是最低的，因为可能会丢失消息。

ACK=1：生产者会等待直到消息的领导者副本（Leader Replica）确认接收到消息。一旦领导者副本存储了消息，生产者会收到一个确认。这个级别在性能和数据可靠性之间提供了一个平衡。但如果领导者副本在确认后发生故障，而消息还未复制到追随者副本（Follower Replicas），则消息可能会丢失。

ACK=all或ACK=-1（默认级别）：生产者会等待消息被所有的同步副本（ISR，In-Sync Replicas）确认。这意味着只有当所有的同步副本都已经接收并存储了消息，生产者才会收到一个确认。这个级别提供了最高的数据可靠性，但可能会牺牲一些性能，因为需要等待所有副本的确认。
如果数据发送成功，就把 InFlighRequests 队列中的请求缓存给清除掉，并且把对应 RecordAccuulator 中的数据清除掉。
如果数据发送失败，会进行重试，重试的次数默认是（Intege.MAX_VALUE），也就是死磕到底，直到发送成功为止。

参数名称	描述
bootstrap.servers	生产者连接集群所需的broker地址清单。例如hadoop102:9092,hadoop103:9092,hadoop104:9092，可以设置1个或者多个，中间用逗号隔开。注意这里并非需要所有的broker地址，因为生产者从给定的broker里查找到其他broker信息。
key.serializer和value.serializer	指定发送消息的key和value的序列化类型。一定要写全类名。
buffer.memory	RecordAccumulator缓冲区总大小，默认32m。
batch.size	缓冲区一批数据最大值，默认16k。适当增加该值，可以提高吞吐量，但是如果该值设置太大，会导致数据传输延迟增加。
linger.ms	如果数据迟迟未达到batch.size，sender等待linger.time之后就会发送数据。单位ms，默认值是0ms，表示没有延迟。生产环境建议该值大小为5-100ms之间。
acks	0：生产者发送过来的数据，不需要等数据落盘应答。 1：生产者发送过来的数据，Leader收到数据后应答。 -1（all）：生产者发送过来的数据，Leader+和isr队列里面的所有节点收齐数据后应答。默认值是-1，-1和all是等价的。
max.in.flight.requests.per.connection	允许最多没有返回ack的次数，默认为5，开启幂等性要保证该值是 1-5的数字。
retries	当消息发送出现错误的时候，系统会重发消息。retries表示重试次数。默认是int最大值，2147483647。如果设置了重试，还想保证消息的有序性，需要设置 MAX_IN_FLIGHT_REQUESTS_PER_CONNECTION=1否则在重试此失败消息的时候，其他的消息可能发送成功了。
retry.backoff.ms	两次重试之间的时间间隔，默认是100ms。
enable.idempotence	是否开启幂等性，默认true，开启幂等性。
compression.type	生产者发送的所有数据的压缩方式。默认是none，也就是不压缩。支持压缩类型：none、gzip、snappy、lz4和zstd。

2、异步发送 API

send 方法有两种传参方式，一种有回调函数，一种不带回调函数。

2.1、普通异步发送

所谓的异步发送指的是外部的数据使用异步的方式吧数据发送到 RecordAccumulator 的内存队列当中去，异步的体现就是外部数据发送到队列中后，并不会等待 RecordAccumulator 把数据传给 Broker 节点并返回成功的消息才继续发送；而是直接把数据扔到 RecordAccumulator 的内存队列后就撒手不管了。

案例演示

导入依赖：

<dependencies>
     <dependency>
          <groupId>org.apache.kafka</groupId>
          <artifactId>kafka-clients</artifactId>
          <version>3.0.0</version>
     </dependency>
</dependencies>

注意：使用 kafka 前必须启动 zookeeper，不然报错无法使用。

public class CustomProducer {

    public static void main(String[] args) {

        Properties properties = new Properties();

        // 连接集群 bootstrap.servers 多写几个主机地址 防止一个客户端挂掉
        properties.put(ProducerConfig.BOOTSTRAP_SERVERS_CONFIG,"hadoop102:9092,hadoop103:9092");

        // 指定对应的 key 和 value 的序列化类型 key.serialize
//        properties.put(ProducerConfig.KEY_SERIALIZER_CLASS_CONFIG,"org.apache.kafka.common.serialization.Serializer");
        // 这两个是等价的
        properties.put(ProducerConfig.KEY_SERIALIZER_CLASS_CONFIG, StringSerializer.class.getName());
        properties.put(ProducerConfig.VALUE_SERIALIZER_CLASS_CONFIG,StringSerializer.class.getName());

        // 1. 创建 Kafka 生产者对象
        // 需要指定键值的类型
        KafkaProducer<String, String> kafkaProducer = new KafkaProducer<>(properties);

        // 2. 发送数据
        for (int i = 0; i < 5; i++) {
            kafkaProducer.send(new ProducerRecord<>("like","test"+i));
        }

        // 3. 关闭资源
        kafkaProducer.close();
    }
}

我们可以看到，一条消息就是一个 ProducerRecord 对象，不管你的消息多么短，哪怕是一个标点，它也会被包装进一个对象里面去。

运行结果：

我们发现，我们的编程步骤和我们上面Kafka的发送原理中生产者的发送步骤是一致的，只不过我们这里没有设置拦截器和分区器，这是一个最简单的 Kafka 生产者程序了。

2.2、带回调函数的异步发送

现在我们来使用带回调函数的异步发送：

只需要修改send方法即可：

    for (int i = 0; i < 5; i++) {
            kafkaProducer.send(new ProducerRecord<>("like", "test" + i), new Callback() {
                @Override
                public void onCompletion(RecordMetadata recordMetadata, Exception e) {
                    if (e == null){ // 如果异常为空 说明正常执行
                        System.out.println("topic: "+recordMetadata.topic()+",partition: "+recordMetadata.partition());
                    }
                }
            });
        }

运行结果：

这种带回调函数的方法可以让我们知道数据更多的元数据信息（比如主题、分区...）。

2.3、同步发送 API

所谓的同步发送，就是外部数据发送到 RecordAccumulator 的内存队列后，必须等待数据被 Selector 发送到 Broker 并返回响应信息才能继续发送。代码的实现很简单，只需要在send方法之后加一个 get() 即可：

for (int i = 0; i < 5; i++) {
      kafkaProducer.send(new ProducerRecord<>("like","test"+i)).get();
}

3、生产者分区

3.1、分区的好处

分区的好处我们太清楚了，之前的 Hadoop、Spark、Flink 都有分区的概念，在 Shuffle 的时候、在 keyBy 的时候，分区的好处显然可以增加并行度，提高我们数据的处理效率；可以负载均衡，不会出现服务器涝的涝死，旱的旱死。

所以，从大数据的存储和计算的角度来看，分区有这么两种好处：

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

3.2、生产者发送消息的分区策略

（1）默认的分区器 DefaultPartitioner

我们可以看到，在初始化 ProducerRecord 时，有 6 种初始化的传参方式：

接下来我们就利用上面的回调函数可以返回数据的元数据信息，来测试一下是不是像它说的这样：

1、指定分区：

for (int i = 0; i < 5; i++) {
            kafkaProducer.send(new ProducerRecord<>("like", 0,"","test" + i), new Callback() {
                @Override
                public void onCompletion(RecordMetadata recordMetadata, Exception e) {
                    if (e == null){ // 如果异常为空 说明正常执行
                        System.out.println("topic: "+recordMetadata.topic()+",partition: "+recordMetadata.partition());
                    }
                }
            });
        }

运行结果：

topic: like,partition: 0
topic: like,partition: 0
topic: like,partition: 0
topic: like,partition: 0
topic: like,partition: 0

面试题：如何把一张 MySQL 表的数据都放到一个 Kafka 的分区当中去?

答：生产者在发送数据时指定数据的分区为表名。

2、不指定分区，只指定 key：

kafkaProducer.send(new ProducerRecord<>("like", ""+i,"test" + i), new Callback() {
                @Override
                public void onCompletion(RecordMetadata recordMetadata, Exception e) {
                    if (e == null){ // 如果异常为空 说明正常执行
                        System.out.println("topic: "+recordMetadata.topic()+",partition: "+recordMetadata.partition());
                    }
                }
            });

我们指定 key 为 i （i 的值为0,1,2,3,4），运行结果：

topic: like,partition: 0
topic: like,partition: 2
topic: like,partition: 2
topic: like,partition: 2
topic: like,partition: 1

3，不指定 partition 也不指定 key。这种方式其实我们上面在学异步发送的时候已经演示过了，它默认会等这一批都满了（16K）或者达到 linger.ms（默认0ms）才会发送。

我们这里在循环的时候，让线程睡眠 2ms，这样就不会因为默认的 linger.ms 太短立即发送，导致数据量太小，发送太快看不出来粘性分区的特点：

for (int i = 0; i < 25; i++) {
            kafkaProducer.send(new ProducerRecord<>("like", ""+i,"test" + i), new Callback() {
                @Override
                public void onCompletion(RecordMetadata recordMetadata, Exception e) {
                    if (e == null){ // 如果异常为空 说明正常执行
                        System.out.println("topic: "+recordMetadata.topic()+",partition: "+recordMetadata.partition());
                    }
                }
            });
            Thread.sleep(2);
        }

运行结果：

topic: like,partition: 0
topic: like,partition: 0
topic: like,partition: 2
topic: like,partition: 2
topic: like,partition: 2
topic: like,partition: 1
topic: like,partition: 1
topic: like,partition: 0
topic: like,partition: 0
topic: like,partition: 2
topic: like,partition: 0
topic: like,partition: 1
topic: like,partition: 1
topic: like,partition: 1
topic: like,partition: 1
topic: like,partition: 0
topic: like,partition: 2
topic: like,partition: 0
topic: like,partition: 1
topic: like,partition: 1
topic: like,partition: 0
topic: like,partition: 1
topic: like,partition: 0
topic: like,partition: 0
topic: like,partition: 1

我们可以看到，粘性分区是这样的：它每次的分区和上一次的分区是不一样的，并且每次的数据尽可能会放到一个分区去。

3.3、自定义分区器

在工作当中，一些特殊场景我们现有的分区策略是无法实现的，这就需要我们自定义来实现分区器了。

1）需求

实现一个分区器，发送过来的数据如果包含 "大傻春" 就发往 0 号分区，否则发往 1 号分区。

2）实现步骤

1. 实现 Partitioner 接口

2. 重写 partition() 方法

public class MyPartitioner implements Partitioner {
    @Override
    public int partition(String topic, Object key, byte[] keyBytes, Object value, byte[] valueBytes, Cluster cluster) {
        String val = value.toString();
        if (val.contains("大傻春"))
            return 0;
        return 1;
    }

    @Override
    public void close() {

    }

    @Override
    public void configure(Map<String, ?> configs) {

    }
}

使用自定义分区器：

// 关联自定义分区器
properties.put(ProducerConfig.PARTITIONER_CLASS_CONFIG,MyPartitioner.class.getName());

KafkaProducer<String, String> kafkaProducer = new KafkaProducer<>(properties);

// 发送数据
for (int i = 0; i < 5; i++) {
    ProducerRecord<String, String> record;
    if (i==3)
        record = new ProducerRecord<>("like", "" + i, "大傻春");
    else
        record = new ProducerRecord<>("like", ""+i,"test" + i);

kafkaProducer.send(record, (RecordMetadata recordMetadata, Exception e)-> {
    if (e == null){ // 如果异常为空 说明正常执行
           System.out.println("topic:"+recordMetadata.topic()+",partition:"+recordMetadata.partition());
       }
    });
}

4、生产经验

4.1、生产者如何提高吞吐量

我们外部的数据是放到 RecordAccumulator 的内存队列当中等待发送的，队列中每份数据的大小（batch.size）默认是16K，但我们知道，如果数据迟迟不能达到 batch.size 的话，会根据默认的配置 linger.ms （默认是 0ms）来发送。但事实上，0ms就意味着不需要数据达到 batch.size 也就是 batch.size 这一配置形同虚设不起作用，也就是只要它察觉到有数据就立即发送，这样的效率其实并不高。

为了提高我们的吞吐量，我们当然需要调整这两个配置的参数大小：

batch.size ：内存队列中每个批次的大小，默认 16K
linger.ms：等待时间，修改为 5-100ms

当然这个参数的值我们需要慎重考虑，就像我们 Flink 当中水位线允许迟到的时间一样，不能说为了保证数据的迟到率最低，就把等待时间设置为几秒，那样 Flink 辛辛苦苦实现的毫秒级延迟有啥用呢。

compression.type：压缩 snappy
RecordAccumulator：缓冲区大小，修改为 64 MB

public class CustomProducerParameters {
    public static void main(String[] args) {

        // 0. 配置信息
        Properties properties = new Properties();
        // 连接 kafka
        properties.put(ProducerConfig.BOOTSTRAP_SERVERS_CONFIG,"hadoop102:9092,hadoop103:9092");
        // key 和 value 的序列化
        properties.put(ProducerConfig.KEY_SERIALIZER_CLASS_CONFIG, StringSerializer.class.getName());
        properties.put(ProducerConfig.VALUE_SERIALIZER_CLASS_CONFIG, StringSerializer.class.getName());

        // batch.size 单位: KB
        properties.put(ProducerConfig.BATCH_SIZE_CONFIG,16384);
        // linger.ms
        properties.put(ProducerConfig.LINGER_MS_CONFIG,1);
        // 压缩
        properties.put(ProducerConfig.COMPRESSION_TYPE_CONFIG,"snappy"); //默认none，可配置值gzip、snappy、lz4和zstd
        // 缓冲区大小
        properties.put(ProducerConfig.BUFFER_MEMORY_CONFIG,33554432*2); // 修改为64MB

        // 1. 创建生产者
        KafkaProducer<String, String> kafkaProducer = new KafkaProducer<String, String>(properties);

        // 2. 发送数据
        for (int i = 0; i < 5; i++) {
            kafkaProducer.send(new ProducerRecord<>("like","value"+i));
        }

        // 3. 关闭资源
        kafkaProducer.close();
    }
}

4.2、数据可靠性

数据的可靠性，指的其实就是当 Selector 把数据发送到 Broker 之后，是否等待响应（ack）之后再发送数据。

我们知道，ack 的值有三种：

ack = 0：发送完直接走，不用等响应，可靠性差，但是效率高。（一般不用）
ack = 1：发送完需要等待 leader 节点响应才能继续发送下一个数据，可靠性中等，效率中等。
ack = -1：发送完需要等待所有节点（leader 和其他 fllower）响应才能继续发送下一个数据。可靠性高，效率低。

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

完全可靠性在这种情况下尽管概率特别低，但是仍然不能排除，我们会在下面的数据去重去学习。

代码中配置 ACK 级别：

// acks
properties.put(ProducerConfig.ACKS_CONFIG,"1");
// 重试次数
properties.put(ProducerConfig.RETRIES_CONFIG,3);

4.3、数据去重

4.3.1、数据传递语义

就像我们 Flink 中的时间语义，Kafka 生产者也有它的数据传递语义：

至少一次（At least once）= ACK级别设置为1 + 分区副本大于等于2 + ISR里应答的最小副本数大于等于2
最多一次（At most once）= ACK级别设置为0
总结：
- Al least once 可以保证数据不丢失，但是不能保证数据不重复；
- At most once 可以保证数据不重复，但是不能保证数据不丢失。
精确一次（Exactly once）：对于一些非常重要的信息，比如和钱相关的数据，要求数据既不能重复也不能丢失。

Kafka 0.11 版本后，引入了一个重要的特性：幂等性和事务。

4.3.2、幂等性

幂等性就是指 Producer 不论向 Broker 发送多少次重复数据，Broker 端都只会持久化一条，保证了不重复。
精确一次（Exactly once）= 幂等性 + 至少一次（ack = -1 + 分区副本数 >= 2 + ISR 最小副本数 >= 2）

重复数据的判断标准就是数据的三个属性必须唯一（PID、Partition、SeqNumber），其中 PID 是 Kafka 每次启动自动生成的，Partition是分区号，SeqNumber 是一个单调递增的数。

幂等性只能保证数据在单分区内不会重复。

配置幂等性

enable.idempotence 默认就是 true，flase 关闭。

4.3.3、生产者事务

我们知道，幂等性只能保证数据在单分区内不会重复，但是还是不能保证绝对的唯一，比如 Kafka 挂掉了需要重启，那么重启之后之前数据的 PID 就失效了，所以当有重复的数据时，并不能识别出来。这就需要事务的方式来解决了。

说明：开启事务必须开启幂等性。

其实，Kafka 实现精确一次的保证机制和我们 Flink 在保证端到端一致性时输出端的保证方式是很相似的（幂等写入和事务写入）

Kafka 的事务一共如下 5 个 API：

// 1初始化事务
void initTransactions();

// 2开启事务
void beginTransaction() throws ProducerFencedException;

// 3在事务内提交已经消费的偏移量（主要用于消费者）
void sendOffsetsToTransaction(Map<TopicPartition, OffsetAndMetadata> offsets,
                              String consumerGroupId) throws ProducerFencedException;

// 4提交事务
void commitTransaction() throws ProducerFencedException;

// 5放弃事务（类似于回滚事务的操作）
void abortTransaction() throws ProducerFencedException;

测试：

public class CustomProducerTransaction {

    public static void main(String[] args) {

        Properties properties = new Properties();

        // 连接集群 bootstrap.servers 多写几个主机地址 防止一个客户端挂掉
        properties.put(ProducerConfig.BOOTSTRAP_SERVERS_CONFIG,"hadoop102:9092,hadoop103:9092");

        // 指定对应的 key 和 value 的序列化类型 key.serialize
//        properties.put(ProducerConfig.KEY_SERIALIZER_CLASS_CONFIG,"org.apache.kafka.common.serialization.Serializer");
        // 这两个是等价的
        properties.put(ProducerConfig.KEY_SERIALIZER_CLASS_CONFIG, StringSerializer.class.getName());
        properties.put(ProducerConfig.VALUE_SERIALIZER_CLASS_CONFIG,StringSerializer.class.getName());

        // 指定事务id
        properties.put(ProducerConfig.TRANSACTIONAL_ID_CONFIG,"transaction_id_01");

        // 1. 创建 Kafka 生产者对象
        // 需要指定键值的类型
        KafkaProducer<String, String> kafkaProducer = new KafkaProducer<>(properties);

        kafkaProducer.initTransactions();

        kafkaProducer.beginTransaction();

        try {
            // 2. 发送数据
            for (int i = 0; i < 5; i++) {
                kafkaProducer.send(new ProducerRecord<>("like","test"+i));
            }
            kafkaProducer.commitTransaction();
        }catch (Exception e){
            kafkaProducer.abortTransaction();   // 终止事务
        }finally {
            // 3. 关闭资源
            kafkaProducer.close();
        }
    }
}

注意：一定要记得手动指定事务id（保证唯一）。我们要把发送数据的代码写进 try-catch 中，如果有异常那么久终止事务。

4.4、数据有序

数据有序的保证一直是流处理领域的一个问题，就像我们的 Flink 通过水位线和Barrier 对齐算法保证数据容错和有序性。我们 Kafka 中也是一样的，单分区的话我们数据当然是有序的，但因为是多分区，所以分区和分区间的数据不能保证哪个数据先被读取，所以说分区间数据的顺序是无序的。

至于多分区要做到有序，可以把每个分区的数据在消费者这里进行排序，但是这样的效率不是很高，所以我们 Kafka 一般都是只保证单分区有序，个人认为，Kafka只要做到数据的尽量有序就可以了，反正Kafka的数据到下游传递时，一般也都是并行读取，比如 Flink 读取 Kafka 的数据就支持多个 Sink 算子，所以数据到了 Flink 的多个算子链里会出现乱序。

单分区内数据有序，但是不一定发送过去仍然是有序的，这就需要给它增加一些条件了，也就是接下来要学习的用幂等性解决数据乱序。

4.5、数据乱序

Kafka 1.x 版本之后保证数据单分区有序的条件：

未开启幂等性
- max.in.flight.requests.per.connection 设置为 1（相当于 NetworkClient 中只能存在一个请求，那数据肯定是有序的，都不要使用幂等性）
开启幂等性
- max.in.flight.requests.per.connection 需要设置为 <= 5（启用幂等性之后，Kafka 服务端会缓存最近的 5 个request元数据，所以无论如何，都可以保证最近的5个request的数据都是有序的。而且这个配置的值不能>5，因为Kafka服务端最多缓存5个请求）

解释：

为什么一定可以保证单分区内数据有序呢，因为幂等性就是（ProducerID，Partition，SeqNumber），其中 SeqNumber 要保证单调递增，对应我们的request，如果生产者的 RecoedAccumulator 中某个broker对应的请求队列中 request1和 request2 发送成功，但是request3 却失败了，那么当然会去重试，但是此时request4和request5也发送过去了怎么办。因为我们开启了幂等性，所以当 request1和request2 发送到Kafka的服务端（broker）之后，因为它们是不重复且有序的，所以会立即落盘，但是我们的 request3 由于发送失败，此时 request4和request5又发送过来了，但是由于 request4 和 request5 并不满足幂等性要求，所以不会落盘，而是留在内存当中，所以只有当 request3 再次到来之后，满足幂等性并落盘之后，request4和request5才能落盘。