從Paxos到Zookeeper分布式一緻性原理與實踐 pdf epub mobi txt 電子書 下載 2025

簡體網頁||繁體網頁

☆☆☆☆☆

倪超 著

圖書標籤:

• 分布式係統
• Paxos
• Zookeeper
• 一緻性算法
• 分布式一緻性
• CAP理論
• Raft
• etcd
• 高可用
• 集群
• 微服務

齣版社： 電子工業齣版社

ISBN：9787121249679

版次：1

商品編碼：11622772

品牌：Broadview

包裝：平裝

開本：16開

齣版時間：2015-02-01

用紙：膠版紙

頁數：420

正文語種：中文

編輯推薦

　　

　　國內罕見係統講解ZooKeeper這一應用廣泛、成熟的分布式協調框架之技術書。

　　原理深入，闡述清晰，覆蓋ACID、CAP、BASE，二階段/三階段提交，Paxos、ZAB協議等熱門話題。

　　徹底剖析分布式一緻性問題，並給齣相應係統思路，以及完整解決方案及實戰參考。

　　無論開發人員，還是運維人士，都可通過書中ZooKeeper使用方法、內部實現及運維技巧來全麵提升。

內容簡介

　　

　　《Paxos到Zookeeper 分布式一緻性原理與實踐》從分布式一緻性的理論齣發，嚮讀者簡要介紹幾種典型的分布式一緻性協議，以及解決分布式一緻性問題的思路，其中重點講解瞭Paxos和ZAB協議。同時，本書深入介紹瞭分布式一緻性問題的工業解決方案——ZooKeeper，並著重嚮讀者展示這一分布式協調框架的使用方法、內部實現及運維技巧，旨在幫助讀者全麵瞭解ZooKeeper，並更好地使用和運維ZooKeeper。全書共8章，分為五部分：前一部分（第1章）主要介紹瞭計算機係統從集中式嚮分布式係統演變過程中麵臨的挑戰，並簡要介紹瞭ACID、CAP和BASE等經典分布式理論；第二部分（第2～4章）介紹瞭2PC、3PC和Paxos三種分布式一緻性協議，並著重講解瞭ZooKeeper中使用的一緻性協議——ZAB協議；第三部分（第5～6章）介紹瞭ZooKeeper的使用方法，包括客戶端API的使用以及對ZooKeeper服務的部署與運行，並結閤真實的分布式應用場景，總結瞭ZooKeeper使用實踐；第四部分（第7章）對ZooKeeper的架構設計和實現原理進行瞭深入分析，包含係統模型、Leader選舉、客戶端與服務端的工作原理、請求處理，以及服務器角色的工作流程和數據存儲等；第五部分（第8章）介紹瞭ZooKeeper的運維實踐，包括配置詳解和監控管理等，重點講解瞭如何構建一個高可用的ZooKeeper服務。

作者簡介

　　倪超，阿裏巴巴集團高級研發工程師，國傢認證係統分析師，畢業於杭州電子科技大學計算機係。2010年加入阿裏巴巴中間件團隊擔任研發實習崗位，一直從事ZooKeeper的開發與運維工作，從中學習與總結瞭不少分布式一緻性相關的理論與實踐經驗，尤其對ZooKeeper及其相關技術有非常深入的研究。目前在中間件團隊專傢組任職産品經理，負責分布式産品的産品化和雲計算化改造工作。

內頁插圖

精彩書評

　　

　　★感謝軟件開源和知識開源，新浪愛彩利用各開源軟件和算法，構建瞭核心交易係統和分布式中間件係統：利用ZooKeeper 構建瞭分布式 ID 生成器、分布式單例控製器、Dubbo RPC 框架，以及基於 Hadoop/JStorm/Spark 體係的業務係統，等等。ZooKeeper 的穩定性和對一緻性的保證一直為業界所稱道，在大量的分布式係統和開源組件中得到應用。本書是作者在長期使用 ZooKeeper 後深入研究其算法原理和源代碼的總結，將對讀者在分布式一緻性的理論學習與實踐上有啓發意義。

　　——新浪愛彩首席架構師　周鋒

　　
　　★分布式一緻性是中國銀聯風控係統架構與設計的重要目標，新一代的銀聯反洗錢交易實時分析係統采用 Storm 進行大數據的實時計算，ZooKeeper 作為 Storm 的重要組成部分，為數據一緻性提供瞭關鍵保障。本書深入淺齣地描述瞭分布式一緻性這一問題的由來，並對 ZooKeeper 在 Storm、Hadoop 和 HBase 等大型分布式係統中的應用場景進行瞭詳盡介紹，針對 ZooKeeper在分布式係統中的業務實踐與運維保障提供瞭重要參考。

　　——中國銀聯反洗錢係統核心負責人　羅科勤

　　
　　★分布式地理信息係統的研發挑戰主要在於它的地理信息共享和分布式協調操作，ZooKeeper 作為一個針對大型分布式係統的高可靠協調係統，提供的功能包括：配置維護、名字服務、分布式同步和組服務等，正好能夠解決地信係統中的諸多分布式一緻性問題。該書兼顧分布式一緻性的理論和實踐，並重點講解瞭 ZooKeeper，適閤不同層次的讀者閱讀。

　　——浙江省測繪局地信係統設計師　王浩烽

　　
　　★騰訊在 2010 年啓動建設開放雲平颱時，麵臨著海量第三方虛擬機之間訪問限製規則以及內網透明負載均衡配置的管理等問題。引入 ZooKeeper 之後，一直穩定運行至今，利用其發布訂閱特性很好地保證瞭規則數據和配置信息的一緻性，確保瞭服務的可用性。本書從分布式一緻性理論齣發，再以ZooKeeper 係統為例詳盡地介紹瞭這個開源係統的架構與實現，並結閤實際的應用場景和運維經驗為在實戰中麵臨分布式問題的讀者提供瞭重要參考。

　　——騰訊企業級産品中心架構師　陳盛龍

　　
　　★一緻性是計算機學科中“硬”和重要的問題之一，可見寫這樣一個主題挑戰之大。阿裏巴巴業務龐大，倪超之前維護的為整個集團提供一緻性方案的 ZooKeeper 集群，場景之復雜、規模之大在國內甚至世界上都可能是罕見的。本人由於工作需要對 Paxos 和 ZooKeeper 進行瞭粗淺的學習，所以有機會和倪超有過這方麵的交流，樂自不言，獲益彼多。本書兼顧理論與實踐，希望讓讀者讀完之後有所提升：使用上知其所以然，架構上能選擇齣閤適又低成本的方案。

　　——阿裏巴巴 Dubbo 框架、PaaS 平颱資深架構師 & 核心開發 李鼎

　　
　　★在我的工作經曆中，有多次與分布式係統的配置管理中心打過交道，比如之前在老東傢阿裏巴巴負責 HSF 服務框架，以及最近在陌陌負責的 MOA 服務框架的工作。基於簡單可用的原則，這些場景都沒有選擇使用 ZooKeeper，而是自己實現瞭配置管理係統。但最近在參與分布式緩存服務建設的過程中，我們發現已經無法再繞開分布式協調問題，這時，ZooKeeper作為行業的成熟實踐就成瞭我們的優選。這本書的作者倪超是我在阿裏的同事，一直從事著與 ZooKeeper 相關的工作 在這個領域積纍瞭豐富的經驗。本書從理論、設計實現和應用場景等多個方麵對 ZooKeeper 進行瞭深入介紹，非常值得一讀。

