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

最新推荐文章于 2024-09-25 08:38:14 发布

pythonxxoo

最新推荐文章于 2024-09-25 08:38:14 发布

阅读量292

点赞数

分类专栏：计算机文章标签： kafka 分布式计算机

本文链接：https://blog.youkuaiyun.com/pythonxxoo/article/details/125688442

版权

本文详细分析了Kafka在不同网络中断和分区场景下的行为，包括broker与leader、controller节点的网络中断，以及非controller节点和Controller节点所在AZ的隔离。讨论了这些情况对生产消费、元数据、数据一致性和双主现象的影响，并举例说明数据丢失的可能性。建议在acks配置上谨慎选择以防止数据丢失。

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

🚀 优质资源分享 🚀

学习路线指引（点击解锁）	知识定位	人群定位
🧡 Python实战微信订餐小程序 🧡	进阶级	本课程是python flask+微信小程序的完美结合，从项目搭建到腾讯云部署上线，打造一个全栈订餐系统。
💛Python量化交易实战💛	入门级	手把手带你打造一个易扩展、更安全、效率更高的量化交易系统

**摘要：**本文主要带来4种Kafka网络中断和网络分区场景分析。

本文分享自华为云社区《Kafka网络中断和网络分区场景分析》，作者：中间件小哥。

以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]