nginx详解（正向代理、反向代理、负载均衡）

一、引言

今天博主的哥们提出个这样的问题：分布式系统中session共享采用什么样的方式解决比较好。这块也是我的知识盲区，说不出个所以然来。经过请教大佬和查阅大量资料后，我们有必要了解下ngnix代理服务器是怎么玩的。（注：前述基础内容https://blog.csdn.net/tsummerb/article/details/79248015这篇博客写的很详细，这里简单引用不再阐述）

二、nginx概述

nginx是一款自由的、开源的、高性能的HTTP服务器和反向代理服务器；同时也是一个IMAP、POP3、SMTP代理服务器；nginx可以作为一个HTTP服务器进行网站的发布处理，另外nginx可以作为反向代理进行负载均衡的实现。这里主要想介绍下ngnix的正向代理，反向代理以及负载均衡。

1.正向代理(代理客户端，服务端不知道实际发起请求的客户端)

在如今的网络环境下，我们如果由于技术需要要去访问国外的某些网站，此时你会发现位于国外的某网站我们通过浏览器是没有办法访问的，此时大家可能都会用一个操作FQ进行访问，FQ的方式主要是找到一个可以访问国外网站的代理服务器，我们将请求发送给代理服务器，代理服务器去访问国外的网站，然后将访问到的数据传递给我们！

简单一点：A向C借钱，由于一些情况不能直接向C借钱，于是A想了一个办法，他让B去向C借钱，这样B就代替A向C借钱，A就得到了C的钱，C并不知道A的存在，B就充当了A的代理人的角色。

2.反向代理(代理服务端，客户端不知道实际提供服务的服务端)

多个客户端给服务器发送的请求，nginx服务器接收到之后，按照一定的规则分发给了后端的业务处理服务器进行处理了。此时~请求的来源也就是客户端是明确的，但是请求具体由哪台服务器处理的并不明确了，nginx扮演的就是一个反向代理角色
反向代理，主要用于服务器集群分布式部署的情况下，反向代理隐藏了服务器的信息

举个通俗点的例子A向B借钱，B没有拿自己的钱，而是悄悄地向C借钱，拿到钱之后再交给A,A以为是B的钱，他并不知道C的存在。

3.项目应用场景

通常情况下，我们在实际项目操作时，正向代理和反向代理很有可能会存在在一个应用场景中，正向代理代理客户端的请求去访问目标服务器，目标服务器是一个反向单利服务器，反向代理了多台真实的业务处理服务器。具体的拓扑图如下：

4.负载均衡

我们已经明确了所谓代理服务器的概念，那么接下来，nginx扮演了反向代理服务器的角色，它是以依据什么样的规则进行请求分发的呢？不用的项目应用场景，分发的规则是否可以控制呢？
这里提到的客户端发送的、nginx反向代理服务器接收到的请求数量，就是我们说的负载量
请求数量按照一定的规则进行分发到不同的服务器处理的规则，就是一种均衡规则
所以~将服务器接收到的请求按照规则分发的过程，称为负载均衡。
负载均衡在实际项目操作过程中，有硬件负载均衡和软件负载均衡两种，硬件负载均衡也称为硬负载，如F5负载均衡，相对造价昂贵成本较高，但是数据的稳定性安全性等等有非常好的保障，如中国移动中国联通这样的公司才会选择硬负载进行操作；更多的公司考虑到成本原因，会选择使用软件负载均衡，软件负载均衡是利用现有的技术结合主机硬件实现的一种消息队列分发机制

nginx支持的负载均衡调度算法方式如下：
weight轮询（默认）：接收到的请求按照顺序逐一分配到不同的后端服务器，即使在使用过程中，某一台后端服务器宕机，nginx会自动将该服务器剔除出队列，请求受理情况不会受到任何影响。 这种方式下，可以给不同的后端服务器设置一个权重值（weight），用于调整不同的服务器上请求的分配率；权重数据越大，被分配到请求的几率越大；该权重值，主要是针对实际工作环境中不同的后端服务器硬件配置进行调整的。
ip_hash：每个请求按照发起客户端的ip的hash结果进行匹配，这样的算法下一个固定ip地址的客户端总会访问到同一个后端服务器，这也在一定程度上解决了集群部署环境下session共享的问题。
fair：智能调整调度算法，动态的根据后端服务器的请求处理到响应的时间进行均衡分配，响应时间短处理效率高的服务器分配到请求的概率高，响应时间长处理效率低的服务器分配到的请求少；结合了前两者的优点的一种调度算法。但是需要注意的是nginx默认不支持fair算法，如果要使用这种调度算法，请安装upstream_fair模块
url_hash：按照访问的url的hash结果分配请求，每个请求的url会指向后端固定的某个服务器，可以在nginx作为静态服务器的情况下提高缓存效率。同样要注意nginx默认不支持这种调度算法，要使用的话需要安装nginx的hash软件包

三、nginx应用

还是用一张图来说明ngnix分发请求方式

客户端发起请求访问应用服务器时，ngnix反向代理服务器进行拦截后分发(取决于应用架构选择何种负载均衡方式，我们可以理解为代理服务器每次重启可以调整负载方式)到具体哪个服务器上，从而进一步访问存储层(如：db，单独提供的数据库服务器)。这里举例两个实际应用场景:
1.a客户端发起一次查询请求，通过代理服务器分发(负载均衡模式为轮询)到A应用服务器上，然后访问db。这时候按客户端又发起了一次修改请求，通过代理服务器假设分发到B应用服务器上，然后访问db进行数据修改。（session共享问题，可以选择redis来存储）
2.a客户端发起一次查询请求，通过代理服务器分发(负载均衡模式为ip hash)到A应用服务器上，然后访问db。这时候按客户端又发起了一次修改请求，通过代理服务器必然分发到A应用服务器上，然后访问db进行数据修改。(注：这里就不存在session共享问题，因为一客户端访问两次请求访问到的必然是同一应用服务器)
当然，依据上述图所示，我们看到的 经过应用服务器访问到的始终只是一台服务器的db，在高并发的场景下，单服务器db必然负载不了。这时候我们应该考虑以下几种方案来分担压力
(1)分库分表机制
(2)引入缓存层，如redis(高并发下万一缓存某段时间大量失效会导致缓存雪崩，数据库依然会有巨大压力。这里仅抛出概念,不作阐述)
(3)服务器集群