分佈式一致性，技術選型之路

問題描述： Hasor－RSF 須要一個註冊中心。而這個註冊中心我想把它設計能夠支持集羣部署的，這就來帶了分佈式下服務註冊狀態一致性的問題。

好了下面開始正文，寫的比較潦草。

－－－－－－－－－－－－－－－－

ZooKeeper 做爲數據中心問題。後來發現單純使用 ZK 有這麼幾個問題：

1. ZK 配置繁瑣，整個 Center 全部配置加起來 90% 都是在配置 ZK。 這讓之後維護管理 Center 配置會變的複雜，不符合 最簡化 的設計初衷。

2. 開發者在使用 RSF 做爲 RPC 框架時並不會引入 ZK 。使用 ZK 的目的是爲了同步 Center 的服務數據，由於 ZK 的設計是讓開發者以 Client 形式使用它。 這就形成了若是採用 ZK 做爲分佈式協調者。一個基於 RSF 的 RPC 場景須要（APP、Center、zkServer）三個角色。這樣會複雜化部署環境。

3. 由於 問題 2 的存在，RSF－Center 採用 內置 ZK Server 的方案，結果發現。 內置 ZK ，至關於 ZK 版本固定死。這對 center lib 化是一個沉痛打擊。這又印證了 zk 建議 Client 形式使用它，這一特性。

4. Hasor 對於外部依賴的見解一直是（只用，不擴展，拒絕改寫），實際狀況中發現，在這個原則下 ZK 常常會有一些小問題。這使得使用 ZK 不得不作不少額外的保障工做。小問題例如：啓動選舉過程當中異常、連接斷開以後 Watcher 須要從新註冊。

5. 因而計劃放棄 ZK另尋它路。

數據庫做爲數據中心載體的問題：

1. 須要部署數據庫，會產生（APP、Center、DB）三個角色，會複雜化部署環境。
2. 須要解決雙寫覆蓋問題。
3. 當服務的規模達到，萬級別時，雙向的訂閱關係就會超過數據庫承載上限。進而須要引進分表分庫，架構演進上會變得複雜。
4. 因而放棄 DB 方案。

使用外部分佈式緩存

1. 和前兩個方案同樣，會產生（APP、Center、xxx）三個角色，這樣會複雜化部署環境。
2. 一樣會遇到 DB 上出現的雙寫覆蓋問題。
3. 因而放棄 分佈式緩存方案。

經典 「Paxos算法」，尋找分佈式系統數據存儲的最終方案嘗試。

1. 不得不說Paxos算法，確實是預想中的同樣，比較晦澀難懂。也充分印證了是一個 難者不會會者不難的東西。它的經典在於：1 二階段遞交、2 半數投票經過便可確認數據被寫入。

2. 算法自己並無給出工程樣例，這在實現上讓人比較難如下手。若是僅實現寫入功能，對於 Center 來講 數據的一致性問題並無完全解決，由於還有讀的問題。

3. 爲了保證數據一致性，還要額外引入數據同步機制。一樣須要經過 Paxos 選出半數一致的最大 number 而後去增量同步數據。

4. 數據增量問題，一樣也有困惑很差解決。即使增量同步完成了，也沒法保證若是節點處於少數派，增量同步並不能保證數據是最新的問題。

5. 此外還有活鎖問題。

6. 最終放棄 經典Paxos 的緣由是，雖然算法能夠保證集羣對數據的寫入的連貫性，可是任意節點讀數據沒法保證最新。

Raft，這貨是在2013年提出的，比起老大哥Paxos晚了將近 25年，先進性天然而言會比 Paxos 好一些。

1. 值得推薦的連接：http://thesecretlivesofdata.com/raft/
2. Raft 的經典在於強化了 Leader 的地位，Leader 負責寫。這個算法解決了數據一致性問題。
3. 工程實踐上也十分方便。到目前爲止，已經有不少 raft 的庫能夠選擇。
4. 單點問題：全部寫操做都要經過 Leader 進行，那麼 Leader 的穩定性尤其重要。由於 Leader 的寫變成了單點。
5. 魯棒性：當 Leader 選舉過程當中整個集羣沒法提供寫服務。這個是個大問題，對於大量寫的場景 Raft 一旦重新選舉 Leader 會 block 整個集羣的服務。
6. 基於單點問題，Raft 被放棄。

經典 「Paxos算法」，的演進 「Multi-Paxos」

1. 這貨在 經典Paxos 之上 增長了一個 Leader 的概念。Leader 負責遞交提案。比起 Raft 好處是 Multi-Paxos 容許某一個時間出現多個主，所以不用擔憂 從新選舉Leader 會致使集羣block 的問題。

2. 多個主爭搶遞交提案，理論上會存在衝突。可是 Paxos 的經典在於，任意一個值的肯定都要通過半數贊成。所以，即使是在多兩個主。整個集羣的寫入依然會保證一致性。

3. 這個算法雖然出現了 Leader 角色，可是並無像 Raft 那樣特別強調 Leader 的地位。

4. 另外 Multi-Paxos 和 Paxos 同樣，容許日誌的連續性出現空洞。 這一點 Center 是能夠接受的必經，我只要最終一致性，不要連續一致性。

5. 寫到這裏彷佛 Multi-Paxos 就是理想中的伊甸園了。可是，這貨實現起來好想沒有那麼簡單。

6. 另外活鎖、讀、增量數據同步。這些問題也是須要在仔細考慮的。

JGroups 意外的收穫。

1. 複雜，JGroups 是爲了解決 組播，等網絡傳輸問題的。並非被設計用來解決 分佈式一致性問題。 引入 JGroups 顯得太重。
2. 協議棧雖然是亮點，可是 Center 的核心問題是 「分佈式一致性」。
3. 若是放棄 ZK 那麼 ，RSF－Center 計劃，一切數據傳輸都基於 RSF 傳輸協議。JGroups 傳輸層上的擴展又回讓人從新陷入，內置 ZK Server 的老路。
4. 放棄 JGroups

最後最後： 看樣子須要本身結合 Paxos 和 Raft，從新設計一個新的算法了，彷佛工程量巨大。

歡迎你們一塊兒探討，有沒有更好的辦法