分布式系統(tǒng)的架構(gòu)思路_第1頁
分布式系統(tǒng)的架構(gòu)思路_第2頁
分布式系統(tǒng)的架構(gòu)思路_第3頁
全文預覽已結(jié)束

下載本文檔

版權(quán)說明:本文檔由用戶提供并上傳,收益歸屬內(nèi)容提供方,若內(nèi)容存在侵權(quán),請進行舉報或認領

文檔簡介

1、分布式系統(tǒng)的架構(gòu)思路一、前言在計算機領域,當單機性能達到瓶頸時,有兩種方式可以解決性能問題,一是堆硬件,進一步提升配置,二是分布式,水平擴展。當然,兩者都是一樣的燒錢。今天聊聊我所理解的分布式系統(tǒng)的架構(gòu)思路。二、分布式系統(tǒng)的兩種方式平時接觸到的分布式系統(tǒng)有很多種,比如分布式文件系統(tǒng),分布式數(shù)據(jù)庫,分布式WebService,分布式計算等等,面向的情景不同,但分布式的思路是否是一樣的呢?1.簡單的例子假設我們有一臺服務器,它可以承擔1百萬/秒的請求,這個請求可以的是通過http訪問網(wǎng)頁,通過tcp下載文件,jdbc執(zhí)行sql,RPC調(diào)用接口,現(xiàn)在我們有一條數(shù)據(jù)的請求是2百萬/秒,很顯然服務器ho

2、ld不住了,會各種拒絕訪問,甚至崩潰,宕機,怎么辦呢。一臺機器解決不了的問題,那就兩臺。所以我們加一臺機器,每臺承擔1百萬。如果請求繼續(xù)增加呢,兩臺解決不了的問題,那就三臺唄。這種方式我們稱之為水平擴展。如何實現(xiàn)請求的平均分配便是負載均衡了。另一個栗子,我們現(xiàn)在有兩個數(shù)據(jù)請求,數(shù)據(jù)1 90萬,數(shù)據(jù)2 80萬,上面那臺機器也hold不住,我們加一臺機器來負載均衡一下,每臺機器處理45萬數(shù)據(jù)1和40萬數(shù)據(jù)2,但是平分太麻煩,不如一臺處理數(shù)據(jù)1,一臺處理數(shù)據(jù)2,同樣能解決問題,這種方式我們稱之為垂直拆分。水平擴展和垂直拆分是分布式架構(gòu)的兩種思路,但并不是一個二選一的問題,更多的是兼并合用。下面介紹一

3、個實際的場景。這也是許多互聯(lián)網(wǎng)的公司架構(gòu)思路。2.實際的例子我此時所在的公司的計算機系統(tǒng)很龐大,自然是一個整的分布式系統(tǒng),為了方便組織管理,公司將整個技術部按業(yè)務和平臺拆分為部門,訂單的,會員的,商家的等等,每個部門有自己的web服務器集群,數(shù)據(jù)庫服務器集群,通過同一個網(wǎng)站訪問的鏈接可能來自于不同的服務器和數(shù)據(jù)庫,對網(wǎng)站及底層對數(shù)據(jù)庫的訪問被分配到了不同的服務器集群,這個便是典型的按業(yè)務做的垂直拆分,每個部門的服務器在hold不住時,會有彈性的擴展,這便是水平擴展。在數(shù)據(jù)庫層,有些表非常大,數(shù)據(jù)量在億級,如果只是純粹的水平的擴展并不一定最好,如果對表進行拆分,比如可以按用戶id進行水平拆表,通

4、過對id取模的方式,將用戶劃分到多張表中,同時這些表也可以處在不同的服務器。按業(yè)務的垂直拆庫和按用戶水平拆表是分布式數(shù)據(jù)庫中通用的解決方案。三、負載均衡前面我們談到了分布式來解決性能問題,但其附帶的問題是怎么分布,即如何負載均衡。這里要解決的問題是當客戶端請求時,應該讓它請求分布式系統(tǒng)中哪一臺服務器,通常的做法是通過一臺中間服務器來給客服端分配目標服務器。這里同樣拿兩個不同的分布式系統(tǒng)做說明,下圖左邊是分布式文件系統(tǒng)FastDFS,右邊是一個用于分布式的RPC中間件。 FastDFS的一次文件下載請求過程是這樣的1.client詢問tracker可以下載指定文件的storage;2.track

5、er返回一臺可用的storage;3.client直接和storage通信完成文件下載。其中tracker便是負載均衡服務器,storage是存儲文件和處理上傳下載請求的服務器。 而另一個RPC中間件Hedwig也是類似的1.client詢問zookeeper哪臺server可以執(zhí)行請求;2.zookeeper返回一臺可用server;3.client直接與service完成一次RPC。zookeeper是分布式系統(tǒng)中一個負載均衡框架,google的chubby的一個開源實現(xiàn),是是Hadoop和Hbase的重要組件。同樣的在http中,常聽說的nginx也是一個負載均衡服務器,它面向的是分布式

6、web服務器。至于具體的負載均衡算法輪詢,hash等這里就不深入了。四、同步分布式系統(tǒng)中,解決了負載均衡的問題后,另外一個問題就是數(shù)據(jù)的一致性了,這個就需要通過同步來保障。根據(jù)不同的場景和需求,同步的方式也是有選擇的。在分布式文件系統(tǒng)中,比如商品頁面的圖片,如果進行了修改,同步要求并不高,就算有數(shù)秒甚至數(shù)分鐘的延遲都是可以接受的,因為一般不會產(chǎn)生損失性的影響,因此可以簡單的通過文件修改的時間戳,隔一定時間掃描同步一次,可以犧牲一致性來提高效率。但銀行中的分布式數(shù)據(jù)庫就不一樣了,一丁點不同步就是無法接受的,甚至可以通過加鎖等犧牲性能的方式來保障完全的一致。在一致性算法中paxos算法是公認的最好的算法,chubby、

溫馨提示

  • 1. 本站所有資源如無特殊說明,都需要本地電腦安裝OFFICE2007和PDF閱讀器。圖紙軟件為CAD,CAXA,PROE,UG,SolidWorks等.壓縮文件請下載最新的WinRAR軟件解壓。
  • 2. 本站的文檔不包含任何第三方提供的附件圖紙等,如果需要附件,請聯(lián)系上傳者。文件的所有權(quán)益歸上傳用戶所有。
  • 3. 本站RAR壓縮包中若帶圖紙,網(wǎng)頁內(nèi)容里面會有圖紙預覽,若沒有圖紙預覽就沒有圖紙。
  • 4. 未經(jīng)權(quán)益所有人同意不得將文件中的內(nèi)容挪作商業(yè)或盈利用途。
  • 5. 人人文庫網(wǎng)僅提供信息存儲空間,僅對用戶上傳內(nèi)容的表現(xiàn)方式做保護處理,對用戶上傳分享的文檔內(nèi)容本身不做任何修改或編輯,并不能對任何下載內(nèi)容負責。
  • 6. 下載文件中如有侵權(quán)或不適當內(nèi)容,請與我們聯(lián)系,我們立即糾正。
  • 7. 本站不保證下載資源的準確性、安全性和完整性, 同時也不承擔用戶因使用這些下載資源對自己和他人造成任何形式的傷害或損失。

評論

0/150

提交評論