4种Kafka网络中断和网络分区场景分析

本文深入探讨了Kafka在不同网络中断和分区场景下的行为,包括单个broker与leader、controller节点的网络中断,非controller节点所在区域隔离,以及Controller节点所在区域隔离的情况。分析了这些场景对生产消费、数据一致性的影响,并补充讨论了故障可能导致的数据不一致问题。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

以Kafka 2.7.1版本为例,依赖zk方式部署

3个broker分布在3个az,3个zk(和broker合部),单分区3副本

1. 单个broker节点和leader节点网络中断

网络中断前:

broker-1和broker-0(leader)间的网络中断后,单边中断,zk可用(zk-1为leader,zk-0和zk-2为follower,zk-0会不可用,但zk集群可用,过程中可能会引起原本连在zk-0上的broker节点会先和zk断开,再重新连接其他zk节点,进而引起controller切换、leader选举等,此次分析暂不考虑这种情况),leader、isr、controller都不变

az2内的客户端无法生产消费(metadata指明leader为broker-0,而az2连不上broker-0),az1/3内的客户端可以生产消费,若acks=-1,retries=1,则生产消息会失败,error_code=7(REQUEST_TIMED_OUT)(因为broker-1在isr中,但无法同步数据),且会发两次(因为retries=1),broker-0和broker-2中会各有两条重复的消息,而broker-1中没有;由于broker-0没有同步数据,因此会从isr中被剔除,controller同步metadata和leaderAndIsr,isr更新为[2,0]

网络恢复后,数据同步,更新isr

2. 单个broker节点和controller节点网络中断

broker和controller断连,不影响生产消费,也不会出现数据不一致的情况

而当发生leader和isr变化时,controller无法将leader和isr的变化更新给broker,导致元数据不一致

broker-0故障时,controller(broker-2)感知,并根据replicas选举新的leader为broker-1,但因为和broker-1网络中断,无法同步给broker-1,broker-1缓存的leader依然是broker-0,isr为[1,2,0];当客户端进行生产消费时,如果从broker-2拿到metadat

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值