利用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点单再做集群。就看是否有必要了。

 

       目前定时器的任务都是通过配置文件写好，以后我还要考虑动态更新任务。

 

       目前代码还在整理中，想做一个开源的项目。

 

       踩我的请告诉我，哪里不对。如果大家有更好的方案，请告诉我，我需要改进

评论

19 楼 zxjlwt 2015-11-30  

学习了。
http://surenpi.com

18 楼 ak478288 2014-11-13  

yangjianzhouctgu 写道

怎么样保证每次的定时任务被执行？在获得锁的情况下，没执行怎么办？

定时任务是否被执行，取决于任务的业务逻辑。只要定时能被触发，就能执行任务。除非quartz有bug。那么要确认执行成功的话，只能双方协商应答。对于不正常的应答就需要重试。

17 楼 yangjianzhouctgu 2014-11-11  

怎么样保证每次的定时任务被执行？在获得锁的情况下，没执行怎么办？

16 楼 ak478288 2014-09-28  

f529352479 写道

ak478288 写道

f529352479 写道

我觉得是可行的，不知道楼主现在用的怎么样了

现在升级换方案了，使用zookeeper来搞定单点和并发锁的问题。

现在换成什么方案了，可否共享一下，我也有这样的问题需要解决

redis和zookeeper实现一样的功能，就是分布式锁，请google看看相关资料就可以，我们也是基于这样的方案来实现

15 楼 f529352479 2014-09-28  

ak478288 写道

f529352479 写道

我觉得是可行的，不知道楼主现在用的怎么样了

现在升级换方案了，使用zookeeper来搞定单点和并发锁的问题。

现在换成什么方案了，可否共享一下，我也有这样的问题需要解决

14 楼 ak478288 2014-07-31  

f529352479 写道

这个得保证各服务器的时间严格一致，如果有一台服务器上的时间快了一秒，一秒之差就能让该服务器每次都能提前一秒去抢锁，而其他的服务器抢不到锁的几率大大降低，就起不到负载均衡的作用了！

你说的对，服务器时间有问题，就会产生误差

13 楼 ak478288 2014-07-30  

f529352479 写道

我觉得是可行的，不知道楼主现在用的怎么样了

现在升级换方案了，使用zookeeper来搞定单点和并发锁的问题。

12 楼 f529352479 2014-07-27  

这个得保证各服务器的时间严格一致，如果有一台服务器上的时间快了一秒，一秒之差就能让该服务器每次都能提前一秒去抢锁，而其他的服务器抢不到锁的几率大大降低，就起不到负载均衡的作用了！

11 楼 f529352479 2014-07-25  

我觉得是可行的，不知道楼主现在用的怎么样了

10 楼 skzr.org 2013-07-04  

就是你同事这样的的方案（多了可以用xml配置任务以实现任务重用，类似shell的管道原理）

ak478288 写道

skzr.org 写道

ak478288 写道

rox 写道

这个方案不错，灵活方便。
系统资源牺牲比较小。
原来，考虑定时器，都是时间同步，配置麻烦，而且，收效甚微。

嗯，只要多个服务器时间差别不大，基本不会有重复的问题。唯一担心的就是redis，这个挂了，就全挂了。因此，如果要考虑更全面，需要对redis点单再做集群。就看是否有必要了。

目前定时器的任务都是通过配置文件写好，以后我还要考虑动态更新任务。

目前代码还在整理中，想做一个开源的项目。

我之前做过的使用db做状态，多机后台执行调度，每行表示一个task。
1. 定时器每隔1s扫描一次表，安排本地下次执行时间和任务。
2. 任务开始执行前尝试锁定，检查状态，然后更新状态为下次执行时间（同时做记录的ver），任务开始执行。
3. 锁定失败就放弃执行

能详细点说么，你的方案，我们有同事类似的做过。
1、使用的是数据库事务序列化的级别来锁定
2、获取要执行的数据
3、更新这些数据的状态
4、提交事务
5、然后执行任务

我认为用db会复杂化。希望能看到你的详细方案

9 楼 ak478288 2013-07-04  

skzr.org 写道

ak478288 写道

rox 写道

这个方案不错，灵活方便。
系统资源牺牲比较小。
原来，考虑定时器，都是时间同步，配置麻烦，而且，收效甚微。

嗯，只要多个服务器时间差别不大，基本不会有重复的问题。唯一担心的就是redis，这个挂了，就全挂了。因此，如果要考虑更全面，需要对redis点单再做集群。就看是否有必要了。

目前定时器的任务都是通过配置文件写好，以后我还要考虑动态更新任务。

目前代码还在整理中，想做一个开源的项目。

我之前做过的使用db做状态，多机后台执行调度，每行表示一个task。
1. 定时器每隔1s扫描一次表，安排本地下次执行时间和任务。
2. 任务开始执行前尝试锁定，检查状态，然后更新状态为下次执行时间（同时做记录的ver），任务开始执行。
3. 锁定失败就放弃执行

对于你说的 我很想知道是如何锁定，如何判断锁定失败。

8 楼 ak478288 2013-07-04  

skzr.org 写道

ak478288 写道

rox 写道

这个方案不错，灵活方便。
系统资源牺牲比较小。
原来，考虑定时器，都是时间同步，配置麻烦，而且，收效甚微。

