一.详细描述常见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，
实现：下次补回来