　　——陌陌基礎平颱部主管　宓學強

　　
　　★搜狐從 2009 年微博時代初期就利用 ZooKeeper 的發布與訂閱模型實現瞭對 CDN URL 和一些基本管理配置的動態加載。至今 ZooKeeper 已經被運用在瞭搜狐各大業務綫上，完成瞭許多分布式高可用服務的構建，範圍涉及分布式緩存、服務化框架和前端業務係統等等，幫助團隊解決瞭分布式方麵的主要技術障礙，大大提高瞭業務穩定性和運維效率。本書全麵詳盡地介紹瞭分布式環境中各個典型場景下的 ZooKeeper 應用實例，為讀者構建自己的分布式高可用服務提供瞭參考。

　　——搜狐移動事業部高級運維主管　劉鵬

目錄

第1章 分布式架構
1．1 從集中式到分布式
1．1．1 集中式的特點
1．1．2 分布式的特點
1．1．3 分布式環境的各種問題
1．2 從ACID到CAP/BASE
1．2．1 ACID
1．2．2 分布式事務
1．2．3 CAP和BASE理論
小結

第2章 一緻性協議
2．1 2PC與3PC
2．1．1 2PC
2．1．2 3PC
2．2 Paxos算法
2．2．1 追本溯源
2．2．2 Paxos理論的誕生
2．2．3 Paxos算法詳解
小結

第3章 Paxos的工程實踐
3．1 Chubby
3．1．1 概述
3．1．2 應用場景
3．1．3 設計目標
3．1．4 Chubby技術架構
3．1．5 Paxos協議實現
3．2 Hypertable
3．2．1 概述
3．2．2 算法實現
小結

第4章 ZooKeeper與Paxos
4．1 初識ZooKeeper
4．1．1 ZooKeeper介紹
4．1．2 ZooKeeper從何而來
4．1．3 ZooKeeper的基本概念
4．1．4 為什麼選擇ZooKeeper
4．2 ZooKeeper的ZAB協議
4．2．1 ZAB協議
4．2．2 協議介紹
4．2．3 深入ZAB協議
4．2．4 ZAB與Paxos算法的聯係與區彆
小結

第5章 使用ZooKeeper
5．1 部署與運行
5．1．1 係統環境
5．1．2 集群與單機
5．1．3 運行服務
5．2 客戶端腳本
5．2．1 創建
5．2．2 讀取
5．2．3 更新
5．2．4 刪除
5．3 Java客戶端API使用
5．3．1 創建會話
5．3．2 創建節點
5．3．3 刪除節點
5．3．4 讀取數據
5．3．5 更新數據
5．3．6 檢測節點是否存在
5．3．7 權限控製
5．4 開源客戶端
5．4．1 ZkClient
5．4．2 Curator
小結

第6章 ZooKeeper的典型應用場景
6．1 典型應用場景及實現注
6．1．1 數據發布/訂閱
6．1．2 負載均衡
6．1．3 命名服務
6．1．4 分布式協調/通知
6．1．5 集群管理
6．1．6 Master選舉
6．1．7 分布式鎖
6．1．8 分布式隊列
小結
6．2 ZooKeeper在大型分布式係統中的應用
6．2．1 Hadoop
6．2．2 HBase
6．2．3 Kafka
6．3 ZooKeeper在阿裏巴巴的實踐與應用
6．3．1 案例一 消息中間件：Metamorphosis
6．3．2 案例二 RPC服務框架：Dubbo
6．3．3 案例三 基於MySQL Binlog的增量訂閱和消費組件：Canal
6．3．4 案例四 分布式數據庫同步係統：Otter
6．3．5 案例五 輕量級分布式通用搜索平颱：終搜
6．3．6 案例六 實時計算引擎：JStorm
小結

第7章 ZooKeeper技術內幕
7．1 係統模型
7．1．1 數據模型
7．1．2 節點特性
7．1．3 版本――保證分布式數據原子性操作
7．1．4 Watcher――數據變更的通知
7．1．5 ACL――保障數據的安全
7．2 序列化與協議
7．2．1 Jute介紹
7．2．2 使用Jute進行序列化
7．2．3 深入Jute
7．2．4 通信協議
7．3 客戶端
7．3．1 一次會話的創建過程
7．3．2 服務器地址列錶
7．3．3 ClientCnxn：網絡I/O
7．4 會話
7．4．1 會話狀態
7．4．2 會話創建
7．4．3 會話管理
7．4．4 會話清理
7．4．5 重連
7．5 服務器啓動
7．5．1 單機版服務器啓動
7．5．2 集群版服務器啓動
7．6 Leader選舉
7．6．1 Leader選舉概述
7．6．2 Leader選舉的算法分析
7．6．3 Leader選舉的實現細節
7．7 各服務器角色介紹
7．7．1 Leader
7．7．2 Follower
7．7．3 Observer
7．7．4 集群間消息通信
7．8 請求處理
7．8．1 會話創建請求
7．8．2 SetData請求
7．8．3 事務請求轉發
7．8．4 GetData請求
7．9 數據與存儲
7．9．1 內存數據
7．9．2 事務日誌
7．9．3 snapshot――數據快照
7．9．4 初始化
7．9．5 數據同步
小結

第8章 ZooKeeper運維
8．1 配置詳解
8．1．1 基本配置
8．1．2 高級配置
8．2 四字命令
8．3 JMX
8．3．1 開啓遠程JMX
8．3．2 通過JConsole連接ZooKeeper
8．4 監控
8．4．1 實時監控
8．4．2 數據統計
8．5 構建一個高可用的集群
8．5．1 集群組成
8．5．2 容災
8．5．3 擴容與縮容
8．6 日常運維
8．6．1 數據與日誌管理
8．6．2 Too many connections
8．6．3 磁盤管理
小結
附錄A Windows平颱上部署ZooKeeper
附錄B 從源代碼開始構建
附錄C 各發行版本重大更新記錄
附錄D ZooKeeper源代碼閱讀指引

精彩書摘

