開放源代碼已經(jīng)成為一些大型網(wǎng)站的基本原則。而在這些網(wǎng)站成長的過程中，一些優(yōu)秀的實踐經(jīng)驗和規(guī)則也出現(xiàn)在他們的結(jié)構(gòu)中。本文旨在介紹一些在大型網(wǎng)站結(jié)構(gòu)設(shè)計的過程中需要注意的關(guān)鍵問題以及實現(xiàn)目標的基礎(chǔ)工作。

本文側(cè)重于介紹網(wǎng)絡(luò)系統(tǒng)，盡管一些準則在其他分布式系統(tǒng)中也是適用的。

1.1. web分布式系統(tǒng)的設(shè)計原則

搭建和運營一個可伸縮的web站點或者應(yīng)用程序意味著什么？在原始層面上這僅僅是用戶通過互聯(lián)網(wǎng)連接到遠程資源-使系統(tǒng)變得可伸縮的部分是將資源、或者訪問的資源，分布于多個服務(wù)器上。

像生活中大多數(shù)事情一樣，當(dāng)構(gòu)建一個web服務(wù)時花時間提前做好計劃從長遠看來還是很有幫助的；了解一些注意事項和大網(wǎng)站背后的權(quán)衡原則可以在創(chuàng)建小型網(wǎng)站時做出更明智的決定。以下是一些影響大規(guī)模web系統(tǒng)設(shè)計的關(guān)鍵原則:

• 可用性:對于很多公司來說一個網(wǎng)站的正常運行時間是非常關(guān)鍵的聲譽和功能，像一些大型的在線零售系統(tǒng)，即使一分鐘的宕機都有可能導(dǎo)致數(shù)千或者數(shù)百萬美元的損失，因此設(shè)計系統(tǒng)的時時可用性和彈性的錯誤處理機制既是一個基本業(yè)務(wù)也是一個技術(shù)要求。 高可用分布式系統(tǒng)需要仔細考慮關(guān)鍵組件的冗余，分系統(tǒng)失敗后能快速修復(fù)，并且當(dāng)問題出現(xiàn)時優(yōu)雅型降級。
• 性能:網(wǎng)站的性能正在變成大多數(shù)站點考慮的一個重要的方面，網(wǎng)站的速度影響正常使用和用戶的滿意度，同樣影響搜索的排名，這也是影響網(wǎng)站收益和保留用戶的一個因素。因此，創(chuàng)建一個快速響應(yīng)和低延遲的系統(tǒng)是非常關(guān)鍵的。
• 可靠性:一個系統(tǒng)需要具備可靠性，比如同一個數(shù)據(jù)的請求始終返回同樣的數(shù)據(jù)響應(yīng) 。如果數(shù)據(jù)改變或者被更新，那么同樣的數(shù)據(jù)將返回一個新的數(shù)據(jù)。用戶需要知道一些東西被寫入系統(tǒng)或者被存儲到系統(tǒng)后，系統(tǒng)會保持不變并且可以在以后恢復(fù)到合適的位置。
• 可伸縮性:當(dāng)談到任何大型的分布式系統(tǒng)時，規(guī)模大小只是考慮的其中一個方面，同樣重要的是增強處理較大規(guī)模的負載性能所做的努力，這通常稱為系統(tǒng)的可伸縮性?？缮炜s性可以代表系統(tǒng)很多不同的參數(shù)：額外流量的處理量，添加存儲容量的便意性，甚至事務(wù)的處理量。
• 可管理性: 設(shè)計一個系統(tǒng)可以方便操作是另一個重要的考慮方面，系統(tǒng)的可管理性等同于操作的可伸縮性：維護和升級?？晒芾硇孕枰紤]的事情是當(dāng)問題發(fā)生時方便診斷和了解問題，易于升級和修改，以及系統(tǒng)能簡單性的操作（即，例行的操作有沒有失敗和異常？）
• 成本: 成本是一個重要的因素。很明顯這包含硬件和軟件成本，但同樣重要需要考慮的其他方面是部署和維護系統(tǒng)的成本。開發(fā)者構(gòu)建系統(tǒng)花費的大量時間，運維部署時間，甚至培訓(xùn)時間都需要考慮，成本是總體成本。

以上每個原則都為設(shè)計分布式web架構(gòu)提供了基礎(chǔ)決策。然而，他們也能彼此互斥，例如要實現(xiàn)某個目標就要以另外的作為代價。一個基本的例子：選擇通過單純增加更多的服務(wù)器（可擴展性）來增加地址容量，是以可管理性（你必須操作增加的服務(wù)器）和成本（服務(wù)器的價格）為代價的。

當(dāng)設(shè)計任何的web應(yīng)用程序時，考慮這些關(guān)鍵原則都是很重要的，即使得承認一個設(shè)計可能要犧牲它們之中的一個或者多個。

1.2. 基礎(chǔ)

當(dāng)設(shè)計一個系統(tǒng)架構(gòu)時，有一些東西是要考慮的：正確的部分是什么，怎樣讓這些部分很好地融合在一起，以及好的折中方法是什么。通常在系統(tǒng)架構(gòu)需要之前就為它的可擴展性投資不是一個聰明的商業(yè)抉擇；然而，在設(shè)計上的深謀遠慮能在未來節(jié)省大量的時間和資源。

這部分關(guān)注點是幾乎所有大型web應(yīng)用程序中心的一些核心因素：服務(wù)、冗余、劃分和錯誤處理。每一個因素都包含了選擇和妥協(xié)，特別是上部分提到的設(shè)計原則。為了詳細的解析這些，最好是用一個例子來開始。

實例：圖片托管應(yīng)用

有時候你可能會在線上傳一張圖片。對于那些托管并負責(zé)分發(fā)大量圖片的網(wǎng)站來說，要搭建一個既節(jié)省成本又高效還能具備較低的延遲性（你能快速的獲圖片）的網(wǎng)站架構(gòu)確實是一種挑戰(zhàn)。

我們來假設(shè)一個系統(tǒng)，用戶可以上傳他們的圖片到中心服務(wù)器，這些圖片又能夠讓一些web鏈接或者API獲取這些圖片，就如同現(xiàn)在的Flickr或者 Picasa。為了簡化的需要，我們假設(shè)應(yīng)用程序分為兩個主要的部分：一個是上傳圖片到服務(wù)器的能力（通常說的寫操作），另一個是查詢一個圖片的能力。然而，我們當(dāng)然想上傳功能很高效，但是我們更關(guān)心的是能夠快速分發(fā)能力，也就是說當(dāng)某個人請求一個圖片的時候（比如，一個web頁面或者其它應(yīng)用程序請求圖片）能夠快速的滿足。這種分發(fā)能力很像web服務(wù)器或者CDN連接服務(wù)器（CDN服務(wù)器一般用來在多個位置存儲內(nèi)容一邊這些內(nèi)容能夠從地理位置或者物理上更靠近訪問它的用戶，已達到高效訪問的目的）氣的作用。

