雲端高效能技術架構淺析

beaty向發表於2015-04-27

無論是國外的Google、Facebook、Amazon,還是國內的Baidu、Taobao等,這些高效能的伺服器在處理高併發的請求時,都能快速、準確的給予應答。通過查閱資料,瞭解現有大型網站的技術架構,發現目前常用的技術有分層、快取、負載均衡、資料庫效能優化,分散式系統等等。接下類分別對這些技術進行簡單介紹。

1、分層與服務分離

無論OSI的7層網路結構,還是計算機底層硬體與上層軟體之間的分層,甚至於Web領域大家非常熟悉的MVC開發模式,分層在計算機領域無處不在。分層可以將不同的功能部件獨立起來,下層為上層提供訪問介面,支撐上層的功能;上層呼叫下層介面來完成服務。

分層也是伺服器端採用的一種方法,通過將資料庫、檔案資源等與應用伺服器分開,可以緩解伺服器壓力。

另外,根據業務需求的不同,將明顯沒有交集的業務分開,獨立成不同的模組單獨進行管理,也可以在很大程度上提升伺服器效能。

2、快取

快取在計算機很多地方都有涉及,比如在記憶體與硬碟之間增加Cache、增加IO緩衝區來緩解速度之間的不匹配。快取的出現主要是依據計算機中著名的二八定律。快取的技術主要包括本地快取、分散式快取、CDN和反向代理。

根據二八定律,80%的操作集中在20%的資料上。網站將常用的資料快取在本地應用伺服器中,以後直接通過快取中的資料來響應使用者的請求,而不用再去計算。這樣就可以減少響應時間。

分散式快取相比本地快取速度要慢,因為應用伺服器要訪問專門的快取伺服器來獲取資料,但是應用伺服器主要用於處理請求,其自身記憶體有限,如果快取大量資料,應用程式的執行速度將受到明顯影響。因此很多大型網站都使用遠端分散式快取,部署大記憶體的伺服器作為專門的快取伺服器。

快取的另外兩種表現形式是CDN和反向代理。不同的地方在於,CDN部署在網路提供商(比如電信、移動、聯通等)的機房,使用者在請求網站服務時,可以直接從網路提供商機房獲取資料;而反向代理則部署在網站的中心機房,當使用者的請求到中心機房後,首先訪問的伺服器是反向代理伺服器,如果反向代理伺服器中有相應資源的快取,就將其直接返回給使用者,而不用再去請求應用伺服器。

3、負載均衡

負載均衡的原理就是去中心化。當使用者併發請求量巨大時,如果將所有的請求都交給一個伺服器去處理,很可能造成伺服器當機,即使能夠正確響應,響應時間也可能會比較長,給使用者造成不好的體驗。

大型網站都是將一個域名繫結不同的伺服器IP,這樣表面上好像只有一臺伺服器在提供服務,實際則是一個伺服器叢集在提供相同的服務。負載均衡器接收所有使用者的請求,再根據每臺應用伺服器正在處理的請求數量來對請求進行分配。這樣就能在很大程度上提高系統的效能,同時擴充套件性也得到很大提升——當某臺伺服器當機時,直接替換就可以,其它伺服器繼續相應使用者請求;當使用者請求量超過預定峰值時,也可以通過實時增加伺服器來緩解壓力。

4、資料庫效能優化

使用快取後,大部分的資料操作不需要通過資料庫即可完成。但是仍有一部分讀操作(快取訪問不命中,快取過期)和全部的寫操作需要訪問資料庫,在網站的使用者達到一定規模時,資料庫因為負載壓力過高而成為網站的瓶頸。因而需要對資料庫進行優化,常用的技術主要包括讀寫分離、結合非關係型資料庫使用、分散式資料庫等。

一般情況下,資料庫讀操作所需要的時間比寫操作的要少很多,通過將資料庫的讀寫操作分離可以明顯改善資料庫效能。目前很多大型網站都配置資料庫主從關係,主資料庫用於寫操作並將資料同步更新到從資料庫上,從資料庫只負責讀操作。例如,新浪雲端計算平臺(SAE)給使用者的資料庫就進行了主從配置。

同時,可以利用非關係型資料庫和搜尋引擎對資料檢索的優勢,來減輕應用伺服器直接訪問關係型資料庫的壓力。

當對業務進行分離後,可以根據業務所涉及的資料,將資料庫進行分庫部署在不同的伺服器上。

5、冗餘

網站需要7×24小時連續執行,但是伺服器隨時可能出現故障,特別是伺服器規模比較大時,出現某臺伺服器當機是必然事件。要想保證在伺服器當機的情況下網站依然可以繼續服務,不丟失資料,就需要一定程度的伺服器冗餘執行,資料冗餘備份,這樣當某臺伺服器當機時,可以將其上的服務和資料轉移到其它機器上繼續執行。

接下來,我們主要針對快取中的Memcached技術進行介紹。

1 Memcached

1.1 Memcached簡介