　　第1章　　分布式架構　　隨著計算機係統規模變得越來越大，將所有的業務單元集中部署在一個或若乾個大型機上的體係結構，已經越來越不能滿足當今計算機係統，尤其是大型互聯網係統的快速發展，各種靈活多變的係統架構模型層齣不窮。同時，隨著微型計算機的齣現，越來越多廉價的PC機成為瞭各大企業IT架構的首選，分布式的處理方式越來越受到業界的青睞——計算機係統正在經曆一場前所未有的從集中式嚮分布式架構的變革。　　1.1 從集中式到分布式　　自20世紀60年代大型主機被發明齣來以後，憑藉其超強的計算和I/O處理能力以及在穩定性和安全性方麵的卓越錶現，在很長一段時間內，大型主機引領瞭計算機行業以及商業計算領域的發展。在大型主機的研發上最知名的當屬IBM，其主導研發的革命性産品System/360係列大型主機，是計算機發展史上的一個裏程碑，與波音707和福特T型車齊名，被譽為20世紀最重要的三大商業成就，並一度成為瞭大型主機的代名詞。從那時起，IT界進入瞭大型主機時代。　　伴隨著大型主機時代的到來，集中式的計算機係統架構也成為瞭主流。在那個時候，由於大型主機卓越的性能和良好的穩定性，其在單機處理能力方麵的優勢非常明顯，使得IT係統快速進入瞭集中式處理階段，其對應的計算機係統稱為集中式係統。但從20世紀80年代以來，計算機係統嚮網絡化和微型化的發展日趨明顯，傳統的集中式處理模式越來越不能適應人們的需求。　　首先，大型主機的人纔培養成本非常之高。通常一颱大型主機匯集瞭大量精密的計算機組件，操作非常復雜，這對一個運維人員掌握其技術細節提齣瞭非常高的要求。　　其次，大型主機也是非常昂貴的。通常一颱配置較好的IBM大型主機，其售價可能在上百萬美元甚至更高，因此也隻有像政府、金融和電信等企業纔有能力采購大型主機。　　另外，集中式係統具有明顯的單點問題。大型主機雖然在性能和穩定性方麵錶現卓越，但這並不代錶其永遠不會齣現故障。一旦一颱大型主機齣現瞭故障，那麼整個係統將處於不可用狀態，其後果相當嚴重。最後，隨著業務的不斷發展，用戶訪問量迅速提高，計算機係統的規模也在不斷擴大，在單一大型主機上進行係統的擴容往往比較睏難。　　而另一方麵，隨著PC機性能的不斷提升和網絡技術的快速普及，大型主機的市場份額變得越來越小，很多企業開始放棄原來的大型主機，而改用小型機和普通PC服務器來搭建分布式的計算機係統。　　其中最為典型的就是阿裏巴巴集團的“去IOE”運動。從2008年開始，阿裏巴巴的各項業務都進入瞭井噴式的發展階段，這對於後颱IT係統的計算與存儲能力提齣瞭非常高的要求，一味地針對小型機和高端存儲進行不斷擴容，無疑會産生巨大的成本。同時，集中式的係統架構體係也存在諸多單點問題，完全無法滿足互聯網應用爆炸式的發展需求。因此，為瞭解決業務快速發展給IT係統帶來的巨大挑戰，從2009年開始，阿裏集團啓動瞭“去IOE”計劃，其電商係統開始正式邁入分布式係統時代。　　1.1.1 集中式的特點　　所謂的集中式係統就是指由一颱或多颱主計算機組成中心節點，數據集中存儲於這個中心節點中，並且整個係統的所有業務單元都集中部署在這個中心節點上，係統的所有功能均由其集中處理。也就是說，在集中式係統中，每個終端或客戶端機器僅僅負責數據的錄入和輸齣，而數據的存儲與控製處理完全交由主機來完成。　　集中式係統最大的特點就是部署結構簡單。由於集中式係統往往基於底層性能卓越的大型主機，因此無須考慮如何對服務進行多個節點的部署，也就不用考慮多個節點之間的分布式協作問題。　　1.1.2 分布式的特點　　在《分布式係統概念與設計》注 一書中，對分布式係統做瞭如下定義：　　分布式係統是一個硬件或軟件組件分布在不同的網絡計算機上，彼此之間僅僅通過消息傳遞進行通信和協調的係統。　　上麵這個簡單的定義涵蓋瞭幾乎所有有效地部署瞭網絡化計算機的係統。嚴格地講，同一個分布式係統中的計算機在空間部署上是可以隨意分布的，這些計算機可能被放在不同的機櫃上，也可能在不同的機房中，甚至分布在不同的城市。無論如何，一個標準的分布式係統在沒有任何特定業務邏輯約束的情況下，都會有如下幾個特徵。　　分布性　　分布式係統中的多颱計算機都會在空間上隨意分布，同時，機器的分布情況也會隨時變動。　　對等性　　分布式係統中的計算機沒有主/從之分，既沒有控製整個係統的主機，也沒有被控製的從機，組成分布式係統的所有計算機節點都是對等的。副本（Replica）是分布式係統最常見的概念之一，指的是分布式係統對數據和服務提供的一種冗餘方式。在常見的分布式係統中，為瞭對外提供高可用的服務，我們往往會對數據和服務進行副本處理。數據副本是指在不同的節點上持久化同一份數據，當某一個節點上存儲的數據丟失時，可以從副本上讀取到該數據，這是解決分布式係統數據丟失問題最為有效的手段。另一類副本是服務副本，指多個節點提供同樣的服務，每個節點都有能力接收來自外部的請求並進行相應的處理。　　並發性　　在“問題的提齣”部分，我們已經提到過與“更新的並發性”相關的內容。在一個計算機網絡中，程序運行過程中的並發性操作是非常常見的行為，例如同一個分布式係統中的多個節點，可能會並發地操作一些共享的資源，諸如數據庫或分布式存儲等，如何準確並高效地協調分布式並發操作也成為瞭分布式係統架構與設計中最大的挑戰之一。　　缺乏全局時鍾　　在上麵的講解中，我們已經瞭解到，一個典型的分布式係統是由一係列在空間上隨意分布的多個進程組成的，具有明顯的分布性，這些進程之間通過交換消息來進行相互通信。因此，在分布式係統中，很難定義兩個事件究竟誰先誰後，原因就是因為分布式係統缺乏一個全局的時鍾序列控製。關於分布式係統的時鍾和事件順序，在Leslie Lamport注 的經典論文Time， Clocks， and the Ordering of Events in a Distributed System注 中已經做瞭非常深刻的講解。　　故障總是會發生　　組成分布式係統的所有計算機，都有可能發生任何形式的故障。一個被大量工程實踐所檢驗過的黃金定理是：任何在設計階段考慮到的異常情況，一定會在係統實際運行中發生，並且，在係統實際運行過程中還會遇到很多在設計時未能考慮到的異常故障。所以，除非需求指標允許，在係統設計時不能放過任何異常情況。　　1.1.3 分布式環境的各種問題　　分布式係統體係結構從其齣現之初就伴隨著諸多的難題和挑戰，本節將嚮讀者簡要的介紹分布式環境中一些典型的問題。　　通信異常　　從集中式嚮分布式演變的過程中，必然引入瞭網絡因素，而由於網絡本身的不可靠性，因此也引入瞭額外的問題。分布式係統需要在各個節點之間進行網絡通信，因此每次網絡通信都會伴隨著網絡不可用的風險，網絡光縴、路由器或是DNS等硬件設備或是係統不可用都會導緻最終分布式係統無法順利完成一次網絡通信。另外，即使分布式係統各節點之間的網絡通信能夠正常進行，其延時也會遠大於單機操作。通常我們認為在現代計算機體係結構中，單機內存訪問的延時在納秒數量級（通常是10ns左右），而正常的一次網絡通信的延遲在0.1~1ms左右（相當於內存訪問延時的105~106倍），如此巨大的延時差彆，也會影響消息的收發的過程，因此消息丟失和消息延遲變得非常普遍。　　網絡分區　　當網絡由於發生異常情況，導緻分布式係統中部分節點之間的網絡延時不斷增大，最終導緻組成分布式係統的所有節點中，隻有部分節點之間能夠進行正常通信，而另一些節點則不能——我們將這個現象稱為網絡分區，就是俗稱的“腦裂”。當網絡分區齣現時，分布式係統會齣現局部小集群，在極端情況下，這些局部小集群會獨立完成原本需要整個分布式係統纔能完成的功能，包括對數據的事務處理，這就對分布式一緻性提齣瞭非常大的挑戰。　　三態　　從上麵的介紹中，我們已經瞭解到瞭在分布式環境下，網絡可能會齣現各式各樣的問題，因此分布式係統的每一次請求與響應，存在特有的“三態”概念，即成功、失敗與超時。在傳統的單機係統中，應用程序在調用一個函數之後，能夠得到一個非常明確的響應：成功或失敗。而在分布式係統中，由於網絡是不可靠的，雖然在絕大部分情況下，網絡通信也能夠接收到成功或失敗的響應，但是當網絡齣現異常的情況下，就可能會齣現超時現象，通常有以下兩種情況：　　由於網絡原因，該請求（消息）並沒有被成功地發送到接收方，而是在發送過程就發生瞭消息丟失現象。　　該請求（消息）成功的被接收方接收後，並進行瞭處理，但是在將響應反饋給發送方的過程中，發生瞭消息丟失現象。　　當齣現這樣的超時現象時，網絡通信的發起方是無法確定當前請求是否被成功處理的。　　節點故障　　節點故障則是分布式環境下另一個比較常見的問題，指的是組成分布式係統的服務器節點齣現的宕機或“僵死”現象。通常根據經驗來說，每個節點都有可能會齣現故障，並且每天都在發生。　　1.2 從ACID到CAP/BASE　　在上文中，我們講解瞭集中式係統和分布式係統各自的特點，同時也看到瞭在從集中式係統架構嚮分布式係統架構變遷的過程中會碰到的一係列問題。接下來，我們再重點看看在分布式係統事務處理與數據一緻性上遇到的種種挑戰。　　1.2.1 ACID　　事務（Transaction）是由一係列對係統中數據進行訪問與更新的操作所組成的一個程序執行邏輯單元（Unit），狹義上的事務特指數據庫事務。一方麵，當多個應用程序並發訪問數據庫時，事務可以在這些應用程序之間提供一個隔離方法，以防止彼此的操作互相乾擾。另一方麵，事務為數據庫操作序列提供瞭一個從失敗中恢復到正常狀態的方法，同時提供瞭數據庫即使在異常狀態下仍能保持數據一緻性的方法。　　事務具有四個特徵，分彆是原子性（Atomicity）、一緻性（Consistency）、隔離性（Isolation）和持久性（Durability），簡稱為事務的ACID特性。　　原子性　　事務的原子性是指事務必須是一個原子的操作序列單元。事務中包含的各項操作在一次執行過程中，隻允許齣現以下兩種狀態之一。　　全部成功執行。　　全部不執行。　　任何一項操作失敗都將導緻整個事務失敗，同時其他已經被執行的操作都將被撤銷並迴滾，隻有所有的操作全部成功，整個事務纔算是成功完成。　　一緻性　　事務的一緻性是指事務的執行不能破壞數據庫數據的完整性和一緻性，一個事務在執行之前和執行之後，數據庫都必須處於一緻性狀態。也就是說，事務執行的結果必須是使數據庫從一個一緻性狀態轉變到另一個一緻性狀態，因此當數據庫隻包含成功事務提交的結果時，就能說數據庫處於一緻性狀態。而如果數據庫係統在運行過程中發生故障，有些事務尚未完成就被迫中斷，這些未完成的事務對數據庫所做的修改有一部分已寫入物理數據庫，這時數據庫就處於一種不正確的狀態，或者說是不一緻的狀態。　　隔離性　　事務的隔離性是指在並發環境中，並發的事務是相互隔離的，一個事務的執行不能被其他事務乾擾。也就是說，不同的事務並發操縱相同的數據時，每個事務都有各自完整的數據空間，即一個事務內部的操作及使用的數據對其他並發事務是隔離的，並發執行的各個事務之間不能互相乾擾。　　在標準SQL規範中，定義瞭4個事務隔離級彆，不同的隔離級彆對事務的處理不同，如未授權讀取、授權讀取、可重復讀取和串行化注 。　　未授權讀取　　未授權讀取也被稱為讀未提交（Read Uncommitted），該隔離級彆允許髒讀取，其隔離級彆最低。換句話說，如果一個事務正在處理某一數據，並對其進行瞭更新，但同時尚未完成事務，因此還沒有進行事務提交；而與此同時，允許另一個事務也能夠訪問該數據。舉個例子來說，事務A和事務B同時進行，事務A在整個執行階段，會將某數據項的值從1開始，做一係列加法操作（比如說加1操作）直到變成10之後進行事務提交，此時，事務B能夠看到這個數據項在事務A操作過程中的所有中間值（如1變成2、2變成3等），而對這一係列的中間值的讀取就是未授權讀取。　　授權讀取　　授權讀取也被稱為讀已提交（Read Committed），它和未授權讀取非常相近，唯一的區彆就是授權讀取隻允許獲取已經被提交的數據。同樣以上麵的例子來說，事務A和事務B同時進行，事務A進行與上述同樣的操作，此時，事務B無法看到這個數據項在事務A操作過程中的所有中間值，隻能看到最終的10。另外，如果說有一個事務C，和事務A進行非常類似的操作，隻是事務C是將數據項從10加到20，此時事務B也同樣可以讀取到20，即授權讀取允許不可重復讀取。　　可重復讀取　　可重復讀取（Repeatable Read），簡單地說，就是保證在事務處理過程中，多次讀取同一個數據時，其值都和事務開始時刻是一緻的。因此該事務級彆禁止瞭不可重復讀取和髒讀取，但是有可能齣現幻影數據。所謂幻影數據，就是指同樣的事務操作，在前後兩個時間段內執行對同一個數據項的讀取，可能齣現不一緻的結果。在上麵的例子，可重復讀取隔離級彆能夠保證事務B在第一次事務操作過程中，始終對數據項讀取到1，但是在下一次事務操作中，即使事務B（注意，事務名字雖然相同，但是指的是另一次事務操作）采用同樣的查詢方式，就可能會讀取到10或20。　　串行化　　串行化（Serializable）是最嚴格的事務隔離級彆。它要求所有事務都被串行執行，即事務隻能一個接一個地進行處理，不能並發執行。　　圖1-1展示瞭不同隔離級彆下事務訪問數據的差異。　　圖1-1．4種隔離級彆示意圖　　以上4個隔離級彆的隔離性依次增強，分彆解決不同的問題，錶1-1對這4個隔離級彆進行瞭一個簡單的對比。　　錶1-1．隔離級彆對比　　隔離級彆 髒讀 可重復讀 幻讀　　未授權讀取 存在 不可以 存在　　授權讀取 不存在 不可以 存在　　可重復讀取 不存在 可以 存在　　串行化 不存在 可以 不存在　　事務隔離級彆越高，就越能保證數據的完整性和一緻性，但同時對並發性能的影響也越大。通常，對於絕大多數的應用程序來說，可以優先考慮將數據庫係統的隔離級彆設置為授權讀取，這能夠在避免髒讀取的同時保證較好的並發性能。盡管這種事務隔離級彆會導緻不可重復讀、虛讀和第二類丟失更新等並發問題，但較為科學的做法是在可能齣現這類問題的個彆場閤中，由應用程序主動采用悲觀鎖或樂觀鎖來進行事務控製。　　持久性　　事務的持久性也被稱為永久性，是指一個事務一旦提交，它對數據庫中對應數據的狀態變更就應該是永久性的。換句話說，一旦某個事務成功結束，那麼它對數據庫所做的更新就必須被永久保存下來——即使發生係統崩潰或機器宕機等故障，隻要數據庫能夠重新啓動，那麼一定能夠將其恢復到事務成功結束時的狀態。　　1.2.2 分布式事務　　隨著分布式計算的發展，事務在分布式計算領域中也得到瞭廣泛的應用。在單機數據庫中，我們很容易能夠實現一套滿足ACID特性的事務處理係統，但在分布式數據庫中，數據分散在各颱不同的機器上，如何對這些數據進行分布式的事務處理具有非常大的挑戰。在1.1.3節中，我們已經講解瞭分布式環境中會碰到的種種問題，其中就包括機器宕機和各種網絡異常等。盡管存在這種種分布式問題，但是在分布式計算領域，為瞭保證分布式應用程序的可靠性，分布式事務是無法迴避的。　　分布式事務是指事務的參與者、支持事務的服務器、資源服務器以及事務管理器分彆位於分布式係統的不同節點之上。通常一個分布式事務中會涉及對多個數據源或業務係統的操作。　　我們可以設想一個最典型的分布式事務場景：一個跨銀行的轉賬操作涉及調用兩個異地的銀行服務，其中一個是本地銀行提供的取款服務，另一個則是目標銀行提供的存款服務，這兩個服務本身是無狀態並且是互相獨立的，共同構成瞭一個完整的分布式事務。如果從本地銀行取款成功，但是因為某種原因存款服務失敗瞭，那麼就必須迴滾到取款前的狀態，否則用戶可能會發現自己的錢不翼而飛瞭。　　從上麵這個例子中，我們可以看到，一個分布式事務可以看作是由多個分布式的操作序列組成的，例如上麵例子中的取款服務和存款服務，通常可以把這一係列分布式的操作序列稱為子事務。因此，分布式事務也可以被定義為一種嵌套型的事務，同時也就具有瞭ACID事務特性。但由於在分布式事務中，各個子事務的執行是分布式的，因此要實現一種能夠保證ACID特性的分布式事務處理係統就顯得格外復雜。　　1.2.3 CAP和BASE理論　　對於本地事務處理或者是集中式的事務處理係統，很顯然我們可以采用已經被實踐證明很成熟的ACID模型來保證數據的嚴格一緻性。而在1.2.2節中，我們也已經看到，隨著分布式事務的齣現，傳統的單機事務模型已經無法勝任。尤其是對於一個高訪問量、高並發的互聯網分布式係統來說，如果我們期望實現一套嚴格滿足ACID特性的分布式事務，很可能齣現的情況就是在係統的可用性和嚴格一緻性之間齣現衝突——因為當我們要求分布式係統具有嚴格一緻性時，很可能就需要犧牲掉係統的可用性。但毋庸置疑的一點是，可用性又是一個所有消費者不允許我們討價還價的係統屬性，比如說像淘寶網這樣的在綫購物網站，就要求它能夠7？24小時不間斷地對外提供服務，而對於一緻性，則更加是所有消費者對於一個軟件係統的剛需。因此，在可用性和一緻性之間永遠無法存在一個兩全其美的方案，於是如何構建一個兼顧可用性和一緻性的分布式係統成為瞭無數工程師探討的難題，齣現瞭諸如CAP和BASE這樣的分布式係統經典理論。　　CAP定理　　2000年7月，來自加州大學伯剋利分校的Eric Brewer教授注 在ACM PODC（Principles of Distributed Computing）會議上，首次提齣瞭著名的CAP猜想注 。2年後，來自麻省理工學院的Seth Gilbert和Nancy Lynch從理論上證明瞭Brewer教授CAP猜想的可行性注 ，從此，CAP理論正式在學術上成為瞭分布式計算領域的公認定理，並深深地影響瞭分布式計算的發展。　　CAP理論告訴我們，一個分布式係統不可能同時滿足一緻性（C：Consistency）、可用性（A：Availability）和分區容錯性（P：Partition tolerance）這三個基本需求，最多隻能同時滿足其中的兩項。　　一緻性　　在分布式環境中，一緻性是指數據在多個副本之間是否能夠保持一緻的特性。在一緻性的需求下，當一個係統在數據一緻的狀態下執行更新操作後，應該保證係統的數據仍然處於一緻的狀態。　　對於一個將數據副本分布在不同分布式節點上的係統來說，如果對第一個節點的數據進行瞭更新操作並且更新成功後，卻沒有使得第二個節點上的數據得到相應的更新，於是在對第二個節點的數據進行讀取操作時，獲取的依然是老數據（或稱為髒數據），這就是典型的分布式數據不一緻情況。在分布式係統中，如果能夠做到針對一個數據項的更新操作執行成功後，所有的用戶都可以讀取到其最新的值，那麼這樣的係統就被認為具有強一緻性（或嚴格的一緻性）。　　可用性　　可用性是指係統提供的服務必須一直處於可用的狀態，對於用戶的每一個操作請求總是能夠在有限的時間內返迴結果。這裏我們重點看下“有限的時間內”和“返迴結果”。　　“有限的時間內”是指，對於用戶的一個操作請求，係統必須能夠在指定的時間（即響應時間）內返迴對應的處理結果，如果超過瞭這個時間範圍，那麼係統就被認為是不可用的。另外，“有限的時間內”是一個在係統設計之初就設定好的係統運行指標，通常不同的係統之間會有很大的不同。比如說，對於一個在綫搜索引擎來說，通常在0.5秒內需要給齣用戶搜索關鍵詞對應的檢索結果。以Google為例，搜索“分布式”這一關鍵詞，Google能夠在0.3秒左右的時間，返迴大約上韆萬條檢索結果。而對於一個麵嚮HIVE的海量數據查詢平颱來說，正常的一次數據檢索時間可能在20秒到30秒之間，而如果是一個時間跨度較大的數據內容查詢，“有限的時間”有時候甚至會長達幾分鍾。　　從上麵的例子中，我們可以看齣，用戶對於一個係統的請求響應時間的期望值不盡相同。但是，無論係統之間的差異有多大，唯一相同的一點就是對於用戶請求，係統必須存在一個閤理的響應時間，否則用戶便會對係統感到失望。　　“返迴結果”是可用性的另一個非常重要的指標，它要求係統在完成對用戶請求的處理後，返迴一個正常的響應結果。正常的響應結果通常能夠明確地反映齣對請求的處理結果，即成功或失敗，而不是一個讓用戶感到睏惑的返迴結果。　　讓我們再來看看上麵提到的在綫搜索引擎的例子，如果用戶輸入指定的搜索關鍵詞後，返迴的結果是一個係統錯誤，通常類似於“OutOfMemoryError”或“System Has Crashed”等提示語，那麼我們認為此時係統是不可用的。　　分區容錯性　　分區容錯性約束瞭一個分布式係統需要具有如下特性：分布式係統在遇到任何網絡分區故障的時候，仍然需要能夠保證對外提供滿足一緻性和可用性的服務，除非是整個網絡環境都發生瞭故障。　　網絡分區是指在分布式係統中，不同的節點分布在不同的子網絡（機房或異地網絡等）中，由於一些特殊的原因導緻這些子網絡之間齣現網絡不連通的狀況，但各個子網絡的內部網絡是正常的，從而導緻整個係統的網絡環境被切分成瞭若乾個孤立的區域。需要注意的是，組成一個分布式係統的每個節點的加入與退齣都可以看作是一個特殊的網絡分區。　　以上就是對CAP定理中一緻性、可用性和分區容錯性的講解，通常使用圖1-2所示的示意圖來錶示CAP定理。　　既然在上文中我們提到，一個分布式係統無法同時滿足上述三個需求，而隻能滿足其中的兩項，因此在進行對CAP定理的應用時，我們就需要拋棄其中的一項，錶1-2所示是拋棄CAP定理中任意一項特性的場景說明。　　圖1-2．CAP定理示意圖　　錶1-2．CAP定理應用　　放棄CAP定理 說明　　放棄P 如果希望能夠避免係統齣現分區容錯性問題，一種較為簡單的做法是將所有的數據（或者僅僅是那些與事務相關的數據）都放在一個分布式節點上。這樣的做法雖然無法100%地保證係統不會齣錯，但至少不會碰到由於網絡分區帶來的負麵影響。但同時需要注意的是，放棄P的同時也就意味著放棄瞭係統的可擴展性　　放棄A 相對於放棄“分區容錯性”來說，放棄可用性則正好相反，其做法是一旦係統遇到網絡分區或其他故障時，那麼受到影響的服務需要等待一定的時間，因此在等待期間係統無法對外提供正常的服務，即不可用　　放棄C 這裏所說的放棄一緻性，並不是完全不需要數據一緻性，如果真是這樣的話，那麼係統的數據都是沒有意義的，整個係統也是沒有價值的。　　事實上，放棄一緻性指的是放棄數據的強一緻性，而保留數據的最終一緻性。這樣的係統無法保證數據保持實時的一緻性，但是能夠承諾的是，數據最終會達到一個一緻的狀態。這就引入瞭一個時間窗口的概念，具體多久能夠達到數據一緻取決於係統的設計，主要包括數據副本在不同節點之間的復製時間長短　　從CAP定理中我們可以看齣，一個分布式係統不可能同時滿足一緻性、可用性和分區容錯性這三個需求。另一方麵，需要明確的一點是，對於一個分布式係統而言，分區容錯性可以說是一個最基本的要求。為什麼這樣說，其實很簡單，因為既然是一個分布式係統，那麼分布式係統中的組件必然需要被部署到不同的節點，否則也就無所謂分布式係統瞭，因此必然齣現子網絡。而對於分布式係統而言，網絡問題又是一個必定會齣現的異常情況，因此分區容錯性也就成為瞭一個分布式係統必然需要麵對和解決的問題。因此係統架構設計師往往需要把精力花在如何根據業務特點在C（一緻性）和A（可用性）之間尋求平衡。　　BASE理論　　BASE是Basically Available（基本可用）、Soft state（軟狀態）和Eventually consistent（最終一緻性）三個短語的簡寫，是由來自eBay的架構師Dan Pritchett在其文章BASE： An Acid Alternative注 中第一次明確提齣的。BASE是對CAP中一緻性和可用性權衡的結果，其來源於對大規模互聯網係統分布式實踐的總結，是基於CAP定理逐步演化而來的，其核心思想是即使無法做到強一緻性（Strong consistency），但每個應用都可以根據自身的業務特點，采用適當的方式來使係統達到最終一緻性（Eventual consistency）。接下來我們著重對BASE中的三要素進行詳細講解。　　基本可用　　基本可用是指分布式係統在齣現不可預知故障的時候，允許損失部分可用性——但請注意，這絕不等價於係統不可用。以下兩個就是“基本可用”的典型例子。　　響應時間上的損失：正常情況下，一個在綫搜索引擎需要在0.5秒之內返迴給用戶相應的查詢結果，但由於齣現故障（比如係統部分機房發生斷電或斷網故障），查詢結果的響應時間增加到瞭1～2秒。　　功能上的損失：正常情況下，在一個電子商務網站上進行購物，消費者幾乎能夠順利地完成每一筆訂單，但是在一些節日大促購物高峰的時候，由於消費者的購物行為激增，為瞭保護購物係統的穩定性，部分消費者可能會被引導到一個降級頁麵。　　弱狀態　　弱狀態也稱為軟狀態，和硬狀態相對，是指允許係統中的數據存在中間狀態，並認為該中間狀態的存在不會影響係統的整體可用性，即允許係統在不同節點的數據副本之間進行數據同步的過程存在延時。　　最終一緻性　　最終一緻性強調的是係統中所有的數據副本，在經過一段時間的同步後，最終能夠達到一個一緻的狀態。因此，最終一緻性的本質是需要係統保證最終數據能夠達到一緻，而不需要實時保證係統數據的強一緻性。　　亞馬遜首席技術官Werner Vogels在於2008年發錶的一篇經典文章Eventually Consistent-　　Revisited中，對最終一緻性進行瞭非常詳細的介紹。他認為最終一緻性是一種特殊的弱一緻性：係統能夠保證在沒有其他新的更新操作的情況下，數據最終一定能夠達到一緻的狀態，因此所有客戶端對係統的數據訪問都能夠獲取到最新的值。同時，在沒有發生故障的前提下，數據達到一緻狀態的時間延遲，取決於網絡延遲、係統負載和數據復製方案設計等因素。　　在實際工程實踐中，最終一緻性存在以下五類主要變種。　　因果一緻性（Causal consistency）　　因果一緻性是指，如果進程A在更新完某個數據項後通知瞭進程B，那麼進程B之後對該數據項的訪問都應該能夠獲取到進程A更新後的最新值，並且如果進程B要對該數據項進行更新操作的話，務必基於進程A更新後的最新值，即不能發生丟失更新情況。與此同時，與進程A無因果關係的進程C的數據訪問則沒有這樣的限製。　　讀己之所寫（Read your writes）　　讀己之所寫是指，進程A更新一個數據項之後，它自己總是能夠訪問到更新過的最新值，而不會看到舊值。也就是說，對於單個數據獲取者來說，其讀取到的數據，一定不會比自己上次寫入的值舊。因此，讀己之所寫也可以看作是一種特殊的因果一緻性。　　會話一緻性（Session consistency）　　會話一緻性將對係統數據的訪問過程框定在瞭一個會話當中：係統能保證在同一個有效的會話中實現“讀己之所寫”的一緻性，也就是說，執行更能操作之後，客戶端能夠在同一個會話中始終讀取到該數據項的最新值。　　單調讀一緻性（Monotonic read consistency）　　單調讀一緻性是指如果一個進程從係統中讀取齣一個數據項的某個值後，那麼係統對於該進程後續的任何數據訪問都不應該返迴更舊的值。　　單調寫一緻性（Monotonic write consistency）　　單調寫一緻性是指，一個係統需要能夠保證來自同一個進程的寫操作被順序地執行。　　以上就是最終一緻性的五類常見的變種，在實際係統實踐中，可以將其中的若乾個變種互相結閤起來，以構建一個具有最終一緻性特性的分布式係統。事實上，最終一緻性並不是隻有那些大型分布式係統纔涉及的特性，許多現代的關係型數據庫都采用瞭最終一緻性模型。在現代關係型數據庫中，大多都會采用同步和異步方式來實現主備數據復製技術。在同步方式中，數據的復製過程通常是更新事務的一部分，因此在事務完成後，主備數據庫的數據就會達到一緻。而在異步方式中，備庫的更新往往會存在延時，這取決於事務日誌在主備數據庫之間傳輸的時間長短，如果傳輸時間過長或者甚至在日誌傳輸過程中齣現異常導緻無法及時將事務應用到備庫上，那麼很顯然，從備庫中讀取的數據將是舊的，因此就齣現瞭數據不一緻的情況。當然，無論是采用多次重試還是人為數據訂正，關係型數據庫還是能夠保證最終數據達到一緻——這就是係統提供最終一緻性保證的經典案例。　　總的來說，BASE理論麵嚮的是大型高可用可擴展的分布式係統，和傳統事務的ACID特性是相反的，它完全不同於ACID的強一緻性模型，而是提齣通過犧牲強一緻性來獲得可用性，並允許數據在一段時間內是不一緻的，但最終達到一緻狀態。但同時，在實際的分布式場景中，不同業務單元和組件對數據一緻性的要求是不同的，因此在具體的分布式係統架構設計過程中，ACID特性與BASE理論往往又會結閤在一起使用。　　小結　　計算機係統從集中式嚮分布式的變革伴隨著包括分布式網絡、分布式事務和分布式數據一緻性等在內的一係列問題與挑戰，同時也催生瞭一大批諸如ACID、CAP和BASE等經典理論的快速發展。　　本章由計算機係統從集中式嚮分布式發展的過程展開，圍繞在分布式架構發展過程中碰到的一係列問題，結閤ACID、CAP和BASE等分布式事務與一緻性方麵的經典理論，嚮讀者介紹瞭分布式架構。　　……

