即時通信新手入門：一文讀懂什麼是Nginx？它可否實現IM的負載均衡？

時間  2019-11-11
標籤 即時 通信 新手 入門 一文 讀懂 什麼 nginx 可否 實現 負載 均衡 欄目 Nginx 简体版
原文   原文鏈接

本文引用了「薔薇Nina」的「Nginx 相關介紹(Nginx是什麼?能幹嗎?)」一文部份內容，感謝做者的無私分享。php

一、引言

 

Nginx（及其衍生產品）是目前被大量使用的服務端反向代理和負載均衡方案，從某種意義上來說，Nginx幾乎是低成本、高負載Web服務端代名詞。html

如此深刻人心的Nginx，不少人也想固然的認爲，在IM或消息推送等場景下是否也能使用Nginx來解決負載均衡問題？mysql

另外，即時通信網的論壇和QQ羣裏也常常有人問起，Nginx是否能支持TCP、UDP、WebSocket的負載均衡？nginx

帶着上面的疑問，咱們來開始本文的學習吧！算法

學習交流：sql

- 即時通信/推送技術開發交流4羣：101279154[推薦]數據庫

- 移動端IM開發入門文章：《新手入門一篇就夠：從零開發移動端IM》編程

（本文同步發佈於：http://www.52im.net/thread-2600-1-1.html）後端

二、相關文章

三、Nginx的產生

沒有聽過Nginx？那麼必定聽過它的"同行"Apache吧！Nginx同Apache同樣都是一種WEB服務器。基於REST架構風格，以統一資源描述符(Uniform Resources Identifier)URI或者統一資源定位符(Uniform Resources Locator)URL做爲溝通依據，經過HTTP協議提供各類網絡服務。瀏覽器

然而，這些服務器在設計之初受到當時環境的侷限，例如當時的用戶規模，網絡帶寬，產品特色等侷限而且各自的定位和發展都不盡相同。這也使得各個WEB服務器有着各自鮮明的特色。

Apache的發展時期很長，並且是毫無爭議的世界第一大服務器。它有着不少優勢：穩定、開源、跨平臺等等。它出現的時間太長了，它興起的年代，互聯網產業遠遠比不上如今。因此它被設計爲一個重量級的。它不支持高併發的服務器。在Apache上運行數以萬計的併發訪問，會致使服務器消耗大量內存。操做系統對其進行進程或線程間的切換也消耗了大量的CPU資源，致使HTTP請求的平均響應速度下降。

這些都決定了Apache不可能成爲高性能WEB服務器，輕量級高併發服務器Nginx就應運而生了。

俄羅斯的工程師Igor Sysoev，他在爲Rambler Media工做期間，使用C語言開發了Nginx。Nginx做爲WEB服務器一直爲Rambler Media提供出色而又穩定的服務。

 

▲ Igor Sysoev，Nginx的創始人

而後呢，Igor Sysoev將Nginx代碼開源，而且賦予自由軟件許可證。

因爲如下緣由：

1）Nginx使用基於事件驅動架構，使得其能夠支持數以百萬級別的TCP鏈接；

2）高度的模塊化和自由軟件許可證使得第三方模塊層出不窮（這是個開源的時代啊~）；

3）Nginx是一個跨平臺服務器，能夠運行在Linux，Windows，FreeBSD，Solaris，AIX，Mac OS等操做系統上；

4）這些優秀的設計帶來的是極大的穩定性。

因此，Nginx火了！

四、Nginx最多見的用途、用法、使用場景

4.1 概述

簡而言之，Nginx是：

1）自由的、開源的、高性能的HTTP服務器和反向代理服務器；

2）也是一個IMAP、POP三、SMTP代理服務器；

3）能夠做爲一個HTTP服務器進行網站的發佈處理；

4）能夠做爲反向代理進行負載均衡的實現。

4.2 什麼是代理？

說到代理，首先咱們要明確一個概念，所謂代理就是一個表明、一個渠道。

