Nginx反向代理提高网站性能的原理（整理）

【手动迁移自前博客】2019-03-13 17:49浏览 143
https://www.iteye.com/blog/zeraw-2438834

现在大部分出名的网站都采用的是nginx服务器。nginx服务器性能得到了全球的认可。那么为什么nginx的性能会如此只好呢？本文将通过普通的现实例子来给大家讲明白nginx性能好的原因。

反向代理的主要作用是分发请求。

首先我们要了解系统的性能瓶颈在哪里，一般来说网络io速度和内存io接近，都远高于磁盘io。假定一个接口请求返回数据100k（一般没有这么大，只是假定一个方便计算的值），10个并发请求就是1M，那么全双工千兆网卡（现在还有万兆网卡，但成本太高，应用还不广），可以支撑并发10000个请求，开双网卡，理论的上限就是20000个并发请求。

假设我们收到请求马上就返回，那么最高并发数就是我们上面计算的结果，但是，问题在于，应用服务器做不到马上返回，因为它有很多业务逻辑需要执行处理，比如给用户发推送发短信发邮件，本地磁盘写日志，请求数据库增删改查，调用微信的登录接口等等等等，都附加了各个层面的io。

所以第一层的优化，我们会尽量优化应用服务自身，把发推送发短信发邮件的活推到队列，让别的服务器去干。这个一般用内存队列，io很高。

开多线程或者协程的方式异步写日志，但再怎么优化，磁盘io的上限突破不了，这个io很低。还有更激进的方案，干脆日志也写内存，或者通过内网网络同步到别的服务器上，可以更优化。

数据库复用连接池，减少连接和断开的时间开销。查询语句尽量优化，减少等待数据库操作的时间。当然，再怎么优化，一样有个上限。

调用微信的登录接口等外部接口，这个就更难办了，受制于人，除了tcp连接池复用能稍微优化一点点，完全是取决于外部条件。

木桶理论取最短板，所有这些条件里，总有最慢最落后的那个。假如拖后腿的这个，最佳状态也只能优化到支持2000个并发，那就尴尬了，本来能支持20000个请求的系统，只能用到1/10性能。

（ 当然也可以在dns对应不同ip方式分布请求，但是dns层面的分布更复杂更麻烦，因为dns缓存的原因，请求也不能均匀分布，而且ip地址也是越来越稀缺的资源，没有背景没有后台的，搞这么多ip也不容易啊 ）

单个公网ip算一个节点的话，这个节点本来的潜力是响应20000个并发请求，实际在应用层面只能到2000并发，潜力还未发掘啊。这个时候，就是反向代理起到用武之地的时候了。

首先一个反向代理的服务器抛开所有业务层的东西，只单纯的接下请求再返回，那么可以支持到20000并发了。接下来应用层面谁来处理？找来10个小弟，转发给他们，每人2000正好。这样这个节点系统虽然性价比只有10/11，但是性能潜力好歹挖尽了。

这就是反向代理的作用了。

打个比方来说：

把服务器想象成饭店，没有Nginx的情况，就如同每一个厨师服务一桌顾客，从点菜开始到炒菜到上菜到收银，有n个厨师就只能服务n桌顾客。有了Nginx的话，Nginx就成了强大的服务员，把招呼，点菜、上菜和收银的活都做了，厨师只需要专心炒菜就行。这样饭店的效率就大大提高了。

技术一点的话：

请求如果直接发到同步处理的后端，那么从收到请求到把响应发出去这段时间，一个进程的资源就被占用了（比如Apache的prefork模式）。在慢连接的情况下，这个进程除了处理之外的大多数时间基本上都耗费在了无意义的等待上。Nginx在这方面的优势就在于它的异步非阻塞模型。这意味着Nginx可以通过基于事件的方式同时处理和维护多个请求，而后端就只需要去做逻辑计算，节约了等待时间去处理更多的请求。
反向代理提高网站性能主要通过三个方面：

1. 反向代理可以理解为7层应用层的负载均衡，使用负载均衡之后可以非常便捷的横向扩展服务器集群，实现集群整体并发能力、抗压能力的提高。
2. 通常反向代理服务器会带有本地Cache功能，通过静态资源的Cache，有效的减少后端服务器所承载的压力，从而提高性能
3. http压缩，开启压缩后，网络流量传输减小，相同带宽下可以服务更多用户

最后还有一个TCP链接复用，不过说实话，如果不是商用的负载均衡器，一般没这个功能。
其实，反向代理还可以有效的隐藏隔离内部服务器，提高了安全性，这也算是提高性能的一个方面吧

