3.kafka3.x Broker相关原理

已于 2022-07-07 11:45:55 修改
阅读量350 收藏
点赞数
分类专栏： kafka 文章标签： kafka java 分布式
于 2022-07-07 11:32:45 首次发布
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/woshiwjma956/article/details/125655426
版权

broker在zookeeper中存储的信息

在这里插入图片描述

在这里插入图片描述

  1. /kafka/brokers/ids 记录了所有存活的broker服务器id

  2. /kafka/brokers/topics/topic_name/partition/0/state 保存了关于该partition的leader信息和ISR信息

    {
    “controller_epoch” : 11,
    “leader” : 0,
    “version” : 1,
    “leader_epoch” : 3,
    “isr” : [ 0, 1 ]
    }

  3. /kafka/controller 用于选举leader,谁先找到controller谁则竞选成功

broker工作流程

在这里插入图片描述

每个broker中都有controller ZK中也有/controller节点 作用在于leader选举和同步zk上注册的leader isr相关信息

  1. broker启动向ZK注册,写入/broker/ids [0,1,2…]

  2. /kafka/controller 选举leader 谁先注册到controller上就是leader

  3. 选举出来的Controller去监听brokers节点变化

  4. ZK中的controller决定leader选举

  5. controller将节点信息通知ZK /brokers/topics/xxx/partition/0/state 维护leader和isr信息

  6. broker其他controller从ZK同步相关信息

  7. 此时producer的与集群中的leader进行通信,leader与其余follower之间再进行信息同步

  8. 如出现Broker中的leader宕机

  9. 发起重新选举

    1. 首先在ISR中存活为前提
    2. 再按照AR中排在前面的优先
    3. 例如AR[1,0,2],ISR[1,0,2]那么leader会按照1,0,2顺序来轮询

  10. Controller监听节点的变化

  11. 重新获取ISR

  12. 选择新的leader(在ISR中存活为前提,按照AR中排在前面的优先)

  13. 更新leader和ISR

broker重要参数

参数名称描述
replica.lag.time.max.msISR 中，如果 Follower 长时间未向 Leader 发送通 信请求或同步数据，则该 Follower 将被踢出 ISR。 该时间阈值，默认 30s。
auto.leader.rebalance.enable默认是 true。 自动 Leader Partition 平衡。
leader.imbalance.per.broker.percentage默认是 10%。每个 broker 允许的不平衡的 leader 的比率。如果每个 broker 超过了这个值，控制器 会触发 leader 的平衡。
leader.imbalance.check.interval.seconds默认值 300 秒。检查 leader 负载是否平衡的间隔时 间。
log.segment.bytesKafka 中 log 日志是分成一块块存储的，此配置是 指 log 日志划分 成块的大小，默认值 1G。
log.index.interval.bytes默认 4kb，kafka 里面每当写入了 4kb 大小的日志 （.log），然后就往 index 文件里面记录一个索引。
log.retention.hoursKafka 中数据保存的时间，默认 7 天。
log.retention.minutesKafka 中数据保存的时间，分钟级别，默认关闭。
log.retention.msKafka 中数据保存的时间，毫秒级别，默认关闭。
log.retention.check.interval.ms检查数据是否保存超时的间隔，默认是 5 分钟。
log.retention.bytes默认等于-1，表示无穷大。超过设置的所有日志总 大小，删除最早的 segment。
log.cleanup.policy默认是 delete，表示所有数据启用删除策略； 如果设置值为 compact，表示所有数据启用压缩策 略。
num.io.threads默认是 8。负责写磁盘的线程数。整个参数值要占 总核数的 50%。
num.replica.fetchers副本拉取线程数，这个参数占总核数的 50%的 1/3
num.network.threads默认是 3。数据传输线程数，这个参数占总核数的 50%的 2/3 。
log.flush.interval.messages强制页缓存刷写到磁盘的条数，默认是 long 的最 大值，9223372036854775807。一般不建议修改， 交给系统自己管理。
log.flush.interval.ms每隔多久，刷数据到磁盘，默认是 null。一般不建 议修改，交给系统自己管理。

节点服役和退役

