?[[278037]]?

 1、概述

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

這篇文章我們對前面的知識點進行總結，并有意進行一些擴展，以便于各位讀者找到新的學習思路。

2、負載均衡層的核心思想

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

我們詳細介紹了一致性哈希算法。并且強調了一致性Hash算法是現代系統架構中的最關鍵算法之一，在分布式計算系統、分布式存儲系統、數據分析等眾多領域中廣泛應用。針對我的博文，在負載均衡層、業務通信層、數據存儲層都會有它的身影。

一致性算法的核心是：

1. 使用對象的某一個屬性(這個屬性可以是服務器的IP地址、開放端口 還可以是用戶名、某種加密串。凡是你可以想到的有散列意義的屬性)，算出一個整數，讓其分布在0 至 2的32次方 范圍內。
2. 一臺服務器的某個或者某一些屬性當然也可以進行hash計算，并且根據計算分布在這個圓環上的某一個點，也就是圖中圓環上的藍色點。
3. 一個處理請求到來時，根據這個請求的某一個或者某一些屬性進行hash計算，并且根據計算記過分布在這個圓環上的某一個點上。也就是上圖圓環上的黃色點。
4. 我們約定落在某一個藍點A左側和藍點B右側的黃色點所代表的請求，都有藍點A所代表的服務器進行處理，這樣就完成解決了“誰來處理”的問題。在藍色點穩定存在的前提下，來自于同一個Hash約定的請求所落在的位置都是一樣的，這就保證了服務處理映射的穩定性。
5. 當某一個藍色點由于某種原因下線，其所影響到的黃色點也是有限的。即下一次客戶端的請求將由其他的藍色點所代表的服務器進行處理。

2-2、輪詢與權

不加權輪詢，就是主控節點(任務來源點)在不考慮目標節點的任何因素的情況下(例如CPU性能、磁盤性能、網絡性能)，按照目標節點的列表順序將任務依次分配下去。這是最簡單的輪詢，也是對主控節點實現復雜性要求最低的輪詢。我之前的博文《架構設計：負載均衡層設計方案(2)——Nginx安裝》、《架構設計：負載均衡層設計方案(4)——LVS原理》 都對這種最簡輪詢進行了介紹：例如LVS中的“rr”參數。

加權輪詢中的“權”，您可以看成是“輪詢”依據的意思。“權”可以是很多種可能，可以是目標機器的性能量化值、可以是一個固定的數字(按照固定數字加權)、可以是目標節點的網絡速度。例如LVS中的“lc”參數，就是指按照目標機器，現在已有的“連接”數量進行加權：連接數量越少，越有更大的幾率獲得這個任務的處理權。

2-3、租約與健康檢查

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

租約協議和我們提到的哈希算法一下一樣，也是系統架構設計中最基本的設計思想，并且大量運用在各類型的系統中，它的工作原理是每一位架構師都需要掌握的。例如：zookeeper使用這個協議保證Flow節點和Leader節點的鏈路是正常的;分布式存儲系統用這個協議保證datanode和namenode的連接是正常的;

3、負載均衡層技術匯總

在前面的博文中，我重點介紹了Nginx、LVS、Keepalived技術。由于時間有限，這里我們對博文中提到的幾種技術進行一個總結，然后再擴展介紹一下DNS技術、CDN技術和硬件負載技術。

3-1、Nginx技術

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

下面這些技術是我在博文中已經重點介紹過得，我們再做一下總結：

• Nginx中的連接數限制問題

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

soft nofile 65535
hard nofile 65535

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

user root root;
worker_processes 4;
worker_rlimit_nofile 65535;#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_connections 65535;
}

• Nginx中的Gzip技術

gzip是Nginx進行HTTP Body數據壓縮的技術。下面這段Nginx配置信息是啟用gzip壓縮的實例：

#開啟gzip壓縮服務， gzip on;#gzip壓縮是要申請臨時內存空間的，假設前提是壓縮后大小是小于等于壓縮前的。例如，如果原始文件大小為10K，那么它超過了8K，所以分配的內存是8 * 2 = 16K;再例如，原始文件大小為18K，很明顯16K也是不夠的，那么按照 8 * 2 * 2 = 32K的大小申請內存。如果沒有設置，默認值是申請跟原始數據相同大小的內存空間去存儲gzip壓縮結果。 gzip_buffers 2 8k;#進行壓縮的原始文件的最小大小值，也就是說如果原始文件小于5K，那么就不會進行壓縮了 gzip_min_length 5K;#gzip壓縮基于的http協議版本，默認就是HTTP 1.1 gzip_http_version 1.1;# gzip壓縮級別1-9，級別越高壓縮率越大，壓縮時間也就越長CPU越高 gzip_comp_level 5;#需要進行gzip壓縮的Content-Type的Header的類型。建議js、text、css、xml、json都要進行壓縮;圖片就沒必要了，gif、jpge文件已經壓縮得很好了，就算再壓，效果也不好，而且還耗費cpu。 gzip_types text/HTML text/plain application/x-javascript text/css application/xml;

