浅析 Apache Kafka 分区重分配的实现原理

最新推荐文章于 2024-08-03 10:01:15 发布
原创 最新推荐文章于 2024-08-03 10:01:15 发布 · 419 阅读 · 1 ·
CC 4.0 BY-SA版权
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
文章标签：

#kafka #java #spring boot #mysql #分布式

本文由中国移动云能力中心大数据团队软件开发工程师孙大鹏撰写，深入剖析 Kafka 2.0.0 版本中分区副本重分配的流程和逻辑。文章介绍了如何使用 kafka-reassign-partitions 工具，探讨了 ZooKeeper 在元数据管理中的角色，以及 Kafka Controller 如何协调分区重分配。整个过程包括客户端发起任务、Controller 的元数据变更维护以及 Broker 端的数据迁移。

本文作者为中国移动云能力中心大数据团队软件开发工程师孙大鹏，本文结合 2.0.0 版本的 Kafka 源码，详细介绍了 Kafka 分区副本重分配的流程和逻辑，供大家参考。

一、前言

Kafka 是由 Apache 软件基金会开发的一个开源流处理平台，旨在提供一个统一的、高吞吐、低延迟的实时数据处理平台。其持久化层本质上是一个“按照分布式事务日志架构的大规模发布/订阅消息队列”，这使它作为企业级基础设施来处理流式数据非常有价值。

在 Kafka 中，用 topic 来对消息进行分类，每个进入到 Kafka 的信息都会被放到一个 topic 下，同时每个 topic 中的消息又可以分为若干 partition 以此来提高消息的处理效率。存储消息数据的主机服务器被命名为 broker。通常为了保证数据的可靠性，数据是以多副本的形式保存在不同 broker 的不同磁盘上的。对于每一个 topic 的每一个 partition，如果多个副本之间完成了数据同步，保证了数据的一致性，则此时的多个副本所在的 broker 的集合称为 Isr。同一时间，某个 topic 的某个 partition 的多个副本中仅有一个对外提供服务，此时对外提供服务的 broker 被认定为该 partition 的 leader，客户端的请求都集中到 leader 上。

对于 2 副本 3 分区的 topic 其描述信息及存储状态如下所示：

test的描述信息：
Topic:test PartitionCount:3 ReplicationFactor:2 Configs:min.insync.replic
as=1
Topic: test Partition: 0 Leader: 0 Replicas: 0，1 Isr: 0，1
Topic: test Partition: 1 Leader: 2 Replicas: 2，0 Isr: 2，0
Topic: test Partition: 2 Leader: 1 Replicas: 1，2 Isr: 1，2

test的副本分布

健康状态的 Kafka 集群，对于每个 topic 的每个 partition，其 Isr 都应该等于预期的副本集合（后面均已 Replicas 表示），但在实际场景中，不可避免的存在磁盘/主机故障，或者 由于某些原因需要将部分 broker 节点下线的情况，此时就需要将故障/要下线的 broker 从 Replicas 中移除。对此 Kafka 提供了 kafka-reassign-partitions

