上一篇總結了下分佈式所產生的問---------分佈式系統中一致性問題。今天繼續站在巨人的肩膀上虛心學習一下，怎樣解決這些問題！
一、一致性協議：
計算機大佬們爲了解決分佈式一致性問題，經過了很長的事件探索和研究，其中三個比較出名的解決一致性協議算法爲：二階段提交算法、三階段提交算法、Paxos（中文發音：帕克鎖斯，英文記憶不是很強所有按照自己的發音加強記憶，有誤之處請指出批評）。二階段、三階段算法，大佬們可以百度一大堆。
PAXOS算法：
三階段算法是在二階段算法上的一個優化，主要優化的是性能方面，但是二階段和三階段兩個算法都不能解決分佈式分區容錯（腦裂）的問題。所有paxos算法是一種基於消息傳遞具有高度容錯特徵的一致性算法。也就是說可以解決腦裂所造成的一致性問題。
小結：從二階段到三階段到Paxos算法，都是經過很多年才得出來的。可以看出任何的東西都是從簡單到複雜，不是一出來就是複雜的。老子說過：天下難事必做於易，天下大事必做於細。從小事做起，化繁爲簡。
二、PAXOS算法與Zookeeper：
- Zookeeper是什麼：典型的分佈式數據一致性解決方案。
- Zookeeper解決問題：提供一個高性能、高可用，具有嚴格的順序訪問控制能力的分佈式協調服務。
- Zookeeper設計目標：
- 數據模型要簡單
- 能集羣
- 順序訪問
- 高性能
- Zookeeper名字由來：雅虎內部很多項目都是使用動物的名字命名的，所有雅虎工程師也說這個項目取個動物的名字；於是一個科學家開玩笑說：在這樣我們這裏成動物園了。這話一出，大家都說就叫動物管理員吧。由此Zookeeper的名字就這樣誕生了。
- 爲什麼要用Zookeeper？
- 免費，開源
- 性能高、穩定
- 得到了廣泛的應用。Hadoop,Hbase,Stormd等都用它用作分佈式協調
- Zookeeper內部協議採用類似於PAXOS算法，具體是什麼呢？
三、Zookeeper與ZAB協議：
Zookeeper並沒有採取Paxos算法，而是使用一種稱爲Zookeeper Atomic Broadcase(ZAB,Zookeeper原子消息廣播協議)的協議作爲數據一致性核心算法。該協議是Zookeeper專門設計的一種指出崩潰恢復的原子廣播協議,注意這一點特別爲Zookeeper設計的崩潰恢復的原子消息廣播算法。
ZAB協議包括兩種模式：一種是崩潰恢復，一種是消息廣播
什麼是崩潰恢復呢？
當整個服務框架在啓動過程中，或者當leader服務器出現網絡中斷、崩潰退出與充氣等異常情況是，ZAB協議就進入了恢復模式並選舉新的leader服務器，新的leader服務於過半的機器完成數據同步之後，ZAB協議就會退出恢復模式。
也就是說：分佈式中必定要有一個leader。其次就是leader掛了重新洗牌，新的leader一定會產生，使zookeeper退出恢復模式。
什麼是消息廣播呢？
Zookeeper服務器的三個角色Follow、Leader（只有一臺被選舉出來）、Observer。
ZAB是原子消息廣播，鐵定zookeeper裏面是一直消息傳送機制。當集羣中已經有過半的Follow服務器完成和leader服務的狀態同步，那麼整個服務框架就進入消息廣播模式。當另一個Follow加入時，就會跟leader進入恢復模式，只到同步完成，接着進入分佈式的消息廣播模式。
也就是說：分佈式服務器（leader）沒有出現異常，好的狀態就是消息廣播模式。
低姿態：能力有限，只從簡單的概念說起，也是自己的一些理解。
總結：我的理解：
- ZAB協議是一個專門爲Zookeeper設計的協議，按照ZAB協議，只要leader掛了，就會進入恢復模式，好了就進入消息廣播模式。
- PAXOS算法只要用於構建一個分佈式的一致性狀態機系統；ZAB協議主要用於構建一個高可用的分佈式數據主備系統（zookeeper）。
（還是個菜鳥，有不對的地方可以關注微信指出，不同的意見可以一起討論）。
