針對共享資源的互斥訪問歷來是很多業(yè)務(wù)系統(tǒng)需要解決的問題。在分布式系統(tǒng)中，通常會采用分布式鎖這一通用型解決方案。本文將就分布式鎖的實現(xiàn)原理、技術(shù)選型以及阿里云存儲的具體實踐進(jìn)行論述。

一 從單機鎖到分布式鎖

在單機環(huán)境中，當(dāng)共享資源自身無法提供互斥能力的時候，為了防止多線程/多進(jìn)程對共享資源的同時讀寫訪問造成的數(shù)據(jù)破壞，就需要一個第三方提供的互斥的能力，這里往往是內(nèi)核或者提供互斥能力的類庫，如下圖所示，進(jìn)程首先從內(nèi)核/類庫獲取一把互斥鎖，拿到鎖的進(jìn)程就可以排他性的訪問共享資源。演化到分布式環(huán)境，我們就需要一個提供同樣功能的分布式服務(wù)，不同的機器通過該服務(wù)獲取一把鎖，獲取到鎖的機器就可以排他性的訪問共享資源，這樣的服務(wù)我們統(tǒng)稱為分布式鎖服務(wù)，鎖也就叫分布式鎖。

??

單機鎖到分布式鎖

由此抽象一下分布式鎖的概念，首先分布式鎖需要是一個資源，這個資源能夠提供并發(fā)控制，并輸出一個排他性的狀態(tài)，也就是： 鎖 = 資源 + 并發(fā)控制 + 所有權(quán)展示

以常見的單機鎖為例：

• Spinlock = BOOL +CAS(樂觀鎖)
• Mutex = BOOL + CAS + 通知(悲觀鎖)

Spinlock 和 Mutex 都是一個 Bool 資源，通過原子的 CAS 指令：當(dāng)現(xiàn)在為 0 設(shè)置為 1，成功的話持有鎖，失敗的話不持有鎖，如果不提供所有權(quán)的展示，例如 AtomicInteger，也是通過資源(Interger)+ CAS，但是不會明確的提示所有權(quán)，因此不會被視為一種鎖，當(dāng)然，可以將“所有權(quán)展示”這個更多地視為某種服務(wù)提供形式的包裝。

單機環(huán)境下，內(nèi)核具備“上帝視角”，能夠知道進(jìn)程的存活，當(dāng)進(jìn)程掛掉的時候可以將該進(jìn)程持有的鎖資源釋放，但發(fā)展到分布式環(huán)境，這就變成了一個挑戰(zhàn)，為了應(yīng)對各種機器故障、宕機等，就需要給鎖提供了一個新的特性：可用性。

如下圖所示，任何提供三個特性的服務(wù)都可以提供分布式鎖的能力，資源可以是文件、KV 等，通過創(chuàng)建文件、KV 等原子操作，通過創(chuàng)建成功的結(jié)果來表明所有權(quán)的歸屬，同時通過 TTL 或者會話來保證鎖的可用性。

??

分布式鎖的特性和實現(xiàn)

二 分布式鎖的系統(tǒng)分類

根據(jù)鎖資源本身的安全性，我們將分布式鎖分為兩個陣營：

• 基于異步復(fù)制的分布式系統(tǒng)，例如 mysql，tair，redis 等。
• 基于 paxos 協(xié)議的分布式一致性系統(tǒng)，例如 zookeeper，etcd，consul 等。

基于異步復(fù)制的分布式系統(tǒng)，存在數(shù)據(jù)丟失(丟鎖)的風(fēng)險，不夠安全，往往通過 TTL 的機制承擔(dān)細(xì)粒度的鎖服務(wù)，該系統(tǒng)接入簡單，適用于對時間很敏感，期望設(shè)置一個較短的有效期，執(zhí)行短期任務(wù)，丟鎖對業(yè)務(wù)影響相對可控的服務(wù)。

基于 paxos 協(xié)議的分布式系統(tǒng)，通過一致性協(xié)議保證數(shù)據(jù)的多副本，數(shù)據(jù)安全性高，往往通過租約(會話)的機制承擔(dān)粗粒度的鎖服務(wù)，該系統(tǒng)需要一定的門檻，適用于對安全性很敏感，希望長期持有鎖，不期望發(fā)生丟鎖現(xiàn)象的服務(wù)。

三 阿里云存儲分布式鎖

