[[185599]]

一、分布式鎖介紹

1.1 何謂“鎖”?

鎖(Lock)，在我們生活當(dāng)中再熟悉不過了，它的主要作用就是鎖住某個物體或者某個區(qū)域空間，一方面阻止無鎖者進(jìn)入查看受隱私保護(hù)的東西，二來阻止惡意者實(shí)施破壞。比如我們都會對手機(jī)加鎖來防止別人偷窺自己的隱私，我們通過鎖門來阻止壞人進(jìn)入家里偷竊等等。

在計(jì)算機(jī)的世界，鎖同樣重要，并且功能和我們生活當(dāng)中的鎖基本是一樣的，只是管理的對象不一樣而已。計(jì)算機(jī)的鎖是為了鎖住某個計(jì)算機(jī)資源或者數(shù)據(jù)，不允許其它用戶或者進(jìn)程隨意訪問讀取，或者保護(hù)數(shù)據(jù)不被其它程序惡意篡改。除此之外，鎖還具有同步的功能，即保證A任務(wù)完成之后才能執(zhí)行B任務(wù)，而不能順序顛倒，也不能在A完成到一半時，B就開始執(zhí)行。

我們的服務(wù)器幾乎都是使用多用戶分時操作系統(tǒng)，意味著同一時間有多個用戶執(zhí)行多個進(jìn)程并且同時運(yùn)行著，即使是同一進(jìn)程，也有可能包含有多個線程跑著。如果我們不對一些互斥訪問的資源進(jìn)行加鎖，勢必會亂套，試想下同時多個程序不加控制的使用同一臺打印機(jī)會造成什么惡果。除了資源，對數(shù)據(jù)的加鎖保護(hù)也同樣重要，如果沒有鎖，數(shù)據(jù)就會各種紊亂，比如你的記賬管理系統(tǒng)，開始總額有5000元，入賬5000元，此時總額應(yīng)該就有10000元了，但還沒有來得及更新到數(shù)據(jù)庫中去，此時，你的另一個進(jìn)程開始讀取總額，由于之前入賬的5000塊還沒有更新，取出來的總額還是原來的5000元，顯然讀取的這5000元是過時的老數(shù)據(jù)，在操作系統(tǒng)術(shù)語中稱為臟數(shù)據(jù)。更詭秘的是，此時你的第二個進(jìn)程開始出賬3000塊，此時開始寫入剩余總額2000元。此時你的兩個進(jìn)程可能同時在寫數(shù)據(jù)，假設(shè)你的進(jìn)程一先寫完(寫入10000)，你的第二個進(jìn)程寫入2000元覆蓋掉了剛剛寫入的10000元，***你的總額為2000元，你剛剛?cè)胭~的5000元莫名其妙地蒸發(fā)了。以上情況就是事務(wù)處理中ACID的數(shù)據(jù)不一致性問題。

閱讀本文讀者只需要知道鎖的作用即可，更多關(guān)于并發(fā)控制的有關(guān)概念(比如幻讀、不可重復(fù)讀、原子性、持久性等)以及各種鎖的概念(互斥鎖、共享鎖、樂觀鎖、悲觀鎖、死鎖等)不是本文討論的重點(diǎn)，感興趣的讀者請自行Google之。

1.2 鎖的實(shí)現(xiàn)非權(quán)威解讀

生活當(dāng)中的鎖原理其實(shí)很簡單，傳統(tǒng)的機(jī)械鎖可以當(dāng)作是一種機(jī)關(guān)，通過匹配形狀齒輪觸發(fā)機(jī)關(guān)某個部位而解鎖。而現(xiàn)代的鎖原理更簡單，加鎖其實(shí)就是設(shè)置一種狀態(tài)，而要解除該狀態(tài)只需要比對信息，比如數(shù)字密碼、指紋等。

計(jì)算機(jī)中的鎖，根據(jù)運(yùn)行環(huán)境可以大體分為以下三類：

