💯 作者： 谢先生。 2014 年入行的程序猿。多年开发和架构经验。专注于 Java、云原生、大数据等技术。从 CRUD 入行，负责过亿级流量架构的设计和落地，解决了千万级数据治理问题。

📖 微信公众号、B 站：搜索「谢先生说技术」不定时更新 ～

📂 清单： goku-framework、【定期开源】享阅读II

前言

每个文思泉涌的时刻都来自深夜。 而且也来自早晨，比如说这篇文章就是每一个早晨不断码字码出来的。

年龄大了，不好熬夜～

系统环境中由于业务不断调整，集群中 Broker 节点数量并不固定，此时不可避免的需要动态增减节点：

• Broker 增加还好，并不会影响到 Topic 的分布，原来已经创建好的 Topic 数据不会进行扩散，但是新 Topic 产生的 Partitions 将会在新增 Broker 上生效

• 而当集群中的 Broker 节点被移除，由于 Partitions 分布在不同 Broker 节点上，甚至会出现当前节点存在 Leader 分区的情况，此时直接移除节点造成 Partitions 中出现：Leader 故障 Follower 故障数据重复或者数据丢失

关于引发故障原理性内容，我们在下一节中介绍～

Broker 负载计划

为了最小程度的减少集群的不可用，我们需要人为手动干预整个 Broker 节点的操作。这就是接下来要隆重上场的主角：- kafka-reassign-partitions.sh

当前脚本主要负责对分区重分配，当集群中 Broker 出现新增、下线时能够对 Topic 数据进行迁移。人为干预下从而保证每个 Broker 节点负载均衡。

通过查看帮助文档我们来找几个关键信息：

• --broker-list： 设置 partition 重分配的 broker 来源信息，已"0,1,2"的形式传递， --topics-to-move-json-file 必填

• --topics-to-move-json-file： 生成负载计划时的 Topic 信息文件，包含了某些 topic 需要做重新分配

• --generate： 通过 --topics-to-move-json-file 提供信息生成负载计划，负载计划展示在终端，需要拷贝到文件内

• --execute： 通过 --reassignment-json-file 指定的负载计划文件开始执行该计划

• --verify： 验证重新分配是否按照 --reassignment-json-file 指定的文件分配完成

这么说可能不是那么明显，接下来我们就实际操作一把，看看具体的效果。

脚本实操

常规情况下 kafka-reassign-partitions.sh 执行需要三个步骤：

• 首先需要准备一份包含 Topic 信息的 JSON 文件，具体格式如下：

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

• 通过执行脚本命令，结合 JSON 文件与 Broker 节点 ID 生成负载均衡计划

• 最后执行该计划并进行验证

根据命令描述帮助也能看到具体说明～

Broker 节点新增

我们先来提前准备一个 Topic，这里需要注意：

• 本次没有启动 node02 节点，故而 ISR 节点少一个

kafka-topics.sh --bootstrap-server master:9092 --create --topic test_res --replication-factor 2 --partitions 3
kafka-topics.sh --bootstrap-server master:9092 --describe --topic test_res

image.png

ISR 节点只有 0、1

随后我们将 node02 节点启动，分片与副本不会与已经创建 Topic 有任何关系随后我们开始创建负载计划，先准备一个 JSON 文件

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

通过如下命令生成负载计划，以下参数前面都已经介绍过

kafka-reassign-partitions.sh --bootstrap-server master:9092 --broker-list "0,1,2" --topics-to-move-json-file a.json --generate

这里需要注意：已 Proposed partition reassignment configuration 为分界线，复制以下内容

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

然后我们执行如下命令

kafka-reassign-partitions.sh --bootstrap-server master:9092 --reassignment-json-file b.json --execute

其实现在已经执行成功，但是我们再次进行校验：

kafka-reassign-partitions.sh --bootstrap-server master:9092 --reassignment-json-file b.json --verify

image.png

随后查看 topic 详情：

image.png

Broker 下线

前面我们复制了一段 JSON 内容，其实我们是可以自定义的当我们想要下线某个 Broker，我们可以通过修改其中 replicas 来进行，比如：

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

此时我们就可以省去--generate的步骤，直接执行计划文件。此处都是重复内容，留下截图一张：

最后结果与第一步创建 Topic 一般无二。

最后

作为一个脚本的使用还单独开了一个章节，能够在真实生产环境中被使用才是重中之重。接下来就会进入 Broker 系列内容的重头戏： 关于对副本的介绍。 精彩不好走开，马上回来。期待～

- END -