kafka有什么缺点？

Kafka 作为一个高吞吐、分布式的流处理平台，在大数据和日志收集领域表现卓越，但其底层架构设计也决定了它在某些场景下存在明显的局限性。综合来看，Kafka 的主要缺点可以归结为以下几个核心维度：

一、 运维与架构复杂度高

• 组件与配置繁多：Kafka 集群涉及 Broker、ZooKeeper（或 KRaft）、生产者、消费者、主题、分区等众多概念。要保证其高性能和高可用，需要精细调优大量参数，对运维团队的技术能力要求极高。
• 资源消耗大：Kafka 高度依赖磁盘和操作系统页缓存（Page Cache），且需维护大量网络连接和元数据。典型的配置通常需要高性能的 SSD 硬盘、大容量内存（如 64GB）及多核 CPU，基础设施成本较高。
• 扩容成本较高：新增的 Broker 默认只处理新 Topic。若要分担老 Topic 的分区压力，需要手动迁移 Partition，此过程会占用大量集群带宽，且无法做到无缝的弹性扩容。

二、 消息延迟与实时性受限

• 非极低延迟：Kafka 的高吞吐量在一定程度上是通过“批量处理”换来的。生产者默认会积累一批数据后再发送，消费者也是批量拉取。这种机制导致其端到端延迟通常在毫秒级，不适合对延迟极度敏感（如微秒级）的金融交易场景。
• Rebalance（再平衡）影响：当消费者组内有新消费者加入或退出时，会触发整个消费组的 Rebalance。这会导致数据短暂不可用或重复消费，增加端到端延迟。

三、 消息模型与功能相对简单

• 不支持复杂路由：Kafka 遵循“一个分区只能被消费者组内的一个消费者消费”的原则，不支持类似 RabbitMQ 那样灵活的 Exchange 和消息路由规则。实现复杂路由通常需要创建多个 Topic 或在消费端自行过滤。
• 仅保证分区内有序：Kafka 只能保证单个 Partition 内部的消息是有序的，无法实现全局消息有序。
• 缺乏内置重试与死信队列：Kafka 本身不提供内置的死信队列（DLQ）或自动重试机制，这些功能需要由应用层自行实现，增加了业务代码的复杂度。

四、 分布式环境下的可靠性风险

• 消息重复与乱序风险：在分布式环境下，为了保证数据不丢失，Kafka 在生产端重试机制和消费端故障再均衡时，都可能引入少量消息重复的风险。如果参数设置不当，也可能出现消息乱序。这要求业务端的消费者必须具备幂等性处理能力。

五、 特定场景下的性能瓶颈

• 不适合海量主题或低吞吐场景：每个分区都会在 Broker 上产生一组文件句柄和内存开销。如果集群中存在成千上万个 Topic，或者大量消息量极低的 Topic，会严重浪费资源并导致性能显著下降。
• 不适合处理小消息体：如果消息体非常小（如只有几个字节），消息本身的有效负载与网络传输、存储带来的元数据开销相比效率极低。此时应考虑在发送端进行批量压缩或合并。
• 分区并非越多越好：盲目增加分区数量会导致日志 Segment 过于分散，操作系统的 Page Cache 效果变差，甚至可能让磁盘的顺序写退化为随机写，反而使性能显著下降。