Ngixn 部分功能介绍

1.http服务器

1
2
3
4
5
当只有静态资源的时候，可以使用Nginx做HTTP服务器，可以将服务器上的静态文件（如HTML、图片）通过HTTP协议展现给客户端。

动静分离常用于前后端分离，Nginx提供的动静分离是指把动态请求和静态请求分离开，合适的服务器处理相应的请求，使整个服务器系统的性能、效率更高。

Nginx可以根据配置对不同的请求做不同转发，这是动静分离的基础。静态请求对应的静态资源可以直接放在Nginx上做缓冲，更好的做法是放在相应的缓冲服务器上。动态请求由相应的后端服务器处理。

2.正向代理和反向代理

1
2
3
4
5
6
7
正向代理：

正向代理，是一个位于客户端与原始服务器之间的服务器，为了从原始服务器取得内容，客户端向代理发送一个请求并指定原始目标（原始服务器），然后代理向原始服务器转交请求并将获得的内容返回给客户端。

反向代理：

客户端本来可以直接通过HTTP协议访问某网站应用服务器，网站管理员可以在中间加上一个Nginx，客户端请求Nginx，Nginx请求应用服务器，然后将结果返回给客户端，此时Nginx就是反向代理服务器。

3.负载均衡

1
2
3
4
5
6
7
8
9
10
11
负载均衡多在高并发情况下需要使用。原理是将数据流量分摊到多个服务器执行，减轻每台服务器的压力，多台服务器(集群)共同完成工作任务，从而提高了数据的吞吐量。同时带来的好处是，其中一台服务器万一宕机，只要还有其他服务器正常运行，就不会影响用户使用。

Nginx可以通过反向代理来实现负载均衡。Nginx可使用的负载均衡策略有：轮询（默认）、权重、ip_hash、url_hash(第三方模块)、fair(第三方模块)

weight轮询（默认）：接收到的请求按照顺序逐一分配到不同的后端服务器，即使在使用过程中，某一台后端服务器宕机，nginx会自动将该服务器剔除出队列，请求受理情况不会受到任何影响。 这种方式下，可以给不同的后端服务器设置一个权重值（weight），用于调整不同的服务器上请求的分配率；权重数据越大，被分配到请求的几率越大；该权重值，主要是针对实际工作环境中不同的后端服务器硬件配置进行调整的。

ip_hash：每个请求按照发起客户端的ip的hash结果进行匹配，这样的算法下一个固定ip地址的客户端总会访问到同一个后端服务器，这也在一定程度上解决了集群部署环境下session共享的问题。

fair：智能调整调度算法，动态的根据后端服务器的请求处理到响应的时间进行均衡分配，响应时间短处理效率高的服务器分配到请求的概率高，响应时间长处理效率低的服务器分配到的请求少；结合了前两者的优点的一种调度算法。nginx默认不支持fair算法，如果要使用这种调度算法，需安装upstream_fair模块。

url_hash：按照访问的url的hash结果分配请求，每个请求的url会指向后端固定的某个服务器，可以在nginx作为静态服务器的情况下提高缓存效率。nginx默认不支持这种调度算法，要使用的话需要安装nginx的hash软件包。

4.Nginx模块

4.1 nginx状态信息

1
2
3
nginx中的stub_status模块主要用于查看Nginx的一些状态信息。

本模块默认是不会编译进Nginx的,如果要使用该模块,则要在编译安装Nginx时指定。

4.1.1 加载http_stub_status模块

1
2
 ./configure --prefix=/usr/local/nginx --with-http_stub_status_module
make && make install

4.1.2 修改nginx配置文件

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
在server中，添加如下代码：

location /NginxStatus {

  stub_status on;

  access_log on;

  auth_basic "NginxStatus";

  auth_basic_user_file htpasswd;

}

命令行操作：

htpasswd -c /usr/local/nginx/conf/htpasswd nginx_focus #连续输入两次密码

New password:

Re-type new password:

Adding password for user nginx_focus

4.1.3 打开nginx 的stub_status

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
可以通过页面链接看到如下信息:

Active connections: 145

server accepts handled requests

 1749 1749 3198

Reading: 0 Writing: 3 Waiting: 142

参数详解：  

Active connections：145           

#nginx 正处理的活动连接数145个。

server accepts handled requests

 1749 1749 3198                   

#nginx启动到现在共处理了 1749个连接 ,nginx启动到现在共成功创建 1749次握手 请求丢失数=(握手-连接),可以看出，我们没丢请求;总共处理了3198 次请求。

Reading: 0 Writing: 3 Waiting: 142