http返回數據進行壓縮的功能在很多場景下都實用：

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

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

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

• Nginx中的rewrite(重寫)技術

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

下面是一段rewrite的示例：

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

• Nginx的圖片處理模塊

http_image_filter_module 是nginx的圖片處理模塊，是使用nginx進行靜態資源和動態資源分開管理的關鍵引用技術。通過這個模塊可以對靜態資源進行縮放、旋轉、驗證。

需要注意的是，http_image_filter_module模塊所處理的縮率圖片是不進行保存的，完全使用節點的CPU性能進行計算，使用節點的內存進行臨時存儲。所以如果要使用http_image_filter_module進行圖片處理，一定要根據客戶端的請求規模進行nginx節點的調整。并且當站點的PV達到一定的規模時，一定要使用CDN技術進行訪問加速、對圖片的訪問處理手段進行規劃。

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

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

yum install gd-devel

然后，Nginx要進行重新編譯：

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.$4 break;
image_filter resize $w $h;
image_filter_buffer 2M;
}

其中關于正則表達式的語法和已經介紹過的rewrite的語法就不再進行介紹了，主要看http_image_filter_module相關的屬性設置：

image_filter test：測試圖片文件合法性
image_filter rotate：進行圖片旋轉，只能按照90 | 180 | 270進行旋轉
image_filter size：返回圖片的JSON數據
image_filter resize width height：按比例進行圖片的等比例縮小，注意，是只能縮小，第二縮小是等比例的。
image_filter_buffer：限制圖片最大讀取大小，沒有設置就是1M；根據不同的系統最好設置為2M—3M
image_filter_jpeg_quality：設置jpeg圖片的壓縮比例（1-99，越高越好）
image_filter_transparency：禁用gif和png圖片的透明度。

• 和Nginx類似的其他技術/軟件

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

這里筆者再次重點提到Tengine，建議各位讀者有時間的時候可以使用一下，這個對Nginx進行了深度再開發的軟件。

3-2、LVS技術

LVS是Linux Virtual Server的簡寫，意即Linux虛擬服務器，是一個虛擬的服務器集群系統。本項目在1998年5月由章文嵩博士成立。

LVS集群采用IP負載均衡技術和基于內容請求分發技術。調度器具有很好的吞吐率，將請求均衡地轉移到不同的服務器上執行，且調度器自動屏蔽掉服務器的故障，從而將一組服務器構成一個高性能的、高可用的虛擬服務器。整個服務器集群的結構對客戶是透明的，而且無需修改客戶端和服務器端的程序。

在我的系列文章中，《架構設計：負載均衡層設計方案(4)——LVS原理》 、《架構設計：負載均衡層設計方案(5)——LVS單節點安裝》 、《負載均衡層設計方案(7)——LVS + Keepalived + Nginx安裝及配置》 都涉及到LVS的講解。

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

3-2-1、NAT模式

NAT方式是一種由LVS Master服務節點收到數據報，然后轉給下層的Real Server節點，當Real Server處理完成后回發給LVS Master節點然后又由LVS Master節點轉發出去的工作方式。LVS的管理程序IPVSADMIN負責綁定轉發規則，并完成IP數據報文和TCP數據報文中屬性的重寫。

LVS-NAT模式的優點在于：

1. 配置管理簡單。LVS-NAT的工作方式是LVS三種工作模式中最容易理解、最容易配置、最容易管理的工作模式。
2. 節省外網IP資源，一般機房分配給使用者的IP數量是有限的，特別是您購買的機架的數量不多時。LVS-NAT工作方式將您的系統架構封裝在局域網中，只需要LVS有一個外網地址或外網地址映射就可以實現訪問了。
3. 系統架構相對封閉。在內網環境下我們對防火墻的設置要求不會很高，也相對容易進行物理服務器的運維。您可以設置來源于外網的請求需要進行防火墻過濾，而對內網請求開放訪問。
4. 另外改寫后轉給Real Server的數據報文，Real Server并不會關心它的真實性，只要TCP校驗和IP校驗都能通過，Real Server就可以進行處理。所以LVS-NAT工作模式下Real Server可以是任何操作系統，只要它支持TCP/IP協議即可。

3-2-2、DR模式

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

LVS-DR模式的優點在于：