系統(tǒng)其他重要方面：

• 對圖片存儲的數(shù)量沒有限制，所以存儲需要可擴展，在圖像數(shù)量方面需要考慮。
• 圖片的下載和請求不需要低延遲。
• 如果用戶上傳一個圖片，圖片應(yīng)該都在那里（圖片數(shù)據(jù)的可靠性）。
• 系統(tǒng)應(yīng)該容易管理（可管理性）。
• 由于圖片主機不會有高利潤的空間，所以系統(tǒng)需要具有成本效益。

Figure 1.1是一個簡化的功能圖。

Figure 1.1: 圖片主機應(yīng)用的簡化架構(gòu)圖

在這個圖片主機的例子里，可遇見系統(tǒng)必需快速，它的數(shù)據(jù)存儲要可靠以及這些所有的屬性都應(yīng)該高度的可擴展。建立這個應(yīng)用程序的一個小版本不是很重要而且很容易部署在單一的服務(wù)器上；然而，這不是這節(jié)里的感興趣部分。假設(shè)下我們想建一個會增長到和Flickr痛讓規(guī)模的東西。

#p#

服務(wù)

當(dāng)要考慮設(shè)計一個可擴展的系統(tǒng)時，為功能解耦和考慮下系統(tǒng)每部分的服務(wù)都定義一個清晰的接口都是很有幫助的。在實際中，在這種方式下的系統(tǒng)設(shè)計被成為面向服務(wù)架構(gòu)（SOA）。對于這類型的系統(tǒng)，每個服務(wù)有自己獨立的方法上下文，以及使用抽象接口與上下文的外部任何東西進行交互，典型的是別的服務(wù)的公共API。

把一個系統(tǒng)解構(gòu)為一些列互補的服務(wù)，能夠為這些部分從別的部分的操作解耦。這樣的抽象幫助在這些服務(wù)服、它的基礎(chǔ)環(huán)境和服務(wù)的消費者之間建立清晰的關(guān)系。建立這種清晰的輪廓能幫助隔離問題，但也允許各模塊相對其它部分獨立擴展。這類面向服務(wù)設(shè)計系統(tǒng)是非常類似面向?qū)ο笤O(shè)計編程的。

在我們的例子中，上傳和檢索圖像的請求都是由同一個服務(wù)器處理的；然而，因為系統(tǒng)需要具有伸縮性，有理由要將這兩個功能分解為各由自己的服務(wù)進行處理。

快速轉(zhuǎn)發(fā)（Fast-forward）假定服務(wù)處于大量使用中；在這種情況下就很容易看到，讀取圖像所花的時間中有多少是由于受到了寫入操作的影響（因為這兩個功能將競爭使用它們共享的資源）。取決于所采用的體系結(jié)構(gòu)，這種影響可能是巨大的。即使上傳和下載的速度完全相同（在絕大多數(shù)IP網(wǎng)絡(luò)中都不是這樣的情況，大部分下載速度和上傳速度之比都至少設(shè)計為3:1），文件讀取操作一般都是從高速緩存中進行的，而寫操作卻不得不進行最終的磁盤操作（而且可能要寫幾次才能達成最后的一致狀態(tài)）。即使所有內(nèi)容都已在內(nèi)存中，或者從磁盤（比如SSD磁盤）中進行讀取，數(shù)據(jù)庫寫入操作幾乎往往都要慢于讀取操作。（Pole Position是一個開源的DB基準測試工具，http://polepos.org/，測試結(jié)果參見 http://polepos.sourceforge.net/results/PolePositionClientServer.pdf）

這種設(shè)計另一個潛在的問題出在web服務(wù)器上，像Apache或者lighttpd通常都有一個能夠維持的并發(fā)連接數(shù)上限（默認情況下在500左右，不過可以更高）和最高流量數(shù)，它們會很快被寫操作消耗掉。因為讀操作可以異步進行，或者采用其它一些像gizp壓縮的性能優(yōu)化或者塊傳輸編碼方式，web服務(wù)器可以通過在多個請求服務(wù)之間切換來滿足比最大連接數(shù)更多的請求（一臺Apache的最大連接數(shù)設(shè)置為500，它每秒鐘提供近千次讀請求服務(wù)也是正常的）。寫操作則不同，它需要在上傳過程中保持連接，所以大多數(shù)家庭網(wǎng)絡(luò)環(huán)境下，上傳一個1MB的文件可能需要超過1秒的時間，所以web服務(wù)器只能處理500個這樣并發(fā)寫操作請求。

對于這種瓶頸，一個好的規(guī)劃案例是將讀取和寫入圖片分離為兩個獨立的服務(wù)，如圖Figure 1.2.所示。這讓我們可以單獨的擴展其中任意一個（因為有可能我們讀操作比寫操作要頻繁很多），同時也有助于我們理清每個節(jié)點在做什么。最后，這也避免了未來的憂慮，這使得故障診斷和查找問題更簡單，像慢讀問題。

這種方法的優(yōu)點是我們能夠單獨的解決各個模塊的問題-我們不用擔(dān)心寫入和檢索新圖片在同一個上下文環(huán)境中。這兩種服務(wù)仍然使用全球資料庫的圖片，但是它們可通過適當(dāng)?shù)姆?wù)接口自由優(yōu)化它們自己的性能（比如，請求隊列，或者緩存熱點圖片-在這之上的優(yōu)化）。從維護和成本角度來看，每個服務(wù)按需進行獨立規(guī)模的規(guī)劃，這點非常有用，試想如果它們都組合混雜在一起，其中一個無意間影響到了性能，另外的也會受影響。

當(dāng)然，上面的例子在你使用兩個不同端點時可以很好的工作（事實上，這非常類似于云存儲和內(nèi)容分發(fā)網(wǎng)絡(luò)）。雖然有很多方式來解決這樣的瓶頸，但每個都有各自的取舍。

