1. 程式人生 > >分散式系統的架構思路 深入理解java:5. Java分散式架構

分散式系統的架構思路 深入理解java:5. Java分散式架構

原文來源:https://www.cnblogs.com/chulung/p/5653135.html

一、前言

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


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

平時接觸到的分散式系統有很多種,比如分散式檔案系統,分散式快取系統,分散式資料庫,分散式WebService,分散式計算等等,面向的情景不同,但分散式的思路是否是一樣的呢?

分散式檔案系統: 出名的有 Hadoop 的HDFS ,還有 google的 GFS , 淘寶的 TFS 等

分散式快取系統:memcache , hbase , mongdb 等

分散式資料庫 : MySQL , Mariadb, PostgreSQL 等

1.簡單的例子

假設我們有一臺伺服器,它可以承擔1百萬/秒的請求,這個請求可以的是通過http訪問網頁,通過tcp下載檔案,jdbc執行sql,RPC呼叫介面…,現在我們有一條資料的請求是2百萬/秒,很顯然伺服器hold不住了,會各種拒絕訪問,甚至崩潰,宕機,怎麼辦呢。一臺機器解決不了的問題,那就兩臺。所以我們加一臺機器,每臺承擔1百萬。如果請求繼續增加呢,兩臺解決不了的問題,那就三臺唄。這種方式我們稱之為水平擴充套件。如何實現請求的平均分配便是負載均衡

了。

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

水平擴充套件垂直拆分是分散式架構的兩種思路,但並不是一個二選一的問題,更多的是兼併合用。下面介紹一個實際的場景。這也是許多網際網路的公司架構思路。

2.實際的例子

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

,每個部門的伺服器在hold不住時,會有彈性的擴充套件,這便是水平擴充套件

在資料庫層,有些表非常大,資料量在億級,如果只是純粹的水平的擴充套件並不一定最好,如果對錶進行拆分,比如可以按使用者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是它保證一致性的核心。這個演算法比較難懂,我目前也沒弄懂,這裡就不深入了。


五、結語

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

擴充套件閱讀