nginx高负载均衡服务器

1.1.1   简介

Nginx ("engine x") 是一个高性能的 HTTP 和 反向代理 服务器，也是一个 IMAP/POP3/SMTP代理服务器。 Nginx 是由 Igor Sysoev 为俄罗斯访问量第二的 Rambler.ru 站点开发的，第一个公开版本0.1.0发布于2004年10月4日。其将源代码以类BSD许可证的形式发布，因它的稳定性、丰富的功能集、示例配置文件和低系统资源的消耗而闻名。

其特点是占有内存少，并发能力强，能够支持高达50000个并发连接响应。这归功于它选择了epoll and kqueue作为开发模型（socket数量不限制）(Apache采用的select开发模型)。它处理请求是异步非阻塞，在高并发下保持低资源低消耗高性能。非常稳定，bug极少。Apache使用处理每个连接都需要一个进程，其并发性能不是很好。而Nginx使用多路复用的技术，让一 个进程处理多个连接，所以并发性能比较好。

成为事实上nginx的并发能力确实在同类型的网页服务器中表现较好，中国使用nginx网站用户有：新浪、网易、腾讯、京东、淘宝等。

l  Nginx是一个高性能的HTTP和方向代理服务器

l  采用C语言编写

l  支持的操作系统众多，windows、linux、MacOSX

l  安全性高，外界只能访问nginx所在服务器，nginx将请求转发内部服务器。调用后，返回调用的结果

l  可实现负载均衡

l  Rewrite功能强大

电商、互联网架构大部分都采用Nginx+Tomcat的架构。

官网地址：http://nginx.org/en/download.html

1.1.2   nginx和Apache、IIS等比较

根据W3Techs公布的数据，Nginx目前已经在Web服务器领域有了一定的地位。

在排名前1000的网站中，Nginx占据了将近三分之一的席位（29.1%），已经取代了IIS（仅为12.7%）第二名的位置。当然，Apache还是当之无愧的老大，占39.1%。这表明，大型网站更愿意使用开源的web服务器。Google服务器也有8.2%的份额。

在排名前100万的网站中，主流服务器仍为Apache，占据了63.7%的份额，也有很大一部分使用IIS，占16.7%。Nginx占据了14.2%。

这得益于Nginx使用了最新的epoll（Linux 2.6内核）和kqueue（freebsd）网络I/O模型，而Apache则使用的是传统的select模型。目前Linux下能够承受高并发访问的Squid、Memcached都采用的是epoll网络I/O模型。

处理大量的连接的读写，Apache所采用的select网络I/O模型非常低效。下面用一个比喻来解析Apache采用的select模型和Nginx采用的epoll模型进行之间的区别：

假设你在大学读书，住的宿舍楼有很多间房间，你的朋友要来找你。select版宿管大妈就会带着你的朋友挨个房间去找，直到找到你为止。而epoll版宿管大妈会先记下每位同学的房间号，你的朋友来时，只需告诉你的朋友你住在哪个房间即可，不用亲自带着你的朋友满大楼找人。如果来了10000个人，都要找自己住这栋楼的同学时，select版和epoll版宿管大妈，谁的效率更高，不言自明。同理，在高并发服务器中，轮询I/O是最耗时间的操作之一，select和epoll的性能谁的性能更高，同样十分明了。

1.1.3   Nginx目录结构

1.1.4   Nginx启动停止

启动：     start nginx.exe   （不能双击，双击后进程无法关掉）

停止：     nginx.exe –s stop

重新加载：  nginx.exe –s reload

注：Windows下有时停止无效，造成开启太多，手工结束进程。

1.1.5   方式1：由nginx转发请求到tomcat

当用户访问http://localhost:80，nginx将这个请求什么也不做，只负责转发到tomcat的访问地址http://localhost:8080

server {

       listen       80;

       server_name  localhost;

 

       location/ {                #拦截所有的资源

           proxy_pass   http://127.0.0.1:8080; #转向tomcat的地址

       }

      

}

1.1.6   方式2：动静分离（指向一个目录）

静态资源：图片、css、js、html（静态资源处理时并发非常高）

动态资源：asp/aspx、php、jsp

 

nginx默认配置

location / {

root   html;  #相对路径，配置了一个html目录，我们可以将网站所用到的所有的静态资源从war中移除，放到这个目录下。

index  index.html index.htm;      #配置的欢迎页面

}

1.1.7   方式3：图片服务器（指向一个目录）

    #图片服务器C:\Windows\System32\drivers\etc\hosts

    server {

       listen       80;

       server_name  image.jt.com;      #域名地址，修改hosts文件做一个配置 image.jt.com127.0.0.1

      

       location/ {

              root c:\\jt-upload;      #图片文件所在目录，按日期来分目录：yyyy/mm/dd/uuid.jpg或者当前时间的毫秒数+随机值.jpg

       }

    }

1.1.8   方式4：负载均衡

tomcat集群，每个tomcat部署的业务相同。

1.1.8.1     轮询

默认配置，tomcats有n个，请求就被平均分配到这n个服务器上。请求次数%n，平均分配到每个服务器。

例子：3个tomcat

