本文引用了“薔薇Nina”的“Nginx 相關(guān)介紹(Nginx是什么?能干嘛?)”一文部分內(nèi)容，下文有修訂和改動(dòng)。

1、引言

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

如此深入人心的Nginx，很多人也想當(dāng)然的認(rèn)為，在IM或消息推送等場景下是否也能使用Nginx來解決負(fù)載均衡問題？

另外，即時(shí)通訊網(wǎng)的論壇和QQ群里也經(jīng)常有人問起，Nginx是否能支持TCP、UDP、WebSocket的負(fù)載均衡？

帶著上面的疑問，我們來開始本文的學(xué)習(xí)吧！

技術(shù)交流：

2、知識準(zhǔn)備

《TCP/IP詳解 - 第11章·UDP：用戶數(shù)據(jù)報(bào)協(xié)議》

《TCP/IP詳解 - 第17章·TCP：傳輸控制協(xié)議》

《TCP/IP詳解 - 第18章·TCP連接的建立與終止》

《TCP/IP詳解 - 第21章·TCP的超時(shí)與重傳》

《通俗易懂-深入理解TCP協(xié)議（上）：理論基礎(chǔ)》

《網(wǎng)絡(luò)編程懶人入門(三)：快速理解TCP協(xié)議一篇就夠》

《新手快速入門：WebSocket簡明教程》

《WebSocket詳解（一）：初步認(rèn)識WebSocket技術(shù)》

《快速理解高性能HTTP服務(wù)端的負(fù)載均衡技術(shù)原理》

《騰訊資深架構(gòu)師干貨總結(jié)：一文讀懂大型分布式系統(tǒng)設(shè)計(jì)的方方面面》

《一篇讀懂分布式架構(gòu)下的負(fù)載均衡技術(shù)：分類、原理、算法、常見方案等》

《新手入門：零基礎(chǔ)理解大型分布式架構(gòu)的演進(jìn)歷史、技術(shù)原理、最佳實(shí)踐》

《通俗易懂：基于集群的移動(dòng)端IM接入層負(fù)載均衡方案分享》

3、Nginx的產(chǎn)生

沒有聽過Nginx？那么一定聽過它的"同行"Apache吧！Nginx同Apache一樣都是一種WEB服務(wù)器?；赗EST架構(gòu)風(fēng)格，以統(tǒng)一資源描述符(Uniform Resources Identifier)URI或者統(tǒng)一資源定位符(Uniform Resources Locator)URL作為溝通依據(jù)，通過HTTP協(xié)議提供各種網(wǎng)絡(luò)服務(wù)。

然而，這些服務(wù)器在設(shè)計(jì)之初受到當(dāng)時(shí)環(huán)境的局限，例如當(dāng)時(shí)的用戶規(guī)模，網(wǎng)絡(luò)帶寬，產(chǎn)品特點(diǎn)等局限并且各自的定位和發(fā)展都不盡相同。這也使得各個(gè)WEB服務(wù)器有著各自鮮明的特點(diǎn)。

Apache的發(fā)展時(shí)期很長，而且是毫無爭議的世界第一大服務(wù)器。它有著很多優(yōu)點(diǎn)：穩(wěn)定、開源、跨平臺等等。它出現(xiàn)的時(shí)間太長了，它興起的年代，互聯(lián)網(wǎng)產(chǎn)業(yè)遠(yuǎn)遠(yuǎn)比不上現(xiàn)在。所以它被設(shè)計(jì)為一個(gè)重量級的。它不支持高并發(fā)的服務(wù)器。在Apache上運(yùn)行數(shù)以萬計(jì)的并發(fā)訪問，會導(dǎo)致服務(wù)器消耗大量內(nèi)存。操作系統(tǒng)對其進(jìn)行進(jìn)程或線程間的切換也消耗了大量的CPU資源，導(dǎo)致HTTP請求的平均響應(yīng)速度降低。

這些都決定了Apache不可能成為高性能WEB服務(wù)器，輕量級高并發(fā)服務(wù)器Nginx就應(yīng)運(yùn)而生了。

俄羅斯的工程師Igor Sysoev，他在為Rambler Media工作期間，使用C語言開發(fā)了Nginx。Nginx作為WEB服務(wù)器一直為Rambler Media提供出色而又穩(wěn)定的服務(wù)。

▲ Igor Sysoev，Nginx的創(chuàng)始人

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

由于以下原因：

