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

[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只在4个broker上创建了队列,那使用率为80%。

  • Brokers Skew %

topic的队列倾斜率。如果集群中存在5个broker节点,topic的总分区数量为4,副本因子为2,但这些队列只分布在其中的4台broker中。那topic的broker使用率(Broker Spread)为80%

众所周知,引入多节点的目的就是负载均衡,队列在broker中的分配自然是希望越均衡越好,期望每台broker上存储2个队列(副本因子为2,总共8个队列),表示没有发生倾斜,如果一台broker中的存在3个队列,而另外一个broker上1个队列,那说明发生了倾斜,计算公式为超过平均队列数的broker节点个数除以总所在Broker数量,其Brokers Skew等于(1/3)=33%。

  • Brokers Leader Skew %

topic分区中Leader分区的倾斜率。在Kafka中,只有分区的Leader节点具有读写权限,真正影响性能读写性能的是Leader分区是否均衡,试想一下,如果一个topic有6个分区,但所有的Leader分区 Java开源项目【ali1024.coding.net/public/P7/Java/git】 只分布在一两个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的利用率只有3分之一,抽取几个数据量大的主题,判断其路由信息,得知都分布在第一个Broker节点上,这样就导致其中一个节点大量出现文章开头部分提到的错误:Too many open files

[](()3、解决方案


[](()3.1 扩分区

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

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

[](()3.1.1 通过Kafka-manager

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

![在这里插入图片描述](https://img-blog.csdnimg.cn/20210520221353972.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3ByZXN0aWdlZGluZw==,size_16,color_FFFFFF,t_70#p 《一线大厂Java面试题解析+后端开发学习笔记+最新架构讲解视频+实战项目源码讲义》开源 ic_center)

Step2:点击增加分区,弹出如下框:

在这里插入图片描述

说明如下:

  • Partitions

扩容后的总分区个数,并不是本次增加的分区个数。

  • Brokers

分区需要分布的Broker,建议全选,充分利用整个集群的性能。

[](()3.1.2 运维命令

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

在这里插入图片描述

温馨提示: 对这些运维命令不熟悉没关系,基本都提供了–help

[](()3.2 分区移动

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

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

[](()3.2.1 kafka-manager

结语

小编也是很有感触,如果一直都是在中小公司,没有接触过大型的互联网架构设计的话,只靠自己看书去提升可能一辈子都很难达到高级架构师的技术和认知高度。向厉害的人去学习是最有效减少时间摸索、精力浪费的方式。

我们选择的这个行业就一直要持续的学习,又很吃青春饭。

虽然大家可能经常见到说程序员年薪几十万,但这样的人毕竟不是大部份,要么是有名校光环,要么是在阿里华为这样的大企业。年龄一大,更有可能被裁。

送给每一位想学习Java小伙伴,用来提升自己。

通过一个Kafka故障解决过程阐述架构师必须具备的架构思维_第1张图片

本文到这里就结束了,喜欢的朋友可以帮忙点赞和评论一下,感谢支持!
直要持续的学习,又很吃青春饭。

虽然大家可能经常见到说程序员年薪几十万,但这样的人毕竟不是大部份,要么是有名校光环,要么是在阿里华为这样的大企业。年龄一大,更有可能被裁。

送给每一位想学习Java小伙伴,用来提升自己。

[外链图片转存中…(img-y4JPbdxG-1650019095941)]

本文到这里就结束了,喜欢的朋友可以帮忙点赞和评论一下,感谢支持!

你可能感兴趣的:(Java,经验分享,面试)