今天，對于在IT行業(yè)從事技術(shù)工作的人，無論是工程師、架構(gòu)師還是管理者，也無論從事的工作是否與分布式相關(guān)，都應(yīng)該了解分布式技術(shù)，因為總有一天，你會遇到它、接觸它、使用它、理解它、完善它。
然而，分布式技術(shù)涉及的方面（存儲、計算、框架、中間件等）是如此之多，且迄今為止尚未見到一本書對其進(jìn)行概括和梳理，要想對分布式技術(shù)有全面的了解，特別是對初學(xué)者而言，何其難哉！
如今初學(xué)者再不用學(xué)習(xí)分布式技術(shù)而發(fā)愁了，剛好有這樣一本適用初學(xué)者的《分布式系統(tǒng)設(shè)計實踐》出版，作者李慶旭 。
本書試圖對近年來涌現(xiàn)出的各種主流分布式技術(shù)做一個簡要介紹，以使不太熟悉這個領(lǐng)域的讀者能了解其概貌、原理和根源。
本書共分為以下6部分。
第一部分對典型的分布式系統(tǒng)的組成及其中每個組件的功能進(jìn)行簡要介紹，以使讀者對分布式系統(tǒng)有一個總體了解。第二部分介紹分布式系統(tǒng)的前端經(jīng)常使用的Web框架、反向代理及負(fù)載均衡技術(shù)。
第三部分對分布式系統(tǒng)中經(jīng)常使用的各種中間件技術(shù)逐一進(jìn)行介紹，包括分布式同步服務(wù)中間件、關(guān)系型數(shù)據(jù)庫訪問中間件、分布式服務(wù)調(diào)用中間件、分布式消息服務(wù)中間件和分布式跟蹤服務(wù)中間件。
第四部分介紹分布式文件系統(tǒng)、各種NoSQL數(shù)據(jù)庫技術(shù)（基于鍵值對的NoSQL技術(shù)、基于列的NoSQL技術(shù)、基于文檔的NoSQL技術(shù)、基于圖的NoSQL技術(shù)）和NewSQL數(shù)據(jù)庫系統(tǒng)。
第五部分對業(yè)界在構(gòu)建大型分布式系統(tǒng)的過程中的主要經(jīng)驗加以總結(jié)，使后來者避免重蹈覆轍。
第六部分介紹業(yè)界幾個知名的大型分布式系統(tǒng)的主要設(shè)計思想和架構(gòu)，包括谷歌搜索系統(tǒng)、淘寶網(wǎng)、阿里云和領(lǐng)英的社交應(yīng)用。此外，還會探討和思考分布式系統(tǒng)實現(xiàn)中的一些問題。
第一部分 分布式系統(tǒng)概述 免費
第1章 分布式系統(tǒng)概述 免費
第二部分 分布式系統(tǒng)的前端構(gòu)造技術(shù) 免費
第2章 Web框架的實現(xiàn)原理
第3章 反向代理與負(fù)載均衡
第三部分 分布式中間件
第4章 分布式同步服務(wù)中間件
第5章 關(guān)系型數(shù)據(jù)庫訪問中間件
第6章 分布式服務(wù)調(diào)用中間件
第7章 分布式消息服務(wù)中間件
第8章 分布式跟蹤服務(wù)中間件
第四部分 分布式存儲技術(shù)
第9章 分布式文件系統(tǒng)
第10章 基于鍵值對的NoSQL數(shù)據(jù)庫
第11章 基于列的NoSQL數(shù)據(jù)庫
第12章 基于文檔的NoSQL數(shù)據(jù)庫
第13章 其他NoSQL數(shù)據(jù)庫
第14章 NewSQL數(shù)據(jù)庫
第五部分 分布式系統(tǒng)的構(gòu)建思想
第15章 云化
第16章 分布式系統(tǒng)的構(gòu)建思想
第六部分 大型分布式系統(tǒng)案例研究及分析
第17章 大型分布式系統(tǒng)案例研究
第18章 關(guān)于分布式系統(tǒng)設(shè)計的思考
本書適合業(yè)界的架構(gòu)師、工程師、項目經(jīng)理，以及大中專院校的高年級本科生和研究生使用和參考。
樣章試讀：
1999年8月6日，CNN報道了一起eBay網(wǎng)站的事故：從7:30開始，整個網(wǎng)站崩潰，一直持續(xù)了9個多小時。下午5:30后，技術(shù)人員開始進(jìn)行系統(tǒng)恢復(fù)，但搜索功能依然不能使用。
2011年4月21日至22日，亞馬遜EC2（Elastic Computer Cloud）服務(wù)出現(xiàn)大面積事故，導(dǎo)致數(shù)以千計的初創(chuàng)公司受到影響，而且造成大約11小時的歷史數(shù)據(jù)永久性丟失。
2013年4月27日，《大掌門》游戲的開發(fā)商玩蟹科技CEO葉凱在微博上吐槽，“我們在阿里云上用了20多臺機器。半年時間，出現(xiàn)過1次所有機器全部斷電，2次多個硬盤突然只讀，3次硬盤I/O突然變滿……”。
2013年12月28日，春運第一天，鐵道部首次推出了網(wǎng)上訂票系統(tǒng)，但很快就出現(xiàn)許多用戶無法訪問、響應(yīng)緩慢甚至串號等事故。
2017年9月17日，谷歌的網(wǎng)盤服務(wù)Drive出現(xiàn)故障，成千上萬用戶受到影響。
上面的這幾起事故，當(dāng)時都鬧得沸沸揚揚，不僅給受影響的用戶帶來了很大的損失，也極大地影響了廠商的形象。事實上，幾乎每一家互聯(lián)網(wǎng)公司的后臺系統(tǒng)都曾經(jīng)不止一次地經(jīng)歷過這樣或那樣的尷尬時刻?？梢赃@樣說，幾乎每一家互聯(lián)網(wǎng)公司的后臺架構(gòu)都是在發(fā)現(xiàn)問題、解決問題的循環(huán)中發(fā)展起來的。
即便是執(zhí)分布式系統(tǒng)技術(shù)牛耳的谷歌，在2017年9月，也出現(xiàn)過分布式系統(tǒng)的故障。可見，開發(fā)并維護(hù)一個成功的分布式系統(tǒng)是多么不易！
最早得到廣泛應(yīng)用的分布式系統(tǒng)是誕生于20世紀(jì)70年代的以太網(wǎng)。盡管分布式系統(tǒng)存在的歷史已經(jīng)有近半個世紀(jì)，然而其大規(guī)模的發(fā)展和應(yīng)用則是2000年以后的事情。
21世紀(jì)以來，隨著雅虎、谷歌、亞馬遜、eBay、Facebook、Twitter等眾多互聯(lián)網(wǎng)公司的崛起，其用戶量以及要處理的數(shù)據(jù)量迅速增長，遠(yuǎn)遠(yuǎn)超過了傳統(tǒng)的計算機系統(tǒng)能夠處理的范圍，因此，以谷歌為代表的互聯(lián)網(wǎng)公司提出了許多新技術(shù)（如HDFS、Bigtable、MapReduce等）。以BAT為代表的中國互聯(lián)網(wǎng)公司，也在21世紀(jì)整體崛起，在初期借鑒美國公司技術(shù)的基礎(chǔ)上，他們也自行開發(fā)了許多新的技術(shù)（如淘寶的管理海量小文件的分布式存儲系統(tǒng)TFS、阿里巴巴開源的分布式調(diào)用框架Dubbo、阿里巴巴開源的數(shù)據(jù)庫中間件Cobar等）。
為了解決分布式系統(tǒng)中的各種各樣的問題，各大互聯(lián)網(wǎng)公司開發(fā)了各種各樣的技術(shù)，當(dāng)然，這也促進(jìn)了當(dāng)今分布式系統(tǒng)技術(shù)領(lǐng)域的飛速發(fā)展。為了存儲大量的網(wǎng)站索引，谷歌設(shè)計了GFS分布式文件存儲系統(tǒng)和基于列存儲的Bigtable NoSQL數(shù)據(jù)庫系統(tǒng)；為了計算PageRank算法中的頁面rank值，谷歌又設(shè)計了MapReduce分布式計算系統(tǒng)；為了方便其分布式系統(tǒng)中不同主機間的協(xié)調(diào)，谷歌還設(shè)計了Chubby分布式鎖系統(tǒng)；為了解決不同語言實現(xiàn)的組件間的通信問題，F(xiàn)acebook設(shè)計了Thrift；為了解決大量消息的快速傳遞問題，領(lǐng)英設(shè)計了Kafka……這個列表可以很長很長。
為了“壓榨”分布式系統(tǒng)中每個組件的性能，人們已經(jīng)不再僅僅滿足于在程序庫（如網(wǎng)絡(luò)編程庫Netty、內(nèi)存管理庫TCMalloc等）、程序框架（如Spring）等“略顯淺薄”的地方提高，而是已經(jīng)滲透到了硬件（如谷歌為其計算中心專門設(shè)計了計算機）、網(wǎng)絡(luò)（如SDN）、操作系統(tǒng)（如各大互聯(lián)網(wǎng)公司定制的Linux內(nèi)核）、語言（如谷歌設(shè)計的Go語言）、數(shù)據(jù)庫系統(tǒng)（如各種NoSQL系統(tǒng)）、算法（如人工智能領(lǐng)域的突飛猛進(jìn)）等各種計算機基礎(chǔ)領(lǐng)域。
毫無疑問，我們處于計算機技術(shù)發(fā)展最為迅猛的時代。在這個如火如荼的時代里，許多塵封多年的計算機技術(shù)（如人工智能、分布式系統(tǒng)、移動計算、虛擬計算等），一改往日不溫不火的模樣，在互聯(lián)網(wǎng)這片廣袤的土地上如日中天，發(fā)展迅速。
今天的計算機領(lǐng)域，已經(jīng)與20年前大為不同。20年前，只需要對操作系統(tǒng)、數(shù)據(jù)庫、網(wǎng)絡(luò)、編譯等領(lǐng)域有深刻的理解，再熟練掌握幾門計算機語言，了解一些常見的軟件架構(gòu)（客戶服務(wù)器架構(gòu)、管道架構(gòu)、分層架構(gòu)等）和軟件工程（主要是瀑布模型）的知識，基本上就能勝任大多數(shù)軟件開發(fā)工作了。而今天，僅了解這些基礎(chǔ)知識已經(jīng)遠(yuǎn)遠(yuǎn)不夠，因為在近20年內(nèi)，人類創(chuàng)造了太多的新技術(shù)，而這些新技術(shù)又大都起源并服務(wù)于分布式計算領(lǐng)域。
1.1 分布式系統(tǒng)的組成
一個大型的分布式系統(tǒng)雖然非常復(fù)雜，但其設(shè)計目標(biāo)卻往往是非常簡單的，例如，京東和淘寶這樣的電商，其設(shè)計目標(biāo)是賣東西；谷歌和百度這樣的搜索引擎，其設(shè)計目標(biāo)是幫助大家在網(wǎng)上找相關(guān)的內(nèi)容；Facebook和微信這樣的社交應(yīng)用，其設(shè)計目標(biāo)是方便大家相互聯(lián)系并分享自己生活中的點點滴滴。
如前文所述，之所以需要有分布式系統(tǒng)，最根本的原因還是單機的計算和存儲能力不能滿足系統(tǒng)的需要。但要把成百上千臺計算機組織成一個有機的系統(tǒng)，絕非易事。在人類社會中，其實也一樣，找到1000個人容易，但要把這1000個人組織成一只能戰(zhàn)斗的軍隊可就沒那么簡單了。
一個典型的分布式系統(tǒng)如圖1-1所示。
分布式系統(tǒng)大都有一個Web前端，用戶可以通過瀏覽器隨時隨地訪問，當(dāng)然，前端也可以是運行在Windows/Linux上的桌面程序或者運行在手機上的應(yīng)用。
分布式系統(tǒng)還要有后端支撐。分布式系統(tǒng)的后端大都是基于Linux的集群[1]。之所以采用Linux，一是因為開源操作系統(tǒng)成本低，二是因為開源軟件可以定制。
就像人類社會需要有一定的組織和管理一樣，為了組成一個集群，在單機的操作系統(tǒng)之上，還需要集群管理系統(tǒng)。在集群管理系統(tǒng)中，一個非常重要的組件是分布式協(xié)調(diào)組件，用來協(xié)調(diào)不同機器之間的工作。這些協(xié)調(diào)系統(tǒng)大都基于一些著名的分布式一致性協(xié)議（如Paxos、Raft等）。有些超大型的后端還擁有專門的集群操作系統(tǒng)，這些系統(tǒng)不僅有分布式協(xié)調(diào)功能，還有資源的分配與管理功能。
為了滿足大規(guī)模數(shù)據(jù)的存儲需要[2]，需要有能夠存儲海量數(shù)據(jù)的后端存儲系統(tǒng)。
為了滿足大規(guī)模數(shù)據(jù)的計算需要[3]，還需要有能夠分析海量數(shù)據(jù)的后端計算系統(tǒng)。
圖1-1 一個典型的分布式系統(tǒng)
在分布式系統(tǒng)中，有很多共性的功能，例如能夠支持分庫分表的數(shù)據(jù)庫訪問中間件、用來異步化的消息中間件、用來開發(fā)不同組件的分布式系統(tǒng)調(diào)用中間件、用來監(jiān)控各個組件狀態(tài)的分布式跟蹤中間件等。事實上，前面所列舉的每一種中間件，也都是一個復(fù)雜的分布式系統(tǒng)。
本章下面的內(nèi)容先就后端最重要的分布式協(xié)調(diào)組件、后端存儲系統(tǒng)和后端計算系統(tǒng)做一個概要的介紹。
1.2 分布式協(xié)調(diào)組件
分布式系統(tǒng)之所以存在，最根本的原因是數(shù)據(jù)量或計算量超過了單機的處理能力，因此不得不求助于水平擴展[4]，而為了協(xié)調(diào)多個節(jié)點的動作，則不得不引入分布式協(xié)調(diào)組件。
在單機操作系統(tǒng)中，幾個相互合作的進(jìn)程（如生產(chǎn)者/消費者模型中的生產(chǎn)者進(jìn)程和消費者進(jìn)程），如果需要進(jìn)行協(xié)調(diào)，就得借助于一些進(jìn)程間通信機制，如共享內(nèi)存、信號量、事件等。分布式協(xié)調(diào)組件提供的功能，本質(zhì)上就是分布式環(huán)境中的進(jìn)程間通信機制。
也許，有人會覺得這有何難，用一個數(shù)據(jù)庫不就解決了嗎？如代碼清單1-1所示，將分布式鎖信息保存在一張數(shù)據(jù)庫表中（假如表名叫LOCK_TABLE），增加一個鎖就是向LOCK_TABLE表中添加一新行（假如該行ID為MYCLOCK1），要獲得該鎖，只需要將MYCLOCK1行的某個字段（如LOCK_STATUS）置為1；要釋放該鎖，只需要將此字段置為0。利用數(shù)據(jù)庫本身的事務(wù)支持，這個問題不就解決了嗎？
代碼清單1-1 利用數(shù)據(jù)庫實現(xiàn)分布式鎖
然而，事情遠(yuǎn)沒有那么簡單。在分布式環(huán)境中，節(jié)點/網(wǎng)絡(luò)故障為常態(tài)，如果采用代碼清單1-1所示的方案，假如數(shù)據(jù)庫所在的節(jié)點宕機了，整個系統(tǒng)就會陷入混亂。因此，這種有單點故障的方案肯定是不可取的。
分布式協(xié)調(diào)組件對外提供的是一種分布式同步服務(wù)。為了獲得健壯性，一個協(xié)調(diào)組件內(nèi)部也是由多個節(jié)點組成的，節(jié)點[5]之間通過一些分布式一致性協(xié)議（如Paxos、Raft）來協(xié)調(diào)彼此的狀態(tài)。如果一個節(jié)點崩潰了，其他節(jié)點就自動接管過來，繼續(xù)對外提供服務(wù)，好像什么都沒有發(fā)生過一樣。
另外，為了應(yīng)用程序的方便，分布式協(xié)調(diào)組件經(jīng)常還會允許在其上存放少量的信息（如主服務(wù)器的名稱），這些信息也是由分布式一致性協(xié)議來維護(hù)其一致性的。
1.3 分布式存儲系統(tǒng)
與單機系統(tǒng)類似，分布式系統(tǒng)的存儲也分為兩個層次：第一個層次是文件級的，即分布式文件系統(tǒng)，如GFS（Google File System）、HDFS（Hadoop Distributed File System）、TFS（Taobao File System）等；第二個層次是在文件系統(tǒng)之上的進(jìn)一步抽象，即數(shù)據(jù)庫系統(tǒng)。不過，分布式系統(tǒng)下的數(shù)據(jù)庫遠(yuǎn)比單機的關(guān)系型數(shù)據(jù)庫復(fù)雜，因為數(shù)據(jù)被存儲在多個節(jié)點上，如何保證其一致性就成了關(guān)鍵，所以，分布式系統(tǒng)下的數(shù)據(jù)庫采用的大都是最終一致性[6]，而非滿足ACID[7]屬性的強一致性。
由于對一致性支持的不同，傳統(tǒng)的ACID理論就不再適用了，于是，Eric Brewer提出了一種新的CAP[8]理論。CAP理論聽起來高大上，但實際上并沒有那么復(fù)雜。它的意思是，在分布式系統(tǒng)里，沒有辦法同時達(dá)到一致性、可用性和網(wǎng)絡(luò)分區(qū)可容忍性，只能在三者中擇其二。
不過，要注意CAP中的C和A與ACID中的C和A的含義是不同的（如表1-1所示），網(wǎng)絡(luò)分區(qū)可容忍性的含義較為晦澀，是指一個分布式系統(tǒng)中是否允許出現(xiàn)多個網(wǎng)絡(luò)分區(qū)。換言之，如果網(wǎng)絡(luò)斷了，一個系統(tǒng)中的多個節(jié)點被分成了多個孤島，這允許嗎？如果允許，就滿足網(wǎng)絡(luò)分區(qū)可容忍性，否則就不滿足。
表1-1 CAP與ACID中的C和A的不同
對于CAP理論，其實很好理解。我們可以想一想，如果需要滿足網(wǎng)絡(luò)分區(qū)可容忍性，即允許孤島的存在，那么當(dāng)孤島產(chǎn)生時，只能要么繼續(xù)提供服務(wù)（即滿足可用性），要么停止服務(wù)（即滿足一致性），其他的情況也類似。然而，在分布式系統(tǒng)中，由于孤島的不可避免性，因此實際的系統(tǒng)只能在一致性和可用性中選擇其一，即只能是滿足一致性和網(wǎng)絡(luò)分區(qū)可容忍性或者滿足可用性和網(wǎng)絡(luò)分區(qū)可容忍性的系統(tǒng)。
采用最終一致性的數(shù)據(jù)庫系統(tǒng)，統(tǒng)稱為NoSQL（Not only SQL）系統(tǒng)。根據(jù)數(shù)據(jù)模型的不同，NoSQL系統(tǒng)又分為以下幾大類：
基于鍵值對的（如Memcached、Redis等）；
基于列存儲的（如谷歌的Bigtable、Apache HBase、Apache Cassandra等）；
基于文檔的（如MongoDB、CouchDB等）；
基于圖的（如Neo4j、OrientDB等）。
近幾年，還涌現(xiàn)出一類稱為NewSQL的系統(tǒng)（如谷歌的Megastore、谷歌的Spanner、阿里巴巴的OceanBase和PingCAP TiDB），號稱既滿足關(guān)系型數(shù)據(jù)庫的ACID屬性，又可以如NoSQL系統(tǒng)那般水平伸縮。然而，這些系統(tǒng)本質(zhì)上還是滿足最終一致性的NoSQL系統(tǒng)，只不過，它們將可用性和一致性處理得非常好，在外界看來，似乎同時滿足了可用性和一致性，實則只是在實現(xiàn)上做了“手腳”，將不一致性“隱藏”起來，并將其“默默”地消化掉。
例如，谷歌Megastore將同一數(shù)據(jù)的不同分區(qū)存放在不同的數(shù)據(jù)中心中，在每個數(shù)據(jù)中心內(nèi)部，屬于同一個分區(qū)的數(shù)據(jù)存放在同一個Bigtable中。借助于Bigtable對單行數(shù)據(jù)讀寫的事務(wù)支持，Megastore支持同一個分區(qū)內(nèi)的ACID屬性，但對于跨分區(qū)（即跨數(shù)據(jù)中心）的事務(wù)，則通過兩階段提交實現(xiàn)，因此，也是最終一致的。
再如阿里巴巴的OceanBase，它將數(shù)據(jù)分為兩部分，一部分是較早的數(shù)據(jù)（稱為基準(zhǔn)數(shù)據(jù)），另一部分是最新的數(shù)據(jù)（稱為增量數(shù)據(jù)），基準(zhǔn)數(shù)據(jù)與增量數(shù)據(jù)分開存儲，讀寫請求都由一個專門的合并服務(wù)器（Merge Server）來處理。合并服務(wù)器解析用戶的SQL請求，然后生成相應(yīng)的命令發(fā)給存儲基準(zhǔn)數(shù)據(jù)和增量數(shù)據(jù)的服務(wù)器，再合并它們返回的結(jié)果；此外，后臺還定期將增量數(shù)據(jù)合并到基準(zhǔn)數(shù)據(jù)中[9]。OceanBase定期將更新服務(wù)器（Update Server）上的增量數(shù)據(jù)合并到各個數(shù)據(jù)塊服務(wù)器（Chunk Server）中。因此，OceanBase也是最終一致的，但通過合并服務(wù)器把暫時的不一致隱藏起來了。
因此，本質(zhì)上，只有兩種數(shù)據(jù)庫系統(tǒng)，即滿足ACID屬性的RDBMS和滿足最終一致性的NoSQL系統(tǒng)。所謂的NewSQL，只不過是披著SQL系統(tǒng)外衣（即SQL支持和ACID屬性）的NoSQL系統(tǒng)而已。
1.4 分布式計算系統(tǒng)
分布式存儲系統(tǒng)只解決了大數(shù)據(jù)的存儲問題，并沒有解決大數(shù)據(jù)的計算問題。當(dāng)計算量遠(yuǎn)遠(yuǎn)超過了單機的處理能力后，該怎么辦呢？一種方式是各自開發(fā)專屬的分布式計算框架，但這些計算框架很難做到通用和共享。因此，在不同公司或同一公司的不同團隊中，存在著各種各樣的分布式計算框架，造成了很大的浪費，而且框架的質(zhì)量也良莠不齊。
1.4.1 批處理分布式計算系統(tǒng)
谷歌公司于2004年發(fā)表的MapReduce論文幾近完美地解決了這個問題。MapReduce通過下面兩個看似簡單卻包含了深刻智慧的函數(shù)，輕而易舉地解決了一大類大數(shù)據(jù)計算問題。
map (<K1, V1>) → list(<K2, V2>)[10]
reduce (<K2, list(V2)>) → list(V3)[11]
如圖1-2所示，使用MapReduce解決問題的步驟如下。
（1）需要將輸入表示成一系列的鍵值對<K1, V1>。
（2）定義一個map函數(shù)，其輸入是上一步的一個鍵值對<K1, V1>，其輸出則是另一種鍵值對<K2, V2>的列表。
圖1-2 MapReduce工作原理
（3）運行時，MapReduce框架會對每一個輸入的鍵值對<K1, V1>調(diào)用map函數(shù)（執(zhí)行map函數(shù)的機器稱為Mapper），并生成一系列另一種鍵值對<K2, V2>。然后，MapReduce框架會根據(jù)K2進(jìn)行分區(qū)（partition），即根據(jù)K2的值，將<K2, V2>對在多個稱為Reducer（即執(zhí)行reduce函數(shù)的機器）的機器間進(jìn)行分發(fā)。
（4）還需要定義一個reduce函數(shù)，該函數(shù)的輸入是一系列K2和與其對應(yīng)的V2值的列表，輸出是另一種值V3的列表。
（5）運行時，MapReduce框架會調(diào)用reduce函數(shù)，由reduce函數(shù)來對同一個K2的V2的列表進(jìn)行聚合。
MapReduce本質(zhì)上是一種“分而治之”的策略，只不過數(shù)據(jù)規(guī)模很大而已。它首先把全部輸入分成多個部分，每部分啟動一個Mapper；然后，等所有Mapper都執(zhí)行完后，將Mapper的輸出根據(jù)K2做分區(qū)，對每個分區(qū)啟動一個Reducer，由Reducer進(jìn)行聚合。
MapReduce看似簡單，卻能夠解決一大類問題。MapReduce能夠解決的問題具有下列特征。
需要一次性處理大批的數(shù)據(jù)，而且在處理前數(shù)據(jù)已經(jīng)就緒，即所謂的批處理系統(tǒng)。
數(shù)據(jù)集能夠被拆分，而且可以獨立進(jìn)行計算，不同的數(shù)據(jù)集之間沒有依賴。例如，谷歌的PageRank算法的迭代實現(xiàn)，每一次迭代時，可以把數(shù)據(jù)分為不同的分區(qū)，不同分區(qū)之間沒有依賴，因此就可以利用MapReduce實現(xiàn)。但斐波那契數(shù)列的計算問題則不然，其后面值的計算必須要等前面的值計算出來后方可開始，因此就不能利用MapReduce實現(xiàn)。
計算對實時性要求不高。這是因為MapReduce計算的過程非常耗時。
1.4.2 流處理分布式計算系統(tǒng)
對于那些不斷有新數(shù)據(jù)進(jìn)來，而且對實時性要求很高的計算（如實時的日志分析、實時的股票推薦系統(tǒng)等），MapReduce就不適用了。于是，流處理系統(tǒng)應(yīng)運而生。
根據(jù)對新數(shù)據(jù)的處理方式，流處理系統(tǒng)分為以下兩大類。
微批處理（micro-batch processing）系統(tǒng)：當(dāng)新數(shù)據(jù)到達(dá)時，并不立即進(jìn)行處理，而是等待一小段時間，然后將這一小段時間內(nèi)到達(dá)的數(shù)據(jù)成批處理。這類系統(tǒng)的例子有Apache Spark。
真正的流處理（true stream processing）系統(tǒng)：當(dāng)一條新數(shù)據(jù)到達(dá)后，立刻進(jìn)行處理。這類系統(tǒng)的例子有Apache Storm、Apache Samza和Kafka Streams（只是一個客戶端庫）。
1.4.3 混合系統(tǒng)
在分布式計算領(lǐng)域，還有一種混合了批處理和流處理的系統(tǒng)，這類系統(tǒng)的一個例子是電商的智能推薦系統(tǒng)，其既需要批處理的功能（為了確保響應(yīng)速度，預(yù)先將大量的計算通過批處理系統(tǒng)完成），也需要流處理的功能（根據(jù)用戶的最新行為，對推薦系統(tǒng)進(jìn)行實時調(diào)整）。
對于這類系統(tǒng)，有一種很流行的架構(gòu)，即Lamda架構(gòu)（如圖1-3所示），其思想是用一個批處理系統(tǒng)（如MapReduce）來進(jìn)行批處理計算，再用一個實時處理系統(tǒng)（如Apache Spark/Storm）來進(jìn)行實時計算，最后用一個合并系統(tǒng)將二者的計算結(jié)果結(jié)合起來并生成最終的結(jié)果。
圖1-3 Lamda架構(gòu)
對于混合系統(tǒng)的實現(xiàn)，有篇非常有趣的文章值得一讀，“Questioning the Lambda Architecture”一文中提到了Lamda架構(gòu)的一個很大的缺點，即處理邏輯需要在批處理系統(tǒng)和流處理系統(tǒng)中實現(xiàn)兩遍。該文提到了一種新的混合系統(tǒng)實現(xiàn)方式，即利用Kafka可以保存歷史消息的特性，根據(jù)業(yè)務(wù)的需要，在Kafka中保存一定時間段內(nèi)的歷史數(shù)據(jù)，當(dāng)需要進(jìn)行批處理時，則訪問Kafka中保存的歷史數(shù)據(jù)，當(dāng)需要實時處理時，則消費Kafka中的最新消息。如此這般，處理邏輯就只需要實現(xiàn)一套了。感興趣的讀者，可以讀一讀此文。
1.5 分布式系統(tǒng)中節(jié)點之間的關(guān)系
一個人類社會的組織，要想實現(xiàn)其組織功能，組織內(nèi)的人需要按照某種方式被組織起來，例如，有的人負(fù)責(zé)管理，有的人負(fù)責(zé)執(zhí)行，等等。由許多節(jié)點組成的分布式系統(tǒng)也一樣，系統(tǒng)中的節(jié)點也需要被有機地組織起來，才能實現(xiàn)想要完成的功能。也就是說，有些節(jié)點需要承擔(dān)這樣的角色，而另一些節(jié)點則需要承擔(dān)另外的角色。根據(jù)所承擔(dān)角色的不同，節(jié)點之間的關(guān)系不外乎下面兩種。
主從式（master-slave）關(guān)系：主節(jié)點集大權(quán)于一身，所有重要的信息都存儲在主節(jié)點上，所有重要的決定也都由主節(jié)點做出。這類系統(tǒng)的例子有谷歌的GFS和Bigtable等，以及受其架構(gòu)影響而開發(fā)的其他系統(tǒng)（如HDFS、HBase、淘寶TFS、京東JFS、百度BFS、百度Tera等）。
對等式（peer-to-peer）關(guān)系：這類系統(tǒng)中的節(jié)點之間的關(guān)系是平等的，沒有中心節(jié)點，而是采用設(shè)置好的選舉與協(xié)調(diào)規(guī)則來處理節(jié)點之間的協(xié)調(diào)問題，這類系統(tǒng)的典型代表是亞馬遜的Dynamo，以及受其架構(gòu)影響而開發(fā)的其他系統(tǒng)（如Cassandra、Riak等）。
相對而言，主從式系統(tǒng)實現(xiàn)起來要簡單些，而對等式系統(tǒng)實現(xiàn)起來則困難些。
聯(lián)系客服