• 1）Nginx使用基于事件驅(qū)動(dòng)架構(gòu)，使得其可以支持?jǐn)?shù)以百萬級別的TCP連接；
• 2）高度的模塊化和自由軟件許可證使得第三方模塊層出不窮（這是個(gè)開源的時(shí)代啊~）；
• 3）Nginx是一個(gè)跨平臺服務(wù)器，可以運(yùn)行在Linux，Windows，F(xiàn)reeBSD，Solaris，AIX，Mac OS等操作系統(tǒng)上；
• 4）這些優(yōu)秀的設(shè)計(jì)帶來的是極大的穩(wěn)定性。

所以，Nginx火了！

4、Nginx最常見的用途、用法、使用場景

4.1 概述

簡而言之，Nginx是：

• 1）自由的、開源的、高性能的HTTP服務(wù)器和反向代理服務(wù)器；
• 2）也是一個(gè)IMAP、POP3、SMTP代理服務(wù)器；
• 3）可以作為一個(gè)HTTP服務(wù)器進(jìn)行網(wǎng)站的發(fā)布處理；
• 4）可以作為反向代理進(jìn)行負(fù)載均衡的實(shí)現(xiàn)。

4.2 什么是代理？

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

此時(shí)就涉及到兩個(gè)角色，一個(gè)是被代理角色，一個(gè)是目標(biāo)角色，被代理角色通過這個(gè)代理訪問目標(biāo)角色完成一些任務(wù)的過程稱為代理操作過程；如同生活中的專賣店~客人到adidas專賣店買了一雙鞋，這個(gè)專賣店就是代理，被代理角色就是adidas廠家，目標(biāo)角色就是用戶。

4.3 什么是正向代理？

說反向代理之前，我們先看看正向代理，正向代理也是大家最常接觸的到的代理模式，我們會從兩個(gè)方面來說關(guān)于正向代理的處理模式，分別從軟件方面和生活方面來解釋一下什么叫正向代理。

在如今的網(wǎng)絡(luò)環(huán)境下，我們?nèi)绻捎诩夹g(shù)需要要去訪問國外的某些網(wǎng)站，此時(shí)你會發(fā)現(xiàn)位于國外的某網(wǎng)站我們通過瀏覽器是沒有辦法訪問的，此時(shí)大家可能都會用一個(gè)操作FQ進(jìn)行訪問，F(xiàn)Q的方式主要是找到一個(gè)可以訪問國外網(wǎng)站的代理服務(wù)器，我們將請求發(fā)送給代理服務(wù)器，代理服務(wù)器去訪問國外的網(wǎng)站，然后將訪問到的數(shù)據(jù)傳遞給我們！

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

• 1）正向代理最大的特點(diǎn)是客戶端非常明確要訪問的服務(wù)器地址；
• 2）服務(wù)器只清楚請求來自哪個(gè)代理服務(wù)器，而不清楚來自哪個(gè)具體的客戶端；
• 3）正向代理模式屏蔽或者隱藏了真實(shí)客戶端信息。

來看個(gè)示意圖（我把客戶端和正向代理框在一塊，同屬于一個(gè)環(huán)境，后面我有介紹）：

客戶端必須設(shè)置正向代理服務(wù)器，當(dāng)然前提是要知道正向代理服務(wù)器的IP地址，還有代理程序的端口。

如下圖所示：

總結(jié)來說：正向代理，"它代理的是客戶端，代客戶端發(fā)出請求"，是一個(gè)位于客戶端和原始服務(wù)器(origin server)之間的服務(wù)器，為了從原始服務(wù)器取得內(nèi)容，客戶端向代理發(fā)送一個(gè)請求并指定目標(biāo)(原始服務(wù)器)，然后代理向原始服務(wù)器轉(zhuǎn)交請求并將獲得的內(nèi)容返回給客戶端?？蛻舳吮仨氁M(jìn)行一些特別的設(shè)置才能使用正向代理。

正向代理的用途：

• 1）訪問原來無法訪問的資源，如Google；
• 2） 可以做緩存，加速訪問資源；
• 3）對客戶端訪問授權(quán)，上網(wǎng)進(jìn)行認(rèn)證；
• 4）代理可以記錄用戶訪問記錄（上網(wǎng)行為管理），對外隱藏用戶信息。

4.4 什么是反向代理？

明白了什么是正向代理，我們繼續(xù)看關(guān)于反向代理的處理方式。