比如，F(xiàn)lickr通過分配用戶訪問不同的分片解決這類讀/寫問題，每一個分片只可以處理一定數(shù)量的用戶，隨著用戶的增加更多的分片被添加到集群上（參看“Flickr縮影”的描述http://mysqldba.blogspot.com/2008/04/mysql-uc-2007-presentation-file.html）。在第一個例子中，可以根據(jù)實際用途更簡單的規(guī)劃硬件資源（在整個系統(tǒng)中讀和寫的比例），然而，F(xiàn)lickr規(guī)劃是根據(jù)用戶基數(shù)（假定每個用戶擁有相同的資源空間）。在前者中一個故障或者問題會導(dǎo)致整個系統(tǒng)功能的下降（比如，全部不能寫入文件了），然而Flickr一個分片的故障只會影響到相關(guān)的那部分用戶。在第一個例子中，更容易操作整個數(shù)據(jù)集-比如，在所有的圖像元數(shù)據(jù)上更新寫入服務(wù)用來包含新的元數(shù)據(jù)或者檢索-然而在Flickr架構(gòu)上每一個分片都需要執(zhí)行更新或者檢索（或者需要創(chuàng)建個索引服務(wù)來核對元數(shù)據(jù)-找出哪一個才是實際結(jié)果）。

冗余(Redundancy)

為了優(yōu)雅的處理故障，web架構(gòu)必須冗余它的服務(wù)和數(shù)據(jù)。例如，單服務(wù)器只擁有單文件的話，文件丟失就意味這永遠丟失了。丟失數(shù)據(jù)是個很糟糕的事情，常見的方法是創(chuàng)建多個或者冗余備份。

同樣的原則也適用于服務(wù)。如果應(yīng)用有一個核心功能，確保它同時運行多個備份或者版本可以安全的應(yīng)對單點故障。

在系統(tǒng)中創(chuàng)建冗余可以消除單點故障，可以在緊急時刻提供備用功能。例如，如果在一個產(chǎn)品中同時運行服務(wù)的兩個實例，當(dāng)其中一個發(fā)生故障或者降級(degrade)，系統(tǒng)可以轉(zhuǎn)移(failover)到好的那個備份上。故障轉(zhuǎn)移(Failover)可以自動執(zhí)行或者人工手動干預(yù)。

服務(wù)冗余的另一個關(guān)鍵部分是創(chuàng)建無共享(shared-nothing)架構(gòu)。采用這種架構(gòu)，每個接點都可以獨立的運作，沒有中心”大腦”管理狀態(tài)或者協(xié)調(diào)活動。這可以大大提高可伸縮性(scalability)因為新的接點可以隨時加入而不需要特殊的條件或者知識。而且更重要的是，系統(tǒng)沒有單點故障。所以可以更好的應(yīng)對故障。

例如，在我們的圖片服務(wù)應(yīng)用，所有的圖片應(yīng)該都冗余備份在另外的一個硬件上（理想的情況下，在不同的地理位置，以防數(shù)據(jù)中心發(fā)生大災(zāi)難，例如地震，火災(zāi)），而且訪問圖片的服務(wù)（見Figure 1.3.）-包括所有潛在的服務(wù)請求-也應(yīng)該冗余。（負載均衡器是個很好的方法冗余服務(wù)，但是下面的方法不僅僅是負載均衡）

Figure 1.3: 使用冗余的圖片存儲

#p#

分區(qū)

我們可能遇見單一服務(wù)器無法存放的龐大數(shù)據(jù)集。也可能遇到一個需要過多計算資源的操作，導(dǎo)致性能下降，急需增添容量。這些情況下，你都有兩種選擇：橫向或縱向擴展。

縱向擴展意味著對單一服務(wù)器增添更多資源。對于一個非常龐大的數(shù)據(jù)集，這可能意味著為單一服務(wù)器增加更多（或更大）的硬盤以存放整個數(shù)據(jù)集。而對于計算操作，這可能意味著將操作移到一個擁有更快的 CPU 或 更大的內(nèi)存的服務(wù)器中。無論哪種情況，縱向擴展都是為了使單個服務(wù)器能夠自己處理更多的方法。

另一方面，對于橫向擴展，則是增加更多的節(jié)點。例如龐大的數(shù)據(jù)集，你可以用第二個服務(wù)器來存放部分數(shù)據(jù)；而對于計算操作，你可以切割計算，或是通過額外的節(jié)點加載。想要充分的利用橫向擴展的優(yōu)勢，你應(yīng)該以內(nèi)在的系統(tǒng)構(gòu)架設(shè)計原則來實現(xiàn)，否則的話，實現(xiàn)的方法將會變成繁瑣的修改和切分操作。

說道橫向分區(qū)，更常見的技術(shù)是將你的服務(wù)分區(qū)，或分片。分區(qū)可以通過對每個功能邏輯集的分割分配而來;可以通過地域劃分，也可以通過類似付費 vs. 未付費用戶來區(qū)分。這種方式的優(yōu)勢是可以通過增添容量來運行服務(wù)或?qū)崿F(xiàn)數(shù)據(jù)存儲。

以我們的圖像服務(wù)器為例，將曾經(jīng)儲存在單一的文件服務(wù)器的圖片重新保存到多個文件服務(wù)器中是可以實現(xiàn)的，每個文件服務(wù)器都有自己惟一的圖片集。（見圖表1.4。）這種構(gòu)架允許系統(tǒng)將圖片保存到某個文件服務(wù)器中，在服務(wù)器都即將存滿時，像增加硬盤一樣增加額外的服務(wù)器。這種設(shè)計需要一種能夠?qū)⑽募痛娣欧?wù)器綁定的命名規(guī)則。一個圖像的名稱可能是映射全部服務(wù)器的完整散列方案的形式?；蛘呖蛇x的，每個圖像都被分配給一個遞增的 ID，當(dāng)用戶請求圖像時，圖像檢索服務(wù)只需要保存映射到每個服務(wù)器的 ID 范圍（類似索引）就可以了。

圖 1.4: 使用冗余和分區(qū)實現(xiàn)的圖片存儲服務(wù)

當(dāng)然，為多個服務(wù)器分配數(shù)據(jù)或功能是充滿挑戰(zhàn)的。一個關(guān)鍵的問題就是數(shù)據(jù)局部性；對于分布式系統(tǒng)，計算或操作的數(shù)據(jù)越相近，系統(tǒng)的性能越佳。因此，一個潛在的問題就是數(shù)據(jù)的存放遍布多個服務(wù)器，當(dāng)需要一個數(shù)據(jù)時，它們并不在一起，迫使服務(wù)器不得不為從網(wǎng)絡(luò)中獲取數(shù)據(jù)而付出昂貴的性能代價。

