今天小编跟大家讲解下有关科技常识：Nginx服务器做负载均衡反向代理的超级攻略，相信小伙伴们对这个话题应该也很关注吧，小编也收集到了有关科技常识：Nginx服务器做负载均衡反向代理的超级攻略的相关资料，希望小伙伴会喜欢也能够帮助大家。

　　nginx 做反向代理时，后端主机有多台，可以使用 upstream 定义一个后端主机池，在反向代理时直接使用主机池的名字。在 upstream 中可以定义负载均衡调度算法，权重，健康状态检测等参数。

　　例如：

　　 upstream backend { server 172.16.0.1:80 weight=1 max-fails=3 fail_timeout=10; server 172.16.0.2:80 weight=1max-fails=3 fail_timeout=10;; }

　　默认请求下，使用 round-robin 调度算法，并有健康状态检查和恢复主机的能力。

　　ningx 还可以使用这些算法：

　　 ip_hash：基于源地址哈希，主要目的是会话保持 least_conn：基于最少活动连接进行调度 sticky：基于 cookie 进行会话绑定，nginx 会在客户端第一次访问时插入路由信息到 cookie 中，或者选择 cookie 中的某个字段的值作为键，以后每次请求将基于此信息进行调度

　　基于 cookie 的会话绑定共有 cookie，route 和 learn 三种。

　　例如，基于 cookie name 的调度：

　　使用此主机组进行反向代理：

　　 location / { proxy_pass

　　proxy_pass URL 指定代理的后端主机，可以指定 http 或 https 协议，域名可以是 ip 地址，也可以是 upstream 池名字

　　 如果代理指定的是一个 URI 地址，如 ，那么将直接被代理至指定 URI，无论请求的 URI 是什么 如果代理指定的一个主机而没有 URI，如 ，客户端请求的URI将被传递至指定域名 如果 location 中使用模式匹配 url，那么 url 也会被传递至代理 URL 的末端 如果 location 中使用了 URI 重写，那么 proxy_pass 会使用重写后的结果进行处理

　　proxy_set_header HEADER VALUE 对转发的报文首部进行修改一些

　　反向代理时的缓存相关设定

　　proxy_cache_path PATH [levels=levels] keys_zone=NAME:SIZE

　　定义磁盘缓存路径，nignx 的缓存是以键值方式存放的，keys_zone 用于指定键存放的内存空间名字和大小，对应的值则存放在 PATH 指定的路径中。levels 可以指定缓存存放路径的级数和名称字符数。此设置只能在 http 段中定义。

　　如：

　　 proxy_cache_path /var/cache/nginx/proxy levels=1:2 keys_zone=one:10m;

　　proxy_cache_valid [code ...] time 指定不同响应码的内容的缓存时间

　　如：

　　 proxy_cache_valid 200 302 10m; proxy_cache_valid 404 1m; proxy_cache_valid any 1m;

　　proxy_cache_method METHOD 定义哪些方法的请求结果可以被缓存，如：

　　 proxy_cache_method GET; proxy_cache_method HEAD;

　　proxy_cache NAME 指定使用预先定义的缓存空间用于缓存

　　一些问题的解决方法

　　下面来看看采用Nginx负载均衡之后碰到的问题：

　　 通常解决服务器负载问题，都会通过多服务器分载来解决。常见的解决方案有：

　　 那我们看看Nginx是如何实现负载均衡的，Nginx的upstream目前支持以下几种方式的分配 1、轮询（默认） 每个请求按时间顺序逐一分配到不同的后端服务器，如果后端服务器down掉，能自动剔除。 2、weight 指定轮询几率，weight和访问比率成正比，用于后端服务器性能不均的情况。 2、ip_hash 每个请求按访问ip的hash结果分配，这样每个访客固定访问一个后端服务器，可以解决session的问题。 3、fair（第三方） 按后端服务器的响应时间来分配请求，响应时间短的优先分配。 4、url_hash（第三方） 按访问url的hash结果来分配请求，使每个url定向到同一个后端服务器，后端服务器为缓存时比较有效。

　　Upstream配置如何实现负载

　　 http { upstream

　　当有请求到时请求会被分发到对应的upstream设置的服务器列表上。test2的每一次请求分发的服务器都是随机的，就是第一种情况列举的。而test1刚是根据来访问ip的hashid来分发到指定的服务器，也就是说该IP的请求都是转到这个指定的服务器上。

　　根据服务器的本身的性能差别及职能，可以设置不同的参数控制。

　　down 表示负载过重或者不参与负载

　　weight 权重过大代表承担的负载就越大

　　backup 其它服务器时或down时才会请求backup服务器

　　max_fails 失败超过指定次数会暂停或请求转往其它服务器

　　fail_timeout 失败超过指定次数后暂停时间

　　以上就Nginx的负载均衡的简单配置。那继续我们的本节讨论内容：

　　一、Session问题

　　当我们确定一系列负载的服务器后，那我们的WEB站点会分布到这些服务器上。这个时候如果采用Test2 每一次请求随机访问任何一台服务器上，这样导致你访问A服务器后，下一次请求又突然转到B服务器上。这个时候与A服务器建立的Session，传到B站点服务器肯定是无法正常响应的。我们看一下常用的解决方案：

　　 Session或凭据缓存到独立的服务器 Session或凭据保存数据库中 nginx ip_hash 保持同一IP的请求都是指定到固定的一台服务器

　　第一种缓存的方式比较理想，缓存的效率也比较高。但是每一台请求服务器都去访问Session会话服务器，那不是加载重了这台Session服务器的负担吗？

　　第二种保存到数据库中，除了要控制Session的有效期，同时加重了数据库的负担，所以最终的转变为SQL Server 负载均衡，涉及读，写，过期，同步。

　　第三种通过nginx ip_hash负载保持对同一服务器的会话，这种看起来最方便，最轻量。

　　正常情况下架构简单的话， ip_hash可以解决Session问题，但是我们来看看下面这种情况

　　这个时候ip_hash 收到的请求都是来自固定IP代理的请求，如果代理IP的负载过高就会导致ip_hash对应的服务器负载压力过大，这样ip_hash就失去了负载均衡的作用了。

　　如果缓存可以实现同步共享的话，我们可以通过多session服务器来解决单一负载过重的问题。那Memcached是否可以做Session缓存服务器呢？MemcachedProvider提供了Session的功能，即将Session保存到数据库中。那为什么不直接保存到数据库中，而要通过Memcached保存到数据库中呢？很简单，如果直接保存到数据库中，每一次请求Session有效性都要回数据库验证一下。其次，即使我们为数据库建立一层缓存，那这个缓存也无法实现分布式共享，还是针对同一台缓存服务器负载过重。网上也看到有用Memcached实现Session缓存的成功案例，当然数据库方式实现的还是比较常用的，比如开源坛。缓存实现的小范围分布式也是比较常用的，比如单点登录也是一种特殊情况。

　　二、文件上传下载

　　如果实现了负载均衡，除了Session问题，我们还会碰到文件的上传下载问题。文件不可能上传不同的服务器上，这样会导致下载不到对应文件的问题。我们看一下下面的方案

　　 独立文件服务器 文件压缩数据库

　　两种方案都是常用的，我们来说一下文件压缩数据库，以前的方式都是将文件二进制压缩至关系型数据库，而现在NOSQL的流行，加上MongoDB处理文件又比较方便，所以文件压库又多了一种选择。毕竟文件服务器的效率和管理以及安全都不及数据库。

　　随便聊聊这点事，其实也就是一些应用的趋势和多一种解决方案的实现。

　　来源：爱蒂网