kafka-稳定性-控制器

最新推荐文章于 2024-06-12 16:27:26 发布
最新推荐文章于 2024-06-12 16:27:26 发布
阅读量211 收藏
点赞数
分类专栏： Kafka MQ
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.youkuaiyun.com/ko0491/article/details/109690051
版权
本文详细介绍了Kafka集群中控制器的角色及其选举机制，利用Zookeeper的分布式锁进行控制器选举，防止“脑裂”。控制器负责在节点加入或离开时进行分区Leader选举，并通过epoch确保一致性。同时，讨论了副本分配策略、失效副本的判定及恢复，以及副本与Leader失去同步的情况。Kafka通过ISR确保数据可靠性，并提供了UnderReplicatedPartitions指标来监控集群健康。

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

控制器

afka集群包含若干个broker，broker.id指定broker的编号，编号不要重复。
Kafka集群上创建的主题，包含若干个分区。
每个分区包含若干个副本，副本因子包括了Follower副本和Leader副本。
副本又分为ISR（同步副本分区）和OSR（非同步副本分区）
在这里插入图片描述
控制器就是一个broker
控制器除了一般broker的功能，还负责Leader分区的选举
broker选举
集群里第一个启动的broker在Zookeeper中创建临时节点 /controller 。
其他broker在该控制器节点创建Zookeeper watch对象，使用Zookeeper的监听机制接收该节点的
变更。
即：Kafka通过Zookeeper的分布式锁特性选举集群控制器

节点 /myKafka/controller 是一个zookeeper临时节点，其中 “brokerid”:0 ，表示当
前控制器是broker.id为0的broker
在这里插入图片描述
每个新选出的控制器通过 Zookeeper 的条件递增操作获得一个全新的、数值更大的 controller
epoch。其他 broker 在知道当前 controller epoch 后，如果收到由控制器发出的包含较旧epoch 的消
息，就会忽略它们，以防止“脑裂”。
比如当一个Leader副本分区所在的broker宕机，需要选举新的Leader副本分区，有可能两个具有不
同纪元数字的控制器都选举了新的Leader副本分区，如果选举出来的Leader副本分区不一样，听谁的？
脑裂了。有了纪元数字，直接使用纪元数字最新的控制器结果
在这里插入图片描述
当控制器发现一个 broker 已经离开集群，那些失去Leader副本分区的Follower分区需要一个新
Leader（这些分区的首领刚好是在这个 broker 上）。

  1. 控制器需要知道哪个broker宕机了？
  2. 控制器需要知道宕机的broker上负责的时候哪些分区的Leader副本分区？
    下图中， /brokers/ids/0 保存该broker的信息，此节点为临时节点，如果broker
    节点宕机，该节点丢失。
    集群控制器负责监听 ids 节点，一旦节点子节点发送变化，集群控制器得到通知。
    在这里插入图片描述
    控制器遍历这些Follower副本分区，并确定谁应该成为新Leader分区，然后向所有包含新Leader分
    区和现有Follower的 broker 发送请求。该请求消息包含了谁是新Leader副本分区以及谁是Follower副
    本分区的信息。随后，新Leader分区开始处理来自生产者和消费者的请求，而跟随者开始从新Leader副
    本分区消费消息。
    当控制器发现一个 broker 加入集群时，它会使用 broker ID 来检查新加入的 broker 是否包含现有
    分区的副本。如果有，控制器就把变更通知发送给新加入的 broker 和其他 broker，新 broker上的副本
    分区开始从Leader分区那里消费消息，与Leader分区保持同步
    结论：
  3. Kafka使用 Zookeeper 的分布式锁选举控制器，并在节点加入集群或退出集群时通知控制器。
  4. 控制器负责在节点加入或离开集群时进行分区Leader选举。
  5. 控制器使用epoch来避免“脑裂”。“脑裂”是指两个节点同时认为自己是当前的控制器

可靠性保证

概念
  1. 创建Topic的时候可以指定 --replication-factor 3 ，表示分区的副本数，不要超过broker的
    数量。
  2. Leader是负责读写的节点，而其他副本则是Follower。Producer只把消息发送到Leader，
    Follower定期地到Leader上Pull数据。
  3. ISR是Leader负责维护的与其保持同步的Replica列表，即当前活跃的副本列表。如果一个
    Follow落后太多，Leader会将它从ISR中移除。落后太多意思是该Follow复制的消息Follow长
    时间没有向Leader发送fetch请求(参数： replica.lag.time.max.ms 默认值：10000)。
  4. 为了保证可靠性，可以设置 acks=all 。Follower收到消息后，会像Leader发送ACK。一旦
    Leader收到了ISR中所有Replica的ACK，Leader就commit，那么Leader就向Producer发送
    ACK