前言/序言

　　問題的提齣

　　在計算機科學領域，分布式一緻性問題是一個相當重要，且被廣泛探索與論證的問題，通常存在於諸如分布式文件係統、緩存係統和數據庫等大型分布式存儲係統中。

　　什麼是分布式一緻性？分布式一緻性分為哪些類型？分布式係統達到一緻性後將會是一個什麼樣的狀態？如果失去瞭一緻性約束，分布式係統是否還可以依賴？如果一味地追求一緻性，對係統的整體架構和性能又有多大影響？這一係列的問題，似乎都沒有一個嚴格意義上準確的定義和答案。

　　終端用戶

　　IT技術的發展，讓我們受益無窮，從日常生活的超市收銀，到高端精細的火箭發射，現代社會中幾乎所有行業，都離不開計算機技術的支持。

　　盡管計算機工程師們創造齣瞭很多高科技的計算機産品來解決我們日常碰到的問題，但用戶隻會傾嚮於選擇一些易用、好用的産品，那些難以使用的計算機産品最終都會被淘汰——這種易用性，其實就是用戶體驗的一部分。

　　計算機産品的用戶體驗，可以分為便捷性、安全性和穩定性等方麵。在本書中，我們主要討論的是用戶在使用計算機産品過程中遇到的那些和一緻性有關的問題。在此之前，我們首先來看一下計算機産品的終端用戶是誰，他們的需求又是什麼。

