本文作者Kate Matsudaira是一位美麗的女工程副總裁，曾在Sun Microsystems、微軟、亞馬遜這些一流的IT公司任職。她有著非常豐富的工作經(jīng)驗和團(tuán)隊管理經(jīng)驗，當(dāng)過程序員、項目經(jīng)理、產(chǎn)品經(jīng)理以及人事經(jīng)理。專注于構(gòu)建和操作大型Web應(yīng)用程序/網(wǎng)站，目前她的主要研究方向是SaaS（軟件即服務(wù)）應(yīng)用程序和云計算（如大家所說的大數(shù)據(jù)）。
本文是作者在AOSA一書介紹如何構(gòu)建可擴(kuò)展的分布式系統(tǒng)里的內(nèi)容，我們進(jìn)行了翻譯并分為上下兩篇分布分享給大家。在上一篇《構(gòu)建高可擴(kuò)Web架構(gòu)和分布式系統(tǒng)實戰(zhàn)》中，我們舉例討論了設(shè)計分布式系統(tǒng)需要考慮的核心要素：可用性、性能、可靠性、可擴(kuò)展、易管理、成本。而在這篇文章中，我們將深入介紹如何設(shè)計可擴(kuò)展的數(shù)據(jù)訪問，包括負(fù)載均衡、代理、全局緩存、分布式緩存等。
構(gòu)建快速可伸縮的數(shù)據(jù)訪問塊
在討論完設(shè)計分布式系統(tǒng)的核心考慮因素后，下面讓我們再一起討論難點部分：可擴(kuò)展的數(shù)據(jù)訪問。
大多數(shù)簡單的Web應(yīng)用程序，例如LAMP堆棧應(yīng)用程序，看起來如圖5所示：
圖5：簡單的Web應(yīng)用程序
隨著系統(tǒng)漸漸擴(kuò)大，他們將面臨兩大主要挑戰(zhàn)：構(gòu)建可擴(kuò)展的應(yīng)用程序服務(wù)器和數(shù)據(jù)訪問機(jī)制。在一個高可擴(kuò)的應(yīng)用程序設(shè)計中，通常最小化的應(yīng)用程序（或Web）服務(wù)往往能體現(xiàn)一種無共享的架構(gòu)。這就使得應(yīng)用程序服務(wù)器層要進(jìn)行橫向擴(kuò)展，這種設(shè)計的結(jié)果就是把繁重的工作轉(zhuǎn)移到堆棧下層的數(shù)據(jù)庫服務(wù)和配置服務(wù)上，這才是這一層上真正的可擴(kuò)展和性能挑戰(zhàn)。
本文的剩余部分專門討論一些常見策略和方法來使這些服務(wù)可以快速和可擴(kuò)展，提升數(shù)據(jù)的訪問速度。
圖6 過于簡化的的Web應(yīng)用程序
大多數(shù)系統(tǒng)可能會簡化成圖6那樣，這是個非常不錯的起點。如果你有大量的數(shù)據(jù)，想要快速便捷地訪問，就好比在你書桌抽屜的最上面有一堆糖果。雖然過于簡化，但也暗示了兩個難題：可擴(kuò)展存儲和快速的數(shù)據(jù)訪問。
為了這個例子，讓我們假設(shè)有許多太字節(jié)（TB）數(shù)據(jù)，并且允許用戶隨機(jī)訪問一小部分?jǐn)?shù)據(jù)（見圖7）。這與本文圖片應(yīng)用程序里的在文件服務(wù)器上定位一個圖片文件非常相似。
圖7 訪問特定數(shù)據(jù)
這也是個非常大的挑戰(zhàn)，把TB級數(shù)據(jù)加載到內(nèi)存中的成本比較昂貴，這可以直接轉(zhuǎn)化到磁盤上進(jìn)行IO。從磁盤上讀取要比內(nèi)存慢的多——內(nèi)存訪問和Chuck Norris一樣快，而磁盤的訪問速度要比在DMV上慢。這個速度不同于大數(shù)據(jù)集上的合計，實數(shù)內(nèi)存訪問大概要比順序訪問快6倍，或者比隨機(jī)從磁盤上讀取快10萬倍（參考The Pathologies of Big Data）。此外，即使是unique ID，想要在較少的數(shù)據(jù)中查找確切的位置也是一項艱巨的任務(wù)。
幸運的是，能找到許多方法讓這個問題變的簡單，這里提供4個非常重要的方法：緩存、代理、索引和負(fù)載均衡器。在下面將會詳細(xì)討論這4個內(nèi)容來提升數(shù)據(jù)訪問速度。
緩存
緩存就是利用本地參考原則：當(dāng)CPU要讀取一個數(shù)據(jù)時，首先從緩存中查找，找到就立即讀取并送給CPU處理；沒有找到，就用相對慢的速率從內(nèi)存中讀取并送給CPU處理，同時把這個數(shù)據(jù)所在的數(shù)據(jù)塊調(diào)入緩存中，可以使得以后對整塊數(shù)據(jù)的讀取都從緩存中進(jìn)行，不必再調(diào)用內(nèi)存。它們幾乎被用在每一個計算層上：硬件、操作系統(tǒng)、Web瀏覽器、Web應(yīng)用程序等。一個緩存就相當(dāng)于是一個臨時內(nèi)存：它有一個有限的空間量，但訪問它比訪問原始數(shù)據(jù)速度要快。緩存也可以存在于各個層的架構(gòu)中，但經(jīng)常在離前端最近的那個層上發(fā)現(xiàn)，在那里可以快速實現(xiàn)并返回數(shù)據(jù)，無需占用下游層數(shù)據(jù)。
那么如何在我們的API例子里利用緩存使數(shù)據(jù)訪問更快呢？在這種情況下，有許多地方可以插入緩存。一種是在請求層節(jié)點上插入緩存，如圖8所示。
圖8 在請求層節(jié)點插入緩存
在請求層節(jié)點上放置一個緩存，即可響應(yīng)本地的存儲數(shù)據(jù)。當(dāng)對服務(wù)器發(fā)送一個請求時，如果本地存在所請求數(shù)據(jù)，那么該節(jié)點即會快速返回本地緩存數(shù)據(jù)。如果本地不存在，那么請求節(jié)點將會查詢磁盤上的數(shù)據(jù)。請求層節(jié)點緩存即可以存在于內(nèi)存中（這個非常快速）也可以位于該節(jié)點的本地磁盤上（比訪問網(wǎng)絡(luò)存儲要快）。
圖9 多個緩存
當(dāng)擴(kuò)展到許多節(jié)點的時候，會發(fā)生什么呢？如圖9所示，如果請求層被擴(kuò)展為多個節(jié)點，它仍然有可能訪問每個節(jié)點所在的主機(jī)緩存。然而，如果你的負(fù)載均衡器隨機(jī)分布節(jié)點之間的請求，那么請求將會訪問各個不同的節(jié)點，因此緩存遺漏將會增加。這里有兩種方法可以克服這個問題：全局緩存和分布式緩存。
全局緩存
顧名思義，全局緩存是指所有節(jié)點都使用同一個緩存空間。這包含添加一臺服務(wù)器或某種類型的文件存儲，所有請求層節(jié)點訪問該存儲要比原始存儲快。每個請求節(jié)點會以同種方式查詢緩存，這種緩存方案可能有點復(fù)雜，隨著客戶機(jī)和請求數(shù)量的增加，單個緩存（Cache）很容易溢出，但在某些結(jié)構(gòu)中卻是非常有效的（特別是那些特定的硬件，專門用來提升全局緩存速度，或者是需要被緩存的特定數(shù)據(jù)集）。
在圖10中描述了全局緩存常見的兩種方式。當(dāng)一個Cache響應(yīng)在高速緩存中沒有發(fā)現(xiàn)時，Cache自己會從底層存儲中檢索缺少的那塊數(shù)據(jù)。如圖11所示，請求節(jié)點去檢索那些在高速緩存中沒有發(fā)現(xiàn)的數(shù)據(jù)。
圖10 負(fù)責(zé)檢索數(shù)據(jù)的全局緩存
圖11 全局緩存里負(fù)責(zé)檢索的請求節(jié)點
大多使用全局緩存的應(yīng)用程序都傾向于使用第一種類型，利用Cache本身來驅(qū)逐和獲取數(shù)據(jù)以防止來自客戶端的同一個數(shù)據(jù)區(qū)發(fā)出大量的請求。然而，在某些情況下，使用第二種實現(xiàn)反而更有意義。例如，如果該緩存用于存儲大量的文件，低緩存的命中率會導(dǎo)致高速緩沖區(qū)不堪重負(fù)和緩存遺漏，在這種情況下， it helps to have a large percentage of the total data set (or hot data set) in the cache.
分布式緩存
分布式緩存即緩存在分布式系統(tǒng)各節(jié)點內(nèi)存中的緩存數(shù)據(jù)。如圖12所示，每個節(jié)點都有自己的緩存數(shù)據(jù)，所以如果冰箱扮演著緩存雜貨店的角色，那么分布式緩存就是把食物放置在不同的地方——冰箱、櫥柜和飯盒——當(dāng)索取的時候，方便拿哪個就拿哪個，而無需特地往商店跑一趟。通常情況下，會使用一致性哈希函數(shù)對緩存進(jìn)行劃分，例如，一個請求節(jié)點正在尋找一個特定塊的數(shù)據(jù)，在分布式緩存中，它很快就會知道去哪里找，并確保這些數(shù)據(jù)是可用的。這種情況下，每個節(jié)點都會有一小塊緩存，然后在向另一個節(jié)點發(fā)送數(shù)據(jù)請求。因此分布式緩存的優(yōu)點之一就是只需向請求池添加節(jié)點即可增加緩存空間，減少對數(shù)據(jù)庫的訪問負(fù)載量。
當(dāng)然，分布式緩存也存在缺點，例如單點實效，當(dāng)該節(jié)點出現(xiàn)故障或宕機(jī)，那么該節(jié)點保存的數(shù)據(jù)就會丟失。
圖12 分布式緩存
分布式緩存的突出優(yōu)點是提高運行速度（前提當(dāng)然是正確實現(xiàn)）。選擇不同的方法也會有不一樣的效果，如果方法正確，即使請求數(shù)很多，也不會對速度有所影響。然而，緩存的維護(hù)需要額外的存儲空間，這些通常需要購買存儲器實現(xiàn)，但價格都很昂貴。
其中一個非常流行的開源緩存產(chǎn)品：Memcached（即可以在本地緩存上工作也可以在分布式緩存上工作）；然而，這里還有許多其他選項（包括許多語言——或者是框架——特定選項）。
Memcached用于許多大型Web站點，其非常強(qiáng)大。Memcached基于一個存儲鍵/值對的hashmap，優(yōu)化數(shù)據(jù)存儲和實現(xiàn)快速搜索（O(1)）。
Facebook采用不同類型的緩存技術(shù)來提升他們的網(wǎng)站性能（參考“Facebook caching and performance”）。在語言層面上使用$GLOBALS和APC（在PHP里提供函數(shù)調(diào)用），這有助于使中間函數(shù)調(diào)用更快（大多數(shù)語言都使用這些類型庫來提升網(wǎng)站頁面性能）。Facebook使用全局緩存并且通過多臺服務(wù)器對緩存進(jìn)行分布（參考“Scaling memcached at Facebook”），這就允許他們通過配置用戶文件數(shù)據(jù)來獲得更好的性能和吞吐量，并且還可以有一個中心位置更新數(shù)據(jù)（這是非常重要的，當(dāng)運行成千上萬臺服務(wù)器時，緩存實效和一致性維護(hù)都是非常大的挑戰(zhàn)）。
下面讓我們談?wù)劗?dāng)數(shù)據(jù)不在緩存中時，我們該做什么……
代理
簡單點講，代理服務(wù)器就是硬件/軟件的中間件，接受客戶端請求并且將他們轉(zhuǎn)發(fā)到后端的源服務(wù)器上。通常，代理服務(wù)器用于過濾請求、記錄請求日志或有時轉(zhuǎn)換請求（通過添加/刪除頭結(jié)點、加密/解密或壓縮）。
圖13 代理服務(wù)器
代理可以優(yōu)化請求，并且從整個系統(tǒng)的角度來優(yōu)化請求通信量。一方面，使用代理可以加速數(shù)據(jù)訪問，可以把相同（或相似的）請求重疊壓縮成一個請求，然后返回單個結(jié)果到請求客戶端，這就是壓縮轉(zhuǎn)發(fā)（collapsed forwarding）。
在一個局域網(wǎng)代理中，例如，客戶端無需使用它們自己的IP去連接互聯(lián)網(wǎng)，對于相同的內(nèi)容，局域網(wǎng)將壓縮來自客戶端的請求。它很容易造成混淆，因為很多代理同樣也是緩存（它是一個非常合乎邏輯放置緩存的地方），但并非所有緩存都扮演代理這一角色。
圖14 使用一個代理服務(wù)器壓縮請求
使用代理服務(wù)器的另一偉大方式是通過壓縮請求對空間數(shù)據(jù)進(jìn)行加密。采用這種策略最大化數(shù)據(jù)本地化的請求會導(dǎo)致減少請求的延遲。例如這里有一大串的節(jié)點請求B：partB1、partB2等等。我們可以設(shè)置代理來識別個人空間的位置請求，把它們壓縮成單一的請求并只返回bigB，大大減少了從數(shù)據(jù)源處讀取數(shù)據(jù)次數(shù)（如圖15所示）。在高負(fù)載的情況下，代理也特別有用，或者當(dāng)你具有有限的緩存時，它們基本上可以把多個請求批處理成一個。
圖15 使用代理對空間數(shù)據(jù)請求進(jìn)行壓縮
如果你正在為系統(tǒng)尋找代理，這里提供幾個供你選擇：Squid和Varnish，它們都做過非常全面的測試并且被廣泛用在許多大型網(wǎng)站上。這些代理解決方案對客戶端——服務(wù)器端通信提供了許多優(yōu)化方案。在Web服務(wù)器層作為反向代理安裝可以大大提高Web服務(wù)性能，減少處理傳入客戶機(jī)請求所需的工作量。
索引
使用索引來快速訪問和優(yōu)化數(shù)據(jù)是一個眾所周知的策略，最有名的莫過于數(shù)據(jù)庫索引。
圖16 索引
一個索引就是數(shù)據(jù)庫表的目錄，表中數(shù)據(jù)和相應(yīng)的存儲位置的列表。好比是一篇文章的目錄，可以加快數(shù)據(jù)表的。例如讓我們來查找一塊數(shù)據(jù)，B中的第二部分——如何發(fā)現(xiàn)它的位置？如果你通過數(shù)據(jù)類型存儲了一個索引——例如數(shù)據(jù)A、B、C——它將告訴你數(shù)據(jù)B的原始位置。然后你只需去查看B并且根據(jù)需要閱讀B的數(shù)據(jù)即可（參考圖16）。
這些索引通常存儲在內(nèi)存或者是傳入客戶端請求的本地中。Berkeley DBs（BDBs）和樹數(shù)據(jù)結(jié)構(gòu)常常被用在有序列表中存儲數(shù)據(jù)，這是訪問索引的理想選擇。
通常，會把許多層索引作為一個映射，從一個位置移到下一個，以此類推，直到你得到想要的特定塊數(shù)據(jù)（參照圖17）。
圖17 多層索引
索引也可以對相同的數(shù)據(jù)創(chuàng)建多個不同的視圖。對大型數(shù)據(jù)集來說，這種方法是非常好的，無需創(chuàng)建多個額外的數(shù)據(jù)副本就可以定義不同的過濾和排序，
例如，早期的圖像托管系統(tǒng)實際上是托管圖像書本內(nèi)容，允許客戶端查詢這些圖像中的內(nèi)容，輸入一個主題，就可以把所有相關(guān)的內(nèi)容搜索出來。此外，采用同樣的方式，搜索引擎還允許你搜索出HTML內(nèi)容。在這種情況下，需要很多的服務(wù)器來存儲這些文件，查找其中一個頁面可能會很麻煩。首先，反向索引查詢?nèi)我鈧€單詞或字元祖都需要可以輕松地訪問；再有就是導(dǎo)航到正確的頁面和位置，檢索到正確的圖像結(jié)果也是項挑戰(zhàn)。因此，在這種情況下，反向索引會映射到一個位置（例如書B），然后書B可能會有一個包含所有內(nèi)容、位置和各個部分出現(xiàn)次數(shù)的索引。
這種中間級索引只包含了Words、位置和書B的信息。與所有的信息不得不存儲到一個大的反向索引中相比，這種嵌套的索引架構(gòu)允許每個索引占用較少的空間。在大型系統(tǒng)中，這是非常關(guān)鍵的，即使采用壓縮，這些索引也需要占用相當(dāng)昂貴的存儲空間。
例如，讓我們假設(shè)這個世界上有——100,000,000本書（參考Inside Google Books官方博客）——每本書只有10頁，每頁只有250個單詞，這也就意味著有2500億個單詞。如果每個單詞只有5個字節(jié)，每個字節(jié)占用8 bits（或1個byte，甚至有些字符占用2 bytes），所以5 bytes/單詞，那么一個索引所包含的單詞就有可能超過一個TB的存儲。此外，索引還有可能包含其他信息，例如元祖單詞、數(shù)據(jù)位置等。
能夠快速、輕松地找到數(shù)據(jù)是非常重要的，而使用索引就可以簡單高效的實現(xiàn)。
負(fù)載均衡器
分布式系統(tǒng)的另一個關(guān)鍵部分是負(fù)載均衡。負(fù)載均衡器幾乎是每個架構(gòu)的主要組成部分，他們的角色是負(fù)責(zé)把網(wǎng)絡(luò)請求分散到一個服務(wù)器集群中的可用服務(wù)器上去，通過管理進(jìn)入的Web數(shù)據(jù)流量和增加有效的網(wǎng)絡(luò)帶寬，從而使網(wǎng)絡(luò)訪問者獲得盡可能最佳的聯(lián)網(wǎng)體驗的硬件設(shè)備。
圖18 負(fù)載均衡器
這里有許多種算法可用于為請求提供服務(wù)，包括隨機(jī)選擇一個節(jié)點、循環(huán)或者甚至是基于某個特定的標(biāo)準(zhǔn)來選擇節(jié)點，例如內(nèi)存或CPU利用率。負(fù)載均衡器即可以以硬件的方式表現(xiàn)出來，也可以以軟件的方式。HAProxy是一個開源的負(fù)載均衡器，并且得到了非常廣泛的使用。
在一個分布式系統(tǒng)中，負(fù)載均衡器通常處于系統(tǒng)的前端位置，所有傳入的請求會相應(yīng)地被路由。在一個復(fù)雜的分布式系統(tǒng)中，一個請求被路由到多個負(fù)載均衡器上并不常見，如圖19所示：
圖19 多個負(fù)載平衡器
和代理一樣，有些負(fù)載均衡器也可以基于請求的類型路由到不同的服務(wù)器集群上。（技術(shù)上來講，這也被稱為反向代理。）
負(fù)載均衡器所面臨的挑戰(zhàn)之一是管理用戶特有的會話（user-session-specific）數(shù)據(jù)。在一個電子商務(wù)網(wǎng)站上，當(dāng)你只有一個客戶端時，是很容易讓用戶把商品放入購物車并且繼續(xù)訪問（這是非常重要的，因為商品很有可能在繼續(xù)出售，而用戶退出時，商品仍然留在購物車?yán)铮?。然而，如果用戶本次會話路由了一個節(jié)點，那么當(dāng)他下次訪問的時候會路由一個不同的節(jié)點，這樣，就很有可能使購物車?yán)锏纳唐凡灰恢?，因為新的?jié)點有可能會丟失該用戶購物車?yán)镌鹊纳唐罚ó?dāng)你先放6包Mountain Dew 在購物車?yán)铮鹊皆俅蔚卿浐蟀l(fā)現(xiàn)購物車為空了）。解決這個問題的方法之一是使用sticky sessions，來使用戶一直被路由到相同的節(jié)點，但它很難利用到可靠性功能，像自動故障轉(zhuǎn)移（automatic failover）。這種情況下，用戶的購物車?yán)飳恢庇猩唐?，但如果sticky node變的不可用，這就需要特殊情況來處理并且假設(shè)購物車?yán)锏纳唐穼⒉辉儆行ВūM管希望這種假設(shè)不會被內(nèi)置于應(yīng)用程序里）。當(dāng)然解決這個問題還有許多其他方法，例如本文提到的服務(wù)以及不包括（瀏覽器緩存、cookies和URL重寫）。
在一個大型系統(tǒng)里會有各種不同類型的調(diào)度和負(fù)載均衡算法，包括簡單點的像隨機(jī)選擇或循環(huán)以及更復(fù)雜的機(jī)制，例如利用率和容量。所有的這些算法都可以分布流量和請求，并且提供有用的可靠性工具，像自動故障轉(zhuǎn)移或者自動清除一個壞的節(jié)點（例如當(dāng)它無法響應(yīng)時）。然而，這種高級功能會把問題診斷的復(fù)雜。 例如，當(dāng)遇到高負(fù)載情況時，負(fù)載均衡器將會移除變慢或超時的節(jié)點（因為請求太多，刪除節(jié)點后會把請求分配到其他節(jié)點上），這無疑會加劇其他節(jié)點的工作量，即負(fù)載加重。這種情況下，大量的監(jiān)測變的非常重要，因為整個系統(tǒng)流量和吞吐量看起來可能會減少（因為節(jié)點服務(wù)更少的請求），但可能會累壞個別節(jié)點（處理更多的請求）。
負(fù)載均衡器也是擴(kuò)展系統(tǒng)容量的一種簡單方式，像文中提到的其他技術(shù)，在分布式系統(tǒng)架構(gòu)中發(fā)揮著非常重要的作用。負(fù)載均衡器也提供一些重要功能來測試節(jié)點的健康狀況，例如，如果該節(jié)點響應(yīng)遲鈍或過載，它可能就會被刪除，然后利用系統(tǒng)中不同的節(jié)點冗余。
隊列
到目前為止，我們已經(jīng)討論了許多方法來加快數(shù)據(jù)讀取速度，但擴(kuò)展數(shù)據(jù)層的另一個重要組成部分是如何高效的寫入數(shù)據(jù)。在簡單的系統(tǒng)中，進(jìn)程負(fù)載等都比較少，并且數(shù)據(jù)庫比較小，毋庸置疑，寫的速度肯定不會慢。然而，在大型復(fù)雜的系統(tǒng)里，這個速度就很難把握了，可能會花費很長的時間。例如，數(shù)據(jù)有可能要寫到幾個不同的地方，不同的服務(wù)器或索引、或者系統(tǒng)正處于高負(fù)載情況下。在這種情況，該在哪里進(jìn)行寫？或者其他任何任務(wù)都有可能花費很長時間，要想在系統(tǒng)實現(xiàn)性能和可用性需要構(gòu)建異步。處理這種異步的一種常見的方式就是采用隊列。
圖20 同步請求
想象在一個系統(tǒng)里，每個客戶機(jī)都要把請求發(fā)送至遠(yuǎn)程服務(wù)器，那么服務(wù)器應(yīng)該盡可能快的接收并完成任務(wù)，然后把結(jié)果返回到相應(yīng)的客戶端。在小型系統(tǒng)中，一臺服務(wù)器（或邏輯服務(wù)器）傳入客戶端數(shù)據(jù)會與客戶端發(fā)出時一樣快，這樣就比較完美了。然而，當(dāng)服務(wù)器接收到的請求多余它的處理能力時，那么每個客戶端必須排隊等待服務(wù)器處理其他客戶端請求，直到輪到你了，服務(wù)器才會處理你的請求，直到最終完成。這就是一個同步請求的例子，如圖20所示。
這種同步行為會嚴(yán)重降低客戶端性能，客戶端被迫等待，而通過添加額外的服務(wù)器來滿足負(fù)載并不能解決問題，即使采用最有效的負(fù)載均衡也很難保證分配公平，在大客戶端下。進(jìn)一步講，如果處理請求的服務(wù)器不可用或者癱瘓，那么客戶端上游也將失敗。有效的解決這個問題需要抽象客戶端請求以及服務(wù)請求的實際工作。
圖21 使用隊列來管理請求
隊列就像聽起來那樣簡單，一個任務(wù)進(jìn)來，就添加到隊列里去，然后the workers挑選有能力處理的下一個任務(wù)。（參考圖21）這些任務(wù)有可能僅是簡單的寫入，也有可能是復(fù)雜的，如把文檔生成圖像預(yù)覽。當(dāng)一個客戶端把任務(wù)請求提交的隊列中時，他們不需要被迫等待結(jié)果，相反，他們只需確認(rèn)請求是否被正確接收。
隊列使客戶端能夠以異步的方式工作，對客戶端請求和響應(yīng)提供戰(zhàn)略抽象。另一方面，在一個同步系統(tǒng)中，請求和回應(yīng)是沒有分化的，因此他們不能被分開管理。在異步系統(tǒng)中，客戶端發(fā)出請求任務(wù)，服務(wù)器對收到的消息進(jìn)行響應(yīng)并確認(rèn)任務(wù)被接收，然后客戶端可以定期檢查任務(wù)狀態(tài)，一旦任務(wù)完成，即可看到結(jié)果。當(dāng)客戶端在等待異步請求是否完成時，它還可以自由執(zhí)行其他任務(wù)，甚至是向其他服務(wù)器發(fā)出異步請求。下面要介紹的是消息和隊列在分布式系統(tǒng)中的杠桿作用。
隊列也對服務(wù)中斷或失敗提供一種保護(hù)機(jī)制。例如，它很容易創(chuàng)建一個高度健壯的隊列，當(dāng)服務(wù)器瞬間失敗時，該隊列可以把剛剛失敗的請求重新發(fā)送至服務(wù)器。相比直接暴露客戶端來間斷服務(wù)供應(yīng)，使用隊列來保證服務(wù)質(zhì)量更可取，要求必須有復(fù)雜且矛盾性的客戶端差錯處理。
隊列是管理分布式通信與任何大規(guī)模分布式系統(tǒng)中各個部分之間的基礎(chǔ)，并且有許多實現(xiàn)方式。這里有許多開源的隊列，如RabbitMQ、ActiveMQ、BeanstalkD，但也有一些當(dāng)做服務(wù)使用，如Zookeeper，甚至是用來數(shù)據(jù)存儲，像Redis。
總結(jié)
設(shè)計出一個高效的分布式系統(tǒng)是令人興奮的事情，尤其是擁有快速的數(shù)據(jù)訪問速度。本文只是討論了幾個實際的例子，希望對你能有所幫助。
相關(guān)閱讀：
構(gòu)建高可擴(kuò)Web架構(gòu)和分布式系統(tǒng)實戰(zhàn)（上）
