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

1、分布式鎖服務(wù)Chubby12主要用于解決分布式一致性問(wèn)題 在一個(gè)分布式系統(tǒng)中，有一組的Process，它們需要確定一個(gè)Value。于是每個(gè)Process都提出了一個(gè)Value，一致性就是指只有其中的一個(gè)Value能夠被選中作為最后確定的值，并且當(dāng)這個(gè)值被選出來(lái)以后，所有的Process都需要被通知到粗粒度的分布式鎖服務(wù) Chubby是Google為解決分布式一致性問(wèn)題而設(shè)計(jì)的提供粗粒度鎖服務(wù)的 其他分布式系統(tǒng)可以使用它對(duì)共享資源的訪問(wèn)進(jìn)行同步試圖由以下三點(diǎn)來(lái)保證數(shù)據(jù)的一致性:（1）決議只有被proposers提出后才能批準(zhǔn)（2）每次只批準(zhǔn)一個(gè)決議（3）只有決議確定被批準(zhǔn)后learners才能獲

2、取這個(gè)決議決議通過(guò)的兩個(gè)階段：決議通過(guò)的兩個(gè)階段：準(zhǔn)備階段：準(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)階段：批準(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)求解決一致性問(wèn)題算法：為了減少?zèng)Q議發(fā)

3、布過(guò)程中的消息量，acceptors將這個(gè)通過(guò)的決議發(fā)送給learners的一個(gè)子集，然后由這個(gè)子集中的learners去通知所有其他的learners；特殊情況：如果兩個(gè)proposer在這種情況下都轉(zhuǎn)而提出一個(gè)編號(hào)更大的提案，那么就可能陷入活鎖。此時(shí)需要選舉出一個(gè)president，僅允許 president提出提案Chubby中還添加了一些新的功能特性；這種設(shè)計(jì)主要是考慮到以下幾個(gè)問(wèn)題:1、開(kāi)發(fā)者初期很少考慮系統(tǒng)的一致性，但隨著開(kāi)發(fā)進(jìn)行，問(wèn)題會(huì)變得越來(lái)越嚴(yán)重。單獨(dú)的鎖服務(wù)可以保證原有系統(tǒng)單獨(dú)的鎖服務(wù)可以保證原有系統(tǒng)架構(gòu)架構(gòu)不會(huì)不會(huì)發(fā)生改變發(fā)生改變，而使用函數(shù)庫(kù)很可能需要對(duì)系統(tǒng)架構(gòu)做出大幅

4、度的改動(dòng)2 2、系統(tǒng)中很多事件發(fā)生是需要告知其他用戶(hù)和服務(wù)器，使用一個(gè)基于文件系統(tǒng)的鎖服務(wù)可以將這些變動(dòng)寫(xiě)入文件中可以將這些變動(dòng)寫(xiě)入文件中。有需要的用戶(hù)和服務(wù)器直接訪問(wèn)這些文件即可，避免因大量系統(tǒng)組件之間事件通信帶來(lái)系統(tǒng)性能下降3 3、基于鎖的開(kāi)發(fā)接口容易被開(kāi)發(fā)者接受。雖然在分布式系統(tǒng)中鎖的使用會(huì)有很大的不同，但是和一致性算法相比，鎖顯然被更多的開(kāi)發(fā)者所熟知Paxos算法實(shí)現(xiàn)過(guò)程中需要一個(gè)“多數(shù)派”就某個(gè)值達(dá)成一致，本質(zhì)上就是分布式系統(tǒng)中常見(jiàn)的quorum機(jī)制；為保證系統(tǒng)高可用性，需要若干臺(tái)機(jī)器，但使用單獨(dú)鎖服務(wù)的話(huà)一臺(tái)機(jī)器也能保證這種高可用性Chubby設(shè)計(jì)過(guò)程中一些細(xì)節(jié)問(wèn)題值得關(guān)注：在Ch

5、ubby系統(tǒng)中采用了建議性的鎖而沒(méi)有采用強(qiáng)制性的鎖。兩者的根本區(qū)別在于用戶(hù)訪問(wèn)某個(gè)被鎖定的文件時(shí)，建議性的鎖不會(huì)阻止訪問(wèn)，而強(qiáng)制性的鎖則會(huì)阻止訪問(wèn)，實(shí)際上這是為了方便系統(tǒng)組件之間的信息交互另外，Chubby還采用了粗粒度（Coarse-Grained）鎖服務(wù)而沒(méi)有采用細(xì)粒度（Fine-Grained）鎖服務(wù)，兩者的差異在于持有鎖的時(shí)間，細(xì)粒度的鎖持有時(shí)間很短Chubby系統(tǒng)本質(zhì)上就是一個(gè)分布式的、存儲(chǔ)大量小文件的文件系統(tǒng)，它所有的操作都是在文件的基礎(chǔ)上完成Chubby最常用的鎖服務(wù)中，每一個(gè)文件就代表一個(gè)鎖，用戶(hù)通過(guò)打開(kāi)、關(guān)閉和讀取文件，獲取共享（Shared）鎖或獨(dú)占（Exclusive）鎖

6、選舉主服務(wù)器過(guò)程中，符合條件的服務(wù)器都同時(shí)申請(qǐng)打開(kāi)某個(gè)文件并請(qǐng)求鎖住該文件成功獲得鎖的服務(wù)器自動(dòng)成為主服務(wù)器并將其地址寫(xiě)入這個(gè)文件夾，以便其他服務(wù)器和用戶(hù)可以獲知主服務(wù)器的地址信息每個(gè)Chubby單元是由五個(gè)副本組成的，這五個(gè)副本中需要選舉產(chǎn)生一個(gè)主服務(wù)器，這種選舉本質(zhì)上就是一個(gè)一致性問(wèn)題。實(shí)際執(zhí)行過(guò)程中，Chubby使用Paxos算法來(lái)解決 主服務(wù)器產(chǎn)生后客戶(hù)端的所有讀寫(xiě)操作都是由主服務(wù)器來(lái)完成的a讀操作很簡(jiǎn)單，客戶(hù)直接從主服務(wù)器上讀取所需數(shù)據(jù)即可a寫(xiě)操作就會(huì)涉及數(shù)據(jù)一致性的問(wèn)題；為了保證客戶(hù)的寫(xiě)操作能夠同步到所有的服務(wù)器上，系統(tǒng)再次利用了Paxos算法需要實(shí)現(xiàn)的特性 高可用性 高可靠性 支持粗粒度的建議性鎖服務(wù) 支持小規(guī)模文件直接存儲(chǔ)不作考慮的特性 高性能 存儲(chǔ)能力1819文件系統(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í)就