　　火車站售票

　　假如說我們的終端用戶是一位經常做火車的旅行傢，通常他是去車站的售票處購買車票，然後拿著車票去檢票口，再坐上火車，開始一段美好的旅行——一切似乎都是那麼和諧。想象一下，如果他選擇的目的地是杭州，而某一趟開往杭州的火車隻剩下最後一張車票瞭，可能在同一時刻，不同售票窗口的另一位乘客也購買瞭同一張車票。假如說售票係統沒有進行一緻性保障，兩人都購票成功瞭。而在檢票口檢票的時候，其中一位乘客會被告知他的車票無效——當然，現代的中國鐵路售票係統已經很少齣現這樣的問題瞭，但在這個例子中，我們可以看齣，終端用戶對於我們的係統的需求非常簡單：

　　“請售票給我，如果沒有餘票瞭，請在售票的時候就告訴我票是無效票的。”

　　這就對購票係統提齣瞭嚴格的一緻性要求——係統的數據（在本例中指的就是那趟開往杭州的火車的餘票數），無論在哪個售票窗口，每時每刻都必須是準確無誤的！

　　銀行轉賬

　　假如說我們的終端用戶是一名剛畢業的大學生，通常在拿到第一個月工資之後，都會選擇嚮傢裏匯款。當他來到銀行櫃颱，完成轉賬操作後，銀行的櫃颱服務員會友善地提醒他：“您的轉賬將在N個工作日後到賬！”此時這名畢業生有一些沮喪，會對那名櫃颱服務員叮囑：“好吧，多久沒關係，錢不要少就行瞭！”——這也成為瞭幾乎所有的用戶對於現代銀行係統最基本的需求。

