負(fù)載均衡技術(shù)的知識(shí)點(diǎn)有哪些

這篇文章主要介紹“負(fù)載均衡技術(shù)的知識(shí)點(diǎn)有哪些”的相關(guān)知識(shí)，小編通過實(shí)際案例向大家展示操作過程，操作方法簡單快捷，實(shí)用性強(qiáng)，希望這篇“負(fù)載均衡技術(shù)的知識(shí)點(diǎn)有哪些”文章能幫助大家解決問題。

1、概述

通過前面文章的介紹，并不能覆蓋負(fù)載均衡層的所有技術(shù)，但是可以作為一個(gè)引子，告訴各位讀者一個(gè)學(xué)習(xí)和使用負(fù)載均衡技術(shù)的思路。雖然后面我們將轉(zhuǎn)向“業(yè)務(wù)層”和“業(yè)務(wù)通信”層的介紹，但是對負(fù)載均衡層的介紹也不會(huì)停止。在后續(xù)的時(shí)間我們將穿插進(jìn)行負(fù)載均衡層的新文章的發(fā)布，包括Nginx技術(shù)的再介紹、HaProxy、LVS新的使用場景等等。

這篇文章我們對前面的知識(shí)點(diǎn)進(jìn)行總結(jié)，并有意進(jìn)行一些擴(kuò)展，以便于各位讀者找到新的學(xué)習(xí)思路。

2、負(fù)載均衡層的核心思想

2-1、一致性哈希與Key的選取

我們詳細(xì)介紹了一致性哈希算法。并且強(qiáng)調(diào)了一致性Hash算法是現(xiàn)代系統(tǒng)架構(gòu)中的最關(guān)鍵算法之一，在分布式計(jì)算系統(tǒng)、分布式存儲(chǔ)系統(tǒng)、數(shù)據(jù)分析等眾多領(lǐng)域中廣泛應(yīng)用。針對我的博文，在負(fù)載均衡層、業(yè)務(wù)通信層、數(shù)據(jù)存儲(chǔ)層都會(huì)有它的身影。

一致性算法的核心是：

使用對象的某一個(gè)屬性（這個(gè)屬性可以是服務(wù)器的IP地址、開放端口 還可以是用戶名、某種加密串。凡是你可以想到的有散列意義的屬性），算出一個(gè)整數(shù)，讓其分布在0 至 2的32次方 范圍內(nèi)。

一臺(tái)服務(wù)器的某個(gè)或者某一些屬性當(dāng)然也可以進(jìn)行hash計(jì)算，并且根據(jù)計(jì)算分布在這個(gè)圓環(huán)上的某一個(gè)點(diǎn)，也就是圖中圓環(huán)上的藍(lán)色點(diǎn)。

一個(gè)處理請求到來時(shí)，根據(jù)這個(gè)請求的某一個(gè)或者某一些屬性進(jìn)行hash計(jì)算，并且根據(jù)計(jì)算記過分布在這個(gè)圓環(huán)上的某一個(gè)點(diǎn)上。也就是上圖圓環(huán)上的黃色點(diǎn)。

我們約定落在某一個(gè)藍(lán)點(diǎn)A左側(cè)和藍(lán)點(diǎn)B右側(cè)的黃色點(diǎn)所代表的請求，都有藍(lán)點(diǎn)A所代表的服務(wù)器進(jìn)行處理，這樣就完成解決了“誰來處理”的問題。在藍(lán)色點(diǎn)穩(wěn)定存在的前提下，來自于同一個(gè)Hash約定的請求所落在的位置都是一樣的，這就保證了服務(wù)處理映射的穩(wěn)定性。

當(dāng)某一個(gè)藍(lán)色點(diǎn)由于某種原因下線，其所影響到的黃色點(diǎn)也是有限的。即下一次客戶端的請求將由其他的藍(lán)色點(diǎn)所代表的服務(wù)器進(jìn)行處理。

2-2、輪詢與權(quán)

不加權(quán)輪詢，就是主控節(jié)點(diǎn)（任務(wù)來源點(diǎn)）在不考慮目標(biāo)節(jié)點(diǎn)的任何因素的情況下（例如CPU性能、磁盤性能、網(wǎng)絡(luò)性能），按照目標(biāo)節(jié)點(diǎn)的列表順序?qū)⑷蝿?wù)依次分配下去。這是最簡單的輪詢，也是對主控節(jié)點(diǎn)實(shí)現(xiàn)復(fù)雜性要求最低的輪詢。我之前的博文《架構(gòu)設(shè)計(jì)：負(fù)載均衡層設(shè)計(jì)方案（2）——Nginx安裝》、《架構(gòu)設(shè)計(jì)：負(fù)載均衡層設(shè)計(jì)方案（4）——LVS原理》 都對這種最簡輪詢進(jìn)行了介紹：例如LVS中的“rr”參數(shù)。

