通过一个Kafka故障解决过程阐述架构师必须具备的架构思维

本文是Kafka系列第4篇，从问题出发，从而探讨集群分区迁移实战、底层原理以及运维时需要考虑的问题。

掌握一到两门java主流中间件，是敲开BAT等大厂必备的技能，送给大家一个Java中间件学习路线，助力大家实现职场的蜕变。

​​Java进阶之梯，成长路线与学习资料，助力突破中间件领域​​

1、问题描述

某一天突然收到开发环境Kafka报 IO Exception(many open files)，其相关的日志如下：

问题是发生在公司的开发环境，为了避免信息泄露，我在本地进行了模拟，不影响本次问题的分析与学习。

2、问题分析

首先我们要能看懂Kafka-manager上的一些监控指标，topic列表中关于topic的信息项如下所示：

• topic
  topic名称
• Partitions
  分区数
• Brokers该topic 队列分布的broker数量。Brokers Spread %该topic中队列在Broker中的使用率，例如集群中有5个broker，但topic只在４个broker上创建了队列，那使用率为80％。Brokers Skew %topic的队列倾斜率。如果集群中存在5个broker节点，topic的总分区数量为4,副本因子为2，但这些队列只分布在其中的４台broker中。那topic的broker使用率(Broker Spread)为80%。众所周知，引入多节点的目的就是负载均衡，队列在broker中的分配自然是希望越均衡越好，期望每台broker上存储2个队列(副本因子为2，总共８个队列)，表示没有发生倾斜，如果一台broker中的存在３个队列，而另外一个broker上１个队列，那说明发生了倾斜，计算公式为超过平均队列数的broker节点个数除以总所在Broker数量，其Brokers Skew等于(1/3)=33%。Brokers Leader Skew %topic分区中Leader分区的倾斜率。在Kafka中，只有分区的Leader节点具有读写权限，真正影响性能读写性能的是Leader分区是否均衡，试想一下，如果一个topic有6个分区，但所有的Leader分区只分布在一两个Broker节点上，这个topic的写入、读取性能将受到制约，这个值建议维持在0％。Replicas副本数、副本因子，即一个分区数据存储的份数，该数值包含Leader分区。Under Replicated %没有跟上复制进度的副本比例，在Kafka的复制模型中，主分区负责读写，该复制组内的其他副本从主节点同步数据，如果跟不上主节点的复制进度，将被提出ISR，被剔除ISR的副本不具备选举Leader的资格，这个数据如果长期或频繁高于0，说明集群一定出现了问题。Producer Message/Sec消息发送实时TPS，通过JMX采集，需要在kafka-manager中开启如下参数：

• Summed Recent Offsets
  该主题当前最大的消息偏移量。

经过对Topic列表观察，发现开发环境存在大量的topic都只有一个队列，并且都分布在第一节点上，其截图如下：

从界面上对应的指标：Brokers Spread即Broker的利用率只有３分之一，抽取几个数据量大的主题，判断其路由信息，得知都分布在第一个Broker节点上，这样就导致其中一个节点大量出现文章开头部分提到的错误：Too many open files。

3、解决方案

3.1 扩分区

问题定位出来了，由于Broker利用率不均匀，大量topic只创建了一个队列，并且还集中落到了第一个节点。

针对这种情况，首先想到的方案：扩分区。

3.1.1 通过Kafka-manager

Step1：在Kafka-manager的topic列表，点击具体的topic，进入详情页面，点击[add Partitions]，如图所示：

Step2：点击增加分区，弹出如下框：

说明如下：

• Partitions
  扩容后的总分区个数，并不是本次增加的分区个数。
• Brokers
  分区需要分布的Broker，建议全选，充分利用整个集群的性能。

3.1.2 运维命令

可以通过Kafka提供的kafka-topics命令，修改topic的分区，具体参考如下：

温馨提示：对这些运维命令不熟悉没关系，基本都提供了--help

3.2 分区移动

由于存在大量的只有一个分区的topic，并且这些topic都分布到了第一个节点，是不是可以将某些topic的分区移动到其他节点呢？

接下来介绍一下分区移动如何操作。

3.2.1 kafka-manager

Step1：进入topic详情页面，点击[Generate Partition Assignments]，如下图所示：

Step2：进入页面后，选择需要迁移到的brroker，还可以改变topic的副本因子，最后点击[Generate Partition Assignments]，如下图所示：

Step3：点击完成后，此时只是生成了分区迁移计划，并没有真正的执行，需要点击[Reassign Parttions]按钮。

3.2.2 运维命令

Step1：首先我们需要准备需要执行迁移的topic信息，例如将如下信息保存在文件dw_test_kafka_040802-topics-to-move.json中。

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

Step2：使用kafka提供的kafka-reassign-partitions.sh命令生成执行计划

上面的参数其实对照kafka-manager的图理解起来会更快，点出如下关键点：

• --broker-list
  分区需要分布的broker。如果多个，使用双引号，例如 "0,1,2"。
• --topics-to-move-json-file
  需要执行迁移的topic列表。
• --generate
  表示生成执行计划(并不真正执行)

执行成功后会输出当前的分区分布计划与新的执行计划，通常我们可以先将当前的执行计划存储到一个备份目录中，将新生成的计划存储到一个文件中。

Step3：使用kafka提供的kafka-reassign-partitions.sh命令执行分区迁移计划

其关键点如下：

• --reassignment-json-file
  指定上一步骤生成的执行计划。

执行成功过后输出Successfully，重分区是一个非常复杂的过程，命令执行完成后，并不会真正执行完成，可以通过查询主题的详细信息来判断是否真正迁移成功。

4、进阶与架构思维

通过kafka-reassign-partitions.sh对分区进行迁移，会影响业务方的正常使用吗？即会影响消息的消费与发送吗？

作为一名架构师，特别是对中间件做变更时，考虑对业务的影响范围是必备的一步，直接影响到实施的复杂度。

我们需要对分区迁移的实现原理做进一步探究，本文暂不从源码角度详细剖析，只是举例阐述一下分区迁移的实现机制。

需求：一个TopicA的其中一个分区p0，分布在broker id为1,2,3上，目前要将其迁移到brokerId为4,5,6。

在介绍迁移过程之前，我们先定义三个变量：

• OAR
  迁移前分区的分布情况。
• RAR
  迁移后的分区分布情况
• AR
  当前运行过程中的分区分布情况

结合上述例子，其整个迁移步骤如下：

从上面这个过程，只有在Leader选举期间会对消息发送、消息消费造成影响，但通过Zookeeper实现Leader选举可在秒级别响应，结合Kafka消息发送端的缓冲队列、重试机制，在理论上可以做到对业务无影响。

文章转载自公众号：中间件兴趣圈