此時就涉及到兩個角色，一個是被代理角色，一個是目標角色，被代理角色經過這個代理訪問目標角色完成一些任務的過程稱爲代理操做過程；如同生活中的專賣店~客人到adidas專賣店買了一雙鞋，這個專賣店就是代理，被代理角色就是adidas廠家，目標角色就是用戶。

4.3 什麼是正向代理？

說反向代理以前，咱們先看看正向代理，正向代理也是你們最常接觸的到的代理模式，咱們會從兩個方面來講關於正向代理的處理模式，分別從軟件方面和生活方面來解釋一下什麼叫正向代理。

在現在的網絡環境下，咱們若是因爲技術須要要去訪問國外的某些網站，此時你會發現位於國外的某網站咱們經過瀏覽器是沒有辦法訪問的，此時你們可能都會用一個操做FQ進行訪問，FQ的方式主要是找到一個能夠訪問國外網站的代理服務器，咱們將請求發送給代理服務器，代理服務器去訪問國外的網站，而後將訪問到的數據傳遞給咱們！

上述這樣的代理模式稱爲正向代理：

1）正向代理最大的特色是客戶端很是明確要訪問的服務器地址；

2）服務器只清楚請求來自哪一個代理服務器，而不清楚來自哪一個具體的客戶端；

3）正向代理模式屏蔽或者隱藏了真實客戶端信息。

來看個示意圖（我把客戶端和正向代理框在一塊，同屬於一個環境，後面我有介紹）：

 

客戶端必須設置正向代理服務器，固然前提是要知道正向代理服務器的IP地址，還有代理程序的端口。

以下圖所示：

 

總結來講：正向代理，"它代理的是客戶端，代客戶端發出請求"，是一個位於客戶端和原始服務器(origin server)之間的服務器，爲了從原始服務器取得內容，客戶端向代理髮送一個請求並指定目標(原始服務器)，而後代理向原始服務器轉交請求並將得到的內容返回給客戶端。客戶端必需要進行一些特別的設置才能使用正向代理。

正向代理的用途：

1）訪問原來沒法訪問的資源，如Google；

2） 能夠作緩存，加速訪問資源；

3）對客戶端訪問受權，上網進行認證；

4）代理能夠記錄用戶訪問記錄（上網行爲管理），對外隱藏用戶信息。

4.4 什麼是反向代理？

明白了什麼是正向代理，咱們繼續看關於反向代理的處理方式。

舉例如我大天朝的某寶網站，天天同時鏈接到網站的訪問人數已經爆表，單個服務器遠遠不能知足人民日益增加的購買慾望了，此時就出現了一個你們耳熟能詳的名詞：分佈式部署。

所謂分佈式部署，也就是經過部署多臺服務器來解決訪問人數限制的問題。某寶網站中大部分功能也是直接使用Nginx進行反向代理實現的，而且經過封裝Nginx和其餘的組件以後起了個高大上的名字：Tengine，有興趣的童鞋能夠訪問Tengine的官網查看具體的信息：http://tengine.taobao.org/。

那麼反向代理具體是經過什麼樣的方式實現的分佈式的集羣操做呢，咱們先看一個示意圖（我把服務器和反向代理框在一塊，同屬於一個環境，後面我有介紹），以下圖所示。

 

經過上述的圖解你們就能夠看清楚了：多個客戶端給服務器發送的請求，Nginx服務器接收到以後，按照必定的規則分發給了後端的業務處理服務器進行處理了。此時~請求的來源也就是客戶端是明確的，可是請求具體由哪臺服務器處理的並不明確了，Nginx扮演的就是一個反向代理角色。

客戶端是無感知代理的存在的，反向代理對外都是透明的，訪問者並不知道本身訪問的是一個代理。由於客戶端不須要任何配置就能夠訪問。

反向代理，"它代理的是服務端，代服務端接收請求"，主要用於服務器集羣分佈式部署的狀況下，反向代理隱藏了服務器的信息。

反向代理的做用：

1）保證內網的安全，一般將反向代理做爲公網訪問地址，Web服務器是內網；

2）負載均衡，經過反向代理服務器來優化網站的負載。