阿里云存儲在長期的實踐過程中，在如何提升分布式鎖使用時的正確性、保證鎖的可用性以及提升鎖的切換效率方面積累比較多的經(jīng)驗。

1 嚴(yán)格互斥性

互斥性作為分布式鎖最基本的要求，對用戶而言就是不能出現(xiàn)“一鎖多占”，那么存儲分布式鎖是如何避免該情況的呢?

答案是，服務(wù)端每把鎖都和唯一的會話綁定，客戶端通過定期發(fā)送心跳來保證會話的有效性，也就保證了鎖的擁有權(quán)。當(dāng)心跳不能維持時，會話連同關(guān)聯(lián)的鎖節(jié)點都會被釋放，鎖節(jié)點就可以被重新?lián)屨?。這里有一個關(guān)鍵的地方，就是如何保證客戶端和服務(wù)端的同步，在服務(wù)端會話過期的時候，客戶端也能感知。

如下圖所示，在客戶端和服務(wù)端都維護(hù)了會話的有效期的時間，客戶端從心跳發(fā)送時刻(S0)開始計時，服務(wù)端從收到請求(S1)開始計時，這樣就能保證客戶端會先于服務(wù)端過期。 用戶在創(chuàng)建鎖之后，核心工作線程在進(jìn)行核心操作之前可以判斷是否有足夠的有效期，同時我們不再依賴墻上時間，而是基于系統(tǒng)時鐘來對時間進(jìn)行判斷，系統(tǒng)時鐘更加精確，且不會向前或者向后移動(秒級別誤差毫秒級，同時在 NTP 跳變的場景，最多會修改時鐘的速率)。

??

存儲場景的使用方式

在分布式鎖互斥性上，我們是不是做到完美了?并非如此，還是存在一種情況，業(yè)務(wù)基于分布式鎖服務(wù)的訪問互斥會被破壞。

我們來看下面的例子：如下圖所示，客戶端在時間點(S0)嘗試去搶鎖，在時間點(S1)在后端搶鎖成功，因此也產(chǎn)生了一個分布式鎖的有效期窗口。在有效期內(nèi)，時間點(S2)做了一個訪問存儲的操作，很快完成，然后在時間點(S3)判斷鎖的有效期依舊成立，繼續(xù)執(zhí)行訪問存儲操作，結(jié)果這個操作耗時良久，超過了分布式鎖的過期時間，那么可能這個時候，分布式鎖已經(jīng)被其他客戶端搶占成功，進(jìn)而出現(xiàn)兩個客戶端同時操作同一批數(shù)據(jù)的可能性，這種可能性是存在的，雖然概率很小。

??

越界場景

針對這個場景，具體的應(yīng)對方案是在操作數(shù)據(jù)的時候確保有足夠的鎖有效期窗口，當(dāng)然如果業(yè)務(wù)本身提供回滾機制的話，那么方案就更加完備，該方案也在存儲產(chǎn)品使用分布式鎖的過程中被采用。

還有一個更佳的方案，即，存儲系統(tǒng)本身引入 IOFence 能力。這里就不得不提 Martin Kleppmann 和 redis 的作者 antirez 之間的討論了。redis 為了防止異步復(fù)制導(dǎo)致的鎖丟失的問題，引入了 redlock，該方案引入了多數(shù)派的機制，需要獲得多數(shù)派的鎖，最大程度的保證了可用性和正確性，但仍然有兩個問題：

• 墻上時間的不可靠(NTP 時間)
• 異構(gòu)系統(tǒng)的無法做到嚴(yán)格正確性

墻上時間可以通過非墻上時間 MonoticTime 來解決(redis 目前仍然依賴墻上時間)，但是異構(gòu)系統(tǒng)只有一個系統(tǒng)并沒有辦法保證完全正確。如下圖所示，Client1 獲取了鎖，在操作數(shù)據(jù)的時候發(fā)生了 GC，在 GC 完成時候丟失了鎖的所有權(quán)，造成了數(shù)據(jù)不一致。

??

異構(gòu)系統(tǒng)無法做到完全正確性

