在計算機領域,當單機性能達到瓶頸時,有兩種方式能夠解決性能問題,一是堆硬件,進一步提高配置,二是分佈式,水平擴展。固然,二者都是同樣的燒錢。
今天聊聊我所理解的分佈式系統的架構思路。html
平時接觸到的分佈式系統有不少種,好比分佈式文件系統,分佈式數據庫,分佈式WebService,分佈式計算等等,面向的情景不一樣,但分佈式的思路是不是同樣的呢?nginx
假設咱們有一臺服務器,它能夠承擔1百萬/秒的請求,這個請求能夠的是經過http訪問網頁,經過tcp下載文件,jdbc執行sql,RPC調用接口…,如今咱們有一條數據的請求是2百萬/秒,很顯然服務器hold不住了,會各類拒絕訪問,甚至崩潰,宕機,怎麼辦呢。一臺機器解決不了的問題,那就兩臺。因此咱們加一臺機器,每臺承擔1百萬。若是請求繼續增長呢,兩臺解決不了的問題,那就三臺唄。這種方式咱們稱之爲水平擴展。如何實現請求的平均分配即是負載均衡了。web
另外一個栗子,咱們如今有兩個數據請求,數據1 90萬,數據2 80萬,上面那臺機器也hold不住,咱們加一臺機器來負載均衡一下,每臺機器處理45萬數據1和40萬數據2,可是平分太麻煩,不如一臺處理數據1,一臺處理數據2,一樣能解決問題,這種方式咱們稱之爲垂直拆分。算法
水平擴展和垂直拆分是分佈式架構的兩種思路,但並非一個二選一的問題,更多的是兼併合用。下面介紹一個實際的場景。這也是許多互聯網的公司架構思路。sql
我此時所在的公司的計算機系統很龐大,天然是一個整的分佈式系統,爲了方便組織管理,公司將整個技術部按業務和平臺拆分爲部門,訂單的,會員的,商家的等等,每一個部門有本身的web服務器集羣,數據庫服務器集羣,經過同一個網站訪問的連接可能來自於不一樣的服務器和數據庫,對網站及底層對數據庫的訪問被分配到了不一樣的服務器集羣,這個即是典型的按業務作的垂直拆分,每一個部門的服務器在hold不住時,會有彈性的擴展,這即是水平擴展。數據庫
在數據庫層,有些表很是大,數據量在億級,若是隻是純粹的水平的擴展並不必定最好,若是對錶進行拆分,好比能夠按用戶id進行水平拆表,經過對id取模的方式,將用戶劃分到多張表中,同時這些表也能夠處在不一樣的服務器。按業務的垂直拆庫和按用戶水平拆表是分佈式數據庫中通用的解決方案。服務器
前面咱們談到了分佈式來解決性能問題,但其附帶的問題是怎麼分佈,即如何負載均衡。這裏要解決的問題是當客戶端請求時,應該讓它請求分佈式系統中哪一臺服務器,一般的作法是經過一臺中間服務器來給客服端分配目標服務器。架構
這裏一樣拿兩個不一樣的分佈式系統作說明,下圖左邊是分佈式文件系統FastDFS,右邊是一個用於分佈式的RPC中間件。負載均衡
其中tracker即是負載均衡服務器,storage是存儲文件和處理上傳下載請求的服務器。框架
zookeeper是分佈式系統中一個負載均衡框架,google的chubby的一個開源實現,是是Hadoop和Hbase的重要組件。
一樣的在http中,常據說的nginx也是一個負載均衡服務器,它面向的是分佈式web服務器。至於具體的負載均衡算法輪詢,hash等這裏就不深刻了。
分佈式系統中,解決了負載均衡的問題後,另一個問題就是數據的一致性了,這個就須要經過同步來保障。根據不一樣的場景和需求,同步的方式也是有選擇的。
在分佈式文件系統中,好比商品頁面的圖片,若是進行了修改,同步要求並不高,就算有數秒甚至數分鐘的延遲都是能夠接受的,由於通常不會產生損失性的影響,所以能夠簡單的經過文件修改的時間戳,隔必定時間掃描同步一次,能夠犧牲一致性來提升效率。
但銀行中的分佈式數據庫就不同了,一丁點不一樣步就是沒法接受的,甚至能夠經過加鎖等犧牲性能的方式來保障徹底的一致。
在一致性算法中paxos算法是公認的最好的算法,chubby、zookeeper中paxos是它保證一致性的核心。這個算法比較難懂,我目前也沒弄懂,這裏就不深刻了。
接觸過這麼多分佈式系統後發現,它們的設計思路是如此的類似,這或許就是萬法歸一吧。
轉自:http://www.cnblogs.com/chulung/p/5653135.html