• 同一個進(jìn)程。此時主要管理該進(jìn)程的多個線程間同步以及控制并發(fā)訪問共享資源。由于進(jìn)程是共享內(nèi)存空間的，一個最簡單的實(shí)現(xiàn)方式就是使用一個整型變量作為flag，這個flag被所有線程所共享，其值為1表示已上鎖，為0表示空閑。使用該方法的前提是設(shè)置(set)和獲取(get)這個flag變量的值都必須是原子操作，即要么成功，要么失敗，并且中間不允許有中斷，也不允許出現(xiàn)中間狀態(tài)。可幸的是，目前幾乎所有的操作系統(tǒng)都提供了此類原子操作，并已經(jīng)引入了鎖機(jī)制，所以以上前提是可以滿足的。
• 同一個主機(jī)。此時需要控制在同一個操作系統(tǒng)下運(yùn)行的多個進(jìn)程間如何協(xié)調(diào)訪問共享資源。不同的進(jìn)程由于不共享內(nèi)存空間，因此不能通過設(shè)置變量來實(shí)現(xiàn)。既然內(nèi)存不能共享，那磁盤是共享的，因此我們自然想到可以通過創(chuàng)建一個文件作為鎖標(biāo)記。進(jìn)程只需要檢查文件是否存在來判斷是否有鎖。
• 不同主機(jī)。此時通常跑的都是分布式應(yīng)用，如何保證不同主機(jī)的進(jìn)程同步和避免資源訪問沖突。有了前面的例子，相信很多人都想到了，使用共享存儲不就可以了，這樣不同主機(jī)的進(jìn)程也可以通過檢測文件是否存在來判斷是否有鎖了。

以上介紹了鎖的非權(quán)威實(shí)現(xiàn)，為了解釋得更簡單通俗，其實(shí)隱瞞了很多真正實(shí)現(xiàn)上的細(xì)節(jié)，甚至可能和實(shí)際的實(shí)現(xiàn)方式并不一致。要想真正深入理解操作系統(tǒng)的鎖機(jī)制以及單主機(jī)的鎖機(jī)制實(shí)現(xiàn)原理，請查閱更多的文獻(xiàn)。本文接下來將重點(diǎn)討論分布式鎖，也就是前面提到的不同主機(jī)的進(jìn)程間如何實(shí)現(xiàn)同步以及控制并發(fā)訪問資源。

1.3 分布式鎖以及DLM介紹

毫無疑問，分布式鎖主要解決的是分布式資源訪問沖突的問題，保證數(shù)據(jù)的一致性。前面提到使用共享存儲文件作為鎖標(biāo)記，這種方案只有理論意義，實(shí)際上幾乎沒有人這么用,因?yàn)閯?chuàng)建文件并不能保證是原子操作。另一種可行方案是使用傳統(tǒng)數(shù)據(jù)庫存儲鎖狀態(tài)，實(shí)現(xiàn)方式也很簡單，檢測鎖時只需要從數(shù)據(jù)庫中查詢鎖狀態(tài)即可。當(dāng)然，可能使用傳統(tǒng)的關(guān)系型數(shù)據(jù)庫性能不太好，因此考慮使用KV-Store緩存數(shù)據(jù)庫，比如redis、memcached等。但都存在問題：

• 不支持堵塞鎖。即進(jìn)程獲取鎖時，不會自己等待鎖，只能通過不斷輪詢的方式判斷鎖的狀態(tài)，性能不好，并且不能保證實(shí)時性。
• 不支持可重入。所謂可重入鎖就是指當(dāng)一個進(jìn)程獲取了鎖時，在釋放鎖之前能夠***次重復(fù)獲取該鎖。試想下，如果鎖是不可重入的，一個進(jìn)程獲取鎖后，運(yùn)行過程中若再次獲取鎖時，就會不斷循環(huán)獲取鎖，可實(shí)際上鎖就在自己的手里，因此將***進(jìn)入死鎖狀態(tài)。當(dāng)然也不是沒法實(shí)現(xiàn)，你可以順便存儲下主機(jī)和進(jìn)程ID，如果是相同的主機(jī)和進(jìn)程獲取鎖時則自動通過，還需要保存鎖的使用計(jì)數(shù)，當(dāng)釋放鎖時，簡單的計(jì)數(shù)-1，只有值為0時才真正釋放鎖。

另外，鎖需要支持設(shè)置最長持有時間。想象下，如果一個進(jìn)程獲取了鎖后突然掛了，如果沒有設(shè)置最長持有時間，鎖就永遠(yuǎn)得不到釋放，成為了該進(jìn)程的陪葬品，其它進(jìn)程將永遠(yuǎn)獲取不了鎖而陷入***堵塞狀態(tài)，整個系統(tǒng)將癱瘓。使用傳統(tǒng)關(guān)系型數(shù)據(jù)庫可以保存時間戳，設(shè)置失效時間，實(shí)現(xiàn)相對較復(fù)雜。而使用緩存數(shù)據(jù)庫時，通常這類數(shù)據(jù)庫都可以設(shè)置數(shù)據(jù)的有效時間，因此相對容易實(shí)現(xiàn)。不過需要注意不是所有的場景都適合通過鎖搶占方式恢復(fù)，有些時候事務(wù)執(zhí)行一半掛了，也不能隨意被其它進(jìn)程強(qiáng)制介入。

