Chubby分布式協(xié)調(diào)系統(tǒng)

MapReduce 很多人已經(jīng)知道了，但關(guān)于Chubyy似乎熟悉它的就非常有限，這倒是不奇怪，因?yàn)镸apReduce是一個(gè)針對(duì)開發(fā)人員的 ProgrammingModel，自然會(huì)有很多人去學(xué)習(xí)它，而Chubby更多的是一種為了實(shí)現(xiàn)MapReduce或者Bigtable而構(gòu)建的內(nèi)部的 工具，對(duì)于開發(fā)人員來說基本上是透明的。文獻(xiàn)[1]我反復(fù)讀了至少有兩三天，但感覺也只是一個(gè)囫圇吞棗的結(jié)果，里面有很多工程實(shí)現(xiàn)上的細(xì)節(jié)，如果不是自己 親自去設(shè)計(jì)或者實(shí)現(xiàn)，很難體會(huì)到其中的道理和奧妙。但是，對(duì)于這樣一個(gè)分布式service的研究，還是讓我對(duì)一個(gè)分布式系統(tǒng)的結(jié)構(gòu)和設(shè)計(jì)思想有了更加直 觀的感覺。

從distributed consensus problem說起

distributed consensus problem(分布的一致性問題)是分布式算法中的一個(gè)經(jīng)典問題。它的問題描述大概是這樣的：在一個(gè)分布式系統(tǒng)中，有一組的Process，它們需要確 定一個(gè)Value。于是每個(gè)Process都提出了一個(gè)Value，consensus就是指只有其中的一個(gè)Value能夠被選中作為最后確定的值，并且 當(dāng)這個(gè)值被選出來以后，所有的Process都需要被通知到。
表面上看，這個(gè)問題很容易解決。比如設(shè)置一個(gè)server，所有的process都 向這個(gè)server提交一個(gè)Value，這個(gè)server可以通過一個(gè)簡(jiǎn)單的規(guī)則來挑選出一個(gè)Value（例如最先到達(dá)的Value被選中），然后由這個(gè) server通知所有的Process。但是在分布式系統(tǒng)中，就會(huì)有各種的問題發(fā)生，例如，這個(gè)server崩潰了怎么辦，所以我們可能需要有幾臺(tái) server共同決定。還有，Process提交Value的時(shí)間都不一樣，網(wǎng)絡(luò)傳輸過程中由于延遲這些Value到達(dá)server的順序也都沒有保證。
為 了解決這個(gè)問題，有很多人提出了各種各樣的Protocol，這些Protocol可以看做是一組需要遵循的規(guī)則，按照這些規(guī)則，這些Process就能 夠選舉出一個(gè)唯一的Value。其中，最有名的一個(gè)Protocol就是Paxos算法。（八卦一下，Paxos的提出者叫做Lamport，有很多分布 式的算法都是他提出的，他還是Latex的作者，大牛啊...）。想更加了解Paxos算法可以參考文獻(xiàn)[2]，很漂亮的一篇文章。

那么 這些和Chubby有什么關(guān)系呢？其實(shí)Chubby就是為了這個(gè)問題而構(gòu)建出來的。只是它并不是一個(gè)Protocol或者是一個(gè)算法，而是google精 心設(shè)計(jì)的一個(gè)service。這個(gè)service不僅能夠解決一致性問題，還有其它的一些很實(shí)用的好處，會(huì)在下文慢慢介紹。

一個(gè)實(shí)例

在Google File System(GFS)中，有很多的server，這些server需要選舉其中的一臺(tái)作為master server。這其實(shí)是一個(gè)很典型的consensus問題，Value就是master server的地址。GFS就是用Chubby來解決的這個(gè)問題，所有的server通過Chubby提供的通信協(xié)議到Chubby server上創(chuàng)建同一個(gè)文件，當(dāng)然，最終只有一個(gè)server能夠獲準(zhǔn)創(chuàng)建這個(gè)文件，這個(gè)server就成為了master，它會(huì)在這個(gè)文件中寫入自己 的地址，這樣其它的server通過讀取這個(gè)文件就能知道被選出的master的地址。