舉例如我大天朝的某寶網(wǎng)站，每天同時(shí)連接到網(wǎng)站的訪問人數(shù)已經(jīng)爆表，單個(gè)服務(wù)器遠(yuǎn)遠(yuǎn)不能滿足人民日益增長的購買欲望了，此時(shí)就出現(xiàn)了一個(gè)大家耳熟能詳?shù)拿~：分布式部署。

所謂分布式部署，也就是通過部署多臺服務(wù)器來解決訪問人數(shù)限制的問題。某寶網(wǎng)站中大部分功能也是直接使用Nginx進(jìn)行反向代理實(shí)現(xiàn)的，并且通過封裝Nginx和其他的組件之后起了個(gè)高大上的名字：Tengine，有興趣的童鞋可以訪問Tengine的官網(wǎng)查看具體的信息：http://tengine.taobao.org/。

那么反向代理具體是通過什么樣的方式實(shí)現(xiàn)的分布式的集群操作呢，我們先看一個(gè)示意圖（我把服務(wù)器和反向代理框在一塊，同屬于一個(gè)環(huán)境，后面我有介紹），如下圖所示。

通過上述的圖解大家就可以看清楚了：多個(gè)客戶端給服務(wù)器發(fā)送的請求，Nginx服務(wù)器接收到之后，按照一定的規(guī)則分發(fā)給了后端的業(yè)務(wù)處理服務(wù)器進(jìn)行處理了。此時(shí)~請求的來源也就是客戶端是明確的，但是請求具體由哪臺服務(wù)器處理的并不明確了，Nginx扮演的就是一個(gè)反向代理角色。

客戶端是無感知代理的存在的，反向代理對外都是透明的，訪問者并不知道自己訪問的是一個(gè)代理。因?yàn)榭蛻舳瞬恍枰魏闻渲镁涂梢栽L問。

反向代理，"它代理的是服務(wù)端，代服務(wù)端接收請求"，主要用于服務(wù)器集群分布式部署的情況下，反向代理隱藏了服務(wù)器的信息。

反向代理的作用：

• 1）保證內(nèi)網(wǎng)的安全，通常將反向代理作為公網(wǎng)訪問地址，Web服務(wù)器是內(nèi)網(wǎng)；
• 2）負(fù)載均衡，通過反向代理服務(wù)器來優(yōu)化網(wǎng)站的負(fù)載。

典型的項(xiàng)目場景：

通常情況下，我們在實(shí)際項(xiàng)目操作時(shí)，正向代理和反向代理很有可能會存在在一個(gè)應(yīng)用場景中，正向代理代理客戶端的請求去訪問目標(biāo)服務(wù)器，目標(biāo)服務(wù)器是一個(gè)反向單利服務(wù)器，反向代理了多臺真實(shí)的業(yè)務(wù)處理服務(wù)器。

具體的拓?fù)鋱D如下：

4.5 正向代理和反向代理的區(qū)別

截了一張圖來說明正向代理和反向代理二者之間的區(qū)別，如下圖。

圖解如下：

• 1）在正向代理中，Proxy和Client同屬于一個(gè)LAN（圖中方框內(nèi)），隱藏了客戶端信息；
• 2）在反向代理中，Proxy和Server同屬于一個(gè)LAN（圖中方框內(nèi)），隱藏了服務(wù)端信息。

實(shí)際上，Proxy在兩種代理中做的事情都是替服務(wù)器代為收發(fā)請求和響應(yīng)，不過從結(jié)構(gòu)上看正好左右互換了一下，所以把后出現(xiàn)的那種代理方式稱為反向代理了。

4.6 Nginx的負(fù)載均衡技術(shù)

我們已經(jīng)明確了所謂代理服務(wù)器的概念，那么接下來，Nginx扮演了反向代理服務(wù)器的角色，它是以依據(jù)什么樣的規(guī)則進(jìn)行請求分發(fā)的呢？不用的項(xiàng)目應(yīng)用場景，分發(fā)的規(guī)則是否可以控制呢？

這里提到的客戶端發(fā)送的、Nginx反向代理服務(wù)器接收到的請求數(shù)量，就是我們說的負(fù)載量。

請求數(shù)量按照一定的規(guī)則進(jìn)行分發(fā)到不同的服務(wù)器處理的規(guī)則，就是一種均衡規(guī)則。

所以~將服務(wù)器接收到的請求按照規(guī)則分發(fā)的過程，稱為負(fù)載均衡。

