利用redis分佈式鎖的功能來實現定時器的分佈式

文章來源於個人 iteye blog http://ak478288.iteye.com/blog/1898190

        

 之前爲部門內部開發過一個定時器程序，這個定時器很簡單，就是配置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點單再作集羣。就看是否有必要了。

 

       目前定時器的任務都是經過配置文件寫好，之後我還要考慮動態更新任務。

 

       目前代碼還在整理中，想作一個開源的項目。