學會用資料說話-分散式鎖究竟可以多少併發？

在鎖操作的客戶端打日誌

獲取鎖：

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的時間鎖失效了。

 

簡介：

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

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

歡迎一起探索技術~