统一来说，业务有“在一段时间之后，完成一个工作任务”的需求。
实现这种定时任务有哪些方法呢，来总结一下想到的方法。
一、定时轮询
这是一个比较直接的思路，启动一个计划任务，每隔一定时间处理一次，这种处理方式只是适用比较小而简单的项目。
假设订单表的结构为：t_order(oid, finish_time, stars, status, …)，更具体的，定时任务每隔一个小时会这么做一次：
select oid from t_order where finish_time > 30minite and status=0;
update t_order set stars=5 and status=1 where oid in[…];
如果数据量很大，需要分页查询，分页update，这将会是一个for循环。
定时轮询的不足：
1、时效性差，会有一定的延迟，这个延迟时间最大就是每隔一定时间的大小，如果你设置每分钟定时轮询一次，那么理论上订单取消时间的最大误差就有一分钟，当然也可能更大，比如一分钟之内有大量数据，但是一分钟没处理完，那么下一分钟的就会顺延。
2、效率低。
二、被动取消
被动取消的方式很简单：只有当用户查询订单信息时，我们再判断该订单是否超时，如果超时再进行超时逻辑的处理。
但是这种方式依赖于用户的查询操作触发，这也就是说如果用户不进行查询订单的操作，该订单就永远不会被取消。
不足：
1、会产生额外影响
比如统计，订单数量等产生影响
2、影响用户体验
用户打开订单列表可能要处理大量数据，影响显示的实时性。
三、延时消息
延时消息设计与实现
高效延时消息，包含两个重要的数据结构：
(1)环形队列，例如可以创建一个包含3600个slot的环形队列(本质是个数组)
(2)任务集合，环上每一个slot是一个Set
同时，启动一个timer，这个timer每隔1s，在上述环形队列中移动一格，有一个Current Index指针来标识正在检测的slot。
Task结构中有两个很重要的属性：
(1)Cycle-Num：当Current Index第几圈扫描到这个Slot时，执行任务
(2)Task-Function：需要执行的任务指针
假设当前Current Index指向第一格，当有延时消息到达之后，例如希望3610秒之后，触发一个延时消息任务，只需：
(1)计算这个Task应该放在哪一个slot，现在指向1，3610秒之后，应该是第11格，所以这个Task应该放在第11个slot的Set中
(2)计算这个Task的Cycle-Num，由于环形队列是3600格(每秒移动一格，正好1小时)，这个任务是3610秒后执行，所以应该绕3610/3600=1圈之后再执行，于是Cycle-Num=1
Current Index不停的移动，每秒移动到一个新slot，这个slot中对应的Set，每个Task看Cycle-Num是不是0：
(1)如果不是0，说明还需要多移动几圈，将Cycle-Num减1
(2)如果是0，说明马上要执行这个Task了，取出Task-Funciton执行(可以用单独的线程来执行Task)，并把这个Task从Set中删除
使用了“延时消息”方案之后，“订单48小时后关闭评价”的需求，只需将在订单关闭时，触发一个48小时之后的延时消息即可：
(1)无需再轮询全部订单，效率高
(2)一个订单，任务只执行一次
(3)时效性好，精确到秒(控制timer移动频率可以控制精度)
四、总结
环形队列是一个实现“延时消息”的好方法，开源的MQ好像都不支持延迟消息，不妨自己实现一个简易的“延时消息队列”，能解决很多业务问题，并减少很多低效扫库的cron任务。
另外，关于MQ的可达性、幂等性未来撰文另述。