解決了LVS-NAT工作模式中的轉發瓶頸問題，能夠支撐規模更大的負載均衡場景。

比較耗費網外IP資源，機房的外網IP資源都是有限的，如果在正式生產環境中確實存在這個問題，可以采用LVS-NAT和LVS-DR混合使用的方式來緩解。

LVS-DR當然也有缺點：

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

由于LVS-DR模式的報文改寫規則，導致LVS節點和Real Server節點必須在一個網段，因為二層交換是沒法跨子網的。但是這個問題針對大多數系統架構方案來說，實際上并沒有本質限制。

3-2-3、TUN模式

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

IPIP隧道。將一個完整的IP報文封裝成另一個新的IP報文的數據部分，并通過路由器傳送到指定的地點。在這個過程中路由器并不在意被封裝的原始協議的內容。到達目的地點后，由目的地方依靠自己的計算能力和對IPIP隧道協議的支持，打開封裝協議，取得原始協議：

可以說LVS-TUN方式基本上具有LVS-DR的優點。在此基礎上又支持跨子網間穿透。

3-3、CDN技術

CDN技術Content Delivery Network：內容分發網絡。為什么有時我們訪問互聯網上的視頻資源、圖片資源會比較慢，甚至訪問失敗。其中有一個重要的原因，是資源的物理位置離客戶端太遠了，可能其中有4層NAT設備(相當于使用網通的線路訪問電信服務器上的資源)。

我們試想一下，如果將我們要訪問的資源放到離我們客戶端最近的一個服務上(例如在廣州的客戶端訪問的資源就在廣州的機房)。那么是不是就解決了這個問題(這個點稱為“邊緣節點”)。這就是CDN網絡解決的問題，如下圖所示：

可以說LVS-TUN方式基本上具有LVS-DR的優點。在此基礎上又支持跨子網間穿透。

3-3、CDN技術

CDN技術Content Delivery Network：內容分發網絡。為什么有時我們訪問互聯網上的視頻資源、圖片資源會比較慢，甚至訪問失敗。其中有一個重要的原因，是資源的物理位置離客戶端太遠了，可能其中有4層NAT設備(相當于使用網通的線路訪問電信服務器上的資源)。

我們試想一下，如果將我們要訪問的資源放到離我們客戶端最近的一個服務上(例如在廣州的客戶端訪問的資源就在廣州的機房)。那么是不是就解決了這個問題(這個點稱為“邊緣節點”)。這就是CDN網絡解決的問題，如下圖所示：

目前CDN服務不需要我們進行開發，市面上有很多公司都提供免費的/付費的 CDN服務。當然如果您想自行搭建CDN網絡，可以參考以下技術方案：

Squid：Squid是一個緩存internet數據的一個軟件，它接收用戶的下載申請，并自動處理所下載的數據。目前，國內很多CDN服務商的網絡都是基于Squid搭建的

利用Nginx的proxy_cache搭建：Nginx中的rewrite技術實際上就可以實現URL請求重寫，實現請求轉發。而Nginx中的proxy_cache組件可以使得從遠端請求的源數據保存在本地，從而實現一個CDN網絡的搭建。

自己寫：CDN網絡沒有特別復雜的技術門檻，如果您有特別的需求，可以自己寫一個。當然上圖中所介紹的CDN網絡屬于第一代CDN網絡，將第二代/第三代P2P技術加入到CDN原理中，可以形成第二代CDN網絡：如下圖所示：

第三代P2P技術又被稱為混合型P2P技術主要是為了解決元數據服務器的處理壓力，加速資源的本地化速度。關于P2P技術我會在講完“業務系統設計”、“業務通信系統設計”后，專門做一個新的專題進行介紹。另外提一下，YouTube的P2P網絡就是自己做的。

3、負載均衡層技術匯總

3-4、Keepalived技術

在這些文章中從來沒有單獨介紹Keepalived。這是因Keepalived是為了監控集群節點的工作狀態，在因為某種原因不能正常提供服務的前提下，完成備機的切換。這里面有兩個關鍵點：監控節點上提供的服務、完成網絡切換。keepalived本身是不提供業務服務的，只是監控提供的服務是否正常工作，那么既然都沒有可以監控的服務，那么Keepalived有什么獨立使用的必要呢?

下圖是Nginx + Keepalived的工作結構和LVS + Keepalived 的工作結構：

Nginx + Keepalived的工作方式

LVS + Keepalived + Nginx的工作方式

相關技術還有：