Chubby是什么

從 上面的這個(gè)實(shí)例可以看出，Chubby首先是一個(gè)分布式的文件系統(tǒng)。Chubby能夠提供機(jī)制使得client可以在Chubby service上創(chuàng)建文件和執(zhí)行一些文件的基本操作。說它是分布式的文件系統(tǒng)，是因?yàn)橐粋€(gè)Chubby cell是一個(gè)分布式的系統(tǒng)，一般包含了5臺(tái)機(jī)器，整個(gè)文件系統(tǒng)是部署在這5臺(tái)機(jī)器上的。
但是，從更高一點(diǎn)的語義層面上，Chubby是一個(gè) lock service，一個(gè)針對(duì)松耦合的分布式系統(tǒng)的lock service。所謂lock service，就是這個(gè)service能夠提供開發(fā)人員經(jīng)常用的“鎖”，“解鎖”功能。通過Chubby，一個(gè)分布式系統(tǒng)中的上千個(gè)client都能夠 對(duì)于某項(xiàng)資源進(jìn)行“加鎖”，“解鎖”。
那么，Chubby是怎樣實(shí)現(xiàn)這樣的“鎖”功能的？就是通過文件。Chubby中的“鎖”就是文件，在上例 中，創(chuàng)建文件其實(shí)就是進(jìn)行“加鎖”操作，創(chuàng)建文件成功的那個(gè)server其實(shí)就是搶占到了“鎖”。用戶通過打開、關(guān)閉和讀取文件，獲取共享鎖或者獨(dú)占鎖； 并且通過通信機(jī)制，向用戶發(fā)送更新信息。

綜上所述，Chubby是一個(gè)lock service，通過這個(gè)lock service可以解決分布式中的一致性問題，而這個(gè)lock service的實(shí)現(xiàn)是一個(gè)分布式的文件系統(tǒng)。

可能會(huì)有人問，為什么不是直接實(shí)現(xiàn)一個(gè)類似于Paxos算法這樣的Protocol來解決一致性問題，而是要通過一個(gè)lock service來解決？文獻(xiàn)[1]中提到，用lock service這種方式有幾個(gè)好處：
1. 大部分開發(fā)人員在開始開發(fā)service的時(shí)候都不會(huì)考慮到這種一致性的問題，所以一開始都不會(huì)使用consensus protocol。只有當(dāng)service慢慢成熟以后，才開始認(rèn)真對(duì)待這個(gè)問題。采用lock service可以使得在保持原有的程序架構(gòu)和通信機(jī)制的情況下，通過添加簡(jiǎn)單的語句就可以解決一致性問題；
2. 正如上文實(shí)例中所展現(xiàn)，很多時(shí)候并不僅僅是選舉出一個(gè)master，還需要將這個(gè)master的地址告訴其它人或者保存某個(gè)信息，這種時(shí)候，使用 Chubby中的文件，不僅僅是提供鎖功能，還能在文件中記錄下有用的信息（比如master的地址）。所以，很多的開發(fā)人員通過使用Chubby來保存 metadata和configuration。
3. 一個(gè)基于鎖的開發(fā)接口更容易被開發(fā)人員所熟悉。并不是所有的開發(fā)人員都了解consensus protocol的，但大部分人應(yīng)該都用過鎖。
4. 一個(gè)consensus protocol一般來說需要使用到好幾臺(tái)副本來保證HA（詳見Paxos算法），而使用Chubby，就算只有一個(gè)client也能用。
可以看出，之所以用lock service這樣的形式，是因?yàn)镃hubby不僅僅想解決一致性問題，還可以提供更多更有用的功能。事實(shí)上，Google有很多開發(fā)人員將Chubby當(dāng)做name service使用，效果非常好。