另一個潛在的問題是不一致性。當(dāng)多個不同的服務(wù)讀取和寫入同一共享資源時，有可能會遭遇競爭狀態(tài)——某些數(shù)據(jù)應(yīng)當(dāng)被更新，但讀取操作恰好發(fā)生在更新之前——這種情形下，數(shù)據(jù)就是不一致的。例如圖像托管方案中可能出現(xiàn)的競爭狀態(tài)，一個客戶端發(fā)送請求，將其某標題為“狗”的圖像改名為”小家伙“。而同時另一個客戶端發(fā)送讀取此圖像的請求。第二個客戶端中顯示的標題是“狗”還是“小家伙”是不能明確的。

當(dāng)然，對于分區(qū)還有一些障礙存在，但分區(qū)允許將問題——數(shù)據(jù)、負載、使用模式等——切割成可以管理的數(shù)據(jù)塊。這將極大的提高可擴展性和可管理性，但并非沒有風(fēng)險。有很多可以降低風(fēng)險，處理故障的方法；不過篇幅有限，不再贅述。若有興趣，可見于此文，獲取更多容錯和檢測的信息。

1.3. 構(gòu)建高效和可伸縮的數(shù)據(jù)訪問模塊

在設(shè)計分布式系統(tǒng)時一些核心問題已經(jīng)考慮到，現(xiàn)在讓我們來討論下比較困難的一部分：可伸縮的數(shù)據(jù)訪問。

對于大多數(shù)簡單的web應(yīng)用程序，比如LAMP系統(tǒng)，類似于圖 Figure 1.5.

Figure 1.5: 簡單web應(yīng)用程序

隨著它們的成長，主要發(fā)生了兩方面的變化：應(yīng)用服務(wù)器和數(shù)據(jù)庫的擴展。在一個高度可伸縮的應(yīng)用程序中，應(yīng)用服務(wù)器通常最小化并且一般是 shared-nothing架構(gòu)（譯注：shared nothing architecture是一 種分布式計算架構(gòu)，這種架構(gòu)中不存在集中存儲的狀態(tài)，整個系統(tǒng)中沒有資源競爭，這種架構(gòu)具有非常強的擴張性，在web應(yīng)用中廣泛使用）方式的體現(xiàn)，這使得系統(tǒng)的應(yīng)用服務(wù)器層水平可伸縮。由于這種設(shè)計，數(shù)據(jù)庫服務(wù)器可以支持更多的負載和服務(wù)；在這一層真正的擴展和性能改變開始發(fā)揮作用了。

剩下的章節(jié)主要集中于通過一些更常用的策略和方法提供快速的數(shù)據(jù)訪問來使這些類型服務(wù)變得更加迅捷。

Figure 1.6: Oversimplified web application

大多數(shù)系統(tǒng)簡化為如圖 Figure 1.6所示，這是一個良好的開始。如果你有大量的數(shù)據(jù)，你想快捷的訪問，就像一堆糖果擺放在你辦公室抽屜的最上方。雖然過于簡化，前面的聲明暗示了兩個困難的問題：存儲的可伸縮性和數(shù)據(jù)的快速訪問。

為了這一節(jié)內(nèi)容，我們假設(shè)你有很大的數(shù)據(jù)存儲空間（TB），并且你想讓用戶隨機訪問一小部分數(shù)據(jù)（查看Figure 1.7）。這類似于在圖像應(yīng)用的例子里在文件服務(wù)器定位一個圖片文件。

Figure 1.7: Accessing specific data

這非常具有挑戰(zhàn)性，因為它需要把數(shù)TB的數(shù)據(jù)加載到內(nèi)存中；并且直接轉(zhuǎn)化為磁盤的IO。要知道從磁盤讀取比從內(nèi)存讀取慢很多倍-內(nèi)存的訪問速度如同敏捷的查克·諾里斯（譯注：空手道冠軍），而磁盤的訪問速度就像笨重的卡車一樣。這個速度差異在大數(shù)據(jù)集上會增加更多；在實數(shù)順序讀取上內(nèi)存訪問速度至少是磁盤的6倍，隨機讀取速度比磁盤快100,000倍（參考“大數(shù)據(jù)之殤”http://queue.acm.org/detail.cfm?id=1563874）。另外，即使使用唯一的ID，解決獲取少量數(shù)據(jù)存放位置的問題也是個艱巨的任務(wù)。這就如同不用眼睛看在你的糖果存放點取出最后一塊Jolly Rancher口味的糖果一樣。

謝天謝地，有很多方式你可以讓這樣的操作更簡單些；其中四個比較重要的是緩存，代理，索引和負載均衡。本章的剩余部分將討論下如何使用每一個概念來使數(shù)據(jù)訪問加快。

緩存

緩存利用局部訪問原則：最近請求的數(shù)據(jù)可能會再次被請求。它們幾乎被用于計算機的每一層：硬件，操作系統(tǒng)，web瀏覽器，web應(yīng)用程序等等。緩存就像短期存儲的內(nèi)存：它有空間的限制，但是通常訪問速度比源數(shù)據(jù)源快并且包含了大多數(shù)最近訪問的條目。緩存可以在架構(gòu)的各個層級存在，但是常常在前端比較常見，在這里通常需要在沒有下游層級的負擔(dān)下快速返回數(shù)據(jù)。

在我們的API例子中如何使用緩存來快速訪問數(shù)據(jù)？在這種情況下，有兩個地方你可以插入緩存。一個操作是在你的請求層節(jié)點添加一個緩存，如圖 Figure 1.8.

Figure 1.8: Inserting a cache on your request layer node

直接在一個請求層節(jié)點配置一個緩存可以在本地存儲相應(yīng)數(shù)據(jù)。每次發(fā)送一個請求到服務(wù)，如果數(shù)據(jù)存在節(jié)點會快速的返回本地緩存的數(shù)據(jù)。如果數(shù)據(jù)不在緩存中，請求節(jié)點將在磁盤查找數(shù)據(jù)。請求層節(jié)點緩存可以存放在內(nèi)存和節(jié)點本地磁盤中（比網(wǎng)絡(luò)存儲快些）。

Figure 1.9: Multiple caches