现在大部分出名的网站都采用的是nginx服务器。nginx服务器性能得到了全球的认可。那么为什么nginx的性能会如此只好呢？本文将通过普通的现实例子来给大家讲明白nginx性能好的原因。

反向代理的主要作用是分发请求。

首先我们要了解系统的性能瓶颈在哪里，一般来说网络io速度和内存io接近，都远高于磁盘io。假定一个接口请求返回数据100k（一般没有这么大，只是假定一个方便计算的值），10个并发请求就是1M，那么全双工千兆网卡（现在还有万兆网卡，但成本太高，应用还不广），可以支撑并发10000个请求，开双网卡，理论的上限就是20000个并发请求。

假设我们收到请求马上就返回，那么最高并发数就是我们上面计算的结果，但是，问题在于，应用服务器做不到马上返回，因为它有很多业务逻辑需要执行处理，比如给用户发推送发短信发邮件，本地磁盘写日志，请求数据库增删改查，调用微信的登录接口等等等等，都附加了各个层面的io。

所以第一层的优化，我们会尽量优化应用服务自身，把发推送发短信发邮件的活推到队列，让别的服务器去干。这个一般用内存队列，io很高。

开多线程或者协程的方式异步写日志，但再怎么优化，磁盘io的上限突破不了，这个io很低。还有更激进的方案，干脆日志也写内存，或者通过内网网络同步到别的服务器上，可以更优化。

数据库复用连接池，减少连接和断开的时间开销。查询语句尽量优化，减少等待数据库操作的时间。当然，再怎么优化，一样有个上限。

调用微信的登录接口等外部接口，这个就更难办了，受制于人，除了tcp连接池复用能稍微优化一点点，完全是取决于外部条件。

木桶理论取最短板，所有这些条件里，总有最慢最落后的那个。假如拖后腿的这个，最佳状态也只能优化到支持2000个并发，那就尴尬了，本来能支持20000个请求的系统，只能用到1/10性能。

（ 当然也可以在dns对应不同ip方式分布请求，但是dns层面的分布更复杂更麻烦，因为dns缓存的原因，请求也不能均匀分布，而且ip地址也是越来越稀缺的资源，没有背景没有后台的，搞这么多ip也不容易啊 ）

单个公网ip算一个节点的话，这个节点本来的潜力是响应20000个并发请求，实际在应用层面只能到2000并发，潜力还未发掘啊。这个时候，就是反向代理起到用武之地的时候了。

首先一个反向代理的服务器抛开所有业务层的东西，只单纯的接下请求再返回，那么可以支持到20000并发了。接下来应用层面谁来处理？找来10个小弟，转发给他们，每人2000正好。这样这个节点系统虽然性价比只有10/11，但是性能潜力好歹挖尽了。

这就是反向代理的作用了。

打个比方来说：

把服务器想象成饭店，没有Nginx的情况，就如同每一个厨师服务一桌顾客，从点菜开始到炒菜到上菜到收银，有n个厨师就只能服务n桌顾客。有了Nginx的话，Nginx就成了强大的服务员，把招呼，点菜、上菜和收银的活都做了，厨师只需要专心炒菜就行。这样饭店的效率就大大提高了。

技术一点的话：

请求如果直接发到同步处理的后端，那么从收到请求到把响应发出去这段时间，一个进程的资源就被占用了（比如Apache的prefork模式）。在慢连接的情况下，这个进程除了处理之外的大多数时间基本上都耗费在了无意义的等待上。Nginx在这方面的优势就在于它的异步非阻塞模型。这意味着Nginx可以通过基于事件的方式同时处理和维护多个请求，而后端就只需要去做逻辑计算，节约了等待时间去处理更多的请求。
反向代理提高网站性能主要通过三个方面：

反向代理可以理解为7层应用层的负载均衡，使用负载均衡之后可以非常便捷的横向扩展服务器集群，实现集群整体并发能力、抗压能力的提高。
通常反向代理服务器会带有本地Cache功能，通过静态资源的Cache，有效的减少后端服务器所承载的压力，从而提高性能
http压缩，开启压缩后，网络流量传输减小，相同带宽下可以服务更多用户
最后还有一个TCP链接复用，不过说实话，如果不是商用的负载均衡器，一般没这个功能。
其实，反向代理还可以有效的隐藏隔离内部服务器，提高了安全性，这也算是提高性能的一个方面吧

并发处理方面apache还是没有 nginx擅长。

b