Kafka 数据一致与可靠性保证 (上篇)

前言

​ 作为消息队列能够保证消息的不重复，不丢失，有序性是非常重要的，而 Kafka 就通过一系列机制很好的保证了数据的一致与可靠性，接下来会用两篇博客来整理一下相关内容，本篇主要内容为: ACK应答机制、ISR 以及 producer 端的Exactly-once 语义

ACK 与 ISR

ACK 应答机制

​ 在 TCP/IP 协议中，如果接收方成功的接收到数据，那么会回复一个 ACK (Acknowledge character) 来告诉发送方成功接收到了数据，而如果超过一段时间没有应答 ACK 那么发送方会尝试重发数据。Kafka 的 broker 同样使用 ACK 来向 producer 确认消息成功写入，而由于 kafka 是分布式的因此对于 ACK 的反应与单机的情况有所不同，一般而言判断是否成功写入集群中的多台集群有两种标准：1）集群中超过半数的节点成功写入数据即返回 ACK；2）集群中全部节点成功写入数据才返回 ACK。前者的写入延迟较后者会低，但是如果需要容忍 n 台节点的故障则需要 2n+1 个节点 zookeeper 即采用这种方式，而 Kafka 选择的是后者，只有全部的备份都写入完成后才会返回 ACK 当然写入延迟会交第一种高但是容忍 n 个节点故障只需要 n+1 个节点。

​ 在这种情况下 kafka Producer API 提供了三种 ACK 应答模式：

1. acks = 0: 在此种模式下 producer 不等待 broker 的 ACK 应答，这种情况下延迟最低，但此种模式可能导致数据丢失
2. acks = 1: 此种模式下 producer 会等待 partition 中的 leader 成功写入数据并返回 ACK，但如果 follower 在同步完成前 leader 挂掉了，则会导致数据丢失
3. acks = -1: 此种模式下 producer 会等待 partition 中的 leader 和 follower 全部写入数据并返回 ACK，此种情况下能保证数据的不丢失，但是在 follower 同步完成 而 leader 返回 ACK 之前 leader 挂掉了则会导致数据重复

在实际应用中会根据对数据可靠性的不同要求来选择不同的模式，一般来说 acks = -1 的模式是最多应用的，但是这种情况下也会导致写入延迟较高，尤其是如下这种情况: 同一个 partition 中的其他节点都完成了写入，只有一个 follower 因为某种故障迟迟不能和 leader 完成同步，因此这次写入就一直无法返回 ACK 导致了很大的延迟，下文所介绍的 ISR 即是 kafka 中这一问题的解决方案。

ISR

​ ISR (in-sync replica set) 是 kafka 维护的一个数据同步集合，当 ISR 中的 follower 与 leader 完成数据同步后 leader 就会向 producer 发送 ACK 来确认数据已经成功写入并且在 leader 挂掉后会在 ISR 的 follower 中选举出新的 leader，kafka 通过参数 replica.lag.time.max.ms(默认为 30s) 来控制 ISR 中的 follower，其表示 follower 需要在设定的时间内发送同步请求并追上 leader 的进度，否则会被踢出 ISR。

​ 通过维护动态的 ISR kafka 就只需要等待那些高效的节点成功写入即可返回 ACK 这就改善了前一节说所的情况，ISR 是 kafka 在保证数据可靠性与写入延迟之间所作的权衡设计。

Exactly-once

三种语义

​ 上文提到 producer 通过 broker 返回的 ACK 来判断是否需要重发消息，但是其无法知晓 broker 是因为何种原因或者是何种状况下没有发送 ACK，由此 producer 对此的处理有三种语义：

• at-least-once:

  在 acks = -1 的情况下如果 producer 收到来自 Kafka broker 的 ACK，则表示该消息已经写入到 Kafka。但如果 producer ACK超时或收到错误，则可能会重试发送消息，客户端会认为该消息未写入 Kafka。如果 broker 在发送 ACK之前失败，但在消息成功写入 Kafka 之后&