典型的項目場景：

一般狀況下，咱們在實際項目操做時，正向代理和反向代理頗有可能會存在在一個應用場景中，正向代理代理客戶端的請求去訪問目標服務器，目標服務器是一個反向單利服務器，反向代理了多臺真實的業務處理服務器。

具體的拓撲圖以下：

 

4.5 正向代碼和反向代理的區別

截了一張圖來講明正向代理和反向代理兩者之間的區別，以下圖。

 

圖解以下：

1）在正向代理中，Proxy和Client同屬於一個LAN（圖中方框內），隱藏了客戶端信息；

2）在反向代理中，Proxy和Server同屬於一個LAN（圖中方框內），隱藏了服務端信息。

實際上，Proxy在兩種代理中作的事情都是替服務器代爲收發請求和響應，不過從結構上看正好左右互換了一下，因此把後出現的那種代理方式稱爲反向代理了。

4.6 Nginx的負載均衡技術

咱們已經明確了所謂代理服務器的概念，那麼接下來，Nginx扮演了反向代理服務器的角色，它是以依據什麼樣的規則進行請求分發的呢？不用的項目應用場景，分發的規則是否能夠控制呢？

這裏提到的客戶端發送的、Nginx反向代理服務器接收到的請求數量，就是咱們說的負載量。

請求數量按照必定的規則進行分發到不一樣的服務器處理的規則，就是一種均衡規則。

因此~將服務器接收到的請求按照規則分發的過程，稱爲負載均衡。

負載均衡在實際項目操做過程當中，有硬件負載均衡和軟件負載均衡兩種，硬件負載均衡也稱爲硬負載，如F5負載均衡，相對造價昂貴成本較高，可是數據的穩定性安全性等等有很是好的保障，如中國移動中國聯通這樣的公司纔會選擇硬負載進行操做；更多的公司考慮到成本緣由，會選擇使用軟件負載均衡，軟件負載均衡是利用現有的技術結合主機硬件實現的一種消息隊列分發機制。

 

Nginx支持的負載均衡調度算法方式以下：

1）weight輪詢(默認，經常使用)：接收到的請求按照權重分配到不一樣的後端服務器，即便在使用過程當中，某一臺後端服務器宕機，Nginx會自動將該服務器剔除出隊列，請求受理狀況不會受到任何影響。 這種方式下，能夠給不一樣的後端服務器設置一個權重值(weight)，用於調整不一樣的服務器上請求的分配率；權重數據越大，被分配到請求的概率越大；該權重值，主要是針對實際工做環境中不一樣的後端服務器硬件配置進行調整的。

2）ip_hash（經常使用）：每一個請求按照發起客戶端的ip的hash結果進行匹配，這樣的算法下一個固定ip地址的客戶端總會訪問到同一個後端服務器，這也在必定程度上解決了集羣部署環境下session共享的問題。

3）fair：智能調整調度算法，動態的根據後端服務器的請求處理到響應的時間進行均衡分配，響應時間短處理效率高的服務器分配到請求的機率高，響應時間長處理效率低的服務器分配到的請求少；結合了前二者的優勢的一種調度算法。可是須要注意的是Nginx默認不支持fair算法，若是要使用這種調度算法，請安裝upstream_fair模塊。

4）url_hash：按照訪問的url的hash結果分配請求，每一個請求的url會指向後端固定的某個服務器，能夠在Nginx做爲靜態服務器的狀況下提升緩存效率。一樣要注意Nginx默認不支持這種調度算法，要使用的話須要安裝Nginx的hash軟件包。

五、Nginx對TCP、UDP、WebSocket的負載均衡支持

5.1 概述

準確地說，對於熟悉Nginx的使用者來說，上面的章節所介紹的內容都是針對Nginx最擅長的Http協議來說的，這也是Nginx最爲成功的應用場景。隨着Nginx的不斷升級和進化，開發者們對於Nginx能支持更爲底層的TCP、UDP以及HTML5裏纔出現的WebSocket協議頗爲期待，好在這一切已經成真！

