项目是否需引入RabbitMQ？两种方案对比及延迟配置咨询

一、两种方案优劣对比 #

从你的业务规模（日单量10000条，约每秒0.11条）来看，方案一直接写入数据库+后台定时清理的方式更优，原因如下：

• 架构极简：不需要额外维护RabbitMQ中间件，减少部署、监控、故障排查的成本。
• 性能足够：这个量级的写入请求，普通关系型数据库（比如MySQL）完全能轻松承载，不会有性能瓶颈。
• 逻辑清晰：工单写入后直接落地，定时任务每10分钟扫描并删除已取消工单，业务流程直观，排查问题更简单。

方案二引入RabbitMQ反而画蛇添足：

• 增加复杂度：多了消息队列的运维环节，还要处理消息丢失、重复消费、队列阻塞等额外问题。
• 无明显性能提升：你的业务量根本到不了需要用消息队列削峰填谷的程度，数据库写入的耗时完全可以忽略。
• 逻辑绕弯：工单先入MQ再落地，还要在消费时判断是否取消，反而增加了业务逻辑的环节。

二、是否需要引入RabbitMQ？ #

结论：完全不需要。你的业务场景简单、数据量小，方案一的架构已经足够稳定高效。RabbitMQ这类消息队列更适合高并发写入、流量削峰、异步解耦（比如订单创建后异步发通知、库存扣减）等场景，你的需求完全用不到这些特性。

三、若必须使用RabbitMQ的相关功能支持 #

1. 延迟消息（10分钟后接收检查） #

RabbitMQ没有原生延迟消息，但有两种成熟实现方式：

• 死信队列（DLX）方案：发送消息时设置x-message-ttl为10分钟，同时给队列绑定死信交换机和死信队列；消息过期后会自动进入死信队列，消费者从死信队列消费即可实现延迟处理。
• 延迟消息插件：安装官方的rabbitmq_delayed_message_exchange插件，创建交换机时指定类型为x-delayed-message，发送消息时设置x-delay参数为600000毫秒（10分钟），消息会在指定延迟时间后被投递到队列。

2. 定时重复发送消息 #

RabbitMQ本身不支持原生的定时重复消息，但可以通过以下方式实现：

• 死信队列循环投递：消费消息后，如果需要重复发送，就重新将消息发送到原队列并设置下一次的延迟时间，以此实现周期性重复。
• 结合外部定时任务：用定时任务工具（比如Linux的crontab、Spring Task）定期触发消息发送逻辑，将消息推送到RabbitMQ队列，实现定时重复投递。

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