修改3个端口，在同一台服务器上启动3个tomcat。每个tomcat下放一个index.html。然后内容修改，分别展示T1，T2，T3。当请求nignx，通过这种方法验证得出默认nginx轮询这3个页面，但顺序不一定是配置的顺序。

    #前台，有3个tomcat集群，用户访问时轮询转向到某一个tomcat

    server {

       listen       80;

       server_name  www.jt.com;

 

       location/ {                #拦截所有的资源

           proxy_pass   http://jt;  #引用定义的upstream

       }

      

    }

 

    #配置一个upstream，声明一个名称jt，配置多个ip地址转向，默认就是轮询

    upstreamjt {

       server127.0.0.1:8080;

       server127.0.0.1:8090;

       server127.0.0.1:8100;

    }

轮询方式存在问题：服务器有性能比较好的，有性能比较差的。新的服务器的配置比旧的服务器强悍很多。CPU核也多，内存也大，硬盘容量也大，速度还快。

如果还使用轮询的方式，就会造成新服务器资源的浪费，旧的服务器资源压力大。显然资源分配不合理，应该多劳多得。

1.1.8.2     权重

    #前台，有3个tomcat集群，用户访问时轮询转向到某一个tomcat

    server {

       listen       80;

       server_name  www.jt.com;

 

       location/ {                #拦截所有的资源

           proxy_pass   http://jt;  #引用下面定义的upstream

       }

      

    }

 

    #配置一个upstream，声明一个名称jt，配置多个ip地址转向，默认就是轮询

    upstreamjt {

       server127.0.0.1:8080 weight=8;    #访问请求分成9份，这个tomcat负责8份的链接

       server127.0.0.1:8090 weight=1;    #访问请求分成9份，这个tomcat负责1份的链接

       server127.0.0.1:8100 down;     #这个tomcat暂时不参加负载

    }

1.1.9   *解决Session共享的解决办法

问题的由来：访问一个网站时，有两类请求。一种请求叫做无状态的请求，一种请求叫做有状态。

无状态，例如：登录页面，类似这种页面，哪个tomcat给我们响应都是一样的，不需要区分。这是我们最喜欢的。集群的动态伸缩性（增加节点，移除节点）。

有状态，例如：系统登录后，假如用户的请求被转发到tomcat1上，这时系统会写一个当前用户的信息放入session中。这种情况就称为有状态的，问题就来了。nginx负载均衡后，下一次用户的请求就被转发tomcat2上。tomcat2上没有session。系统就会要求用户去登录，这显然是不合理的。把这个问题称作session共享问题。

解决的办法：

1.1.9.1     session同步

tomcat支持动态将某个tomcat下的session复制到其他的tomcat中。但是这个方式是早期的企业级应用习惯的方式。现在很少使用。

这种方式在集群数量很少时，结果还是可以的。但如果集群数量庞大。都需要复制session，这时会因为网络延迟，或者session的内容非常大。都会造成隐患，这时可能读到脏数据。

1.1.9.2     Session黏着-放在服务端

对ip地址或者域名地址进行hash；或者uri进行hash。

缺点：用户浏览器的IP地址hash以后满足单调性。会可能造成资源的分配不均衡，负载均衡就达不到到目的。有的服务器负载过重，有的服务器负载过轻，显然没有充分利用资源。

 

    #配置一个upstream，声明一个名称jt，配置多个ip地址转向，默认就是轮询

    upstreamjt {

       ip_hash;             #IP_HASH方式来实现session共享

       server127.0.0.1:8080 weight=5;    #访问请求分成9份，这个tomcat负责8份的链接

       server127.0.0.1:8090 weight=5;    #访问请求分成9份，这个tomcat负责1份的链接

       server127.0.0.1:8100 down;     #这个tomcat暂时不参加负载

    }

因为uri比ip地址相应数量多，变化就多，因此uri-hash比ip-hash分布更均衡些。

uri-hash需要第三方软件支持pcre-8.02.tar.gz、Nginx_upstream_hash-0.3.1.tar.gz

1.1.9.3     将信息放到cookie-放在客户端

session存在服务器端，会对服务器产生压力。如果将信息保存到cookie中，减轻了服务器的压力，同时每个客户端的压力也很小。因为只保存自己的信息。这种方式在实际的开发中广泛的采用。

缺点：cookie可以被禁用，cookie要随着浏览器传递，增大了传输的内容，cookie大小有限制。

1.1.9.4     终极的解决方案-新SSO单点登录

将session从系统中独立出来。Apache shiro顶级安全框架，它的session管理就是独立出来的。目前主流做法是利用redis作为session管理的实现，因为redis访问极其快速。

 

 

原先我们将项目的资源一起放到war中，而nginx可以将这些资源单独出来，无需判断为动态资源还是静态资源而直接进行静态资源的返回。这点使处理静态资源时，它的效率比Apache高数倍。

    #图片服务器

    server {

       listen       80;

       server_name  image.jt.com;

       #charsetkoi8-r;

       #access_log  logs/host.access.log  main;

      

       proxy_set_headerX-Forwarded-Host $host;

       proxy_set_headerX-Forwarded-Server $host;

       proxy_set_headerX-Forwarded-For $proxy_add_x_forwarded_for;

      

       location/ {

              root c:\\jt-upload;

       }

    }

目录：C:\jt-upload\images\2016\03\07\607.jpg

访问：http://image.jt.com/images/2016/03/07/607.jpg

1.1.10 流行的nginx部署结构

先通过一个nginx进行转发到2个nginx上，然后再通过nginx进行负载到多个tomcat集群上。