一、前言

在計算機領域，當單機性能達到瓶頸時，有兩種方式可以解決性能問題，一是堆硬件，進一步提升配置，二是分布式，水平擴展。當然，兩者都是一樣的燒錢。
今天聊聊我所理解的分布式系統的架構思路。

二、分布式系統的兩種方式

平時接觸到的分布式系統有很多種，比如分布式文件系統，分布式數據庫，分布式WebService，分布式計算等等，面向的情景不同，但分布式的思路是否是一樣的呢?

1.簡單的例子

假設我們有一臺服務器，它可以承擔1百萬/秒的請求，這個請求可以的是通過http訪問網頁，通過tcp下載文件，jdbc執行sql，RPC調用接口…，現在我們有一條數據的請求是2百萬/秒，很顯然服務器hold不住了，會各種拒絕訪問，甚至崩潰，宕機，怎麽辦呢。一臺機器解決不了的問題，那就兩臺。所以我們加一臺機器，每臺承擔1百萬。如果請求繼續增加呢，兩臺解決不了的問題，那就三臺唄。這種方式我們稱之為水平擴展

另一個栗子，我們現在有兩個數據請求，數據1 90萬，數據2 80萬，上面那臺機器也hold不住，我們加一臺機器來負載均衡一下，每臺機器處理45萬數據1和40萬數據2，但是平分太麻煩，不如一臺處理數據1，一臺處理數據2，同樣能解決問題，這種方式我們稱之為垂直拆分。

水平擴展和垂直拆分是分布式架構的兩種思路，但並不是一個二選一的問題，更多的是兼並合用。下面介紹一個實際的場景。這也是許多互聯網的公司架構思路。

2.實際的例子

我此時所在的公司的計算機系統很龐大，自然是一個整的分布式系統，為了方便組織管理，公司將整個技術部按業務和平臺拆分為部門，訂單的，會員的，商家的等等，每個部門有自己的web服務器集群，數據庫服務器集群，通過同一個網站訪問的鏈接可能來自於不同的服務器和數據庫，對網站及底層對數據庫的訪問被分配到了不同的服務器集群,這個便是典型的按業務做的垂直拆分

在數據庫層，有些表非常大，數據量在億級，如果只是純粹的水平的擴展並不一定最好，如果對表進行拆分，比如可以按用戶id進行水平拆表，通過對id取模的方式，將用戶劃分到多張表中，同時這些表也可以處在不同的服務器。按業務的垂直拆庫和按用戶水平拆表是分布式數據庫中通用的解決方案。

三、負載均衡

前面我們談到了分布式來解決性能問題，但其附帶的問題是怎麽分布，即如何負載均衡。這裏要解決的問題是當客戶端請求時，應該讓它請求分布式系統中哪一臺服務器，通常的做法是通過一臺中間服務器來給客服端分配目標服務器。

這裏同樣拿兩個不同的分布式系統做說明，下圖左邊是分布式文件系統FastDFS,右邊是一個用於分布式的RPC中間件。

• FastDFS的一次文件下載請求過程是這樣的
  1.client詢問tracker可以下載指定文件的storage；
  2.tracker返回一臺可用的storage；
  3.client直接和storage通信完成文件下載。

其中tracker便是負載均衡服務器，storage是存儲文件和處理上傳下載請求的服務器。

• 而另一個RPC中間件Hedwig也是類似的
  1.client詢問zookeeper哪臺server可以執行請求；
  2.zookeeper返回一臺可用server；
  3.client直接與service完成一次RPC。

zookeeper是分布式系統中一個負載均衡框架，google的chubby的一個開源實現，是是Hadoop和Hbase的重要組件。

同樣的在http中，常聽說的nginx也是一個負載均衡服務器，它面向的是分布式web服務器。至於具體的負載均衡算法輪詢，hash等這裏就不深入了。

四、同步

分布式系統中，解決了負載均衡的問題後，另外一個問題就是數據的一致性了，這個就需要通過同步來保障。根據不同的場景和需求，同步的方式也是有選擇的。

在分布式文件系統中，比如商品頁面的圖片，如果進行了修改，同步要求並不高，就算有數秒甚至數分鐘的延遲都是可以接受的，因為一般不會產生損失性的影響，因此可以簡單的通過文件修改的時間戳，隔一定時間掃描同步一次，可以犧牲一致性來提高效率。

但銀行中的分布式數據庫就不一樣了，一丁點不同步就是無法接受的，甚至可以通過加鎖等犧牲性能的方式來保障完全的一致。

在一致性算法中paxos算法是公認的最好的算法，chubby、zookeeper中paxos是它保證一致性的核心。這個算法比較難懂，我目前也沒弄懂，這裏就不深入了。

五、結語

接觸過這麽多分布式系統後發現，它們的設計思路是如此的相似，這或許就是萬法歸一吧。

轉自：http://www.cnblogs.com/chulung/p/5653135.html

(轉)分布式系統架構概論