服役(添加节点)

  1. 查看当前topic的分区规则 kafka-topics.sh --bootstrap-server node1:9092 --topic test_topic --describe

  2. 新增node3节点

  3. 创建一个负载均衡主题 vim topics-to-move.json

    {
 "topics": [
 {"topic": "test_topic"}
 ],
 "version": 1
}

  4. 生成负载均衡计划

    bin/kafka-reassign-partitions.sh --bootstrap-server node1:9092 --topics-to-move-json-file topics-to-move.json --broker-list "0,1" --generate

# 之前的负载均衡计划 可以用于回滚
Current partition replica assignment
{"version":1,"partitions":[{"topic":"test_topic","partition":0,"replicas":[0],"log_dirs":["any"]},{"topic":"test_topic","partition":1,"replicas":[0],"log_dirs":["any"]}]}

# 重新生成分区的计划
Proposed partition reassignment configuration
{"version":1,"partitions":[{"topic":"test_topic","partition":0,"replicas":[0],"log_dirs":["any"]},{"topic":"test_topic","partition":1,"replicas":[1],"log_dirs":["any"]}]}

在这里插入图片描述

  1. 复制重新生成分区计划 vim increase-replication-factor.json

    {"version":1,"partitions":[{"topic":"test_topic","partition":0,"replicas":[0],"log_dirs":["any"]},{"topic":"test_topic","partition":1,"replicas":[1],"log_dirs":["any"]}]}

  2. 执行负载均衡计划

    bash ../bin/kafka-reassign-partitions.sh --bootstrap-server node1:9092 --reassignment-json-file ./increase-replication-factor.json --execute

# 之前分片计划 可以用于回滚
Current partition replica assignment

{"version":1,"partitions":[{"topic":"test_topic","partition":0,"replicas":[0],"log_dirs":["any"]},{"topic":"test_topic","partition":1,"replicas":[0],"log_dirs":["any"]}]}

Save this to use as the --reassignment-json-file option during rollback
Successfully started partition reassignments for test_topic-0,test_topic-1

  3. 验证

    bash ../bin/kafka-reassign-partitions.sh --bootstrap-server node1:9092 --reassignment-json-file ./increase-replication-factor.json --verify

Status of partition reassignment:
Reassignment of partition test_topic-0 is complete.
Reassignment of partition test_topic-1 is complete.

Clearing broker-level throttles on brokers 0,1
Clearing topic-level throttles on topic test_topic

  4. 此时再查看topic的描述,此时副本和leader已经改变

在这里插入图片描述

退役(移除节点)

  1. 查看当前topic的分区规则 kafka-topics.sh --bootstrap-server node1:9092 --topic test_topic --describe

在这里插入图片描述

  1. 此时如果需要对node2节点进行下线

  2. 编写需要执行负载均衡的主题json文件

    {
 "topics": [
 {"topic": "test_topic"}
 ],
 "version": 1
}

  3. 生成一个负载均衡计划 bash …/bin/kafka-reassign-partitions.sh --bootstrap-server node1:9092 --topics-to-move-json-file ./topics-move-plan.json --broker-list “0” --generate

在这里插入图片描述

  1. 此时异常表示因为目前broker只有1台机器 但是replication-factor是2 无法做到副本为2此时修改partition0,1的副本为1

  2. 生成副本修改计划 /bin/kafka-reassign-partitions.sh --bootstrap-server node1:9092 --reassignment-json-file ./decrease-replication-factor.json --execute

    {
    "version": 1,
    "partitions": [
        {
            "topic": "test_topic",
            "partition": 1,
            "replicas": [
                0
            ]
        },
        {
            "topic": "test_topic",
            "partition": 0,
            "replicas": [
                0
            ]
        }
    ]
}

在这里插入图片描述

  1. 再执行负载均衡计划 bash …/bin/kafka-reassign-partitions.sh --bootstrap-server node1:9092 --topics-to-move-json-file ./topics-move-plan.json --broker-list “0” --generate
    在这里插入图片描述

  2. 此时再查看topic的状态 bash …/bin/kafka-topics.sh --bootstrap-server node1:9092 --topic test_topic --describe

在这里插入图片描述

  1. leader replicas 和ISR 都变成了0

