分散式鎖的作用

在單機場景下可以使用內建鎖來實現程序同步，但在分散式場景下需要同步的程序可能位於不同節點上，就需要用到分散式鎖， 可以保證在分散式部署的應用叢集中，同一個方法在同一操作只能被一臺機器上的一個執行緒執行。

簡而言之分散式鎖是解決分散式環境中同一個方法被客戶端呼叫的一致性問題。

分散式鎖的三種實現方式

1. 基於資料庫實現分散式鎖；
2. 基於快取（Redis等）實現分散式鎖；
3. 基於Zookeeper實現分散式鎖；

redis分散式鎖Redisson解決方案

　　模擬springCloud分散式環境中商品秒殺問題

• 假設秒殺服務分佈在2個節點上，每個節點上有1000件商品。
• 分別建立eureka，zuul，springboot-reddsion三個服務，其中springboot-reddsion服務作為秒殺服務，並啟動2個例項(8000,8001)，模擬2個節點
• 通過zuul閘道器統一入口購買商品，預設zuul閘道器負載均衡是輪詢策略，因此訪問購買介面時會輪詢呼叫springboot-reddsion例項介面
• 啟動20個執行緒(模擬20個使用者)購買商品，直到介面返回庫存不足時結束購買，不加分散式鎖和加分散式鎖分別測試10次

　　測試結果如下：

第一批測試
========不加redisson鎖-測試20個使用者同時購買2個節點上(各1000件)共2000件商品========
第1次測試，一共購買2012個
第2次測試，一共購買2004個
第3次測試，一共購買2028個
第4次測試，一共購買2032個
第5次測試，一共購買2014個
第6次測試，一共購買2004個
第7次測試，一共購買2066個
第8次測試，一共購買2084個
第9次測試，一共購買2072個
第10次測試，一共購買2072個
========加redisson鎖-測試20個使用者同時購買2個節點上(各1000件)共2000件商品========
第1次測試，一共購買1986個
第2次測試，一共購買1996個
第3次測試，一共購買2000個
第4次測試，一共購買1974個
第5次測試，一共購買2000個
第6次測試，一共購買1992個
第7次測試，一共購買2000個
第8次測試，一共購買1992個
第9次測試，一共購買1976個
第10次測試，一共購買1990個
--------------------------------------------------------------------------
第二批測試
========不加redisson鎖-測試20個使用者同時購買2個節點上(各1000件)共2000件商品========
第1次測試，一共購買2064個
第2次測試，一共購買2046個
第3次測試，一共購買2062個
第4次測試，一共購買2028個
第5次測試，一共購買2048個
第6次測試，一共購買2042個
第7次測試，一共購買2036個
第8次測試，一共購買2062個
第9次測試，一共購買2044個
第10次測試，一共購買2048個
========加redisson鎖-測試20個使用者同時購買2個節點上(各1000件)共2000件商品========
第1次測試，一共購買1978個
第2次測試，一共購買1990個
第3次測試，一共購買1944個
第4次測試，一共購買1974個
第5次測試，一共購買2000個
第6次測試，一共購買2000個
第7次測試，一共購買1952個
第8次測試，一共購買1956個
第9次測試，一共購買1966個
第10次測試，一共購買1996個

結論

　　很明顯不加鎖出現了超賣現象，而加鎖沒有出現超賣問題。

分析

• 不加鎖超賣是由於沒做同步導致，但加鎖後為什麼大部分購買總件數沒達到2000件就結束了呢？

• 加鎖狀態下總購買件數小於2000，是由於直接在專案中寫死了1000件（偷懶了）。模擬呼叫時介面時只要返回沒庫存時就結束購買，

• 由於zuul閘道器預設是輪序負載均衡，所以當輪詢到已經賣完的節點就會結束當前使用者的購買，因此測試結果才小於等於2000。

• 如果節點使用同一資料來源就不會出現小於總數的問題了。到此為止加分散式鎖時，可有效解決分散式環境中同一個介面資料一致性問題。

測試程式碼見倉庫專案