采用分布式系統架構是由於業務需求決定的，若系統要求具備如下特性，便可考慮采用分布式架構來實現：
1.數據存儲的分區容錯，冗余
2.應用的大訪問、高性能要求
3.應用的高可用要求，故障轉移
分布式系統遵循幾個基本原則
1.CAP原理
CAP Theorem，CAP原理中，有三個要素：
一致性(Consistency)
可用性(Availability)
分區容忍性(Partition tolerance)
CAP原理指的是，在分布式系統中這三個要素最多只能同時實現兩點，不可能三者兼顧。因此在進行分布式架構設計時，必須做出取舍。而對於分布式數據系統，分區容忍性是基本要求，否則就失去了價值。因此設計分布式數據系統，就是在一致性和可用性之間取一個平衡。對於大多數web應用，其實並不需要強一致性，因此犧牲一致性而換取高可用性，是目前多數分布式數據庫產品的方向。
從客戶端角度，多進程並發訪問時，更新過的數據在不同進程如何獲取的不同策略，決定了不同的一致性。對於關系型數據庫，要求更新過的數據能被后續的訪問都能看到，這是強一致性。如果能容忍后續的部分或者全部訪問不到，則是弱一致性。如果經過一段時間后要求能訪問到更新后的數據，則是最終一致性。
但web應用也有例外，比如支付寶系統，就要求數據（銀行賬戶）的強一致性，而且面對大量淘寶用戶，可用性要求很高，因此只能犧牲數據的分區冗余。這一點也曾在和支付寶工程師交流時，得到驗證。
2.C10K問題
分布式系統另一個理論是C10K問題，即系統的並發用戶增加1萬（customer ten thousand，過去一台服務器承載假設為1萬用戶，現在平均3～5萬），是否意味着增加一台機器就能解決問題？答案通常是否定
因為這涉及到系統的應用架構問題----串行系統和並行系統的架構和性能提升的關系：
串行系統一般設備越多，性能成一條向下彎曲的曲線，最差情況，可能性能不增反降；而並行分布式系統設備越多，性能是正比例線性增長的直線
3.串行系統和並行系統的可靠性問題
一個大系統一般都有超過 30 個環節（串行）：如果每個環節都做到 99% 的准確率，最終系統的准確率是 74%; 如果每個環節都做到98%的准確率，最終系統的准確率 54%。一個 74% 的系統是可用的（有商業價值的），一個 54% 的系統僅比隨機稍好一點，不可用。這就是做大系統的魅力和挑戰！
而以上描述只是各模塊串行系統所遇到的問題
如果是並行系統，准確率=1-(1-A)^B ，其中A是單個模塊准確率，B是並行模塊個數
如系統中每個模塊的准確率是70%，那么3個模塊並行，整體准確率=1-0.3^3=97.3%,如果是4個並行，准確率=1-0.3^4=99.19%,我在想這就是負載均衡靠譜的數學原理
5個9或6個9的QoS一定是指數思維的結果，線性思維等於送死
而對系統單一模塊優化，准確性和可用性提升一個百分點，越接近100%，難度越大，投入成本越不可控（系統熵永不為零）
因此可靠性系統必然選擇並行分布式作為架構的基本方法。
從數據的存儲角度，多份冗余也是可靠性保障的一個方法。分布式存儲的冗余備份常規是3份（aws就這么干的），古埃及的羅塞塔rosetta石碑用古埃及象形文字、埃及拼音和古希臘文三種文字記錄一段歷史，就算象形文字缺了一部分，沒人能看懂，也能破譯補全，這大概也是raid5的思想起源吧
分布式系統架構的實踐
1.分布式存儲架構
分布式存儲架構現階段有3種模式
1.1一種是物理存儲采用集中式，存儲節點采用多實例的方式，如NFS掛載SAN、NAS等等
1.2第二種是帶有中央控制器的分布式存儲，如luster、moosefs、googlefs等等，一般特征是具備2個角色metadata server和storage node，將文件的元數據（描述數據的數據，如文件位置、大小等等）和數據塊文件分開存儲
其中metadata server除保存文件的元數據外，還維護存儲節點的ip、狀態等信息
luster的典型架構
MDS--meatadata server
MDT--metadata target
OSS--obj storage server
OST--obj starage target
其中MDT和OST是可以掛在NAS等中央存儲上的；可見，luster借鑒了上面中央存儲的模式，無論元數據服務還是節點服務都將服務實例和存儲分離，但進化了一步，將元數據和數據塊分離
luster系統很好解決了數據分布式存儲，，在超級計算領域Lustre應用廣泛，如美國LLNL國家實驗室計算機系統、我國的天河超級計算機系統均采用Lustre搭建分布式存儲系統。Lustre在全球排名前30個超級計算機系統中有15個在使用。
但有一個問題，就是metadata server的SPoF（single point of failure）問題，即單點故障；一旦metadata server掛了，整個集群也就掛了。實際應用中，是有解決方案的，如dell的官網有個pdf，就是采用heart beat和drbd網絡raid的方式，啟動2個實例，再如和keepalived一起組成故障轉移的方案等等，可以自己試試
再來看moosefs架構
moosefs架構和luster很相似，但進化了一步，mater（也就是metadata server）可以有從機備份了，而且可以多個
而且服務實例和存儲放在一起，沒有像luster，自此服務和數據不離不棄了；其實luster也可以簡化成不離不棄模式，moosefs也可以學他搞個后端存儲，但隨着雲計算、追求低成本的趨勢，采用SAN這樣存儲設備就太貴了
1.3第三種分布式存儲是去中心化、全對稱的架構（non-center or symmetric）
其設計思想是采用一致性哈希consistent hash算法（DHT的一種實現，關於一致性hash具體參考后面的鏈接）來定位文件在存儲節點中的位置，從而取消了metadata server的角色
整個系統只有storage node一個角色，不區分元數據和數據塊；
典型系統如sheepdog，但sheepdog是為滿足kvm鏡像和類EBS塊存儲而設計的，不是常規的分布式文件系統，架構如下
為了維護存儲節點的信息，一般采用P2P技術的totem single ring算法（corosync是一種實現）來維護和更新node路由信息
對稱架構有一個問題，采用totem single ring算法的存儲節點數量有限，因為node數量超過1000，集群內的通信風暴就會產生（此處更正，應該是環太大，令牌傳遞效率下降，不會產生通信風暴），效率下降，sheepdog提出了一個解決方案，就是在一致性hash環上做嵌套處理，如圖
1.4半對稱結構
其實介於1.2metadata server中央控制和1.3全對稱的架構之間還有一種，就是把metadata也做成對稱結構，我們可以稱半對稱結構，典型應用如fastdfs，淘寶一大牛fishman寫的，主要用作圖片存儲，可以實現排重存儲
看圖，tracker cluster就是metadata server的角色，實現了對稱架構設計
國內幾個大的網站都使用了fastdfs，在實際使用中，發現storage server之間同步數據較慢，一直沒仔細研究
2.分布式數據庫
分布式數據庫一般都基於分布式文件系統實現數據的分片sharding，每中數據庫都有自己的應用特性，就不做介紹，列出幾個典型的應用，供參考
Google的big table，實現數據的追加存儲append，順序寫入快速，不適合隨機讀的場景
hadoop的HBase
mongodb
hypertable 2010年以前，百度在用，今年infoq的中國qcon，百度的楊棟也講了百度用hypertable的血淚史
3.分布式應用架構
分布式應用架構涉及具體應用場景，設計上除考慮上面的CAP和C10K等等經典分布式理論，還應根據業務進行權衡。
基本的思路是
3.1在做完需求和模塊設計后，要對各模塊進行解藕Decoupling
傳統的企業應用設計一般是一條操作從頭跑到尾（串行系統），拿視頻網站的流程距離，傳統應用設計是先上傳是視頻，然后存儲，編碼，最后發布一條龍
如下圖
3.2在進行分布式設計時，先將各模塊解藕，通過異步消息通知的方式將各模塊鏈接，如下圖
3.3最后，
要考慮這個應用的壓力承載點在哪，根據用戶規模估算各模塊的並行數量（如本例中的encode壓力大，就增加encode模塊的並行系統數量），如下圖
以上是分布式系統構建的基本原則和實踐步驟，在實際應用中，仍有很多細節要考慮。但有一點要再強調，就是要根據業務來選擇各層、各模塊的技術，做好業務適用、成本和難度之間的權衡。
技術本無好壞，在於適當的使用和積累。
參考：