-
分布式鎖的實作方案?
相比單例鎖，分布式鎖需要解決的問題：- 互斥性：任意時刻只能有一個客戶端擁有鎖，不能同時多個客戶端獲取，
- 安全性：鎖只能被持有該鎖的用戶洗掉，而不能被其他用戶洗掉，
- 死鎖：獲取鎖的客戶端因為某些原因而宕機，而未能釋放鎖，其他客戶端無法獲取此鎖，需要有機制來避免該類問題的發生，
- 容錯：當部分節點宕機，客戶端仍能獲取鎖或者釋放鎖，
常用的方案是基于Redis集群的鎖實作，常用的Java組件是Redission，它對Redis分布式鎖的實作非常完善，實作可重入鎖、讀寫鎖、公平鎖、信號量、CountDownLatch等很多種復雜的鎖的語意，滿足我們對分布式鎖的不同層次的需求，
-
主從模式下節點宕機可能導致鎖失效，Redission怎么解決的
Redission實作了Redlock演算法解決這個問題， -
說說Redlock演算法的原理
假設我們有5個Redis master實體：- 客戶端獲取服務器當前的的時間t0，毫秒數，
- 使用相同的key和value依次向5個實體獲取鎖，客戶端在獲取鎖的時候自身設定一個遠小于業務鎖需要的持續時間的超時時間，舉個例子，假設鎖需要10秒，超時時間可以設定成比如5-50毫秒，這個避免某個Redis本身已經掛了，但是客戶端一直在嘗試獲取鎖的情況，超時了之后就直接跳到下一個節點，
- 客戶端通過當前時間（t1）減去t0，計算獲取鎖所消耗的時間t2（t1-t0)，只有t2小于鎖的業務有效時間(也就是第二步的10秒)，并且，客戶端在至少3(5/2+1)臺上獲取到鎖我們才認為鎖獲取成功，
- 如果鎖已經獲取，那么鎖的業務有效時間為10s-t2，
- 如果客戶端沒有獲取到鎖，可能是沒有在大于等于N/2+1個實體上獲取鎖，也可能是有效時間(10s-t2)為負數，我們就嘗試去釋放鎖，即使是并沒有在那個節點上獲取到，
-
Redlock演算法有什么缺點嗎？
時間偏差在分布式系統中很常見，在鎖有效時間里雖然減去了時鐘偏移，但是這個值不太好確定，Redis作者也建議對鎖互斥的安全性要求高的應用不要使用這個演算法，
參考(部分摘抄的文字著作權屬于原作者)：
https://www.jianshu.com/p/47fd7f86c848
https://www.jianshu.com/p/2d3bf2ff2315
https://www.cnblogs.com/sheldon-lou/p/11039795.html
https://www.cnblogs.com/luocaodan/p/10949558.html
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/10572.html
標籤：其他
上一篇：求MTR測驗工具