一次“失败”的技术选型复盘：我们为什么放弃了Kafka？

一次“失败”的技术选型复盘：我们为什么放弃了Kafka？
在技术选型的道路上，没有绝对的“正确”或“错误”，只有是否适合当前场景。我们团队曾满怀信心地选择了Kafka作为消息队列的核心组件，却在落地过程中遭遇了诸多挑战，最终不得不做出放弃的决定。本文将复盘这次“失败”的技术选型，从多个维度分析原因，希望能为同行提供一些借鉴。
运维成本超出预期
Kafka的部署和运维复杂度远超我们最初的预估。虽然它的高吞吐和低延迟特性非常吸引人，但为了实现这些优势，我们需要投入大量资源进行集群管理、监控和调优。尤其是在规模较小时，Kafka的运维成本显得过于沉重，而团队缺乏足够的人力去应对这些挑战。相比之下，其他轻量级消息队列（如RabbitMQ）在中小规模场景下更易于维护。
业务场景适配不足
我们的业务场景对消息的实时性和顺序性要求并不高，反而更关注消息的可靠性和易用性。Kafka的“至少一次”投递机制虽然强大，但在某些边缘情况下仍可能导致消息重复消费，而我们的业务逻辑对重复消息的容忍度较低。Kafka的消费者组机制在动态扩缩容时表现不佳，而我们的业务需求恰恰需要频繁调整消费者数量。这些适配问题最终让我们意识到，Kafka可能并不是最优解。
团队技术储备有限
Kafka的学习曲线相对陡峭，尤其是其底层原理（如分区、副本同步、ISR机制等）需要较长时间掌握。我们的团队此前主要使用简单的消息队列（如Redis的List结构），切换到Kafka后，开发效率显著下降。尽管Kafka社区提供了丰富的文档，但在实际调试和问题排查时，团队仍感到力不从心。技术储备不足导致我们在遇到问题时无法快速解决，进一步放大了Kafka的劣势。
总结来看，Kafka无疑是一款优秀的分布式消息系统，但它并不适合所有场景。我们的“失败”并非技术本身的缺陷，而是选型时未能充分权衡业务需求、运维成本和团队能力。希望这次复盘能为其他团队提供参考，避免类似的弯路。