原创作品，允许转载，转载时请务必以超链接形式标明文章 原始出处 、作者信息和本声明。否则将追究法律责任。http://mageedu.blog.51cto.com/4265610/1405190
当我们打开手机访问点评客户端的时候，访问商户的请求是如何到达对应某台应用服务器的？
当有很多XX宽带的用户投诉说我大点评某某域名无法打开但是我们却找不出任何问题的时候，我们就想到会不会是宽带运营商的问题。
今天与大家分享的话题，主要是跟我们的软负载集群和Nginx这个强大的开源应用有关系。
当我们准备上线一个新的业务，或者新的功能时候，除了把代码发布的线上生产环境的应用服务器外，还需要做什么工作才能让我们的资深吃货的用户们可以访问到我们高端大气上档次的服务呢？
用户是不可能直接跑到我们的IDC机房插根网线就来访问我们的内部服务器的，我们答应，电信管理IDC的怪叔叔们也不会答应啊。
首先，我们很清楚用户是通过dianping.com的域名来访问我们的站点，同时通过我们对外开放的url链接来访问一些新站点或者新功能的页面。然后，用户访问的域名会通过DNS服务被替换为我们对外的IP地址，这样才能被网络设备识别，然后将用户的请求按照一个一个网络包发给我们的网络设备，最后网络设备收到这些网络数据包后，会将这些数据整理后转化为应用程序可以理解的数据。
数据到了我们的核心网络设备被转换为应用层的数据后，是如何到我们具体某一台应用服务器来处理呢，这就牵涉到我们要讲的负载均衡器了。负载均衡器如果是硬件设备的话，那就是我们经常提到的负载均衡设备，如果是linux服务器上运行的负载均衡软件，那就是软负载了，如果是集群而不是单机的话，那就是传说中的负载均衡集群了。
如下图是我们 线上生产环境的用户请求走向图：
当一个吃货通过浏览器或手机APP访问我们网站的时候，无论是访问商户，添加点评，购买团购，还是在社区通过私信功能与妹子聊天，所有请求都会经过我们的F5负载均衡设备按照设定的转发策略（随机，权重，最小连接等）转发到特定的某台应用服务器来处理，然后再将处理结果返回给用户。
好吧，当我们说了这个硬件设备时候，是不是要谈谈以软件实现的负载均衡功能呢，其实目前在我们PPE环境（xx机房，以后的双IDC运行后另一个生产环境）运行着这样一套软负载集群来处理用户的请求（当然，现在都是伪造的用户请求）。
网络设备和Nginx负载均衡集群中间的F5作为流量管理设备，做4层（连接层，tcp）流量分发。
软负载实质上是一组nginx集群以及允许用户管理nginx配置文件的一个web端。
Nginx ("engine x") 是一个高性能的 HTTP 和 反向代理 服务器，也是一个 IMAP/POP3/SMTP 代理服务器。 Nginx因稳定性、丰富的功能集和低系统资源的消耗而闻名。
从中我们可以看出，nginx至少可以做web服务器，同时可以做反向代理服务器，同时又可以做邮件代理服务器，功能还是非常丰富的，稍后我们会对nginx的功能模块做简要的介绍。
作为web服务器，nginx由于自身的优势，在处理静态文件上有着绝对的优势，所以也是天然的优秀web服务器软件。
什么是反向代理服务器，和我们平时说的用代理服务器上国外网站又有什么区别？
有图有真相，看图说话
代理服务器呢，就是当我想访问某个网站的时候因为各种原因不能直接访问，我可以主动或者被动用一台可以访问目标站点的服务器做代理去访问我想要访问的站点。
当我主动去找代理服务器去访问是一种情况，还有一种比较悲催的情况，当我们使用了某些无良宽带运营商提供的物美价廉，缩水严重，还不断搞各种潜规则的宽带时候，就会碰到我们这些吃货去访问点评网站的时候，首先是去访问宽带运营商局域网的代理服务器，然后代理服务器去访问点评的网站。这样做对于宽带运营商来说，可以缓存一些数据，这样就能节省点带宽，但是对于我们这些使用宽带的用户而言，一则数据不安全，运营商的代理服务器上可能有我们的***也说不定，二则，当点评站点可正常访问，宽带运营商代理服务器出现问题的时候，就会收到各种用户投诉，点评又跪了，这让吃货怎么活？问题是点评活的好好的，用户却访问不到。
反向代理（Reverse Proxy）是指以代理服务器来接受internet上的连接请求，然后将请求转发给内部网络上的服务器，并将从服务器上得到的结果返回给internet上请求连接的客户端，此时代理服务器对外就表现为一个服务器。
反向代理服务器可以看下面图，nginx就是反向代理的角色，用户的请求是先发到nginx，然后转发到后端的tomcat。
当然，代理服务器和反向代理服务器的类型不只web服务一种。
如下是一个简单的反向代理的配置：
|
1
2
3
4
5
|
server_name qunying.dianping.com;
location / {
proxy_pass test.qunying.liu.dianping.com; //反向代理站。
index index.html index.htm;
}
|
当用户访问qunying.dianping.com/helloword.jsp的时候，这台服务器上的nginx就会将用户的请求转发到qunying.liu.dianping.com/helloword.jsp,当然proxy_pass转向的地址也可以是内部地址，比如127.0.0.1：8080
当然对于我们线上的环境，nginx不是作为典型的反向代理在使用，目前点评java相关web业务服务器上采用的是 nginx （缓存和压缩，日志）+tomcat（java容器），充分利用了nginx低系统占用以及高并发处理的优势。
很多人会有疑问，tomcat也可以做web容器的啊，改个端口不就可以直接给用户提供服务了，而且tomcat也能记录日志，没必要再放一个nginx啊。
tomcat 前面有没有必要放一个nginx呢？
术业有专攻，tomcat做web服务器是兼职，做java容器是专职。nginx服务器是专职做web服务器，支持高并发，响应快，擅长处理静态内容，而且可以把动态内容交给tomcat处理。用tomcat做web容器响应用户请求，有可能1分钟只能处理10个请求，但是用nginx+tomcat一分钟就可能可以处理100个请求。
nginx为什么可以这么快处理用户的请求呢？
nginx的进程模型以及系统事件机制
nginx启动后的进程，如图所示：
我们可以看到master进程，是以root身份启动，执行内容为：/usr/local/nginx/sbin/nginx -c /usr/local/nginx/conf/nginx.conf
worker进程都是以我们指定的nobody身份运行，其中有一个worker进程是旧的worker进程奔溃后，自动重新创建的，你能找到他吗？
nginx在启动后，会有一个master进程和多个worker进程。master进程主要用来管理worker进程，包含：接收来自外界的信号，向各个worker进程发送信号，监控worker进程的运行状态，当worker进程退出后(异常情况下)，会自动重新启动新的worker进程。基本的网络事件，则是放在worker进程中来处理了。多个worker进程之间是对等的，他们同等竞争来自客户端的请求，各进程互相之间是独立的。一个请求，只可能在一个worker进程中处理，一个worker进程，不可能处理其它进程的请求。worker进程的个数是可以设置的，一般我们会设置与机器cpu核数一致。
我们要控制nginx，只需要通过kill向master进程发送信号就行了。比如kill -HUP pid，则是告诉nginx，从容地重启nginx，我们一般用这个信号来重启nginx，或重新加载配置，因为是从容地重启，因此服务是不中断的。master进程在接收到HUP信号后是怎么做的呢？首先master进程在接到信号后，会先重新加载配置文件，然后再启动新的进程，并向所有老的进程发送信号，告诉他们可以光荣退休了。新的进程在启动后，就开始接收新的请求，而老的进程在收到来自master的信号后，就不再接收新的请求，并且在当前进程中的所有未处理完的请求处理完成后，再退出。当然，直接给master进程发送信号，这是比较老的操作方式，nginx在0.8版本之后，引入了一系列命令行参数，来方便我们管理。比如，./nginx -s reload，就是来重启nginx，./nginx -s stop，就是来停止nginx的运行。如何做到的呢？我们还是拿reload来说，我们看到，执行命令时，我们是启动一个新的nginx进程，而新的nginx进程在解析到reload参数后，就知道我们的目的是控制nginx来重新加载配置文件了，它会向master进程发送信号，然后接下来的动作，就和我们直接向master进程发送信号一样了。
worker进程是如何处理我们的http请求的？
master（master进程会先建立好需要listen的socket）--------fork生成子进程workers，继承socket（此时workers子进程们都继承了父进程master的所有属性，当然也包括已经建立好的socket，当然不是同一个socket，只是每个进程的这个socket会监控在同一个ip地址与端口，这个在网络协议里面是允许的）------当一个连接进入，产生惊群现象（惊群现象：指一个fd的事件被触发后，等候这个fd的所有线程/进程都被唤醒。虽然都被唤醒，但是只有一个会去响应。）。
Nginx对惊群现象的处理：共享锁
nginx提供了一个accept_mutex这个东西，从名字上，我们可以看这是一个加在accept上的一把共享锁。有了这把锁之后，同一时刻，就只会有一个进程在accpet连接，这样就不会有惊群问题了。accept_mutex是一个可控选项，我们可以显示地关掉，默认是打开的。
worker进程工作：
当一个worker进程在accept这个连接之后，就开始读取请求，解析请求，处理请求，产生数据后，再返回给客户端，最后才断开连接，这样一个完整的请求就是这样的了。我们可以看到，一个请求，完全由worker进程来处理，而且只在一个worker进程中处理。
采用这种方式的好处：
1）节省锁带来的开销。对于每个worker进程来说，独立的进程，不需要加锁，所以省掉了锁带来的开销，同时在编程以及问题查上时，也会方便很多
2）独立进程，减少风险。采用独立的进程，可以让互相之间不会影响，一个进程退出后，其它进程还在工作，服务不会中断， master进程则很快重新启动新的worker进程。当然，worker进程的异常退出，肯定是程序有bug了，异常退出，会导致当前worker上的所有请求失败，不过不会影响到所有请求，所以降低了风险。
Nginx的事件处理机制，采用异步非阻塞事件处理机制，一个worker进程只有一个主线程，通过异步非阻塞的事件处理机制，实现了循环处理多个准备好的事件，从而实现轻量级和高并发。
异步非阻塞事件处理机制：
同步和异步的概念,这两个概念与消息的通知机制有关.同步的情况下,是由处理消息者自己去等待消息是否被触发,而异步的情况下是由触发机制来通知处理消息者。
阻塞和非阻塞,这两个概念与程序等待消息(无所谓同步或者异步)时的状态有关.
当读写事件没有准备好时，就放入epoll里面。如果有事件准备好了，那么就去处理；如果事件返回的是EAGAIN，那么继续将其放入epoll里面。从而，只要有事件准备好了，我们就去处理，只有当所有时间都没有准备好时，才在epoll里面等着。这样，我们就可以并发处理大量的并发了，当然，这里的并发请求，是指未处理完的请求，线程只有一个，所以同时能处理的请求当然只有一个了，只是在请求间进行不断地切换而已，切换也是因为异步事件未准备好，而主动让出的。这里的切换是没有任何代价，你可以理解为循环处理多个准备好的事件。
与多线程相比，这种事件处理方式是有很大的优势的，不需要创建线程，每个请求占用的内存也很少，没有上下文切换，事件处理非常的轻量级。并发数再多也不会导致无谓的资源浪费（上下文切换）。更多的并发数，只是会占用更多的内存而已.
之前我们提到nginx的负载均衡功能，那么和LVS的负载均衡有什么区别呢？
负载均衡分为：
L4 switch（四层交换），即在OSI第4层工作，就是TCP层啦。此种Load Balance不理解应用协议（如HTTP/FTP/MySQL等等）。例子：LVS，F5
L7 switch（七层交换），OSI的最高层，应用层。此时，该Load Balancer能理解应用协议。例子：haproxy，MySQL Proxy
很多Load Balancer（例如F5）既可以做四层交换，也可以做七层交换。
LVS 工作在网络4层仅做请求分发之用没有流量，可配置性低，几乎可对所有应用做负载均衡，对网络依赖大，没有健康检查机制。
nginx的7层(应用层)，所以它可以针对http应用本身来做分流策略，比如针对域名、目录结构等，对网络依赖小，可检测服务器内部错误。
nginx可以根据URL进行负载均衡的请求转发，而LVS只能根据ip:port进行请求转发
一般情况下，LVS会被放在最前端做负载均衡，nginx可作为lvs的节点服务器。
前面我们也提到过nginx实现邮件代理服务器的功能，一般使用nginx做邮件代理服务器的场景不多。
很不幸，nginx最早也是被当作邮件代理服务器来开发的。
--with-mail - 启用 IMAP4/POP3/SMTP 代理模块
安装时需要注意的库依赖：
gzip模块需要 zlib 库
rewrite模块需要 pcre 库
ssl 功能需要openssl库
我们nginx一般安装在:/usr/local/nginx 目录，nginx的安装目录结构如下图所示
/usr/local/nginx
├── conf（配置文件目录）
│ ├── fastcgi.conf
│ ├── fastcgi.conf.default
│ ├── fastcgi_params
│ ├── fastcgi_params.default
│ ├── hosts
│ ├── koi-utf
│ ├── koi-win
│ ├── mime.types
│ ├── mime.types.default
│ ├── nginx_app.conf（应用相关配置段 server段）
│ ├── nginx.conf（nginx公用配置信息 events，http段）
│ ├── nginx.conf.default
│ ├── nginx_status.conf
│ ├── proxy.conf
│ ├── scgi_params
│ ├── scgi_params.default
│ ├── uwsgi_params
│ ├── uwsgi_params.default
│ └── win-utf
├── html
│ ├── 50x.html
│ └── index.html
├── logs -> /data/applogs/nginx
├── sbin（nginx程序目录）
│ └── nginx
└── tmpdir
├── client_body_temp
├── fastcgi_temp
├── proxy_temp
│ ├── 0
│ │ └── 01
│ ├── 1
│ │ ├── 00
│ │ └── 01
│ ├── 2
│ │ ├── 00
│ │ └── 01
│ ├── 3
│ │ ├── 00
│ │ └── 01
│ ├── 4
│ │ ├── 00
│ │ └── 01
│ ├── 5
│ │ ├── 00
│ │ └── 01
│ ├── 6
│ │ ├── 00
│ │ └── 01
│ ├── 7
│ │ ├── 00
│ │ └── 01
│ ├── 8
│ │ ├── 00
│ │ └── 01
│ └── 9
│ └── 00
├── scgi_temp
└── uwsgi_temp