阿雷网站建设,海口网球场,免费版权申请入口,专业网站设计速寻亿企邦我知道你想裂#xff0c;但你先别裂
脑裂
用集群部署的大多数的分布式系统无可避免会面临脑裂问题。简单来说#xff0c;脑裂就是在同一时刻出现了两个“Leader#xff08;或叫Master#xff09;”。设想这样一个场景#xff1a;某分布式系统的分别部署在A#xff0c;B…我知道你想裂但你先别裂
脑裂
用集群部署的大多数的分布式系统无可避免会面临脑裂问题。简单来说脑裂就是在同一时刻出现了两个“Leader或叫Master”。设想这样一个场景某分布式系统的分别部署在AB两机房每个机房有若干个节点。在正常情况下这个分布式系统通过一致性协议如 Paxos 或 Raft来选举出一个 Leader所有的读写请求都会通过 Leader 进行处理副本们同Leader保持一致确保数据的一致性。
假设一天出现了某种故障A 机房和 B 机房之间的通信中断且Leader丢失。这时A 机房和 B 机房的节点可能会各自进行Leader选举导致出现两个 Leader。这就是脑裂现象。
此时如果多个不同区域的客户端向系统发送请求根据就近路由的原则用户可能向A机房的 leader 发送写请求也可能向 B 机房的 leader 发送写请求那么这两个请求可能会导致系统状态不一致。
为了解决脑裂问题分布式系统通常会采取以下策略 引入协调服务使用 zooKeeper 作为第三方协调服务来管理 Leader 选举和节点状态。 采用一致性算法通过使用 Paxos、Raft 等一致性算法系统可以在网络分区发生时保证只有一个 Leader 被选举出来。这些算法通常要求选举过程中获得超过半数节点的支持以确保 Leader 的唯一性。 降低系统可用性根据 CAP ConsistencyAvailabilityPartition tolerance定理在保证分区容错性的前提下分布式系统必须在一致性和可用性之间做出选择。为了避免脑裂问题系统可以牺牲部分可用性例如拒绝处理写请求。 使用租约机制分布式系统中的 Leader 可以通过租约Lease机制来确保其地位。Leader 需要在租约期限内定期向其他节点发送心跳消息。如果租约到期Leader 未能及时更新租约那么其他节点会发起新一轮的选举。这样即使出现脑裂现象只要租约期限设置得当系统也能在一定程度上保持一致性。 Kafka如何防止脑裂-Leader Epoch
为了解决脑裂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此外在查看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列表
ISRIn-Sync Replicas列表包含了分区的leader副本和已经成功同步了leader副本数据的follower副本。当选举发生时新的leader会从ISR列表中选举出来这样可以确保新的Leader副本拥有最新的数据从而保证数据的一致性。
当Leader接收到客户端的写入请求后它会将数据写入本地日志并将数据发送给所有的Follower副本。当follower副本成功写入数据后它会向Leader发送ACK确认。当leader收到ISR列表中的所有follower副本的ack后它会认为写入操作成功完成并向客户端返回成功响应。
当某个副本无法及时同步leader的数据时它会被从ISR列表中移除以确保ISR列表中的副本始终具有最新的数据。当该副本恢复正常并成功同步了Leader的数据后再将它重新加入到ISR列表中。
