學會用數聽說話-分佈式鎖究竟能夠多少併發？

程序員萌萌在瀏覽關於分佈式鎖的文章，忽然下面的話引發了萌萌的注意：

 

 

 

在鎖操做的客戶端打日誌

獲取鎖：

T13:31:51.230redisname-lock:hsetnx

E13:31:51.230GetConnection10.X.X.X

T13:31:51.231redisname-lock:hsetnx

設置超時時間：

T13:31:51.230redisname-lock:hsetnx

E13:31:51.230GetConnection10.X.X.X

T13:31:51.231redisname-lock:hsetnx

釋放鎖：

T13:31:51.230redisname-unlock:hsetnx

E13:31:51.230GetConnection10.X.X.X

T13:31:51.231redisname-unlock:hsetnx

從上面數據能夠看到一個正常分佈式鎖操做，操做時間在1ms，由於是從客戶端獲取的，由於粒度只能是毫秒級。再從服務端看看是什麼狀況。

 

 

上面顯示了大於1ms的慢查詢狀況，能夠看到每秒幾百個的QPS不會形成分佈式鎖自己的慢查詢。耗時超過1ms的都是集羣操做，分佈式鎖的lock和unlock操做時間都是us級。

    若是lock和unlock中間沒有任何邏輯的理想狀況下，同一個鎖能夠支持每秒：

   1000ms/ (1ms的lock+1ms的設置超時+1ms的unlock)=333(個)

結論

分佈式鎖自己lock和unlock耗時是us級，在理想狀況下大概可支持每秒1000個原子操做，300多個從分配到釋放流程結束。

 

舉個栗子🌰：

秒殺場景下，秒殺的產品有1000件。若是使用了分佈式鎖，理想狀況下能夠在1m內處理完全部的秒殺成功請求，其餘請求直接返回秒殺結束。

既然秒殺都沒有問題，通常狀況下，分佈式鎖不會是性能瓶頸。若是出現了性能問題，首先先排查業務邏輯。

 

目錄

1：一個線程裏lock成功，unlock失敗？

2：有哪些抓手能夠肯定哪些邏輯耗時太多？

3：鎖內部要避免的操做有哪些？

4：循環獲取鎖的時間間隔怎麼算合理？

5：獲取鎖重試次數怎麼算合理？

6：屢次獲取鎖失敗緣由有哪些？

7：加了分佈式鎖還出現了併發問題？

1：一個線程裏lock成功，unlock失敗？

Q: 日誌裏報了屢次的unlock失敗，什麼緣由？

A: 以前的代碼裏try finally模式的unlock，是否lock成功都會unlock。

Q:加上了lock成功才unlock，仍是有unlock失敗？

A:這是鎖住的邏輯耗時太多，超過了expire的時間，自動釋放鎖了。

2：有哪些抓手能夠肯定哪些邏輯耗時太多？

Q: 日誌能夠嗎？

A: 目前的日誌能夠找到有問題的traceId，看整個鏈路都進行了哪些處理，大概幾步時間消耗，可是具體sql的耗時分析沒有

Q：CAT監控能夠嗎？

A：CAT監控能夠找到耗時多的幾個請求，看到每條sql的耗時狀況，超過5秒的sql都是須要注意的

3：鎖內部要避免的操做有哪些？

Q：邏輯上的？

A：避免顯式的和隱式的循環。如：.stream().

Q：性能上的？

A：數據查詢的條件是否創建了索引

4：循環獲取鎖的時間間隔怎麼算合理？

A：獲取鎖與服務器通信時間能夠忽略不計，在跨機房的狀況下理論上也不超過2ms

因此鎖能夠獲取到的時間=一段分佈式鎖中間執行時間平均值

5：獲取鎖重試次數怎麼算合理？

A：獲取鎖的重試次數理論上若是獲取鎖時間間隔合理的話，就與容許的同時擴容最大容器數接近，不大於最大容器數20%。

6：屢次獲取鎖失敗緣由有哪些？

A：若是不符合可獲取到的時間間隔計算，則考慮是否特定場景下有耗時操做。具體可參考 3：鎖內部要避免的操做有哪些？

7：加了分佈式鎖還出現了併發問題？

Q：鎖獲取失敗是怎麼處理的？

A：鎖獲取失敗並無按請求失敗處理，而是在無鎖狀態下繼續執行會引起併發問題。

Q：鎖獲取成功了仍是出現併發問題？

A：執行太慢了，超過了expire的時間鎖失效了。

 

 

簡介：

一個有邏輯、有觀點、有溫度、有調性的技術公衆號~

做者是一個有日本東京、美國硅谷工做經驗，有百項技術發明專利，十一年程序媛。

歡迎一塊兒探索技術~