一.详细描述常见nginx常用模块和模块的使用示例

1.http_core_module

http核心配置模块，该模块提供了一堆的指令及一堆的变量，常用指令及用法：

alias

只能用于location配置段，定义路径别名；

location /images/ {

    root /data/imgs/;

}

location  /images/  {

    alias /data/imgs/;

}

注意：

root指令：给定的路径对应于location的“/”这个URL；

/images/test.jpg -->  /data/imgs/images/test.jpg

alias指令：给定的路径对应于location的“/uri/"这个URL；

/images/test.jpg -->  /data/imgs/test.jpg

"root-左侧对其，alias右侧对其"

这个location相当于访问服务器上的文件目录：/home/nginx/abc.jpg(即alias不会使用location后面配置的路径)而且alias 指定的目录名后面一定要加上  "/"

error_page

根据http的状态码重定向错误页面；

error_page 404 /404.html

error_page  404  =200  /404.html  （以指定的响应状态码进行响应）

http

http协议相关的配置段，大致格式如下，里面可根据需求配置一堆信息，如：

http {

    ...

}

limit_rate

限制客户端每秒钟所能够传输的字节数，默认为0表示无限制；

listen

设置nginx监听的端口，如：

listen 127.0.0.1:8000;

listen 127.0.0.1;

listen 8000;

listen *:8000;

listen localhost:8000;

location

Syntax:location [ = | ~ | ~* | ^~ ] uri { ... }

location @name { ... }

Default:—

Context:server, location

允许根据用户请求的URI来匹配定义的各location，匹配到时，此请求将被相应的location块中的配置所处理；简言之，即用于为需要用到专用配置的uri提供特定配置；

=：URI的精确匹配；

~：做正则表达式匹配，区分字符大小写；

~*：做正则表达式匹配，不区分字符大小写；

^~：URI的左半部分匹配，不检查正则表达式，不区分字符大小写；

匹配优先级：精确匹配=、^~、~或~*、不带符号的URL；

nginx官网例子：

location = / {

    [ configuration A ]

}

location / {

    [ configuration B ]

}

location /documents/ {

    [ configuration C ]

}

location ^~ /images/ {

    [ configuration D ]

}

location ~* \.(gif|jpg|jpeg)$ {

    [ configuration E ]

}

The “/” request will match configuration A, the “/index.html” request will match configuration B, the “/documents/document.html” request will match configuration C, the “/images/1.gif” request will match configuration D, and the “/documents/1.jpg” request will match configuration E.

root

设置web资源的路径映射；指明请求的URL所对应的文档的目录路径；

server {

...

root  /data/www/vhost1;

}

http://www.magedu.com/images/logo.jpg --> /data/www/vhosts/images/logo.jpg

sendfile

是否启用sendfile功能，sendfile on | off;

server

sets configuration for a virtual server，即定义个虚拟主机，如：

server {

listen PORT;

server_name NAME;

root /PATH/TO/DOCUMENTROOT;

}

server_name

sets names of a virtual server, for example:

server {

    server_name example.com www.example.com;

}

http_core_module模块中的变量

---

2.http_ssl_module

ssl_certificate file;

    证书文件路径；

ssl_certificate_key file;

    证书对应的私钥文件；

ssl_ciphers ciphers;

    指明由nginx使用的加密算法，可以是OpenSSL库中所支持各加密套件；

ssl_protocols [SSLv2] [SSLv3] [TLSv1] [TLSv1.1] [TLSv1.2];

    指明支持的ssl协议版本，默认为后三个；

ssl_session_cache off | none | [builtin[:size]] [shared:name:size];

    指明ssl会话缓存机制；

    builtin：使用OpenSSL内置的ssl会话缓存，对机制为各worker私有；

    shared：在各worker之间使用一个共享的缓存；

    name：独有名称；

    size：缓存空间大小；

ssl_session_timeout time;

    ssl会话超时时长；即ssl session cache中的缓存有效时长；

3.http_proxy_module

(1) proxy_pass URL;

应用上下文：location, if in location, limit_except

proxy_pass后面的路径不带uri时，其会将location的uri传递给后端的主机；下面的示例会将/uri/传递给backend服务器；

location  /uri/ {

proxy_pass http://hostname;

}

proxy_pass后面的路径是一个uri时，其会将location的uri替换为后端主机自己的uri；

location  /uri/ {

proxy_pass http://hostname/new_uri/;

}

如果location定义其uri时使用的正则表达式模式匹配，则proxy_pass后的路径不能够使用uri；

location  ~*  \.(jpg|gif|jpeg)$  {

proxy_pass  http://HOSTNAME;

}

此处的http://HOSTNAME后面不能有任何uri，哪怕只有/也不可以；

(2) proxy_set_header field value;

用于proxy server向backend server发请求报文时，将某请求首部重新赋值，或在原有值后面添加一个新的值； 也可以添加自定义首部；

