原文：
執行緒併發問題和程序間併發問題都可以通過分布式鎖解決，但是很大題小做。非常消耗資源。
分布式鎖最適合解決分布式情況下的多程序併發問題。
分布式鎖本身lock和unlock耗時是us微秒級，在理想情況下大概可支援每秒1000個原子操作，300多個從分配到釋放流程結束。
場景：採用分布式鎖1秒間秒殺1000件商品，如果效能出現了問題，應該先排查業務邏輯。
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：多次獲取鎖失敗原因有哪些？
7：加了分布式鎖還出現了併發問題？
q：鎖獲取失敗是怎麼處理的？
a：鎖獲取失敗並沒有按請求失敗處理，而是在無鎖狀態下繼續執行會引發併發問題。
q：鎖獲取成功了還是出現併發問題？
a：執行太慢了，超過了expire的時間鎖失效了。
分布式 分布式鎖
本質是利用redis的setnx 方法的特性來加鎖，setnx 即key不存在則設定key，否則直接返回false，要求在分布式系統中使用同乙個redis服務，以下提供兩種解決方案 1 直接使用redistemplate 這其實並不能完全保證高併發下的安全問題，因為可能在鎖過期之後該執行緒尚未執行完...
分布式專題 分布式鎖
在傳統的單體應用架構中,遇到併發安全性問題時我們可以通過同步鎖synchronized,同步 塊,reentrantlock等方式都可以解決,但隨著業務的發展，單體應用架構不能滿足龐大的使用者請求量，於是分布式系統應用而生，在分布式系統中,由於每個系統都執行在不同的伺服器上，有著不同的jvm,所以j...
分布式鎖 使用Redis實現分布式鎖
關於分布式鎖的實現，我的前一篇文章講解了如何使用zookeeper實現分布式鎖。關於分布式鎖的背景此處不再做贅述，我們直接討論下如何使用redis實現分布式鎖。關於redis，筆主不打算做長篇大論的介紹，只介紹下redis優秀的特性。支援豐富的資料型別，如string list map set zs...