订单系统技术选型：数据库轮询、Redis轮询与消息队列的取舍之道

1. 别急着上消息队列：先搞清楚自己的系统到底缺什么

先聊聊标题里那个排序：能用数据库轮询解决的不用Redis，能用Redis解决的不用消息队列。

这句话不是教条，是我这几年处理订单系统真实踩坑后最想分享的一条准则。很多团队一提到订单状态同步、任务调度、通知推送，第一反应就是上MQ，仿佛没有消息队列的项目就不够“互联网”。但现实情况是，消息队列引入之后带来的运维成本、数据一致性成本、排查链路复杂度，往往比它解决的问题还要多。

你得先问自己一个问题：你的系统，到底需要一个“实时推送”方案，还是只需要一个“轮询拉取”方案？这两者的差距天壤之别。

实时推送方案，典型就是消息队列。生产者把消息往队列里一塞，消费者立即收到，端到端延迟能做到毫秒级。但为了这个“毫秒级”，你需要解决的问题一个接一个：消息不丢失怎么搞、重复消费怎么处理、消费失败重试链路怎么设计、积压了怎么扩容、顺序性怎么保障。每一个问题都是一个深坑，每一个坑都需要对应的人力成本去填。

轮询拉取方案，说白了就是定时去查数据，有变化就处理，没变化就歇着。这个方案不需要额外引入任何中间件——数据库就在那儿，Redis已经用了的话也顺手，查询条件写上，定时任务一把梭。缺点是轮询间隔意味着延迟，但在大量真实业务场景下，这个延迟压根不是瓶颈。

举个例子，后端订单超时未支付自动关闭。支付网关回调的时效性再慢，一般也就几十秒内；而订单关闭这个操作，用户感知层面的容忍度是以“分钟”计的。你用数据库定时任务每30秒扫一次，只要索引建对了，对数据库的压力也没想象中大。但你非要用消息队列来做延迟队列，就要处理Redis过期监听不可靠的问题，或者引入RocketMQ的延迟消息等级——为了省那几十秒延迟，结果捅出一堆新问题，这个账怎么算都不划算。

再举个例子，订单创建后要给用户推送站内信、短信、微信模板消息。这种场景，数据库里加一张message_task表，状态字段从PENDING到SENT，定时任务按批次扫，扫到就发，发完就更新状态。就这么简单。我之前做过一个每秒峰值不到300笔订单的小型交易系统，用的就是这种方案。消息积压量最大也就两万条，但发送能力完全够用，数据还能随时查、随时对账，出了问题直接看数据库表，排查成本低到几乎没有。

所以，选轮询方案还是消息队列，本质上要看需求的延迟敏感度和数据规模。如果一个功能允许秒级甚至分钟级延迟，数据库轮询就是答案；如果Redis的重试、幂等、查询能力能兜住，那也不要轻易上MQ。只有当你发现一个功能确实需要毫秒级实时性、同时数据量又大到数据库扛不住定时扫描的时候，引入消息队列才是一个合理的选择。

这个顺序就是标题要表达的核心思想：技术选型要从小到大地去考虑，而不是从大到小地去做架构储备。

2. 数据库轮询的实际边界：什么时候该用它、什么时候该撤

2.1 数据库轮询的本质是一张“待办表”加一个“调度器”

很多人觉得数据库轮询很low、很笨，其实是因为没把它当产品来设计。数据库轮询的核心就两件事：一张记录任务状态的表，一个按固定频率扫描这张表的调度器。

这张任务表设计得好，整个轮询机制就是可靠的。字段大概长这样：

