以前為部門內部開發過乙個定時器程式，這個定時器很簡單，就是配置quartz，來實現定時呼叫配置的url功能。最近為了防止定時器所在的伺服器由於特殊原因掛掉，需要對定時器做多機部署。那麼如果按照原來的方式進行部署，就會遇到在一定的間隔時間內，可能出現多次重複呼叫的問題。為了解決這個問題，我就借助了redis的分布式鎖功能。
redis分布式鎖參考 :
具體原理如下：
定時器到時間被觸發，程式開始先爭取乙個redis鎖。
如果獲得鎖，就設定鎖的超時時間為到下次定時器觸發的時間。
然後執行定時器任務。後來的定時器也來嘗試獲得redis鎖，當然，這個鎖已不能獲取了，而且超時時間在未來，所以就放棄這次任務呼叫。
定時器到時間再次被觸發，然後嘗試獲得鎖，由於鎖的超時時間為定時任務的時間間隔，當前時間正好大於或等於超時時間，所以，程式可以順利的獲得鎖，並重置超時時間。
。。。。。。。不斷的迴圈呼叫，判斷
在此之間測試迴圈間隔時間最小單位為1s最好，如果小於1s的呼叫，由於使用redis會有10幾毫秒的運算耗費，因此不能保證在1s以下的時間間隔比較均勻.
為了能保證定時觸發時，能獲得redis鎖，可以設定鎖的超時時間為間隔時間-10ms。這樣就判斷超時時間 now > timeouttime = true。
補充：只要多個伺服器時間差別不大，基本不會有重複的問題。唯一擔心的就是redis，這個掛了，就全掛了。
因此，如果要考慮更全面，需要對redis點單再做集群。就看是否有必要了。
目前定時器的任務都是通過配置檔案寫好，以後我還要考慮動態更新任務。
目前**還在整理中，想做乙個開源的專案。
踩我的請告訴我，**不對。如果大家有更好的方案，請告訴我，我需要改進
利用redis實現分布式鎖
一.對於分布式的應用，一定程度上會增加處理的速度。但是也會帶來一些分布式上的麻煩,比如有個需求 後台程式部署在多台伺服器上，client向該後台程式傳送引數為 使用者賬號和 賬號型別 的rpc請求，後台程式需要返回該賬號對應的身份資訊 邏輯很簡單，先判斷庫中有沒有該賬號資訊，有就返回，沒有就新生成乙...
利用redis實現分布式鎖
因為redis是單執行緒程式，可以天然的保證執行緒安全，只要我們的命令是單條命令，就可以保證操作的安全性，而redis中給我們提供了setnx key value命令，setnx命令的作用就是當我們的redis中沒有這個key的鍵值隊時，就會建立這個鍵值隊的值，如果已經有了這個key就不作操作 所以...
利用Redis實現分布式鎖
實現 redis 完成分布式鎖 所用到的指令 思路 1 在執行具體的買票業務之前先通過 setnx 的指令去獲取其返回值，如果設定成功 返回值為1 說明獲取到了鎖，沒有設定成功 返回值為0 則說明沒有獲取到鎖，繼續迴圈執行 2.搶到鎖的執行緒先給key 設定過期時間，這一步主要是為了避免死鎖問題 在...