為了防止分布式系統中的多個程序之間相互干擾，我們需要一種分布式協調技術來對這些程序進行排程。而這個分布式協調技術的核心就是來實現這個分布式鎖。
分布式鎖實現的三個核心要素：加鎖、解鎖、鎖超時
1） 加鎖
最簡單的方法是使用setnx命令。key是鎖的唯一標識，按業務來決定命名。比如想要給一種商品的秒殺活動加鎖，可以給key命名為 「lock_sale_商品id」 。value設定成1，表示庫存。
當乙個執行緒執行setnx返回1，說明key原本不存在，該執行緒成功得到了鎖；當乙個執行緒執行setnx返回0，說明key已經存在，該執行緒搶鎖失敗。
2）解鎖
有加鎖就得有解鎖。當得到鎖的執行緒執行完任務，需要釋放鎖，以便其他執行緒可以進入。釋放鎖的最簡單方式是執行del指令。
3）鎖超時
如果乙個得到鎖的執行緒在執行任務的過程中掛掉，來不及顯式地釋放鎖，這塊資源將會永遠被鎖住（死鎖），別的執行緒再也別想進來。所以，setnx的key必須設定乙個超時時間，以保證即使沒有被顯式釋放，這把鎖也要在一定時間後自動釋放。setnx不支援超時引數，所以需要額外的指令。
情景：首先執行緒a拿到了鎖，但這個時候執行緒a掛掉了，鎖就會一直存在。
情景：1）由於設定了超時時間，如果執行緒a，在規定時間內，沒有處理完任務，它自動釋放了鎖，但實際還在占用資源。
2）執行緒b這個時候去申請鎖，申請到了鎖，如果執行的是和a不同的任務（如果相同的任務，導致資料異常）。
3）然後a完成了任務，執行刪除鎖的命令，實際刪除的是b的鎖。
1）首先解決刪除別人的鎖的問題
我們可以在刪除的時候進行乙個判斷，看當前持有鎖的執行緒是不是自己，如果是自己再刪除
2）解決自動釋放問題
可以用乙個監聽執行緒，去監聽a鎖的持續時間，一般當鎖的時間不足2/3時，續時
解決方案一：主從模式
主從模式的問題：如果在主庫剛拿到鎖的時候，掛了，從庫頂上，會導致鎖丟失。
解決：改用集群
解決方案二：集群
集群模式的問題：因為集群模式要給各個庫都傳送鎖資訊，各個庫得到鎖的時間不同，會導致鎖的持續時間不同
解決：啟用監聽執行緒
其他分布式鎖的也是類似的，做了乙個總結圖。
[外鏈轉存失敗,源站可能有防盜煉機制,建議將儲存下來直接上傳(img-kx8zp0f4-1597712518087)(c:\users\93584\desktop\面經\鎖.png)]
參考:
分布式鎖總結（一）
在某次某街面試中，面試官問 能否使用redis incr命令是否可以實現分布式鎖？正確的使用方式 incr 方法會導致什麼問題？當你template.opsforvalue increment key,1 這個key就存在了，如果忽然redis宕機，那麼這個key一直存在。為啥說我上面鏈結是正確解法...
分布式的一些思考
最有效率的分布式是在執行方法前知道所執行的方法使用的資料即所謂環境，並把相關資料和方法本法放到指定的機器上執行，返回結果給指定的客戶端。在方法本身不確定的前提下，所有資料都是環境一部分。如果使用統一資料伺服器的方法，網路和硬碟的開銷抵消了分布式的優勢。因為大部分操作無外乎就是把資料簡單操作後放到新的...
關於分布式排程框架的一些優秀資源總結
paste image.png niubi job 社群資料少，群 包含作者 活躍度極低，有問題靠自己 目前市面上的分布式任務框架有 簡單,但針對可靠性需要擴充套件的地方太多.建議,簡單場景使用 資料最多,技術群活躍度高.第一推薦 產品功能比較全,作者提供有較為詳細的資料,可以自己上手.技術群活躍度...