Kafka生产者：数据可靠性策略与幂等性

目录

 

1. Kafka生产者发送消息的过程

2. 分区策略

3. 数据可靠性保证

---

1. Kafka生产者发送消息的过程

• Kafka 会将发送消息包装为 ProducerRecord 对象， ProducerRecord 对象包含了目标主题和要发送的内容，同时还可以指定键和分区。在发送 ProducerRecord 对象前，生产者会先把键和值对象序列化成字节数组，这样它们才能够在网络上传输。

• 接下来，数据被传给分区器。如果之前已经在 ProducerRecord 对象里指定了分区，那么分区器就不会再做任何事情。如果没有指定分区 ，那么分区器会根据 ProducerRecord 对象的键来选择一个分区，紧接着，这条记录被添加到一个记录批次里，这个批次里的所有消息会被发送到相同的主题和分区上。有一个独立的线程负责把这些记录批次发送到相应的 broker 上。

• 服务器在收到这些消息时会返回一个响应。如果消息成功写入 Kafka，就返回一个 RecordMetaData 对象，它包含了主题和分区信息，以及记录在分区里的偏移量。如果写入失败，则会返回一个错误。生产者在收到错误之后会尝试重新发送消息，如果达到指定的重试次数后还没有成功，则直接抛出异常，不再重试。

2. 分区策略

2.1 分区原因

• 提高并发

• 方便集群中扩展

2.2 分区策略

• 可指定partition；

• 有key值的情况下，将key的hash值与topic的partition数取余；

• 第一次调用随机生成一个整数（后面每次调用时在这个数上自增），再对partition数取余。

3. 数据可靠性保证

为保证 producer 发送的数据，能可靠的发送到指定的 topic， topic 的每个 partition 收到producer 发送的数据后， 都需要向 producer 发送 ack（acknowledgement 确认收到） ，如果producer 收到 ack， 就会进行下一轮的发送，否则重新发送数据。

3.1 三种可靠性级别

• acks=0：producer不等待broker的ack，当broker故障时会丢失数据；

• acks=1：producer等待leader收到数据后返回ack，如果在producer同步完成前leader故障，会丢失数据。

• acks=-1(all)：producer等待partition的leader和所有follower成功同步后返回ack，如果返回ack前故障，会造成数据重复。

3.2 故障处理

LEO（Log End Offset）：每个副本的最后一个offset

HW（High Watermark）：所有副本的最小LEO

3.2.1 follower故障

follower会被踢出isr，恢复后，follower读取本地磁盘记录的上次的HW，并将log文件高于HW的部分截取掉，从HW开始向leader进行同步，等follower的LEO大于等于该partition的HW后，就可以重新加入isr。

3.2.2 leader故障

leader 发生故障之后，会从 ISR 中选出一个新的 leader，之后，为保证多个副本之间的， 数据一致性， 其余的 follower 会先将各自的 log 文件高于 HW 的部分截掉，然后从新的 leader同步数据。

4. Exactly Once 语义（生产时的幂等性）

将服务器的 ACK 级别设置为-1，可以保证 Producer 到 Server 之间不会丢失数据，即 At Least Once 语义。相对的，将服务器 ACK 级别设置为 0，可以保证生产者每条消息只会被发送一次，即 At Most Once 语义。At Least Once 可以保证数据不丢失，但是不能保证数据不重复；相对的， At Least Once可以保证数据不重复，但是不能保证数据不丢失。 但是，对于一些非常重要的信息，比如说交易数据，下游数据消费者要求数据既不重复也不丢失，即 Exactly Once 语义。

在 0.11 版本以前的 Kafka，对此是无能为力的，只能保证数据不丢失，再在下游消费者对数据做全局去重。对于多个下游应用的情况，每个都需要单独做全局去重，这就对性能造成了很大影响。0.11 版本的 Kafka，引入了一项重大特性：幂等性。所谓的幂等性就是指 Producer 不论向 Server 发送多少次重复数据， Server 端都只会持久化一条。幂等性结合 At Least Once 语义，就构成了 Kafka 的 Exactly Once 语义。即：At Least Once + 幂等性 = Exactly Once。

要启用幂等性，只需要将 Producer 的参数中 enable.idompotence 设置为 true 即可。 Kafka的幂等性实现其实就是将原来下游需要做的去重放在了数据上游。

为了实现幂等语义，Kafka引入了Producer ID（即PID）和Sequence Number。每个新的Producer在初始化的时候会被分配一个唯一的PID，该PID对用户完全透明而不会暴露给用户。

对于每个PID，该Producer发送数据的每个<Topic, Partition>都对应一个从0开始单调递增的Sequence Number。

类似地，Broker端也会为每个<PID, Topic, Partition>维护一个序号，并且每次Commit一条消息时将其对应序号递增。对于接收的每条消息，如果其序号比Broker维护的序号（即最后一次Commit的消息的序号）大1，则Broker会接受它，否则将其丢弃：

• 如果消息序号比Broker维护的序号大一以上，说明中间有数据尚未写入，也即乱序，此时Broker拒绝该消息，Producer抛出InvalidSequenceNumber

• 如果消息序号小于等于Broker维护的序号，说明该消息已被保存，即为重复消息，Broker直接丢弃该消息，Producer抛出DuplicateSequenceNumber

上述设计解决了0.11.0.0之前版本中的两个问题：

• Broker保存消息后，发送ACK前宕机，Producer认为消息未发送成功并重试，造成数据重复

• 前一条消息发送失败，后一条消息发送成功，前一条消息重试后成功，造成数据乱序

Kafka的特点和他的存储机制
Kafka高性能的原因——零拷贝机制
Kafka生产者：数据可靠性策略与幂等性
Kafka消费者：分区分配策略，协调器，offset
Kafka：整理的一些面试题