加權(quán)輪詢中的“權(quán)”，您可以看成是“輪詢”依據(jù)的意思?！皺?quán)”可以是很多種可能，可以是目標(biāo)機(jī)器的性能量化值、可以是一個(gè)固定的數(shù)字（按照固定數(shù)字加權(quán)）、可以是目標(biāo)節(jié)點(diǎn)的網(wǎng)絡(luò)速度。例如LVS中的“l(fā)c”參數(shù)，就是指按照目標(biāo)機(jī)器，現(xiàn)在已有的“連接”數(shù)量進(jìn)行加權(quán)：連接數(shù)量越少，越有更大的幾率獲得這個(gè)任務(wù)的處理權(quán)。

2-3、租約與健康檢查

租約協(xié)議主要為了保證一個(gè)事實(shí)：如果服務(wù)器對客戶端的檢查操作在“最遲時(shí)間”失敗后，那么服務(wù)器端肯定會(huì)注銷客戶端的登錄信息，同時(shí)客戶端上服務(wù)器的連接信息也會(huì)消失（并且不在向下提供服務(wù)）。每一次檢查成功，這個(gè)“最遲時(shí)間”都會(huì)向后推移。

租約協(xié)議和我們提到的哈希算法一下一樣，也是系統(tǒng)架構(gòu)設(shè)計(jì)中最基本的設(shè)計(jì)思想，并且大量運(yùn)用在各類型的系統(tǒng)中，它的工作原理是每一位架構(gòu)師都需要掌握的。例如：zookeeper使用這個(gè)協(xié)議保證Flow節(jié)點(diǎn)和Leader節(jié)點(diǎn)的鏈路是正常的；分布式存儲(chǔ)系統(tǒng)用這個(gè)協(xié)議保證datanode和namenode的連接是正常的；

3、負(fù)載均衡層技術(shù)匯總

在前面的博文中，我重點(diǎn)介紹了Nginx、LVS、Keepalived技術(shù)。由于時(shí)間有限，這里我們對博文中提到的幾種技術(shù)進(jìn)行一個(gè)總結(jié)，然后再擴(kuò)展介紹一下DNS技術(shù)、CDN技術(shù)和硬件負(fù)載技術(shù)。

3-1、Nginx技術(shù)

在負(fù)載均衡層這個(gè)大的章節(jié)中，我有三篇文章都在直接介紹Nginx的原理和使用。但是之后有朋友給我反映還想了解更多的Nginx知識(shí)，特別點(diǎn)名要求我再做一篇文章介紹Nginx的動(dòng)態(tài)緩存。是的，我在后面的時(shí)間里是有計(jì)劃介紹Nginx的動(dòng)態(tài)緩存技術(shù)，還會(huì)介紹Nginx和多款主流的反向代理軟件的性能對比。但這需要時(shí)間，特別是我不想去網(wǎng)上找一些已有的性能對比圖，還是自己一邊做這樣的性能測試，一邊做性能報(bào)告比較靠譜。

下面這些技術(shù)是我在博文中已經(jīng)重點(diǎn)介紹過得，我們再做一下總結(jié)：

Nginx中的連接數(shù)限制問題

重要的配置項(xiàng)包括：worker_processes、worker_connections。但是光是配置這些屬性是不夠的，最關(guān)鍵的是我們要打開操作系統(tǒng)級別的“最大文件數(shù)”限制問題。使用“ulimit -n 65535”設(shè)置本次會(huì)話的“最大文件數(shù)”限制；還要使用“vim /etc/security/limits.conf”命令，修改內(nèi)核的配置信息。主要是以下兩項(xiàng)：

* soft nofile 65535* hard nofile 65535

另外，還要注意和nginx配置項(xiàng)中的“worker_rlimit_nofile”屬性共同使用：

user root root; worker_processes4; worker_rlimit_nofile65535;#error_log logs/error.log; #error_log logs/error.log notice; #error_log logs/error.log info;#pid logs/nginx.pid; events {     use epoll;     worker_connections65535; }

Nginx中的Gzip技術(shù)

gzip是Nginx進(jìn)行HTTP Body數(shù)據(jù)壓縮的技術(shù)。下面這段Nginx配置信息是啟用gzip壓縮的實(shí)例：

