文章目录
- 1. 副本基本信息
- 2. Leader选举流程
- 3. Follower故障
- 4. 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② 查看 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③ 停止掉 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同步数据。
注意：这只能保证副本之间的数据一致性，并不能保证数据不丢失或者不重复。