sql复制CREATE TABLE order_task (
  id BIGINT PRIMARY KEY AUTO_INCREMENT,
  order_no VARCHAR(32) NOT NULL COMMENT '订单号',
  task_type TINYINT NOT NULL COMMENT '任务类型：1-超时关单 2-推送通知 3-自动确认收货',
  task_status TINYINT NOT NULL DEFAULT 0 COMMENT '状态：0-待处理 1-处理中 2-成功 3-失败',
  retry_count INT NOT NULL DEFAULT 0 COMMENT '重试次数',
  next_execute_time DATETIME NOT NULL COMMENT '下次执行时间',
  create_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP,
  update_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
  KEY idx_next_time_status (next_execute_time, task_status),
  KEY idx_order_no (order_no)
) ENGINE=InnoDB COMMENT '订单任务表';

这个结构里最重要的就是next_execute_time和task_status的联合索引。只要你轮询的SQL是走这个索引去扫，从几百万行里找出“当前时间已到且待处理”的那一小撮任务，效率是完全不用担心的。

扫描SQL长这样：

sql复制SELECT id, order_no, task_type 
FROM order_task 
WHERE task_status = 0 
  AND next_execute_time <= NOW() 
ORDER BY next_execute_time ASC 
LIMIT 200;

拿到这批记录后，先执行一个原子性的状态抢占：

sql复制UPDATE order_task 
SET task_status = 1, update_time = NOW() 
WHERE id IN (?, ?, ?) AND task_status = 0;

UPDATE走主键，并用task_status=0作为版本条件，一旦影响行数符合预期，说明这批任务被你独占了。这就是数据库天然自带的能力——用更新语句实现了分布式锁，根本不需要额外引入Redis的SETNX方案。

2.2 数据库轮询扛不住的那些场景：高频率、大流量处理型任务

数据库轮询适合“低频触发+单次处理耗时不长”的场景，但它有明确的边界。

当一个任务需要非常频繁地被执行，比如每秒钟要处理成千上万个轻量级任务，数据库轮询的性能瓶颈就暴露了。你每一次轮询都要扫描表，而扫描的总量一旦上了千万级别，即使索引再合理，数据库的CPU和IO消耗也是真实成本。另外，频繁的UPDATE状态抢占会把行锁竞争推向高峰，多实例部署时，两个节点同时抢同一批任务的概率会急剧上升，导致大量死锁和锁等待超时。

这时候就该把“待办任务列表”从数据库挪到Redis里。Redis轮询和数据库轮询的区别在于：数据库是用SQL去扫描“状态字段”，而Redis是用List、ZSet、Stream这种数据结构去维护“待处理集合”。前者天然和业务数据强耦合，后者是一个纯粹的任务缓冲层。

我见过不止一个团队，订单量也就是一天几千单的水平，却把超时关单、退款回调、对账补偿全部压给RocketMQ。问他们为什么，回答是“以后订单量肯定会上涨”。但事实是，系统上线了快两年，日订单量仍在四位数徘徊，而光维护MQ集群顺便处理消息堆积告警的时间成本，已经远超当初省下来的那点数据库扫描开销。

2.3 数据库轮询最容易被忽略的坑：扫描时刻不均匀

数据库轮询还有一个隐性坑：如果你用固定频率的定时任务，比如@Scheduled(fixedDelay = 30000)，那么你的处理能力是锯齿形的。任务刚执行完，等待30秒，然后一股脑扫出一批，处理完，再等30秒。如果某一秒产生了大量任务，这一批任务可能要等将近一个扫描周期才能被捞起来。

解决办法其实也简单：动态缩短队列为空时的休眠时间，或者调整扫描周期和扫描批次大小。把固定频率改成动态频率，当前批没扫到任务就sleep 3秒，扫到任务就连续扫描直到队列空，再sleep。这样既保证空闲时候不浪费数据库资源，又能让新到达的任务在极短时间内被捞起。

3. Redis轮询能解决什么、不能解决什么

3.1 用Redis做轮询不是“被迫降级”：它天生适合状态流转