#開啟gzip壓縮服務(wù)， gzipon;#gzip壓縮是要申請臨時(shí)內(nèi)存空間的，假設(shè)前提是壓縮后大小是小于等于壓縮前的。例如，如果原始文件大小為10K，那么它超過了8K，所以分配的內(nèi)存是8 * 2 = 16K;再例如，原始文件大小為18K，很明顯16K也是不夠的，那么按照 8 * 2 * 2 = 32K的大小申請內(nèi)存。如果沒有設(shè)置，默認(rèn)值是申請跟原始數(shù)據(jù)相同大小的內(nèi)存空間去存儲(chǔ)gzip壓縮結(jié)果。 gzip_buffers28k;#進(jìn)行壓縮的原始文件的最小大小值，也就是說如果原始文件小于5K，那么就不會(huì)進(jìn)行壓縮了 gzip_min_length6K;#gzip壓縮基于的http協(xié)議版本，默認(rèn)就是HTTP 1.1 gzip_http_version1.1;# gzip壓縮級別1-9，級別越高壓縮率越大，壓縮時(shí)間也就越長CPU越高 gzip_comp_level5;#需要進(jìn)行g(shù)zip壓縮的Content-Type的Header的類型。建議js、text、css、xml、json都要進(jìn)行壓縮；圖片就沒必要了，gif、jpge文件已經(jīng)壓縮得很好了，就算再壓，效果也不好，而且還耗費(fèi)cpu。 gzip_typestext/HTMLtext/plainapplication/x-javascripttext/cssapplication/xml;

http返回?cái)?shù)據(jù)進(jìn)行壓縮的功能在很多場景下都實(shí)用：

a、 如果瀏覽器使用的是3G/4G網(wǎng)絡(luò)，那么流量對于用戶來說就是money。

b、 壓縮可節(jié)約服務(wù)器機(jī)房的對外帶寬，為更多用戶服務(wù)。按照目前的市場價(jià)良好的機(jī)房帶寬資源的一般在200RMB/Mbps，而服務(wù)器方案的壓力往往也來自于機(jī)房帶寬。

c、 不是Nginx開啟了gzip功能，HTTP響應(yīng)的數(shù)據(jù)就一定會(huì)被壓縮，除了滿足Nginx設(shè)置的“需要壓縮的http格式”以外，客戶端（瀏覽器）也需要支持gzip（不然它怎么解壓呢），一個(gè)好消息是，目前大多數(shù)瀏覽器和API都支持http壓縮。

Nginx中的rewrite（重寫）技術(shù)

Nginx的強(qiáng)大在于其對URL請求的重寫（重定位）。Nginx的rewrite功能依賴于PCRE Lib，請一定在Nginx編譯安裝時(shí)，安裝Pcre lib。

下面是一段rewrite的示例：

#示例1：location ~* ^/(.+)/(.+)\.(jpg|gif|png|jpeg)$ {    rewrite ^/orderinfo/(.+)\.(jpg|gif|png|jpeg)$ /img/$1.$2break;    root   /cephclient;}#location在不進(jìn)行大小寫區(qū)分的情況下利用正則表達(dá)式對$url進(jìn)行匹配。當(dāng)匹配成功后進(jìn)行rewrite重定位。#rewrite進(jìn)行重寫url的規(guī)則是：regex表達(dá)式第一個(gè)括號(hào)中的內(nèi)容對應(yīng)$1，regex表達(dá)式第二個(gè)括號(hào)中的內(nèi)容對應(yīng)$2，以此類推。#這樣重定位的意義就很明確了：將任何目錄下的文件名重定位到img目錄下的對應(yīng)文件名，#并且馬上在這個(gè)location中（注意是Nginx，而不是客戶端）執(zhí)行這個(gè)重寫后的URL定位。#示例2：server {    。。。。    。。。。    location ~* ^/orderinfo/(.+)\.(jpg|gif|png|jpeg)$ {        rewrite ^/orderinfo/(.+)\.(.+)$ /img/$1.$2last;    }    location / {        root   /cephclient;    }}#在server中，有兩個(gè)location位置，當(dāng)url需要訪問orderinfo目錄下的某一個(gè)圖片時(shí)，rewrite將重寫這個(gè)url，#并且重新帶入這個(gè)url到server執(zhí)行，這樣“l(fā)ocation /”這個(gè)location就會(huì)執(zhí)行了，并找到圖片存儲(chǔ)的目錄。

Nginx的圖片處理模塊

http_image_filter_module 是nginx的圖片處理模塊，是使用nginx進(jìn)行靜態(tài)資源和動(dòng)態(tài)資源分開管理的關(guān)鍵引用技術(shù)。通過這個(gè)模塊可以對靜態(tài)資源進(jìn)行縮放、旋轉(zhuǎn)、驗(yàn)證。

需要注意的是，http_image_filter_module模塊所處理的縮率圖片是不進(jìn)行保存的，完全使用節(jié)點(diǎn)的CPU性能進(jìn)行計(jì)算，使用節(jié)點(diǎn)的內(nèi)存進(jìn)行臨時(shí)存儲(chǔ)。所以如果要使用http_image_filter_module進(jìn)行圖片處理，一定要根據(jù)客戶端的請求規(guī)模進(jìn)行nginx節(jié)點(diǎn)的調(diào)整。并且當(dāng)站點(diǎn)的PV達(dá)到一定的規(guī)模時(shí)，一定要使用CDN技術(shù)進(jìn)行訪問加速、對圖片的訪問處理手段進(jìn)行規(guī)劃。

