项目产品中，大家都会有"定时任务"和"定时超时"的需求，初始阶段，我们基本都是用少数的一些timer，即使是任务量越来越大的时候，我们就难免维护着大量的timer，或者进行了大量低效的扫描。
定时任务使用场景：当订单一直处于未支付状态时，如何及时地关闭订单(已经使用)
如何定期检查处于退款状态的订单是否已经退款成功(后期重构使用)
设计方案：
整个Redis当做消息池，以KV形式存储消息使用ZSET做优先队列，按照Score维持优先级使用LIST结构，以先进先出的方式消费ZSET和LIST存储消息地址(对应消息池的每个KEY)使用定时器维护路由根据TTL规则实现消息延迟RoomWits现阶段就是使用的这套方法：
1.新增一个job，会job_pool中插入一条数据，记录了业务方消费方。也会在bucket插入一条记录，记录执行的时间戳
2.搬运线程会去bucket中查找哪些执行时间戳的RunTimeMillis比现在的时间小，将这些记录全部删除；同时会解析出每个任务的Topic是什么，然后将这些任务PUSH到TOPIC对应的列表queue中
3每个topic的list都会有一个监听线程去批量获取list中的待消费数据，获取到的数据全部扔给这个topic的消费线程池
4.消费线程池执行会去job_pool查找数据结构，返回给回调结构，执行回调方法。
待优化的内容：
目前只有一个Queue队列存放消息，当需要消费的消息大量堆积后，会影响消息通知的时效。改进的办法是，开启多个Queue，进行消息路由，再开启多个消费线程进行消费，提供吞吐量消息没有进行持久化，存在风险，后续会将消息持久化到MongoDB中一般来说还有什么其他方法实现这类需求呢？
“轮询扫描法”
1.用一个Map<uid, last_packet_time>来记录每一个uid最近一次请求时间last_packet_time
2.当某个用户uid有请求包来到，实时更新这个Map
3.启动一个timer，当Map中不为空时，轮询扫描这个Map，看每个uid的last_packet_time是否超过30s，如果超过则进行超时处理
“多timer触发法”
1.用一个Map<uid, last_packet_time>来记录每一个uid最近一次请求时间last_packet_time
2.当某个用户uid有请求包来到，实时更新这个Map，并同时对这个uid请求包启动一个timer，30s之后触发
3.每个uid请求包对应的timer触发后，看Map中，查看这个uid的last_packet_time是否超过30s，如果超过则进行超时处理
方案一：只启动一个timer，但需要轮询，效率较低
方案二：不需要轮询，但每个请求包要启动一个timer，比较耗资源
还没有评论，来说两句吧...