消息队列延时方案

很多团队会问：既然已经有消息队列，能不能直接用它做延时队列？答案取决于消息系统支持的延迟语义、业务对精度的要求，以及你是否接受中间件自身的限制。消息队列延时方案的价值，是把“到期后投递给消费者”这件事交给成熟消息系统，但它不自动解决所有调度问题。

本章会比较常见方案：RabbitMQ 可以通过 TTL 加死信队列或延迟插件实现延时投递；Kafka 更适合高吞吐日志流，通常需要额外调度层或按时间分区扫描；RocketMQ 等系统提供更直接的延迟消息能力，但延迟级别、精度和可配置性仍有边界。不同中间件的差异，会直接影响架构设计。

使用消息队列做延时任务时，要特别关注可取消性和可修改性。订单支付后，原来的取消任务应该失效；如果消息已经进入中间件延迟队列，是否能删除或更新，往往取决于具体实现。生产系统通常会在消费端再次读取业务状态，通过幂等和条件判断决定是否真正执行，而不是盲目信任延迟消息本身。

本章还会讨论失败处理：消费者宕机、消息重复投递、死信堆积、延迟队列积压和顺序性要求。消息队列可以提供可靠投递和消费扩展能力，但延时队列仍然需要任务状态表、幂等键、监控告警和补偿任务来兜底。

完成本章后，你应当能判断“用现有 MQ 做延时任务”是否适合当前业务，并能解释 RabbitMQ、Kafka 和专用延迟消息在精度、吞吐、可取消性和运维复杂度上的取舍。