kafka副本

  1. 副本作用可以提高数据可靠性
  2. 生产环境一般配置为2,可以保证数据可靠性,太多的副本会增加磁盘占用,且在数据副本同步的时候会占用网络资源降低效率
  3. Kafka中的副本分为leader和follower,producer只会把数据发往leader然后follower找leader进行数据同步
  4. kafka分区中所有的副本统称AR(Assigned Replicas)
  5. AR = ISR + OSR
    1. ISR: 表示leader保持同步的follower集合.如果follower长时间未向leader发送同步通信请求或者同步数据,该follower会被踢出ISR,时间阈值由replica.lag.time.max.ms控制默认30s.当leader发生故障时候会从ISR中重新选举新的leader
    2. OSR: 表示follower和leader副本同步时,延迟过高的副本

leader选举流程

kafka集群中有一个broker的controller会被选举成为controller leader,负责管理整个集群的broker的上下线,所有topic的分区副本分配和leader选举

在这里插入图片描述

故障迁移细节

LEO (Log End Offset): 每个副本的最后一个offset+1 即使最新的offset+1

HW (High Waterark): 所有副本中最小的LEO

follower故障
在这里插入图片描述

  1. follower发生故障之后会被临时踢出ISR
  2. 期间leader和其他follower继续接受数据
  3. 待follower恢复之后,follower会读取本地磁盘记录中的上次的HW,并将log文件高于HW的部分截取掉,从HW开始向leader进行同步
  4. 等到follower的LEO>=该partition的HW,即使follower追上了leader此时重新加入ISR
  5. 如上图如果broker2 宕机,宕机瞬间follower的HW和LEO 分别是5和7,此时leader和follower继续接受数据HW和LEO后移,此时broker2恢复发现自己的HW是5,先将HW之后的6,7清除,重新与leader通信进行HW和LEO的同步

leader故障

在这里插入图片描述

  1. leader故障之后,会从ISR中选出新的leader
  2. 为了保证多副本之前的数据一致性,其他follower会先自己log文件高于HW的部分截掉,然后重新从leader同步数据
  3. 保证了各个副本之间的数据一致性,但是不能保证数据不丢失和不重复

手动调整副本数

具体的生产环境可能因为每个服务器的配置和剩余资源不一样，如果全部根据kafka的默认规则进行负载均衡可能会造成资源的利用率不高,此时需要手动调整分区和副本的存储

  1. 创建副本存储计划 vim increase-replication-factor.json

    {
"version":1,
"partitions":[{"topic":"test_topic","partition":0,"replicas":[0,1]},
{"topic":"test_topic","partition":1,"replicas":[0,1]}, # 修改分区的replicas即可
{"topic":"test_topic","partition":2,"replicas":[1,0]},
{"topic":"test_topic","partition":3,"replicas":[1,0]}]
}

  2. 执行修改副本存储计划

    bash bin/kafka-reassign-partitions.sh --bootstrap-server node1:9092 --reassignment-json-file increase-replication-factor.json --execute

  3. 验证

    bin/kafka-reassign-partitions.sh -- bootstrap-server node1:9092 --reassignment-json-file increase-replication-factor.json --verify

  4. 查看分区描述describe

    bin/kafka-topics.sh --bootstrap-server node1:9092 --describe --topic test_topic

Leader Partition 负载均衡

默认情况下,kafka会自动将Leader Partition均匀的分布到各个机器上,保证每一台的机器的读写吞吐量均匀,但是如果某一些broker宕机,会导致leader partition过于集中在少部分broker机器上,会导致部分broker压力过大,其他broker重启之后都是follower,导致读写请求很低,造成集群的负载不均衡

kafka通过三个参数来控制leader partition的负载均衡

auto.leader.rebalance.enable 是否开启 默认开启

leader.imbalance.per.broker.percentage 允许不平衡比例 默认10%

leader.imbalance.check.interval.seconds 检查leader负载均衡时间间隔 默认300s

leader.imbalance.per.broker.percentage计算规则

如下实例为例