　　網上購物

　　假如說我們的終端用戶是一名網上購物狂，當他看到一件庫存量為5的心儀商品，會迅速地確認購買，寫下收貨地址，然後下單——然而，在下單的那個瞬間，係統可能會告知該用戶：“庫存量不足！”此時，絕大部分的消費者往往都會抱怨自己動作太慢，使得心愛的商品被其他人搶走瞭！

　　但其實有過網購係統開發經驗的工程師一定明白，在商品詳情頁麵上顯示的那個庫存量，通常不是該商品的真實庫存量，隻有在真正下單購買的時候，係統纔會檢查該商品的真實庫存量。但是，誰在意呢？

　　在上麵三個例子中，相信讀者一定已經看齣來瞭，我們的終端用戶在使用不同的計算機産品時對於數據一緻性的需求是不一樣的：

　　有些係統，既要快速地響應用戶，同時還要保證係統的數據對於任意客戶端都是真實可靠的，就像火車站的售票係統。

　　還有些係統，需要為用戶保證絕對可靠的數據安全，雖然在數據一緻性上存在延時，但最終務必保證嚴格的一緻，就像銀行的轉賬係統。

　　另外的一些係統，雖然嚮用戶展示瞭一些可以說是“錯誤”的數據，但是在整個係統使用過程中，一定會在某一個流程上對係統數據進行準確無誤的檢查，從而避免用戶發生不必要的損失，就像網購係統。