Nginx從1.3版開始支持WebSocket協議的反向代理（負載均衡），從1.9.0版本開始支持TCP協議反向代理（負載均衡），從1.9.13開始支持UDP協議反向代理（負載均衡）。

從原理上說，Nginx對於UDP或TCP的反向代理（負載均衡）是一致的，而WebSocket協議實際是就是TCP協議的應用層協議，所以本節咱們將介紹Nginx對TCP協議反向代理（負載均衡）的支持。

Nginx對於經典的HTTP協議，也就是咱們一般所說的「七層負載均衡」，它實際上工做在第七層「應用層」。而對於更爲底層的TCP協議來講，負載均衡就是咱們一般所說的「四層負載均衡」，工做在「網絡層」和「傳輸層」。例如，LVS（Linux Virtual Server，Linux虛擬服務）和F5（一種硬件負載均衡設備），也是屬於「四層負載均衡」。

 

5.2 TCP負載均衡的執行原理

當Nginx從監聽端口收到一個新的客戶端連接時，馬上執行路由調度算法，得到指定須要鏈接的服務IP，而後建立一個新的上游鏈接，鏈接到指定服務器。

 

TCP負載均衡支持Nginx原有的調度算法，包括Round Robin（默認，輪詢調度），哈希（選擇一致）等。同時，調度信息數據也會和健壯性檢測模塊一塊兒協做，爲每一個鏈接選擇適當的目標上游服務器。若是使用Hash負載均衡的調度方法，你可使用$remote_addr（客戶端IP）來達成簡單持久化會話（同一個客戶端IP的鏈接，老是落到同一個服務server上）。

和其餘upstream模塊同樣，TCP的stream模塊也支持自定義負載均和的轉發權重（配置「weight=2」），還有backup和down的參數，用於踢掉失效的上游服務器。max_conns參數能夠限制一臺服務器的TCP鏈接數量，根據服務器的容量來設置恰當的配置數值，尤爲在高併發的場景下，能夠達到過載保護的目的。

Nginx監控客戶端鏈接和上游鏈接，一旦接收到數據，則Nginx會馬上讀取而且推送到上游鏈接，不會作TCP鏈接內的數據檢測。Nginx維護一分內存緩衝區，用於客戶端和上游數據的寫入。若是客戶端或者服務端傳輸了量很大的數據，緩衝區會適當增長內存的大小。

 

當Nginx收到任意一方的關閉鏈接通知，或者TCP鏈接被閒置超過了proxy_timeout配置的時間，鏈接將會被關閉。對於TCP長鏈接，咱們更應該選擇適當的proxy_timeout的時間，同時，關注監聽socke的so_keepalive參數，防止過早地斷開鏈接。

 

5.3 服務健壯性監控

TCP負載均衡模塊支持內置健壯性檢測，一臺上游服務器若是拒絕TCP鏈接超過proxy_connect_timeout配置的時間，將會被認爲已經失效。在這種狀況下，Nginx馬上嘗試鏈接upstream組內的另外一臺正常的服務器。鏈接失敗信息將會記錄到Nginx的錯誤日誌中。

 

若是一臺服務器，反覆失敗（超過了max_fails或者fail_timeout配置的參數），Nginx也會踢掉這臺服務器。服務器被踢掉60秒後，Nginx會偶爾嘗試重連它，檢測它是否恢復正常。若是服務器恢復正常，Nginx將它加回到upstream組內，緩慢加大鏈接請求的比例。

之所「緩慢加大」，由於一般一個服務都有「熱點數據」，也就是說，80%以上甚至更多的請求，實際都會被阻擋在「熱點數據緩存」中，真正執行處理的請求只有不多的一部分。在機器剛剛啓動的時候，「熱點數據緩存」實際上尚未創建，這個時候爆發性地轉發大量請求過來，極可能致使機器沒法「承受」而再次掛掉。以mysql爲例子，咱們的mysql查詢，一般95%以上都是落在了內存cache中，真正執行查詢的並很少。

其實，不管是單臺機器或者一個集羣，在高併發請求場景下，重啓或者切換，都存在這個風險。