副本的分配：

当某个topic的 --replication-factor 为N(N>1)时，每个Partition都有N个副本，称作replica。原
则上是将replica均匀的分配到整个集群上。不仅如此，partition的分配也同样需要均匀分配，为了更好
的负载均衡。
副本分配的三个目标：

  1. 均衡地将副本分散于各个broker上
  2. 对于某个broker上分配的分区，它的其他副本在其他broker上
  3. 如果所有的broker都有机架信息，尽量将分区的各个副本分配到不同机架上的broker。
    在不考虑机架信息的情况下：
  4. 第一个副本分区通过轮询的方式挑选一个broker，进行分配。该轮询从broker列表的随机位置
    进行轮询。
  5. 其余副本通过增加偏移进行分配
    在这里插入图片描述
失效副本

失效副本的判定
replica.lag.time.max.ms 默认大小为10000。
当ISR中的一个Follower副本滞后Leader副本的时间超过参数 replica.lag.time.max.ms 指定的值
时即判定为副本失效，需要将此Follower副本剔出除ISR。
具体实现原理：当Follower副本将Leader副本的LEO之前的日志全部同步时，则认为该Follower副
本已经追赶上Leader副本，此时更新该副本的lastCaughtUpTimeMs标识。
Kafka的副本管理器（ReplicaManager）启动时会启动一个副本过期检测的定时任务，而这个定时
任务会定时检查当前时间与副本的lastCaughtUpTimeMs差值是否大于参数
replica.lag.time.max.ms 指定的值。
Kafka源码注释中说明了一般有两种情况会导致副本失效：

  1. Follower副本进程卡住，在一段时间内没有向Leader副本发起同步请求，比如频繁的Full
    GC。
  2. Follower副本进程同步过慢，在一段时间内都无法追赶上Leader副本，比如IO开销过大。
    如果通过工具增加了副本因子，那么新增加的副本在赶上Leader副本之前也都是处于失效状态的。
    如果一个Follower副本由于某些原因（比如宕机）而下线，之后又上线，在追赶上Leader副本之前
    也是出于失效状态。
    失效副本的分区个数是用于衡量Kafka性能指标的重要部分。Kafka本身提供了一个相关的指标，即
    UnderReplicatedPartitions，这个可以通过JMX访问:
kafka.server:type=ReplicaManager,name=UnderReplicatedPartitions

取值范围是大于等于0的整数。注意：如果Kafka集群正在做分区迁移（kafka-reassignpartitions.sh）的候，这个值也会大于0

副本复制

日志复制算法（log replication algorithm）必须提供的基本保证是，如果它告诉客户端消息已被提
交，而当前Leader出现故障，新选出的Leader也必须具有该消息。在出现故障时，Kafka会从挂掉
Leader的ISR里面选择一个Follower作为这个分区新的Leader。
每个分区的 leader 会维护一个in-sync replica（同步副本列表，又称 ISR）。当Producer向broker
发送消息，消息先写入到对应Leader分区，然后复制到这个分区的所有副本中。ACKS=ALL时，只有将
消息成功复制到所有同步副本（ISR）后，这条消息才算被提交。
什么情况下会导致一个副本与 leader 失去同步
一个副本与 leader 失去同步的原因有很多，主要包括：
慢副本（Slow replica）：follower replica 在一段时间内一直无法赶上 leader 的写进度。造
成这种情况的最常见原因之一是 follower replica 上的 I/O瓶颈，导致它持久化日志的时间比
它从 leader 消费消息的时间要长；
卡住副本（Stuck replica）：follower replica 在很长一段时间内停止从 leader 获取消息。
这可能是以为 GC 停顿，或者副本出现故障；
刚启动副本（Bootstrapping replica）：当用户给某个主题增加副本因子时，新的 follower
replicas 是不同步的，直到它跟上 leader 的日志。
当副本落后于 leader 分区时，这个副本被认为是不同步或滞后的。在 Kafka中，副本的滞后于
Leader是根据 replica.lag.time.max.ms 来衡量。

如何确认某个副本处于滞后状态
通过 replica.lag.time.max.ms 来检测卡住副本（Stuck replica）在所有情况下都能很好地工
作。它跟踪 follower 副本没有向 leader 发送获取请求的时间，通过这个可以推断 follower 是否正常。
另一方面，使用消息数量检测不同步慢副本（Slow replica）的模型只有在为单个主题或具有同类流量模
式的多个主题设置这些参数时才能很好地工作，但我们发现它不能扩展到生产集群中所有主题