最低0.47元/天 解锁文章
【kafka源码】ReassignPartitionsCommand分区副本重分配源码原理分析(附配套教学视频)
石臻说AI(szzdzhp001) 【原名 石臻臻的杂货铺】
07-29 1万+
文章目录1.脚本的使用2.源码解析2.1`--generate ` 生成分配策略分析2.2`--execute ` 执行阶段分析2.2.1 已有任务,尝试限流2.2.2 开始执行副本重分配任务2.2.3 Controller监听`/admin/reassign_partitions`节点变化onPartitionReassignment2.2.4 Controller监听节点`brokers/topics/{topicName}`变化,检查是否有新增分区2.2.5 Controller监听zk节点`/bro
【技海登峰】Kafka漫谈系列（十一）SpringBoot整合Kafka之消费者Consumer
最新发布
这里是阿安的博客
05-18 664
【技海登峰】Kafka漫谈系列（十一）SpringBoot整合Kafka之生产者Consumer：Spring for Apache Kafka(spring-kafka)项目对原生Java客户端进行了基于Spring特性的抽象与封装，本文详细介绍了SpringBoot整合Kafka中的生产者Consumer相关内容，包括@KafkaListener注解、消息的多种消费方式、反序列化、拦截器、分区策略等待。
kafka分区重分配详解
徐海兴的专栏
11-28 4709
​ 当集群中的一个节点突然宕机下线时，如果节点上的分区是单副本的，那么这些分区就变得不可用，在节点恢复前，相应的数据也就处于丢失状态；如果节点上的分区是多副本的，那么位于这个节点上的leader副本的角色会转交到集群中的其他follower副本中。总而言之，这个节点上的分区副本都已经处于功能失效状态。kafka并不会将这些失效的副本自动地迁移到集群中剩余的可用broker节点上。如果放任不管则不仅影响整个集群的均衡负载，还会影响整体服务的可用性和可靠性。 ​ 当要对集群中的一个节点进行有计划的下线操作时
Apache 是如何完成负载均衡策略配置
12-17 3473
随着访问量的不断提升，以及对响应速度要求的苛刻，进行负载均衡设置就显得尤为重要了。公司的系统在最初设计的时候就已经考虑到了负载均衡的规 划，www静态服务器配置了两台，由于初期项目时间紧，并且访问量并不高，所以当时只用了一台，另一台在内网中，只是进行了同步，并为发挥出效用来。此次 就是对负载均衡的一个简单测试。 先介绍一下apache mod_proxy_balancer的几个配置规则：
Kafka Partition重分配流程简析
LittleMagic's Blog
10-24 2809
节日快乐~ 今天是属于广大程序员的节日，祝自己快乐hhhhhh 随着业务量的急速膨胀和又一年双11的到来，我们会对现有的Kafka集群进行扩容，以应对更大的流量和业务尖峰。当然，扩容之后的新Kafka Broker默认是不会有任何Topic和Partition的，需要手动利用分区重分配命令kafka-reassign-partitions将现有的Partition/Replica平衡...
Kafka Raft知识整理
zidongxiangxi的博客
12-27 1569
背景 Kafka2.8 之后，移除了Zookeeper，而使用了自己研发的Kafka Raft。 为什么移除Zookeeper？ 原来Zookeeper在Kafka中承担了Controller选举、Broker注册、TopicPartition注册和选举、Consumer/Producer元数据管理和负载均衡等。 即承担了各种元数据的保存和各种选举。 而Zookeeper并“不快”，集群规模大了之后，很容易成为集群的性能瓶颈。 Kafka作为一个消息中间件，还依赖额外的一个协调系统，而不能实现自
Kafka由浅入深
m0_72533993的博客
07-06 788
Kafka由浅入深在项目中，我们常常需要用到消息队列中间件，主要用来解决应用耦合，异步消息，流量削锋等问题。实现高性能、高可用、可伸缩和最终一致性架构。使用较多的消息队列有kafka、RabbitMQ、ActiveMQ、RocketMQ。不同的消息队列都会有不同的特点和优势。本文将对 Kafka 进行浅析，并分享一套kafka重试方案。2.1、什么是消息系统消息系统是负责将消息数据从一个应用传递到另外一个应用的系统，应用只需关注于数据，无需关注数据在两个或多个应用间是如何传递的。分布式消息传递基于可靠的消息
Flink技术实战分享和原理浅析
吒哇
09-15 1725
1 Flink是什么 在当前的数据量激增的时代，各种业务场景都有大量的数据产生，对于这些不断产生的数据应该如何高效的处理，成为当前的所面临的问题。而相对传统的数据处理模式，流式数据处理有着更高的处理效率和成本控制能力。Flink在德语中的意思快速和敏捷，同时又以一只棕红色的松鼠作为项目的Logo。 Apache Flink是一个支持高吞吐、低延迟、高性能的分布式处理框架和分布式处理引擎，用于在无边界和有边界数据流上进行有状态的计算。Flink能在所有常见集群环境中运行，并能以内存速度和任意规...
Kafka重分配流程图
Coding fly的博客
11-07 1006
Kafka 原理以及分区分配策略剖析
Java搜索工程技术栈
03-05 2543
一、简介 Apache Kafka 是一个分布式的流处理平台（分布式的基于发布/订阅模式的消息队列【Message Queue】）。 流处理平台有以下3个特性： 可以让你发布和订阅流式的记录。这一方面与消息队列或者企业消息系统类似。 可以储存流式的记录，并且有较好的容错性。 可以在流式记录产生时就进行处理。 1.1 消息队列的两种模式 1.1.1 点对点模式 生产者将消息发送到queue中，然后消费者从queue中取出并且消费消息。消息被消费以后，queue中不再存储.
二、kafka分区副本重分配-限流
Coding fly的博客
11-19 2182
这一篇我们主要来看看分区副本重分配限流是如何实现的，此源码分析基于kafka2.5版本。在开始之前我们先来回顾一下分区重分配的流程，如图一所示。 [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传 执行分区重分配脚本，这里相当于起了个kafka客户端，执行完脚本将重分配数据写入zk即返回了。 kafkaController监听到zk分区重分配节点数据变动，会调相应的handler来处理数据，这里相当于kafka服务端大脑的角色，控制了分区重分配主要处理的流程，并发送命令给其他节点执行，描
Kafka分区管理（优先副本的选举、分区重新分配）
m0_57771583的博客
06-13 600
Kafka可以将主题划分为多个分区（Partition），会根据分区规则选择把消息存储到哪个分区中，只要如果分区规则设置的合理，那么所有的消息将会被均匀的分布到不同的分区中，这样就实现了负载均衡和水平扩展。另外，多个订阅者可以从一个或者多个分区中同时消费数据，以支撑海量数据处理能力。 顺便说一句，由于消息是以追加到分区中的，多个分区顺序写磁盘的总效率要比随机写内存还要高（引用Apache Kafka – A High Throughput Distributed Messaging System的观点），是
大数据-64 Kafka 深入理解 Kafka 分区与重分配机制：高并发与高可用的核心 实机测试
永远好奇 无限进步
08-03 2800
Kafka 分区是实现高并发与高可用的核心机制。每个主题可被划分为多个分区，分布在不同 Broker 上，以实现水平扩展和并行处理。生产者可并发写入不同分区，消费者组内多个消费者可并行消费数据，从而显著提升吞吐量。分区配合副本机制（Leader 与 Follower）提供容错能力，即使某个 Broker 宕机，仍可在秒级切换 Leader 保证服务可用。分区重新分配（Partition Reassignment）用于在扩容、缩容或负载不均时调整分区分布，确保资源利用均衡和机架容灾。执行重分配。
Kafka的Rebalance机制与分区分配策略详解
RLCRAFT的博客
07-25 1378
Kafka 中的 Rebalance（重平衡）机制是在消费者组的成员发生变化时，重新分配分区以确保每个消费者都能处理适当数量的分区。这种机制对于保证数据消费的平衡性和系统的高可用性至关重要。有新的消费者加入消费者组时，需要重新分配分区，以便新的消费者也能接收到数据。消费者退出或崩溃时，组内的分区需要重新分配给剩余的消费者。主题的分区数量增加或减少时，也会触发 Rebalance。如果消费者组的协调器发生变化，也会触发 Rebalance。
Kafka重平衡与分区策略解析
日拱一卒无有尽，功不唐捐终入海
11-21 9976
Kafka 的重平衡与分区策略如同隐藏在数据洪流中的精密齿轮，既支撑着千万级消息的高效流转，也暗藏着消费停顿、数据重复等潜在陷阱。你是否好奇：当消费者节点增减时，Kafka 如何在毫秒级内完成分区的重新洗牌？默认的 Range 分配策略为何会导致分区负载不均？又该如何驯服重平衡这头 "猛兽"，让数据处理链路始终保持丝滑
kafka-重新分区
面朝大海，春暖花开
04-26 1609
kafka 重新分区 为什么要重新分区？ kafka 不会因为 broker 的增加或者减少而重新对原有的分区进行扩展 重新分区命令 –generate 生成分区重分配计划 –execute 执行分区重分配计划 –verify 验证分区充重配计划 准备 现集群： $ docker ps CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS
kafka重分配分区
weixin_43046724的博客
11-19 1556
1、确定需要执行重分区的topic，可以指定多个，建议每次重分区一个；（重分区之前检查下topic大小） # vi topics-to-move.json { "topics": [{ "topic": "test-topic" }], "version": 1 } 2、生成分区方案 Current partition replica assignment 当前分区分布（用于回滚） Proposed partition reassignmen.
kafka集群磁盘满警告，新增kafka节点，重新分配partition
zzhongcy的专栏
07-03 5550
本文参考了网上部分文章，并进行了说明和归纳，详情请查看参考。 官方文档参考：https://cwiki.apache.org/confluence/display/KAFKA/Replication+tools kafka环境中机器磁盘告警很容易出现，原因可能是某一个topic的partition为1(或者partition不足导致的)，只往一台机器上写数据，造成kafka集群空间使用不均。 下面主要使用kafka-topics.sh和kafka-reassign-partitions.s...
kafka 分区重分配 脚本
05-30
Kafka 提供了一些工具和脚本来实现分区重分配的管理和优化。 其中，最常用的脚本是 kafka-reassign-partitions.sh，该脚本可以帮助用户进行分区重分配的计算和执行。 使用 kafka-reassign-partitions.sh 脚本的具体步骤如下： 1. 创建一个 JSON 格式的分区重分配计划文件，格式如下： ``` { "version":1, "partitions":[ {"topic":"test","partition":0,"replicas":[1,2,3]}, {"topic":"test","partition":1,"replicas":[2,3,1]}, {"topic":"test","partition":2,"replicas":[3,1,2]} ] } ``` 其中，version 表示计划文件的版本号，partitions 表示需要进行重分配的分区列表，每个分区包括 topic、partition 和 replicas 三个属性，分别表示分区所属的 Topic 名称、分区编号和副本分配情况。 2. 执行 kafka-reassign-partitions.sh 脚本，指定计划文件和 Broker 地址清单，例如： ``` ./kafka-reassign-partitions.sh --zookeeper localhost:2181 --reassignment-json-file reassignment.json --execute ``` 执行该命令后，Kafka 会根据计划文件中的副本分配情况，重新分配分区到各个 Broker 节点上。 3. 监控分区重分配的状态和进度，可以使用 kafka-reassign-partitions.sh 脚本的 --verify 参数来验证分区重分配是否成功，例如： ``` ./kafka-reassign-partitions.sh --zookeeper localhost:2181 --reassignment-json-file reassignment.json --verify ``` 执行该命令后，Kafka 会检查分区重分配的状态和进度，并输出验证结果。 需要注意的是，分区重分配过程可能会影响 Kafka 集群的稳定性和消息传递的实时性，因此在进行分区重分配时需要谨慎操作，避免影响业务的正常运行。同时，Kafka 还提供了多种工具和策略来帮助用户进行分区重分配的管理和优化。
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
表情包 代码片
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值