由于我們在之前涉及Nginx的文章中，并沒有詳細(xì)講解Nginx的圖片處理模塊，只是說了要進(jìn)行介紹，所以這里我給出一個(gè)較為詳細(xì)的安裝和配置示例：

nginx的http_image_filter_module模塊由GD library進(jìn)行支持，所以要使用這個(gè)圖片處理模塊，就必須進(jìn)行第三方依賴包的安裝：

yuminstallgd-devel

然后，Nginx要進(jìn)行重新編譯：

configure--with-http_image_filter_modulemake&&make install

使用圖片處理模塊的配置示例：

location ~* /(.+)_(\d+)_(\d+)\.(jpg|gif|png|ioc|jpeg)$ {set$h$3;set$w$2;    rewrite /(.+)_(\d+)_(\d+)\.(jpg|gif|png|ioc|jpeg)$ /$1.$4break;    image_filter resize$w$h;    image_filter_buffer2M;}

其中關(guān)于正則表達(dá)式的語法和已經(jīng)介紹過的rewrite的語法就不再進(jìn)行介紹了，主要看http_image_filter_module相關(guān)的屬性設(shè)置：

image_filter test：測試圖片文件合法性

image_filter rotate：進(jìn)行圖片旋轉(zhuǎn)，只能按照90 | 180 | 270進(jìn)行旋轉(zhuǎn)

image_filter size：返回圖片的JSON數(shù)據(jù)

image_filter resize width height：按比例進(jìn)行圖片的等比例縮小，注意，是只能縮小，第二縮小是等比例的。

image_filter_buffer：限制圖片最大讀取大小，沒有設(shè)置就是1M；根據(jù)不同的系統(tǒng)最好設(shè)置為2M—3M

image_filter_jpeg_quality：設(shè)置jpeg圖片的壓縮比例（1-99，越高越好）

image_filter_transparency：禁用gif和png圖片的透明度。

和Nginx類似的其他技術(shù)/軟件

目前行業(yè)內(nèi)也有很多與Nginx解決同類問題的軟件，他們分別是Apache基金會(huì)的 Apache HTTP Server、淘寶開源的Tengine、Haproxy、包括Windows 下運(yùn)行的IIS，也支持反向代理 。

這里筆者再次重點(diǎn)提到Tengine，建議各位讀者有時(shí)間的時(shí)候可以使用一下，這個(gè)對Nginx進(jìn)行了深度再開發(fā)的軟件。

3-2、LVS技術(shù)

LVS是Linux Virtual Server的簡寫，意即Linux虛擬服務(wù)器，是一個(gè)虛擬的服務(wù)器集群系統(tǒng)。本項(xiàng)目在1998年5月由章文嵩博士成立。

LVS集群采用IP負(fù)載均衡技術(shù)和基于內(nèi)容請求分發(fā)技術(shù)。調(diào)度器具有很好的吞吐率，將請求均衡地轉(zhuǎn)移到不同的服務(wù)器上執(zhí)行，且調(diào)度器自動(dòng)屏蔽掉服務(wù)器的故障，從而將一組服務(wù)器構(gòu)成一個(gè)高性能的、高可用的虛擬服務(wù)器。整個(gè)服務(wù)器集群的結(jié)構(gòu)對客戶是透明的，而且無需修改客戶端和服務(wù)器端的程序。

在我的系列文章中，《架構(gòu)設(shè)計(jì)：負(fù)載均衡層設(shè)計(jì)方案（4）——LVS原理》 、《架構(gòu)設(shè)計(jì)：負(fù)載均衡層設(shè)計(jì)方案（5）——LVS單節(jié)點(diǎn)安裝》 、《負(fù)載均衡層設(shè)計(jì)方案（7）——LVS + Keepalived + Nginx安裝及配置》 都涉及到LVS的講解。

這里我們再總結(jié)一下LVS中的三種工作模式：

3-2-1、NAT模式

NAT方式是一種由LVS Master服務(wù)節(jié)點(diǎn)收到數(shù)據(jù)報(bào)，然后轉(zhuǎn)給下層的Real Server節(jié)點(diǎn)，當(dāng)Real Server處理完成后回發(fā)給LVS Master節(jié)點(diǎn)然后又由LVS Master節(jié)點(diǎn)轉(zhuǎn)發(fā)出去的工作方式。LVS的管理程序IPVSADMIN負(fù)責(zé)綁定轉(zhuǎn)發(fā)規(guī)則，并完成IP數(shù)據(jù)報(bào)文和TCP數(shù)據(jù)報(bào)文中屬性的重寫。

LVS-NAT模式的優(yōu)點(diǎn)在于：

配置管理簡單。LVS-NAT的工作方式是LVS三種工作模式中最容易理解、最容易配置、最容易管理的工作模式。