示例：

proxy_set_header  X-Real-IP  $remote_addr;

proxy_set_header  X-Forwarded-For  $proxy_add_x_forwarded_for;

原有请求报文中如果存在X-Forwared-For首部，则将remote_addr以逗号分隔补原有值后，否则则直接添加此首部；

4.http_upstream_module

用于将多个服务器定义成服务器组，而由proxy_pass, fastcgi_pass等指令进行引用；

(1) upstream name { ... }

定义一个后端服务器组，name为组名称；仅能用于http上下文 ；

(2) server address [parameters];

在upstream中定义一个服务器及其相关参数；仅能用于upstream上下文；

常用参数：

weight=number：定义服务器权重，默认为1；

max_fails=number：最大失败连接尝试次数，失败连接超时时长由fail_timeout参数指定；

fail_timeout=number：等待目标服务器发送响应的时长；

backup：备用服务器，所有主服务器均故障时才启用此主机；

down：手动标记其不再处理任何用户请求；

使用方法：

(a) 定义upstream服务器组

upstream websrvs {

server 172.16.100.68 weight=2 max_fails=2 fail_timeout=6s;

server 172.16.100.6  weight=1 max_fails=2 fail_timeout=6s;

}

(b) 在反代场景中（proxy_pass, fastcgi_pass, ...）进行调用；

location / {

proxy_pass http://websrvs/;

}

(3) ip_hash;

源地址hash，把来自同一个ip地址的请求始终发往同一个backend server，除非此backend server不可用；

(4) least_conn;

最少连接；当各server权重不同时，即为加权最少连接；

(5) health_check [parameters];

健康状态检测机制；只能用于location上下文；

常用参数：

interval=time检测的频率，默认为5秒；

fails=number：判定服务器不可用的失败检测次数；默认为1次；

passes=number：判定服务器可用的失败检测次数；默认为1次；

uri=uri：做健康状态检测测试的目标uri；默认为/；

match=NAME：健康状态检测的结果评估调用此处指定的match配置块；

(6) match name { ... }

对backend server做健康状态检测时，定义其结果判断机制；只能用于http上下文；

常用的参数：

status  code[  code ...]: 期望的响应状态码；

header  HEADER[operator  value]：期望存在响应首部，也可对期望的响应首部的值基于比较操作符和值进行比较；

body：期望响应报文的主体部分应该有的内容；

(7) hash key [consistent];

指明基于hash方式进行调度时，其hash key；

hash  $remote_addr相当于ip_hash；

常用的hash key:

$cookie_name：将一个用户的请求始终发往同一个backend server，能实现会话绑定的功能；此处的name为cookie某些参数的名称，此处常用的有cookie_username；

$request_uri: 将对同一个uri的请求始终发往同一个backend server，后端为cache server时特别有用；

session会话保持：

session sticky：基于ip, ngix还可基于请求报文首部中的多种信息，例如cookie, uri；

session cluster：每个server均把创建和维护session同步集群中的其它主机；仅适用于较小规模的环境；

session server：使用一个共享的存储服务存储session信息；

location ~* \.php$ {

proxy_pass

}

location / {

proxy_pass

}

5.http_gunzip_module

模块为那些不支持gzip模块的客户端解压缩gzip格式相应的相应。

用法：

location /storage/ {

    gunzip on;

    ...

}

6.http_gzip_module

开启或关闭http协议中的数据压缩，用法：

gzip on;

gzip_min_length 1000;

gzip_proxied    expired no-cache no-store private auth;

gzip_types      text/plain application/xml;

更多配置参加官网配置文档：http://nginx.org/en/docs/

二.简述Linux集群类型、系统扩展方式及调度方法

集群类型：

LB：负载均衡集群，Load Balancing

HA：高可用集群，High Availability

HP：高性能集群，High Performancing

系统扩展的方式：

scale up: 向上扩展

scale out: 向外扩展

ipvs scheduler：

根据其调度时是否考虑各RS当前的负载状态，可分为静态方法和动态方法两种：

静态方法：仅根据算法本身进行调度；

RR：roundrobin，轮询；

WRR：Weighted RR，加权轮询；

SH：Source Hashing，实现session sticky，源IP地址hash；将来自于同一个IP地址的请求始终发往第一次挑中的RS，从而实现会话绑定；

DH：Destination Hashing；目标地址哈希，将发往同一个目标地址的请求始终转发至第一次挑中的RS，典型使用场景是正向代理缓存场景中的负载均衡；

动态方法：主要根据每RS当前的负载状态及调度算法进行调度；

Overhead=负载值

LC：least connections

Overhead=activeconns*256+inactiveconns

WLC：Weighted LC

Overhead=(activeconns*256+inactiveconns)/weight

SED：Shortest Expection Delay

