#Nginx+Redis实现反向代理和Session共享(一)
###什么是正向代理和反向代理？
正向代理
假如我访问不了google，但是有个代理服务器可以访问google，那我可以通过连接这个代理服务器来访问google。
正向代理是一个位于客户端和目标服务器之间的一个代理服务器，为了从目标服务器取得内容，客户端向代理发送一个请求并指定目标(原始服务器)，然后代理向目标服务器转交请求并将获得的内容返回给客户端。
反向代理
访问http://www.baidu.com，但是百度页面文件不是在访问的目标服务器上，目标服务器只是暗中从另外一台服务器获取页面文件，然后呈现给用户，用户对内部操作并不知情。
###正向代理和反向代理区别
从用途上来讲：
正向代理的典型用途是为在防火墙内的局域网客户端提供访问Internet的途径。正向代理还可以使用缓冲特性减少网络使用率。
反向代理的典型用途是将防火墙后面的服务器提供给Internet用户访问。
反向代理还可以为后端的多台服务器提供负载平衡，或为后端较慢的服务器提供缓冲服务。另外，反向代理还可以启用高级URL策略和管理技术，从而使处于不同web服务器系统的web页面同时存在于同一个URL空间下。
从安全性来讲：
正向代理允许客户端通过它访问任意网站并且隐藏客户端自身，因此你必须采取安全措施以确保仅为经过授权的客户端提供服务。
反向代理对外都是透明的，访问者并不知道自己访问的是一个代理。
###反向代理和负载均衡区别？
这里不得不说说两者之间的区别了，之前还一直认为它们没啥区别~~~从功能方面看，个人认为是一个包含和被包含的关系。
1.反向代理，是有把命令转发的能力，这个是必须基础。而负载均衡，是把命令转发到不同的服务器上，均衡各个服务器。
2.做了反向代理才能实现负载均衡。负载均衡是做反向代理的目的之一。
###服务器架构 IMG
1.有三台服务器，其中两台是用作Web服务(相同系统项目)，另外一台用Nginx实现负载均衡、反向代理、Session服务器
2.访问过程：
a. 当用户A访问nginx代理的时候，nginx指向web1；
b. web1通过session_id()获取当前浏览器头的cookie信息所带的session_id，然后以[session_id()."username"]的作为key的形式保存在redis中。
c. 当用户A再次刷新页面访问nginx代理的时候，nginx指向web2；
d. web2获取session_id然后以[session_id()."username"]的形式查询redis是否存在该session，如果存在则无需登录。
3.架构特点 
###Nginx反向代理配置
1.添加hosts文件
#vi /etc/hosts 127.0.0.1 centos.agent.com
2.nginx.conf
nginx 使用反向代理，主要是使用location模块下的proxy_pass选项
#centos.agent.conf server { listen 80; server_name centos.agent.com; access_log /usr/local/var/log/nginx/centos.agent.access.log main; error_log /usr/local/var/log/nginx/centos.agent.error.log error; location / { proxy_pass http://192.168.33.10; } }3.测试访问 当我访问上的nginx 的 centos.agent.com 的内容时候, 就反向代理到虚拟机centos上的 192.168.33.10 的index.html页面。
###Nginx负载均衡
随着业务量的增大，就需要使用负载均衡减轻单台服务器压了。
centos.agent.com作为主服务器承担请求分发的任务，当外部访问centos.agent.com，就会把请求发送给以下这三台服务器192.168.33.11
192.168.33.12
192.168.33.13
基于 weight 权重的负载 该配置使用恒等权重，三台服务器权重相同，轮询分发。
upstream agent_servers{#定义上游服务器列表组
server 192.168.33.11 weight=10; server 192.168.33.12 weight=10; server 192.168.33.13 weight=10; } server { listen 80; server_name upstream.agent.com; access_log /usr/local/var/log/nginx/upstream.agent.access.log main; error_log /usr/local/var/log/nginx/upstream.agent.error.log error; location / { proxy_pass http://agent_servers; proxy_set_header X-Real-IP $remote_addr; } }其他负载均衡 该配置使用恒等权重，三台服务器权重相同，轮询分发。
upstream webservers{ server 192.168.33.11 down; server 192.168.33.12 weight=10 max_fails=2 fail_timeout=30s; server 192.168.33.13 backup; } ○ max_fails :允许请求失败的次数，默认为1。当超过最大次数时，返回proxy_next_upstream 模块定义的错误。 ○ fail_timeout : 在经历了max_fails次失败后，暂停服务的时间。max_fails可以和fail_timeout一起使用，进行健康状态检查。 ○ 所以这2个一起搭配使用，表示：当失败2次的时候，就停止使30秒。 ○ down 表示这台机器暂时不参与负载均衡。相当于注释掉了。 ○ backup 表示这台机器是备用机器，是其他的机器不能用的时候，这台机器才会被使用，俗称备胎 O__O "…
基于 ip_hash 的负载
这种分配方式，每个请求按访问IP的hash结果分配，这样来自同一个IP的访客固定访问一个后端服务器，这种方法可以有效解决了动态网页存在的session共享问题
upstream webservers{ ip_hash; server 192.168.33.11 weight=1 max_fails=2 fail_timeout=30s; server 192.168.33.12 weight=1 max_fails=2 fail_timeout=30s; server 192.168.33.13 down; }注意：
ip_hash 模式下，最好不要设置weight参数，这样将会导致很多的流量分配不均匀。
按照访问IP的hash结果分配，如果某一IP访问量大的话就变相的违背了负载均衡特性。
