大数据-65 Kafka 高级特性 分区 Broker自动再平衡 ISR 副本 宕机恢复再重平衡 实测

点一下关注吧!!!非常感谢!!持续更新!!!

目前已经更新到了:

  • Hadoop(已更完)
  • HDFS(已更完)
  • MapReduce(已更完)
  • Hive(已更完)
  • Flume(已更完)
  • Sqoop(已更完)
  • Zookeeper(已更完)
  • HBase(已更完)
  • Redis (已更完)
  • Kafka(正在更新...)

章节内容

上节我们完成了如下的内容:

我们模拟了让分区重新分配的过程,在业务上实际发生的情况。比如:当几台Kafka节点不够用后,我们将对Kafka进行扩容,但是此时遇到的问题是,之前的分区不会分配到新的Kafka节点上,那此时我们需要借助Kafka提供的脚本来实现这一过程:

  • Kafka分区重分配
  • 包含启动服务、创建主题、新增服务等操作
  • 查看集群、生成JSON、执行计划
  • 最终确认完成了新加Kafka节点后,分区进行了重分配。

Kafka启动再平衡

我们可以在新建主题的时候,手动指定主题各个Leader分区以及Follower分区的分配情况,即什么分区副本在哪个Broker节点上

随着系统的运行,Broker的宕机重启,会引发Leader分区和Follower分区的角色转换,最后可能Leader大部分都集中在少数几台Broker上,由于Leader负责客户端的读写操作,此时集中Leader分区的少数几台服务器的网络IO和CPU都会很紧张。

Leader和Follower的角色转换会引起Leader副本在集群中分布的不均衡,此时我们需要一种手段,让Leader的分布重新恢复到一个均衡的状态。

启动服务

目前我们需要启动两台Kafka进行测试:

分别在h121 和 h122节点上启动服务

shell 复制代码
kafka-server-start.sh /opt/servers/kafka_2.12-2.7.2/config/server.properties

h121

h122

新建主题

shell 复制代码
kafka-topics.sh --zookeeper h121.wzk.icu:2181 --create --topic topic_test_01 --replica-assignment "0:1,1:0,0:1"

该命令的解释:

  • 创建了主题 topic_test_01
  • 有三个分区,每个分区两个副本

创建的结果如下图:

查看主题

我们可以通过如下的命令进行查看:

shell 复制代码
kafka-topics.sh --zookeeper h121.wzk.icu:2181 --describe --topic topic_test_01 

执行结果如下图:

主题信息

  • 主题名称 topic_test_01
  • 分区数 3
  • 复制因子 2

分区详情

分区0:

  • Leader 0
  • 副本 0,1
  • ISR(同步副本集合)0,1

分区1:

  • Leader 1
  • 副本:1,0
  • ISR(同步副本集合)1,0

分区2:

  • Leader 0
  • 副本 0,1
  • ISR(同步副本集合)0,1

模拟宕机

停止节点

我们结束掉 h122 的机器的Kafka

此时查看我们的主题信息:

shell 复制代码
kafka-topics.sh --zookeeper h121.wzk.icu:2181 --describe --topic topic_test_01

运行结果如下图所示:

分析解释

  • 通过对比我们可以看到,Leader已经全是0了,且ISR为0了。
  • 分区0、1、2的Leader都变成了Broker的Broker0接管了所有分区的Leader角色。
  • 所有分区的ISR现在只包含Broker0,原来包含的Broker1已经从ISR中移除,这表明只有Broker0目前保持同步状态。
  • 副本状态中,尽管Replicase任列出0、1或1、0,但由于Broker1已经停止,实际上只有Broker0保持活跃。

重启节点

我们在刚才停掉的 h122 节点上,重新启动Kafka服务:

shell 复制代码
kafka-server-start.sh /opt/servers/kafka_2.12-2.7.2/config/server.properties

重新启动后,h122是Broker1,继续查看主题的分区:

shell 复制代码
kafka-topics.sh --zookeeper h121.wzk.icu:2181 --describe --topic topic_test_01

观察结果如下:

  • 根据对比,我们发现,Broker恢复了,但是Leader的分配并没有改变,还是出于Leader切换后的状态。
  • 分区还是3个,副本也正常,ISR也正常,但是唯独Leader这一项,会发现都是Broker0,而没有Broker1。

这种问题我们需要让Kafka自动平衡一下。

自动再平衡

脚本介绍

此时,我们需要使用Kafka自动再平衡的脚本:kafka-preferred-replica-election.sh

我们直接运行,可以看到脚本的介绍:

shell 复制代码
kafka-preferred-replica-election.sh

脚本的介绍如下图:

编写JSON

我们编写JSON,这样编写是因为我们开始配置的时候是:

在逗号分割的每个数值对儿中:

● 排在前面的是Leader分区

● 后面的是副本的分区

shell 复制代码
# 这是我们希望的分区状况
--replica-assignment "0:1,1:0,0:1"

所以我们编写的JSON内容如下:

shell 复制代码
vim topic_test_01_preferred-replica.json


{
  "partitions": [
    {
      "topic": "topic_test_01",
      "partition": 0
    },
    {
      "topic": "topic_test_01",
      "partition": 1
    },
    {
      "topic": "topic_test_01",
      "partition": 2
    }
  ]
}

写入的内容如下图所示:

运行测试

执行如下的脚本:

shell 复制代码
kafka-preferred-replica-election.sh --zookeeper h121.wzk.icu:2181 --path-to-json-file topic_test_01_preferred-replica.json

运行后返回的结果如下:

查看分区

我们再次查看分区:

shell 复制代码
kafka-topics.sh --zookeeper h121.wzk.icu:2181 --describe --topic topic_test_01

执行的结果如下图所示:

我们可以观察到,此时的Leader中,已经重新平衡了:Leader0、Leader1、Leader0。

相关推荐
木头没有瓜6 分钟前
ruoyi 请求参数类型不匹配,参数[giftId]要求类型为:‘java.lang.Long‘,但输入值为:‘orderGiftUnionList
android·java·okhttp
奋斗的老史6 分钟前
Spring Retry + Redis Watch实现高并发乐观锁
java·redis·spring
high20118 分钟前
【Java 基础】-- ArrayList 和 Linkedlist
java·开发语言
老马啸西风15 分钟前
NLP 中文拼写检测纠正论文 C-LLM Learn to CSC Errors Character by Character
java
TDengine (老段)27 分钟前
两分钟掌握 TDengine 全部写入方式
大数据·数据库·时序数据库·tdengine·涛思数据
Cosmoshhhyyy37 分钟前
LeetCode:3083. 字符串及其反转中是否存在同一子字符串(哈希 Java)
java·leetcode·哈希算法
AI人H哥会Java1 小时前
【Spring】基于XML的Spring容器配置——<bean>标签与属性解析
java·开发语言·spring boot·后端·架构
开心工作室_kaic1 小时前
springboot493基于java的美食信息推荐系统的设计与实现(论文+源码)_kaic
java·开发语言·美食
缺少动力的火车1 小时前
Java前端基础—HTML
java·前端·html