負(fù)載均衡在實(shí)際項(xiàng)目操作過程中，有硬件負(fù)載均衡和軟件負(fù)載均衡兩種，硬件負(fù)載均衡也稱為硬負(fù)載，如F5負(fù)載均衡，相對造價(jià)昂貴成本較高，但是數(shù)據(jù)的穩(wěn)定性安全性等等有非常好的保障，如中國移動(dòng)中國聯(lián)通這樣的公司才會選擇硬負(fù)載進(jìn)行操作；更多的公司考慮到成本原因，會選擇使用軟件負(fù)載均衡，軟件負(fù)載均衡是利用現(xiàn)有的技術(shù)結(jié)合主機(jī)硬件實(shí)現(xiàn)的一種消息隊(duì)列分發(fā)機(jī)制。

Nginx支持的負(fù)載均衡調(diào)度算法方式如下：

• 1）weight輪詢(默認(rèn)，常用)：接收到的請求按照權(quán)重分配到不同的后端服務(wù)器，即使在使用過程中，某一臺后端服務(wù)器宕機(jī)，Nginx會自動(dòng)將該服務(wù)器剔除出隊(duì)列，請求受理情況不會受到任何影響。 這種方式下，可以給不同的后端服務(wù)器設(shè)置一個(gè)權(quán)重值(weight)，用于調(diào)整不同的服務(wù)器上請求的分配率；權(quán)重?cái)?shù)據(jù)越大，被分配到請求的幾率越大；該權(quán)重值，主要是針對實(shí)際工作環(huán)境中不同的后端服務(wù)器硬件配置進(jìn)行調(diào)整的。
• 2）ip_hash（常用）：每個(gè)請求按照發(fā)起客戶端的ip的hash結(jié)果進(jìn)行匹配，這樣的算法下一個(gè)固定ip地址的客戶端總會訪問到同一個(gè)后端服務(wù)器，這也在一定程度上解決了集群部署環(huán)境下session共享的問題。
• 3）fair：智能調(diào)整調(diào)度算法，動(dòng)態(tài)的根據(jù)后端服務(wù)器的請求處理到響應(yīng)的時(shí)間進(jìn)行均衡分配，響應(yīng)時(shí)間短處理效率高的服務(wù)器分配到請求的概率高，響應(yīng)時(shí)間長處理效率低的服務(wù)器分配到的請求少；結(jié)合了前兩者的優(yōu)點(diǎn)的一種調(diào)度算法。但是需要注意的是Nginx默認(rèn)不支持fair算法，如果要使用這種調(diào)度算法，請安裝upstream_fair模塊。
• 4）url_hash：按照訪問的url的hash結(jié)果分配請求，每個(gè)請求的url會指向后端固定的某個(gè)服務(wù)器，可以在Nginx作為靜態(tài)服務(wù)器的情況下提高緩存效率。同樣要注意Nginx默認(rèn)不支持這種調(diào)度算法，要使用的話需要安裝Nginx的hash軟件包。

5、Nginx對TCP、UDP、WebSocket的負(fù)載均衡支持

5.1 概述

準(zhǔn)確地說，對于熟悉Nginx的使用者來講，上面的章節(jié)所介紹的內(nèi)容都是針對Nginx最擅長的Http協(xié)議來講的，這也是Nginx最為成功的應(yīng)用場景。隨著Nginx的不斷升級和進(jìn)化，開發(fā)者們對于Nginx能支持更為底層的TCP、UDP以及HTML5里才出現(xiàn)的WebSocket協(xié)議頗為期待，好在這一切已經(jīng)成真！

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

從原理上說，Nginx對于UDP或TCP的反向代理（負(fù)載均衡）是一致的，而WebSocket協(xié)議實(shí)際是就是TCP協(xié)議的應(yīng)用層協(xié)議，因此本節(jié)我們將介紹Nginx對TCP協(xié)議反向代理（負(fù)載均衡）的支持。

Nginx對于經(jīng)典的HTTP協(xié)議，也就是我們通常所說的“七層負(fù)載均衡”，它實(shí)際上工作在第七層“應(yīng)用層”。而對于更為底層的TCP協(xié)議來說，負(fù)載均衡就是我們通常所說的“四層負(fù)載均衡”，工作在“網(wǎng)絡(luò)層”和“傳輸層”。例如，LVS（Linux Virtual Server，Linux虛擬服務(wù)）和F5（一種硬件負(fù)載均衡設(shè)備），也是屬于“四層負(fù)載均衡”。