　　更新的並發性

　　在計算機發展的早期階段，受到底層硬件技術的製約，同時也是由於人們對於計算機係統的實際使用需求比較簡單，因此很多上層的應用程序架構都是單綫程模型的。以C語言為例，其誕生於上世紀70年代，當時幾乎所有使用C語言開發的應用程序都是單綫程的。從現在來看，單綫程應用程序雖然在運行效率上無法和後來的多綫程應用程序相比，但是在編程模型上相對簡單，因此能夠避免多綫程程序中齣現的不少並發問題。

　　隨著計算機底層硬件技術和現代操作係統的不斷發展，多綫程技術開始被越來越多地引入到計算機編程模型之中，並對現代計算機應用程序的整體架構起到瞭至關重要的作用。

　　多綫程的引入，為應用程序帶來性能上的卓越提升，同時也帶來瞭一個最大的副作用，那就是並發。《深入理解計算機係統》一書對並發進行瞭如下定義：如果邏輯控製流在時間上重疊，那麼它們就是並發的。這裏提到的邏輯控製流，通俗地講，就是一次程序操作，比如讀取或更新內存中變量的值。

　　在本書後麵的討論中，我們提到的“並發”都特指更新操作的並發，即有多個綫程同時更新內存中變量的值——我們將這一現象稱為更新的並發性。

　　分布式一緻性問題

　　在分布式係統中另一個需要解決的重要問題就是數據的復製。在我們日常的開發經驗中，相信很多開發人員都碰到過這樣的問題：假設客戶端C1將係統中的一個值K由V1更新為V2，但客戶端C2無法立即讀取到K的最新值，需要在一段時間之後纔能讀取到。讀者可能也已經猜到瞭，上麵這個例子就是常見的數據庫之間復製的延時問題。

　　分布式係統對於數據的復製需求一般都來自於以下兩個原因。

　　為瞭增加係統的可用性，以防止單點故障引起的係統不可用。

　　提高係統的整體性能，通過負載均衡技術，能夠讓分布在不同地方的數據副本都能夠為用戶提供服務。

　　數據復製在可用性和性能方麵給分布式係統帶來的巨大好處是不言而喻的，然而數據復製所帶來的一緻性挑戰，也是每一個係統研發人員不得不麵對的。

　　所謂的分布式一緻性問題，是指在分布式環境中引入數據復製機製後，不同數據節點間可能齣現的，並無法依靠計算機應用程序自身解決的數據不一緻情況。簡單地講，數據一緻性就是指在對一個副本數據進行更新的同時，必須確保也能夠更新其他的副本，否則不同副本之間的數據將不再一緻。

　　那怎麼來解決這個問題呢？順著上麵提到的復製延時問題，很快就有人想到瞭一種解決辦法，那就是：

　　“既然是由於延時引起的問題，那我可以將寫入的動作阻塞，直到數據復製完成後，纔完成寫入動作。”

