一 本書作者介紹
此書名爲從Paxos到ZooKeeper分佈式一致性原理與實踐，作者倪超，阿里巴巴集團高級研發工程師，國家認證系統分析師，畢業於杭州電子科技大學計算機系。2010年加入阿里巴巴中間件團隊擔任研發實習崗位，一直從事Zookeeper的開發與運維工作，從中學習與總結了不少分佈式一致性相關的理論與實踐經驗，尤其對Zookeeper及其相關技術有非常深入的研究。目前在中間件團隊專家組任職產品經理，負責分佈式產品的產品化和雲計算改造工作。這本書涉及分佈式領域絕大多數系統和框架，適合剛入門和想深入學習分佈式框架的使用者。
二 書目內容結構
這本書先從分佈式一致性的理論出發，向讀者介紹了幾種典型的分佈式一致協議，以及解決分佈式一致性問題的思路，重點講解了Paxos和ZAB協議。同時，深入介紹了分佈式一致性問題的工業解決方案----ZooKeeper，然後展示了這款框架的使用方法，旨在幫助讀者掌握Zookeeper的原理和實際應用。全書分爲8章，總共有5部分：第一部分（第1章）主要介紹了計算機系統從集中式向分佈式系統演變過程中面臨的挑戰，並簡要介紹了ACID、CAP和BASE等經典分佈式理論；第二部分（第2～4章）介紹了2PC、3PC和Paxos三種分佈式一致性協議，並着重講解了ZooKeeper中使用的一致性協議——ZAB協議；第三部分（第5～6章）介紹了ZooKeeper的使用方法，包括客戶端API的使用以及對ZooKeeper服務的部署與運行，並結合真實的分佈式應用場景，總結了ZooKeeper使用實踐；第四部分（第7章）對ZooKeeper的架構設計和實現原理進行了深入分析，包含系統模型、Leader選舉、客戶端與服務端的工作原理、請求處理，以及服務器角色的工作流程和數據存儲等；第五部分（第8章）介紹了ZooKeeper的運維實踐，包括配置詳解和監控管理等，重點講解了如何構建一個高可用的ZooKeeper服務。
三 讀書心得
讀完本書，我對自己的要求就是知道下面的幾個方面，是什麼---這本書主要內容及技術，以及這些技術在什麼場景下使用；怎麼做----主要針對Zookeeper的具體使用；爲什麼---使用這些技術，帶來的效率還是經濟的影響。
（1）這本書主要內容是什麼
從5個部分來講，第一，計算機系統的演變，從集中式到分佈式的過程，集中式在歷史發展過程中顯示出來的缺點：部署結構簡單，數據的存儲和控制處理完全由集中式的服務器或者服務器集羣來處理，瓶頸問題很突出。所以出現了分佈式，分佈式的幾個特徵：分佈性，多臺計算機在空間上是任意分佈的，機器分佈情況會隨時間而變化，對等性，系統中的計算機沒有主從之分，分佈式的系統通過副本共享數據，一致性通過消息傳遞來保證。然後是ACID即事務的原子性，一致性，隔離性和持久性。同時CAP理論告訴我們：一個分佈式系統不可能同時滿足一致性，可用性，分區容錯性這三個基本需求。所以出現了BASE理論，基本可用，軟狀態，最終一致性。第二，學習了2PC、3PC和Paxos三種分佈式一致性協議，以及Zookeeper用到的一致性協議ZAB協議。其中，
Paxos算法---兩個最重要的屬性：Safety和Liveness：永遠不會發生的，最終都會發生的
一種基於消息傳遞且具有高度容錯特性的一致性算法，目前公認的解決分佈式一致性問題最有效的算法之一。
需要解決的問題1：如何在一個可能放生某個節點異常的分佈式系統中，快速且正確地在集羣內部對某個數據的值達成一致，並且保證不論發生什麼異常（消息通道的異常和節點處的異常），都不會破壞整個系統的一致性。
問題2：假設不存在拜占庭將軍的問題情況下，如何解決一致性問題
paxos算法具體描述：
假設有一組可以提出提案的進程集合，那麼對於一個一致性算法來說，
- 在這些被提出的提案中，只有一個會被選定。
- 如果沒有提案被提出，那麼就不會有被選定的提案。
- 當一個提案被選定後，進程應該可以獲取被選定的提案信息。
- 只有被提出的提案才能被選定。
- 只有一個值被選定
- 如果某個進程認爲某個提案被選定了，那麼這個提案必須是真的被選定的那個
其目標：保證最終由一個提案會被選定，當提案被選定後，進程最終也能獲取到被選定的提案。
三種角色：Proposer、Acceptor、Learner 每個進程可擔任多重角色。
假設：每個參與者以任意的速度執行，可能因爲出錯而停止，也可能會重啓。同時，即是一個提案被選定後，所有的參與者也都有可能失敗或者重啓，因此除非那些失敗或重啓的參與者可以記錄某些信息，否則將無法確定最終的值。
消息在傳輸過程中可能會出現不可預知的延遲，也可能會重複或丟失，但是消息不會被損壞，即消息內容不會被篡改。（保證不會發生拜占庭式的問題）。
提案的選定過程：
P1.只有一個Acceptor的話，Proposer只能發送給該Acceptor,這樣實現起來容易，但是當Acceptor出現問題時候，那麼整個系統就會癱瘓。
P2.不同的Proposer分別提出多個提案。這種情況下，可能會發生下面的情況，沒有一個提案是被多數人批准的，是無法選定一個提案的。如圖1。
圖1
P3.不同的Proposer分別提出多個提案，這樣即使只有兩個提案被提出，如果有一個Acceptor出錯，可能導致無法確定該選定哪個提案。如圖2。
圖2
P4.由於通信是異步的，當提案超過半數接受者，但是某提案還沒發出，或發出的提案還沒被接受者接受，此時就需保證先提出的提案是最新的提案。如果3
圖3
實現主要協議是ZAB
ZAB包括兩種基本的模式，崩潰恢復和消息廣播。當整個服務框架在啓動過程中，或是當Leader服務器出現網絡中斷,崩潰退出與重啓等異常情況時，ZAB協議就會進入恢復模式並選舉產生新的Leader服務器。當選舉產生了新的Leader服務器，同時集羣中已經有過半的機器與該Leader服務器完成了狀態同步以後，ZAB協議就會退出恢復模式。其中，所謂的狀態同步是指數據同步，用來保證集羣中存在過半的機器能夠與Leader服務器的數據狀態保持一致。
當集羣中已經有過半的Follower服務器完成了和Leader服務器的協議同步，那麼整個服務框架就可以進入消息廣播模式了。當一臺同樣遵守ZAB協議的服務器啓動後加入到集羣中時，如果此時集羣中已經存在一個Leader服務器在負責進行消息廣播，那麼新加入的服務器就會自覺地進入數據恢復模式：找到Leader所在的服務器，並與其進行數據同步，，然後一起參與到消息廣播流程中去。ZooKeeper設計成只允許唯一的一個Leader服務器進行事務請求的處理。Leader服務器在接受到客戶端的事務請求後，會生成對應的事務提案併發起一輪廣播協議;而如果集羣中的其他機器接收到客戶端的事務請求，那麼這些非Leader服務器會首先將這個事務請求轉發給Leader服務器。
當Leader服務器出現奔潰退出或機器重啓，或者集羣中已經不存在過半的服務器與該Leader服務器保持正常通信時，那麼在重新開始新一輪的原子廣播事務操作之前，所有的進程首先會使用奔潰恢復協議來使彼此達到一個一致的狀態，於是整個ZAB流程就會從消息廣播模式進入到奔潰恢復模式。
一個機器要成爲新的Leader，必須獲得過半進程的支持，同時由於每個進程都有可能會奔潰，因此。在ZAB協議運行過程中，前後會出現多個Leader，並且每個進程也有可能會多次成爲Leader。進入奔潰恢復模式後，只要集羣中存在過半的服務器能夠彼此進行正常通信，那麼就可以產生一個新的Leader並再次進入消息廣播模式。
（2）技術應用場景
ZooKeeper的應用
默認服務端端口2181，可以配置成單機、集羣、僞集羣三種形式。
其關係：其實單機就是隻有一臺機器，也只配置一臺機器，集羣是有多臺機器也配置了多臺機器，而僞集羣是隻有一臺機器配置了多臺機器，所以這樣的話，自然端口就必須不一樣，因爲端口就是區別於進程的唯一標誌。
主要配置
server.1=127.0.0.1:20881:30881
server.2=127.0.0.1:20882:30882
server.3=127.0.0.1:20883:30883
上面的配置中有兩個TCP port。後面一個是用於Zookeeper選舉用的，而前一個是Leader和Follower或Observer交換數據使用的。我們還注意到server.後面的數字。這個就是myid，用來唯一標識服務器。
Zookeeper的典型應用場景
Zookeeper 是一個典型的發佈/訂閱模式的分佈式數據管理與協調框架開發人員可以使用它來進行分佈式數據的發佈與訂閱。另一方面，通過對Zookeeper中豐富的數據節點類型進行交叉使用，配合Watcher事件通知機制，可以非常方便地構建一些列分佈式應用中都會涉及的核心功能，如數據發佈/訂閱，負載均衡，命名服務，分佈式協調通知，集羣管理，Master選舉，分佈式鎖和分佈式隊列等。
越來越多的分佈式系統將Zookeeper作爲核心組件，如Hadoop,HBase和Kafka等，因此，正確理解Zookeeper的應用場景，對於Zookeeper的使用者來說，顯得尤爲重要。
1.數據的發佈與訂閱
目的：爲了實現配置信息的集中式管理和數據的動態更新。
方式：Push 和 Pull 模式 push模式下，服務端主動將數據更新發送給所有訂閱的客戶端；而拉模式是由客戶端主動發送請求來獲取最新數據，通常客戶端都採用定時進行輪詢拉去的方式。Zookeeper採用的是推拉想結合的方式，客戶端向服務端註冊需要關注的節點，一旦該節點的數據發生變更，那麼服務端就會向相應的客戶端發送Watcher事件通知，客戶端收到這個消息通知之後，需要主動到服務端獲取最新的數據。如果將配置信息存放到ZooKeeper上進行集中管理，那麼通常情況下，應用在啓動的時候會主動到Zookeeper服務端上進行一次配置信息的獲取，同時，在指定節點上註冊一個Watcher監聽，這樣，配置發生變更，服務端會實時通知到所有訂閱的客戶端，從而保證獲取最新配置信息的目的。
應用：在實際開發中，系統中需要使用到的一些通用的配置信息，如硬件系統信息，運行開關設置，數據庫配置信息等。其特點是數據量小，內容會在運行時發生變化，各機器共享，配置一致。一般做法是放在本地配置文件或是內存變量中。都可以在啓動時，或者運行時讀取來保證一致，內存的方式比如JMX來實現對系統運行時內存變量的更新。但是當規模變大時，就比較困難了，因此想到分佈式的解決方案。比如數據源的配置。
2.負載均衡
原理：通過在對等的服務提供方中選擇一個來執行相關業務邏輯。
典例：DNS服務,首先用戶訪問某網站需要知道域名來代替不容易記住的ip，首先可以通過hosts文件來綁定，使得域名與ip對應來解析，但是規模大了，如果需要臨時改域名，就得逐個變更，消耗大量時間，而實時性卻不一定能保證。將這份配置文件放到Zookeeper提供端，可能是某個節點，當啓動時會將它共享於整個服務集羣。當在運行時，如果應用app動態改變，也可以實現監測與運維正常。
3.命名服務
常在一些分佈式服務框架（如RPC、RMI)中的服務地址列表。消費者可以通過指定名字來獲取資源的實體、服務地址和提供者的信息等。
4.分佈式協調/通知
將不同的分佈式組件有機結合起來，作爲一個協調者來控制整個系統的運行流程。基於Zookeeper實現分佈式協調與通知功能，通常做法是不同的客戶端都對Zookeeper上同一個數據節點進行Watcher註冊，監聽數據節點的變化，如果數據節點發生變化，那麼所有訂閱的客戶端都能夠接受到相應的Watcher通知，並作出相應的處理。
（3）爲什麼是Zookeeper
Zookeeper以樹作爲內存數據模型，數據上的每一個節點是最小的數據單元，即Znode.Znode具有不同的節點特性，同時每個節點都具有一個遞增的版本號以此來實現分佈式數據的原子性更新。Zookeeper是作爲大數據時代下從Hadoop分離出來的組件，旨在解決大規模分佈式應用場景下，服務協調同步的問題，他可以爲同在一個分佈式系統中的其他服務提供：統一命名服務、配置管理、分佈式鎖服務、集羣管理等功能）是個很偉大的開源項目，很成熟，有相當大的社區來支持它的發展，而且在生產環境得到廣泛使用。從而造就了Zookeeper
四 已閱讀書目清單
1.深入理解Java虛擬機：JVM高級特性與最佳實踐
2.大型網站系統與JAVA中間件實踐
3.Tomcat權威指南(第二版)(中文版)
更多書籍![]()
加羣161867053獲得。