Redis在订单轮询里最典型的两个用法：一是用ZSet做延迟队列，比如超时关单；二是用List做任务队列，比如推送任务分发。和数据库相比，Redis的读写是内存级的，单线程模型天然规避了并发更新同一批任务时的锁竞争，处理能力完全不在一个量级。

先说ZSet做延迟轮的姿势。score存目标执行时间戳，member存订单号：

bash复制# 订单创建后，30分钟没有支付，超时关单。
# 现在时间戳 + 1800秒 作为score
ZADD order_delay_close 1699999999 ORDER_20260101000001

轮询的时候，用ZRANGEBYSCORE把score小于当前时间戳的任务取出来：

bash复制ZRANGEBYSCORE order_delay_close -inf 1700000000 LIMIT 0 200

取出来之后，每个订单号对应去数据库查订单当前状态。如果还是待支付状态，就执行关单；如果已经支付了，直接把ZSet里的记录删掉。这种方案最大的优势是查询速度极快，百万级延迟任务在ZSet里也就是毫秒级别定位。

至于延迟精度问题，Redis轮询一般做到秒级是没问题的。毕竟你轮询频率是1秒或者2秒一次，误差也就是这一两秒。除非你要做到几百毫秒级别的精确延迟，那才需要考虑时间轮和更精细的调度，但一般订单场景根本不需要这么激烈，你也没法掌控用户支付网关回调的延迟。

3.2 Redis做轮询时，最要命的是“任务丢了怎么办”

Redis做任务存储有一个天然的缺陷——它不是业务数据库。Redis数据全在内存里，就算开启了AOF持久化，崩溃时也最多只能恢复到最近一次刷盘的状态，总会有一段窗口期的数据丢失。

订单关单这个场景，丢了就丢了，最坏结果是有极少数订单超时了没被自动关闭，用户来投诉说“我没支付怎么订单还在”，你去手工关一下就行。可如果是资金类的自动退款任务，Redis里丢了，钱就没退，这个事故等级完全不一样了。

所以Redis轮询的正确姿势必须是：Redis当“加速索引”，数据库当“事实标准”。Redis里的每个待处理任务，在数据库里都要有一条对应的状态记录。轮询到任务后，必须先去数据库校验业务状态，再决定是否执行真正的处理动作。

实操中我常用的模式是：写入任务的时候，先插入数据库任务表，再往Redis里写一条，两者以数据库为准。处理任务的时候，先从Redis捞到一批候选任务，再回数据库核验状态，正确处理了才把Redis记录删掉。就算Redis整个崩溃，或者Redis里部分任务丢失，数据库里的待处理任务还在，启动一个补偿任务扫描数据库就能找回来。永远要记住：Redis是缓存层，不是数据层。

另外还有一点必须提：单线程模型下，如果你的一个任务里包含了耗时操作，比如调外部API、发短信，一定不能把这个操作放在取任务的同一个循环里同步执行。否则你就把Redis处理线程给堵了。正确做法是：轮询线程只做“取任务 + 更新状态”，真正的业务处理丢给线程池异步去跑，处理完再回写任务结果。这个设计能极大减少Redis写阻塞和排查困难。

3.3 Redis Stream：比List和ZSet更适合做可靠任务队列的替代品

Redis 5.0引入的Stream类型，其实已经具备了很多消息队列的雏形能力。支持消费者组、ACK确认、待处理消息列表，比手动维护List任务列表要优雅很多。

比如你用XADD往Stream里投递任务：

bash复制XADD order_stream * order_no ORDER_20260101000001 task_type close_order

消费者组消费：

bash复制XGROUP CREATE order_stream order_group 0
XREADGROUP GROUP order_group consumer_1 COUNT 100 BLOCK 3000 STREAMS order_stream >

处理完业务，确认消费：

bash复制XACK order_stream order_group 1699999999-0

这套机制的价值在于：你在Redis轮询的基础上，免费获得了“至少一次”的投递保障。消费者拿到消息后如果崩溃了，消息会进入Pending列表，你用一个定时任务扫描Pending列表，对超时未ACK的消息重新投递即可。