當(dāng)你擴展這些節(jié)點后會發(fā)生什么呢？如圖Figure 1.9所示，如果請求層擴展為多個節(jié)點，每個主機仍然可能有自己的緩存。然而，如果你的負載均衡器隨機分配請求到節(jié)點，同樣的請求將指向不同的節(jié)點，從而增加了緩存的命中缺失率。有兩種選擇可以解決這個問題：全局緩存和分布式緩存。

#p#

全局緩存

全局緩存顧名思義：所有的節(jié)點使用同一個緩存空間，這涉及到添加一個服務(wù)器，或者某種文件存儲系統(tǒng)，速度比訪問源存儲和通過所有節(jié)點訪問要快些。每個請求節(jié)點以同樣的方式查詢本地的一個緩存，這種緩存方案可能有點復(fù)雜，因為在客戶端和請求數(shù)量增加時它很容易被壓倒，但是在有些架構(gòu)里它還是很有用的（尤其是那些專門的硬件來使全局緩存變得非常快，或者是固定數(shù)據(jù)集需要被緩存的）。

在描述圖中有兩種常見形式的緩存。在圖Figure 1.10中，當(dāng)一個緩存響應(yīng)沒有在緩存中找到時，緩存自身從底層存儲中查找出數(shù)據(jù)。在 Figure 1.11中，當(dāng)在緩存中招不到數(shù)據(jù)時，請求節(jié)點會向底層去檢索數(shù)據(jù)。

Figure 1.10: Global cache where cache is responsible for retrieval

Figure 1.11: Global cache where request nodes are responsible for retrieval

大多數(shù)使用全局緩存的應(yīng)用程序趨向于第一類，這類緩存可以管理數(shù)據(jù)的讀取，防止客戶端大量的請求同樣的數(shù)據(jù)。然而，一些情況下，第二類實現(xiàn)方式似乎更有意義。比如，如果一個緩存被用于非常大的文件，一個低命中比的緩存將會導(dǎo)致緩沖區(qū)來填滿未命中的緩存；在這種情況下，將使緩存中有一個大比例的總數(shù)據(jù)集。另一個例子是架構(gòu)設(shè)計中文件在緩存中存儲是靜態(tài)的并且不會被排除。（這可能是因為應(yīng)用程序要求周圍數(shù)據(jù)的延遲-某些片段的數(shù)據(jù)可能需要在大數(shù)據(jù)集中非常快-在有些地方應(yīng)用程序邏輯理清排除策略或者熱點 比緩存方案好使些）

分布式緩存

在分布式緩存（圖1.12）中，每個節(jié)點都會緩存一部分數(shù)據(jù)。如果把冰箱看作食雜店的緩存的話，那么分布式緩存就象是把你的食物分別放到多個地方 —— 你的冰箱、柜櫥以及便當(dāng)盒 ——放到這些便于隨時取用的地方就無需一趟趟跑去食雜店了。緩存一般使用一個具有一致性的哈希函數(shù)進行分割，如此便可在某請求節(jié)點尋找某數(shù)據(jù)時，能夠迅速知道要到分布式緩存中的哪個地方去找它，以確定改數(shù)據(jù)是否從緩存中可得。在這種情況下，每個節(jié)點都有一個小型緩存，在直接到原數(shù)據(jù)所作處找數(shù)據(jù)之前就可以向別的節(jié)點發(fā)出尋找數(shù)據(jù)的請求。由此可得，分布式緩存的一個優(yōu)勢就是，僅僅通過向請求池中添加新的節(jié)點便可以擁有更多的緩存空間。

分布式緩存的一個缺點是修復(fù)缺失的節(jié)點。一些分布式緩存系統(tǒng)通過在不同節(jié)點做多個備份繞過了這個問題；然而，你可以想象這個邏輯迅速變復(fù)雜了，尤其是當(dāng)你在請求層添加或者刪除節(jié)點時。即便是一個節(jié)點消失和部分緩存數(shù)據(jù)丟失了，我們還可以在源數(shù)據(jù)存儲地址獲取-因此這不一定是災(zāi)難性的!

Figure 1.12: Distributed cache

緩存的偉大之處在于它們使我們的訪問速度更快了（當(dāng)然前提是正確使用），你選擇的方法要在更多請求下更快才行。然而，所有這些緩存的代價是必須有額外的存儲空間，通常在放在昂貴的內(nèi)存中；從來沒有嗟來之食。緩存讓事情處理起來更快，而且在高負載情況下提供系統(tǒng)功能，否則將會使服務(wù)器出現(xiàn)降級。

有一個很流行的開源緩存項目Memcached (http://memcached.org/)（它可以當(dāng)做一個本地緩存，也可以用作分布式緩存）；當(dāng)然，還有一些其他操作的支持（包括語言包和框架的一些特有設(shè)置）。

Memcached 被用作很多大型的web站點，盡管他很強大，但也只是簡單的內(nèi)存key-value存儲方式，它優(yōu)化了任意數(shù)據(jù)存儲和快速檢索（o(1)）。

Facebook使用了多種不同的緩存來提高他們站點的性能（查看”Facebook caching and performance”）。在語言層面上（使用PHP內(nèi)置函數(shù)調(diào)用）他們使用$GLOBALSand APC緩存，這有助于使中間函數(shù)調(diào)用和結(jié)果返回更快（大多數(shù)語言都有這樣的類庫用來提高web頁面的性能）。Facebook使用的全局緩存分布在多個服務(wù)器上（查看 ”Scaling memcached at Facebook”），這樣一個訪問緩存的函數(shù)調(diào)用可以使用很多并行的請求在不同的Memcached 服務(wù)器上獲取存儲的數(shù)據(jù)。這使得他們在為用戶分配數(shù)據(jù)空間時有了更高的性能和吞吐量，同時有一個中央服務(wù)器做更新（這非常重要，因為當(dāng)你運行上千服務(wù)器時，緩存失效和一致性將是一個大挑戰(zhàn)）。

現(xiàn)在讓我們討論下當(dāng)數(shù)據(jù)不在緩存中時該如何處理···

代理

簡單來說，代理服務(wù)器是一種處于客戶端和服務(wù)器中間的硬件或軟件，它從客戶端接收請求，并將它們轉(zhuǎn)交給服務(wù)器。代理一般用于過濾請求、記錄日志或?qū)φ埱筮M行轉(zhuǎn)換(增加/刪除頭部、加密/解密、壓縮，等等)。

圖1.13: 代理服務(wù)器