5.2 TCP負(fù)載均衡的執(zhí)行原理

當(dāng)Nginx從監(jiān)聽端口收到一個(gè)新的客戶端鏈接時(shí)，立刻執(zhí)行路由調(diào)度算法，獲得指定需要連接的服務(wù)IP，然后創(chuàng)建一個(gè)新的上游連接，連接到指定服務(wù)器。

TCP負(fù)載均衡支持Nginx原有的調(diào)度算法，包括Round Robin（默認(rèn)，輪詢調(diào)度），哈希（選擇一致）等。同時(shí)，調(diào)度信息數(shù)據(jù)也會和健壯性檢測模塊一起協(xié)作，為每個(gè)連接選擇適當(dāng)?shù)哪繕?biāo)上游服務(wù)器。如果使用Hash負(fù)載均衡的調(diào)度方法，你可以使用$remote_addr（客戶端IP）來達(dá)成簡單持久化會話（同一個(gè)客戶端IP的連接，總是落到同一個(gè)服務(wù)server上）。

和其他upstream模塊一樣，TCP的stream模塊也支持自定義負(fù)載均和的轉(zhuǎn)發(fā)權(quán)重（配置“weight=2”），還有backup和down的參數(shù)，用于踢掉失效的上游服務(wù)器。max_conns參數(shù)可以限制一臺服務(wù)器的TCP連接數(shù)量，根據(jù)服務(wù)器的容量來設(shè)置恰當(dāng)?shù)呐渲脭?shù)值，尤其在高并發(fā)的場景下，可以達(dá)到過載保護(hù)的目的。

Nginx監(jiān)控客戶端連接和上游連接，一旦接收到數(shù)據(jù)，則Nginx會立刻讀取并且推送到上游連接，不會做TCP連接內(nèi)的數(shù)據(jù)檢測。Nginx維護(hù)一份內(nèi)存緩沖區(qū)，用于客戶端和上游數(shù)據(jù)的寫入。如果客戶端或者服務(wù)端傳輸了量很大的數(shù)據(jù)，緩沖區(qū)會適當(dāng)增加內(nèi)存的大小。

當(dāng)Nginx收到任意一方的關(guān)閉連接通知，或者TCP連接被閑置超過了proxy_timeout配置的時(shí)間，連接將會被關(guān)閉。對于TCP長連接，我們更應(yīng)該選擇適當(dāng)?shù)膒roxy_timeout的時(shí)間，同時(shí)，關(guān)注監(jiān)聽socke的so_keepalive參數(shù)，防止過早地?cái)嚅_連接。

5.3 服務(wù)健壯性監(jiān)控

TCP負(fù)載均衡模塊支持內(nèi)置健壯性檢測，一臺上游服務(wù)器如果拒絕TCP連接超過proxy_connect_timeout配置的時(shí)間，將會被認(rèn)為已經(jīng)失效。在這種情況下，Nginx立刻嘗試連接upstream組內(nèi)的另一臺正常的服務(wù)器。連接失敗信息將會記錄到Nginx的錯(cuò)誤日志中。

如果一臺服務(wù)器，反復(fù)失?。ǔ^了max_fails或者fail_timeout配置的參數(shù)），Nginx也會踢掉這臺服務(wù)器。服務(wù)器被踢掉60秒后，Nginx會偶爾嘗試重連它，檢測它是否恢復(fù)正常。如果服務(wù)器恢復(fù)正常，Nginx將它加回到upstream組內(nèi)，緩慢加大連接請求的比例。

之所“緩慢加大”，因?yàn)橥ǔＲ粋€(gè)服務(wù)都有“熱點(diǎn)數(shù)據(jù)”，也就是說，80%以上甚至更多的請求，實(shí)際都會被阻擋在“熱點(diǎn)數(shù)據(jù)緩存”中，真正執(zhí)行處理的請求只有很少的一部分。在機(jī)器剛剛啟動(dòng)的時(shí)候，“熱點(diǎn)數(shù)據(jù)緩存”實(shí)際上還沒有建立，這個(gè)時(shí)候爆發(fā)性地轉(zhuǎn)發(fā)大量請求過來，很可能導(dǎo)致機(jī)器無法“承受”而再次掛掉。以mysql為例子，我們的mysql查詢，通常95%以上都是落在了內(nèi)存cache中，真正執(zhí)行查詢的并不多。

