分佈式同步服務就是提供分佈式同步服務的組件，它對外提供的功能就如同一個單機的鎖服務一樣，當其內部是由多個結點組成的，而且節點之間通過某種分佈式一致性協議（Paxos、Raft）來協調彼此的狀態。如果其中一個節點崩潰了，其他節點就自動接管其功能，繼續對外提供服務，好像什麼都沒有發生過一樣。
4.1 分佈式一致性協議
- 基於狀態機的複製協議，又稱主動複製協議（如Paxos、Raft）
- 集羣中的每個節點，即數據副本（replica [ˈreplɪkə] ）都可以響應客戶的請求，如果某個節點A響應了客戶的請求，就由A將該請求發送給集羣中的每個節點
- 集羣中的每個節點都維護一個狀態機，當有新請求到達時，節點的狀態機就遷移到新狀態。爲了保證數據的一致性，無論這些請求以什麼樣的順序到達，每個節點都安裝同樣的順序執行一系列的用戶請求
- 因爲協議裏已經包含了領導選舉過程，所以不需要單獨的領導選舉協議
- 基於主副本的複製協議，又稱爲被動複製協議（如ZAB）
- 只有主副本處理客戶請求
- 每隔一段時間，主副本就給其他節點發送一個變化更新
- 爲了處理主副本宕機的情況，還需要一個額外的領導選舉協議
4.2 分佈式同步服務中間件簡介
在大型分佈式系統中，分佈式同步服務提供的功能類似於單機操作系統提供的進程（或線程）同步功能，如信號量（semaphore [ˈseməfɔːr] ）、互斥量（mutex /mjuteks/）、事件（event）等
4.3 分佈式同步服務中間件的實現原理
Chubby是谷歌公司實現的以Paxos協議爲基礎的分佈式同步服務。另外，還可以在Chubby上面存放少量的共享信息，因此也可以用Chubby實現Registry服務
一個Chubby部署實例稱爲一個單元（cell）。一個單元由多個副本組成，當前提供服務的副本稱爲主副本（master replica），其他副本稱爲非主副本（non-master-replica）
4.3.1 架構
客戶端通過一個Chubby客戶端與chubby單元通信。每個客戶端都保存了單元中所有副本所在的節點列表。
客戶端先給副本節點列表中的機器發送一個主副本位置查詢請求，如果非主副本收到該消息，就返回主副本的標識；如果主副本收到該消息，就返回自己的標識。知道主副本標識後，客戶端就直接與主副本通信。
4.3.2 如何消除單點故障
在同一時刻，一個單元中只有一個主副本對外提供服務。
單元啓動後，會通過Paxos協議選舉一個主副本。選舉出的主副本有一個幾秒的租約期。其他副本承諾在該租約期不會選舉新的主副本。租約到期後，主副本可以續約，前提是它能夠獲得多數副本的同意。如果主副本宕機了，在當前主副本租約到期後，其他副本會通過Paxos協議選舉出一個新的主副本。
4.3.4 數據庫
Chubby的目錄和文件信息都存放在數據庫中。Chubby使用的數據庫是帶有複製功能的Berkeley（[ˈbɜrkli]） DB。但考慮到Berkeley DB的複製功能是新增加的，Chubby的後續版本就實現了一個與Berkeley DB類似的分佈式數據庫，以替代Berkeley DB
4.4 其他分佈式同步服務中間件
4.4.1 Linux心跳機制
Linux心跳（heartbeat）機制並不能算作是分佈式同步服務，但因其引用廣泛，在此也做一簡單介紹
Linux heartbeat利用Gratuitous ARP原理將多個Linux服務器綁定在一個虛擬IP上，這些服務器中，只有一個處於活動狀態，其他的都處於待機狀態。待機服務器和活動服務器之間有週期性心跳。如果活動服務器宕機了，待機服務器就可以發現這一點，然後發送一個Gratuitous ARP，通知其他的機器該IP對應的MAC地址變成其MAC地址了。
4.4.2 Zookeeper
ZooKeeper（ [ˈzuːkiːpə®] ）是一個分佈式的，開放源碼的分佈式應用程序協調服務，是Google的Chubby一個開源的實現，是Hadoop和Hbase的重要組件。它是一個爲分佈式應用提供一致性服務的軟件，提供的功能包括：配置維護、域名服務、分佈式同步、組服務等。
4.4.3 iNexus
iNexus ([ˈneksəs]簡稱ins) 是一個基於 Raft 協議實現的高可用的分佈式 Key-Value 數據庫，支持數據變更通知（Watch）和分佈式鎖，可用於大型分佈式系統的協調工作。