關(guān)于分布式鎖，可能絕大部分人都會或多或少涉及到恋沃。
我舉二個例子：
場景一：從前端界面發(fā)起一筆支付請求，如果前端沒有做防重處理，那么可能在某一個時刻會有二筆一樣的單子同時到達系統(tǒng)后臺蛀缝。
場景二：在App中下訂單的時候，點擊確認之后目代，沒反應屈梁，就又點擊了幾次。在這種情況下榛了，如果無法保證該接口的冪等性在讶，那么將會出現(xiàn)重復下單問題。
在接收消息的時候霜大，消息推送重復构哺。如果處理消息的接口無法保證冪等，那么重復消費消息產(chǎn)生的影響可能會非常大战坤。
類似這種場景曙强，我們有很多種方法，可以使用冪等操作途茫，也可以使用鎖的操作碟嘴。
我們先來解釋一下什么是冪等操作：
所謂冪等，簡單地說囊卜，就是對接口的多次調(diào)用所產(chǎn)生的結(jié)果和調(diào)用一次是一致的臀防。擴展一下眠菇，這里的接口，可以理解為對外發(fā)布的HTTP接口或者Thrift接口袱衷，也可以是接收消息的內(nèi)部接口捎废，甚至是一個內(nèi)部方法或操作。
在分布式環(huán)境中致燥，網(wǎng)絡環(huán)境更加復雜登疗，
因前端操作抖動、網(wǎng)絡故障嫌蚤、消息重復辐益、響應速度慢等原因，對接口的重復調(diào)用概率會比集中式環(huán)境下更大脱吱，尤其是重復消息在分布式環(huán)境中很難避免智政。
分布式環(huán)境中，有些接口是天然保證冪等性的箱蝠，如查詢操作续捂。有些對數(shù)據(jù)的修改是一個常量，并且無其他記錄和操作宦搬，那也可以說是具有冪等性的牙瓢。其他情況下，所有涉及對數(shù)據(jù)的修改间校、狀態(tài)的變更就都有必要防止重復性操作的發(fā)生矾克。通過間接的實現(xiàn)接口的冪等性來防止重復操作所帶來的影響，成為了一種有效的解決方案憔足。
于是我們根據(jù)以上內(nèi)容就可以講一下使用分布式鎖的方法有哪些胁附。
1、使用數(shù)據(jù)庫樂觀鎖滓彰，包括主鍵防重汉嗽，版本號控制。但是這兩種方法各有利弊找蜜。
使用主鍵沖突的策略進行防重，在并發(fā)量非常高的情況下對數(shù)據(jù)庫性能會有影響稳析，尤其是應用數(shù)據(jù)表和主鍵沖突表在一個庫的時候洗做，表現(xiàn)更加明顯。其實針對是否會對數(shù)據(jù)庫性能產(chǎn)生影響這個話題彰居，我也和一些專業(yè)的DBA同學討論過诚纸，普遍認可的是在MySQL數(shù)據(jù)庫中采用主鍵沖突防重，在大并發(fā)情況下有可能會造成鎖表現(xiàn)象陈惰，比較好的辦法是在程序中生產(chǎn)主鍵進行防重畦徘。
使用版本號策略
這個策略源于mysql的mvcc機制，使用這個策略其實本身沒有什么問題，唯一的問題就是對數(shù)據(jù)表侵入較大井辆，我們要為每個表設計一個版本號字段关筒，然后寫一條判斷sql每次進行判斷。
2杯缺、Zookeeper防重策略
利用ZK確實是一個不錯的方案蒸播，流程如下：
以前的版本中普遍傳言說它的性能不好，但是后續(xù)的版本性能得到了較大提高萍肆，經(jīng)過系統(tǒng)壓測還是能夠支撐較大并發(fā)量的袍榆，經(jīng)過壓測三臺Zookeeper能搞住20000tps。
用zookeeper的優(yōu)點大概有：高可用塘揣、公平鎖包雀、心跳保持鎖。
3亲铡、Redis防重策略
關(guān)于主從Redis方案最簡單的實現(xiàn)流程如下：
表面來看才写，這個方案似乎很管用，但是這里存在一個問題：在我們的系統(tǒng)架構(gòu)里存在一個單點故障奴愉，如果Redis的master節(jié)點宕機了怎么辦呢琅摩？有人可能會說：加一個slave節(jié)點！在master宕機時用slave就行了锭硼！但是其實這個方案明顯是不可行的房资，因為這種方案無法保證第1個安全互斥屬性，因為Redis的復制是異步的檀头。 總的來說轰异，這個方案里有一個明顯的競爭條件（race condition），舉例來說：
客戶端A在master節(jié)點拿到了鎖暑始。
master節(jié)點在把A創(chuàng)建的key寫入slave之前宕機了搭独。
slave變成了master節(jié)點
B也得到了和A還持有的相同的鎖（因為原來的slave里還沒有A持有鎖的信息）。
