Kafka - 09 Kafka副本 | Leader选举流程 | Follower故障 | Leader故障

1. 副本基本信息

1）Kafka 副本作用：提高数据可靠性。

2）Kafka 默认副本 1 个，生产环境一般配置为 2 个，保证数据可靠性；太多副本会增加磁盘存储空间，增加网络上数据传输，降低效率。

3）Kafka 中副本分为：Leader 和 Follower。Kafka 生产者只会把数据发往 Leader，然后 Follower 找 Leader 进行同步数据。

4）Kafka 分区中的所有副本统称为 AR（Assigned Repllicas）。

• AR = ISR + OSR
• ISR，表示和 Leader 保持同步的 Follower 集合。如果 Follower 长时间未向 Leader 发送通信请求或同步数据，则该 Follower 将被踢出 ISR。该时间阈值由 replica.lag.time.max.ms 参数设定，默认 30s。Leader 发生故障之后，就会从 ISR 中选举新的 Leader。
• OSR，表示 Follower 与 Leader 副本同步时，延迟过多的副本。

2. Leader选举流程

Partition：为了实现扩展性，一个非常大的 topic 可以分布到多个 broker 上，一个 topic 可以分为多个 partition， 如 TopicA主题内有3个分区 partition0~partition2 分别分布在 broker0~broker2 上。

Replication：为保证集群中的某个节点发生故障时， 该节点上的 partition数据不丢失 ， 且 kafka 仍然能够继续工作， kafka提供了副本机制，一个 topic 的每个分区都有若干个副本，一个 leader 和若干个 follower，并且leader 和 follower 需要分布在不同的服务器上。

Kafka 集群中有一个 broker 的 Controller 会被选举为 Controller Leader，负责管理集群 broker 的上下线，所有 topic 的分区副本分配和 Leader 选举等工作。Controller 的信息同步工作是依赖于 Zookeeper 的。

选举流程：

① kafka每启动一个节点就会在zookeeper中注册一个节点信息，每一个broker节点都有对应的Controller，他们会争先抢占Controller的注册，谁先注册谁会被选举为 Controller Leader。

② 选举出来的 Controller 会监听 brokers 节点变化，决定 Leader 的选举，将节点信息上传到 zookeeper，其他Contorller 就会从 zookeeper 同步相关信息。

③ 假设 Broker1 中 Leader 挂了，Controller 就会监听到节点变化，然后获取到 ISR，选举新的 Leader（在 ISR 中存活为前提，按照 AR 中排在前面的优先），更新 Leader 及 ISR。

利用4台服务器 hadoop101、hadoop102、hadoop103、hadoop104 来验证以上整个流程 ：

① 创建一个新的 topic，4 个分区，4 个副本：

[root@hadoop101 kafka_2.12-2.2.1]# bin/kafka-topics.sh --bootstrap-server hadoop101:9092 --create --topic test3 --partitions 4 --replication-factor 4
1

② 查看 Leader 分布情况：

[root@hadoop101 kafka_2.12-2.2.1]# bin/kafka-topics.sh --bootstrap-server hadoop101:9092 --describe --topic test3
Topic: test3  PartitionCount:4  ReplicationFactor:4  Configs:segment.bytes=1073741824
Topic: test3    Partition: 0    Leader: 0       Replicas: 0,2,3,1       Isr: 0,2,3,1
Topic: test3    Partition: 1    Leader: 2       Replicas: 2,3,1,0       Isr: 2,3,1,0
Topic: test3    Partition: 2    Leader: 3       Replicas: 3,1,0,2       Isr: 3,1,0,2
Topic: test3    Partition: 3    Leader: 1       Replicas: 1,0,2,3       Isr: 1,0,2,3
1
2
3
4
5
6

③ 停止掉 hadoop103 的 kafka 进程，并查看 Leader 分区情况：

Partition为2的分区有4个副本，其中 Leader为3，假如 hadoop104 挂掉了，那么Partition为2 的Leader 就会重新选举，选举的规则为：在 ISR 中存活为前提，按照AR中排在前面的优先，即新的Leader将是1。

④ 停止掉 hadoop103 的 kafka 进程，并查看 Leader 分区情况：

Partition为1的分区有4个副本，其中 Leader为2，假如 hadoop103 挂掉了，那么Partition为2 的Leader 就会重新选举，选举的规则为：在 ISR 中存活为前提，按照AR中排在前面的优先，即新的Leader将是1。

⑤ 启动 hadoop104 的 kafka 进程，并查看 Leader 分区情况：

⑥ 启动 hadoop104 的 kafka 进程，并查看 Leader 分区情况：

⑦ 停止掉 hadoop102 的 kafka 进程，并查看 Leader 分区情况：

可以看到选举是按照AR中的顺序轮询选举的，而不是ISR中的顺序。

3. Follower故障

LEO（Log End Offset）：每个副本的最后一个offset，LEO其实就是最新的 offset + 1。

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

Follower故障：

① Follower发生故障后会被临时踢出ISR

② 这个期间Leader和Follower继续接收数据

③ 待该Follower恢复后，Follower会读取本地磁盘记录的上次的HW，并将log文件高于HW的部分截取掉，从HW开始向Leader进行同步。

④ 等该Follower的LEO大于等于该Partition的HW，即Follower追上Leader之后，就可以重新加入ISR了。

4. Leader故障

LEO（Log End Offset）：每个副本的最后一个offset，LEO其实就是最新的 offset + 1。

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

Leader故障：

① Leader发生故障之后，会从ISR中选出一个新的Leader

② 为保证多个副本之间的数据一致性，其余的Follower会先将各自的log文件高于HW的部分截掉，然后从新的Leader同步数据。

注意：这只能保证副本之间的数据一致性，并不能保证数据不丢失或者不重复。