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

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

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
    当前运行过程中的分区分布情况

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

AR

Leader(ISR)

说明

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

好了，本文就介绍到这里了，一键三连(关注、点赞、留言)是对我最大的鼓励。
掌握一到两门java主流中间件，是敲开BAT等大厂必备的技能，送给大家一个Java中间件学习路线，助力大家实现职场的蜕变。

不整理不知道，中间件兴趣圈已发表12个专栏、3本电子书、两个开源项目(建议收藏)​mp.weixin.qq.com/s/iKQvIccBlNPPhRUDZ52nrw

最后分享笔者一个硬核的RocketMQ电子书，您将获得千亿级消息流转的运维经验，助你轻松打造自己的职场亮点。

下载地址：

rocketmqpdf.zip-Java文档类资源-CSDN下载​download.csdn.net/download/prestigeding/18212152?spm=1001.2014.3001.5503

你的点赞，关注、收藏是最对我最大的认可与帮助，一起加油吧。

原网址: 访问
创建于: 2021-08-18 14:22:44
目录: default
标签: 无

未标明原创文章均为采集，版权归作者所有，转载无需和我联系，请注明原出处，南摩阿彌陀佛，知识，不只知道，要得到

请先后发表评论
  • 最新评论
  • 总共0条评论