【轉(zhuǎn)自】：https://forum.huawei.com/enterprise/zh/thread-478965.html
DR 模式：直接路由
DR 模式下需要 LVS 和 RS 集群綁定同一個 VIP（RS 通過將 VIP 綁定在 loopback 實現(xiàn)），但與 NAT 的不同點在于：請求由 LVS 接受竿报，由真實提供服務(wù)的服務(wù)器（RealServer句携，RS）直接返回給用戶疗锐，返回的時候不經(jīng)過 LVS衡载。
詳細來看搔耕，一個請求過來時，LVS 只需要將網(wǎng)絡(luò)幀的 MAC 地址修改為某一臺 RS 的 MAC痰娱，該包就會被轉(zhuǎn)發(fā)到相應(yīng)的 RS 處理弃榨，注意此時的源 IP 和目標 IP 都沒變，LVS 只是做了一下移花接木梨睁。RS 收到 LVS 轉(zhuǎn)發(fā)來的包時鲸睛，鏈路層發(fā)現(xiàn) MAC 是自己的，到上面的網(wǎng)絡(luò)層坡贺，發(fā)現(xiàn) IP 也是自己的官辈，于是這個包被合法地接受划咐，RS 感知不到前面有 LVS 的存在。而當 RS 返回響應(yīng)時钧萍，只要直接向源 IP（即用戶的 IP）返回即可，不再經(jīng)過 LVS政鼠。
DR 負載均衡模式數(shù)據(jù)分發(fā)過程中不修改 IP 地址风瘦，只修改 mac 地址，由于實際處理請求的真實物理 IP 地址和數(shù)據(jù)請求目的 IP 地址一致公般，所以不需要通過負載均衡服務(wù)器進行地址轉(zhuǎn)換万搔，可將響應(yīng)數(shù)據(jù)包直接返回給用戶瀏覽器，避免負載均衡服務(wù)器網(wǎng)卡帶寬成為瓶頸官帘。因此瞬雹，DR 模式具有較好的性能，也是目前大型網(wǎng)站使用最廣泛的一種負載均衡手段刽虹。
LVS 的優(yōu)點
抗負載能力強酗捌、是工作在傳輸層上僅作分發(fā)之用，沒有流量的產(chǎn)生涌哲，這個特點也決定了它在負載均衡軟件里的性能最強的胖缤，對內(nèi)存和 cpu 資源消耗比較低。
配置性比較低阀圾，這是一個缺點也是一個優(yōu)點哪廓，因為沒有可太多配置的東西，所以并不需要太多接觸初烘，大大減少了人為出錯的幾率涡真。
工作穩(wěn)定，因為其本身抗負載能力很強肾筐，自身有完整的雙機熱備方案哆料，如 LVS + Keepalived。
無流量吗铐，LVS 只分發(fā)請求剧劝，而流量并不從它本身出去，這點保證了均衡器 IO 的性能不會受到大流量的影響抓歼。
應(yīng)用范圍比較廣讥此，因為 LVS 工作在傳輸層，所以它幾乎可以對所有應(yīng)用做負載均衡谣妻，包括 http萄喳、數(shù)據(jù)庫、在線聊天室等等蹋半。
LVS 的缺點
軟件本身不支持正則表達式處理他巨，不能做動靜分離；而現(xiàn)在許多網(wǎng)站在這方面都有較強的需求，這個是 Nginx染突、HAProxy + Keepalived 的優(yōu)勢所在捻爷。
如果是網(wǎng)站應(yīng)用比較龐大的話，LVS/DR + Keepalived 實施起來就比較復(fù)雜了份企，相對而言也榄，Nginx / HAProxy + Keepalived 就簡單多了。
Nginx
Nginx 是一個強大的 Web 服務(wù)器軟件司志，用于處理高并發(fā)的 HTTP 請求和作為反向代理服務(wù)器做負載均衡甜紫。具有高性能、輕量級骂远、內(nèi)存消耗少囚霸，強大的負載均衡能力等優(yōu)勢。
Nignx 的架構(gòu)設(shè)計
相對于傳統(tǒng)基于進程或線程的模型（Apache就采用這種模型）在處理并發(fā)連接時會為每一個連接建立一個單獨的進程或線程激才，且在網(wǎng)絡(luò)或者輸入/輸出操作時阻塞拓型。這將導(dǎo)致內(nèi)存和 CPU 的大量消耗，因為新起一個單獨的進程或線程需要準備新的運行時環(huán)境瘸恼，包括堆和棧內(nèi)存的分配吨述，以及新的執(zhí)行上下文，當然钞脂，這些也會導(dǎo)致多余的 CPU 開銷揣云。最終，會由于過多的上下文切換而導(dǎo)致服務(wù)器性能變差冰啃。
反過來邓夕，Nginx 的架構(gòu)設(shè)計是采用模塊化的、基于事件驅(qū)動阎毅、異步焚刚、單線程且非阻塞。
Nginx 大量使用多路復(fù)用和事件通知扇调，Nginx 啟動以后矿咕，會在系統(tǒng)中以 daemon 的方式在后臺運行，其中包括一個 master 進程狼钮，n(n>=1) 個 worker 進程碳柱。所有的進程都是單線程（即只有一個主線程）的，且進程間通信主要使用共享內(nèi)存的方式熬芜。
其中莲镣，master 進程用于接收來自外界的信號，并給 worker 進程發(fā)送信號涎拉，同時監(jiān)控 worker 進程的工作狀態(tài)瑞侮。worker 進程則是外部請求真正的處理者的圆，每個 worker 請求相互獨立且平等的競爭來自客戶端的請求。請求只能在一個 worker 進程中被處理半火，且一個 worker 進程只有一個主線程越妈，所以同時只能處理一個請求。（原理同 Netty 很像）
Nginx 負載均衡
Nginx 負載均衡主要是對七層網(wǎng)絡(luò)通信模型中的第七層應(yīng)用層上的 http钮糖、https 進行支持梅掠。
Nginx 是以反向代理的方式進行負載均衡的。反向代理（Reverse Proxy）方式是指以代理服務(wù)器來接受 Internet 上的連接請求藐鹤，然后將請求轉(zhuǎn)發(fā)給內(nèi)部網(wǎng)絡(luò)上的服務(wù)器，并將從服務(wù)器上得到的結(jié)果返回給 Internet 上請求連接的客戶端赂韵，此時代理服務(wù)器對外就表現(xiàn)為一個服務(wù)器娱节。
Nginx 實現(xiàn)負載均衡的分配策略有很多，Nginx 的 upstream 目前支持以下幾種方式：
輪詢（默認）：每個請求按時間順序逐一分配到不同的后端服務(wù)器祭示，如果后端服務(wù)器 down 掉肄满，能自動剔除。
weight：指定輪詢幾率质涛，weight 和訪問比率成正比稠歉，用于后端服務(wù)器性能不均的情況。
ip_hash：每個請求按訪問 ip 的 hash 結(jié)果分配汇陆，這樣每個訪客固定訪問一個后端服務(wù)器怒炸，可以解決 session 的問題。
fair（第三方）：按后端服務(wù)器的響應(yīng)時間來分配請求毡代，響應(yīng)時間短的優(yōu)先分配阅羹。
url_hash（第三方）：按訪問 url 的 hash 結(jié)果來分配請求，使每個 url 定向到同一個后端服務(wù)器教寂，后端服務(wù)器為緩存時比較有效捏鱼。
Nginx 的優(yōu)點
跨平臺：Nginx 可以在大多數(shù) Unix like OS編譯運行，而且也有 Windows 的移植版本
配置異常簡單：非常容易上手酪耕。配置風(fēng)格跟程序開發(fā)一樣导梆，神一般的配置
非阻塞、高并發(fā)連接：官方測試能夠支撐5萬并發(fā)連接迂烁，在實際生產(chǎn)環(huán)境中跑到2～3萬并發(fā)連接數(shù)
事件驅(qū)動：通信機制采用 epoll 模型看尼，支持更大的并發(fā)連接
Master/Worker 結(jié)構(gòu)：一個 master 進程，生成一個或多個 worker 進程
內(nèi)存消耗忻瞬健：處理大并發(fā)的請求內(nèi)存消耗非常小狡忙。在3萬并發(fā)連接下，開啟的10個 Nginx 進程才消耗150M 內(nèi)存（15M*10=150M）
內(nèi)置的健康檢查功能：如果 Nginx 代理的后端的某臺 Web 服務(wù)器宕機了址芯，不會影響前端訪問
節(jié)省帶寬：支持 GZIP 壓縮灾茁，可以添加瀏覽器本地緩存的 Header 頭
穩(wěn)定性高：用于反向代理窜觉，宕機的概率微乎其微
Nginx 的缺點
Nginx 僅能支 持http、https 和 Email 協(xié)議北专，這樣就在適用范圍上面小些啦粹，這個是它的缺點
對后端服務(wù)器的健康檢查，只支持通過端口來檢測浑塞，不支持通過 ur l來檢測关筒。不支持 Session 的直接保持，但能通過 ip_hash 來解決
HAProxy
HAProxy 支持兩種代理模式 TCP（四層）和HTTP（七層）驶睦，也是支持虛擬主機的砰左。
HAProxy 的優(yōu)點能夠補充 Nginx 的一些缺點，比如支持 Session 的保持场航，Cookie 的引導(dǎo)缠导；同時支持通過獲取指定的 url 來檢測后端服務(wù)器的狀態(tài)。
HAProxy 跟 LVS 類似溉痢，本身就只是一款負載均衡軟件僻造；單純從效率上來講 HAProxy 會比 Nginx 有更出色的負載均衡速度，在并發(fā)處理上也是優(yōu)于 Nginx 的孩饼。
HAProxy 支持 TCP 協(xié)議的負載均衡轉(zhuǎn)發(fā)髓削，可以對 MySQL 讀進行負載均衡，對后端的 MySQL 節(jié)點進行檢測和負載均衡镀娶，大家可以用 LVS+Keepalived 對 MySQL 主從做負載均衡立膛。
HAProxy 負載均衡策略非常多：Round-robin（輪循）、Weight-round-robin（帶權(quán)輪循）梯码、source（原地址保持）旧巾、RI（請求URL）、rdp-cookie（根據(jù)cookie）忍些。