Topic: test_topic	Partition: 0	Leader: 0	Replicas: [3,0,2,1]	Isr: [3,0,2,1]
Topic: test_topic	Partition: 1	Leader: 1	Replicas: [1,2,3,0]	Isr: [1,2,3,0]
Topic: test_topic	Partition: 2	Leader: 2	Replicas: [0,3,1,2]	Isr: [0,3,1,2]
Topic: test_topic	Partition: 3	Leader: 3	Replicas: [2,1,0,3]	Isr: [2,1,0,3]

如果此时broker0节点宕机为例,此时AR中优先副本是3,但3不是leader节点,所以不平衡+1,AR副本总数是4,计算出不平衡节点为 1/4 > 10% 需要再平衡

在生产环境下一般不开启自动平衡,因为触发leader partition的自动平衡会损耗性能,或者将自动触发平衡的leader.imbalance.per.broker.percentage 参数阈值调大,一般采用手动调整的模式

文件存储

kafka的文件存储,topic是一个逻辑上的概念,而partition是物理上的概念.一个partition对应一个log文件,log文件存储了producer生产的数据,producer生产的数据会不断的 追加 到log文件的尾部,为了提高log文件定位效率,kafka采用了分片和索引的策略.每一个partition文件分割成多个segement,每一个segement包含了 .index .log .timeindex等文件位于同一个目录下,该目录命名规则为topic名称+分区序号如 test_topic-0

在这里插入图片描述

Log文件和Index文件详解

在这里插入图片描述

  1. 默认每写入4kb大小的日志log之后,就会往index记录一个索引(稀疏索引)
  2. index文件保存了offset是相对offset,确保了offset的值占用空间不会过大
  3. 根据offset定位到segment文件
  4. 找到小于等于目标offset的最大offset对应的索引
  5. 定位到log文件
  6. 向下遍历找到目标record
参数描述
log.segment.bytesKafka 中 log 日志是分成一块块存储的，此配置是指 log 日志划分 成块的大小，默认值 1G。
log.index.interval.bytes默认 4kb，kafka 里面每当写入了 4kb 大小的日志（.log），然后就 往 index 文件里面记录一个索引。 稀疏索引。

文件清理策略

kafka默认日志保存时间为7天日志过期之后kafka提供了两种清理策略delete和compact两种

参数描述
log.retention.hours最低优先级小时，默认 7 天
log.retention.minutes分钟 优先级高于log.retention.hours
log.retention.ms最高优先级毫秒
log.retention.check.interval.ms负责设置检查周期，默认 5 分钟
log.cleanup.policy日志清理策略 默认delete
log.retention.bytes基于大小：默认关闭。超过设置的所有日志总大小,，默认等于-1，表示无穷大

基于时间以中segement所有记录中最大时间戳为该文件的时间戳

在这里插入图片描述

例如segement2最新的记录没有达到过期时间,这次该segement不会被清理

compact日志压缩原理

在这里插入图片描述

相同key的数据只保留最后一个版本,压缩之后的数据会导致offset不连续,该策略适合一些特殊的场景,比如key是用户id,value是用户信息,用户的信息是会 不断更新的,compact策略只保留最新数据

kafka的高效读写原理

  1. kafka本身是分布式集群,采用分区技术提高了并行度
  2. 读数据采用了稀疏索引可以快速定位消费的数据
  3. 顺序写
  4. 页缓存 + 零拷贝
