前言

我們前面剛講完Zookeeper的共識演算法，還沒介紹它的功能，怎麼就跳到什麼鎖服務了呢？

這是因為Apache系列底下的分散式系統例如: Hadoop、Kafka...等，如果你曾經手動從頭部署過，一定會知道部署的過程中也會同時部署Zookeeper這個服務。

而Zookeeper其實就是Chubby的開源實現;
就像Hadoop是MapReduce的一種開源實現;
就像Kubernetes是Borg的開源實現一樣。

而Google從2000年左右開始跟Amazon一樣也進入了雲的時代，如果有概念的一定知道Google進入雲端有三大馬車頭: GFS、BigTable與MapReduce。

而這三大服務的一個共同核心就是今天要介紹的Chubby，這樣知道這個服務有多重要了吧！

Chubby

簡介

目的

首先，我們要知道Chubby是一個Distributed Lock Service，這在論文的題目就定義了: 《The Chubby lock service for loosely coupled distributed systems》

Chubby provides coarse-grained locking as well as reliable storage for a loosely-coupled distributed system.

為什麼分散式系統會需要一個鎖服務呢？

大家看到現在應該有一個直覺，其實不管是什麼分散式系統，都會碰到的兩個問題就是

1. 選Leader，分散式系統裡的節點要能夠選Leader，對誰是Leader有一個共識
2. 儲存資料的一致性

而這部分你都可以利用Paxos的二階段提交整合Raft的replicate state machine都基本上可以解決，而這甚至可以把Paxos與Raft寫成library用在每一個需要共識演算法的project裡面。

但是Google因為以下幾個原因設計了Chubby這個獨立的鎖服務。

1. 首先，大部分的服務在設計時都是從很小的scale開始的。最開始一定講求可以運作，等到服務為了效能為了HA變得成熟後，需要加入replica servers加入Leader設計時，比較有機會需要用到Consensus Protocal。而使用獨立的Lock Service可以讓開發者不用在現有的架構下做太大的改動，加入幾行條件判斷與RPC Call使用Lock service就可以。

2. 另外在系統選出Leader或是進行Data Partition後，我們會需要讓每一個processes與client知道這些資訊，比方說Leader的位址(ip)。這聽起來像是Name Services的工作，但是Chubby好像就可以直接提供這個功能了，怎麼做呢？Chubby除了設計提供Lock Service，也提供了基本的文件儲存，而這個資訊在Chubby內就會用共識演算法來備份在他自己的內部。有了這個文件儲存，Client與processes可以透過讀取Chubby的文件來得到Leader的資訊與Data的metadata。因此在Google內部有些地方直接拿Chubby來做為DNS使用。而Chubby甚至讓Client可以cache這些文件資料，加快讀取時間，並且在更新時會保證Consistent Caching，因此甚至沒有DNS time-to-live的過期問題

3. 這點很搞笑，設計Chubby的人認為，Lock是大部分開發者都熟悉的東西，畢竟在寫Multithreading/Multiprocessing時，都曾用過Lock來管理Race Condition。因此相較於說服開發者在開發時要用共識演算法來考量一致性問題是非常反直覺的。諷刺的是，其實很多開發者以為自己會用Lock，但是其實非常容易犯錯，尤其在分散式系統沒有考慮到Asynchronous環境下process失效或是網路延遲對Lock的影響。

如果你有印象，Chubby作者就是之前提到世界上只有一個共識演算法，那就是Paxos的那位先生- Mike Burrows，他就是那麼嗆

4. replica servers要HA，就要共識演算法，就要Quorum的要求，因此要是一個集群，超過半數的processes活著。如果抽離出來成為一個Lock services而非讓開發著用Paxos Library寫在程式裡。那就算今天只有一個process作為使用Lock services也可以享受資料儲存HA且一致的好處。

目前為止的小總結，Chubby是一個Lock Service也提供文件儲存。
然後他的Client就是我們常見的分散式系統例如: Hadoop、HBase、GFS...等。

設計方向

Chubby除了上述兩個功能還針對一些使用情境設計了一些功能。

1. 選擇實作一個Lock Service而非一個Consensus Protocal Library
2. 為了Leader Election和資訊紀錄機制，提供文件儲存
3. 這個資訊可能會被上千個clients使用，因此提供watch機制，讓clients可以watch被創建的文件。
4. 也因此搭配watch設計事件通知機制，而不用讓client一直polling資訊
5. 但是還是會有使用chubby的client就是喜歡不斷polling(很嗆)，所以提供caching機制給每一個有watch的clients
6. 因為有些開發者對caching很不熟(更嗆)，所以一律提供Consistent Caching，你不用處理caching機制，你只管讀一定對
7. (作為Google我很怕財物損失與官司)所以提供安全機制與access control

第七點是真的，原文如下

• To avoid both financial loss and jail time, we provide
security mechanisms, including access control.

Chubby

Chubby implements locks, a reliable small-file storage
system, and a session/lease mechanism in a single service.

Coarse-Grained(粗粒度) Lock

這邊講一下Chubby提供的Coarse-Grained Lock，簡單說就是這個Lock的租期比較長，因為使用情境大部分都不需要頻繁地取得/釋放Lock，比方說Leader Election在Leader存活期間可以一直拿著Lock不用釋放又取得。

好處有兩個

1. 對Chubby的負擔較小效能較高，可以服務更多Client。
2. 所以如果Chubby短暫失效，Client仍可以運作不太會被延遲
   Eg. Coarse-Grained的設計可以在Chubby短暫失效又恢復後很大機率還在同一個Lock週期(幾天、幾個禮拜)，如果是Fine-Grained Lock則Chubby失效後，可能Lock也剛好到期，Clint要重新拿Lock時就要等Chubby恢復。
3. 也因此如果是Fine-Grained Lock，Client(分散式系統)要頻繁的重新拿取Lock，效能跟可擴展性比較差。

小結

以上就是Chubby的簡介與設計方向，接下來幾天我們會探討他的設計接著就是他的應用。
這個我們會多花一點篇幅說明，因為其實更後面的Zookeeper、Redis與Etcd本質上是類似的東西，可以更快的融會貫通跟比較。