分散式鎖

為什麼需要分散式鎖

• 應用中需要避免多個線程在同一時間對同一個共用變數做修改
• 在單機部署的項目中，為了避免上述現象，需要對變數或代碼塊做同步
• 在分散式部署的項目中，為了避免上述現象，用同步是解決不了的（因為相同的項目部署在了多台伺服器，同步只能解決單台伺服器的問題），所以就需要分散式鎖，保證在分散式部署的應用集群中，同一個方法在同一時間只能被一臺機器上的一個線程執行

分散式鎖有幾種實現方式

主流的實現方式有三種
1、利用資料庫實現
2、利用緩存(redis)實現
3、利用zookeeper實現

簡述各種方式及優缺點

1、利用資料庫實現

優點：簡單、易理解
缺點：高併發時，性能差，增加了資料庫開銷

方法一：

• 新建一張表，向該表中添加相同主鍵的一條記錄， 哪個線程添加成功，即獲得了分散式鎖，
• 然後執行相關邏輯，邏輯執行完之後，刪除資料庫表中的該數據，刪除即代表解鎖

方法二、

• 使用for update，數據表會在查詢的時候添加排它鎖，
• 多個線程同時來執行時，只有一個會成功加鎖，其餘的線程都會阻塞，
• 加鎖成功的線程即獲得分散式鎖的線程，該線程執行相關邏輯，
• 邏輯執行完之後，使用connection.commit解鎖，此時阻塞的其他線程中會有一個加鎖成功....

2、使用redis緩存實現

優點：效率高
缺點：設置過期時間過長過短都不合適，需要根據實際情況權衡

大概思路：

• 向redis中添加key，並設置過期時間
• 如果key已存在，則添加失敗
• 如果key不存在，則添加成功
• 添加成功，即獲得了分散式鎖
• 獲得鎖的線程執行業務邏輯，執行完之後，刪除redis中的key(即解鎖)

3、通過zookeeper實現

優點：有效的解決單點問題，不可重入問題，非阻塞問題以及鎖無法釋放的問題。實現起來較為簡單
缺點：因為每次在創建鎖和釋放鎖的過程中，都要動態創建、銷毀臨時節點來實現鎖功能。
ZK中創建和刪除節點只能通過Leader伺服器來執行，然後將數據同步到所有的 Follower 機器上。

大概思路：

• 每一個鎖都是zookeeper上的一個znode（普通節點）
• 當多個線程來獲取鎖時，都會在該znode上創建有序臨時子節點，每個有序臨時子節點都有自己的序號
• 只有序號最小的可以擁有鎖，然後執行相關邏輯，執行完成之後刪除子節點（即解鎖），觸發監聽
• 序號如果不是最小的，則沒有獲得鎖，設置監聽事件，監聽序號比本身小的前一個節點，
• 等待事件觸發再次比較是否是最小的