【kafka】命令 数据的路径间迁移kafka-reassign-partitions.sh
九师兄
01-06 573
Controller 在初始化时，会利用 ZK 的 watch 机制注册很多不同类型的监听器，当监听的事件被触发时，Controller 就会触发相应的操作。监听节点，用于分区副本迁移的监听；监听节点，用于 Partition Isr 变动的监听，；监听节点，用于需要进行 Partition 最优 leader 选举的监听；监听节点，用于 Topic 新建的监听；监听节点，用于 Topic Partition 扩容的监听；监听节点，用于 Topic 删除的监听；监听节点。
Kafka的ISR收缩机制
959
02-18 2014
ISR什么时候收缩 ISR什么时候扩展 ISR的传播机制 Broker宕机之后怎么ISR的收缩？ Kafka在启动的时候,会启动一个副本管理器ReplicaManager,这个副本管理器会启动几个定时任务。 ISR过期定时任务isr-expiration,每隔replica.lag.time.max.ms/2毫秒就执行一次。 ISR变更的传播定时任务isr-change-propagation,每隔2500毫秒就执行一次。 replica.lag.time.max.ms : 如果一个follower.
Kafka kafka-reassign-partitions.sh 命令使用
胖头鱼的专栏
03-21 7230
编辑文件：tmp，内容如下： {"topics": [{"topic": "__consumer_offsets"},{"topic": "kafka_topic"}],  "version":1 } 生成reassign结果： sh kafka-reassign-partitions.sh --generate --zookeeper localhost:21
Kafka topic分区迁移
qq_42554735的博客
08-24 1552
多分区迁移和单分区一样只是验证和–generate 命令时候输出的、json有一些区别，比单分区会多一些内容。generate模式，给定需要重新分配的Topic，自动生成reassign plan（并不执行）迁移之后 分区目录名又了-delete的标识会被删除。2、把建议的的配置转成json----https://www.sojson.com/在进行分区副本重分配之前,最好是用下面方式获取一个合理的分配文件;3、转换后的json写入到另外一个文件ex.json。目标是分配到 broker 为0的节点、
kafka扩容数据自动重分配脚本
weixin_42566359的博客
09-26 831
kafka 扩容自动化数据重分配
Kafka 部署安装及相关操作记录
Gabriel的博客
07-04 923
⾃定义反序列化类，需要实现 org.apache.kafka.common.serialization.Deserializer 接⼝。
kafka-connect-jdbc-5.0.0.jar
07-08
《Kafka Connect JDBC Sink Connector详解》 在大数据领域，数据集成是至关重要的环节，而Apache ...在实际应用中，根据具体的业务需求和数据库环境，进行合理配置和优化，能够极大地提升数据处理的效率和稳定性。
kafka-2.13-4.0.0
最新发布
04-13
迁移过程中需验证 KRatt 控制器集群的稳定性，确保元数据同步正常，避免因迁移导致的业务中断。 3.性能提升与可扩展性增强 KRaft 模式通过优化元数据管理，减少了ZooKeeper的性能瓶颈，提升了元数据操作的效 率，...
Kafka--Kafka日志索引详解以及生产常见问题分析与总结
weixin_43874650的博客
12-20 2186
​ Kafka的设计重点是在网络不稳定，服务也不稳定的复杂分布式环境下，如何保持高性能，高可用，高可扩展的三高架构。在这方面，Kafka的设计是很复杂也很完善的，是业内公认的老大哥。因此网上的解读文章也是最多的。但是这些解读的文章如果没有一条主线串起来，那永远都只是一些零散的，过目既忘的东西。​ 在这几期的课程中，一直在尝试以可见的方式去深入理解Kafka的各种主要设计思想。内容非常多，节奏也非常紧凑，但是梳理出了客户端、Zookeeper数据、Log日志三条可以看得见的数据主线。
kafka-connect-tools
08-23
**Kafka Connect Tools详解** Kafka Connect 是 Apache Kafka 项目的一部分，它提供了一种可扩展且...通过熟练掌握这些工具，可以提升数据处理的效率，保障数据集成的稳定性，为企业的数据基础设施提供坚实的支持。
kafka-稳定性-事务
小城我家
11-14 812
稳定性 事务 一、事务场景 如producer发的多条消息组成一个事务这些消息需要对consumer同时可见或者同时不可见 。 producer可能会给多个topic，多个partition发消息，这些消息也需要能放在一个事务里面，这就形成了一个典型的分布式事务。 kafka的应用场景经常是应用先消费一个topic，然后做处理再发到另一个topic，这个consume-transform-produce过程需要放到一个事务里面，比如在消息处理或者发送的过程中如果失败了，消费偏移量也不能提交。 produc
Kafka分区的管理
通往神秘的道路的专栏
11-10 1324
本节主要介绍与分区相关的知识和操作,包括优先副本的选举、分区重分配、复制限流、修改副本因子等内容。 1、优先副本的选举 分区使用多副本机制来提升可靠性,但只有 leader副本对外提供读写服务,而 follower副本只负责在内部进行消息的同步。如果一个分区的 leader副本不可用,那么就意味着整个分区变得不可用,此时就需要Kafka从剩余的 follower副本中挑选一个新的 leader...
【源码分析】Kafka分区重分配/迁移（kafka-reassign-partitions.sh）
gaofeng的博客
06-30 4253
/** * This callback is invoked by the reassigned partitions listener. When an admin command initiates a partition * reassignment, it creates the /admin/reassign_partitions path that triggers the zookeeper listener. * Reassigning replicas for a par
实操 | kafka如何手动异步提交offset
CREATE_17的博客
09-21 3641
点击上方蓝色“大数据实战演练”，选择“设为星标”或“置顶”回复“资源”领取独家整理的学习资料！每一个成功人士的背后，必定曾经做出过勇敢而又孤独的决定。放弃不难，但坚持很酷~kafka_2...
Kafka
qq_52868288的博客
06-07 462
一、概述 > 1、定义 > 1）传统定以 > 生产者命令操作 消费者命令行操作 生产者生产经验 生产经验——生产者如何提高吞吐量 思考：ACK应答级别：-1 Leader收到数据，所有Follower都开始同步数据， 但有一个Follower，因为某种故障，迟迟不能与Leader进行 同步，那这个问题怎么解决呢？数据完全可靠条件 = ACK级别设置为-1 + 分区副本大于等于2 + ISR里应答的最小副本数量大于等于2数据重复分析： PID是Kafka每次重启都会分配一个新的；
kafka分区重分配详解
徐海兴的专栏
11-28 4482
​ 当集群中的一个节点突然宕机下线时，如果节点上的分区是单副本的，那么这些分区就变得不可用，在节点恢复前，相应的数据也就处于丢失状态；如果节点上的分区是多副本的，那么位于这个节点上的leader副本的角色会转交到集群中的其他follower副本中。总而言之，这个节点上的分区副本都已经处于功能失效状态。kafka并不会将这些失效的副本自动地迁移到集群中剩余的可用broker节点上。如果放任不管则不仅影响整个集群的均衡负载，还会影响整体服务的可用性和可靠性。 ​ 当要对集群中的一个节点进行有计划的下线操作时
Kafka源码分析（二七）——Broker：集群管理——分区重分配
smart_an的专栏
06-12 1227
本章，我对Kafka的分区重分配流程和底层实现原理进行了讲解，分区重分配本质在于数据复制，先增加新的副本，然后进行数据同步，最后删除旧的副本来达到最终目的。数据复制会占用额外的资源，所以，分区重分配一定要在低峰值时期执行。另外，可以减小重分配的粒度，以小批次的方式来操作是一种可行的解决思路。但是，如果集群中某个分区的流量即使在低峰时期还是特别大，那么就需要采取限流机制，Kafka默认提供了两种复制限流的方式：通过脚本和实现。我就不赘述了，读者可以找相关资料了解。
Kafka运维监控
weixin_38910645的博客
07-18 661
消息格式和消息压缩 Kafka消息始终以成批的方式写入。一批消息的技术术语是一个记录批，并且一个记录批包含一个或多个记录。在简单的情况下，我们可以有一个包含单个记录的记录批。记录批和记录具有自己的标题。每个文件的格式如下图所示： 上图和日志文件输出项对应关系如下： first offset baseOffset(int64) length batchLength(int32) leader epoch partitionLeaderEpoc
4.2.3 Kafka高级特性解析(主题--shell管理、增加分区、分区副本分配、app操作；分区--leader选举、重新分配、自动再均衡、分区策略)
weixin_47134119的博客
03-18 1230
Kafka高级特性解析 文章目录Kafka高级特性解析2.3 主题2.3.1 管理2.3.1.1 创建主题2.3.1.2 查看主题2.3.1.3 修改主题2.3.1.4 删除主题2.3.2 增加分区2.3.3 分区副本的分配-了解2.3.4 必要参数配置2.3.5 KafkaAdminClient应用查看主题创建主题删除主题修改主题查看分区详情查询集群信息查看配置信息修改配置信息修改副本的日志目录查询节点的日志目录信息 2.3 主题 2.3.1 管理 使用kafka-topics.sh脚本： 主
探索kafka-rust：Rust语言的Apache Kafka客户端实现
同时，还对测试进行了调整，以确保客户端的稳定性和可靠性。 关于项目的“新家”，文档中提到kafka-rust已经搬到了一个新地址。这可能意味着代码仓库已经被迁移到了新的位置，以便于管理和维护。 在文档资料方面，...
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值