解決的途徑主要是兩種：

1）請求逐步增長，從少到多，逐步積累熱點數據，最終達到正常服務狀態；

2）提早準備好「經常使用」的數據，主動對服務作「預熱」，預熱完成以後，再開放服務器的訪問。

TCP負載均衡原理上和LVS等是一致的，工做在更爲底層，性能會高於原來HTTP負載均衡很多。可是，不會比LVS更爲出色，LVS被置於內核模塊，而Nginx工做在用戶態，並且，Nginx相對比較重。

六、Nginx可否實現IM的負載均衡？

6.1 概述

從上一節內容來看，Nginx是能夠實現TCP、UDP、WebSocket協議的反向代碼（負載均衡）的，既然如此，那麼基於TCP、UDP或者WebSocket協議的IM聊天系統來講，是否能經過Nginx直接實現IM的負載均衡呢？

要回答這個問題，咱們首先來不一樣的長鏈接場景下，具體的數據走向狀況。

爲了方便敘述，如下基於TCP、UDP或者WebSocket協議實現的socket長鏈接，咱們簡稱爲socket長鏈接。

6.2 Nginx所支持的長鏈接反向代理數據走向能力

對於利於Nginx實現的socket長鏈接，數據走向以下圖所示：

 

如上圖，即：

1）客戶端經過Nginx反向代理到一臺socket長鏈接服務器；

2）客戶端能夠與創建鏈接的socket長鏈接服務器進行雙向通訊（即客戶端->socket長鏈接服務器、和socket長鏈接服務器->客戶端兩個方向）。

簡而言之，Nginx能實現的長鏈接數據走向能力爲：

1）Client to Server方向（簡稱c2s）：即客戶端向長鏈接服務端發送數據的能力；

2）Server to Client方向（簡稱s2c）：即長鏈接服務端向客戶端發送數據的能力。

6.3 IM聊天軟件須要的長鏈接數據走向能力

對於IM聊天應用來講，必須具有的數據走向能力爲：

1）Client to Server方向（簡稱c2s）：即客戶端向長鏈接服務端發送數據的能力；

2）Server to Client方向（簡稱s2c）：即長鏈接服務端向客戶端發送數據的能力；

3）Client to Client方向（簡稱c2c）：即客戶端向客戶端發送數據的能力。

IM聊天應用中的3種數據走向，對應的典型功能邏輯場景：

1）Client to Server方向（簡稱c2s）：一般用於客戶端向IM長鏈接服務端發起指令，好比：發起加好友請求、發送一條陌生人聊天消息、發送一條羣聊消息等；

2）Server to Client方向（簡稱s2c）：一般用於服務端主動向客戶端推送指令，好比：向客戶端轉達加好友請求、轉發陌生人聊天消息、擴散寫式的發送羣聊消息（給全部羣成員）、系統通知等；

3）Client to Client方向（簡稱c2c）：即客戶端向客戶端發送數據的能力，好比：一條正常的好友聊天消息就是由客戶端A發送給客戶端B（固然這不必定是P2P技術實現）。

6.4 結論

顯然，如上節所講，Nginx所實現的TCP、UDP或者WebSocket協議的反向代理（負載均衡），只能實現c2s、s2c兩種數據走向，而IM聊天應用中是必須須要c2s、s2c、c2c 共3種消息走向。對於c2c這種數據走向，顯然是IM特有的場景需求，要讓Nginx這種通用解決方案來提供，就有點牽強了。

咱們能夠得出結論：咱們是沒法經過Nginx直接實現IM的負載均衡的。

換句話講，若是真能經過Nginx直接實現IM的負載均衡，那IM的服務端在處理高併發、高吞吐時，就能夠像Http協議同樣安逸啦！

6.5 例外

不過，對於即時通信網所關注的另外一技術範疇——消息推送系統（或相似系統），是徹底能夠經過Nginx直接實現消息推送的負載均衡的，由於剛好消息推送系統也只須要c2s、s2c兩種數據走向，並不須要c2c這種橫向的數據交互。