節(jié)省外網(wǎng)IP資源，一般機(jī)房分配給使用者的IP數(shù)量是有限的，特別是您購買的機(jī)架的數(shù)量不多時(shí)。LVS-NAT工作方式將您的系統(tǒng)架構(gòu)封裝在局域網(wǎng)中，只需要LVS有一個(gè)外網(wǎng)地址或外網(wǎng)地址映射就可以實(shí)現(xiàn)訪問了。

系統(tǒng)架構(gòu)相對封閉。在內(nèi)網(wǎng)環(huán)境下我們對防火墻的設(shè)置要求不會(huì)很高，也相對容易進(jìn)行物理服務(wù)器的運(yùn)維。您可以設(shè)置來源于外網(wǎng)的請求需要進(jìn)行防火墻過濾，而對內(nèi)網(wǎng)請求開放訪問。

另外改寫后轉(zhuǎn)給Real Server的數(shù)據(jù)報(bào)文，Real Server并不會(huì)關(guān)心它的真實(shí)性，只要TCP校驗(yàn)和IP校驗(yàn)都能通過，Real Server就可以進(jìn)行處理。所以LVS-NAT工作模式下Real Server可以是任何操作系統(tǒng)，只要它支持TCP/IP協(xié)議即可。

3-2-2、DR模式

LVS的DR工作模式，是目前生產(chǎn)環(huán)境中最常用的一種工作模式，網(wǎng)上的資料也是最多的，有的文章對DR工作模式的講解還是比較透徹的：

LVS-DR模式的優(yōu)點(diǎn)在于：

解決了LVS-NAT工作模式中的轉(zhuǎn)發(fā)瓶頸問題，能夠支撐規(guī)模更大的負(fù)載均衡場景。

比較耗費(fèi)網(wǎng)外IP資源，機(jī)房的外網(wǎng)IP資源都是有限的，如果在正式生產(chǎn)環(huán)境中確實(shí)存在這個(gè)問題，可以采用LVS-NAT和LVS-DR混合使用的方式來緩解。

LVS-DR當(dāng)然也有缺點(diǎn)：

配置工作較LVS-NAT方式稍微麻煩一點(diǎn)，您至少需要了解LVS-DR模式的基本工作方式才能更好的指導(dǎo)自己進(jìn)行LVS-DR模式的配置和運(yùn)行過程中問題的解決。

由于LVS-DR模式的報(bào)文改寫規(guī)則，導(dǎo)致LVS節(jié)點(diǎn)和Real Server節(jié)點(diǎn)必須在一個(gè)網(wǎng)段，因?yàn)槎咏粨Q是沒法跨子網(wǎng)的。但是這個(gè)問題針對大多數(shù)系統(tǒng)架構(gòu)方案來說，實(shí)際上并沒有本質(zhì)限制。

3-2-3、TUN模式

LVS-DR模式和LVS-TUN模式的工作原理完全不一樣，工作場景完全不一樣。DR基于數(shù)據(jù)報(bào)文重寫，TUN模式基于IP隧道，后者是對數(shù)據(jù)報(bào)文的重新封裝：

IPIP隧道。將一個(gè)完整的IP報(bào)文封裝成另一個(gè)新的IP報(bào)文的數(shù)據(jù)部分，并通過路由器傳送到指定的地點(diǎn)。在這個(gè)過程中路由器并不在意被封裝的原始協(xié)議的內(nèi)容。到達(dá)目的地點(diǎn)后，由目的地方依靠自己的計(jì)算能力和對IPIP隧道協(xié)議的支持，打開封裝協(xié)議，取得原始協(xié)議：

可以說LVS-TUN方式基本上具有LVS-DR的優(yōu)點(diǎn)。在此基礎(chǔ)上又支持跨子網(wǎng)間穿透。

3-3、CDN技術(shù)

CDN技術(shù)Content Delivery Network：內(nèi)容分發(fā)網(wǎng)絡(luò)。為什么有時(shí)我們訪問互聯(lián)網(wǎng)上的視頻資源、圖片資源會(huì)比較慢，甚至訪問失敗。其中有一個(gè)重要的原因，是資源的物理位置離客戶端太遠(yuǎn)了，可能其中有4層NAT設(shè)備（相當(dāng)于使用網(wǎng)通的線路訪問電信服務(wù)器上的資源）。

我們試想一下，如果將我們要訪問的資源放到離我們客戶端最近的一個(gè)服務(wù)上（例如在廣州的客戶端訪問的資源就在廣州的機(jī)房）。那么是不是就解決了這個(gè)問題（這個(gè)點(diǎn)稱為“邊緣節(jié)點(diǎn)”）。這就是CDN網(wǎng)絡(luò)解決的問題，如下圖所示：

目前CDN服務(wù)不需要我們進(jìn)行開發(fā)，市面上有很多公司都提供免費(fèi)的/付費(fèi)的 CDN服務(wù)（請直接在google或者百度上面輸入：CDN，就會(huì)有很多“推廣”信息了，在我的博文中不打廣告^_^）。當(dāng)然如果您想自行搭建CDN網(wǎng)絡(luò)，可以參考以下技術(shù)方案：