但Stream仍然不是万能的，它解决不了持久性和数据主备切换时的可靠性问题，因此在核心资金链路仍然需要数据库做最终的兜底。另外，如果你已经有RocketMQ或Kafka在团队里运行得很成熟，那Stream的意义就没那么大了。至少对于一个平时不太想折腾Redis集群的团队来说，Stream的运维复杂度已经超过其收益了。

4. 消息队列这个终极武器：什么时候才算“不能不用”

4.1 消息队列真正解决的问题是“流量削峰”和“下游解耦”，不是“通知延迟”

到什么时候，你才真正需要消息队列？一句话总结：当瞬时数据压力超过单机数据库或单机Redis的处理极限，并且这些数据需要被多个下游系统以不同速度消费的时候。

经典场景是秒杀。用户点击抢购，后端先在校验库存的入口用Redis做秒杀令牌，抢到令牌后，真正的写库操作不直接同步执行，而是把订单数据发到MQ，由消费端批量落库。这样数据库的写入压力被削峰，前端能迅速得到“抢购成功”的反馈，而库的落库节奏完全在可控范围。

不做削峰的情况下，订单表每秒钟迎接上万次INSERT，还带索引维护、事务日志、状态更新，数据库立马变成热点，性能断崖式下跌。这种场景下，数据库轮询和Redis轮询再怎么优化，都解决不了写入侧瞬间压力过大的问题。

另一个必须上MQ的场景是“一个订单状态变更，多个下游都要响应”。订单支付成功，需要更新积分系统、通知配送系统、触发发票开具、同步风控系统。如果全部用同步RPC调用，链路一深，任意一个下游抖动都会拖死主链路。用MQ把这些依赖解耦后，订单服务只需要发送一条“支付成功”事件，下游各自消费，互不阻塞。

4.2 消息队列的隐性成本：重复消费、顺序性、全链路监控

很多团队冲进MQ世界后，第一个被现实教育的问题就是“消息重复”。如果消费端不实现幂等，消息一重复，积分加两次、短信发两遍，问题就大了。

幂等设计必须落在消费端。收到消息后，拿着消息里的唯一业务键去数据库查一下，发现处理过了就直接ACK。这个“查一下”如果用数据库去做，每消费一条消息就是一次主键查询，量大的时候又是性能瓶颈；所以真正成熟的方案是消费端用Redis的SETNX做一个幂等标记，处理过的消息直接跳过，省去回查数据库的开销。

然后再看顺序性。RocketMQ的普通消息发送，默认同一队列里是有顺序的，但一旦涉及多个队列并发消费，全局顺序就不能保证。很多团队把一个订单的多个状态变更全部发到一个Topic里，结果这些消息被分散到不同队列并行消费，顺序乱了，状态错乱。解决方案是保证同一个订单号的强相关消息都发到同一个队列；而实现不走样，就得在发送时按订单号对队列数量做取模。

最后是全链路监控。MQ把系统解耦了，也把问题埋了进去。一条消息从Producer发出去到Consumer处理完成，中间经过了哪个节点、卡在哪个环节、成功没有，如果没有任何Trace机制，排查问题就像大海捞针。至少要记录消息ID、业务ID、发送时间、入队时间、消费开始时间、消费结束时间，这些字段落到日志系统里，遇到问题才能快速定位。

4.3 从Redis轮询“升级”到消息队列的正确姿势：先摸清吞吐压测数据

我特别不建议“因为技术新所以要用”的心态来做迁移。从Redis轮询升级到MQ，唯一站得住脚的理由是：你的Redis轮询方案经过压测后，确认无法满足QPS或稳定性指标。

