kafka问题

Log Cleaner 无限膨胀占用过多磁盘空间

Kafka提供了专门的后台线程定期地巡检待Compact的主题，看看是否存在满足条件的可删除数据 K 。这个后 台线程叫Log Cleaner。很多实际生产环境中都出现过位移主题无限膨胀占用过多磁盘空间的问题，如果你 的环境中也有这个问题，我建议你去检查一下Log Cleaner线程的状态，通常都是这个线程挂掉了导致的。

消费者组重平衡能避免吗？

你可能会对这里提到的“协调者”有些陌生，我来简单介绍下。所谓协调者，在Kafka中对应的术语是 Coordinator，它专门为Consumer Group服务，负责为Group执行Rebalance以及提供位移管理和组成员管 理等。

所有Broker在启动时，都会创建和开启相应的Coordinator组件。也就是说，所有Broker都有各自的 所 Coordinator组件 C 。那么，Consumer Group如何确定为它服务的Coordinator在哪台Broker上呢？答案就在 我们之前说过的Kafka内部位移主题__consumer_offsets身上。

那么，Rebalance的弊端是什么呢？总结起来有以下3点：

1. Rebalance影响Consumer端TPS。这个之前也反复提到了，这里就不再具体讲了。总之就是，在 Rebalance期间，Consumer会停下手头的事情，什么也干不了。
2. 2. Rebalance很慢。如果你的Group下成员很多，就一定会有这样的痛点。还记得我曾经举过的那个国外用 户的例子吧？他的Group下有几百个Consumer实例，Rebalance一次要几个小时。在那种场景下，Consumer Group的Rebalance已经完全失控了。
3. Rebalance效率不高。当前Kafka的设计机制决定了每次Rebalance时，Group下的所有成员都要参与进 来，而且通常不会考虑局部性原理，但局部性原理对提升系统性能是特别重要的。

怪不得 阿里最佳实践，一个消费者 3-5个topic最佳 减低rebalance

要避免Rebalance，还是要从Rebalance发生的时机入手。我们在前面说过，Rebalance发生的时机有三个：
组成员数量发生变化
订阅主题数量发生变化
订阅主题的分区数发生变化

如果

Consumer Group下的Consumer实例数量发生变化

，就一定会引发Rebalance。这是Rebalance发生的 最常见的原因。我碰到的99%的Rebalance，都是这个原因导致的。

我们更在意的是Group下实例数减少这件事。如果你就是要停掉某些Consumer实例，那自不必说，关键是 在某些情况下，Consumer实例会被Coordinator错误地认为“已停止”从而被“踢出”Group。如果是这个 原因导致的Rebalance，我们就不能不管了。