为什么Kafka不是Saga实现的首选消息中间件？与传统MQ差异解析

• 原生消息优先级机制：RabbitMQ、ActiveMQ都支持在队列/消息维度配置优先级，高优先级消息可被优先消费，Kafka原生完全不支持该能力，只能自行在业务层按主题拆分模拟，额外开销极高。
• *死信队列（DLQ）*的原生自动化处理：传统MQ可配置消费失败重试次数阈值，超限后自动投递到死信队列无需业务干预，Kafka需要自行实现消费失败计数、死信主题投递的全链路逻辑。
• 精准的单条消息确认机制（ACK per message）：传统MQ支持消费端单条消费完成后单独确认，Kafka的位移提交是按分区的偏移量递增提交，一旦提交了某个偏移量，该偏移量之前的所有消息都默认被确认，无法单独跳过某条异常消息继续消费后续消息。
• 原生的延迟消息/定时消息能力：ActiveMQ、RabbitMQ（配合内置插件）都支持指定消息延迟投递时间，Kafka原生不支持，需要自行实现延迟主题轮询等方案，一致性和时效性都难以保证。
• 队列的动态负载均衡能力：传统MQ的队列消费可以动态新增消费节点分摊压力，Kafka的分区消费最大并行度受限于主题分区数，分区数调整会带来重平衡开销，无法灵活应对突发流量的消费扩容。

• Saga需要的事务补偿消息的精准投递、有序性、去重能力在Kafka上实现成本高：Saga的每个事务步骤的补偿命令需要保证只被执行一次，且按事务顺序投递，Kafka的幂等性仅在单生产者、单会话、单分区范围内有效，跨分区、跨生产者的幂等需要业务层额外实现分布式唯一ID、消费去重表等逻辑，远高于传统MQ原生的消息去重、精准投递能力。
• Kafka的事务机制局限性大：Kafka的事务仅支持生产者-消费位移提交-生产者的链路事务，也就是常说的「读-处理-写」链路原子性，无法支持Saga模式中常见的「本地数据库事务执行 + 消息发送」的原子性需求，需要自行实现XA事务或者本地消息表方案，额外引入了分布式事务的复杂度。
• 消费异常的回滚难度大：Saga执行过程中如果某一步失败需要触发补偿链路，传统MQ可以将未确认的消息放回队列后续重试，或者直接投递补偿消息，Kafka由于是偏移量提交机制，想要回滚到某条消息之前的状态，需要手动重置消费位移，还需要避免重复消费已经处理成功的消息，需要额外维护每个Saga事务的执行位点，复杂度陡增。
• 长事务的支持度差：Saga事务通常是跨服务的长生命周期事务，Kafka的事务超时时间默认较短，调整到过长会导致事务协调器（Coordinator）积压大量未提交的事务状态，引发集群稳定性问题，而传统MQ的消息确认超时可以灵活配置，无需影响集群核心组件的稳定性。

内容的提问来源于stack exchange，提问作者user1958187