Overhead=(activeconns+1)*256/weight

NQ：Never Queue

LBLC：Locality-Based LC，动态的DH算法；

LBLCR：LBLC with Replication，带复制功能的LBLC；

三.简述lvs四种集群特点及使用场景

lvs集群的类型：

lvs-nat：修改请求报文的目标IP；多目标IP的DNAT；

lvs-dr：操纵封装新的MAC地址；

lvs-tun：在原请求IP报文之外新加一个IP首部；

lvs-fullnat：修改请求报文的源和目标IP；

lvs-nat：

多目标IP的DNAT，通过将请求报文中的目标地址和目标端口修改为某挑出的RS的RIP和PORT实现转发；

（1）RIP和DIP必须在同一个IP网络，且应该使用私网地址；RS的网关要指向DIP； （DIP是内网，VIP是外网？）

（2）请求报文和响应报文都必须经由Director转发；Director易于成为系统瓶颈；

（3）支持端口映射，可修改请求报文的目标PORT；

（4）vs必须是Linux系统，rs可以是任意系统；

lvs-dr：

Direct Routing，直接路由；

通过为请求报文重新封装一个MAC首部进行转发，源MAC是DIP所在的接口的MAC，

目标MAC是某挑选出的RS的RIP所在接口的MAC地址；源IP/PORT，以及目标IP/PORT均保持不变；

Director和各RS都得配置使用VIP；

(1) 确保前端路由器将目标IP为VIP的请求报文发往Director：

(a) 在前端网关做静态绑定；

(b) 在RS上使用arptables；

(c) 在RS上修改内核参数以限制arp通告及应答级别；

arp_announce

arp_ignore

(2) RS的RIP可以使用私网地址，也可以是公网地址；RIP与DIP在同一IP网络；RIP的网关不能指向DIP，以确保响应报文不会经由Director；

(3) RS跟Director要在同一个物理网络；

(4) 请求报文要经由Director，但响应不能经由Director，而是由RS直接发往Client；

(5) 不支持端口映射；

lvs-tun：

转发方式：不修改请求报文的IP首部（源IP为CIP，目标IP为VIP），而是在原IP报文之外再封装一个IP首部（源IP是DIP，目标IP是RIP），

将报文发往挑选出的目标RS；RS直接响应给客户端（源IP是VIP，目标IP是CIP）；

(1) DIP, VIP, RIP都应该是公网地址；

(2) RS的网关不能，也不可能指向DIP；

(3) 请求报文要经由Director，但响应不能经由Director；

(4) 不支持端口映射；

(5) RS的OS得支持隧道功能；

lvs-fullnat：

通过同时修改请求报文的源IP地址和目标IP地址进行转发；

CIP <--> DIP 

VIP <--> RIP 

(1) VIP是公网地址，RIP和DIP是私网地址，且通常不在同一IP网络；因此，RIP的网关一般不会指向DIP；

(2) RS收到的请求报文源地址是DIP，因此，只能响应给DIP；但Director还要将其发往Client；

(3) 请求和响应报文都经由Director；

(4) 支持端口映射；

注意：此类型默认不支持；

总结：

lvs-nat, lvs-fullnat：请求和响应报文都经由Director；

lvs-nat：RIP的网关要指向DIP；

lvs-fullnat：RIP和DIP未必在同一IP网络，但要能通信；

lvs-dr, lvs-tun：请求报文要经由Director，但响应报文由RS直接发往Client；

lvs-dr：通过封装新的MAC首部实现，通过MAC网络转发；

lvs-tun：通过在原IP报文之外封装新的IP首部实现转发，支持远距离通信；

四.描述LVS-NAT、LVS-DR的工作原理并实现配置

lvs-nat:

多目标的DNAT(iptables)；它通过修改请求报文的目标IP地址(同时可能会修改目标端口)至挑选出某RS的RIP地址实现转发；

(1) RS应该和DIP应该使用私网地址，且RS的网关要指向DIP；

(2) 请求和响应报文都要经由director转发；极高负载的场景中，director可能会成为系统瓶颈；

(3) 支持端口映射；

(4) RS可以使用任意OS；

(5) RS的RIP和Director的DIP必须在同一IP网络；

实现：下次补回来

lvs-dr:

它通过修改请求报文的目标MAC地址进行转发；

(1) 保证前端路由器将目标IP为VIP的请求报文发送给director;

解决方案：

    静态绑定

    arptables

    修改RS主机内核（2.6版本以后）的参数

(2) RS的RIP可以使用私有地址；但也可以使用公网地址；

(3) RS跟Director必须在同一物理网络中；

(4) 请求报文经由Director调度，但响应报文一定不能经由Director；

(5) 不支持端口映射；

(6) RS可以大多数OS；

(7) RS的网关不能指向DIP；

关键点：RealServer的lo口绑定VIP，

实现：下次补回来