Squid：Squid是一個(gè)緩存internet數(shù)據(jù)的一個(gè)軟件，它接收用戶的下載申請，并自動(dòng)處理所下載的數(shù)據(jù)。目前，國內(nèi)很多CDN服務(wù)商的網(wǎng)絡(luò)都是基于Squid搭建的

利用Nginx的proxy_cache搭建：Nginx中的rewrite技術(shù)實(shí)際上就可以實(shí)現(xiàn)URL請求重寫，實(shí)現(xiàn)請求轉(zhuǎn)發(fā)。而Nginx中的proxy_cache組件可以使得從遠(yuǎn)端請求的源數(shù)據(jù)保存在本地，從而實(shí)現(xiàn)一個(gè)CDN網(wǎng)絡(luò)的搭建。

自己寫：CDN網(wǎng)絡(luò)沒有特別復(fù)雜的技術(shù)門檻，如果您有特別的需求，可以自己寫一個(gè)。當(dāng)然上圖中所介紹的CDN網(wǎng)絡(luò)屬于第一代CDN網(wǎng)絡(luò)，將第二代/第三代P2P技術(shù)加入到CDN原理中，可以形成第二代CDN網(wǎng)絡(luò)：如下圖所示：

第三代P2P技術(shù)又被稱為混合型P2P技術(shù)主要是為了解決元數(shù)據(jù)服務(wù)器的處理壓力，加速資源的本地化速度。關(guān)于P2P技術(shù)我會(huì)在講完“業(yè)務(wù)系統(tǒng)設(shè)計(jì)”、“業(yè)務(wù)通信系統(tǒng)設(shè)計(jì)”后，專門做一個(gè)新的專題進(jìn)行介紹。另外提一下，YouTube的P2P網(wǎng)絡(luò)就是自己做的。

3、負(fù)載均衡層技術(shù)匯總

3-4、Keepalived技術(shù)

在這些文章中從來沒有單獨(dú)介紹Keepalived。這是因Keepalived是為了監(jiān)控集群節(jié)點(diǎn)的工作狀態(tài)，在因?yàn)槟撤N原因不能正常提供服務(wù)的前提下，完成備機(jī)的切換。這里面有兩個(gè)關(guān)鍵點(diǎn)：監(jiān)控節(jié)點(diǎn)上提供的服務(wù)、完成網(wǎng)絡(luò)切換。keepalived本身是不提供業(yè)務(wù)服務(wù)的，只是監(jiān)控提供的服務(wù)是否正常工作，那么既然都沒有可以監(jiān)控的服務(wù)，那么Keepalived有什么獨(dú)立使用的必要呢？

下圖是Nginx + Keepalived的工作結(jié)構(gòu)和LVS + Keepalived 的工作結(jié)構(gòu)：

Nginx + Keepalived的工作方式

LVS + Keepalived + Nginx的工作方式

相關(guān)技術(shù)還有：

Heartbeat是Linux-HA計(jì)劃中的一個(gè)重要項(xiàng)目，它的功能比Keepalived更強(qiáng)大，安裝和管理也相對復(fù)雜。網(wǎng)絡(luò)上有很多資料介紹Heartbeat和Keepalived的優(yōu)缺點(diǎn)和使用對比。但就我自己的使用經(jīng)驗(yàn)來說，個(gè)人更喜歡使用Keepalived，原因很簡單：Keepalived安裝和配置更簡單，而且夠用。另外Redhat Rhcs套件也可以搭建類似的HA集群，但是說實(shí)話本人沒有嘗試過。

3-5、DNS輪詢和智能DNS

//TODO DNS技術(shù)還沒有介紹

3-6、硬件負(fù)載

在這個(gè)系列的“負(fù)載均衡層設(shè)計(jì)方案”博文中，我們所提到的諸如Nginx、LVS等技術(shù)，沒有詳細(xì)講述的Haproxy、Squid等技術(shù)，都是基于軟件的負(fù)載技術(shù)。F5是一家公司，它的BIG-IP LTM技術(shù)是基于硬件負(fù)載的。硬件負(fù)載方案提供了軟件負(fù)載技術(shù)無法提供了性能空間，并且集成了NAT映射功能、SSL加速、Cookie加密、高速緩存、攻擊過濾、包過濾、動(dòng)態(tài)Session保持等等很多軟件負(fù)載無法提供的功能（或者需要多個(gè)軟件組合使用才能提供的功能）。

但是硬件負(fù)載方案也有其缺點(diǎn)，主要就是建設(shè)費(fèi)用比較高昂，它不像軟負(fù)載可以根據(jù)系統(tǒng)的吞吐量的持續(xù)增加進(jìn)行持續(xù)擴(kuò)展。當(dāng)然您可以根據(jù)系統(tǒng)的吞吐量需求，在前期采用軟負(fù)載，后期采用硬件負(fù)載的方案。除了F5公司提供的硬件負(fù)載技術(shù)，還有Citrix公司的硬負(fù)載方案、A10公司的硬件負(fù)載方案。

