时间轮算法-实战场景一的感想

[cccvip]

场景带入

实际应用场景中, 有一个中台的图表展示系统(附带告警功能)

当前有1000个图表,需要定时执行,也就意味着存在1000个定时任务。并且每个任务的定时执行时间不太一样。

换句话说存在1000个crontab表达式。那么我们该如何解决这个问题呢？

思考

问题点在于如何找到最近的应该执行的任务，并且执行它

redis过期key的监听策略

例如 针对0号库创建1000个key,初始化的时候分别设置过期时间, 监听这些带有同一前缀的动向

基于redis过期key的策略, 发布订阅模型，消费者线程会执行当前这些任务,并且会更新掉过期时间

缺点

• redis的内存
• redis的内存淘汰算法

数据库的每秒轮询策略

每N秒轮询一次,并且更新记录的下一次执行时间

缺点

• 时间不够精准
• 对数据库会有大量没必要的查询
• 分布式场景中, 必然会引入分布式锁

时间轮算法+数据库改进

参考借鉴xxl-job的定时任务调度模型,

生产者线程 使用60s刻度的时间轮, 查询任务并且将任务都丢到刻度的list集合。

消费者线程 每一秒轮询时间轮,取值并且开启异步调用线程。