根據規模的提升在不同的階段需要使用不同的技術和架構，具體的需求需要具體分析，如果是中小型的 Web 應用，

• 榷訓躍小于 1000 萬，使用 nginx 就可以完全滿足了；
• 大型網站或重要的服務，并且服務比較多時，就可以考慮使用 LVS，

Nginx

Nginx ("engine x") 是一個高性能的 HTTP 和 反向代理 服務器，也是一個 IMAP/POP3/SMTP 代理服務器，

Nginx 特點是占有記憶體少，并發能力強，nginx 的并發能力在同型別的網頁服務器中表現較好，

Nginx 的簡單架構：

Nginx 的架構設計

Nginx 的架構設計采用的是模塊化的，基于事件驅動、異步、單執行緒且非阻塞（epoll 模型）

Nginx 使用多路復用和事件通知，Nginx 啟動后，在后臺以 daemon 的方式在系統中運行，其中會包括一個主（master）行程，n（n≥1）個作業（worker）行程，

所有的行程都是單執行緒（即只有一個主執行緒）的，行程間通信主要使用共享記憶體的方式，

其中，master 行程用于接收外部的請求，發送信號給 worker 行程，同時監控 worker 行程的作業狀態，

worker 行程用來處理外部請求資訊，請求只能在一個 worker 行程中被處理，一個 worker 行程只有一個主執行緒，同時只能處理一個請求，

Nginx 負載均衡

Nginx 負載均衡是對七層網路通信模型中的應用層（HTTP，HTTPS）進行的，

Nginx 是以反向代理的方式進行負載均衡

• 反向代理：是以代理服務器來接收用戶的請求，然后將請求發給內部網路上的服務器，并將服務器上的結果回傳給請求的客戶端，此時代理服務器就是一個服務器，
• 負載均衡：就是將這些客戶端的請求按照某種策略分攤到后臺多臺服務器上面，進行處理，

Nginx 的 upstream 目前支持 6 種演算法分配方式：

輪詢

最基本的配置方法，它是 upstream 模塊默認的負載均衡默認策略，每個請求會按時間順序逐一分配到不同的后端服務器，

有如下引數：

在 30 秒內錯誤次數超過 2 次，就認為服務器已經不能訪問了，下次就不會訪問該機器

server 10.168.226.1:8080 max_fails=2 fail_timeout=30s;

server 10.168.226.2:8080 max_fails=2 fail_timeout=30s;

weight

權重方式，在輪詢策略的基礎上指定輪詢的幾率

server 10.168.226.1:8080 weight=1 ;

server 10.168.226.2:8080 weight=2;

注意：

• 權重越高分配到需要處理的請求越多，
• 此策略比較適合服務器的硬體配置差別比較大的情況，

ip_hash

指定負載均衡器按斬訓于客戶端 IP 的分配方式，這個方法確保了相同的客戶端的請求一直發送到相同的服務器，以保證 session 會話，

這樣每個訪客都固定訪問一個后端服務器，可以解決 session 不能跨服務器的問題，

ip_hash; # 保證每個訪客固定訪問一個后端服務器

server 10.168.226.1:8080 weight=1 ;

server 10.168.226.2:8080 weight=2;

注意：

ip_hash在nginx1.3版本之后才有的 ip_hash不能與backup同時使用這種策略適合有狀態服務，比如session 當有服務器需要剔除，必須手動down掉，

least_conn

把請求轉發給連接數較少的后端服務器，輪詢演算法是把請求平均的轉發給各個后端服，使它們的負載大致相同，

但是，有些請求占用的時間很長，會導致所在的后端負載較高，這種情況下，least_conn這種方式就可以達到更好的負載均衡效果least_conn;

server 10.168.226.1:8080 weight=1;

server 10.168.226.2:8080 weight=2;

注意：

這種負載均衡策略適合請求處理時間長短不一致造成服務器過載的情況

第三方策略

第三方的負載均衡策略的實作需要安裝第三方插件（upstream_fair)

• fair安裝服務器端回應時間來分配請求，回應時間段的優先分配fair；server 10.168.226.1:8080 weight=1;
  server 10.168.226.2:8080 weight=2;
• url_hash按訪問 URL 的 hash 結果來分配請求，是每個 URL 定向知道同一個后端服務器，要配合緩沖命中來使用同一個資源多次求，可能會到達不同的服務器上，導致不必要的多次下載，快取命中率不高以及一些資源時間的浪費，而使用 url_hash，可以使得同一個 URL 會到達同一臺服務器，一段快取了資源，再次請求的時候，就可以從快取中讀取，需要 hash 軟體包

• hash $request_uri; # 實作每個 URL 定向到同一個后端服務器
• server 10.168.226.1:8080 weight=1;
  server 10.168.226.2:8080 weight=2;

Nginx 的優點

• 跨平臺：Nginx 可以在 Linux 上編譯運行，也可以在 window 上運行
• 配置簡單：直接可以通過簡單修改組態檔，容易上手
• 非阻塞、高并發：官網理論可以支持 5 萬并發連接，在實際生產環境也可以跑到 2-3 萬的并發
• 事件驅動：采用 epoll 模型，支持更多的并發連接
• 記憶體消耗小：記憶體和 CPU 占用率低，（為 Apache 的 1/5-1/10）
• 內置健康檢查：Nginx 代理的后端的某臺服務器宕機了，會自動不訪問該機器