4、常見負(fù)載均衡技術(shù)組合

這里我們在重新回顧一下這個(gè)系列博文中，提到的目前常用的負(fù)載均衡技術(shù)的組合方式。

4-1、獨(dú)立的Nginx/Haproxy

一般的WEB系統(tǒng)，前段假設(shè)一個(gè)Nginx或者Haproxy服務(wù)器，基本上可以解決包括負(fù)載分發(fā)在內(nèi)的很多問題了。

4-2、Nginx + Keepalived 或 Haproxy + Keepalived 或 + Heartbeat

為了保證Nginx或者HaProxy服務(wù)器的穩(wěn)定性，可以使用Keepalived或者Heartbeat做一個(gè)簡單的熱備方案。

4-3、LVS + (Keepalived | Heartbeat) + (Nginx | Haproxy)

隨著訪問壓力的增大，我們開始采用多層負(fù)載方案，在Nginx或者Haproxy的前段架設(shè)LVS服務(wù)，并通過Keepalived或者Heartbeat保證Keepalived的持續(xù)工作。

4-4、加如DNS輪詢技術(shù)或者智能DNS路由技術(shù)

技術(shù)方案擴(kuò)展到這一步，日千萬級PV是完全可以支撐了。前提條件是：程序沒有問題^_^。

如果您站點(diǎn)的流量還要大甚至高出幾個(gè)數(shù)量級，那么恭喜您，您肯定是全球排名前100位互聯(lián)網(wǎng)公司工作；但是從另一個(gè)角度來說，您遇到的問題可能只能根據(jù)貴公司的業(yè)務(wù)特點(diǎn)，自己尋求解決方案了。這樣的例子有很多，例如YouTube發(fā)現(xiàn)市面上的商用CDN網(wǎng)絡(luò)無法滿足他們對視頻加速的需求，于是YouTube的工程師們自己動(dòng)手寫了一專門針對自己業(yè)務(wù)的CDN加速技術(shù)；再例如，淘寶發(fā)現(xiàn)市面上已經(jīng)沒有一款分布式文件系統(tǒng)能夠滿足他們對小文件存儲(chǔ)的需求，于是動(dòng)手寫了一個(gè)TFS。

5、負(fù)載均衡技術(shù)的其他運(yùn)用

在這個(gè)系列的文章中，我們?nèi)趯⒂糜诳蛻舳耸褂肏TTP協(xié)議請求服務(wù)器端進(jìn)行處理的情況，這里的客戶端可以使最終用戶，也可以是某個(gè)一第三方系統(tǒng)。但實(shí)際上負(fù)載均衡技術(shù)在信息處理領(lǐng)域內(nèi)，不是只有這樣的請求響應(yīng)層才使用，在其它的技術(shù)領(lǐng)域也大量使用，這個(gè)小節(jié)，我們就來梳理這些技術(shù)，作為一個(gè)擴(kuò)展話題。

5-1、關(guān)系型數(shù)據(jù)庫系統(tǒng)的負(fù)載均衡

一說到關(guān)系型數(shù)據(jù)庫，大家自然會(huì)聯(lián)想到Oracle、MS SQL、DB2 和Mysql。在移動(dòng)互聯(lián)網(wǎng)領(lǐng)域，通常很多公司在走去OEI的路程。這里我們不去討論去OEI是否是正確的，也不去討論怎樣走去OEI這條路才合理，一個(gè)不可爭辯的事實(shí)是，目前很多移動(dòng)互聯(lián)網(wǎng)公司在使用Mysql數(shù)據(jù)庫。

單臺(tái)Mysql數(shù)據(jù)庫的處理能力確實(shí)趕不上Oracle，甚至趕不上MS SQL這些商用數(shù)據(jù)庫，但是我們可以為Mysql做集群來提高整個(gè)數(shù)據(jù)服務(wù)的性能。Mysql從5.1.X版本開始，就已經(jīng)支持單數(shù)據(jù)節(jié)點(diǎn)的“表分區(qū)”功能了，但這個(gè)支持僅限于每個(gè)節(jié)點(diǎn)的配置，提高單個(gè)Mysql上的讀寫性能（還要配合底層的塊存儲(chǔ)選型，例如DAS）。而想要實(shí)現(xiàn)整個(gè)Mysql集群性能，就需要從更高級別實(shí)現(xiàn)讀寫分離了。

