人生第一份工作■Kafka架构原理，也就这么回事( 三 ) |美好，一直在身边|大数据|

数据可靠性保证
为保证 Producer 发送的数据，能可靠地发送到指定的 Topic ， Topic 的每个 Partition 收到 Producer 发送的数据后，都需要向 Producer 发送 ACK(ACKnowledge 确认收到) 。
如果 Producer 收到 ACK ，就会进行下一轮的发送，否则重新发送数据。

本文插图
①副本数据同步策略
何时发送 ACK?确保有 Follower 与 Leader 同步完成， Leader 再发送 ACK ，这样才能保证 Leader 挂掉之后，能在 Follower 中选举出新的 Leader 而不丢数据。
多少个 Follower 同步完成后发送 ACK?全部 Follower 同步完成，再发送 ACK 。

本文插图
②ISR
采用第二种方案，所有 Follower 完成同步， Producer 才能继续发送数据，设想有一个 Follower 因为某种原因出现故障，那 Leader 就要一直等到它完成同步。
这个问题怎么解决?Leader维护了一个动态的 in-sync replica set(ISR)：和 Leader 保持同步的 Follower 集合。
当 ISR 集合中的 Follower 完成数据的同步之后， Leader 就会给 Follower 发送 ACK 。
如果 Follower 长时间未向 Leader 同步数据，则该 Follower 将被踢出 ISR 集合，该时间阈值由 replica.lag.time.max.ms 参数设定。 Leader 发生故障后，就会从 ISR 中选举出新的 Leader 。
③ACK 应答机制
对于某些不太重要的数据，对数据的可靠性要求不是很高，能够容忍数据的少量丢失，所以没必要等 ISR 中的 Follower 全部接受成功。
所以 Kafka 为用户提供了三种可靠性级别，用户根据可靠性和延迟的要求进行权衡，选择以下的配置。

本文插图
Ack 参数配置：

0：Producer 不等待 Broker 的 ACK ，这提供了最低延迟， Broker 一收到数据还没有写入磁盘就已经返回，当 Broker 故障时有可能丢失数据。
1：Producer 等待 Broker 的 ACK ， Partition 的 Leader 落盘成功后返回 ACK ，如果在 Follower 同步成功之前 Leader 故障，那么将会丢失数据。
-1(all)：Producer 等待 Broker 的 ACK ， Partition 的 Leader 和 Follower 全部落盘成功后才返回 ACK 。但是在 Broker 发送 ACK 时， Leader 发生故障，则会造成数据重复。

④故障处理细节

本文插图
LEO：每个副本最大的 Offset 。 HW：消费者能见到的最大的 Offset ， ISR 队列中最小的 LEO 。
Follower 故障：Follower 发生故障后会被临时踢出 ISR 集合，待该 Follower 恢复后， Follower 会读取本地磁盘记录的上次的 HW ，并将 log 文件高于 HW 的部分截取掉，从 HW 开始向 Leader 进行同步数据操作。
等该 Follower 的 LEO 大于等于该 Partition 的 HW ，即 Follower 追上 Leader 后，就可以重新加入 ISR 了。
Leader 故障：Leader 发生故障后，会从 ISR 中选出一个新的 Leader ，之后，为保证多个副本之间的数据一致性，其余的 Follower 会先将各自的 log 文件高于 HW 的部分截掉，然后从新的 Leader 同步数据。
注意：这只能保证副本之间的数据一致性，并不能保证数据不丢失或者不重复。
Exactly Once 语义
将服务器的 ACK 级别设置为 -1 ，可以保证 Producer 到 Server 之间不会丢失数据，即 At Least Once 语义。