夹毛局的程序员
关注
专栏目录
Kafka3.0.0版本——Broker（上下线）示例
小志的博客
08-08 475
Kafka3.0.0版本——Broker（上下线）示例
Kafka3.0 Broker 生产经验
weixin_45417821的博客
06-04 254
正常情况下，Kafka本身会自动把Leader Partition均匀分散在各个机器上，来保证每台机器的读写吞吐量都是均匀的。但是如果某 些broker宕机，会导致Leader Partition过于集中在其他少部分几台broker上，这会导致少数几台broker的读写请求压力过高，其他宕机的broker重启之后都是follower partition，读写请求很低，造成集群负载不均衡。在生产环境当中，由于某个主题的重要等级需要提升，我们考虑增加副本。副本数的增加需要先制定计划，然后根据计划执行。 1）创建
Kafka知识总结之Broker原理总结
热门推荐
学习和工作总结，共勉！
03-18 1万+
这篇文章介绍Kafka的Broker工作流程，包括其中控制器的选举过程；kafka副本的leader选举以及leader和follower故障流程；简单讲述了生产环境中如何调整分区副本；kafka的文件存储机制以及日志文件的删除策略；最后了解下kafka中使用的页缓冲和零拷贝的原理。
消息队列之-Kafka原理讲解
wanglei_storage的博客
09-20 8039
一、入门 1.1 简介 一、入门 1.1 简介 Apache Kafka 是一个分布式流媒体平台 流媒体平台有三个关键功能 发布和订阅记录流，类似于消息队列或企业消息传递系统 以容错的持久方式存储记录流 记录发生时的处理流 Kafka 通常用于两大类应用： 构建可在系统或应用程序之间可靠获取数据的实时流数据管道 构建转换或相应数据流的实时流应用程序...
实战问答：leader切换未发生原因探析
kafka_zsxq的博客
12-24 1244
Q 对一套kafka1.1.1三个topic实施副本重分布，目标为将图中replica副本中第一个选为leader，前提条件，这套环境的auto.leader.rebalance.enable这个参数等于true，以为是会自动优选，但似乎只有leader为1的那个topic发生了leader切换（原本三个topic leader都为3）。 问题1:想了解其余两个topic未发生leader切换原因，根据controller日志，似乎这个配置策略不是kafka认为的优选策略？ 问题2:replica和i
kafka3.x原理详解看这篇就够了
javase1086的博客
03-08 669
一、概述 （一）、kafka的定义 1、定义 1）kafka传统的定义：kafka是一个分布式的基于发布/订阅模式的消息队列，主要用于大数据实时处理领域 2）kafka最新的定义：kafka是一个开源的分布式事件流平台（event stream platform），主要用高性能数据管道，流分析，数据集成和关键任务等领域 2、消息队列 目前市面上大部分公司采用的消息队列主要有kafka，activeMQ，rabbitMQ，rocketMQ等。kafka作为消息队列，主要应用于大数据场景下，而在Javaee开发
Kafka3.x最全面的总结
rianple的博客
02-23 1322
一、概述 　　（一）、kafka的定义 　　　　　　1、定义 　　　　　　　　1）kafka传统的定义：kafka是一个分布式的基于发布/订阅模式的消息队列，主要用于大数据实时处理领域 　　　　　　　　2）kafka最新的定义：kafka是一个开源的分布式事件流平台（event stream platform），主要用高性能数据管道，流分析，数据集成和关键任务等领域 　　　　　　2、消息队列 　　　　　　　　目前市面上大部分公司采用的消息队列主要有kafka，activeMQ，rabbitMQ，
Kafka3.x重点归纳2
qq_43585580的博客
08-11 562
kafka
Kafka之生产者
d303577562的博客
08-18 751
1.简介 从编程的角度而言，生产者就是负责向Kafka发送消息的应用程序。在Kafka的历史变迁中，一共有两个大版本的生产者客户端：第一个是于Kafka开源之初使用Scala语言编写的客户端，我们可以称之为旧生产者客户端（Old Producer）或Scala版生产者客户端；第二个是从Kafka0.9x 版本开始推出的使用Java语言编写的客户端，我们可以称之为新生产者客户端（New Producer）或Java版生产者客户端，它弥补了旧版客户端中存在的诸多设计缺陷。虽然Kafka是用Java/Scala语
2. kafka安装
阿飞Javaer的专栏
06-23 555
这篇文章主要讲解kafka单机安装，以及集群安装。kafka的单机安装非常简单，只需按照下一段落提到的几步操作即可。 单机安装 下载 首先从官方下载安装包，官方地址：http://kafka.apache.org/downloads。kafka安装包和一般安装包的命名方式不一样，我们看一个kafka包命名：kafka_2.11-1.1.0.tgz，其中2.11是scala的版本，1.1...
Kafka 分区
qq_45562973的博客
05-31 1189
🚀 优质资源分享 🚀 学习路线指引（点击解锁） 知识定位 人群定位 🧡 Python实战微信订餐小程序 🧡 进阶级 本课程是python flask+微信小程序的完美结合，从项目搭建到腾讯云部署上线，打造一个全栈订餐系统。 💛Python量化交易实战💛 入门级 手把手带你打造一个易扩展、更安全、效率更高的量化交易系统 一、副本机制 Kafka在⼀定数量的服务器上对主题分区进⾏复制。 当集群中的⼀个broker宕机后系统可以⾃动故障转移到其他可⽤的副本上，不会造成数据丢失。 创建主题
Kafka：关闭和设置Leader Partition负载平衡
程序员无羡的博客
03-20 646
Kafka：关闭和设置Leader Partition负载平衡
Kafka 参数优化
Jwwwy的博客
07-13 422
常用的Kafka参数优化
kafka服务器节点的配置(三)
XinhuaShuDiao的博客
02-09 3475
kafka的核心配置是： broker.id--节点id log.dirs--日志路径 zookeeper.connect--zookeeper的连接地址 节点重新配置后有3种启动方式： read-only:需要重新启动broker进行更新。 per-broker:可以为每个broker动态更新。 cluster-wide:可以作为集群范围的默认值动态更新，也可以为测试更新为每个broker的值。 下面分别看下服务器节点的配置： 1.zookeeper.co...
分布式 - 消息队列Kafka：Kafka分区常见问题总结
最新发布
你今天真好看呀
07-21 2059
如果某个 Broker 上的领导者分区数量超过了平均值的 10%，则该 Broker 将不再接受新的领导者分区，直到其他 Broker 上的领导者分区数量增加，使得整个集群的领导者分区数量平衡。比如很多公司使用 Kafka 收集应用服务器的日志数据，这种数据都是很多的，特别是对于那种大批量机器组成的集群环境，每分钟产生的日志量都能以 GB 数，因此如何将这么大的数据量均匀地分配到 Kafka 的各个 Broker 上，就成为一个非常重要的问题。并且，我们还可以通过添加新的节点机器来增加整体系统的吞吐量。
Kafka系列之：Broker配置
zhengzaifeidelushang的博客
08-26 1395
Kafka系列之：Broker配置
不一样的kafka系列#Topic和Partition
kimichen123的专栏
09-29 322
主题的管理包括创建主题、查看主题信息、修改主题和删除主题等操作。可以通过Kafka提供的kafka-topics.sh 脚本来执行这些操作，这个脚本位于$KAFKA_HOME/bin/ 目录下，其核心代码仅有一行，具体如下： exec $(dirname $0)/kafka-run - class.sh kafka.admin.Top ic Command ＂$＠＂ Topic相关 auto .create.topics .enable 设置为true会自动创建主题，和...
Kafka的灵魂伴侣Logi-KafkaManger(三)之运维管控--集群列表
weixin_42073629的博客
05-04 361
运维管控 运维管控这个菜单栏目下面主要是供运维人员来管理所有集群的; 接入集群 Kafka的灵魂伴侣Logi-KafkaManger一之集群的接入及相关概念讲解 物理集群列表 列出了所有物理集群,点击一个物理集群进去看详细信息; 如果没有信息请检查一下是否正确开启了JMX; ==> JMX-连接失败问题解决 集群概览 实时流量 指标说明 因为我发送和消费过消息, 为了不让之前的数据干扰; 我们重新把Broker重启一下,Jmx的数据就会清0了; 历史数据清楚就去数据库中把
消息中间件学习笔记（三）——kafka配置
lvxiaowei777的博客
04-03 1987
目录 一、Broker配置 二、Topic配置 三、Producer配置 四、Consumer配置 1、新消费者配置 2、老消费者配置 五、Connect配置 六、Streams配置 七、AdminClient配置 一、Broker配置 关于broker配置的详情，可以查看scala类中的 kafka.server.KafkaConfig。 名称 描述 类型 ...
3.Kafka如何保证可靠性？
06-01
3. 消息持久化：Kafka将消息持久化到磁盘上，确保即使出现故障，也能够快速恢复。 4. 消息重试：Kafka允许生产者在发送消息时进行重试，如果某个Broker宕机或者网络故障，生产者会重试发送消息，保证消息不会丢失。...
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值