其中有一種成熟的Mysql集群讀寫分離的做法，是一臺(tái)寫節(jié)點(diǎn)做成Master節(jié)點(diǎn)（Master節(jié)點(diǎn)單機(jī)性能可以做得較高，后端可以使用DAS系統(tǒng)）；然后多臺(tái)讀節(jié)點(diǎn)做成Salve節(jié)點(diǎn)，并接受來源于Master節(jié)點(diǎn)的同步日志（MySQL Replication技術(shù)），并通過另一個(gè)LVS進(jìn)行讀請求的負(fù)載，而且可以再配合單個(gè)節(jié)點(diǎn)上的“表分區(qū)”功能。這個(gè)做法在80%以上都是讀請求的任何系統(tǒng)上，都可以大大增強(qiáng)數(shù)據(jù)庫系統(tǒng)的整體性能，如下圖所示：

從上圖可以看到，來源于程序的“寫”操作通過一個(gè)數(shù)據(jù)源提交給了Mysql Master，而所有的讀操作則通過LVS-DR模式分發(fā)給3個(gè)Mysql Salve。這里要說明幾個(gè)問題：

Mysql Master和Mysql Salve的數(shù)據(jù)同步是通過MySQL Replication同步技術(shù)來實(shí)現(xiàn)的，這是一種基于操作日志的異步同步，雖然響應(yīng)時(shí)間不能達(dá)到“毫秒”級，但是基本上還是很快很快的。如果不是銀行系統(tǒng)、或者“秒殺系統(tǒng)”基本上可以滿足事實(shí)性

MySQL Replication會(huì)降低Mysql Master節(jié)點(diǎn)的20%的工作性能，但是轉(zhuǎn)移了原來Mysql Master負(fù)責(zé)的所有讀操作。當(dāng)然，我們以后介紹“多主”方式和使用HiveDB橫向切分的時(shí)候，還會(huì)重點(diǎn)介紹如何提高M(jìn)ysql的寫性能。

事實(shí)上正式的開發(fā)架構(gòu)中，我們不會(huì)給程序員兩個(gè)數(shù)據(jù)源，這樣既不利于代碼的管理，也增加了開發(fā)難度。我們會(huì)采用類似Mysql-Proxy、Amoeba之類的軟件實(shí)現(xiàn)數(shù)據(jù)源的整個(gè)。

后面在介紹數(shù)據(jù)存儲(chǔ)層架構(gòu)的時(shí)候，我還會(huì)介紹多種成熟的可靠的Mysql集群、Mysql讀寫分離、Mysql橫向擴(kuò)展方式，和讀者討論如何實(shí)現(xiàn)幾十臺(tái)Mysql節(jié)點(diǎn)的運(yùn)行和管理。

5-2、分布式存儲(chǔ)系統(tǒng)的負(fù)載均衡

分布式存儲(chǔ)系統(tǒng)目前有很多，Ceph、Swift、MFS、HDFS。他們有的是基于對象存儲(chǔ)的，有的是基于快存儲(chǔ)的（在《標(biāo)準(zhǔn)Web系統(tǒng)的架構(gòu)分層》這篇博文中，我對塊存儲(chǔ)、文件存儲(chǔ)和對象存儲(chǔ)做了較詳細(xì)的介紹，后文我們還將詳細(xì)介紹存儲(chǔ)系統(tǒng)）。但是他們有一個(gè)或者多個(gè)主控節(jié)點(diǎn)（有的叫namenode、有的叫master、有的叫Metadata），無論怎么叫，他們都有一些相同的功能：

計(jì)算“數(shù)據(jù)該存儲(chǔ)在哪里”的問題

協(xié)調(diào)控制“數(shù)據(jù)是否正確存儲(chǔ)”的問題

監(jiān)控“數(shù)據(jù)節(jié)點(diǎn)”的健康狀態(tài)

轉(zhuǎn)移數(shù)據(jù)

回答客戶端“到哪里取數(shù)據(jù)”的問題

。。。。。

在處理問題的過程中，這些控制節(jié)點(diǎn)實(shí)際上起到的就是負(fù)載分發(fā)的作用，他們的基本原理都是通過“一致性hash算法”，對“數(shù)據(jù)該存儲(chǔ)在”哪里的問題進(jìn)行分析（用來做hash的屬性依據(jù)不同而已）：

5-3、更廣義的負(fù)載均衡系統(tǒng)

相同的客流量下，銀行多個(gè)窗口排隊(duì)的等待時(shí)間肯定比一個(gè)窗口排隊(duì)的時(shí)間短；同樣的車流量，8車道肯定比6車道的通過率高；把一個(gè)任務(wù)拆分成多個(gè)任務(wù)由多個(gè)人負(fù)責(zé)處理其中的一部分，肯定比一個(gè)人做一個(gè)大任務(wù)的時(shí)間短；

負(fù)載均衡的核心思想在于分流、關(guān)鍵問題在于如何分流、評價(jià)標(biāo)準(zhǔn)在于分流后的吞吐量。

關(guān)于“負(fù)載均衡技術(shù)的知識(shí)點(diǎn)有哪些”的內(nèi)容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業(yè)相關(guān)的知識(shí)，可以關(guān)注億速云行業(yè)資訊頻道，小編每天都會(huì)為大家更新不同的知識(shí)點(diǎn)。