Heartbeat是Linux-HA計劃中的一個重要項目，它的功能比Keepalived更強大，安裝和管理也相對復雜。網絡上有很多資料介紹Heartbeat和Keepalived的優缺點和使用對比。但就我自己的使用經驗來說，個人更喜歡使用Keepalived，原因很簡單：Keepalived安裝和配置更簡單，而且夠用。另外Redhat Rhcs套件也可以搭建類似的HA集群，但是說實話本人沒有嘗試過。

3-5、DNS輪詢和智能DNS

//TODO DNS技術還沒有介紹

3-6、硬件負載

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

但是硬件負載方案也有其缺點，主要就是建設費用比較高昂，它不像軟負載可以根據系統的吞吐量的持續增加進行持續擴展。當然您可以根據系統的吞吐量需求，在前期采用軟負載，后期采用硬件負載的方案。除了F5公司提供的硬件負載技術，還有Citrix公司的硬負載方案、A10公司的硬件負載方案。

4、常見負載均衡技術組合

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

4-1、獨立的Nginx/Haproxy

一般的WEB系統，前段假設一個Nginx或者Haproxy服務器，基本上可以解決包括負載分發在內的很多問題了。

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

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

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

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

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

5、負載均衡技術的其他運用

在這個系列的文章中，我們全在將用于客戶端使用HTTP協議請求服務器端進行處理的情況，這里的客戶端可以使最終用戶，也可以是某個一第三方系統。但實際上負載均衡技術在信息處理領域內，不是只有這樣的請求響應層才使用，在其它的技術領域也大量使用，這個小節，我們就來梳理這些技術，作為一個擴展話題。

5-1、關系型數據庫系統的負載均衡

一說到關系型數據庫，大家自然會聯想到Oracle、MS SQL、DB2 和Mysql。在移動互聯網領域，通常很多公司在走去OEI的路程。這里我們不去討論去OEI是否是正確的，也不去討論怎樣走去OEI這條路才合理，一個不可爭辯的事實是，目前很多移動互聯網公司在使用Mysql數據庫。

單臺Mysql數據庫的處理能力確實趕不上Oracle，甚至趕不上MS SQL這些商用數據庫，但是我們可以為Mysql做集群來提高整個數據服務的性能。Mysql從5.1.X版本開始，就已經支持單數據節點的“表分區”功能了，但這個支持僅限于每個節點的配置，提高單個Mysql上的讀寫性能(還要配合底層的塊存儲選型，例如DAS)。而想要實現整個Mysql集群性能，就需要從更高級別實現讀寫分離了。

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

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

1. Mysql Master和Mysql Salve的數據同步是通過MySQL Replication同步技術來實現的，這是一種基于操作日志的異步同步，雖然響應時間不能達到“毫秒”級，但是基本上還是很快很快的。如果不是銀行系統、或者“秒殺系統”基本上可以滿足事實性
2. MySQL Replication會降低Mysql Master節點的20%的工作性能，但是轉移了原來Mysql Master負責的所有讀操作。當然，我們以后介紹“多主”方式和使用HiveDB橫向切分的時候，還會重點介紹如何提高Mysql的寫性能。
3. 事實上正式的開發架構中，我們不會給程序員兩個數據源，這樣既不利于代碼的管理，也增加了開發難度。我們會采用類似Mysql-Proxy、Amoeba之類的軟件實現數據源的整個。
4. 后面在介紹數據存儲層架構的時候，我還會介紹多種成熟的可靠的Mysql集群、Mysql讀寫分離、Mysql橫向擴展方式，和讀者討論如何實現幾十臺Mysql節點的運行和管理。

5-2、分布式存儲系統的負載均衡

分布式存儲系統目前有很多，Ceph、Swift、MFS、HDFS。他們有的是基于對象存儲的，有的是基于快存儲的(在《標準Web系統的架構分層》這篇博文中，我對塊存儲、文件存儲和對象存儲做了較詳細的介紹，后文我們還將詳細介紹存儲系統)。但是他們有一個或者多個主控節點(有的叫namenode、有的叫master、有的叫Metadata)，無論怎么叫，他們都有一些相同的功能：

1. 計算“數據該存儲在哪里”的問題
2. 協調控制“數據是否正確存儲”的問題
3. 監控“數據節點”的健康狀態
4. 轉移數據
5. 回答客戶端“到哪里取數據”的問題
6. 。。。。。

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

5-3、更廣義的負載均衡系統

相同的客流量下，銀行多個窗口排隊的等待時間肯定比一個窗口排隊的時間短;同樣的車流量，8車道肯定比6車道的通過率高;把一個任務拆分成多個任務由多個人負責處理其中的一部分，肯定比一個人做一個大任務的時間短;

負載均衡的核心思想在于分流、關鍵問題在于如何分流、評價標準在于分流后的吞吐量。