业务场景举例：

   用户下单5分钟内没有支付，以PUSH的方式催付

解决方案：

方案A：

定时轮询当天全量的订单数据，找到符合要求的数据。

方案特点：

1. 方案简单、不依赖过多的技术组件

2. 轮询效率过低，不适合大数据量业务场景

方案B：--建议方案

发送RocketMQ支持的延迟消息，Consumer侧消息延迟消息即可

方案特点：

1. 方案简单，但依赖MQ中间件

2. 具备高可用性、可扩展性、分布式特性

注意：RabbitMQ的死信和死信路由的方案也可以做为选择

方案C：

Redis的SortSet，时间作为score，JAVA线程轮询SortSet

方案特点：

1. 方案有些复杂，但实现方便

2. 具备可扩展性、分布式、高可用性特性

3. 会限制JAVA容器集群数量，存在Redis热点问题，规模达到一定期数量会导致Redis CPU 100%或者持续很高（一般30个线程以上轮询会出现此类问题）

方案D：

TimingWheel（时间轮算法），Kafka、Netty等组件都有使用此算法，Netty的HashedWheelTimer用来判断Socket连接超时，能很好支撑10万级数量判断

方案特点：

1. 方案成熟、可靠、实现方便，无第三方组件依赖

2. 适合单进程，效率高

方案E：

DelayQueue+Leader/Follower线程模式（后面会有文章介绍线程模型）

方案特点：

1. 方案编码复杂，无第三方组件依赖

2. 适合单进程，效率高

方案F：--建议方案

上面的方案都是组件化或者功能化，在资源允许的情况下，这个问题最好的介绍方案是服务化，可抽象为任务提交、任务调度、任务执行三个阶段

方案特点：

1. 前期需要投入较多资源

2. 复用性、扩展性、可用性强

方案G：

流式计算的滑动窗口，只要窗口时长+滑动间隔能包含延迟时间即可，可能需要做到排重或者幂等处理

方案特点：

1. 延迟时间不能太长，可处理大量的数据

2. 对技术要求高点