其實(shí)，無論是單臺機(jī)器或者一個(gè)集群，在高并發(fā)請求場景下，重啟或者切換，都存在這個(gè)風(fēng)險(xiǎn)。

解決的途徑主要是兩種：

• 1）請求逐步增加，從少到多，逐步積累熱點(diǎn)數(shù)據(jù)，最終達(dá)到正常服務(wù)狀態(tài)；
• 2）提前準(zhǔn)備好“常用”的數(shù)據(jù)，主動(dòng)對服務(wù)做“預(yù)熱”，預(yù)熱完成之后，再開放服務(wù)器的訪問。

TCP負(fù)載均衡原理上和LVS等是一致的，工作在更為底層，性能會高于原來HTTP負(fù)載均衡不少。但是，不會比LVS更為出色，LVS被置于內(nèi)核模塊，而Nginx工作在用戶態(tài)，而且，Nginx相對比較重。

6、Nginx能否實(shí)現(xiàn)IM的負(fù)載均衡？

6.1 概述

從上一節(jié)內(nèi)容來看，Nginx是可以實(shí)現(xiàn)TCP、UDP、WebSocket協(xié)議的反向代碼（負(fù)載均衡）的，既然如此，那么基于TCP、UDP或者WebSocket協(xié)議的IM聊天系統(tǒng)來說，是否能通過Nginx直接實(shí)現(xiàn)IM的負(fù)載均衡呢？

要回答這個(gè)問題，我們首先來不同的長連接場景下，具體的數(shù)據(jù)走向情況。

為了方便敘述，以下基于TCP、UDP或者WebSocket協(xié)議實(shí)現(xiàn)的socket長連接，我們簡稱為socket長連接。

6.2 Nginx所支持的長連接反向代理數(shù)據(jù)走向能力

對于利于Nginx實(shí)現(xiàn)的socket長連接，數(shù)據(jù)走向如下圖所示：

如上圖，即：

• 1）客戶端通過Nginx反向代理到一臺socket長連接服務(wù)器；
• 2）客戶端可以與建立連接的socket長連接服務(wù)器進(jìn)行雙向通信（即客戶端->socket長連接服務(wù)器、和socket長連接服務(wù)器->客戶端兩個(gè)方向）。

簡而言之，Nginx能實(shí)現(xiàn)的長連接數(shù)據(jù)走向能力為：

• 1）Client to Server方向（簡稱c2s）：即客戶端向長連接服務(wù)端發(fā)送數(shù)據(jù)的能力；
• 2）Server to Client方向（簡稱s2c）：即長連接服務(wù)端向客戶端發(fā)送數(shù)據(jù)的能力。

6.3 IM聊天軟件需要的長連接數(shù)據(jù)走向能力

對于IM聊天應(yīng)用來說，必須具備的數(shù)據(jù)走向能力為：

• 1）Client to Server方向（簡稱c2s）：即客戶端向長連接服務(wù)端發(fā)送數(shù)據(jù)的能力；
• 2）Server to Client方向（簡稱s2c）：即長連接服務(wù)端向客戶端發(fā)送數(shù)據(jù)的能力；
• 3）Client to Client方向（簡稱c2c）：即客戶端向客戶端發(fā)送數(shù)據(jù)的能力。

IM聊天應(yīng)用中的3種數(shù)據(jù)走向，對應(yīng)的典型功能邏輯場景：

• 1）Client to Server方向（簡稱c2s）：通常用于客戶端向IM長連接服務(wù)端發(fā)起指令，比如：發(fā)起加好友請求、發(fā)送一條陌生人聊天消息、發(fā)送一條群聊消息等；
• 2）Server to Client方向（簡稱s2c）：通常用于服務(wù)端主動(dòng)向客戶端推送指令，比如：向客戶端轉(zhuǎn)達(dá)加好友請求、轉(zhuǎn)發(fā)陌生人聊天消息、擴(kuò)散寫式的發(fā)送群聊消息（給所有群成員）、系統(tǒng)通知等；
• 3）Client to Client方向（簡稱c2c）：即客戶端向客戶端發(fā)送數(shù)據(jù)的能力，比如：一條正常的好友聊天消息就是由客戶端A發(fā)送給客戶端B（當(dāng)然這不一定是P2P技術(shù)實(shí)現(xiàn)）。

6.4 結(jié)論

