kafka学习笔记（一）--脑裂_kafka脑裂

我知道你想裂，但你先别裂

脑裂

用集群部署的大多数的分布式系统无可避免会面临脑裂问题。简单来说，脑裂就是在同一时刻出现了两个“Leader（或叫Master）”。设想这样一个场景：某分布式系统的分别部署在A，B两机房，每个机房有若干个节点。在正常情况下，这个分布式系统通过一致性协议（如 Paxos 或 Raft）来选举出一个 Leader，所有的读写请求都会通过 Leader 进行处理，副本们同Leader保持一致，确保数据的一致性。

假设一天出现了某种故障，A 机房和 B 机房之间的通信中断，且Leader丢失。这时，A 机房和 B 机房的节点可能会各自进行Leader选举，导致出现两个 Leader。这就是脑裂现象。

此时，如果多个不同区域的客户端向系统发送请求，根据就近路由的原则，用户可能向A机房的 leader 发送写请求，也可能向 B 机房的 leader 发送写请求，那么这两个请求可能会导致系统状态不一致。

Kafka脑裂实验

通过制造网络分区实现脑裂场景，观察kafka做了些什么

1. 准备一个kafka实例，包含三个broker（brokerA，brokerB，brokerC）；
2. 在kafka中创建一个Topic，设置副本数为3，min.insync.replicas=1，随意生产几条消息，确认集群正常运行；
   
3. 查看Isr，找到Leader hostip

./kafka-topics.sh --describe --zookeeper <zk ip>:<port>  --topic <topic>
./zookeeper-shell.sh <zk ip>:<port> get /brokers/ids/<leader id>
1
2

4. 制造网络分区：将Leader副本与其他Follower副本之间的网络连接断开。自建kafka集群可以通过修改iptables实现（此操作会造成节点之间网络不通，请谨慎操作）：

# 在Leader上执行以下命令（假设是A），阻止与B和C之间的通信
iptables -A INPUT -s <broker_B_IP> -j DROP
iptables -A OUTPUT -d <broker_B_IP> -j DROP
iptables -A INPUT -s <broker_C_IP> -j DROP
iptables -A OUTPUT -d <broker_C_IP> -j DROP
1
2
3
4
5

5. 生产几条消息，查看Isr

./kafka-topics.sh --describe --zookeeper <zk ip>:<port>  --topic <topic>
1

这里有两种可能：

• A节点被排除在ISR之外：leader发生变化。在这种情况下，ISR只包含B、C节点。

• B、C节点被排除在ISR之外：由于B、C节点无法与A节点进行通信，它们可能会落后于A节点，导致B、C节点被排除在ISR之外。在这种情况下，ISR只包含A节点。

8. 恢复网络连接

iptables -D INPUT -s <broker_B_IP> -j DROP
iptables -D OUTPUT -d <broker_B_IP> -j DROP
iptables -D INPUT -s <broker_C_IP> -j DROP
iptables -D OUTPUT -d <broker_C_IP> -j DROP
1
2
3
4

9. 在网络连接恢复后，Kafka集群将自动恢复正常状态。ISR列表又重新包含了A，B，C三个节点。

Kafka如何防止脑裂–Leader Epoch

鉴于kafka的副本选举机制，kafka也会面临脑裂问题。为了解决脑裂，kafka从0.11.0.0开始引入Leader Epoch的概念。
epoch是一个递增的整数。每当一个当新的leader被选举出来时，epoch都会+1。kafka的所有副本都会维护一个leader-epoch-checkpoint的文件，当eppch发生更新时，kafka会将矢量<LeaderEpoch => StartOffset> 追加到这个文件中，其中StartOffset表示当前的epoch下写入第一条消息的偏移量。副本在同步数据时，会将自己最新的epoch值一同发送给leader。leader收到follower的请求后，会检查请求中的epoch值。如果请求中的epoch值与当前leader的epoch值一致，说明follower与leader之间的同步关系符合预期，leader会接受follower的请求，将自己的数据复制给follower。如果请求中的epoch值小于当前leader的epoch值，说明follower已经过时，leader会拒绝follower的请求，并更新follower的epoch值。

# 查看leader-epoch-checkpoint
# broker ip
tail -f /kafka-logs/<your—topic-partition>/leader-epoch-checkpoint
0
1
1
2
3
4
5

此外，在查看leader-epoch-checkpoint的时候可能会注意到replication-offset-checkpoint 文件。这个文件记录了follower副本已经成功同步的各个主题分区的Offset信息。当follower副本重新启动或发生故障恢复时，会根据这个文件从正确的位置继续同步数据。
leader-epoch-checkpoint和replication-offset-checkpoint文件在Kafka中分别负责管理leader副本和follower副本的状态信息。它们之间的关系在于它们共同参与了Kafka副本同步和故障恢复的过程，确保了Kafka集群在面临故障时能够正确地恢复状态，保证数据的一致性和可靠性。

epoch的局限性

Kafka利用epoch机制确保了在leader发生变更时，follower副本能够及时更新自己的状态，避免了脑裂问题。在leader切换的过程中，可能会出现数据不一致的情况，这种方法在某种程度上牺牲了一致性。

如何将不一致性带来的损失降到最低?
-用ISR

ISR列表

ISR（In-Sync Replicas）列表包含了分区的leader副本和已经成功同步了leader副本数据的follower副本。当选举发生时，新的leader会从ISR列表中选举出来，这样可以确保新的Leader拥有最新的数据，从而保证数据的一致性。

# 查看ISR列表
./kafka-topics.sh --describe --zookeeper <zookeeper_host>:<zookeeper_port> --topic <topic_name>
# ./kafka-topics.sh --describe --zookeeper localhost:15028 --topic topic0
Topic:topic0    PartitionCount:1        ReplicationFactor:3     Configs:retention.ms=43200000,cleanup.policy=delete,min.insync.replicas=1,max.message.bytes=1000012,retention.bytes=-1
        Topic: topic0   Partition: 0    Leader: 2       Replicas: 2,1,0 Isr: 2,1,0
# 其中，Isr字段表示ISR列表，包含了当前分区的Leader副本和已经成功同步了Leader副本数据的Follower副本。该分区的副本包括节点 2、1、0，目前处于同步复制（In-Sync Replica）状态的副本有节点 2、1、0。
# 针对该主题的一些配置包括保留时间为 43200000 毫秒、清理策略为删除、最小副本数为 1，最大消息字节数为 1000012，保留字节数为 -1
1
2
3
4
5
6
7

当Leader接收到客户端的写入请求后，它会将数据写入本地日志，并将数据发送给所有的Follower副本。当follower副本成功写入数据后，它会向Leader发送ACK确认。当leader收到ISR列表中的所有follower副本的ack后，它会认为写入操作成功完成，并向客户端返回成功响应。

当某个副本无法及时同步leader的数据时，它会被从ISR列表中移除转为OSR（Out-of-Sync Replicas）。当该副本恢复正常并成功同步了Leader的数据后，再将它重新加入到ISR列表中。

ISR列表的伸缩机制

• 此部分内容多数引用《深入理解Kafka：核心设计与实践原理 2019》第八章，朱忠华老师的这本书确确实实声明：本文内容由网友自发贡献，不代表【wpsshop博客】立场，版权归原作者所有，本站不承担相应法律责任。如您发现有侵权的内容，请联系我们。转载请注明出处：https://www.wpsshop.cn/w/2023面试高手/article/detail/142654