【Kafka技术内幕】（三）：Kafka生产者：高可用Producer和ISR机制

我是少侠露飞。学习塑造人生，技术改变世界。

引言

上一篇我们介绍了Kafka的基本概念及工作流程，附传送门👇
【Kafka技术内幕】（二）：Kafka简介
本节我们将侧重介绍Kafka的Producer，即生产者，将介绍Kafka是如何发送消息的，以及如何保证消息发送过程的可靠性的。

1 Producer的分区策略

说到Kafka的生产者，首先要想到的就是Producer的分区策略，为何要分区呢，大概有两点原因：

1. 提高了消息队列在集群中的扩展性，一个Topic可以有多个Partition组成。
2. 可以提高并发量，因为可以按照Partition为单位进行读写了。

那么Producer在发送消息的时候如何指定Partition呢？
所有要分区的数据都会被封装成一个ProducerRecord对象。然后会按照如下规则进行分区：

• 指明partition时，直接将该值作为partition值。
• 若未指明，但是有key的情况下，将key的hash值与该topic下可用的分区数取余得到partition值。
• 若既未指明partition，也没有key时，在第一次调用时随机生成一个整数（后续每次调用都会在这个整数上自增），将该整数与topic下可用的分区数取余得到partition值，也就是常说的round-robin算法。

2 Producer的可靠性

生产者唯一的职责就是发送消息，但是既然有发送，可能就会出现消息丢失，那么Kafka是如何保证消息的不丢失呢？
Kafka为了保证数据的可靠性，在生产者层面做了两个实现，一是在存储层面，即为每个partition设置了副本，分leader和follower，发送的时候只发送到leader上，然后leader将消息数据同步到follower；二是在发送层面，Kafka要求只有当leader回复了ack确认收到之后才会完成该条消息的投递，否则会重试。

2.1 Producer的ISR机制

如下图所示，生产者把消息发送到服务器上的leader上，然后leader将消息同步给自己的所有follower。

Kafka默认当所有follower都完成同步消息后再返回给生产者ack。但考虑这样一种场景，当leader有若干个follower，其中每次同步的时候都有一个follower因为故障，迟迟不能与leader完成同步，那么leader就要一直等下去。这个问题如何解决呢？
事实上，leader通过一个同步副本ISR（in-sync replica set）机制解决了这个难题。ISR意味着和leader保持同步的follower集合，当follower从leader完成同步消息之后，leader就会向follower发送ack，如果follower长时间没有响应ack，则会被剔除ISR，该时间阈值由replica.lag.time.max.ms指定（默认10s）。当leader宕机之后，则会从ISR中选举出新的leader。

事实上，在更老版本的Kafka里，导致follower被踢出ISR，除了响应时间，还有和leader的差异信息条数。但是现在差异条数已经被取消了，原因主要是Kafka是按批次发送消息，假设一批次大小是12，然后差异条数的阈值是10，这样每次生产者给leader发送消息都会导致follower被踢出ISR，然后follower完成同步之后，又被重新选进ISR，这样往复很消耗Kafka和ZK的性能。

2.2 Producer的ACK机制

现在我们已经知道生产者发送消息有个确认的机制，那么Kafka里是何时确认呢？Kafka是通过配置acks的值确认机制的，这里一共提供了三种情况，对应不同的ACK机制：

1. acks=0，生产者不等待broker的响应。这种情况下延迟最低，但是有可能丢失数据，比较适合高吞吐量、接受消息丢失的场景。
2. acks=1，生产者发送消息等待broker的响应，等待leader落盘成功后响应确认。这种情况下，如果是在leader完成同步消息给follower前发生故障，则可能发生消息丢失。
3. acks=-1，生产者发送消息等待broker的响应，直到leader和follower全部落盘成功后才会响应确认。此机制能严格保证不丢失数据。但当所有的follower同步完成之后，leader发送ack响应之前，leader发生了宕机，此时生产者会以为发送失败了，然后会重新发送数据给新的leader，因此该情况下会导致数据重复发送。

3 Producer的数据一致性

Kafka里数据有副本，那么必然会出现leader和follower不一致的情况，那么Kafka又是如何保证数据一致性的呢？如下图所示，这里先介绍两个概念：

• LEO：Log end offset，即每个副本中的最后一个offset。
• HW：High Watermark，所有副本中最小的LEO。
  

1. follower故障
   此时follower会被临时踢出ISR，待到恢复时，会读取本地磁盘里的HW，将log文件里高于HW的消息截断掉并从leader开始同步数据，直到follower赶上leader时会重新加入ISR。
2. leader故障
   此时会从ISR选举出新的leader，然后会将所有副本里的log文件高于HW的消息截断，从新的leader重新同步数据。

注意，LEO和HW是保证数据一致性的机制，并不能保证数据不丢失或者数据不重复。

4 Producer的ExactlyOnce

聊完上面的，相信大家对Kafka生产者的可靠性、数据一致性有了一定的认识。这里再抛出一个比较深入的问题：Kafka能保证ExactlyOnce（即精准一次性）么，如果能，又是如何保证呢？
实际上，在交易业务里，对于精准一次性要求是比较高的，我们绝不能丢失交易数据，也不应该发起重复交易，这就是ExactlyOnce语义。
Kafka本身可以保证两种语义，根据上面的ack机制，我们可以明显的得到：当ack=0时，消息可能丢失，此时对应的是At most once语义；当ack=-1时，消息不会丢失但可能重复消费，此时对应的At least once语义。此时我们应该想到，要想保证ExactlyOnce，应该在At least once语义的基础上保证幂等性即可。

幂等性：用户对于同一操作发起的一次请求或者多次请求的结果是一致的，不会因为多次点击而产生了副作用。

但Kafka如何保证消息发送的幂等性呢？
Kafka在0.11新增的功能，对于每个producer会分配一个唯一 的PID，发往同一个broker的消息会附带一个Sequence Number，broker端会对<PID,partitionId,Sequence Number>做一个缓存，当具有相同主键的消息提交时，Kafka只会持久化一条。

但是PID会随着生产者重启而发生变化，并且不同的partition对应的partitionId也不相同，所以Kafka的幂等性无法保证跨会话、跨分区的ExactlyOnce。

点点关注，不会迷路