同一個jvm里多個線程操作同一個有狀態(tài)的變量，可以通過JVM內(nèi)的鎖保證線程安全。
如果是多個JVM操作同一個有狀態(tài)的變量，如何保證線程安全呢？
這時候就需要分布式鎖來發(fā)揮它的作用了
分布式系統(tǒng)往往業(yè)務(wù)流量比較大、并發(fā)較高，對分布式鎖的高可用和高性能有較高的要求。一般分布式鎖的方案需要滿足如下要求：
利用主鍵唯一的特性，如果有多個請求同時提交到數(shù)據(jù)庫的話，數(shù)據(jù)庫會保證只有一個插入操作可以成功，那么我們就可以認(rèn)為操作成功的那個線程獲得了該方法的鎖，當(dāng)方法執(zhí)行完畢之后，想要釋放鎖的話，刪除這條數(shù)據(jù)庫記錄即可
重慶分公司
重慶分公司
connection.commit()操作來釋放鎖一般數(shù)據(jù)庫使用innodb存儲引擎，在插入數(shù)據(jù)的時候會加行級鎖。從而達到是并發(fā)請求按順序執(zhí)行的效果
更新數(shù)據(jù)的時候帶上指定版本號，如果被其他線程提前更新的版本號，則此次更新失敗
對數(shù)據(jù)庫表侵入較大，每個表需要增加version字段
高并發(fā)下存在很多更新失敗
原子命令：SET key value NX PX milliseconds
PX?milliseconds 過期時間，防止加鎖線程死掉不能解鎖。過期時間設(shè)置太短，可能加鎖線程還沒有執(zhí)行完正常邏輯，就到了過期時間
NX 如果沒有這個key則設(shè)置，存在key返回失敗
value 隨機值（一般用UUID），用來實現(xiàn)只能由加鎖線程解鎖
lua腳本實現(xiàn)get value，delete的操作。加鎖的時候設(shè)置的value是不會重復(fù)的隨機值，解鎖的時候必須UUID一致才能解鎖
org.redisson
redisson
3.3.2
在Redis的分布式環(huán)境中，我們假設(shè)有N個Redis master。這些節(jié)點完全互相獨立，不存在主從復(fù)制或者其他集群協(xié)調(diào)機制。我們確保將在N個實例上使用與在Redis單實例下相同方法獲取和釋放鎖?，F(xiàn)在我們假設(shè)有5個Redis master節(jié)點，同時我們需要在5臺服務(wù)器上面運行這些Redis實例，這樣保證他們不會同時都宕掉。
假設(shè)有cluster-1，cluster-2，cluster-3總計3個cluster模式集群。如果要獲取分布式鎖，那么需要向這3個cluster集群通過EVAL命令執(zhí)行LUA腳本，需要3/2+1=2，即至少2個cluster集群響應(yīng)成功。set的value要具有唯一性，redisson的value通過UUID+threadId保證value的唯一性
1.獲取當(dāng)前時間（單位是毫秒）。
2.輪流用相同的key和隨機值在N個節(jié)點上請求鎖，在這一步里，客戶端在每個master上請求鎖時，會有一個和總的鎖釋放時間相比小的多的超時時間。比如如果鎖自動釋放時間是10秒鐘，那每個節(jié)點鎖請求的超時時間可能是5-50毫秒的范圍，這個可以防止一個客戶端在某個宕掉的master節(jié)點上阻塞過長時間，如果一個master節(jié)點不可用了，我們應(yīng)該盡快嘗試下一個master節(jié)點。
3.客戶端計算第二步中獲取鎖所花的時間，只有當(dāng)客戶端在大多數(shù)master節(jié)點上成功獲取了鎖（在這里是3個），而且總共消耗的時間不超過鎖釋放時間，這個鎖就認(rèn)為是獲取成功了。
4.如果鎖獲取成功了，那現(xiàn)在鎖自動釋放時間就是最初的鎖釋放時間減去之前獲取鎖所消耗的時間。
5.如果鎖獲取失敗了，不管是因為獲取成功的鎖不超過一半（N/2+1)還是因為總消耗時間超過了鎖釋放時間，客戶端都會到每個master節(jié)點上釋放鎖，即便是那些他認(rèn)為沒有獲取成功的鎖。
需要在所有節(jié)點都釋放鎖就行，不管之前有沒有在該節(jié)點獲取鎖成功。
客戶端如果沒有在多數(shù)節(jié)點獲取到鎖，一定要盡快在獲取鎖成功的節(jié)點上釋放鎖，這樣就沒必要等到key超時后才能重新獲取這個鎖
開始之前，讓我們假設(shè)客戶端可以在大多數(shù)節(jié)點都獲取到鎖，這樣所有的節(jié)點都會包含一個有相同存活時間的key。但是需要注意的是，這個key是在不同時間點設(shè)置的，所以這些key也會在不同的時間超時，但是我們假設(shè)最壞情況下第一個key是在T1時間設(shè)置的（客戶端連接到第一個服務(wù)器時的時間），最后一個key是在T2時間設(shè)置的（客戶端收到最后一個服務(wù)器返回結(jié)果的時間），從T2時間開始，我們可以確認(rèn)最早超時的key至少也會存在的時間為MIN_VALIDITY=TTL-(T2-T1)-CLOCK_DRIFT，TTL是鎖超時時間、（T2-T1）是最晚獲取到的鎖的耗時，CLOCK_DRIFT是不同進程間時鐘差異，這個是用來補償前面的(T2-T1）。其他的key都會在這個時間點之后才會超時，所以我們可以確定這些key在這個時間點之前至少都是同時存在的。
如果一個客戶端獲取大多數(shù)節(jié)點鎖的耗時接近甚至超過鎖的大有效時間時（就是我們?yōu)镾ET操作設(shè)置的TTL值），那么系統(tǒng)會認(rèn)為這個鎖是無效的同時會釋放這些節(jié)點上的鎖，所以我們僅僅需要考慮獲取大多數(shù)節(jié)點鎖的耗時小于有效時間的情況。在這種情況下，根據(jù)我們前面的證明，在MIN_VALIDITY時間內(nèi)，沒有客戶端能重新獲取鎖成功，所以多個客戶端都能同時成功獲取鎖的結(jié)果，只會發(fā)生在多數(shù)節(jié)點獲取鎖的時間都大大超過TTL時間的情況下，實際上這種情況下這些鎖都會失效
利用臨時節(jié)點與 watch 機制。每個鎖占用一個普通節(jié)點 /lock，當(dāng)需要獲取鎖時在 /lock 目錄下創(chuàng)建一個臨時節(jié)點，創(chuàng)建成功則表示獲取鎖成功，失敗則 watch/lock 節(jié)點，有刪除操作后再去爭鎖。臨時節(jié)點好處在于當(dāng)進程掛掉后能自動上鎖的節(jié)點自動刪除即取消鎖。
所有取鎖失敗的進程都監(jiān)聽父節(jié)點，很容易發(fā)生羊群效應(yīng)，即當(dāng)釋放鎖后所有等待進程一起來創(chuàng)建節(jié)點，并發(fā)量很大。
上鎖改為創(chuàng)建臨時有序節(jié)點，每個上鎖的節(jié)點均能創(chuàng)建節(jié)點成功，只是其序號不同。只有序號最小的可以擁有鎖，如果這個節(jié)點序號不是最小的則 watch 序號比本身小的前一個節(jié)點 (公平鎖)。
在鎖節(jié)點下創(chuàng)建臨時順序節(jié)點。讀節(jié)點為R+序號，寫節(jié)點為W+序號。創(chuàng)建完節(jié)點后，獲取所有子節(jié)點，對鎖節(jié)點注冊子節(jié)點變更的watcher監(jiān)聽，確定自己的序號在所有子節(jié)點中的位置。對于讀請求，沒有比自己序號小的寫節(jié)點，就表示獲得了共享鎖，執(zhí)行讀取邏輯。對于寫請求，如果自己不是序號最小的子節(jié)點，就需要進入等待。接收到watcher通知后，重復(fù)獲取鎖。
共享鎖羊群效應(yīng)。大量的watcher通知和子節(jié)點列表獲取，兩個操作重復(fù)運行。集群規(guī)模比較大的情況下，會對zookeeper服務(wù)器造成巨大的性能影響和網(wǎng)絡(luò)沖擊
讀請求，監(jiān)聽比自己小的寫節(jié)點。寫請求，監(jiān)聽比自己小的最后一個節(jié)點。
另外有需要云服務(wù)器可以了解下創(chuàng)新互聯(lián)scvps.cn，海內(nèi)外云服務(wù)器15元起步，三天無理由+7*72小時售后在線，公司持有idc許可證，提供“云服務(wù)器、裸金屬服務(wù)器、高防服務(wù)器、香港服務(wù)器、美國服務(wù)器、虛擬主機、免備案服務(wù)器”等云主機租用服務(wù)以及企業(yè)上云的綜合解決方案，具有“安全穩(wěn)定、簡單易用、服務(wù)可用性高、性價比高”等特點與優(yōu)勢，專為企業(yè)上云打造定制，能夠滿足用戶豐富、多元化的應(yīng)用場景需求。
