1.反向代理产生的背景
在计算机世界里，由于单个服务器的处理客户端（用户）请求能力有一个极 限，当用户的接入请求蜂拥而入时，会造成服务器忙不过来的局面，可以使用多个 服务器来共同分担成千上万的用户请求，这些服务器提供相同的服务，对于用户来 说，根本感觉不到任何差别。
2.反向代理服务的实现
需要有一个负载均衡设备（即反向代理服务器）来分发用户请求，将用户请 求分发到空闲的服务器上。服务器返回自己的服务到负载均衡设备。负载均衡设备 将服务器的服务返回用户。
1.正向代理
正向代理的过程隐藏了真实的请求客户端，服务器不知道真实的客户端是谁， 客户端请求的服务都被代理服务器代替请求。我们常说的代理也就是正向代理，正 向代理代理的是请求方，也就是客户端；比如我们要访问youtube，可是不能访问， 只能先安装个FQ软件间接访问，通过软件才能访问，FQ软件就叫作正向代理。
2.反向代理
反向代理的过程隐藏了真实的服务器，客户不知道真正提供服务的人是谁， 客户端请求的服务都被代理服务器处理。反向代理代理的是响应方，也就是服务端； 我们请求www.baidu.com时这www.baidu.com就是反向代理服务器，真实提供服务 的服务器有很多台，反向代理服务器会把我们的请求分/转发到真实提供服务的各 台服务器。Nginx就是性能非常好的反向代理服务器，用来做负载均衡。
3.图示
Apache/nginx是静态服务器（HTTP Server）：
Nginx优点：
负载均衡、反向代理、处理静态文件优势。nginx处理静态请求的速度高于apache；
Apache优点：
相对于Tomcat服务器来说处理静态文件是它的优势，速度快。Apache是静态解析，适合静态HTML、图片等。
HTTP Server关心的是HTTP协议层面的传输和访问控制，所以在Apache/Nginx上你可以看到代理、负载均衡等功能，HTTP Server（Nginx/Apache）常用做静态内容服务和代理服务器，将外来请求转发给后面的应用服务（tomcat，jboss,jetty等）。
应用服务器(tomcat/jboss/jetty)是动态服务器（Application Server），是一个应用执行的容器。它首先需要支持开发语言的 Runtime（对于 Tomcat 来说，就是 Java，若是Ruby/Python 等其他语言开发的应用也无法直接运行在 Tomcat 上）。
但是事无绝对，为了方便，应用服务器(如tomcat)往往也会集成 HTTP Server 的功能，nginx也可以通过模块开发来提供应用功能，只是不如专业的 HTTP Server 那么强大，所以应用服务器往往是运行在 HTTP Server 的背后，执行应用，将动态的内容转化为静态的内容之后，通过 HTTP Server 返回到客户端。
常用开源集群软件有：lvs，keepalived，haproxy，nginx，apache，heartbeat
常用商业集群硬件有：F5, Netscaler，Radware，A10等
1.了解代理配置
ngx_http_proxy_module //代理模块
Syntax: proxy_pass URL; //代理的后端服务器URL
Default: —
Context: location, if in location, limit_except
Syntax: proxy_set_header field value; //头信息
Default: proxy_set_header Host $proxy_host; //设置真实客户端地址
proxy_set_header Connection close;
Context: http, server, location
Syntax: proxy_connect_timeout time; //链接超时
Default: proxy_connect_timeout 60s;
Context: http, server, location
Syntax: proxy_read_timeout time;
Default: proxy_read_timeout 60s;
Context: http, server, location
Syntax: proxy_send_timeout time; //nginx进程向fastcgi进程发送request的整个过程的超时时间
Default: proxy_send_timeout 60s;
Context: http, server, location
2.配置实例
1）环境
两台已下载好nginx服务器：
10.8.161.112 网站服务器
10.8.161.34 代理服务器
2）网站服务器
3）代理服务器
4）测试访问
PC端访问http://10.8.161.34/，会有新日志内容在112服务器的日志文件。
1.作用
如果你的nginx服务器给2台web服务器做代理，负载均衡算法采用轮询，那么当你的一台机器web程序关闭造成web不能访问，那么nginx服务器分发请求还是会给这台不能访问的web服务器，如果这里的响应连接时间过长，就会导致客户端的页面一直在等待响应，对用户来说体验就大大折扣，这时可以配置负载均衡。
如果负载均衡中其中web2发生这样的情况，nginx首先会去web1请求，但是nginx在配置不当的情况下会继续分发请求到web2，然后等待web2响应，直到我们的响应时间超时，才会把请求重新分发给web1，这里的响应时间如果过长，用户等待的时间就会越长。
2.Upstream配置
Upstream配置是写一组被代理的服务器地址，然后配置负载均衡的算法。这里的被代理服务器地址有2种写法。
3.算法
Upstream支持四种负载均衡调度算法：
1）轮询(默认)
每个请求按时间顺序逐一分配到不同的后端服务器;
2）ip_hash
每个请求按访问IP的hash结果分配，同一个IP客户端固定访问一 个后端服务器。可以保证来自同一ip的请求被打到固定的机器上，可以解决session 问题。
3）url_hash
按访问url的hash结果来分配请求，使每个url定向到同一个后端 服务器。后台服务器为缓存的时候效率。
4）fair
这是比上面两个更加智能的负载均衡算法。此种算法可以依据页面大 小和加载时间长短智能地进行负载均衡，也就是根据后端服务器的响应时间来分配 请求，响应时间短的优先分配。Nginx本身是不支持 fair的，如果需要使用这种调 度算法，必须下载Nginx的 upstream_fair模块。
4.示例
1）热备
如果你有2台服务器，当一台服务器发生事故时，才启用第二台服务器给提供服务。服务器处理请求的顺序：AAAAAA,突然A出故障了，然后BBBBBBBBBBBBBB…
2）轮询
Nginx默认就是轮询其权重都默认为1，服务器处理请求的顺序：ABABABABAB…
3）加权轮询
根据配置的权重的大小而分发给不同服务器不同数量的请求。如果不设置，则默认为1。下面服务器的请求顺序为：ABBABBABBABBABB…
4）ip_hash
Nginx会让相同的客户端ip请求相同的服务器。
5.nginx负载均衡配置状态参数
down，表示当前的server暂时不参与负载均衡。
backup，预留的备份机器。当其他所有的非backup机器出现故障或者忙的时候，才会请求backup机器，因此这台机器的压力最轻。
max_fails，允许请求失败的次数，默认为1。当超过最大次数时，返回错误。
fail_timeout，在经历了max_fails次失败后，暂停服务的时间单位秒。max_fails可以和fail_timeout一起使用。
6.7层和4层协议
1）7层协议
OSI（Open System Interconnection）是一个开放性的通行系统互连参考模型， 他是一个定义的非常好的协议规范，共包含七层协议。
2）4层协议
TCP/IP协议 之所以说TCP/IP是一个协议族，是因为TCP/IP协议包括TCP、IP、UDP、ICMP、RIP、TELNETFTP、SMTP、ARP、TFTP等许多协议，这些协议一起称为TCP/IP协议。
从协议分层模型方面来讲，TCP/IP由四个层次组成：网络接口层、网络层、传输层、应用层。
3）实例
1>简介
在nginx做负载均衡，负载多个服务，部分服务是需要7层的，部分服务 是需要4层的，也就是说7层和4层配置在同一个配置文件中。
2>环境
三台机器，一台本机，两台yum安装nginx
10.8.161.48 本机
10.8.161.34 后端服务器a
10.8.161.112 后端服务器b
3>代理服务器配置
4>后端服务器配置
5>4层tcp负载
nginx在1.9.0的时候，增加了一个 stream 模块，用来实现四层协议（网络层和传输层）的转发、代理、负载均衡等。stream模块的用法跟http的用法 类似，允许我们配置一组TCP或者UDP等协议的监听，然后通过proxy_pass 来转发我们的请求，通过upstream添加多个后端服务，实现负载均衡。
nginx会话保持主要有三种：ip_hash，sticky_cookie_insert，jvm_route。
1.ip_hash
ip_hash使用源地址哈希算法，将同一客户端的请求总是发往同一个后端服务器，除非该服务器不可用。
ip_hash简单易用，但有部分缺陷：当后端服务器宕机后，session会话丢失；同一客户端会被转发到同一个后端服务器，可能导致负载失衡。
2.sticky_cookie_insert
使用sticky_cookie_insert启用会话亲缘关系，这会导致来自同一客户端的请求 被传递到一组服务器的同一台服务器。与ip_hash不同之处在于，它不是基于IP来判断客户端的，而是基于cookie来判断。因此可以避免上述ip_hash中来自同一客户端导致负载失衡的情况。(需要引入第三方模块才能实现)