支持可重入和設(shè)置鎖的有效時間其實(shí)都是有方法實(shí)現(xiàn)，但要支持堵塞鎖，則依賴于鎖狀態(tài)的觀察機(jī)制，如果鎖的狀態(tài)一旦變化就能立即通知調(diào)用者并執(zhí)行回調(diào)函數(shù)，則實(shí)現(xiàn)堵塞鎖就很簡單了。慶幸的是，分布式協(xié)調(diào)服務(wù)就支持該功能，Google的Chubby就是非常經(jīng)典的例子，Zookeeper是Chubby的開源實(shí)現(xiàn)，類似的還有后起之秀etcd等。這些協(xié)調(diào)服務(wù)有些類似于KV-Store，也提供get、set接口，但也更類似于一個分布式文件系統(tǒng)。以Zookeeper為例，它通過瞬時有序節(jié)點(diǎn)標(biāo)識鎖狀態(tài)，請求鎖時會在指定目錄創(chuàng)建一個瞬時節(jié)點(diǎn)，節(jié)點(diǎn)是有序的，Zookeeper會把鎖分配給節(jié)點(diǎn)最小的服務(wù)。Zookeeper支持watcher機(jī)制，一旦節(jié)點(diǎn)變化，比如節(jié)點(diǎn)刪除(釋放鎖)，Zookeeper會通知客戶端去重新競爭鎖，從而實(shí)現(xiàn)了堵塞鎖。另外，Zookeeper支持臨時節(jié)點(diǎn)的概念，在客戶進(jìn)程掛掉后，臨時節(jié)點(diǎn)會自動被刪除，這樣可實(shí)現(xiàn)鎖的異常釋放，不需要給鎖增加超時功能了。

以上提供鎖服務(wù)的應(yīng)用我們通常稱為DLM(Distributed lock manager)，對比以上提到的三種類型的DLM:

注: 以上支持度僅考慮最簡單實(shí)現(xiàn)，不涉及高級實(shí)現(xiàn)，比如傳統(tǒng)數(shù)據(jù)庫以及緩存數(shù)據(jù)庫也是可以實(shí)現(xiàn)可重入的，只是需要花費(fèi)更多的工作量。

二、OpenStack Tooz項(xiàng)目介紹

2.1 Tooz為何而生?

前面介紹了很多實(shí)現(xiàn)分布式鎖的方式，但也只是提供了實(shí)現(xiàn)的可能和思路，而并未達(dá)到拿來即用的地步。開發(fā)者仍然需要花費(fèi)大量的時間完成對分布式鎖的封裝實(shí)現(xiàn)。使用不同的后端，可能還有不同的實(shí)現(xiàn)方式。如果每次都需要重復(fù)造輪子，將浪費(fèi)大量的時間，并且質(zhì)量難以保證。

你一定會想，會不會有人已經(jīng)封裝了一套鎖管理的庫或者框架，只需要簡單調(diào)用lock、trylock、unlock即可，不用關(guān)心底層內(nèi)部實(shí)現(xiàn)細(xì)節(jié)，也不用了解后端到底使用的是Zookeeper、Redis還是Etcd。curator庫實(shí)現(xiàn)了基于Zookeeper的分布式鎖，但不夠靈活，不能選擇使用其它的DLM。OpenStack社區(qū)為了解決項(xiàng)目中的分布式問題，開發(fā)了一個非常靈活的通用框架，項(xiàng)目名為Tooz，它實(shí)現(xiàn)了非常易用的分布式鎖接口，本文接下來將詳細(xì)介紹該項(xiàng)目。

2.2 Tooz

Tooz是一個python庫，提供了標(biāo)準(zhǔn)的coordination API。最初由eNovance幾個工程師編寫，其主要目標(biāo)是解決分布式系統(tǒng)的通用問題，比如節(jié)點(diǎn)管理、主節(jié)點(diǎn)選舉以及分布式鎖等，更多Tooz背景可參考Distributed group management and locking in Python with tooz。Tooz抽象了高級接口，支持對接十多種DLM驅(qū)動，比如Zookeeper、Redis、Mysql、Etcd、Consul等，其官方描述為:

• The Tooz project aims at centralizing the most common distributed primitives like group membership protocol, lock service and leader ?election by providing a coordination API helping developers to build distributed applications.

使用Tooz也非常方便，只需要三步：

1.與后端DLM建立連接，獲取coordination實(shí)例。

2.聲明鎖名稱，創(chuàng)建鎖實(shí)例