压测方式很简单：模拟订单写入，让整个处理链路跑起来。先测Redis轮询方案在单实例下的吞吐上限，看看在整个处理流程完整跑通的前提下，它的QPS峰值是多少，CPU和内存占用是否处于舒适区。然后再叠加场景，比如消息体变大、处理线程数增加、消费端耗时波动，观察Redis的响应延迟是否出现尖刺。

我当年测过的一组数据供参考：单台8核16G的虚拟机，Redis单实例做任务轮询，每个任务只做数据库状态核验和简单字段更新，整体QPS能稳定在2000左右，P99延迟在40ms以内。如果超了这个量，再想着上MQ。低于这个量，你把Redis轮询方案优化一下，大概率还能再用两三年。

5. 三层轮询架构的选型决策矩阵与最佳实践拆解

5.1 一个真实订单系统的混合架构案例

我负责过的一个订单系统，日订单量在15万左右，秒杀场景峰值在每分钟5万请求。技术选型最终是三层混合：超时关单和自动确认收货走数据库轮询；站内信、短信、微信通知走Redis List队列轮询；秒杀场景的订单创建，数据打到MQ异步落库。

超时关单这个模块，数据库订单表加了一个pay_expire_time字段，建索引，每30秒扫描一次。因为订单每天15万，30天滚动下来表里活跃数据量约450万行，扫描一次耗时平均800ms，峰值也不到1.5秒。数据库的CPU在白天高峰期也只增加了不到10个百分点，完全可接受。

通知消息这个模块，Redis List每天积压的消息大约20万条。消费者每2秒POP一次，每次取200条，异步发送，发送失败重试3次，最后还失败就把消息重新放回List并记录日志。Redis的内存占用不到500MB，整个模块运维成本为零。

真正上MQ的就是秒杀场景。抢购令牌用Redis做限流，拿到令牌的请求生成订单消息发到RocketMQ，MQ的消费者以每秒3000笔的速率落库。这样即使瞬间涌入5万请求，MySQL承受的写入压力也只有每秒3000，完全在安全水位以下。

5.2 决策矩阵：拿到一个需求，先按这些维度打分

很多人问我，有没有一张可以照着判断的表。我整理了一张，每次评审方案的时候直接用：

这张表的用法很简单：把新需求逐项对照，哪一列符合项最多，就走哪个方案。如果几个方案的评分接近，优先级永远是从数据库到Redis再到MQ，不要跳级。

5.3 无论选哪一层，这几个通用原则不会变

先记录状态，再执行动作。任何任务处理前，先把状态从待处理改成处理中，避免重复执行；处理完成后再改成成功。如果处理过程中宕机，状态停留在处理中，靠超时重试机制捞回来。这比“执行完再改状态”安全得多。

凡事都要做重试。数据库更新失败、Redis写入失败、MQ消费失败，都要有统一的重试机制。通常我建议重试3次，间隔依次为1秒、5秒、30秒，超过3次进入人工/补偿通道。不要无限重试，容易把下游打死。

幂等是底线。同一个任务被重复执行，结果必须一致。在数据库层面，用唯一业务键做约束；在Redis层面，用SETNX加过期时间；在MQ层面，消费者处理前先查处理记录。这个动作看似浪费一次查询，实际上省掉的是重复执行带来的数据错乱和事故处理时间。

状态变更必须留轨迹。订单状态从待支付变成已关闭，是谁改的、什么时候改的、触发源是什么，全部记录。对账的时候能少吵很多架。

5.4 关于“轮询”我最后想多说一句

轮询不是技术上的妥协，而是对业务需求的准确认知。一件允许分钟级延迟完成的事，你花大力气去追求毫秒级推送，属于过度建设。工程上最重要的能力，不是掌握最多技术栈，而是知道什么场景用什么方案最划算。

数据库轮询能解决的，绝不上Redis；Redis轮询能解决的，绝不上消息队列。这个顺序倒过来的人，绝大多数都付出过惨痛的维护代价。希望我的这套经验能帮你避开那些坑，在技术选型的时候，多一层清醒。