　　沒錯，這似乎能解決問題，而且有一些係統的架構也確實直接使用瞭這個思路。但這個思路在解決一緻性問題的同時，又帶來瞭新的問題：寫入的性能。如果你的應用場景有非常多的寫請求，那麼使用這個思路之後，後續的寫請求都將會阻塞在前一個請求的寫操作上，導緻係統整理性能急劇下降。

　　總的來講，我們無法找到一種能夠滿足分布式係統所有係統屬性的分布式一緻性解決方案。因此，如何既保證數據的一緻性，同時又不影響係統運行的性能，是每一個分布式係統都需要重點考慮和權衡的。於是，一緻性級彆由此誕生。

　　強一緻性

　　這種一緻性級彆是最符閤用戶直覺的，它要求係統寫入什麼，讀齣來的也會是什麼，用戶體驗好，但實現起來往往對係統的性能影響比較大。

　　弱一緻性

　　這種一緻性級彆約束瞭係統在寫入成功後，不承諾立即可以讀到寫入的值，也不具體承諾多久之後數據能夠達到一緻，但會盡可能地保證到某個時間級彆（比如秒級彆）後，數據能夠達到一緻狀態。弱一緻性還可以再進行細分：

　　會話一緻性：該一緻性級彆隻保證對於寫入的值，在同一個客戶端會話中可以讀到一緻的值，但其他的會話不能保證。

　　用戶一緻性：該一緻性級彆隻保證對於寫入的值，在同一個用戶中可以讀到一緻的值，但其他用戶不能保證。

　　最終一緻性

　　最終一緻性是弱一緻性的一個特例，係統會保證在一定時間內，能夠達到一個數據一緻的狀態。這裏之所以將最終一緻性單獨提齣來，是因為它是弱一緻性中非常重要的一種一緻性模型，也是業界在大型分布式係統的數據一緻性上比較推崇的模型。

　　本書將會從分布式一緻性的理論齣發，嚮讀者講解幾種典型的分布式一緻性協議是如何解決分布式一緻性問題的。之後，本書則會深入介紹分布式一緻性問題的工業解決方案——ZooKeeper，並著重嚮讀者展示這一分布式協調框架的使用方法、內部實現以及運維技巧。

　　緻謝

　　首先要感謝現在的部門老大蔣江偉先生。第一次接觸蔣江偉是在2011年，當時參加瞭他的一個講座“淘寶前颱係統優化實踐——吞吐量優化”，對其中關於“編寫GC友好代碼”的內容有不解之處，於是私下請教。他耐心的講解令我至今記憶猶新。兩年前，他全麵負責中間件團隊之後，給予瞭我更大的幫助和鼓勵，使我得到瞭極大的進步，真的非常感謝。本書的問世，離不開他的推薦。也正是這一份寫作的責任感，讓我有決心和毅力來對整個ZooKeeper內容進行瞭一次全麵的整理。在這裏，衷心祝福蔣江偉先生帶領中間件團隊走嚮新的高度。

　　其次，本書的寫作，離不開各位小夥伴們的支持和幫助，他們是各領域的資深專傢，我嚮他們徵集瞭很多有營養的內容。在這裏，按照章節順序，依次錶示感謝：許澤彬參與瞭“問題提齣”的寫作；侯前明對Paxos算法的前世今生進行的整理；段培樂對晦澀的Paxos協議進行瞭細緻的講解；薑宇嚮我提供瞭他對於分布式事務的見解；徐偉辰參與瞭分布式鎖服務Chubby相關的寫作；葉成旭提供瞭他在上傢公司時對Hypertable的學習和研究成果；高偉細緻地嚮我展示瞭Curator這一ZooKeeper客戶端的使用；陳傑提供瞭他在“自動化的DNS服務”場景中的經驗總結；曹龍參與瞭Hadoop相關內容的寫作；鄧明鑒則貢獻瞭他對HBase的深刻見解；作為産品的開源負責人，莊曉丹和王強提供瞭對消息中間件Metamorphosis技術架構的講解；李鼎則嚮我全麵展示瞭RPC服務框架Dubbo的技術細節；樓江航嚮我提供瞭Canal和Otter這兩個分布式産品中的ZooKeeper應用場景；李雨前、柳明和溫朝凱則一起寫瞭終搜在産品演進過程中對ZooKeeper的使用和改進；封仲淹參與瞭對其自主産品JStorm的技術剖析……是你們一遍又一遍地對內容進行修改，纔使得本書內容更為豐滿。

　　另外，也要感謝溫文鎏、王林、許澤彬、高偉和段培樂等人對全書的審閱，正是你們提齣的寶貴建議，對完善本書提供瞭非常大的幫助。

　　感謝現在的同事陸學慧先生，從2013年下半年開始，他全麵接手對ZooKeeper的開發和運維，在他身上感受到的專業和創新精神讓我備受鼓舞。

　　另外，感謝我的第一個主管馬震先生，是他的幫助為我指引瞭方嚮，讓我有機會進入ZooKeeper的世界，並負責這個産品在公司的發展。盡管由於業務調整，馬震先生已經轉崗到其他部門，但依然由衷祝福他工作順利。

　　還要感謝我的同事，阿裏巴巴店鋪平颱的侯前明先生。本來該書作者應該是我們兩個人，但是由於期間他的傢庭又增加瞭一個小生命，導緻其不得不中途退齣。從本書的選題到寫作大綱的製定，他都傾注瞭不少心血，相信如果有他一起創作，本書內容會更加豐滿、深刻。這裏錶達遺憾的同時，也嚮這位兩個孩子的父親送去祝福，祝願他生活美滿。

　　感謝本書的責任編輯劉蕓女士，是她反復審稿和編排，纔能讓本書的內容趨於完美。

　　感謝本書的封麵設計吳海燕女士，她的努力已經無需言錶，在技術書上的這一前衛、極富視覺衝擊力的封麵設計，深深震撼到瞭我，也希望讀者朋友們能夠喜歡。

　　尤其感謝本書的策劃編輯張春雨先生。作為一個南方人，我很少有機會和那些有著一口北方腔的朋友交談，第一次接到張春雨先生電話的時候，我纔真正領略瞭北京腔，也正是他的邀請，纔能讓我有機會進行本書的撰寫，同時在前後將近1年半的漫長寫作過程中，也是他的幫助和鼓勵，纔讓我堅持完成並不斷完善本書的內容。在這裏，也衷心祝願張春雨先生事業更上一層樓。

　　最後，還有我的父母，在過去的1年時間裏，多次放假沒有迴傢，盡管父母一直鼓勵我專注工作，專注於自己的事業，但我深知他們內心對兒子的牽掛，在這裏也深深地嚮他們道一聲：“謝謝”，也謹以此書獻給我最親愛的爸爸媽媽。

　　倪超

　　2014年12月於杭州淘寶城

評分☆☆☆☆☆

喜歡，贊贊贊，美美美，好好好，哈哈哈

評分☆☆☆☆☆

包裝好，紙質也不錯，質量不錯

評分☆☆☆☆☆

東西不錯！東西不錯！

評分☆☆☆☆☆

很滿意，書很好，物流很快

評分☆☆☆☆☆

基礎很有用，看瞭有幫助

評分☆☆☆☆☆

書還沒有看完，前後過來評價

評分☆☆☆☆☆

這本書寫的還不錯，用心瞭，值得擁有。

評分☆☆☆☆☆

經典技術書籍，活動買很劃算

評分☆☆☆☆☆

東西很好 物流很快 態度很好