3.使用鎖

官方給出了一個非常簡單的實(shí)例，如下：

from tooz import coordination 
coordinator = coordination.get_coordinator('zake://', b'host-1') 
coordinator.start()  
# Create a lock 
lock = coordinator.get_lock("foobar") 
with lock: 
    ... 
    print("Do something that is distributed")  
coordinator.stop() 

由于該項(xiàng)目***是由Ceilometer項(xiàng)目core開發(fā)者發(fā)起的，因此tooz***在Ceilometer中使用，主要用在alarm-evaluator服務(wù)。目前Cinder也正在使用該庫來實(shí)現(xiàn)cinder-volume的Active/Active高可用，將在下文重點(diǎn)介紹。

三、分布式鎖在Cinder中的應(yīng)用

3.1 Cinder之傷

Cinder是OpenStack的核心組件之一，為云主機(jī)提供可擴(kuò)展可伸縮的塊存儲服務(wù)，用于管理volume數(shù)據(jù)卷資源，類似于AWS的EBS服務(wù)。cinder-volume服務(wù)是Cinder最關(guān)鍵的服務(wù)，負(fù)責(zé)對接后端存儲驅(qū)動，管理volume數(shù)據(jù)卷生命周期，它是真正干活的服務(wù)。

顯然volume數(shù)據(jù)卷資源也需要處理并發(fā)訪問的沖突問題，比如防止刪除一個volume時，另一個線程正在基于該volume創(chuàng)建快照，或者同時有兩個線程同時執(zhí)行掛載操作等。cinder-volume也是使用鎖機(jī)制實(shí)現(xiàn)資源的并發(fā)訪問，volume的刪除、掛載、卸載等操作都會對volume加鎖。在OpenStack Newton版本以前，Cinder的鎖實(shí)現(xiàn)都是基于本地文件實(shí)現(xiàn)的，該方法在前面已經(jīng)介紹過，只不過并不是根據(jù)文件是否存在來判斷鎖狀態(tài)，而是使用了Linux的flock工具進(jìn)行鎖管理。Cinder執(zhí)行加鎖操作默認(rèn)會從配置指定的lockpath目錄下創(chuàng)建一個命名為cinder-volume_uuid-{action}的空文件，并對該文件使用flock加鎖。flock只能作用于同一個操作系統(tǒng)的文件鎖，即使使用共享存儲，另一個操作系統(tǒng)也不能判斷是否有鎖，一句話說就是Cinder使用的是本地鎖。

我們知道OpenStack的大多數(shù)無狀態(tài)服務(wù)都可以通過在不同的主機(jī)同時運(yùn)行多個實(shí)例來保證高可用，即使其中一個服務(wù)掛了，只要還存在運(yùn)行的實(shí)例就能保證整個服務(wù)是可用的，比如nova-api、nova-scheduler、nova-conductor等都是采用這種方式實(shí)現(xiàn)高可用，該方式還能實(shí)現(xiàn)服務(wù)的負(fù)載均衡，增加服務(wù)的并發(fā)請求能力。而極為不幸的是，由于Cinder使用的是本地鎖，導(dǎo)致cinder-volume服務(wù)長期以來只能支持Active/Passive(主備)HA模式，而不支持Active/Active(AA，主主)多活，即對于同一個backend，只能同時起一個cinder-volume實(shí)例，不能跨主機(jī)運(yùn)行多個實(shí)例，這顯然存在嚴(yán)重的單點(diǎn)故障問題，該問題一直以來成為實(shí)現(xiàn)Cinder服務(wù)高可用的痛點(diǎn)。

因?yàn)閏inder-volume不支持多實(shí)例，為了避免該服務(wù)掛了導(dǎo)致Cinder服務(wù)不可用，需要引入自動恢復(fù)機(jī)制，通常會使用pacemaker來管理，pacemaker輪詢判斷cinder-volume的存活狀態(tài)，一旦發(fā)現(xiàn)掛了，pacemaker會嘗試重啟服務(wù)，如果依然重啟失敗，則嘗試在另一臺主機(jī)啟動該服務(wù)，實(shí)現(xiàn)故障的自動恢復(fù)。該方法大多數(shù)情況都是有效的，但依然存在諸多問題：

