关于负载均衡（传送门）scrat的另一篇文章，本篇讲解nginx反向代理方式实现负载均衡。
1.Nginx简介
Nginx是一款高性能的http 服务器/反向代理服务器及电子邮件（IMAP/POP3）代理服务器。由俄罗斯的程序设计师Igor Sysoev所开发，官方测试nginx能够支支撑5万并发链接，并且cpu、内存等资源消耗却非常低，运行非常稳定。
2.Nginx应用场景
1、http服务器。Nginx是一个http服务可以独立提供http服务。可以做网页静态服务器。
2、虚拟主机。可以实现在一台服务器虚拟出多个网站。例如个人网站使用的虚拟主机。
3、反向代理，负载均衡。当网站的访问量达到一定程度后，单台服务器不能满足用户的请求时，需要用多台服务器集群可以使用nginx做反向代理。并且多台服务器可以平均分担负载，不会因为某台服务器负载高宕机而某台服务器闲置的情况。
3.概念解释
3.1正向代理
所谓正向代理其实就和我们平时所做的翻墙一样，例如:当我们想要访问某些国外的**网站时，因为某些原因我们无法访问到，这时候我们就可以找代理，代理有能力访问到那个网站，而我们只需要访问代理。就可以得到那个网站的内容了。且代理可以决定是否将用户信息告诉给网站。
总的来说正向代理是一个位于客户端与原始服务器之间的一个代理服务器，为了从原始服务器获取内容，客户端向代理发送一个请求并指定目标服务器(原始服务器),然后代理服务器向原始服务器转交请求并获取内容交给目标服务器，客户端必须进行特殊的设置才能使用正向代理。
如下图所示。
3.2反向代理
与正向代理相反，举个例子：当用户访问某个服务器下的内容时，其实该服务器并无此内容，但是该服务器通过反向代理从另一台服务器中获取到了用户想要的内容，并返回给了用户。用户以为是在此服务器下获取到的内容，其实并不是。
总的来说，反向代理用户不需要进行特殊的设置，对用户来说他以为访问得到的内从是从原始服务器中得到的。其实是客户端向反向代理的命名空间中发送普通请求，接着反向代理将判断向何处(原始服务器)转交请求，并将获得的内容返回给客户端，就像这些内容 原本就是它自己的一样。 如图所示
4.安装Nginx
4.1 下载
进入http://nginx.org/en/download.html 下载nginx，本人使用的是nginx1.8.0版本。
4.2 安装
4.2.1 安装环境
安装nginx需要如下环境
1.gcc
编译依赖gcc环境，如果没有gcc环境，需要安装gcc
yum install gcc-c++ 2.PCRE
PCRE(Perl Compatible Regular Expressions)是一个Perl库，包括 perl 兼容的正则表达式库。nginx的http模块使用pcre来解析正则表达式，所以需要在linux上安装pcre库。
yum install -y pcre pcre-devel3.zlib
lib库提供了很多种压缩和解压缩的方式，nginx使用zlib对http包的内容进行gzip，所以需要在linux上安装zlib库。
yum install -y zlib zlib-devel4.openssl
OpenSSL 是一个强大的安全套接字层密码库，囊括主要的密码算法、常用的密钥和证书封装管理功能及SSL协议，并提供丰富的应用程序供测试或其它目的使用。
nginx不仅支持http协议，还支持https（即在ssl协议上传输http），所以需要在linux安装openssl库。
yum install -y openssl openssl-devel4.2.2 编译安装
将nginx-1.8.0.tar.gz拷贝至linux服务器。
解压：
tar -zxvf nginx-1.8.0.tar.gz
cd nginx-1.8.0
执行如下命令
./configure \
--prefix=/usr/local/nginx \
--pid-path=/var/run/nginx/nginx.pid \
--lock-path=/var/lock/nginx.lock \
--error-log-path=/var/log/nginx/error.log \
--http-log-path=/var/log/nginx/access.log \
--with-http_gzip_static_module \
--http-client-body-temp-path=/var/temp/nginx/client \
--http-proxy-temp-path=/var/temp/nginx/proxy \
--http-fastcgi-temp-path=/var/temp/nginx/fastcgi \
--http-uwsgi-temp-path=/var/temp/nginx/uwsgi \
--with-http_stub_status_module \
--with-http_ssl_module \
--http-scgi-temp-path=/var/temp/nginx/scgi注意：上边将临时文件目录指定为/var/temp/nginx，需要在/var下创建temp/nginx目录
开始编译和安装
make
make install
安装成功查看安装目录 ：
4.3启动Nginx
启动
cd /usr/local/nginx/sbin/
./nginx查看
ps -aux | grep nginx
其中6844为Nginx的主进程id，6845为Nginx的工作进程id
4.3退出Nginx
cd /usr/local/nginx/sbin
./nginx -s quit4.4 重启Nginx
cd /usr/local/nginx/sbin
./nginx -s reload4.5 Nginx测试
访问对应安装Nginx的linux的ip，出现如下界面即安装成功。
5.搭建负载均衡
5.1 什么是负载均衡
负载均衡 建立在现有网络结构之上，它提供了一种廉价有效透明的方法扩展网络设备和服务器的带宽、增加吞吐量、加强网络数据处理能力、提高网络的灵活性和可用性。
负载均衡，英文名称为Load Balance，其意思就是分摊到多个操作单元上进行执行，例如Web服务器、FTP服务器、企业关键应用服务器和其它关键任务服务器等，从而共同完成工作任务。
5.2 负载均衡的优点
简单的来说。可以减少服务器的压力，将原本一台服务器所要承受的访问量分给了多台，并提高了项目的可用性，当一台服务器挂掉的时候也不会导致整个项目瘫痪。
5.3 nginx实现负载均衡
nginx作为负载均衡服务器，用户请求先到达nginx，再由nginx根据负载配置将请求转发至 tomcat服务器。
nginx负载均衡服务器：192.168.14.129
tomcat1服务器：192.168.14.131
tomcat2服务器：192.168.14.134
我们将两个相同的项目分别放到了131与134服务器中，当我们通过129负载访问项目接口时，nginx会自动将请求轮流分配给131与134来执行。
5.4 配置
以vim模式打开nginx.conf配置文件
cd /usr/local/nginx/conf/
vi nginx.conf根据上边的需求在nginx.conf文件中配置负载均衡，如下：
#在server上添加此upstream节点
upstream mytomcat{
#分权 即访问131与134的次数比例为1比1
server 192.168.14.131:8080 weight=1;
server 192.168.14.134:8080 weight=1;
}
server {
listen 80;
server_name localhost;
#即所有请求都到这里去找分配
location / {
#使用mytomcat分配规则，即刚自定义添加的upstream节点
proxy_pass http://mytomcat;
}
}配置完成，保存并退出。
5.5 测试结果
多次访问此接口。通过后台日志我们发现两个接口分别轮流被调用，这样一个简单的负载就搭建完成了。
补充，应当注意的几个问题：
nginx还可以按照调度规则实现动态、静态页面的分离，可以按照轮询、ip哈希、URL哈希、权重等多种方式对后端服务器做负载均衡，同时还支持后端服务器的健康检查。
nginx 的 upstream目前支持 4 种方式的分配
1)、轮询（默认）
每个请求按时间顺序逐一分配到不同的后端服务器，如果后端服务器down掉，能自动剔除。
2)、weight
指定轮询几率，weight和访问比率成正比，用于后端服务器性能不均的情况。
2)、ip_hash
每个请求按访问ip的hash结果分配，这样每个访客固定访问一个后端服务器，可以解决session的问题。
3)、fair（第三方）
按后端服务器的响应时间来分配请求，响应时间短的优先分配。
4)、url_hash（第三方）
多台机器间session的共享问题
配置负载均衡比较简单,但是最关键的一个问题是怎么实现多台服务器之间session的共享
下面有几种方法(以下内容来源于网络,第四种方法没有实践.)
1). 不使用session，换作cookie
能把session改成cookie，就能避开session的一些弊端，在集群系统中不能用session，如果系统不复杂，就优先考虑能否将session去掉，改动起来非常麻烦的话，再用下面的办法。
2). 应用服务器自行实现共享
php可以用数据库或memcached来保存session，从而在php本身建立了一个session集群，用这样的方式可以令 session保证稳定，即使某个节点有故障，session也不会丢失，适用于较为严格但请求量不高的场合。但是它的效率是不会很高的，不适用于对效率要求高的场合。
以上两个办法都跟nginx没什么关系，下面来说说用nginx该如何处理：
3). ip_hash
nginx中的ip_hash技术能够将某个ip的请求定向到同一台后端，这样一来这个ip下的某个客户端和某个后端就能建立起稳固的session，ip_hash是在upstream配置中定义的：
upstream backend {
server 127.0.0.1:8080 ;
server 127.0.0.1:9090 ;
ip_hash;
}
ip_hash是容易理解的，但是因为仅仅能用ip这个因子来分配后端，因此ip_hash是有缺陷的，不能在一些情况下使用：
nginx不是最前端的服务器。ip_hash要求nginx一定是最前端的服务器，否则nginx得不到正确ip，就不能根据ip作hash。譬如使用的是squid为最前端，那么nginx取ip时只能得到squid的服务器ip地址，用这个地址来作分流是肯定错乱的。
nginx的后端还有其它方式的负载均衡。假如nginx后端又有其它负载均衡，将请求又通过另外的方式分流了，那么某个客户端的请求肯定不能定位到同一台session应用服务器上。这么算起来，nginx后端只能直接指向应用服务器，或者再搭一个squid，然后指向应用服务器。最好的办法是用location作一次分流，将需要session的部分请求通过ip_hash分流，剩下的走其它后端去。
4). upstream_hash
为了解决ip_hash的一些问题，可以使用upstream_hash这个第三方模块，这个模块多数情况下是用作url_hash的，但是并不妨碍将它用来做session共享。假如前端是squid，他会将ip加入x_forwarded_for这个http_header里，用upstream_hash可以用这个头做因子，将请求定向到指定的后端：可见这篇文档：http://www.sudone.com/nginx/nginx_url_hash.html
在文档中是使用$request_uri做因子，稍微改一下：
hash $http_x_forwarded_for;
这样就改成了利用x_forwarded_for这个头作因子，在nginx新版本中可支持读取cookie值，所以也可以改成：
hash $cookie_jsessionid;
假如在php中配置的session为无cookie方式，配合nginx自己的一个userid_module模块就可以用nginx自发一个cookie，可参见userid模块的英文文档：http://wiki.nginx.org/NginxHttpUserIdModule
另可用姚伟斌编写的模块upstream_jvm_route：http://code.google.com/p/nginx-upstream-jvm-route/
后端服务器自动加上端口的问题
一个典型的 Nginx + Apache 应用方案可以是Nginx 占用 80 端口，过滤静态请求，然后动态请求即 Proxy 到 Apache 的 8080 端口。Proxy 反向代理的好处是访问的时候，始终就是 80端口，来访者不会觉察到有任何的区别。但有的应用确非常“聪明”，识别到 Apache 所位于的端口是 8080 ，就会把相关的超链接都一并加上 :8080 的后续。这么就死定了，还能有正常访问麽？！有个方法可以解决这事，就是把 apache 也运行在80端口上。同一台服务器，有Nginx 也有 Apache，2个httpd服务，都是80，不会冲突麽？
nginx.conf 的配置中
server {
listen 80;
server_name www.linuxidc.com;
....
}
修改为：
server {
listen 123.123.123.123:80; #指定Nginx只占用某个公网IP的80端口。
#listen 123.123.123.124:80; #如果你服务器中有多个IP，还可以指定多个。
server_name www.linuxidc.com;
....
}
把 apache 的配置文件 httpd.conf 中的
Listen 80
改为
Listen 127.0.0.1:80
跟Nginx一样，指定apache所占用的IP及端口。
保存退出，重启apache即可生效。