大数据-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节点上启动服务

登录后复制

kafka-server-start.sh /opt/servers/kafka_2.12-2.7.2/config/server.properties

• 1.

h121

h122

新建主题

登录后复制

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

• 1.

该命令的解释：

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

创建的结果如下图：

查看主题

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

登录后复制

kafka-topics.sh --zookeeper h121.wzk.icu:2181 --describe --topic topic_test_01

• 1.

执行结果如下图：

主题信息

• 主题名称 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

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

登录后复制

kafka-topics.sh --zookeeper h121.wzk.icu:2181 --describe --topic topic_test_01

• 1.

运行结果如下图所示：

分析解释

• 通过对比我们可以看到，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服务：

登录后复制

kafka-server-start.sh /opt/servers/kafka_2.12-2.7.2/config/server.properties

• 1.

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

登录后复制

kafka-topics.sh --zookeeper h121.wzk.icu:2181 --describe --topic topic_test_01

• 1.

观察结果如下：

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

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

自动再平衡

脚本介绍

此时，我们需要使用Kafka自动再平衡的脚本：kafka-preferred-replica-election.sh
我们直接运行，可以看到脚本的介绍：

登录后复制

kafka-preferred-replica-election.sh

• 1.

脚本的介绍如下图：

编写JSON

我们编写JSON，这样编写是因为我们开始配置的时候是：
在逗号分割的每个数值对儿中：
● 排在前面的是Leader分区
● 后面的是副本的分区

登录后复制

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

• 1.
• 2.

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

登录后复制

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

• 1.
• 2.
• 3.
• 4.
• 5.
• 6.
• 7.
• 8.
• 9.
• 10.
• 11.
• 12.
• 13.
• 14.
• 15.
• 16.
• 17.
• 18.
• 19.

写入的内容如下图所示：

运行测试

执行如下的脚本：

登录后复制

kafka-preferred-replica-election.sh --zookeeper h121.wzk.icu:2181 --path-to-json-file topic_test_01_preferred-replica.json

• 1.

运行后返回的结果如下：

查看分区

我们再次查看分区：

登录后复制

kafka-topics.sh --zookeeper h121.wzk.icu:2181 --describe --topic topic_test_01

• 1.

执行的结果如下图所示：

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

原创作者: u_16814091 转载于: https://blog.51cto.com/u_16814091/11731269