分布式鎖的三種實現方式：
1、基於數據庫：1）利用唯一索引約束；2）利用數據庫自帶排他鎖
2、基於緩存：利用setnx()返回值
3、基於ZooKeeper：1）利用ZooKeeper同一個目錄下只能有一個唯一文件名；2）利用ZooKeeper分布式鎖客戶端Curator
注：需要考慮的因素：單點、可重入、阻塞、失效時間
一、基於數據庫的實現方式
基於數據庫的實現方式的核心思想是：在數據庫中創建一個表，表中包含方法名等字段，並在方法名字段上創建唯一索引，想要執行某個方法，就使用這個方法名向表中插入數據，成功插入則獲取鎖，執行完成后刪除對應的行數據釋放鎖。
1、創建一個表：
DROP TABLE IF EXISTS `method_lock`; CREATE TABLE `method_lock` ( `id` int(11) unsigned NOT NULL AUTO_INCREMENT COMMENT '主鍵', `method_name` varchar(64) NOT NULL COMMENT '鎖定的方法名', `desc` varchar(255) NOT NULL COMMENT '備注信息', `update_time` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, PRIMARY KEY (`id`), UNIQUE KEY `uidx_method_name` (`method_name`) USING BTREE ) ENGINE=InnoDB AUTO_INCREMENT=3 DEFAULT CHARSET=utf8 COMMENT='鎖定中的方法';
2、想要執行某個方法，就使用這個方法名向表中插入數據：
INSERT INTO method_lock (method_name, desc) VALUES ('methodName', '測試的methodName');
因為我們對method_name做了唯一性約束，這里如果有多個請求同時提交到數據庫的話，數據庫會保證只有一個操作可以成功，那么我們就可以認為操作成功的那個線程獲得了該方法的鎖，可以執行方法體內容。
3、成功插入則獲取鎖，執行完成后刪除對應的行數據釋放鎖：
delete from method_lock where method_name ='methodName';
注意：這只是使用基於數據庫的一種方法，使用數據庫實現分布式鎖還有很多其他的玩法！
使用基於數據庫的這種實現方式很簡單，但是對於分布式鎖應該具備的條件來說，它有一些問題需要解決及優化：
1）因為是基於數據庫實現的，數據庫的可用性和性能將直接影響分布式鎖的可用性及性能，所以，數據庫需要雙機部署、數據同步、主備切換；
2）不具備可重入的特性，因為同一個線程在釋放鎖之前，行數據一直存在，無法再次成功插入數據，所以，需要在表中新增一列，用於記錄當前獲取到鎖的機器和線程信息，在再次獲取鎖的時候，先查詢表中機器和線程信息是否和當前機器和線程相同，若相同則直接獲取鎖；
3）沒有鎖失效機制，因為有可能出現成功插入數據后，服務器宕機了，對應的數據沒有被刪除，當服務恢復后一直獲取不到鎖，所以，需要在表中新增一列，用於記錄失效時間，並且需要有定時任務清除這些失效的數據；
4）不具備阻塞鎖特性，獲取不到鎖直接返回失敗，所以需要優化獲取邏輯，循環多次去獲取。
5）在實施的過程中會遇到各種不同的問題，為了解決這些問題，實現方式將會越來越復雜；依賴數據庫需要一定的資源開銷，性能問題需要考慮。
二、基於Redis的實現方式
1、選用Redis實現分布式鎖原因：
1）Redis有很高的性能；
2）Redis命令對此支持較好，實現起來比較方便
2、使用命令介紹：
1）SETNX
SETNX key val：當且僅當key不存在時，set一個key為val的字符串，返回1；若key存在，則什么都不做，返回0。
2）expire
expire key timeout：為key設置一個超時時間，單位為second，超過這個時間鎖會自動釋放，避免死鎖。
3）delete
delete key：刪除key
3、實現思想：
1）獲取鎖的時候，使用setnx加鎖，並使用expire命令為鎖添加一個超時時間，超過該時間則自動釋放鎖，鎖的value值為一個隨機生成的UUID，通過此在釋放鎖的時候進行判斷。
2）獲取鎖的時候還設置一個獲取的超時時間，若超過這個時間則放棄獲取鎖。
3）釋放鎖的時候，通過UUID判斷是不是該鎖，若是該鎖，則執行delete進行鎖釋放。
4、 分布式鎖的簡單實現代碼：
/** * 分布式鎖的簡單實現代碼 */ public class DistributedLock { private final JedisPool jedisPool; public DistributedLock(JedisPool jedisPool) { this.jedisPool = jedisPool; } /** * 加鎖 * @param lockName 鎖的key * @param acquireTimeout 獲取超時時間 * @param timeout 鎖的超時時間 * @return 鎖標識 */ public String lockWithTimeout(String lockName, long acquireTimeout, long timeout) { Jedis conn = null; String retIdentifier = null; try { // 獲取連接 conn = jedisPool.getResource(); // 隨機生成一個value String identifier = UUID.randomUUID().toString(); // 鎖名，即key值 String lockKey = "lock:" + lockName; // 超時時間，上鎖后超過此時間則自動釋放鎖 int lockExpire = (int) (timeout / 1000); // 獲取鎖的超時時間，超過這個時間則放棄獲取鎖 long end = System.currentTimeMillis() + acquireTimeout; while (System.currentTimeMillis() < end) { if (conn.setnx(lockKey, identifier) == 1) { conn.expire(lockKey, lockExpire); // 返回value值，用於釋放鎖時間確認 retIdentifier = identifier; return retIdentifier; } // 返回-1代表key沒有設置超時時間，為key設置一個超時時間 if (conn.ttl(lockKey) == -1) { conn.expire(lockKey, lockExpire); } try { Thread.sleep(10); } catch (InterruptedException e) { Thread.currentThread().interrupt(); } } } catch (JedisException e) { e.printStackTrace(); } finally { if (conn != null) { conn.close(); } } return retIdentifier; } /** * 釋放鎖 * @param lockName 鎖的key * @param identifier 釋放鎖的標識 * @return */ public boolean releaseLock(String lockName, String identifier) { Jedis conn = null; String lockKey = "lock:" + lockName; boolean retFlag = false; try { conn = jedisPool.getResource(); while (true) { // 監視lock，准備開始事務 conn.watch(lockKey); // 通過前面返回的value值判斷是不是該鎖，若是該鎖，則刪除，釋放鎖 if (identifier.equals(conn.get(lockKey))) { Transaction transaction = conn.multi(); transaction.del(lockKey); List<object> results = transaction.exec(); if (results == null) { continue; } retFlag = true; } conn.unwatch(); break; } } catch (JedisException e) { e.printStackTrace(); } finally { if (conn != null) { conn.close(); } } return retFlag; } }
三、基於ZooKeeper的實現方式
ZooKeeper是一個為分布式應用提供一致性服務的開源組件，它內部是一個分層的文件系統目錄樹結構，規定同一個目錄下只能有一個唯一文件名。基於ZooKeeper實現分布式鎖的步驟如下：
1）創建一個目錄mylock；
2）線程A想獲取鎖就在mylock目錄下創建臨時順序節點；
3）獲取mylock目錄下所有的子節點，然后獲取比自己小的兄弟節點，如果不存在，則說明當前線程順序號最小，獲得鎖；
4）線程B獲取所有節點，判斷自己不是最小節點，設置監聽比自己次小的節點；
5）線程A處理完，刪除自己的節點，線程B監聽到變更事件，判斷自己是不是最小的節點，如果是則獲得鎖。
這里推薦一個Apache的開源庫Curator，它是一個ZooKeeper客戶端，Curator提供的InterProcessMutex是分布式鎖的實現，acquire方法用於獲取鎖，release方法用於釋放鎖。
優點：具備高可用、可重入、阻塞鎖特性，可解決失效死鎖問題。
缺點：因為需要頻繁的創建和刪除節點，性能上不如Redis方式。