因此需要兩個系統(tǒng)同時協(xié)作來完成一個完全正確的互斥訪問，在存儲系統(tǒng)引入 IOFence能力，如下圖所示，全局鎖服務(wù)提供全局自增的 token，Client 1 拿到鎖返回的 token 是 33，并帶入存儲系統(tǒng)，發(fā)生 GC，當(dāng) Client 2 搶鎖成功返回 34，帶入存儲系統(tǒng)，存儲系統(tǒng)會拒絕 token 較小的請求，那么經(jīng)過了長時間 full gc 重新恢復(fù)后的 Client 1 再次寫入數(shù)據(jù)的時候，因為存儲層記錄的token 已經(jīng)更新，攜帶 token 值為 33 的請求將被直接拒絕，從而達(dá)到了數(shù)據(jù)保護(hù)的效果(chubby 的論文中有講述，也是 Martin Kleppmann 提出的解決方案)。

??

引入IOFence能力

這與阿里云分布式存儲平臺盤古的設(shè)計思路不謀而合，盤古支持了類似 IO Fence 的寫保護(hù)能力，引入 Inline File 的文件類型，配合 SealFile 操作，這就有著類似 IO Fence 的寫保護(hù)能力。首先，SealFile 操作用來關(guān)閉已經(jīng)打開的 cs 上面的文件，防止舊的 Owner 繼續(xù)寫數(shù)據(jù);其次，InlineFile 可以防止舊的 Owner 打開新的文件。這兩個功能事實上也是提供了存儲系統(tǒng)中的 Token 支持。

2 可用性

存儲分布式鎖通過持續(xù)心跳來保證鎖的健壯性，讓用戶不用投入很多精力關(guān)注可用性，但也有可能異常的用戶進(jìn)程持續(xù)占據(jù)鎖。針對該場景，為了保證鎖最終可以被調(diào)度，提供了可以安全釋放鎖的會話加黑機制。

當(dāng)用戶需要將發(fā)生假死的進(jìn)程持有的鎖釋放時，可以通過查詢會話信息，并將會話加黑，此后，心跳將不能正常維護(hù)，最終導(dǎo)致會話過期，鎖節(jié)點被安全釋放。這里我們不是強制刪除鎖，而是選用禁用心跳的原因如下:

• 刪除鎖操作本身不安全，如果鎖已經(jīng)被其他人正常搶占，此時刪鎖請求會產(chǎn)生誤刪除。
• 刪除鎖后，持有鎖的人會話依然正常，它仍然認(rèn)為自己持有鎖，會打破鎖的互斥性原則。

3 切換效率

當(dāng)進(jìn)程持有的鎖需要被重新調(diào)度時，持有者可以主動刪除鎖節(jié)點，但當(dāng)持有者發(fā)生異常(如進(jìn)程重啟，機器宕機等)，新的進(jìn)程要重新?lián)屨?，就需要等待原先的會話過期后，才有機會搶占成功。默認(rèn)情況下，分布式鎖使用的會話生命期為數(shù)十秒，當(dāng)持有鎖的進(jìn)程意外退出后(未主動釋放鎖)，最長需要經(jīng)過很長時間鎖節(jié)點才可以被再次搶占。

??

客戶端和服務(wù)各自維護(hù)過期時間

要提升切換精度，本質(zhì)上要壓縮會話生命周期，同時也意味著更快的心跳頻率，對后端更大的訪問壓力。我們通過對進(jìn)行優(yōu)化，使得會話周期可以進(jìn)一步壓縮。

同時結(jié)合具體的業(yè)務(wù)場景，例如守護(hù)進(jìn)程發(fā)現(xiàn)鎖持有進(jìn)程掛掉的場景，提供鎖的 CAS 釋放操作，使得進(jìn)程可以零等待進(jìn)行搶鎖。比如利用在鎖節(jié)點中存放進(jìn)程的唯一標(biāo)識，強制釋放已經(jīng)不再使用的鎖，并重新爭搶，該方式可以徹底避免進(jìn)程升級或意外重啟后搶鎖需要的等待時間。

四 結(jié)語

分布式鎖提供了分布式環(huán)境下共享資源的互斥訪問，業(yè)務(wù)或者依賴分布式鎖追求效率提升，或者依賴分布式鎖追求訪問的絕對互斥。同時，在接入分布式鎖服務(wù)過程中，要考慮接入成本、服務(wù)可靠性、分布式鎖切換精度以及正確性等問題，正確和合理的使用分布式鎖，是需要持續(xù)思考并予以優(yōu)化的。

參考文章

How to do distributed locking - Martin KleppmannIs Redlock safe? - antirezchubby 論文 - google