顯然，如上節(jié)所講，Nginx所實(shí)現(xiàn)的TCP、UDP或者WebSocket協(xié)議的反向代理（負(fù)載均衡），只能實(shí)現(xiàn)c2s、s2c兩種數(shù)據(jù)走向，而IM聊天應(yīng)用中是必須需要c2s、s2c、c2c 共3種消息走向。對于c2c這種數(shù)據(jù)走向，顯然是IM特有的場景需求，要讓Nginx這種通用解決方案來提供，就有點(diǎn)牽強(qiáng)了。

我們可以得出結(jié)論：我們是無法通過Nginx直接實(shí)現(xiàn)IM的負(fù)載均衡的。

換句話講，如果真能通過Nginx直接實(shí)現(xiàn)IM的負(fù)載均衡，那IM的服務(wù)端在處理高并發(fā)、高吞吐時(shí)，就可以像Http協(xié)議一樣安逸啦！

6.5 例外

不過，對于即時(shí)通訊網(wǎng)所關(guān)注的另一技術(shù)范疇——消息推送系統(tǒng)（或類似系統(tǒng)），是完全可以通過Nginx直接實(shí)現(xiàn)消息推送的負(fù)載均衡的，因?yàn)榍『孟⑼扑拖到y(tǒng)也只需要c2s、s2c兩種數(shù)據(jù)走向，并不需要c2c這種橫向的數(shù)據(jù)交互。

更多IM架構(gòu)設(shè)計(jì)的資料

《淺談IM系統(tǒng)的架構(gòu)設(shè)計(jì)》

《簡述移動(dòng)端IM開發(fā)的那些坑：架構(gòu)設(shè)計(jì)、通信協(xié)議和客戶端》

《一套海量在線用戶的移動(dòng)端IM架構(gòu)設(shè)計(jì)實(shí)踐分享(含詳細(xì)圖文)》

《一套原創(chuàng)分布式即時(shí)通訊(IM)系統(tǒng)理論架構(gòu)方案》

《從零到卓越：京東客服即時(shí)通訊系統(tǒng)的技術(shù)架構(gòu)演進(jìn)歷程》

《蘑菇街即時(shí)通訊/IM服務(wù)器開發(fā)之架構(gòu)選擇》

《騰訊QQ1.4億在線用戶的技術(shù)挑戰(zhàn)和架構(gòu)演進(jìn)之路PPT》

《微信后臺基于時(shí)間序的海量數(shù)據(jù)冷熱分級架構(gòu)設(shè)計(jì)實(shí)踐》

《微信技術(shù)總監(jiān)談架構(gòu)：微信之道——大道至簡(演講全文)》

《如何解讀《微信技術(shù)總監(jiān)談架構(gòu)：微信之道——大道至簡》》

《快速裂變：見證微信強(qiáng)大后臺架構(gòu)從0到1的演進(jìn)歷程（一）》

《17年的實(shí)踐：騰訊海量產(chǎn)品的技術(shù)方法論》

《移動(dòng)端IM中大規(guī)模群消息的推送如何保證效率、實(shí)時(shí)性？》

《現(xiàn)代IM系統(tǒng)中聊天消息的同步和存儲方案探討》

《WhatsApp技術(shù)實(shí)踐分享：32人工程團(tuán)隊(duì)創(chuàng)造的技術(shù)神話》

《微信朋友圈千億訪問量背后的技術(shù)挑戰(zhàn)和實(shí)踐總結(jié)》

《IM系統(tǒng)的MQ消息中間件選型：Kafka還是RabbitMQ？》

《子彈短信光鮮的背后：網(wǎng)易云信首席架構(gòu)師分享億級IM平臺的技術(shù)實(shí)踐》

《IM開發(fā)基礎(chǔ)知識補(bǔ)課(五)：通俗易懂，正確理解并用好MQ消息隊(duì)列》

《微信技術(shù)分享：微信的海量IM聊天消息序列號生成實(shí)踐（算法原理篇）》

《微信技術(shù)分享：微信的海量IM聊天消息序列號生成實(shí)踐（容災(zāi)方案篇）》

《一套高可用、易伸縮、高并發(fā)的IM群聊、單聊架構(gòu)方案設(shè)計(jì)實(shí)踐》

《社交軟件紅包技術(shù)解密(一)：全面解密QQ紅包技術(shù)方案——架構(gòu)、技術(shù)實(shí)現(xiàn)等》

