本文介绍了一种使用Redis分布式锁解决定时器多机部署下任务重复调用问题的方法。通过对定时器进行优化，避免了多服务器环境下定时任务的冲突，并探讨了进一步提升稳定性的策略。
以前为部门内部开发过一个定时器程序，这个定时器很简单，就是配置quartz，来实现定时调用配置的url功能。最近为了防止定时器所在的服务器由于特殊原因挂掉，需要对定时器做多机部署。那么如果按照原来的方式进行部署，就会遇到 在一定的间隔时间内，可能出现多次重复调用的问题。为了解决这个问题，我就借助了redis的分布式锁功能。
redis分布式锁参考 : http://www.jeffkit.info/2011/07/1000/
具体原理如下：
定时器到时间被触发，程序开始先争取一个redis锁。
如果获得锁，就设置锁的超时时间为到下次定时器触发的时间。
然后执行定时器任务。后来的定时器也来尝试获得redis锁，当然，这个锁已不能获取了，而且超时时间在未来，所以就放弃这次任务调用。
定时器到时间再次被触发，然后尝试获得锁，由于锁的超时时间为定时任务的时间间隔，当前时间正好大于或等于超时时间，所以，程序可以顺利的获得锁，并重置超时时间。
。。。。。。。不断的循环调用，判断
在此之间测试循环间隔时间最小单位为1s最好，如果小于1s的调用，由于使用redis会有10几毫秒的运算耗费，因此不能保证在1s以下的时间间隔比较均匀.
为了能保证定时触发时，能获得redis锁，可以设置锁的超时时间为间隔时间-10ms。这样就判断超时时间 now > timeoutTime = true。
补充：
只要多个服务器时间差别不大，基本不会有重复的问题。唯一担心的就是redis，这个挂了，就全挂了。
因此，如果要考虑更全面，需要对redis点单再做集群。就看是否有必要了。
目前定时器的任务都是通过配置文件写好，以后我还要考虑动态更新任务。
目前代码还在整理中，想做一个开源的项目。
<iframe src="/iframe_ggbd/794" frameborder="0" scrolling="no" width="468" height="60"></iframe>
顶
踩
扫一扫
712
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
评论
其实是可以从业务角度来考虑的。谁都不想维护那么多依赖。但是为了简化业务系统，就需要这么一个独立的定时器系统来解决所有业务系统都需要的功能。
这么做维护是不可避免的。例如你要用数据库，不够用了，就要加入缓存，以后还要考虑数据库和缓存的集群。都是一样的道理。
重点看是要解决问题的方式和引入的问题，哪个更重要。方案没有完美的，只有均衡选择。
呵呵，这个需要考虑下时间，解耦合是好的，不过如果有跟简单的办法实现，就不用复杂的。
其实是可以从业务角度来考虑的。谁都不想维护那么多依赖。但是为了简化业务系统，就需要这么一个独立的定时器系统来解决所有业务系统都需要的功能。
这么做维护是不可避免的。例如你要用数据库，不够用了，就要加入缓存，以后还要考虑数据库和缓存的集群。都是一样的道理。
重点看是要解决问题的方式和引入的问题，哪个更重要。方案没有完美的，只有均衡选择。
系统资源牺牲比较小。
原来，考虑定时器，都是时间同步，配置麻烦，而且，收效甚微。
嗯，只要多个服务器时间差别不大，基本不会有重复的问题。唯一担心的就是redis，这个挂了，就全挂了。因此，如果要考虑更全面，需要对redis点单再做集群。就看是否有必要了。
目前定时器的任务都是通过配置文件写好，以后我还要考虑动态更新任务。
目前代码还在整理中，想做一个开源的项目。
我之前做过的使用db做状态，多机后台执行调度，每行表示一个task。
1. 定时器每隔1s扫描一次表，安排本地下次执行时间和任务。
2. 任务开始执行前尝试锁定，检查状态，然后更新状态为下次执行时间（同时做记录的ver），任务开始执行。
3. 锁定失败就放弃执行
系统资源牺牲比较小。
原来，考虑定时器，都是时间同步，配置麻烦，而且，收效甚微。
嗯，只要多个服务器时间差别不大，基本不会有重复的问题。唯一担心的就是redis，这个挂了，就全挂了。因此，如果要考虑更全面，需要对redis点单再做集群。就看是否有必要了。
目前定时器的任务都是通过配置文件写好，以后我还要考虑动态更新任务。
目前代码还在整理中，想做一个开源的项目。
系统资源牺牲比较小。
原来，考虑定时器，都是时间同步，配置麻烦，而且，收效甚微。