linkedin启动TopicGC删除Kafka不用的topic后，已经删除了近20%的topic，大大降低了Kafka集群的元数据压力。客户端请求性能提高了 40% 左右，CPU 使用率降低了 30%。
Apache Kafka 是一个开源的事件流平台，用户可以在其中创建 Kafka 主题作为数据传输单元，然后与生产者和消费者发布或订阅该主题。虽然大多数 Kafka 主题都被积极使用，但由于业务需求发生变化或主题本身是短暂的，因此不再需要某些主题。
Kafka 本身没有自动检测未使用的主题并删除它们的机制。这通常不是什么大问题，因为 Kafka 集群可以容纳相当多的主题，数百到数千个。
但是，如果主题数量不断增长，它最终会遇到瓶颈并对整个 Kafka 集群产生破坏性影响。
linkedin的TopicGC 服务就是为了解决这个问题而诞生的。事实证明，删除约 20% 的主题可以减少 Kafka 的压力：
元数据压力
出于主题管理的目的，Kafka 将主题的元数据存储在多个位置，包括 Apache ZooKeeper 和每个代理上的元数据缓存。主题元数据包含分区和副本分配的信息。
我们这里做个简单的计算：topic A可以有25个partition，复制因子为3，也就是说每个partition有3个replicas。即使主题 A 不再被使用，Kafka 仍然需要将所有 75 个副本的位置信息存储在某个地方。
元数据压力对单个主题的影响可能不那么明显，但如果主题很多，它就会产生很大的影响。元数据可以消耗来自 Kafka 代理和 ZooKeeper 节点的内存，并且可以向元数据请求添加有效负载。
获取请求
在 Kafka 中，follower 副本定期向 leader 副本发送获取请求以与 leader 保持同步。即使对于空主题和分区，追随者仍会尝试与领导者同步。因为 Kafka 不知道一个主题是否永久未使用，它总是强制跟随者从领导者那里获取。这些冗余的获取请求将进一步导致创建更多的获取线程，这可能会导致额外的网络、CPU 和内存占用，并可能支配请求队列，导致其他请求被延迟甚至丢弃。
控制器初始化
Kafka 控制器是协调和管理 Kafka 集群中其他代理的代理。许多 Kafka 请求必须由控制器处理，因此控制器可用性对 Kafka 至关重要。
在控制器故障转移时，必须选出一个新控制器并接管管理集群的角色。新的controller在充当controller之前，会从ZooKeeper中加载整个集群的元数据，这个时间叫做controller initialization time。正如本文前面提到的，未使用的主题会生成额外的元数据，使控制器初始化速度变慢，并威胁到 Kafka 的可用性。当 ZooKeeper 响应大于 1MB 时，可能会出现问题。对于我们最大的集群之一，ZooKeeper 响应已经达到 0.75MB，我们预计在两到三年内它将遇到瓶颈。
详细点击标题