延时消息方案设计

延时消息概念;

生产者发送一条消息，希望在指定时间之后再被消费。比如用户下单会发送一条消息给mq,半个小时后推送给消费者，如果完成支付就无需处理，如果未支付则会取消订单并恢复商品库存等。

 

数据库轮循

原理：定时间隔一定时间查询数据库，获取即将到期的任务执行

缺点：时效性差（间隔指定时间查询，难以做到准时）、任务量大会有风险（比如某次数据量过大，可能这个间隔时间都没执行完下次又执行了）

 

redis+数据库

redis分成delay queue和ready queue两块, 　server会查询快到期的delay queue中的任务放到ready queue中，然后执行

delay queue;使用zset键值对存储，key存时间 value存消息指定的索引

ready queue:使用list存储，只存储索引

缺点：　

 

 

 

RocketMq

RocketMq原生的延时方案只支持18个level的延时，即broker端的message delay level.

messageDelayLevel=1s 5s 10s 30s 1m 2m 3m 4m 5m 6m 7m 8m 9m 10m 20m 30m 1h 2h,

producer发送消息给commit log，正常消息放正常队列直接被消费即可，

如果是延时消息会被放到延时消息队列，延时队列根据时间间隔分为18个level，broker中的ScheduleMessageService充当延迟服务，为每个level创建一个timeTask,负责一个级别的消息消费与投递。到期会被放到queue等待执行

 

时间轮

把定时任务以小时为度，划分多个schedual log, 到期前的五分钟把schedual log的消息放到时间轮，

时间轮以map格式存储，key存时间 value存消息索引，判断时间轮的key到点后即发送到队列供消费。