Nginx 的缺點

• Nginx 僅能支持 HTTP，HTTPS，tcp，email 等協議
• 不支持直接保存 session，可以通過 ip_hash 來支持

LVS

LVS 就是 Linux 虛擬（Virtual Server）服務器，從 Linux 內核 2.4 之后，內置了 LVS 的各個功能模塊，就可以直接 使用 LVS 提供的功能，

LVS 的體系架構

LVS 架構 的服務器集群系統有三個部分 組成：

• 最前端的負載均衡層，用 Load Balancer 表示
• 中間的服務器集群層，用 Server Array 表示
• 最底層的資料共享層，Shard storage 表示

負載均衡機制

LVS 是四層負載均衡，建立在 OSI 模型的第四層——傳輸層之上，傳輸層有 TCP/UDP，相對于其它高層負載均衡的方法，比如 DNS 域名輪詢決議，應用層負載的調度，客戶端的調度等，它的效率都非常高，

• 四層負載均衡：主要通過報文中的目標地址和埠
• 七層負載均衡：也稱為“內容交換”，主要通過報文中的 真正有意義的應用層內容，

LVS 的轉發主要通過修改 IP 地址（NAT 模式，分為源地址修改 SNAT 和目標地址修改 DNAT）、修改目標 MAC（DR 模式）來實作，

LVS 相關術語

DS：Director Server，指的是前端負載均衡器節點，

RS：Real Server，后端真實的作業服務器，

VIP：向外部直接面向用戶請求，作為用戶請求的目標的 IP 地址，

DIP：Director Server IP，主要用于和內部主機通訊的 IP 地址，

RIP：Real Server IP，后端服務器的 IP 地址，

CIP：Client IP，訪問客戶端的 IP 地址

NAT 模式：網路地址轉換

NAT（network address transaction）是外網和內網地址映射的技術，

NAT 模式下，網路資料的進出都要經過 LVS 處理，LVS 需要作為真實服務器的網關，

• 當包請求到 LVS 時，LVS 做目標地址轉換(DNAT)，將目標 IP 改為 RS 的 IP，
• RS 處理完，回傳回應時，源 IP 是 RS IP，目標 IP 是客戶端的 IP，
• RS 的包通過網關(LVS)中轉，LVS 做源地址轉換(SNAT)，將包的源地址改為 VIP，這樣，這個包對客戶端來說就像是 LVS 直接回傳給它的，

DR 模式：直接路由

DR 模式下需要 LVS 和 RS 集群系結同一個 VIP，與 NAT 的不同點在于：

請求由 LVS 接受，由真實提供服務的服務器(RS)直接發放給用戶，回傳的時候不經過 LVS，

一個請求程序中，LVS 只需要將網路幀的 Mac 地址修改為某一臺 RS 的 MAC，該請求就去會被轉發到回應的 RS 處理，此時的源 IP 和目標 IP 都沒有變，

RS 收到 LVS 轉發來的請求時，鏈路層發現 Mac 地址是自己的，當上面的網路層，也發現 IP 是自己的，于是這個包被合法的接受，RS 感知不到前面有 RS 的存在，當 RS 回傳回應時，只要直接向源 IP 回傳即可，不再經過 LVS，

DR 負載均衡模式資料分發程序中不修改 IP 地址，只修改 Mac 地址，由于實際處理請求的真實物理 IP 地址和 資料請求目的 IP 地址一致，所以不需要通過負載均衡服務器進行地址轉換，就可以將回應資料直接回傳給瀏覽器，避免服務器網卡帶寬成為瓶頸，

DR 模式具有較好的性能，也是目前大型網站使用最廣泛的一種負載均衡，

LVS 的優點

• 負載能力強，作業在傳輸層上僅作為分發的作用，沒有流量的產生，對記憶體和 CPU 資源消耗比較低
• 配置簡單，很容易上手
• 作業穩定，有完整的雙機熱備方案，如：LVS+Keepalived
• 無流量，LVS 只分發請求
• 應用范圍比較廣，LVS 作業在傳輸層，幾乎可以對所有應用做負載均衡，包括 HTTP，資料庫

LVS 的缺點

• 軟體本身不支持正則運算式，不能做動靜方法分離
• 網站應用比較龐大的話，LVS 實施起來比較復雜

這些資料，對于【軟體測驗】的朋友來說應該是最全面最完整的備戰倉庫，這個倉庫也陪伴我走過了最艱難的路程，希望也能幫助到你

關注我的微信公眾號【程式員二黑】免費獲取

最后，寫給大家：每一個優秀的人，都不是帶著與生俱來的光環的，也不一定是比別人幸運，他們只是在任何一件小事上，都對自己有所要求，不因舒適而散漫放縱，不因辛苦而放棄追求，雕塑自己的程序，必定伴隨著疼痛與辛苦，可那一錘一鑿的自我敲打，終究能讓我們識訓一個更好的自己，