分布式延迟队列的实现方案比较

1.定时轮询表

优点：简单易用,可以利用quartz的分布式特性轻易的进行横向扩展。

缺点： 需要扫表会增加程序负荷、任务执行不够准时。

2.利用jdk自带的delayQueue

优点： 效率高,任务触发时间延迟低。

缺点： 复杂度比quartz要高,自己要处理分布式横向扩展的问题,因为数据是放在内存里,需要自己写持久化的备案以达到高可用。

3.利用wheelTimer：netty的HashedWheelTimer

优点： 效率高,根据楼主自己写的测试,在大量高负荷的任务堆积的情况下,HashWheelTimer基本要比delayQueue低上一倍的延迟率.netty中也有了时间轮算法的实现,实现难度低

缺点： 内存占用相对较高,对时间精度要求相对不高.和delayQueue有着相同的问题,自己要处理分布式横向扩展的问题,因为数据是放在内存里,需要自己写持久化的备案以达到高可用。

4.rabbitMq的延迟队列

优点： 高效,可以利用rabbitmq的分布式特性轻易的进行横向扩展,消息支持持久化增加了可靠性。

缺点： 本身的易用度要依赖于rabbitMq的运维.因为要引用rabbitMq,所以复杂度和成本变高

5.利用elastic-job或quartz动态创建任务

优点：简单易用，可以实现动态横向扩展，可以通过console直接查看任务状态

缺点：会创建很多的zk节点，占用zk的内存，可能会导致zk内存不够用

改进：在任务执行完成后主动调用清除任务方法，将zk中的节点清除；同时在动态创建任务时，将任务的状态存储到数据库中，这样就能将任务的执行状态进行持久化。同时可以利用elastic-job的console功能进行任务状态的查看。

问题：由于elastic-job每创建一个任务就新建一个线程，会导致内存耗尽。

6.redis的ZSet

优点：解耦，异常回复，分布式

缺点：持久化这块有问题

后续优化：将redis的数据写入到DB中，实现持久化