即时通讯新手入门：一文读懂什么是Nginx？它能否实现IM的负载均衡？

本文引用了“蔷薇Nina”的“Nginx 相关介绍(Nginx是什么?能干嘛?)”一文部分内容，感谢作者的无私分享。

1、引言

Nginx（及其衍生产品）是目前被大量使用的服务端反向代理和负载均衡方案，从某种意义上来讲，Nginx几乎是低成本、高负载Web服务端代名词。

如此深入人心的Nginx，很多人也想当然的认为，在IM或消息推送等场景下是否也能使用Nginx来解决负载均衡问题？

另外，即时通讯网的论坛和QQ群里也经常有人问起，Nginx是否能支持TCP、UDP、WebSocket的负载均衡？

带着上面的疑问，我们来开始本文的学习吧！

2、相关文章

• 《TCP/IP详解 - 第11章·UDP：用户数据报协议》
• 《TCP/IP详解 - 第17章·TCP：传输控制协议》
• 《TCP/IP详解 - 第18章·TCP连接的建立与终止》
• 《TCP/IP详解 - 第21章·TCP的超时与重传》
• 《通俗易懂-深入理解TCP协议（上）：理论基础》
• 《网络编程懒人入门(三)：快速理解TCP协议一篇就够》
• 《新手快速入门：WebSocket简明教程》
• 《WebSocket详解（一）：初步认识WebSocket技术》
• 《快速理解高性能HTTP服务端的负载均衡技术原理》
• 《腾讯资深架构师干货总结：一文读懂大型分布式系统设计的方方面面》
• 《一篇读懂分布式架构下的负载均衡技术：分类、原理、算法、常见方案等》
• 《新手入门：零基础理解大型分布式架构的演进历史、技术原理、最佳实践》
• 《通俗易懂：基于集群的移动端IM接入层负载均衡方案分享》
  

3、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火了！

4、Nginx最常见的用途、用法、使用场景

4.1概述

简而言之，Nginx是：

• 1）自由的、开源的、高性能的HTTP服务器和反向代理服务器；
• 2）也是一个IMAP、POP3、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.6Nginx的负载均衡技术

我们已经明确了所谓代理服务器的概念，那么接下来，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软件包。
  

5、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.2TCP负载均衡的执行原理

当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相对比较重。

6、Nginx能否实现IM的负载均衡？

6.1概述

从上一节内容来看，Nginx是可以实现TCP、UDP、WebSocket协议的反向代码（负载均衡）的，既然如此，那么基于TCP、UDP或者WebSocket协议的IM聊天系统来说，是否能通过Nginx直接实现IM的负载均衡呢？

要回答这个问题，我们首先来不同的长连接场景下，具体的数据走向情况。

为了方便叙述，以下基于TCP、UDP或者WebSocket协议实现的socket长连接，我们简称为socket长连接。

6.2Nginx所支持的长连接反向代理数据走向能力

对于利于Nginx实现的socket长连接，数据走向如下图所示：


如上图，即：

• 1）客户端通过Nginx反向代理到一台socket长连接服务器；
• 2）客户端可以与建立连接的socket长连接服务器进行双向通信（即客户端->socket长连接服务器、和socket长连接服务器->客户端两个方向）。
  

简而言之，Nginx能实现的长连接数据走向能力为：

• 1）Client to Server方向（简称c2s）：即客户端向长连接服务端发送数据的能力；
• 2）Server to Client方向（简称s2c）：即长连接服务端向客户端发送数据的能力。
  

6.3IM聊天软件需要的长连接数据走向能力

对于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红包的功能逻辑、容灾、运维、架构等》
《社交软件红包技术解密(十)：手Q客户端针对2020年春节红包的技术实践》
《即时通讯新手入门：一文读懂什么是Nginx？它能否实现IM的负载均衡？》
《即时通讯新手入门：快速理解RPC技术——基本概念、原理和用途》
《多维度对比5款主流分布式MQ消息队列，妈妈再也不担心我的技术选型了》
《从游击队到正规军(一)：马蜂窝旅游网的IM系统架构演进之路》
《从游击队到正规军(二)：马蜂窝旅游网的IM客户端架构演进和实践总结》
《IM开发基础知识补课(六)：数据库用NoSQL还是SQL？读这篇就够了！》
《瓜子IM智能客服系统的数据架构设计（整理自现场演讲，有配套PPT）》
《阿里钉钉技术分享：企业级IM王者——钉钉在后端架构上的过人之处》
《从游击队到正规军(三)：基于Go的马蜂窝旅游网分布式IM系统技术实践》
《微信后台基于时间序的新一代海量数据存储架构的设计实践》
《IM开发基础知识补课(九)：想开发IM集群？先搞懂什么是RPC！》
>> 更多同类文章 ……

引用：Gangan_Master 发表于 2022-06-01 17:18
或许思考下面这几个问题大家就知道Nginx能不能作为IM的负载均衡了：
1.谁负责跟client三次握手四次挥手， ...

专业

或许思考下面这几个问题大家就知道Nginx能不能作为IM的负载均衡了：
1.谁负责跟client三次握手四次挥手，是Nginx还是后面的RS
2.客户端的IP和端口在谁那里维护，怎么找到对应用户的连接信息
3.客户端新建连接的时候，Nginx与后面的RS是不是也会新建一条连接

引用：JackJiang 发表于 2019-06-10 11:18
c2c不是p2p。
c2c依然是走服务器中转
但如果要做多实例负载，当两个人登陆在不同的实例上时，两个服务 ...

