簡介：?阿里云存儲提供了完整的分布式鎖解決方案，經過了阿里云眾多云產品寶貴的業務場景中長期錘煉，穩定高可靠，且提供了多種語言的SDK選擇，甚至是RESTful集成方案。

1 背景

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

圖1 鎖

2 從單機鎖到分布式鎖

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

圖2 單機鎖到分布式鎖

由此抽象一下分布式鎖的概念，首先分布式鎖需要是一個資源，這個資源能夠提供并發控制，并輸出一個排他性的狀態，也就是：?
鎖 = 資源 + 并發控制 + 所有權展示?
以常見的單機鎖為例：?
Spinlock = BOOL + CAS （樂觀鎖）?
Mutex = BOOL + CAS + 通知 （悲觀鎖）?
Spinlock和Mutex都是一個Bool資源，通過原子的CAS指令：當現在為0設置為1，成功的話持有鎖，失敗的話不持有鎖，如果不提供所有權的展示，例如AtomicInteger，也是通過資源（Interger）+CAS，但是不會明確的提示所有權，因此不會被視為一種鎖，當然，可以將“所有權展示”這個更多地視為某種服務提供形式的包裝。?
單機環境下，內核具備“上帝視角”，能夠知道進程的存活，當進程掛掉的時候可以將該進程持有的鎖資源釋放，但發展到分布式環境，這就變成了一個挑戰，為了應對各種機器故障、宕機等，就需要給鎖提供了一個新的特性：可用性。?
如下圖所示，任何提供三個特性的服務都可以提供分布式鎖的能力，資源可以是文件、KV等，通過創建文件、KV等原子操作，通過創建成功的結果來表明所有權的歸屬，同時通過TTL或者會話來保證鎖的可用性。

圖3 分布式鎖的特性和實現

3 分布式鎖的系統分類

根據鎖資源本身的安全性，我們將分布式鎖分為兩個陣營：?
A：基于異步復制的分布式系統，例如mysql，tair，redis等；?
B：基于paxos協議的分布式一致性系統，例如zookeeper，etcd，consul等；?
基于異步復制的分布式系統，存在數據丟失（丟鎖）的風險，不夠安全，往往通過TTL的機制承擔細粒度的鎖服務，該系統接入簡單，適用于對時間很敏感，期望設置一個較短的有效期，執行短期任務，丟鎖對業務影響相對可控的服務。
基于paxos協議的分布式系統，通過一致性協議保證數據的多副本，數據安全性高，往往通過租約（會話）的機制承擔粗粒度的鎖服務，該系統需要一定的門檻，適用于對安全性很敏感，希望長期持有鎖，不期望發生丟鎖現象的服務。

4 阿里云存儲分布式鎖

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

4.1 嚴格互斥性?
互斥性作為分布式鎖最基本的要求，對用戶而言就是不能出現“一鎖多占”，那么存儲分布式鎖是如何避免該情況的呢？
答案是，服務端每把鎖都和唯一的會話綁定，客戶端通過定期發送心跳來保證會話的有效性，也就保證了鎖的擁有權。當心跳不能維持時，會話連同關聯的鎖節點都會被釋放，鎖節點就可以被重新搶占。這里有一個關鍵的地方，就是如何保證客戶端和服務端的同步，在服務端會話過期的時候，客戶端也能感知，如下圖所示，在客戶端和服務端都維護了會話的有效期的時間，客戶端從心跳發送時刻（S0）開始計時，服務端從收到請求（S1）開始計時，這樣就能保證客戶端會先于服務端過期。 用戶在創建鎖之后，核心工作線程在進行核心操作之前可以判斷是否有足夠的有效期，同時我們不再依賴墻上時間，而是基于系統時鐘來對時間進行判斷，系統時鐘更加精確，且不會向前或者向后移動（秒級別誤差毫秒級，同時在NTP跳變的場景，最多會修改時鐘的速率）。

圖4 存儲場景的使用方式