當(dāng)需要協(xié)調(diào)來自多個服務(wù)器的請求時，代理服務(wù)器也十分有用，它允許我們從整個系統(tǒng)的角度出發(fā)、對請求流量執(zhí)行優(yōu)化。壓縮轉(zhuǎn)發(fā)(collapsed forwarding)是利用代理加快訪問的其中一種方法，將多個相同或相似的請求壓縮在同一個請求中，然后將單個結(jié)果發(fā)送給各個客戶端。

假設(shè)，有幾個節(jié)點都希望請求同一份數(shù)據(jù)，而且它并不在緩存中。在這些請求經(jīng)過代理時，代理可以通過壓縮轉(zhuǎn)發(fā)技術(shù)將它們合并成為一個請求，這樣一來，數(shù)據(jù)只需要從磁盤上讀取一次即可(見圖1.14)。這種技術(shù)也有一些缺點，由于每個請求都會有一些時延，有些請求會由于等待與其它請求合并而有所延遲。不管怎么樣，這種技術(shù)在高負載環(huán)境中是可以幫助提升性能的，特別是在同一份數(shù)據(jù)被反復(fù)訪問的情況下。壓縮轉(zhuǎn)發(fā)有點類似緩存技術(shù)，只不過它并不對數(shù)據(jù)進行存儲，而是充當(dāng)客戶端的代理人，對它們的請求進行某種程度的優(yōu)化。

在一個LAN代理服務(wù)器中，客戶端不需要通過自己的IP連接到Internet，而代理會將請求相同內(nèi)容的請求合并起來。這里比較容易搞混，因為許多代理同時也充當(dāng)緩存(這里也確實是一個很適合放緩存的地方)，但緩存卻不一定能當(dāng)代理。

圖1.14: 通過代理來合并請求

另一個使用代理的方式不只是合并相同數(shù)據(jù)的請求，同時也可以用來合并靠近存儲源（一般是磁盤）的數(shù)據(jù)請求。采用這種策略可以讓請求最大化使用本地數(shù)據(jù)，這樣可以減少請求的數(shù)據(jù)延遲。比如，一群節(jié)點請求B部分信息：partB1,partB2等，我們可以設(shè)置代理來識別各個請求的空間區(qū)域，然后把它們合并為一個請求并返回一個bigB，大大減少了讀取的數(shù)據(jù)來源（查看圖Figure 1.15）。當(dāng)你隨機訪問上TB數(shù)據(jù)時這個請求時間上的差異就非常明顯了！代理在高負載情況下，或者限制使用緩存時特別有用，因為它基本上可以批量的把多個請求合并為一個。

Figure 1.15: Using a proxy to collapse requests for data that is spatially close together

值得注意的是，代理和緩存可以放到一起使用，但通常最好把緩存放到代理的前面，放到前面的原因和在參加者眾多的馬拉松比賽中最好讓跑得較快的選手在隊首起跑一樣。因為緩存從內(nèi)存中提取數(shù)據(jù)，速度飛快，它并不介意存在對同一結(jié)果的多個請求。但是如果緩存位于代理服務(wù)器的另一邊，那么在每個請求到達 cache之前都會增加一段額外的時延，這就會影響性能。

如果你正想在系統(tǒng)中添加代理，那你可以考慮的選項有很多；Squid和Varnish都經(jīng)過了實踐檢驗，廣泛用于很多實際的web站點中。這些代理解決方案針對大部分client－server通信提供了大量的優(yōu)化措施。將二者之中的某一個安裝為web服務(wù)器層的反向代理（reverse proxy，下面負載均衡器一節(jié)中解釋）可以大大提高web服務(wù)器的性能，減少處理來自客戶端的請求所需的工作量。

索引

使用索引快速訪問數(shù)據(jù)是個優(yōu)化數(shù)據(jù)訪問性能公認的策略；可能我們大多數(shù)人都是從數(shù)據(jù)庫了解到的索引。索引用增長的存儲空間占用和更慢的寫（因為你必須寫和更新索引）來換取更快的讀取。

你可以把這個概念應(yīng)用到大數(shù)據(jù)集中就像應(yīng)用在傳統(tǒng)的關(guān)系數(shù)據(jù)存儲。索引要關(guān)注的技巧是你必須仔細考慮用戶會怎樣訪問你的數(shù)據(jù)。如果數(shù)據(jù)集有很多 TBs，但是每個數(shù)據(jù)包(payload)很小(可能只有1KB)，這時就必須用索引來優(yōu)化數(shù)據(jù)訪問。在這么大的數(shù)據(jù)集找到小的數(shù)據(jù)包是個很有挑戰(zhàn)性的工作因為你不可能在合理的時間內(nèi)遍歷所有數(shù)據(jù)。甚至，更有可能的是這么大的數(shù)據(jù)集分布在幾個（甚至很多個）物理設(shè)備上-這意味著你要用些方法找到期望數(shù)據(jù)的正確物理位置。索引是最適合的方法做這種事情。

Figure 1.16: Indexes

索引可以作為內(nèi)容的一個表格-表格的每一項指明你的數(shù)據(jù)存儲的位置。例如，如果你正在查找B的第二部分數(shù)據(jù)-你如何知道去哪里找？如果你有個根據(jù)數(shù)據(jù)類型(數(shù)據(jù)A，B，C)排序的索引，索引會告訴你數(shù)據(jù)B的起點位置。然后你就可以跳轉(zhuǎn)(seek)到那個位置，讀取你想要的數(shù)據(jù)B的第二部分。 (See Figure 1.16.)

這些索引常常存儲在內(nèi)存中，或者存儲在對于客戶端請求來說非常快速的本地位置(somewhere very local)。Berkeley DBs (BDBs)和樹狀數(shù)據(jù)結(jié)構(gòu)常常按順序存儲數(shù)據(jù)，非常理想用來存儲索引。

常常索引有很多層，當(dāng)作數(shù)據(jù)地圖，把你從一個地方指向另外一個地方，一直到你的得到你想要的那塊數(shù)據(jù)。(See Figure 1.17.)

Figure 1.17: Many layers of indexes

索引也可以用來創(chuàng)建同樣數(shù)據(jù)的多個不同視圖(views)。對于大數(shù)據(jù)集來說，這是個很棒的方法來定義不同的過濾器(filter)和類別(sort)，而不用創(chuàng)建多個額外的數(shù)據(jù)拷貝。