Memcached是一個高效能的分散式物件快取系統,用於動態Web應用,以減輕資料庫負載[1]。它通過在記憶體中快取資料和物件來減少應用程式讀取資料庫的次數,從而提高網站的效能。如圖1是Memcached在網站中的位置示意圖。

雲端高效能技術架構淺析

圖1 Memcached位置示意圖

Memcached以鍵值對的形式將資料(或物件)快取在記憶體中,雖然使用到了多個服務節點,但是和一般分散式快取系統不同的是,每一份資料在Memcached中只存在一份,每個Memcached服務節點之間相互不可見。因此,Memcached中每份資料的鍵值是唯一的。

簡而言之,Memcached類似於一個典型的非關係型儲存系統,可以歸入基於內容的鍵值對儲存型別[2]。

1.2 Memcached工作原理

當高併發的外部請求訪問伺服器時,負載均衡伺服器會根據各應用伺服器的使用情況進行分配轉發,如果需要對資料進行讀取,應用伺服器會按照一定的Hash演算法計算鍵值的結果,並根據計算結果訪問Memcached的某一個服務節點,服務節點再次計算鍵值的第二次Hash值,再根據計算結果對資料進行讀取,如果快取中有資料則直接返回給應用,否則需要從資料庫獲取資料,同時將獲取到的資料寫入到Memcached中[3]。

雲端高效能技術架構淺析

圖2 Memcached工作原理

2 效能分析

在本機上安裝Memcached,客戶端使用Memcached提供的介面進行資料的儲存與訪問,並與直接通過MySQL獲取資料的方式進行對比。

2.1 Memcached安裝

由於Memcached主要用於伺服器端,而伺服器端作業系統大多用Linux,因此網上多數教程是關於在Linux上安裝使用Memcached的。在Windows上安裝更加簡單,只需找到對應作業系統的版本即可[4]。

安裝Memcached後,開啟服務即可使用相應功能,Memcached預設監聽11211埠,如果是在本機上,直接使用127.0.0.1:11211就可以訪問了,這點和MySQL非常類似。

Memcached提供了很多高階語言的介面,可以根據這些介面來完成對資料的儲存與訪問。

2.2 Memcached和MySQL效能比較

為了比較使用Memcached前後訪問資料效能的情況,進行以下模擬實驗。

硬體條件:

CPU:Intel Core 2.60GHz;

記憶體:2GB;

軟體條件:

作業系統:Window 64;

Memcached最大記憶體:64MB;

Memcached最大連線數:1024。

MySQL中共有29120條記錄,使用多執行緒模擬使用者的併發訪問,每個使用者請求100次資料讀取。表1是在使用者數量為N的條件下,測試所有請求都處理完所用時間T的結果。

表1 測試結果

雲端高效能技術架構淺析

三種方法說明:MySQL表示所有的資料請求直接通過訪問資料庫返回;隨機Mem表示在增加了Memcached快取後,對於每個使用者的100次請求,資料之間沒有任何關係,完全隨機;二八定律Mem表示使用者的請求遵循二八定律,就是說平均100次請求中,有比較多的次數訪問的是相同資料,這個可以通過程式模擬,在訪問時控制相應次數訪問相同的資料。

圖3、圖4分別對應表1的兩種資料表示。

雲端高效能技術架構淺析

圖3 柱狀圖顯示結果

雲端高效能技術架構淺析

圖4 折線顯示結果

由於在完全隨機訪問的條件下,資料的命中率非常低(幾乎為0),每次請求都需要從資料庫中獲取,同時還要將請求到的資料儲存在快取中,因此效率比直接從資料庫中獲取還要低。但是當使用者多次請求相同的資料是,使用Memcached 明顯比直接從MySQL中獲取效率要高很多。

整個測試過程還存在著一些不足之處:

  • 受實際條件限制,Memcached服務節點數只有1個;
  • 另外,資料庫中資料量級也不是非常大;
  • 沒有測試資料寫入的情況

3 關鍵問題

通過上述分析可知,Memcached在一些條件下對提升資料訪問效率有很大作用。對於那些不常變動訪問頻率又非常高的資料,將其放在快取中,可以很好的緩解資料庫的壓力,進而提升系統效能。但同時,Memcached自身也還存在著一些不足之處:

由於Memcached是將資料快取在記憶體中,當出現斷電情況時,資料將立即消失;

所有資料在Memcached中只儲存一份,因此可靠性不是很高,一旦某臺服務節點出現故障,相應的資料將丟失;

Memcached在設計之初每個key的value最大是1MB,隨著目前資料量的快速增長,快取資料量大的檔案,比如音訊、視訊等有很大不足。

4 參考資料

俞華鋒.Memcached 在大型網站中的應用[J]. 科技資訊, 2008(1), p70.

王新根. Web後端效能優化關鍵技術研究[D]. 浙江大學, 2012.

http://en.wikipedia.org/wiki/Memcached

http://blog.csdn.net/zhaotengfei36520/article/details/41315329

徐劍強,鄒偉平. Memcached應用研究[J]. 科技廣場, 2012(7), p95-97.

相關文章