《即時(shí)通訊新手入門：一文讀懂什么是Nginx？它能否實(shí)現(xiàn)IM的負(fù)載均衡？》

《即時(shí)通訊新手入門：快速理解RPC技術(shù)——基本概念、原理和用途》

《從游擊隊(duì)到正規(guī)軍(一)：馬蜂窩旅游網(wǎng)的IM系統(tǒng)架構(gòu)演進(jìn)之路》

《從游擊隊(duì)到正規(guī)軍(二)：馬蜂窩旅游網(wǎng)的IM客戶端架構(gòu)演進(jìn)和實(shí)踐總結(jié)》

《從游擊隊(duì)到正規(guī)軍(三)：基于Go的馬蜂窩旅游網(wǎng)分布式IM系統(tǒng)技術(shù)實(shí)踐》

《瓜子IM智能客服系統(tǒng)的數(shù)據(jù)架構(gòu)設(shè)計(jì)（整理自現(xiàn)場演講，有配套PPT）》

《阿里釘釘技術(shù)分享：企業(yè)級IM王者——釘釘在后端架構(gòu)上的過人之處》

《微信后臺基于時(shí)間序的新一代海量數(shù)據(jù)存儲架構(gòu)的設(shè)計(jì)實(shí)踐》

《IM開發(fā)基礎(chǔ)知識補(bǔ)課(九)：想開發(fā)IM集群？先搞懂什么是RPC！》

《IM開發(fā)基礎(chǔ)知識補(bǔ)課(十)：大型IM系統(tǒng)有多難？萬字長文，搞懂異地多活！》

《阿里技術(shù)分享：電商IM消息平臺，在群聊、直播場景下的技術(shù)實(shí)踐》

《一套億級用戶的IM架構(gòu)技術(shù)干貨(上篇)：整體架構(gòu)、服務(wù)拆分等》

《一套億級用戶的IM架構(gòu)技術(shù)干貨(下篇)：可靠性、有序性、弱網(wǎng)優(yōu)化等》

《從新手到專家：如何設(shè)計(jì)一套億級消息量的分布式IM系統(tǒng)》

《企業(yè)微信的IM架構(gòu)設(shè)計(jì)揭秘：消息模型、萬人群、已讀回執(zhí)、消息撤回等》

《融云技術(shù)分享：全面揭秘億級IM消息的可靠投遞機(jī)制》

《IM開發(fā)技術(shù)學(xué)習(xí)：揭秘微信朋友圈這種信息推流背后的系統(tǒng)設(shè)計(jì)》

《阿里IM技術(shù)分享(三)：閑魚億級IM消息系統(tǒng)的架構(gòu)演進(jìn)之路》

《基于實(shí)踐：一套百萬消息量小規(guī)模IM系統(tǒng)技術(shù)要點(diǎn)總結(jié)》

《跟著源碼學(xué)IM(十)：基于Netty，搭建高性能IM集群（含技術(shù)思路+源碼）》

《一套十萬級TPS的IM綜合消息系統(tǒng)的架構(gòu)實(shí)踐與思考》

《直播系統(tǒng)聊天技術(shù)(八)：vivo直播系統(tǒng)中IM消息模塊的架構(gòu)實(shí)踐》

《得物從0到1自研客服IM系統(tǒng)的技術(shù)實(shí)踐之路》

《海量用戶IM聊天室的架構(gòu)設(shè)計(jì)與實(shí)踐》

《企業(yè)微信針對百萬級組織架構(gòu)的客戶端性能優(yōu)化實(shí)踐》

《一套分布式IM即時(shí)通訊系統(tǒng)的技術(shù)選型和架構(gòu)設(shè)計(jì)》

《陌陌技術(shù)分享：陌陌IM在后端KV緩存架構(gòu)上的技術(shù)實(shí)踐》

《微信團(tuán)隊(duì)分享：微信后端海量數(shù)據(jù)查詢從1000ms降到100ms的技術(shù)實(shí)踐》

《微信團(tuán)隊(duì)分享：來看看微信十年前的IM消息收發(fā)架構(gòu)，你做到了嗎》

《攜程技術(shù)分享：億級流量的辦公I(xiàn)M及開放平臺技術(shù)實(shí)踐》

《百度公共IM系統(tǒng)的Andriod端IM SDK組件架構(gòu)設(shè)計(jì)與技術(shù)實(shí)現(xiàn)》

（本文已同步發(fā)布于：http://www.52im.net/thread-2600-1-1.html）