嗯，只要多个服务器时间差别不大，基本不会有重复的问题。唯一担心的就是redis，这个挂了，就全挂了。因此，如果要考虑更全面，需要对redis点单再做集群。就看是否有必要了。

目前定时器的任务都是通过配置文件写好，以后我还要考虑动态更新任务。

目前代码还在整理中，想做一个开源的项目。

我之前做过的使用db做状态，多机后台执行调度，每行表示一个task。
1. 定时器每隔1s扫描一次表，安排本地下次执行时间和任务。
2. 任务开始执行前尝试锁定，检查状态，然后更新状态为下次执行时间（同时做记录的ver），任务开始执行。
3. 锁定失败就放弃执行

能详细点说么，你的方案，我们有同事类似的做过。
1、使用的是数据库事务序列化的级别来锁定
2、获取要执行的数据
3、更新这些数据的状态
4、提交事务
5、然后执行任务

我认为用db会复杂化。希望能看到你的详细方案

7 楼 ak478288 2013-07-04  

skzr.org 写道

ak478288 写道

youjianbo_han_87 写道

为了实现A，引入B，结果又要维护B。为了保证B，可能又要引入C，又要维护C。。。。系统就是这么膨胀的。能否从业务角度优化下呢？

其实是可以从业务角度来考虑的。谁都不想维护那么多依赖。但是为了简化业务系统，就需要这么一个独立的定时器系统来解决所有业务系统都需要的功能。

这么做维护是不可避免的。例如你要用数据库，不够用了，就要加入缓存，以后还要考虑数据库和缓存的集群。都是一样的道理。

重点看是要解决问题的方式和引入的问题，哪个更重要。方案没有完美的，只有均衡选择。

呵呵，这个需要考虑下时间，解耦合是好的，不过如果有跟简单的办法实现，就不用复杂的。

谁说不是呢 ，不过目前我没有看到解决的好办法。

6 楼 skzr.org 2013-07-04  

ak478288 写道

youjianbo_han_87 写道

为了实现A，引入B，结果又要维护B。为了保证B，可能又要引入C，又要维护C。。。。系统就是这么膨胀的。能否从业务角度优化下呢？

其实是可以从业务角度来考虑的。谁都不想维护那么多依赖。但是为了简化业务系统，就需要这么一个独立的定时器系统来解决所有业务系统都需要的功能。

这么做维护是不可避免的。例如你要用数据库，不够用了，就要加入缓存，以后还要考虑数据库和缓存的集群。都是一样的道理。

重点看是要解决问题的方式和引入的问题，哪个更重要。方案没有完美的，只有均衡选择。

呵呵，这个需要考虑下时间，解耦合是好的，不过如果有跟简单的办法实现，就不用复杂的。

5 楼 ak478288 2013-07-04  

youjianbo_han_87 写道

为了实现A，引入B，结果又要维护B。为了保证B，可能又要引入C，又要维护C。。。。系统就是这么膨胀的。能否从业务角度优化下呢？

其实是可以从业务角度来考虑的。谁都不想维护那么多依赖。但是为了简化业务系统，就需要这么一个独立的定时器系统来解决所有业务系统都需要的功能。

这么做维护是不可避免的。例如你要用数据库，不够用了，就要加入缓存，以后还要考虑数据库和缓存的集群。都是一样的道理。

重点看是要解决问题的方式和引入的问题，哪个更重要。方案没有完美的，只有均衡选择。

4 楼 youjianbo_han_87 2013-07-04  

为了实现A，引入B，结果又要维护B。为了保证B，可能又要引入C，又要维护C。。。。系统就是这么膨胀的。能否从业务角度优化下呢？

3 楼 skzr.org 2013-07-04  

ak478288 写道

rox 写道

这个方案不错，灵活方便。
系统资源牺牲比较小。
原来，考虑定时器，都是时间同步，配置麻烦，而且，收效甚微。

嗯，只要多个服务器时间差别不大，基本不会有重复的问题。唯一担心的就是redis，这个挂了，就全挂了。因此，如果要考虑更全面，需要对redis点单再做集群。就看是否有必要了。

目前定时器的任务都是通过配置文件写好，以后我还要考虑动态更新任务。

目前代码还在整理中，想做一个开源的项目。

我之前做过的使用db做状态，多机后台执行调度，每行表示一个task。
1. 定时器每隔1s扫描一次表，安排本地下次执行时间和任务。
2. 任务开始执行前尝试锁定，检查状态，然后更新状态为下次执行时间（同时做记录的ver），任务开始执行。
3. 锁定失败就放弃执行

2 楼 ak478288 2013-07-04  

rox 写道

这个方案不错，灵活方便。
系统资源牺牲比较小。
原来，考虑定时器，都是时间同步，配置麻烦，而且，收效甚微。

嗯，只要多个服务器时间差别不大，基本不会有重复的问题。唯一担心的就是redis，这个挂了，就全挂了。因此，如果要考虑更全面，需要对redis点单再做集群。就看是否有必要了。

目前定时器的任务都是通过配置文件写好，以后我还要考虑动态更新任务。

目前代码还在整理中，想做一个开源的项目。

1 楼 rox 2013-07-04  

这个方案不错，灵活方便。
系统资源牺牲比较小。
原来，考虑定时器，都是时间同步，配置麻烦，而且，收效甚微。