[[185599]]

一、分布式鎖介紹

1.1 何謂“鎖”?

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

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

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

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

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

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

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

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

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

1.3 分布式鎖以及DLM介紹

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

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

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

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

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

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

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

2.1 Tooz為何而生?

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

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

2.2 Tooz

Tooz是一個(gè)python庫(kù)，提供了標(biāo)準(zhǔn)的coordination API。最初由eNovance幾個(gè)工程師編寫(xiě)，其主要目標(biāo)是解決分布式系統(tǒng)的通用問(wèn)題，比如節(jié)點(diǎn)管理、主節(jié)點(diǎn)選舉以及分布式鎖等，更多Tooz背景可參考Distributed group management and locking in Python with tooz。Tooz抽象了高級(jí)接口，支持對(duì)接十多種DLM驅(qū)動(dòng)，比如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.使用鎖

官方給出了一個(gè)非常簡(jiǎn)單的實(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開(kāi)發(fā)者發(fā)起的，因此tooz***在Ceilometer中使用，主要用在alarm-evaluator服務(wù)。目前Cinder也正在使用該庫(kù)來(lái)實(shí)現(xiàn)cinder-volume的Active/Active高可用，將在下文重點(diǎn)介紹。

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

3.1 Cinder之傷

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

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

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

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

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

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

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

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

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

Cinder對(duì)Tooz又封裝了一個(gè)單獨(dú)的coordination模塊，其源碼位于cinder/coordination.py，需要使用同步鎖時(shí)，只需要在函數(shù)名前面加上@coordination.synchronized裝飾器即可(有沒(méi)有突然想到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ī)置于一個(gè)cluster中，只有在同一個(gè)cluster的主機(jī)存在鎖競(jìng)爭(zhēng)，不同cluster的主機(jī)不存在鎖競(jìng)爭(zhēng)。

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

四、總結(jié)

本文首先介紹了分布式鎖的概念，詳細(xì)介紹了分布式鎖多種實(shí)現(xiàn)方式以及它們的優(yōu)缺點(diǎn)。然后介紹了OpenStack Tooz項(xiàng)目，該項(xiàng)目實(shí)現(xiàn)了分布式鎖的通用框架，支持對(duì)接不同的DLM。***介紹了Openstack Cinder實(shí)現(xiàn)高可用的痛點(diǎn)問(wèn)題以及討論了社區(qū)當(dāng)前正如何使用分布式鎖來(lái)實(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)載請(qǐng)通過(guò)51CTO獲得聯(lián)系】

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