在分布式鎖互斥性上，我們是不是做到完美了？并非如此，還是存在一種情況下業務基于分布式鎖服務的訪問互斥會被破壞。我們來看下面的例子：如下圖9所示，客戶端在時間點S0嘗試去搶鎖，在時間點S1在后端搶鎖成功，因此也產生了一個分布式鎖的有效期窗口。在有效期內，時間點S2做了一個訪問存儲的操作，很快完成，然后在時間點S3判斷鎖的有效期依舊成立，繼續執行訪問存儲操作，結果這個操作耗時良久，超過了分布式鎖的過期時間，那么可能這個時候，分布式鎖已經被其他客戶端搶占成功，進而出現兩個客戶端同時操作同一批數據的可能性，這種可能性是存在的，雖然概率很小。

圖6 越界場景

針對這個場景，具體的應對方案是在操作數據的時候確保有足夠的鎖有效期窗口，當然如果業務本身提供回滾機制的話，那么方案就更加完備，該方案也在存儲產品使用分布式鎖的過程中被采用。
還有一個更佳的方案，即，存儲系統本身引入IO Fence能力。這里就不得不提Martin Kleppmann和redis的作者antirez之間的討論了，redis為了防止異步復制導致的鎖丟失的問題，引入redlock，該方案引入了多數派的機制，需要獲得多數派的鎖，最大程度的保證了可用性和正確性，但仍然有兩個問題：
? 墻上時間的不可靠（NTP時間）
? 異構系統的無法做到嚴格正確性
墻上時間可以通過非墻上時間MonoticTime來解決（redis目前仍然依賴墻上時間），但是異構系統的只有一個系統并沒有辦法保證完全正確，如下圖10所示，Client1獲取了鎖，在操作數據的時候發生了GC，在GC完成時候丟失了鎖的所有權，造成了數據不一致。

圖7 異構系統無法做到完全正確性

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

圖8 引入IO Fence能力

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

4.2 可用性
存儲分布式鎖通過持續心跳來保證鎖的健壯性，讓用戶不用投入很多精力關注可用性，但也有可能異常的用戶進程持續占據鎖。針對該場景，為了保證鎖最終可以被調度，提供了可以安全釋放鎖的會話加黑機制。
當用戶需要將發生假死的進程持有的鎖釋放時，可以通過查詢會話信息，并將會話加黑，此后，心跳將不能正常維護，最終導致會話過期，鎖節點被安全釋放。這里我們不是強制刪除鎖，而是選用禁用心跳的原因如下:

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

4.3 切換效率?
當進程持有的鎖需要被重新調度時，持有者可以主動刪除鎖節點，但當持有者發生異常(如進程重啟，機器宕機等)，新的進程要重新搶占，就需要等待原先的會話過期后，才有機會搶占成功。默認情況下，分布式鎖使用的會話生命期為數十秒，當持有鎖的進程意外退出后(未主動釋放鎖)，最長需要經過很長時間鎖節點才可以被再次搶占。

圖5 客戶端和服務各自維護過期時間

要提升切換精度，本質上要壓縮會話生命周期，同時也意味著更快的心跳頻率，對后端更大的訪問壓力。我們通過對進行優化，使得會話周期可以進一步壓縮。?
同時結合具體的業務場景，例如守護進程發現鎖持有進程掛掉的場景，提供鎖的CAS釋放操作，使得進程可以零等待進行搶鎖。比如利用在鎖節點中存放進程的唯一標識，強制釋放已經不再使用的鎖，并重新爭搶，該方式可以徹底避免進程升級或意外重啟后搶鎖需要的等待時間。

5 結語

阿里云存儲提供了完整的分布式鎖解決方案，經過了阿里云眾多云產品寶貴的業務場景中長期錘煉，穩定高可靠，且提供了多種語言的SDK選擇，甚至是RESTful集成方案。
分布式鎖提供了分布式環境下共享資源的互斥訪問，業務或者依賴分布式鎖追求效率提升，或者依賴分布式鎖追求訪問的絕對互斥。同時，在接入分布式鎖服務過程中，要考慮接入成本、服務可靠性、分布式鎖切換精度以及正確性等問題，正確和合理的使用分布式鎖，是需要持續思考并予以優化的。

?

原文鏈接
本文為阿里云原創內容，未經允許不得轉載。

總結

以上是生活随笔為你收集整理的分布式锁在存储系统中的技术实践的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。