附錄：有關IM架構設計的文章

《淺談IM系統的架構設計》
《簡述移動端IM開發的那些坑：架構設計、通訊協議和客戶端》
《一套海量在線用戶的移動端IM架構設計實踐分享(含詳細圖文)》
《一套原創分佈式即時通信(IM)系統理論架構方案》
《從零到卓越：京東客服即時通信系統的技術架構演進歷程》
《蘑菇街即時通信/IM服務器開發之架構選擇》
《騰訊QQ1.4億在線用戶的技術挑戰和架構演進之路PPT》
《微信後臺基於時間序的海量數據冷熱分級架構設計實踐》
《微信技術總監談架構：微信之道——大道至簡(演講全文)》
《如何解讀《微信技術總監談架構：微信之道——大道至簡》》
《快速裂變：見證微信強大後臺架構從0到1的演進歷程（一）》
《17年的實踐：騰訊海量產品的技術方法論》
《移動端IM中大規模羣消息的推送如何保證效率、實時性？》
《現代IM系統中聊天消息的同步和存儲方案探討》
《IM開發基礎知識補課(二)：如何設計大量圖片文件的服務端存儲架構？》
《IM開發基礎知識補課(三)：快速理解服務端數據庫讀寫分離原理及實踐建議》
《IM開發基礎知識補課(四)：正確理解HTTP短鏈接中的Cookie、Session和Token》
《WhatsApp技術實踐分享：32人工程團隊創造的技術神話》
《微信朋友圈千億訪問量背後的技術挑戰和實踐總結》
《王者榮耀2億用戶量的背後：產品定位、技術架構、網絡方案等》
《IM系統的MQ消息中間件選型：Kafka仍是RabbitMQ？》
《騰訊資深架構師乾貨總結：一文讀懂大型分佈式系統設計的方方面面》
《以微博類應用場景爲例，總結海量社交系統的架構設計步驟》
《快速理解高性能HTTP服務端的負載均衡技術原理》
《子彈短信光鮮的背後：網易雲信首席架構師分享億級IM平臺的技術實踐》
《知乎技術分享：從單機到2000萬QPS併發的Redis高性能緩存實踐之路》
《IM開發基礎知識補課(五)：通俗易懂，正確理解並用好MQ消息隊列》
《微信技術分享：微信的海量IM聊天消息序列號生成實踐（算法原理篇）》
《微信技術分享：微信的海量IM聊天消息序列號生成實踐（容災方案篇）》
《新手入門：零基礎理解大型分佈式架構的演進歷史、技術原理、最佳實踐》
《一套高可用、易伸縮、高併發的IM羣聊、單聊架構方案設計實踐》
《阿里技術分享：深度揭祕阿里數據庫技術方案的10年變遷史》
《阿里技術分享：阿里自研金融級數據庫OceanBase的艱辛成長之路》
《社交軟件紅包技術解密(一)：全面解密QQ紅包技術方案——架構、技術實現等》
《社交軟件紅包技術解密(二)：解密微信搖一搖紅包從0到1的技術演進》
《社交軟件紅包技術解密(三)：微信搖一搖紅包雨背後的技術細節》
《社交軟件紅包技術解密(四)：微信紅包系統是如何應對高併發的》
《社交軟件紅包技術解密(五)：微信紅包系統是如何實現高可用性的》
《社交軟件紅包技術解密(六)：微信紅包系統的存儲層架構演進實踐》
《社交軟件紅包技術解密(七)：支付寶紅包的海量高併發技術實踐》
《社交軟件紅包技術解密(八)：全面解密微博紅包技術方案》
《社交軟件紅包技術解密(九)：談談手Q紅包的功能邏輯、容災、運維、架構等》
《即時通信新手入門：一文讀懂什麼是Nginx？它可否實現IM的負載均衡？》
>> 更多同類文章 ……

（本文同步發佈於：http://www.52im.net/thread-2600-1-1.html）

相關文章
相關標籤/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公眾號
   歡迎關注本站公眾號,獲取更多信息
聯繫我們 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程