• 在輪詢服務(wù)狀態(tài)間隔內(nèi)掛了，服務(wù)會不可用。即不能保證服務(wù)的連續(xù)性和服務(wù)狀態(tài)的實(shí)時性。
• 有時cinder-volume服務(wù)啟動和停止都比較慢，導(dǎo)致服務(wù)恢復(fù)時間較長，甚至出現(xiàn)超時錯誤。
• 不支持負(fù)載均衡，極大地限制了服務(wù)的請求量。
• 有時運(yùn)維不當(dāng)或者pacemaker自身問題，可能出現(xiàn)同時起了兩個cinder-volume服務(wù)，出現(xiàn)非常詭秘的問題，比如volume實(shí)例刪不掉等。

總而言之，cinder-volume不支持Active/Active HA模式是Cinder的一個重大缺陷。

3.2 Cinder的"進(jìn)化"

玩過三國殺的都知道，很多武將最開始都比較脆弱，經(jīng)過各種虐殺后會觸發(fā)覺醒技能，又如pokemon完成一次進(jìn)化，變得異常強(qiáng)大。cinder-volume不支持AA模式一直受人詬病，社區(qū)終于在Newton版本開始討論實(shí)現(xiàn)cinder-volume的AA高可用，準(zhǔn)備引入分布式鎖替代本地鎖，這可能意味著Cinder即將完成一次功能突發(fā)變強(qiáng)的重大進(jìn)化。

Cinder引入分布式鎖，需要用戶自己部署和維護(hù)一套DLM，比如Zookeeper、Etcd等服務(wù)，這無疑增加了運(yùn)維的成本，并且也不是所有的存儲后端都需要分布式鎖。社區(qū)為了滿足不同用戶、不同場景的需求，并沒有強(qiáng)制用戶部署固定的DLM，而是采取了非常靈活的可插除方式，使用的正是前面介紹Tooz庫。當(dāng)用戶不需要分布式鎖時，只需要指定后端為本地文件即可，此時不需要部署任何DLM，和引入分布式鎖之前的方式保持一致，基本不需要執(zhí)行大的變更。當(dāng)用戶需要cinder-volume支持AA時，可以選擇部署一種DLM，比如Zookeeper服務(wù)。

Cinder對Tooz又封裝了一個單獨(dú)的coordination模塊，其源碼位于cinder/coordination.py，需要使用同步鎖時，只需要在函數(shù)名前面加上@coordination.synchronized裝飾器即可(有沒有突然想到Java的synchronized關(guān)鍵字 )，方便易用，并且非常統(tǒng)一，而不像之前一樣，不同的函數(shù)需要加不同的加鎖裝飾器。比如刪除volume操作的使用形式為：

@coordination.synchronized('{volume.id}-{f_name}')  
@objects.Volume.set_workers  
def delete_volume(self, context, volume, unmanage_only=False,  
cascade=False):  
... 

后端的不同主機(jī)置于一個cluster中，只有在同一個cluster的主機(jī)存在鎖競爭，不同cluster的主機(jī)不存在鎖競爭。

不過截至到剛剛發(fā)布的Ocata版本，cinder-volume的AA模式還正處于開發(fā)過程中，其功能還沒有完全實(shí)現(xiàn)，還不能用于生產(chǎn)環(huán)境中部署。我們期待cinder-volume能夠盡快實(shí)現(xiàn)AA高可用功能，云極星創(chuàng)也會持續(xù)關(guān)注該功能的開發(fā)進(jìn)度，并加入社區(qū)，與更多開發(fā)者一起完善該功能的開發(fā)。

四、總結(jié)

本文首先介紹了分布式鎖的概念，詳細(xì)介紹了分布式鎖多種實(shí)現(xiàn)方式以及它們的優(yōu)缺點(diǎn)。然后介紹了OpenStack Tooz項(xiàng)目，該項(xiàng)目實(shí)現(xiàn)了分布式鎖的通用框架，支持對接不同的DLM。***介紹了Openstack Cinder實(shí)現(xiàn)高可用的痛點(diǎn)問題以及討論了社區(qū)當(dāng)前正如何使用分布式鎖來實(shí)現(xiàn)cinder-volume服務(wù)的AA高可用模式。

參考文獻(xiàn)

1.Building a Distributed Lock Revisited: Using Curator's InterProcessMutex.

2. Distributed lock manager.

3 .并發(fā)控制.

4 Ocata Series Release Notes.

5 Distributed group management and locking in Python with tooz.

6 Cinder Volume Active/Active support - Manager Local Locks.

7 etcd API: Waiting for a change.

8 The Chubby lock service for loosely-coupled distributed systems.

9 OpenStack中tooz介紹及實(shí)踐.

10 A Cinder Road to Active/Active HA.

【本文是51CTO專欄作者“付廣平”的原創(chuàng)文章，如需轉(zhuǎn)載請通過51CTO獲得聯(lián)系】

戳這里，看該作者更多好文