我理解的C2C，是指有3步C2S ,S2S，S2C，关键，第2步，S2S，是指不通的C端可能分别被Nginx分配到不同的S服务端上去了

如同生活中的专卖店~客人到adidas专卖店买了一双鞋，这个专卖店就是代理，被代理角色就是adidas厂家，目标角色就是用户。这个用户是从哪来的，我怎么感觉目标角色是鞋呢

引用：ronaldo9107 发表于 2020-11-13 21:15
怎么没人回复

问题太多了，回答完要累死了

引用：yaohuan 发表于 2020-04-16 14:26
明白了。请假个问题，当前消息推送系统或者IM，接入几百万，上千万TCP长连接，负载均衡用LVS ...

怎么没人回复

引用：JackJiang 发表于 2020-04-16 10:14
你理解的很到位。

说白了，Nginx是为web而生，对于im这种业务来说，如果用nginx，也最多只能作为IM集 ...

明白了。请假个问题，当前消息推送系统或者IM，接入几百万，上千万TCP长连接，负载均衡用LVS或者像阿里云上的SLB，通常一台 自搭建的LVS  ECS机器 能够支持多少TCP连接？因为我看到说一个TCP连接对应一个文件描述符FD，linux上单进程 最大能打开 100多万个fd ？ 那么如果采用云主机 自己搭建一个LVS，后面反向代理 接上五台RS服务器，就算后面的RS  每台支撑100万，原则上五台 可以支撑500万TCP连接，但是由于linux 的单进程 最大能打开 fd数只是100多万 ？ 也就是后面接再多RS也没用了？现在的问题是，LVS能够支撑多少TCP长连接，是跟内存有关呢还是跟FD设置有关？linux下，FD到底能够设置多大？

引用：yaohuan 发表于 2020-04-16 09:54
我理解的反向代理，应该只是进行流量负载均衡，不包括路由寻址。C2S是因为C知道S的IP（由公网Nginx转发到后 ...

你理解的很到位。

说白了，Nginx是为web而生，对于im这种业务来说，如果用nginx，也最多只能作为IM集群里的前置LBS而已，起到的作用，跟它在Web中的地位相差太多。所以，正因为是这样，所以IM集群中多数时候LBS也会自已来写而很少考虑Nginx，因为与期鸡肋地用着Nginx，不如自已简单的写一个，还能深度匹配自已的业务，技术更可控，难度也并不大。必竟，im的集群技术难度并不在前置LBS这点事情上。

我理解的反向代理，应该只是进行流量负载均衡，不包括路由寻址。C2S是因为C知道S的IP（由公网Nginx转发到后端内网服务器的IP），建立了TCP长连接，该连接可以双向通信，这就让S能够找到该连接的C，因此能够进行S2C。S2C通常在C2S的前提下才能进行，因为C通常都在私网，S是不能首先得知其地点的。而C2C，我们通常认为C是在私网中，外网是不能够直达C的，两个不同网络的C2C通信只能通过S进行中转，同局域网网段的C2C可以进行P2P通信，大多数情况下要解决的是不同网络中的C2C通讯问题，所以大多数情况下是由业务层进行路由寻址的，Nginx不负责具体业务。我觉得只要Nginx能够支持TCP，应该就能进行IM负载均衡。不知道理解是否正确？

这个观点有问题，nginx负载到各个实例作为的是接入层，已经实现了socket长连接的负载，至于c2c就是上游业务的事情，服务端记录了某个用户登录到某个节点上，转发的时候只要rpc调用到msg发给目标节点接入层就ok了

引用：ym_im 发表于 2019-09-06 11:09
直接搭肯定是不行的。我在考虑开发nginx moudle,这个moudle能多个长连接连接其他服务器,然后nginx接收的客 ...

你有这个定制开发能力的话，那倒是可以

直接搭肯定是不行的。我在考虑开发nginx moudle,这个moudle能多个长连接连接其他服务器,然后nginx接收的客户端msg都通过这个连接转发大logic服务器,然后logic服务器也能转发消息到nginx，就实现了c2c，相当于接入网关

引用：fsliangzp 发表于 2019-06-25 14:07
所以题主提到的c2c这种场景下，也能研发自己维护了。
需要保存关联关系，客户端A链接服务端A、客户端B链接 ...

im集群就是这么麻烦，大厂会更复杂。不然，几百上千亿的市值，随便找找开源软件配置配置就能成，那赚钱就太容易了

所以题主提到的c2c这种场景下，也能研发自己维护了。
需要保存关联关系，客户端A链接服务端A、客户端B链接服务端B。
客户端A往客户端B发送信息的时候，服务端A就要去中间接找客户端B的服务端B机器出来。然后再广播事件通知服务端B，需要转发消息到客户端B

听着就觉得IM这块在实现方面挺有重量的...不知道大厂的解决方案是怎么样的，这样解决靠谱不。哈哈

引用：摸鱼中 发表于 2019-06-10 11:06
c2c 需要服务端吗

c2c不是p2p。
c2c依然是走服务器中转
但如果要做多实例负载，当两个人登陆在不同的实例上时，两个服务端实例间怎么通信？
这是nginx解决不了，也不应该去解决的.
这说的是横向通信能力了。
im难搞就在这里

引用：Client to Client方向（简称c2c）：即客户端向客户端发送数据的能力，比如：一条正常的好友聊天消息就是由客户端A发送给客户端B（当然这不一定是P2P技术实现）。

c2c 需要服务端吗