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

Posted 2023-04-01 m0_69379016

[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分区 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的利用率只有３分之一，抽取几个数据量大的主题，判断其路由信息，得知都分布在第一个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

结语

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

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

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

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

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

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

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

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

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

你为什么当不了架构师？除了技术，你还需具备这些能力

为什么人人都想成为架构师？不外乎这几点：能力强，工资高，有底气。但是有80%的程序员是成不了架构师，这说明架构师的稀缺性。今天就带你走进架构师世界，帮助你更好了解什么是架构师必备技能。

架构师需具备的特殊能力？

想要成为一名架构师，必须具备快速解决系统故障的能力，和可以在项目中做到统筹兼顾。因此，在技术要求方面，像Linux/ WebServer(Apache或Nginx)/ MYSQL 等基础服务的配置，优化和故障排查，根据不同的环境和要求，需要具备更多的如Memcached,NOSQL, 等服务的配置、优化和故障排查。都需要掌握和理解。除此之外，必须精通至少一门语言，如 PHP。掌握其他一些数据分析和日志分析的能力。

到了架构师这一层面，要做的是解决现实碰到的问题，包括技术的问题，产品的问题，实现系统性能的最优化，系统稳定性的保障等。此时衡量一个人的能力，不是能写多少代码，实现多少种算法，而是是否能用最快速的方法，有效地解决当前的需求或故障。

技术不是唯一？

有一定经验的程序员都清楚，在工作中必须要有强大的自学能力，没有人会手把手的教给你所有的东西。很多技术都是自己摸索学习，想成为架构师不是懂了一大堆技术就可以。技术只是解决问题的基础、是工具，它只是帮助程序员在遇到问题时懂得如何提解决方案。

我们要明白，架构师是做什么？

首先，出具针对性解决方，即“1+1=2”。针对业务特点、系统的性能要求提出、能解决问题、成本低的设计方案。例如说，假如是一个几百人用户系统，访问量不大，数据量小，这时如果上集群、上分布式存储、上高端服务器这些，单纯性的为了架构而架构，不仅不会解决问题，更会显得莫名其妙。

架构师的作用就是要满足业务需求，用低的硬件网络成本和技术维护成本。

业务方面

上面有提架构师还需要具备统筹兼顾的能力，在业务发展阶段，他们要提前预见发展到下一个阶段系统架构的解决方案，并且设计当前架构时将架构的升级扩展考虑进去，做到易于升级。

当然沟通协调力与领导力也缺一不可。因为架构师的作用是把整个团队力量凝聚在一起，带动团队共同设计，让知识流动起来，从而让设计达到一个新高度。这中间人员协调、需求理解、核心架构都需要架构师来把控。

因此，仅仅只有20%的程序员登上架构师这做金字塔，享受高新待遇。透过某招聘网站得知，2019年腾讯PHP架构师薪酬达30k-60k，依据腾讯工资体系。能力突出者则可以自己谈工资。以下是腾讯企业对于PHP架构师要求，你可以达到吗

如果还在为自己技术有限而懊恼？如果你有心进大厂却拿不到进去门票，请关注我吧！