例如，想象一下，圖片存儲系統(tǒng)開始實際上存儲的是書的每一頁的圖像，而且服務(wù)允許客戶查詢這些圖片中的文字，搜索每個主題的所有書的內(nèi)容，就像搜索引擎允許你搜索HTML內(nèi)容一樣。在這種情況下，所有的書的圖片占用了很多很多服務(wù)器存儲，查找其中的一頁給用戶顯示有點難度。首先，用來查詢?nèi)我庠~或者詞數(shù)組(tuples)的倒排索引(inverse indexes)需要很容易的訪問到；然后，導(dǎo)航到那本書的確切頁面和位置并獲取準確的圖片作為返回結(jié)果，也有點挑戰(zhàn)性。所以，這種境況下，倒排索引應(yīng)該映射到每個位置(例如書B)，然后B要包含一個索引每個部分所有單詞，位置和出現(xiàn)次數(shù)的索引。

可以表示上圖Index1的一個倒排索引，可能看起來像下面的樣子-每個詞或者詞數(shù)組對應(yīng)一個包含他們的書。

這個中間索引可能看起來像上面的樣子，但是可能只包含詞，位置和書B的信息。這種嵌套的索引架構(gòu)要使每個子索引占用足夠小的空間，以防所有的這些信息必須保存在一個大的倒排索引中。

這是大型系統(tǒng)的關(guān)鍵點，因為即使壓縮，這些索引也太大，太昂貴（expensive）而難以存儲。在這個系統(tǒng)，如果我們假設(shè)我們世界上的很多書-100,000,000 (see Inside Google Books blog post)-每個書只有10頁(只是為了下面好計算)，每頁有250個詞，那就是2500億(250 billion)個詞。如果我們假設(shè)每個詞有5個字符，每個字符占用8位(或者1個字節(jié)，即使某些字符要用2個字節(jié))，所以每個詞占用5個字節(jié)，那么每個詞即使只包含一次，這個索引也要占用超過1000GB存儲空間。那么，你可以明白創(chuàng)建包含很多其他信息-詞組，數(shù)據(jù)位置和出現(xiàn)次數(shù)-的索引，存儲空間增長多快了吧。

創(chuàng)建這些中間索引和用更小分段表示數(shù)據(jù)，使的大數(shù)據(jù)問題可以得到解決。數(shù)據(jù)可以分散到多個服務(wù)器，訪問仍然很快。索引是信息檢索 (information retrieval)的奠基石，是現(xiàn)代搜索引擎的基礎(chǔ)。當(dāng)然，我們這段只是淺顯的介紹，還有其他很多深入研究沒有涉及-例如如何使索引更快，更小，包含更多信息(例如關(guān)聯(lián)(relevancy))，和無縫的更新（在競爭條件下(race conditions)，有一些管理性難題；在海量添加或者修改數(shù)據(jù)的更新中，尤其還涉及到關(guān)聯(lián)(relevancy)和得分(scoring)，也有一些難題）。

快速簡便的查找到數(shù)據(jù)是很重要的；索引是可以達到這個目的有效簡單工具。

負載均衡器

最后還要講講所有分布式系統(tǒng)中另一個比較關(guān)鍵的部分，負載均衡器。負載均衡器是各種體系結(jié)構(gòu)中一個不可或缺的部分，因為它們擔(dān)負著將負載在處理服務(wù)請求的一組節(jié)點中進行分配的任務(wù)。這樣就可以讓系統(tǒng)中的多個節(jié)點透明地服務(wù)于同一個功能（參見圖1.18）。它的主要目的就是要處理大量并發(fā)的連接并將這些連接分配給某個請求處理節(jié)點，從而可使系統(tǒng)具有伸縮性，僅僅通過添加新節(jié)點便能處理更多的請求。

圖1.18: 負載均衡器

用于處理這些請求的算法有很多種，包括隨機選取節(jié)點、循環(huán)式選取，甚至可以按照內(nèi)存或CPU的利用率等等這樣特定的條件進行節(jié)點選取。負載均衡器可以用軟件或硬件設(shè)備來實現(xiàn)。近來得到廣泛應(yīng)用的一個開源的軟件負載均衡器叫做 HAProxy）。

在分布式系統(tǒng)中，負載均衡器往往處于系統(tǒng)的最前端，這樣所有發(fā)來的請求才能進行相應(yīng)的分發(fā)。在一些比較復(fù)雜的分布式系統(tǒng)中，將一個請求分發(fā)給多個負載均衡器也是常事，如圖1.19所示。

圖1.19: 多重負載均衡器

和代理類似，有些負載均衡器還可以基于請求的類型對不同的請求進行不同的處理（技術(shù)上講，這樣的叫做反向代理）。

負載均衡器面臨的一個難題是怎么管理同用戶的session相關(guān)的數(shù)據(jù)。在電子商務(wù)網(wǎng)站中，如果你只有一個客戶端，那么很容易就可以把用戶放入購物車里的東西保存起來，等他下次訪問訪問時購物車里仍能看到那些東西（這很重要，因為當(dāng)用戶回來發(fā)現(xiàn)仍然呆在購物車里的產(chǎn)品時很有可能就會買它）。然而，如果在一個session中將用戶分發(fā)到了某個節(jié)點，但該用戶下次訪問時卻分發(fā)到了另外一個節(jié)點，這里就有可能產(chǎn)生不一致性，因為新的節(jié)點可能就沒有保留下用戶購物車里的東西。（要是你把6盒子子農(nóng)夫山泉放到購物車里了，可下次回來一看購物車空了，難道你不會發(fā)火嗎？） 解決該問題的一個方法是可以使session具有保持性，讓同一用戶總是分發(fā)到同一個節(jié)點之上，但這樣一來就很難利用類似failover這樣的可靠性措施了。如果這樣的話，用戶的購物車里的東西不會丟，但如果用戶保持的那個節(jié)點失效，就會出現(xiàn)一種特殊的情況，購物車里的東西不會丟這個假設(shè)再也不成立了（雖然但愿不要把這個假設(shè)寫到程序里）。當(dāng)然，這個問題還可以用本章中講到的其它策略和工具來解決，比如服務(wù)以及許多并沒有講到的方法（象服務(wù)器緩存、 cookie以及URL重寫）。

