以前为部门内部开发过一个定时器程序，这个定时器很简单，就是配置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点单再做集群。就看是否有必要了。
目前定时器的任务都是通过配置文件写好，以后我还要考虑动态更新任务。
目前代码还在整理中，想做一个开源的项目。
踩我的请告诉我，哪里不对。如果大家有更好的方案，请告诉我，我需要改进