#Reading ：nginx读取到客户端的Header信息数。

#Writing ： nginx返回给客户端的Header信息数。

#Waiting ： Nginx已经处理完正在等候下一次请求指令的驻留连接.开启keep-alive的情况下,这个值等于active–(reading+writing)。

4.1.4 访问量统计

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
1、叙述

PV（Page View）：即页面浏览量或者点击量，用户每一次对网站中每个页面访问均记录1个PV。用户对同一页面的多次访问，访问量累积。
UV（Unique Visitor）：指通过互联网浏览这个网页的人，电脑称为一个访客、手机也称为一个访客，一天之内相同的客户端只能被计算一次。
IP（Internet Protocol）：指独立IP访问站点的IP总数，一天内相同IP只能算一次。
VV（Visit View）：指所有访客一天内访问网站的次数，当访客完成所有浏览并最终关闭网站的所有页面时变完成了一次访问，同一访客一天内可能有多次访问行为，访问次数累积。 


1.根据访问IP统计UV

awk '{print $1}'  access.log|sort | uniq -c |wc -l

2.统计访问URL统计PV

awk '{print $7}' access.log|wc -l

3.查询访问最频繁的URL

awk '{print $7}' access.log|sort | uniq -c |sort -n -k 1 -r|more

4.查询访问最频繁的IP

awk '{print $1}' access.log|sort | uniq -c |sort -n -k 1 -r|more

5.根据时间段统计查看日志

 cat  access.log| sed -n  '/14\/Mar\/2015:21/,/14\/Mar\/2015:22/p'|more

4.2 nginx健康检查机制

1
nginx原生的健康检测主要涉及两个模块:ngx_http_proxy_module和ngx_http_upstream_module

4.2.1 ngx_http_proxy_module

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
upstream backend {

    server 127.0.0.1:8080 max_fails=3 fail_timeout=30s;



}

1.max_fails

设定Nginx与服务器通信的尝试失败的次数。在fail_timeout参数定义的时间段内，如果失败的次数达到此值，Nginx就认为服务器不可用。在下一个fail_timeout时间段，服务器不会再被尝试。 失败的尝试次数默认是1。设为0就会停止统计尝试次数，认为服务器是一直可用的。 你可以通过指令proxy_next_upstream、fastcgi_next_upstream和 memcached_next_upstream来配置什么是失败的尝试。 默认配置时，http_404状态不被认为是失败的尝试。

2.fail_timeout

设定服务器被认为不可用的时间段以及统计失败尝试次数的时间段。在这段时间中，服务器失败次数达到指定的尝试次数，服务器就被认为不可用。默认情况下，该超时时间是10秒。

4.2.2 ngx_http_proxy_module

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
1.proxy_connect_timeout

与后端服务器建立连接的超时时间

2.proxy_read_timeout

定义从后端服务器读取响应的超时。此超时是指相邻两次读操作之间的最长时间间隔，而不是整个响应传输完成的最长时间。如果后端服务器在超时时间段内没有传输任何数据，连接将被关闭

3.proxy_next_upstream

指定在何种情况下一个失败的请求应该被发送到下一台后端服务器

 

需要理解一点的是，只有在没有向客户端发送任何数据以前，将请求转给下一台后端服务器才是可行的。也就是说，如果在传输响应到客户端时出现错误或者超时，这类错误是不可能恢复的。

zookeeper

1. zookeeper 概述

1
2
zookeeper是一种观察者模式的设计模式。负责管理存储数据，然后接受观察者的注册，一旦数据的状态发生变化，zookeeper就将负责通知已经在zookeeper上注册的那些观察者做出相应的反应

观察者模式

1
观察者模式是一种对象行为模式。它定义对象间的一种一对多的依赖关系，当一个对象的状态发生改变时，所有依赖于它的对象都得到通知并被自动更新。在观察者模式中，主体是通知的发布者，它发出通知时并不需要知道谁是它的观察者，可以有任意数目的观察者订阅并接收通知。观察者模式不仅被广泛应用于软件界面元素之间的交互，在业务对象之间的交互、权限管理等方面也有广泛的应用。

2. zookeeper的特点

1
2
3
4
5
6
7
1. zookeeper是一个领导者和多个跟随着组成的集群。
2. 集群中只w要有半数以上的节点存活，zookeeper集群就能正常服务
3. 全局数据一直：每个service保存一份相同的数据副本，client无论连接到哪个service，数据都是一致的
4. 更新顺序执行
5. 数据更新原子性，要么成功要么失败
6. 实时性，能读到最新数据

3. zookeeper 的应用场景

1