如果系統(tǒng)中只有不太多的節(jié)點，循環(huán)式（round robin）DNS系統(tǒng)這樣的方案也許更有意義，因為負載均衡器可能比較貴，而且還額外增加了一層沒必要的復(fù)雜性。當(dāng)然，在比較大的系統(tǒng)中會有各種各樣的調(diào)度以及負載均衡算法，簡單點的有隨機選取或循環(huán)式選取，復(fù)雜點的可以考慮上利用率以及處理能力這些因素。所有這些算法都是對瀏覽和請求進行分發(fā)，并能提供很有用的可靠性工具，比如自動failover或者自動提出失效節(jié)點（比如節(jié)點失去響應(yīng)）。然而，這些高級特性會讓問題診斷難以進行。例如，當(dāng)系統(tǒng)載荷較大時，負載均衡器可能會移除慢速或者超時的節(jié)點（由于節(jié)點要處理大量請求），但對其它節(jié)點而言，這么做實際上是加劇了情況的惡化程度。在這時進行大量的監(jiān)測非常重要，因為系統(tǒng)總體流量和吞吐率可能看上去是在下降（因為節(jié)點處理的請求變少了），但個別節(jié)點卻越來越忙得不可開交。

負載均衡器是一種能讓你擴展系統(tǒng)能力的簡單易行的方式，和本文中所講的其它技術(shù)一樣，它在分布式系統(tǒng)架構(gòu)中起著基礎(chǔ)性的作用。負載均衡器還要提供一個比較關(guān)鍵的功能，它必需能夠探測出節(jié)點的運行狀況，比如，如果一個節(jié)點失去響應(yīng)或處于過載狀態(tài)，負載均衡器可以將其總處理請求的節(jié)點池中移除出去，還接著使用系統(tǒng)中冗余的其它不同節(jié)點。

#p#

隊列

目前為止我們已經(jīng)介紹了許多更快讀取數(shù)據(jù)的方法，但另一個使數(shù)據(jù)層具伸縮性的重要部分是對寫的有效管理。當(dāng)系統(tǒng)簡單的時候，只有最小的處理負載和很小的數(shù)據(jù)庫，寫的有多快可以預(yù)知；然而，在更復(fù)雜的系統(tǒng)，寫可能需要幾乎無法決定的長久時間。例如，數(shù)據(jù)可能必須寫到不同數(shù)據(jù)庫或索引中的幾個地方，或者系統(tǒng)可能正好處于高負載。這些情況下，寫或者任何那一類任務(wù)，有可能需要很長的時間，追求性能和可用性需要在系統(tǒng)中創(chuàng)建異步；一個通常的做到那一點的辦法是通過隊列。

Figure 1.20: Synchronous request

設(shè)想一個系統(tǒng)，每個客戶端都在發(fā)起一個遠程服務(wù)的任務(wù)請求。每一個客戶端都向服務(wù)器發(fā)送它們的請求，服務(wù)器盡可能快的完成這些任務(wù)，并分別返回結(jié)果給各個客戶端。在一個小型系統(tǒng)，一個服務(wù)器（或邏輯服務(wù)）可以給傳入的客戶端請求提供迅速服務(wù)，就像它們來的一樣快，這種情形應(yīng)該工作的很好。然而，當(dāng)服務(wù)器收到了超過它所能處理數(shù)量的請求時，每個客戶端在產(chǎn)生一個響應(yīng)前，將被迫等待其他客戶端的請求結(jié)束。這是一個同步請求的例子，示意在圖1.20。

這種同步的行為會嚴重的降低客戶端性能；客戶端被迫等待，有效的執(zhí)行零工作，直到它的請求被應(yīng)答。添加額外的服務(wù)器承擔(dān)系統(tǒng)負載也不會解決這個問題；即使是有效的負載均衡，為了最大化客戶端性能，保證平等的公平的分發(fā)工作也是極其困難的。而且，如果服務(wù)器處理請求不可及，或者失敗了，客戶端上行也會失敗。有效解決這個問題在于，需要在客戶端請求與實際的提供服務(wù)的被執(zhí)行工作之間建立抽象。

圖 1.21:用隊列管理請求

進入隊列。一個隊列就像它聽起來那么簡單：一個任務(wù)進入，被加入隊列然后工人們只要有能力去處理就會拿起下一個任務(wù)。（看圖1.21）這些任務(wù)可能是代表了簡單的寫數(shù)據(jù)庫，或者一些復(fù)雜的事情，像為一個文檔生成一個縮略預(yù)覽圖一類的。當(dāng)一個客戶端提交一個任務(wù)請求到一個隊列，它們再也不會被迫等待結(jié)果；它們只需要確認請求被正確的接收了。這個確認之后可能在客戶端請求的時候，作為一個工作結(jié)果的參考。

隊列使客戶端能以異步的方式工作，提供了一個客戶端請求與其響應(yīng)的戰(zhàn)略抽象。換句話說，在一個同步系統(tǒng)，沒有請求與響應(yīng)的區(qū)別，因此它們不能被單獨的管理。在一個異步的系統(tǒng)，客戶端請求一個任務(wù)，服務(wù)端響應(yīng)一個任務(wù)已收到的確認，然后客戶端可以周期性的檢查任務(wù)的狀態(tài)，一旦它結(jié)束就請求結(jié)果。當(dāng)客戶端等待一個異步的請求完成，它可以自由執(zhí)行其它工作，甚至異步請求其它的服務(wù)。后者是隊列與消息在分布式系統(tǒng)如何成為杠桿的例子。

隊列也對服務(wù)中斷和失敗提供了防護。例如，創(chuàng)建一個高度強健的隊列，這個隊列能夠重新嘗試由于瞬間服務(wù)器故障而失敗的服務(wù)請求，是非常容易的事。相比直接暴露客戶端于間歇性服務(wù)中斷，需要復(fù)雜的而且經(jīng)常矛盾的客戶端錯誤處理程序，用一個隊列去加強服務(wù)質(zhì)量的擔(dān)保更為可取。

隊列對管理任何大規(guī)模分布式系統(tǒng)不同部分之間的分布式通信，是一個基礎(chǔ)，而且實現(xiàn)它們有許多的方法。有不少開源的隊列如 RabbitMQ, ActiveMQ, BeanstalkD，但是有些也用像 Zookeeper的服務(wù)，或者甚至像Redis的數(shù)據(jù)存儲。

1.4. 結(jié)論

設(shè)計有效的系統(tǒng)來進行快速的大數(shù)據(jù)訪問是有趣的，同時有大量的好工具來幫助各種各樣的應(yīng)用程序進行設(shè)計。 這文章只覆蓋了一些例子，僅僅是一些表面的東西，但將會越來越多–同時在這個領(lǐng)域里一定會繼續(xù)有更多創(chuàng)新東西。

英文原文：Scalable Web Architecture and Distributed Systems

譯文鏈接：http://www.oschina.net/translate/scalable-web-architecture-and-distributed-systems