Google云計(jì)算原理-分布式鎖服務(wù)Chubby

Google的云計(jì)算分布式鎖服務(wù)Chubby1Chubby是什么？2主要用于解決分布式一致性問題在一個(gè)分布式系統(tǒng)中，有一組的Process，它們需要確定一個(gè)Value。于是每個(gè)Process都提出了一個(gè)Value，一致性就是指只有其中的一個(gè)Value能夠被選中作為最后確定的值，并且當(dāng)這個(gè)值被選出來以后，所有的Process都需要被通知到粗粒度的分布式鎖服務(wù)Chubby是Google為解決分布式一致性問題而設(shè)計(jì)的提供粗粒度鎖服務(wù)的文件系統(tǒng)其他分布式系統(tǒng)可以使用它對(duì)共享資源的訪問進(jìn)行同步1.Paxos算法該方案存的缺陷試圖由以下三點(diǎn)來保證數(shù)據(jù)的一致性:（1）決議只有被proposers提出后才能批準(zhǔn)（2）每次只批準(zhǔn)一個(gè)決議（3）只有決議確定被批準(zhǔn)后learners才能獲取這個(gè)決議決議通過的兩個(gè)階段：準(zhǔn)備階段：proposers選擇一個(gè)提案并將它的編號(hào)設(shè)為n，然后將它發(fā)送給acceptors中的一個(gè)“多數(shù)派”。Acceptors收到后，如果提案的編號(hào)大于它已經(jīng)回復(fù)的所有消息，則acceptors將自己上次的批準(zhǔn)回復(fù)給proposers，并不再批準(zhǔn)小于n的提案

批準(zhǔn)階段：當(dāng)proposers接收到acceptors中的這個(gè)“多數(shù)派”的回復(fù)后，就向回復(fù)請(qǐng)求的acceptors發(fā)送accept請(qǐng)求，在符合acceptors一方的約束條件下，acceptors收到accept請(qǐng)求后即批準(zhǔn)這個(gè)請(qǐng)求

解決一致性問題算法：為了減少?zèng)Q議發(fā)布過程中的消息量，acceptors將這個(gè)通過的決議發(fā)送給learners的一個(gè)子集，然后由這個(gè)子集中的learners去通知所有其他的learners；特殊情況：如果兩個(gè)proposer在這種情況下都轉(zhuǎn)而提出一個(gè)編號(hào)更大的提案，那么就可能陷入活鎖。此時(shí)需要選舉出一個(gè)president，僅允許president提出提案2.Chubby的系統(tǒng)設(shè)計(jì)Chubby中還添加了一些新的功能特性；這種設(shè)計(jì)主要是考慮到以下幾個(gè)問題:1、開發(fā)者初期很少考慮系統(tǒng)的一致性，但隨著開發(fā)進(jìn)行，問題會(huì)變得越來越嚴(yán)重。單獨(dú)的鎖服務(wù)可以保證原有系統(tǒng)架構(gòu)不會(huì)發(fā)生改變，而使用函數(shù)庫很可能需要對(duì)系統(tǒng)架構(gòu)做出大幅度的改動(dòng)2、系統(tǒng)中很多事件發(fā)生是需要告知其他用戶和服務(wù)器，使用一個(gè)基于文件系統(tǒng)的鎖服務(wù)可以將這些變動(dòng)寫入文件中。有需要的用戶和服務(wù)器直接訪問這些文件即可，避免因大量系統(tǒng)組件之間事件通信帶來系統(tǒng)性能下降3、基于鎖的開發(fā)接口容易被開發(fā)者接受。雖然在分布式系統(tǒng)中鎖的使用會(huì)有很大的不同，但是和一致性算法相比，鎖顯然被更多的開發(fā)者所熟知Paxos算法實(shí)現(xiàn)過程中需要一個(gè)“多數(shù)派”就某個(gè)值達(dá)成一致，本質(zhì)上就是分布式系統(tǒng)中常見的quorum機(jī)制；為保證系統(tǒng)高可用性，需要若干臺(tái)機(jī)器，但使用單獨(dú)鎖服務(wù)的話一臺(tái)機(jī)器也能保證這種高可用性Chubby設(shè)計(jì)過程中一些細(xì)節(jié)問題值得關(guān)注：在Chubby系統(tǒng)中采用了建議性的鎖而沒有采用強(qiáng)制性的鎖。兩者的根本區(qū)別在于用戶訪問某個(gè)被鎖定的文件時(shí)，建議性的鎖不會(huì)阻止訪問，而強(qiáng)制性的鎖則會(huì)阻止訪問，實(shí)際上這是為了方便系統(tǒng)組件之間的信息交互另外，Chubby還采用了粗粒度（Coarse-Grained）鎖服務(wù)而沒有采用細(xì)粒度（Fine-Grained）鎖服務(wù)，兩者的差異在于持有鎖的時(shí)間，細(xì)粒度的鎖持有時(shí)間很短Chubby的系統(tǒng)架構(gòu)3、Chubby中的Paxos算法Chubby系統(tǒng)本質(zhì)上就是一個(gè)分布式的、存儲(chǔ)大量小文件的文件系統(tǒng)，它所有的操作都是在文件的基礎(chǔ)上完成?Chubby最常用的鎖服務(wù)中，每一個(gè)文件就代表一個(gè)鎖，用戶通過打開、關(guān)閉和讀取文件，獲取共享（Shared）鎖或獨(dú)占（Exclusive）鎖?選舉主服務(wù)器過程中，符合條件的服務(wù)器都同時(shí)申請(qǐng)打開某個(gè)文件并請(qǐng)求鎖住該文件?成功獲得鎖的服務(wù)器自動(dòng)成為主服務(wù)器并將其地址寫入這個(gè)文件夾，以便其他服務(wù)器和用戶可以獲知主服務(wù)器的地址信息

4、Chubby文件系統(tǒng)5、通信協(xié)議?每個(gè)Chubby單元是由五個(gè)副本組成的，這五個(gè)副本中需要選舉產(chǎn)生一個(gè)主服務(wù)器，這種選舉本質(zhì)上就是一個(gè)一致性問題。實(shí)際執(zhí)行過程中，Chubby使用Paxos算法來解決

?主服務(wù)器產(chǎn)生后客戶端的所有讀寫操作都是由主服務(wù)器來完成的

a讀操作很簡(jiǎn)單，客戶直接從主服務(wù)器上讀取所需數(shù)據(jù)即可

a寫操作就會(huì)涉及數(shù)據(jù)一致性的問題；為了保證客戶的寫操作能夠同步到所有的服務(wù)器上，系統(tǒng)再次利用了Paxos算法6、正確性與性能一致性

需要實(shí)現(xiàn)的特性高可用性高可靠性支持粗粒度的建議性鎖服務(wù)支持小規(guī)模文件直接存儲(chǔ)不作考慮的特性高性能存儲(chǔ)能力Chubby的設(shè)計(jì)目標(biāo)18Chubby的系統(tǒng)架構(gòu)19文件系統(tǒng)中文件的權(quán)限文件系統(tǒng)中文件操作的權(quán)限有哪些？這些權(quán)限之間的互斥關(guān)系是怎樣的？Chubby系統(tǒng)本質(zhì)上就是一個(gè)分布式的、存儲(chǔ)大量小文件的文件系統(tǒng)Chubby中的鎖就是文件在GFS的例子中，創(chuàng)建文件就是進(jìn)行“加鎖”操作，創(chuàng)建文件成功的那個(gè)server其實(shí)就是搶占到了“鎖”用戶通過打開、關(guān)閉和存取文件，獲取共享鎖或者獨(dú)占鎖；并且通過通