关于kafka:Kafka生产者ack机制剖析

Kafka有两个很重要的配置参数，acks与min.insync.replicas .其中acks是producer的配置参数，min.insync.replicas是Broker端的配置参数，这两个参数对于生产者不失落数据起到了很大的作用.接下来，本文会以图示的形式解说这两个参数的含意和应用形式。通过本文，你能够理解到：

• Kafka的分区正本
• 什么是同步正本(In-sync replicas)
• 什么是acks确认机制
• 什么是最小同步正本
• ack=all与最小同步正本是如何发挥作用的

分区正本

Kafka的topic是能够分区的，并且能够为分区配置多个正本，改配置能够通过replication.factor参数实现. Kafka中的分区正本包含两种类型：领导者正本（Leader Replica）和追随者正本（Follower Replica)，每个分区在创立时都要选举一个正本作为领导者正本，其余的正本主动变为追随者正本. 在 Kafka 中，追随者正本是不对外提供服务的，也就是说，任何一个追随者正本都不能响应消费者和生产者的读写申请. 所有的申请都必须由领导者副原本解决. 换句话说，所有的读写申请都必须发往领导者正本所在的 Broker，由该 Broker 负责解决. 追随者正本不解决客户端申请，它惟一的工作就是从领导者正本异步拉取音讯，并写入到本人的提交日志中，从而实现与领导者正本的同步.

Kafka默认的正本因子是3，即每个分区只有1个leader正本和2个follower正本.具体如下图所示：

下面提到生产者客户端仅写入Leader broker，跟随者异步复制数据。因为Kafka是一个分布式系统，必然会存在与 Leader 不能实时同步的危险，所以须要一种办法来判断这些追随者是否跟上了领导者的步调, 即追随者是否同步了最新的数据.换句话说，Kafka 要明确地通知咱们，追随者正本到底在什么条件下才算与 Leader 同步？这就是上面所要说的ISR同步正本机制.

同步正本(In-sync replicas)

In-sync replica(ISR)称之为同步正本，ISR中的正本都是与Leader进行同步的正本，所以不在该列表的follower会被认为与Leader是不同步的. 那么，ISR中存在是什么正本呢？首先能够明确的是：Leader正本总是存在于ISR中. 而follower正本是否在ISR中，取决于该follower正本是否与Leader正本放弃了“同步”.

尖叫提醒：对于”follower正本是否与Leader正本放弃了同步”的了解如下：

(1)下面所说的同步不是指齐全的同步，即并不是说一旦follower正本同步滞后与Leader正本，就会被踢出ISR列表.

(2)Kafka的broker端有一个参数replica.lag.time.max.ms, 该参数示意follower正本滞后与Leader正本的最长工夫距离，默认是10秒. 这就意味着，只有follower正本落后于leader正本的工夫距离不超过10秒，就能够认为该follower正本与leader正本是同步的，所以哪怕以后follower正本落后于Leader正本几条音讯，只有在10秒之内赶上Leader正本，就不会被踢出出局.

（3）如果follower正本被踢出ISR列表，等到该正本追上了Leader正本的进度，该正本会被再次退出到ISR列表中，所以ISR是一个动静列表，并不是动态不变的。

如上图所示：Broker3上的partition1正本超过了规定工夫，未与Leader正本同步，所以被踢出ISR列表，此时的ISR为[1,3].

acks确认机制

acks参数指定了必须要有多少个分区正本收到音讯，生产者才认为该音讯是写入胜利的，这个参数对于音讯是否失落起着重要作用，该参数的配置具体如下：

• acks=0，示意生产者在胜利写入音讯之前不会期待任何来自服务器的响应. 换句话说，一旦呈现了问题导致服务器没有收到音讯，那么生产者就无从得悉，音讯也就失落了. 改配置因为不须要等到服务器的响应，所以能够以网络反对的最大速度发送音讯，从而达到很高的吞吐量。

• acks=1，示意只有集群的leader分区正本接管到了音讯，就会向生产者发送一个胜利响应的ack，此时生产者接管到ack之后就能够认为该音讯是写入胜利的. 一旦音讯无奈写入leader分区正本(比方网络起因、leader节点解体),生产者会收到一个谬误响应，当生产者接管到该谬误响应之后，为了防止数据失落，会从新发送数据.这种形式的吞吐量取决于应用的是异步发送还是同步发送.

  尖叫提醒：如果生产者收到了谬误响应，即使是从新发消息，还是会有可能呈现丢数据的景象. 比方，如果一个没有收到音讯的节点成为了新的Leader，音讯就会失落.

• acks =all,示意只有所有参加复制的节点(ISR列表的正本)全副收到音讯时，生产者才会接管到来自服务器的响应. 这种模式是最高级别的，也是最平安的，能够确保不止一个Broker接管到了音讯. 该模式的提早会很高.

最小同步正本

下面提到，当acks=all时，须要所有的正本都同步了才会发送胜利响应到生产者. 其实这外面存在一个问题：如果Leader正本是惟一的同步正本时会产生什么呢？此时相当于acks=1.所以是不平安的.

Kafka的Broker端提供了一个参数min.insync.replicas,该参数管制的是音讯至多被写入到多少个正本才算是”真正写入”,该值默认值为1，生产环境设定为一个大于1的值能够晋升音讯的持久性. 因为如果同步正本的数量低于该配置值，则生产者会收到谬误响应，从而确保音讯不失落.

Case 1

如下图，当min.insync.replicas=2且acks=all时，如果此时ISR列表只有[1,2],3被踢出ISR列表，只须要保障两个正本同步了，生产者就会收到胜利响应.

Case 2

如下图，当min.insync.replicas=2，如果此时ISR列表只有[1],2和3被踢出ISR列表，那么当acks=all时，则不能胜利写入数；当acks=0或者acks=1能够胜利写入数据.

Case 3

这种状况是很容易引起误会的，如果acks=all且min.insync.replicas=2，此时ISR列表为[1,2,3],那么还是会等到所有的同步正本都同步了音讯，才会向生产者发送胜利响应的ack.因为min.insync.replicas=2只是一个最低限度，即同步正本少于该配置值，则会抛异样，而acks=all，是须要保障所有的ISR列表的正本都同步了才能够发送胜利响应. 如下图所示：

总结

acks=0，生产者在胜利写入音讯之前不会期待任何来自服务器的响应.

acks=1,只有集群的leader分区正本接管到了音讯，就会向生产者发送一个胜利响应的ack.

acks=all,示意只有所有参加复制的节点(ISR列表的正本)全副收到音讯时，生产者才会接管到来自服务器的响应，此时如果ISR同步正本的个数小于min.insync.replicas的值，音讯不会被写入.

公众号『大数据技术与数仓』，回复『材料』支付大数据资料包