實現分佈式鎖的方法主要有四種：
- 數據庫唯一索引
- Redis的SETNX指令
- Redis實現的RedLock算法
- ZooKeeper的臨時有序節點
第一種是通過數據庫唯一索引，通過往數據庫中插入唯一索引表示獲取到鎖，刪除該唯一索引表示釋放該鎖。唯一索引可以保證當前數據庫中該索引是唯一的。那麼就可以使用這個唯一索引來判斷數據是否處於鎖定狀態。但是數據庫唯一索引沒法設置過期時間，一旦解鎖失敗其它進程就沒法再獲取鎖了。另外這種方式實現的鎖是不可重入的，也就是已經獲得該鎖的進程也必須重新獲取該鎖。
因此，就有了第二種方式，通過Redis的SETNX(set if not exist) 命令實現，使用setnx指令往redis數據庫中插入一個鍵值對，如果key已經存在則插入失敗，表示獲取鎖失敗，插入成功表示成功獲取鎖。setnx指令和數據庫唯一索引類似，可以保證數據庫中同時只存在一個Key的鍵值對，那麼這個Key的鍵值對就可以用來判斷數據是否處於鎖定狀態。與數據庫唯一索引不同的是，redis可以爲鍵值對設置過期時間，這樣就可以避免出現數據庫中唯一索引釋放鎖失敗的問題。
然而，Redis的setnx方式是在單例Redis上實現的分佈式鎖，一旦這個Redis數據庫崩潰，既出現單點故障，分佈式鎖的服務就無法使用了。爲了解決這個問題，Redis的RedLock算法和Zookeeper實現的分佈式鎖被提出來。
首先我們先來講一下Redis實現的RedLock算法。RedLock算法使用了多個Redis實例來實現分佈式鎖，這樣就可以保證單點發生故障的時候依然可用。RedLock算法嘗試從N個相互獨立的Redis實例中獲取鎖，當客戶端獲取鎖消耗的時間小於鎖的過期時間，並且從（N/2+1）實例上獲取了鎖，說明這個客戶端獲取到鎖。否則，則需要到每個實例上將獲取到的鎖釋放掉。
採用ZooKeeper實現的分佈式鎖主要使用的是Zookeeper中的臨時有序節點。首先創建一個鎖目錄/lock，然後客戶端需要獲取鎖的時候，就在鎖目錄/lock下創建臨時且有序的子節點。之後客戶端獲取鎖目錄/lock下的子節點列表，判斷自己創建的子節點是不是當前子節點列表的最小節點，如果是就表示獲取到鎖。否則設置一個監聽器監聽自己的前一個節點，獲取子節點的變更通知後重復該步驟直至獲取到鎖。執行完業務代碼後會刪除掉對應的子節點表示釋放鎖。