Kafka常见痛点及优化方案

1.集群木桶效应，broker雪崩

痛点：
当整个集群当leader和follower分布不均衡时，这可能导致流量分布不均衡。一部分节点比较空闲，一部分节点负载过高（这里当负载主要是磁盘IO与网络带宽，CPU基本上不会成为Kafka的瓶颈）。最后导致出现大量副本缺失，直至broker挂掉后，流量压力转移到另外一个broker节点，很可能这个节点也会因为负载过大而被打挂。

优化方案：
1）实现一套自动负载均衡程序，自动生成均衡计划，逐个topic进行均衡。【推荐】
2）手动切换分区leader或者进行副本迁移；【效率低，不推荐】

2.集群扩容无法自动负载均衡

痛点：
当扩容集群时，topic的分区生产消费无法落在新加入的broker节点上。这样相当于已经存在的topic读写数据无法落在新broker节点上，从而新节点无法得到充分利用。

优化方案：
1）实现一套自动负载均衡程序，自动生成均衡计划，逐个topic进行均衡。【推荐】
2）手动切换分区leader或者进行副本迁移；【效率低，不推荐】

3.集群副本迁移影响集群稳定，迁移任务不可控

痛点：
当需要迁移的分区数据量比较大时（单分区数据量超过100GB以上），这将导致迁移任务启动的新副本会从leader所在的broker节点大量拉取历史数据。这可能带来以下问题：
1）broker的磁盘IO被持续打满；
2）操作系统pagecache受到污染，导致生产消费延迟；
3）出现大量副本缺失；
4）迁移任务一旦开启便无法停止，只有让其执行失败或者成果才能结束。

优化方案：
1）改造源码，从最新偏移量开始同步数据，实现增量副本迁移；
2）增量迁移，新副本加入isr列表的时机可以根据当前分区是否有消费延迟和指定同步时间两个方面去考虑；
3）修改源码，对迁移任务添加可手动终止功能；

4.异常流量打挂集群

痛点：
当出现入流量当突增或出流量当突增时，可能造成broker节点负载过大（经常时磁盘IO被持续打满到100%）。以下情况容易造成流量突增：
1）新业务上线，数据源加入了新的大业务，生产者写入流量突增；
2）消费端程序从历史最早位置开始消费，拉去大量历史数据；
3）消费端程序停止服务一段时间后，重启追数；
4）大topic在消费端程序有新的消费者组加入，出流量突增；

优化方案：
1）根据用户维度，对各集群用户的出入流量进行限制；保证单个broker节点上所有用户的出入流量之和在broker的处理能力范围内；

5.一个业务异常影响整个集群稳定

痛点：
当某个业务的部分topic异常时，可能会影响到集群上的其他业务。

优化方案：
根据不同业务线，以资源组为单位对集群进行物理隔离，让各业务线的topic都是分布在自己的资源组内。不受其他业务线影响

6.pagecache污染及优化

痛点：
1）大量拉去历史数据，导致pagecache污染，造成生产消费延迟；

优化方案：
1）对pagecache参数进行调优；文章地址：https://blog.youkuaiyun.com/yangyijun1990/article/details/105341785
2）修改源码，对kafka的cache进行改造。自定义一套cache，专门用来做消费cache。保证副本同步和拉取历史数据不会污染最近生产的数据。

7.磁盘故障或者坏道，整个broker半死不活

痛点：
1）当整块磁盘故障或出现磁盘坏道情况，整个broker部分分区可以读写，部分分区无法读写；broker进程不会主动推出，坏道所影响的分区消费一直被卡住，同时造成数据丢失。

优化方案：
1）当整块磁盘故障或者坏道时，消费者消费会在服务端抛出一些特定关键字符串当异常信息，用程序扫描异常信息，检测到后，把对应的磁盘从 log.dirs 中剔除；

8.同一个消费者组消费多个topic问题

痛点：
1）当同一个消费者组消费多个topic，无法回收消费者组下某个topic的读权限，只能对整个组下面的topic进行读权限回收；
2）消费组内多个topic间经常出现join操作，导致topic分区重新分配，影响整个组下面topic消费；

优化方案：
1）限定一个组只能消费一个topic；

9.所有请求竞争同一个阻塞请求队列

痛点：
1）kafka中所有请求，包括元数据请求及生产消费请求，全部使用了同一个请求队列。当集群达到一定规模后，出现请求队列被用完，不同类型的请求相互影响，相同类型的请求也会相互影响，被阻塞。

优化方案：
1）根据不同的请求类型，对请求队列进行拆分；这里主要是分为元数据类请求、生产请求、消费请求三类；

10.核心业务无法实现跨集群高可用

核心业务采用多链路来实现跨集群高可用。