运维面试知识点---01
2023-10-03 19:24:03 0 举报运维常见面试知识点---第一部分
作者其他创作
大纲/内容
1、磁盘使用率检测（用shell脚本）
cat fdisk.sh
#!/bin/bash
# 截取IP
IP=`ifconfig eth0 |awk -F " " 'NR==2{print $2}'`
# 定义使用率,并转换为数字
SPACE=`df -Ph |awk '{print int($5)}'`
for i in $SPACE
do
if [ $i -ge 90 ]
then
echo "$IP的磁盘使用率已经超过了90%，请及时处理"
fi
done
#!/bin/bash
# 截取IP
IP=`ifconfig eth0 |awk -F " " 'NR==2{print $2}'`
# 定义使用率,并转换为数字
SPACE=`df -Ph |awk '{print int($5)}'`
for i in $SPACE
do
if [ $i -ge 90 ]
then
echo "$IP的磁盘使用率已经超过了90%，请及时处理"
fi
done
2、 LVS 负载均衡有哪些策略？
LVS一共有三种工作模式： DR，Tunnel,NAT
LVS一共有三种工作模式： DR，Tunnel,NAT
3. 谈谈你对LVS的理解？
LVS是一个虚拟的服务器集群系统，在unix系统下实现负载均衡的功能；采用IP负载均衡技术和机遇内容请求分发技术来实现。
LVS采用三层结构，分别是：
第一层： 负载调度器
第二层： 服务池
第三层：共享存储
负载调度器（load balancer/ Director），是整个集群的总代理，它有两个网卡，一个网卡面对访问网
站的客户端，一个网卡面对整个集群的内部。负责将客户端的请求发送到一组服务器上执行，而客户也
认为服务是来自这台主的。举个生动的例子，集群是个公司，负载调度器就是在外接揽生意，将接揽到
的生意分发给后台的真正干活的真正的主机们。当然需要将活按照一定的算法分发下去，让大家都公平
的干活。
服务器池（server pool/ Realserver），是一组真正执行客户请求的服务器，可以当做WEB服务器。就
是上面例子中的小员工。
共享存储（shared storage），它为服务器池提供一个共享的存储区，这样很容易使得服务器池拥有相
同的内容，提供相同的服务。一个公司得有一个后台账目吧，这才能协调。不然客户把钱付给了A，而
换B接待客户，因为没有相同的账目。B说客户没付钱，那这样就不是客户体验度的问题了。
LVS采用三层结构，分别是：
第一层： 负载调度器
第二层： 服务池
第三层：共享存储
负载调度器（load balancer/ Director），是整个集群的总代理，它有两个网卡，一个网卡面对访问网
站的客户端，一个网卡面对整个集群的内部。负责将客户端的请求发送到一组服务器上执行，而客户也
认为服务是来自这台主的。举个生动的例子，集群是个公司，负载调度器就是在外接揽生意，将接揽到
的生意分发给后台的真正干活的真正的主机们。当然需要将活按照一定的算法分发下去，让大家都公平
的干活。
服务器池（server pool/ Realserver），是一组真正执行客户请求的服务器，可以当做WEB服务器。就
是上面例子中的小员工。
共享存储（shared storage），它为服务器池提供一个共享的存储区，这样很容易使得服务器池拥有相
同的内容，提供相同的服务。一个公司得有一个后台账目吧，这才能协调。不然客户把钱付给了A，而
换B接待客户，因为没有相同的账目。B说客户没付钱，那这样就不是客户体验度的问题了。
4、负载均衡的原理是什么？
当客户端发起请求时，请求直接发给Director Server（调度器），这时会根据设定的调度算法，将请求按照算法的规定智能的分发到真正的后台服务器。以达到将压力均摊。但是我们知道，http的连接时无状态的，假设这样一个场景，我登录某宝买东西，当我看上某款商品时，我将它加入购物车，但是我刷新了一下页面，这时由于负载均衡的原因，调度器又选了新的一台服务器为我提供服务，我刚才的购物车内容全都不见了，这样就会有十分差的用户体验。所以就还需要一个存储共享，这样就保证了用户请求的数据是一样的
当客户端发起请求时，请求直接发给Director Server（调度器），这时会根据设定的调度算法，将请求按照算法的规定智能的分发到真正的后台服务器。以达到将压力均摊。但是我们知道，http的连接时无状态的，假设这样一个场景，我登录某宝买东西，当我看上某款商品时，我将它加入购物车，但是我刷新了一下页面，这时由于负载均衡的原因，调度器又选了新的一台服务器为我提供服务，我刚才的购物车内容全都不见了，这样就会有十分差的用户体验。所以就还需要一个存储共享，这样就保证了用户请求的数据是一样的
5、LVS由哪两部分组成的？
LVS 由2部分程序组成，包括 ipvs 和 ipvsadm。
1、ipvs(ip virtual server)：一段代码工作在内核空间，叫ipvs，是真正生效实现调度的代码。
2.、ipvsadm：另外一段是工作在用户空间，叫ipvsadm，负责为ipvs内核框架编写规则，定义谁是集群服务，而谁是后端真实的服务器(Real Server)
1、ipvs(ip virtual server)：一段代码工作在内核空间，叫ipvs，是真正生效实现调度的代码。
2.、ipvsadm：另外一段是工作在用户空间，叫ipvsadm，负责为ipvs内核框架编写规则，定义谁是集群服务，而谁是后端真实的服务器(Real Server)
6、 与lvs相关的术语有哪些？
DS：Director Server。指的是前端负载均衡器节点。
RS：Real Server。后端真实的工作服务器。
VIP：Virtual IP 向外部直接面向用户请求，作为用户请求的目标的IP地址。
DIP：Director Server IP，主要用于和内部主机通讯的IP地址。
RIP：Real Server IP，后端服务器的IP地址。
CIP：Client IP，访问客户端的IP地址。
DS：Director Server。指的是前端负载均衡器节点。
RS：Real Server。后端真实的工作服务器。
VIP：Virtual IP 向外部直接面向用户请求，作为用户请求的目标的IP地址。
DIP：Director Server IP，主要用于和内部主机通讯的IP地址。
RIP：Real Server IP，后端服务器的IP地址。
CIP：Client IP，访问客户端的IP地址。
7、LVS-NAT模式的原理
原理图：
图释
(a). 当用户请求到达Director Server，此时请求的数据报文会先到内核空间的PREROUTING链。此时报文的源IP为CIP，目标IP为VIP
(b). PREROUTING检查发现数据包的目标IP是本机，将数据包送至INPUT链
(c). IPVS比对数据包请求的服务是否为集群服务，若是，修改数据包的目标IP地址为后端服务器IP， 然后将数据包发至POSTROUTING链。 此时报文的源IP为CIP，目标IP为RIP
(d). POSTROUTING链通过选路，将数据包发送给Real Server
(e). Real Server比对发现目标为自己的IP，开始构建响应报文发回给Director Server。 此时报文的源IP为RIP，目标IP为CIP
(f). Director Server在响应客户端前，此时会将源IP地址修改为自己的VIP地址，然后响应给客户端。 此时报文的源IP为VIP，目标IP为CIP
(a). 当用户请求到达Director Server，此时请求的数据报文会先到内核空间的PREROUTING链。此时报文的源IP为CIP，目标IP为VIP
(b). PREROUTING检查发现数据包的目标IP是本机，将数据包送至INPUT链
(c). IPVS比对数据包请求的服务是否为集群服务，若是，修改数据包的目标IP地址为后端服务器IP， 然后将数据包发至POSTROUTING链。 此时报文的源IP为CIP，目标IP为RIP
(d). POSTROUTING链通过选路，将数据包发送给Real Server
(e). Real Server比对发现目标为自己的IP，开始构建响应报文发回给Director Server。 此时报文的源IP为RIP，目标IP为CIP
(f). Director Server在响应客户端前，此时会将源IP地址修改为自己的VIP地址，然后响应给客户端。 此时报文的源IP为VIP，目标IP为CIP
8、LVS-NAT模型的特性
RS应该使用私有地址，RS的网关必须指向DIP
DIP和RIP必须在同一个网段内
请求和响应报文都需要经过Director Server，高负载场景中，Director Server易成为性能瓶颈
支持端口映射
RS可以使用任意操作系统
缺陷：对Director Server压力会比较大，请求和响应都需经过director server
RS应该使用私有地址，RS的网关必须指向DIP
DIP和RIP必须在同一个网段内
请求和响应报文都需要经过Director Server，高负载场景中，Director Server易成为性能瓶颈
支持端口映射
RS可以使用任意操作系统
缺陷：对Director Server压力会比较大，请求和响应都需经过director server
9、LVS-DR模式原理
原理图：
图释
(a) 当用户请求到达Director Server，此时请求的数据报文会先到内核空间的PREROUTING链。 此时报文的源IP为CIP，目标IP为VIP
(b) PREROUTING检查发现数据包的目标IP是本机，将数据包送至INPUT链
(c) IPVS比对数据包请求的服务是否为集群服务，若是，将请求报文中的源MAC地址修改为DIP的MAC地址，将目标MAC地址修改RIP的MAC地址，然后将数据包发至POSTROUTING链。 此时的源IP和目的IP均未修改，仅修改了源MAC地址为DIP的MAC地址，目标MAC地址为RIP的MAC地址
(d) 由于DS和RS在同一个网络中，所以是通过二层来传输。POSTROUTING链检查目标MAC地址为RIP的MAC地址，那么此时数据包将会发至Real Server。
(e) RS发现请求报文的MAC地址是自己的MAC地址，就接收此报文。处理完成之后，将响应报文通过lo接口传送给eth0网卡然后向外发出。 此时的源IP地址为VIP，目标IP为CIP
(f) 响应报文最终送达至客户端
(a) 当用户请求到达Director Server，此时请求的数据报文会先到内核空间的PREROUTING链。 此时报文的源IP为CIP，目标IP为VIP
(b) PREROUTING检查发现数据包的目标IP是本机，将数据包送至INPUT链
(c) IPVS比对数据包请求的服务是否为集群服务，若是，将请求报文中的源MAC地址修改为DIP的MAC地址，将目标MAC地址修改RIP的MAC地址，然后将数据包发至POSTROUTING链。 此时的源IP和目的IP均未修改，仅修改了源MAC地址为DIP的MAC地址，目标MAC地址为RIP的MAC地址
(d) 由于DS和RS在同一个网络中，所以是通过二层来传输。POSTROUTING链检查目标MAC地址为RIP的MAC地址，那么此时数据包将会发至Real Server。
(e) RS发现请求报文的MAC地址是自己的MAC地址，就接收此报文。处理完成之后，将响应报文通过lo接口传送给eth0网卡然后向外发出。 此时的源IP地址为VIP，目标IP为CIP
(f) 响应报文最终送达至客户端
10、LVS-DR模型的特性
特点：保证前端路由将目标地址为VIP报文统统发给Director Server，而不是RS
RS可以使用私有地址；也可以是公网地址，如果使用公网地址，此时可以通过互联网对RIP进行直接访问
RS跟Director Server必须在同一个物理网络中
所有的请求报文经由Director Server，但响应报文必须不能进过Director Server
不支持地址转换，也不支持端口映射
RS可以是大多数常见的操作系统
RS的网关绝不允许指向DIP(因为我们不允许他经过director)
RS上的lo接口配置VIP的IP地址
缺陷：RS和DS必须在同一机房中
特点：保证前端路由将目标地址为VIP报文统统发给Director Server，而不是RS
RS可以使用私有地址；也可以是公网地址，如果使用公网地址，此时可以通过互联网对RIP进行直接访问
RS跟Director Server必须在同一个物理网络中
所有的请求报文经由Director Server，但响应报文必须不能进过Director Server
不支持地址转换，也不支持端口映射
RS可以是大多数常见的操作系统
RS的网关绝不允许指向DIP(因为我们不允许他经过director)
RS上的lo接口配置VIP的IP地址
缺陷：RS和DS必须在同一机房中
11、LVS三种负载均衡模式的比较
三种负载均衡： nat，tunneling，dr
|类目|NAT|TUN|DR|
|--|--|--|--|
操作系统|任意|支持隧道|多数（支持non-arp）
|服务器网络|私有网络|局域网/广域网|局域网
|服务器数目|10-20|100|大于100
|服务器网关|负载均衡器|自己的路由|自己的路由|
效率|一般|高|最高
三种负载均衡： nat，tunneling，dr
|类目|NAT|TUN|DR|
|--|--|--|--|
操作系统|任意|支持隧道|多数（支持non-arp）
|服务器网络|私有网络|局域网/广域网|局域网
|服务器数目|10-20|100|大于100
|服务器网关|负载均衡器|自己的路由|自己的路由|
效率|一般|高|最高
12、LVS的负载调度算法
轮叫调度
加权轮叫调度
最小连接调度
加权最小连接调度
基于局部性能的最少连接
带复制的基于局部性能最小连接
目标地址散列调度
源地址散列调度
轮叫调度
加权轮叫调度
最小连接调度
加权最小连接调度
基于局部性能的最少连接
带复制的基于局部性能最小连接
目标地址散列调度
源地址散列调度
13、LVS与nginx的区别
lvs的优势
1. 抗负载能力强，因为lvs工作方式的逻辑是非常简单的，而且工作在网络的第4层，仅作请求分发用，没有流量，所以在效率上基本不需要太过考虑。lvs一般很少出现故障，即使出现故障一般也是其他地方（如内存、CPU等）出现问题导致lvs出现问题。
2.配置性低，这通常是一大劣势同时也是一大优势，因为没有太多的可配置的选项，所以除了增减服务器，并不需要经常去触碰它，大大减少了人为出错的几率。
3.工作稳定，因为其本身抗负载能力很强，所以稳定性高也是顺理成章的事，另外各种lvs都有完整的双机热备方案，所以一点不用担心均衡器本身会出什么问题，节点出现故障的话，lvs会自动判别，所以系统整体是非常稳定的。
4.无流量，lvs仅仅分发请求，而流量并不从它本身出去，所以可以利用它这点来做一些线路分流之用。没有流量同时也保住了均衡器的IO性能不会受到大流量的影响。
5.lvs基本上能支持所有应用，因为lvs工作在第4层，所以它可以对几乎所有应用做负载均衡，包括http、数据库、聊天室等。
1. 抗负载能力强，因为lvs工作方式的逻辑是非常简单的，而且工作在网络的第4层，仅作请求分发用，没有流量，所以在效率上基本不需要太过考虑。lvs一般很少出现故障，即使出现故障一般也是其他地方（如内存、CPU等）出现问题导致lvs出现问题。
2.配置性低，这通常是一大劣势同时也是一大优势，因为没有太多的可配置的选项，所以除了增减服务器，并不需要经常去触碰它，大大减少了人为出错的几率。
3.工作稳定，因为其本身抗负载能力很强，所以稳定性高也是顺理成章的事，另外各种lvs都有完整的双机热备方案，所以一点不用担心均衡器本身会出什么问题，节点出现故障的话，lvs会自动判别，所以系统整体是非常稳定的。
4.无流量，lvs仅仅分发请求，而流量并不从它本身出去，所以可以利用它这点来做一些线路分流之用。没有流量同时也保住了均衡器的IO性能不会受到大流量的影响。
5.lvs基本上能支持所有应用，因为lvs工作在第4层，所以它可以对几乎所有应用做负载均衡，包括http、数据库、聊天室等。
nginx与LVS的对比：
1、nginx工作在网络的第7层，所以它可以针对http应用本身来做分流策略，比如针对域名、目录结构等，相比之下lvs并不具这样的功能，所以nginx单凭这点可以利用的场合就远多于lvs了；但nginx有用的这些功能使其可调整度要高于lvs，所以经常要去触碰，由lvs的第2条优点来看，触碰多了，人为出现问题的几率也就会大。
2、nginx对网络的依赖较小，理论上只要ping得通，网页访问正常，nginx就能连得通，nginx同时还能区分内外网，如果是同时拥有内外网的节点，就相当于单机拥有了备份线路；lvs就比较依赖于网络环境，目前来看服务器在同一网段内并且lvs使用direct方式分流，效果较能得到保证。另外注意，lvs需要向托管商至少申请多于一个ip来做visual ip。
3、nginx安装和配置比较简单，测试起来也很方便，因为它基本能把错误用日志打印出来。lvs的安装和配置、测试就要花比较长的时间，因为同上所述，lvs对网络依赖性比较大，很多时候不能配置成功都是因为网络问题而不是配置问题，出了问题要解决也相应的会麻烦的多。
4、nginx也同样能承受很高负载且稳定，但负载度和稳定度差lvs还有几个等级：nginx处理所有流量；所以受限于机器IO和配置；本身的bug也还是难以避免的；nginx没有现成的双机热备方案，所以跑在单机上还是风险比较大，单机上的事情全都很难说。
5、nginx可以检测到服务器内部的故障，比如根据服务器处理网页返回的状态码、超时等等，并且会把返回错误的请求重新提交到另一个节点。目前lvs中ldirectd也能支持针对服务器内部的情况来监控，但lvs的原理使其不能重发请求。比如用户正在上传一个文件，而处理该上传的节点刚好在上传过程中出现故障，nginx会把上传切到另一台服务器重新处理，而lvs就直接断掉了。
1、nginx工作在网络的第7层，所以它可以针对http应用本身来做分流策略，比如针对域名、目录结构等，相比之下lvs并不具这样的功能，所以nginx单凭这点可以利用的场合就远多于lvs了；但nginx有用的这些功能使其可调整度要高于lvs，所以经常要去触碰，由lvs的第2条优点来看，触碰多了，人为出现问题的几率也就会大。
2、nginx对网络的依赖较小，理论上只要ping得通，网页访问正常，nginx就能连得通，nginx同时还能区分内外网，如果是同时拥有内外网的节点，就相当于单机拥有了备份线路；lvs就比较依赖于网络环境，目前来看服务器在同一网段内并且lvs使用direct方式分流，效果较能得到保证。另外注意，lvs需要向托管商至少申请多于一个ip来做visual ip。
3、nginx安装和配置比较简单，测试起来也很方便，因为它基本能把错误用日志打印出来。lvs的安装和配置、测试就要花比较长的时间，因为同上所述，lvs对网络依赖性比较大，很多时候不能配置成功都是因为网络问题而不是配置问题，出了问题要解决也相应的会麻烦的多。
4、nginx也同样能承受很高负载且稳定，但负载度和稳定度差lvs还有几个等级：nginx处理所有流量；所以受限于机器IO和配置；本身的bug也还是难以避免的；nginx没有现成的双机热备方案，所以跑在单机上还是风险比较大，单机上的事情全都很难说。
5、nginx可以检测到服务器内部的故障，比如根据服务器处理网页返回的状态码、超时等等，并且会把返回错误的请求重新提交到另一个节点。目前lvs中ldirectd也能支持针对服务器内部的情况来监控，但lvs的原理使其不能重发请求。比如用户正在上传一个文件，而处理该上传的节点刚好在上传过程中出现故障，nginx会把上传切到另一台服务器重新处理，而lvs就直接断掉了。
两者配合使用：
1、nginx用来做http的反向代理，能够upsteam实现http请求的多种方式的均衡转发。由于采用的是异步转发可以做到如果一个服务器请求失败，立即切换到其他服务器，直到请求成功或者最后一台服务器失败为止。这可以最大程度的提高系统的请求成功率。
2、lvs采用的是同步请求转发的策略。这里说一下同步转发和异步转发的区别。同步转发是在lvs服务器接收到请求之后，立即redirect到一个后端服务器，由客户端直接和后端服务器建立连接。异步转发是nginx在保持客户端连接的同时，发起一个相同内容的新请求到后端，等后端返回结果后，由nginx返回给客户端。
3、进一步来说：当做为负载均衡服务器的nginx和lvs处理相同的请求时，所有的请求和响应流量都会经过nginx；但是使用lvs时，仅请求流量经过lvs的网络，响应流量由后端服务器的网络返回。也就是，当作为后端的服务器规模庞大时，nginx的网络带宽就成了一个巨大的瓶颈。但是仅仅使用lvs作为负载均衡的话，一旦后端接受到请求的服务器出了问题，那么这次请求就失败了。但是如果在lvs的后端在添加一层nginx（多个），每个nginx后端再有几台应用服务器，那么结合两者的优势，既能避免单nginx的流量集中瓶颈，又能避免单lvs时一锤子买卖的问题。
1、nginx用来做http的反向代理，能够upsteam实现http请求的多种方式的均衡转发。由于采用的是异步转发可以做到如果一个服务器请求失败，立即切换到其他服务器，直到请求成功或者最后一台服务器失败为止。这可以最大程度的提高系统的请求成功率。
2、lvs采用的是同步请求转发的策略。这里说一下同步转发和异步转发的区别。同步转发是在lvs服务器接收到请求之后，立即redirect到一个后端服务器，由客户端直接和后端服务器建立连接。异步转发是nginx在保持客户端连接的同时，发起一个相同内容的新请求到后端，等后端返回结果后，由nginx返回给客户端。
3、进一步来说：当做为负载均衡服务器的nginx和lvs处理相同的请求时，所有的请求和响应流量都会经过nginx；但是使用lvs时，仅请求流量经过lvs的网络，响应流量由后端服务器的网络返回。也就是，当作为后端的服务器规模庞大时，nginx的网络带宽就成了一个巨大的瓶颈。但是仅仅使用lvs作为负载均衡的话，一旦后端接受到请求的服务器出了问题，那么这次请求就失败了。但是如果在lvs的后端在添加一层nginx（多个），每个nginx后端再有几台应用服务器，那么结合两者的优势，既能避免单nginx的流量集中瓶颈，又能避免单lvs时一锤子买卖的问题。
14、负载均衡的作用有哪些？
转发功能
按照一定的算法【权重、轮询】，将客户端请求转发到不同应用服务器上，减轻单个服务器压力，提高系统并发量。
按照一定的算法【权重、轮询】，将客户端请求转发到不同应用服务器上，减轻单个服务器压力，提高系统并发量。
故障移除
通过心跳检测的方式，判断应用服务器当前是否可以正常工作，如果服务器期宕掉，自动将请求发送到其他应用服务器。
通过心跳检测的方式，判断应用服务器当前是否可以正常工作，如果服务器期宕掉，自动将请求发送到其他应用服务器。
恢复添加
如检测到发生故障的应用服务器恢复工作，自动将其添加到处理用户请求队伍中。
如检测到发生故障的应用服务器恢复工作，自动将其添加到处理用户请求队伍中。
15、nginx实现负载均衡的分发策略
Nginx 的 upstream目前支持的分配算法：
轮询 ——1：1 轮流处理请求（默认）
每个请求按时间顺序逐一分配到不同的应用服务器，如果应用服务器down掉，自动剔除，剩下的继续轮询。
每个请求按时间顺序逐一分配到不同的应用服务器，如果应用服务器down掉，自动剔除，剩下的继续轮询。
权重 ——you can you up
通过配置权重，指定轮询几率，权重和访问比率成正比，用于应用服务器性能不均的情况。
通过配置权重，指定轮询几率，权重和访问比率成正比，用于应用服务器性能不均的情况。
ip_哈希算法
每个请求按访问ip的hash结果分配，这样每个访客固定访问一个应用服务器，可以解决session共享的问题。
每个请求按访问ip的hash结果分配，这样每个访客固定访问一个应用服务器，可以解决session共享的问题。
16、keepalived 是什么？
广义上讲是高可用，狭义上讲是主机的冗余和管理
1、Keepalived起初是为LVS设计的，专门用来监控集群系统中各个服务节点的状态，它根据TCP/IP参考模型的第三、第四层、第五层交换机制检测每个服务节点的状态，如果某个服务器节点出现异常，或者工作出现故障，Keepalived将检测到，并将出现的故障的服务器节点从集群系统中剔除，这些工作全部是自动完成的，不需要人工干涉，需要人工完成的只是修复出现故障的服务节点。
2、后来Keepalived又加入了VRRP的功能，VRRP（VritrualRouterRedundancyProtocol,虚拟路由冗余协议)出现的目的是解决静态路由出现的单点故障问题，通过VRRP可以实现网络不间断稳定运行，因此Keepalvied一方面具有服务器状态检测和故障隔离功能，另外一方面也有HAcluster功能。
3、所以keepalived的核心功能就是健康检查和失败且换。
所谓的健康检查，就是采用tcp三次握手，icmp请求，http请求，udp echo请求等方式对负载均衡器后面的实际的服务器(通常是承载真实业务的服务器)进行保活；而失败切换主要是应用于配置了主备模式的负载均衡器，利用VRRP维持主备负载均衡器的心跳，当主负载均衡器出现问题时，由备负载均衡器承载对应的业务，从而在最大限度上减少流量损失，并提供服务的稳定性
1、Keepalived起初是为LVS设计的，专门用来监控集群系统中各个服务节点的状态，它根据TCP/IP参考模型的第三、第四层、第五层交换机制检测每个服务节点的状态，如果某个服务器节点出现异常，或者工作出现故障，Keepalived将检测到，并将出现的故障的服务器节点从集群系统中剔除，这些工作全部是自动完成的，不需要人工干涉，需要人工完成的只是修复出现故障的服务节点。
2、后来Keepalived又加入了VRRP的功能，VRRP（VritrualRouterRedundancyProtocol,虚拟路由冗余协议)出现的目的是解决静态路由出现的单点故障问题，通过VRRP可以实现网络不间断稳定运行，因此Keepalvied一方面具有服务器状态检测和故障隔离功能，另外一方面也有HAcluster功能。
3、所以keepalived的核心功能就是健康检查和失败且换。
所谓的健康检查，就是采用tcp三次握手，icmp请求，http请求，udp echo请求等方式对负载均衡器后面的实际的服务器(通常是承载真实业务的服务器)进行保活；而失败切换主要是应用于配置了主备模式的负载均衡器，利用VRRP维持主备负载均衡器的心跳，当主负载均衡器出现问题时，由备负载均衡器承载对应的业务，从而在最大限度上减少流量损失，并提供服务的稳定性
17、你是如何理解VRRP协议的
为什么使用VRRP？
主机之间的通信都是通过配置静态路由或者(默认网关)来完成的，而主机之间的路由器一旦发生故障，通信就会失效，因此这种通信模式当中，路由器就成了一个单点瓶颈，为了解决这个问题，就引入了VRRP协议。
VRRP协议是一种容错的主备模式的协议，保证当主机的下一跳路由出现故障时，由另一台路由器来代替出现故障的路由器进行工作，通过VRRP可以在网络发生故障时透明的进行设备切换而不影响主机之间的数据通信。
主机之间的通信都是通过配置静态路由或者(默认网关)来完成的，而主机之间的路由器一旦发生故障，通信就会失效，因此这种通信模式当中，路由器就成了一个单点瓶颈，为了解决这个问题，就引入了VRRP协议。
VRRP协议是一种容错的主备模式的协议，保证当主机的下一跳路由出现故障时，由另一台路由器来代替出现故障的路由器进行工作，通过VRRP可以在网络发生故障时透明的进行设备切换而不影响主机之间的数据通信。
VRRP的三种状态：
VRRP路由器在运行过程中有三种状态：
1. Initialize状态： 系统启动后就进入Initialize，此状态下路由器不对VRRP报文做任何处理；
2. Master状态；
3. Backup状态；
一般主路由器处于Master状态，备份路由器处于Backup状态。
VRRP路由器在运行过程中有三种状态：
1. Initialize状态： 系统启动后就进入Initialize，此状态下路由器不对VRRP报文做任何处理；
2. Master状态；
3. Backup状态；
一般主路由器处于Master状态，备份路由器处于Backup状态。
18、keepalived的工作原理？
keepalived采用是模块化设计，不同模块实现不同的功能。
keepalived主要有三个模块，分别是core、check和vrrp。
core：是keepalived的核心，负责主进程的启动和维护，全局配置文件的加载解析等
check： 负责healthchecker(健康检查)，包括了各种健康检查方式，以及对应的配置的解析包括LVS的配置解析；可基于脚本检查对IPVS后端服务器健康状况进行检查
vrrp：VRRPD子进程，VRRPD子进程就是来实现VRRP协议的
Keepalived高可用对之间是通过 VRRP进行通信的， VRRP是通过竞选机制来确定主备的，主的优先级高于备，因此，工作时主会优先获得所有的资源，备节点处于等待状态，当主宕机的时候，备节点就会接管主节点的资源，然后顶替主节点对外提供服务在Keepalived服务对之间，只有作为主的服务器会一直发送 VRRP广播包,告诉备它还活着，此时备不会抢占主，当主不可用时，即备监听不到主发送的广播包时，就会启动相关服务接管资源，保证业务的连续性.接管速度最快
keepalived主要有三个模块，分别是core、check和vrrp。
core：是keepalived的核心，负责主进程的启动和维护，全局配置文件的加载解析等
check： 负责healthchecker(健康检查)，包括了各种健康检查方式，以及对应的配置的解析包括LVS的配置解析；可基于脚本检查对IPVS后端服务器健康状况进行检查
vrrp：VRRPD子进程，VRRPD子进程就是来实现VRRP协议的
Keepalived高可用对之间是通过 VRRP进行通信的， VRRP是通过竞选机制来确定主备的，主的优先级高于备，因此，工作时主会优先获得所有的资源，备节点处于等待状态，当主宕机的时候，备节点就会接管主节点的资源，然后顶替主节点对外提供服务在Keepalived服务对之间，只有作为主的服务器会一直发送 VRRP广播包,告诉备它还活着，此时备不会抢占主，当主不可用时，即备监听不到主发送的广播包时，就会启动相关服务接管资源，保证业务的连续性.接管速度最快
19、出现脑裂的原因
什么是脑裂？
在高可用（HA）系统中，当联系2个节点的“心跳线”断开时，本来为一整体、动作协调的HA系统，就分裂成为2个独立的个体。
由于相互失去了联系，都以为是对方出了故障。两个节点上的HA软件像“裂脑人”一样，争抢“共享资源”、争起“应用服务”，就会发生严重后果。共享资源被瓜分、两边“服务”都起不来了；或者两边“服务”都起来了，但同时读写“共享存储”，导致数据损坏
在高可用（HA）系统中，当联系2个节点的“心跳线”断开时，本来为一整体、动作协调的HA系统，就分裂成为2个独立的个体。
由于相互失去了联系，都以为是对方出了故障。两个节点上的HA软件像“裂脑人”一样，争抢“共享资源”、争起“应用服务”，就会发生严重后果。共享资源被瓜分、两边“服务”都起不来了；或者两边“服务”都起来了，但同时读写“共享存储”，导致数据损坏
都有哪些原因导致脑裂？
高可用服务器对之间心跳线链路发生故障，导致无法正常通信。
因心跳线坏了（包括断了，老化）。
因网卡及相关驱动坏了，ip配置及冲突问题（网卡直连）
因心跳线间连接的设备故障（网卡及交换机）
因仲裁的机器出问题（采用仲裁的方案）
高可用服务器上开启了 iptables防火墙阻挡了心跳消息传输。
高可用服务器上心跳网卡地址等信息配置不正确，导致发送心跳失败
其他服务配置不当等原因，如心跳方式不同，心跳广插冲突、软件Bug等。
高可用服务器对之间心跳线链路发生故障，导致无法正常通信。
因心跳线坏了（包括断了，老化）。
因网卡及相关驱动坏了，ip配置及冲突问题（网卡直连）
因心跳线间连接的设备故障（网卡及交换机）
因仲裁的机器出问题（采用仲裁的方案）
高可用服务器上开启了 iptables防火墙阻挡了心跳消息传输。
高可用服务器上心跳网卡地址等信息配置不正确，导致发送心跳失败
其他服务配置不当等原因，如心跳方式不同，心跳广插冲突、软件Bug等。
20、如何解决keepalived脑裂问题？
在实际生产环境中，我们从以下方面防止脑裂：
1、同时使用串行电缆和以太网电缆连接、同时使用两条心跳线路，这样一条线路断了，另外一条还是好的，依然能传送心跳消息
2、当检查脑裂时强行关闭一个心跳节点（这个功能需要特殊设备支持，如stonith、fence）相当于备节点接收不到心跳消息，通过单独的线路发送关机命令关闭主节点的电源
3、做好对脑裂的监控报警
解决常见方案：
1、如果开启防火墙，一定要让心跳消息通过，一般通过允许IP段的形式解决
2、可以拉一条以太网网线或者串口线作为主被节点心跳线路的冗余
3、开发检测程序通过监控软件检测脑裂
1、同时使用串行电缆和以太网电缆连接、同时使用两条心跳线路，这样一条线路断了，另外一条还是好的，依然能传送心跳消息
2、当检查脑裂时强行关闭一个心跳节点（这个功能需要特殊设备支持，如stonith、fence）相当于备节点接收不到心跳消息，通过单独的线路发送关机命令关闭主节点的电源
3、做好对脑裂的监控报警
解决常见方案：
1、如果开启防火墙，一定要让心跳消息通过，一般通过允许IP段的形式解决
2、可以拉一条以太网网线或者串口线作为主被节点心跳线路的冗余
3、开发检测程序通过监控软件检测脑裂
21、zabbix如何监控脑裂？
监控只是监控发生脑裂的可能性，不能保证一定是发生了脑裂，因为正常的主备切换VIP也是会到备上的
监控脚本：
mkdir -p /scripts && cd /scripts
vim check_keepalived.sh
#!/bin/bash
if [ `ip a show ens33 |grep 192.168.32.250|wc -l` -ne 0 ]
then
echo "keepalived is error!"
else
echo "keepalived is OK !"
fi
监控脚本：
mkdir -p /scripts && cd /scripts
vim check_keepalived.sh
#!/bin/bash
if [ `ip a show ens33 |grep 192.168.32.250|wc -l` -ne 0 ]
then
echo "keepalived is error!"
else
echo "keepalived is OK !"
fi
截图：
截图：
22、nginx做负载均衡实现的策略有哪些
轮询（默认）
权重
ip_hash
fair(第三方插件）
url_hash（第三方插件）
轮询（默认）
权重
ip_hash
fair(第三方插件）
url_hash（第三方插件）
23、nginx做负载均衡用到哪些模块
upstream 定义负载节点池。
location 模块 进行URL匹配。
proxy模块 发送请求给upstream定义的节点池。
upstream 定义负载节点池。
location 模块 进行URL匹配。
proxy模块 发送请求给upstream定义的节点池。
24、负载均衡有哪些实现方式
硬件负载
HTTP重定向负载均衡
DNS负载均衡
反向代理负载均衡
IP层负载均衡
数据链路层负载均衡
一般常用的DNS负载均衡或者数据链路层负载均衡：思维导图地址：https://www.processon.com/mindmap/649686acc51e5f5150530d0a
硬件负载
HTTP重定向负载均衡
DNS负载均衡
反向代理负载均衡
IP层负载均衡
数据链路层负载均衡
一般常用的DNS负载均衡或者数据链路层负载均衡：思维导图地址：https://www.processon.com/mindmap/649686acc51e5f5150530d0a
25、nginx如何实现四层负载？
四层负载分为动态和静态负载
Nginx的四层静态负载均衡需要启用ngx_stream_core_module模块
默认情况下，ngx_stream_core_module是没有启用的，需要在安装Nginx时，添加--with-stream配置参数启用配置HTTP负载均衡时，都是配置在http指令下，配置四层负载均衡，则是在stream指令下，
Nginx的四层静态负载均衡需要启用ngx_stream_core_module模块
默认情况下，ngx_stream_core_module是没有启用的，需要在安装Nginx时，添加--with-stream配置参数启用配置HTTP负载均衡时，都是配置在http指令下，配置四层负载均衡，则是在stream指令下，
结构如下所示.
stream {
upstream mysql_backend {
server 192.168.175.100:3306 max_fails=2 fail_timeout=10s weight=1;
least_conn;
}
server { #监听端口，默认使用的是tcp协议，如果需要UDP协议，则配置成listen 3307 udp;
listen 3307; #失败重试 proxy_next_upstream on;
proxy_next_upstream_timeout 0;
proxy_next_upstream_tries 0; #超时配置 #配置与上游服务器连接超时时间，默认60s
proxy_connect_timeout 1s; #配置与客户端上游服务器连接的两次成功读/写操作的超时时间，如果超
时，将自动断开连接 #即连接存活时间，通过它可以释放不活跃的连接，默认10分钟 proxy_timeout 1m;
#限速配置 #从客户端读数据的速率，单位为每秒字节数，默认为0，不限速 proxy_upload_rate 0; #从
上游服务器读数据的速率，单位为每秒字节数，默认为0，不限速 proxy_download_rate 0; #上游服务器
proxy_pass mysql_backend;
}
}
使用Nginx的四层动态负载均衡有两种方案：使用商业版的Nginx和使用开源的nginx-stream-upsyncmodule模块。注意：四层动态负载均衡可以使用nginx-stream-upsync-module模块，七层动态负载均衡可以使用nginx-upsync-module模块。
stream {
upstream mysql_backend {
server 192.168.175.100:3306 max_fails=2 fail_timeout=10s weight=1;
least_conn;
}
server { #监听端口，默认使用的是tcp协议，如果需要UDP协议，则配置成listen 3307 udp;
listen 3307; #失败重试 proxy_next_upstream on;
proxy_next_upstream_timeout 0;
proxy_next_upstream_tries 0; #超时配置 #配置与上游服务器连接超时时间，默认60s
proxy_connect_timeout 1s; #配置与客户端上游服务器连接的两次成功读/写操作的超时时间，如果超
时，将自动断开连接 #即连接存活时间，通过它可以释放不活跃的连接，默认10分钟 proxy_timeout 1m;
#限速配置 #从客户端读数据的速率，单位为每秒字节数，默认为0，不限速 proxy_upload_rate 0; #从
上游服务器读数据的速率，单位为每秒字节数，默认为0，不限速 proxy_download_rate 0; #上游服务器
proxy_pass mysql_backend;
}
}
使用Nginx的四层动态负载均衡有两种方案：使用商业版的Nginx和使用开源的nginx-stream-upsyncmodule模块。注意：四层动态负载均衡可以使用nginx-stream-upsync-module模块，七层动态负载均衡可以使用nginx-upsync-module模块。
26、你知道的web服务有哪些？
apache
nginx
IIS
tomcat
lighttpd
weblogic
apache
nginx
IIS
tomcat
lighttpd
weblogic
27、为什么要用nginx
跨平台、配置简单，非阻塞、高并发连接：处理2-3万并发连接数，官方监测能支持5万并发，
内存消耗小：开启10个nginx才占150M内存 ，nginx处理静态文件好,耗费内存少,
内置的健康检查功能：如果有一个服务器宕机，会做一个健康检查，再发送的请求就不会发送到宕
机的服务器了。重新将请求提交到其他的节点上。
节省宽带：支持GZIP压缩，可以添加浏览器本地缓存
稳定性高：宕机的概率非常小
接收用户请求是异步的
跨平台、配置简单，非阻塞、高并发连接：处理2-3万并发连接数，官方监测能支持5万并发，
内存消耗小：开启10个nginx才占150M内存 ，nginx处理静态文件好,耗费内存少,
内置的健康检查功能：如果有一个服务器宕机，会做一个健康检查，再发送的请求就不会发送到宕
机的服务器了。重新将请求提交到其他的节点上。
节省宽带：支持GZIP压缩，可以添加浏览器本地缓存
稳定性高：宕机的概率非常小
接收用户请求是异步的
28、 nginx的性能为什么比apache高？
nginx采用的是epoll模型和kqueue网络模型，而apache采用的是select模型
举一个例子来解释两种模型的区别：
菜鸟驿站放着很多快件，以前去拿快件都是短信通知你有快件，然后你去了之后，负责菜鸟驿站的人在
一堆快递里帮你找，直到找到为止。
但现在菜鸟驿站的方式变了，他会发你一个地址，比如 3-3-5009. 这个就是第三个货架的第三排，从做往右第九个。
如果有几百个人同时去找快递，这两种方式哪个更有效率，不言而喻。
之前还看到这个例子也比较形象：
假设你在大学读书，住的宿舍楼有很多间房间，你的朋友要来找你。
select版宿管大妈就会带着你的朋友挨个房间去找，直到找到你为止。
而epoll版宿管大妈会先记下每位同学的房间号，你的朋友来时，只需告诉你的朋友你住在哪个房间即可，不用亲自带着你的朋友满大楼找人。
如果来了10000个人，都要找自己住这栋楼的同学时，select版和epoll版宿管大妈，谁的效率更高，不言自明。
同理，在高并发服务器中，轮询I/O是最耗时间的操作之一，select和epoll的性能谁的性能更高，同样十分明了
select 采用的是轮询的方式来处理请求，轮询的次数越多，耗时也就越多。
举一个例子来解释两种模型的区别：
菜鸟驿站放着很多快件，以前去拿快件都是短信通知你有快件，然后你去了之后，负责菜鸟驿站的人在
一堆快递里帮你找，直到找到为止。
但现在菜鸟驿站的方式变了，他会发你一个地址，比如 3-3-5009. 这个就是第三个货架的第三排，从做往右第九个。
如果有几百个人同时去找快递，这两种方式哪个更有效率，不言而喻。
之前还看到这个例子也比较形象：
假设你在大学读书，住的宿舍楼有很多间房间，你的朋友要来找你。
select版宿管大妈就会带着你的朋友挨个房间去找，直到找到你为止。
而epoll版宿管大妈会先记下每位同学的房间号，你的朋友来时，只需告诉你的朋友你住在哪个房间即可，不用亲自带着你的朋友满大楼找人。
如果来了10000个人，都要找自己住这栋楼的同学时，select版和epoll版宿管大妈，谁的效率更高，不言自明。
同理，在高并发服务器中，轮询I/O是最耗时间的操作之一，select和epoll的性能谁的性能更高，同样十分明了
select 采用的是轮询的方式来处理请求，轮询的次数越多，耗时也就越多。
29、epoll的组成
epoll的接口非常简单，一共就三个函数：
1. int epoll_create(int size);
创建一个epoll的句柄，size用来告诉内核这个监听的数目一共有多大。这个参数不同于select()中的第一个参数，给出最大监听的fd+1的值。需要注意的是，当创建好epoll句柄后，它就是会占用一个fd值，在linux下如果查看/proc/进程id/fd/，是能够看到这个fd的，所以在使用完epoll后，必须调用close()关闭，否则可能导致fd被耗尽。
2. int epoll_ctl(int epfd, int op, int fd, struct epoll_event *event);
epoll的事件注册函数，它不同与select()是在监听事件时告诉内核要监听什么类型的事件，而是在这里先注册要监听的事件类型。第一个参数是epoll_create()的返回值，第二个参数表示动作，用三个宏来表示：
EPOLL_CTL_ADD：注册新的fd到epfd中；EPOLL_CTL_MOD：修改已经注册的fd的监听事件；EPOLL_CTL_DEL：从epfd中删除一个fd；第三个参数是需要监听的fd，第四个参数是告诉内核需要监听什么事
3. int epoll_wait(int epfd, struct epoll_event * events, int maxevents, inttimeout);
等待事件的产生，类似于select()调用。参数events用来从内核得到事件的集合，maxevents告之内核这个events有多大，这个 maxevents的值不能大于创建epoll_create()时的size，参数timeout是超时时间（毫秒，0会立即返回，-1将不确定，也有说法说是永久阻塞）。该函数返回需要处理的事件数目，如返回0表示已超时
1. int epoll_create(int size);
创建一个epoll的句柄，size用来告诉内核这个监听的数目一共有多大。这个参数不同于select()中的第一个参数，给出最大监听的fd+1的值。需要注意的是，当创建好epoll句柄后，它就是会占用一个fd值，在linux下如果查看/proc/进程id/fd/，是能够看到这个fd的，所以在使用完epoll后，必须调用close()关闭，否则可能导致fd被耗尽。
2. int epoll_ctl(int epfd, int op, int fd, struct epoll_event *event);
epoll的事件注册函数，它不同与select()是在监听事件时告诉内核要监听什么类型的事件，而是在这里先注册要监听的事件类型。第一个参数是epoll_create()的返回值，第二个参数表示动作，用三个宏来表示：
EPOLL_CTL_ADD：注册新的fd到epfd中；EPOLL_CTL_MOD：修改已经注册的fd的监听事件；EPOLL_CTL_DEL：从epfd中删除一个fd；第三个参数是需要监听的fd，第四个参数是告诉内核需要监听什么事
3. int epoll_wait(int epfd, struct epoll_event * events, int maxevents, inttimeout);
等待事件的产生，类似于select()调用。参数events用来从内核得到事件的集合，maxevents告之内核这个events有多大，这个 maxevents的值不能大于创建epoll_create()时的size，参数timeout是超时时间（毫秒，0会立即返回，-1将不确定，也有说法说是永久阻塞）。该函数返回需要处理的事件数目，如返回0表示已超时
30、nginx和apache的区别
Nginx
轻量级，采用 C 进行编写，同样的 web 服务，会占用更少的内存及资源
抗并发，nginx 以 epoll and kqueue 作为开发模型，处理请求是异步非阻塞的，负载能力比
apache 高很多，而 apache 则是阻塞型的。在高并发下 nginx 能保持低资源低消耗高性能 ，而
apache 在 PHP 处理慢或者前端压力很大的情况下，很容易出现进程数飙升，从而拒绝服务的现象。
nginx 处理静态文件好，静态处理性能比 apache 高三倍以上
nginx 的设计高度模块化，编写模块相对简单
nginx 配置简洁，正则配置让很多事情变得简单，而且改完配置能使用 -t 测试配置有没有问题，
apache 配置复杂 ，重启的时候发现配置出错了，会很崩溃
nginx 作为负载均衡服务器，支持 7 层负载均衡
七层负载可以有效的防止ddos攻击
nginx本身就是一个反向代理服务器，也可以左右邮件代理服务器来使用
轻量级，采用 C 进行编写，同样的 web 服务，会占用更少的内存及资源
抗并发，nginx 以 epoll and kqueue 作为开发模型，处理请求是异步非阻塞的，负载能力比
apache 高很多，而 apache 则是阻塞型的。在高并发下 nginx 能保持低资源低消耗高性能 ，而
apache 在 PHP 处理慢或者前端压力很大的情况下，很容易出现进程数飙升，从而拒绝服务的现象。
nginx 处理静态文件好，静态处理性能比 apache 高三倍以上
nginx 的设计高度模块化，编写模块相对简单
nginx 配置简洁，正则配置让很多事情变得简单，而且改完配置能使用 -t 测试配置有没有问题，
apache 配置复杂 ，重启的时候发现配置出错了，会很崩溃
nginx 作为负载均衡服务器，支持 7 层负载均衡
七层负载可以有效的防止ddos攻击
nginx本身就是一个反向代理服务器，也可以左右邮件代理服务器来使用
Apache
apache 的 rewrite 比 nginx 强大，在 rewrite 频繁的情况下，用 apache
apache 发展到现在，模块超多，基本想到的都可以找到
apache 更为成熟，少 bug ，nginx 的 bug 相对较多
apache 对 PHP 支持比较简单，nginx 需要配合其他后端用
apache 在处理动态请求有优势，nginx 在这方面是鸡肋，一般动态请求要 apache 去做，nginx 适合静态和反向。
apache 仍然是目前的主流，拥有丰富的特性，成熟的技术和开发社区
apache 的 rewrite 比 nginx 强大，在 rewrite 频繁的情况下，用 apache
apache 发展到现在，模块超多，基本想到的都可以找到
apache 更为成熟，少 bug ，nginx 的 bug 相对较多
apache 对 PHP 支持比较简单，nginx 需要配合其他后端用
apache 在处理动态请求有优势，nginx 在这方面是鸡肋，一般动态请求要 apache 去做，nginx 适合静态和反向。
apache 仍然是目前的主流，拥有丰富的特性，成熟的技术和开发社区
两者最核心的区别在于 apache 是同步多进程模型，一个连接对应一个进程，而 nginx 是异步的，多个连接（万级别）可以对应一个进程。需要稳定用apache，需要高性能用nginx
31、Tomcat作为web的优缺点？
缺点：
tomcat 只能用做java服务器，处理静态请求的能力不如nginx和apache。，高并发能力有限
优点：
动态解析容器，处理动态请求，是编译JSP/Servlet的容器，轻量级
缺点：
tomcat 只能用做java服务器，处理静态请求的能力不如nginx和apache。，高并发能力有限
优点：
动态解析容器，处理动态请求，是编译JSP/Servlet的容器，轻量级
32、tomcat的三个端口及作用
8005： 关闭Tomcat通信接口
8009： 与其他httpd服务器通信接口，用于http服务器的集合
8080： 建立httpd连接用，如浏览器访问
8005： 关闭Tomcat通信接口
8009： 与其他httpd服务器通信接口，用于http服务器的集合
8080： 建立httpd连接用，如浏览器访问
33、fastcgi 和cgi的区别
cgi：
web 服务器会根据请求的内容，然后会 fork 一个新进程来运行外部 c 程序（或 perl 脚本…）， 这个进程会把处理完的数据返回给 web 服务器，最后 web 服务器把内容发送给用户，刚才 fork 的进程也随之退出。
如果下次用户还请求改动态脚本，那么 web 服务器又再次 fork 一个新进程，周而复始的进行。
fastcgi：
web 服务器收到一个请求时，他不会重新 fork 一个进程（因为这个进程在 web 服务器启动时就开启了，而且不会退出），web 服务器直接把内容传递给这个进程（进程间通信，但 fastcgi 使用了别的方式，tcp 方式通信），这个进程收到请求后进行处理，把结果返回给 web 服务器，最后自己接着等待下一个请求的到来，而不是退出。
cgi：
web 服务器会根据请求的内容，然后会 fork 一个新进程来运行外部 c 程序（或 perl 脚本…）， 这个进程会把处理完的数据返回给 web 服务器，最后 web 服务器把内容发送给用户，刚才 fork 的进程也随之退出。
如果下次用户还请求改动态脚本，那么 web 服务器又再次 fork 一个新进程，周而复始的进行。
fastcgi：
web 服务器收到一个请求时，他不会重新 fork 一个进程（因为这个进程在 web 服务器启动时就开启了，而且不会退出），web 服务器直接把内容传递给这个进程（进程间通信，但 fastcgi 使用了别的方式，tcp 方式通信），这个进程收到请求后进行处理，把结果返回给 web 服务器，最后自己接着等待下一个请求的到来，而不是退出。
34、nginx常用的命令
启动 nginx
停止 nginx -s stop 或 nginx -s quit
重载配置 ./sbin/nginx -s reload(平滑重启) 或 service nginx reload
重载指定配置文件 .nginx -c /usr/local/nginx/conf/nginx.conf
查看 nginx 版本 nginx -v
检查配置文件是否正确 nginx -t
显示帮助信息 nginx -h
启动 nginx
停止 nginx -s stop 或 nginx -s quit
重载配置 ./sbin/nginx -s reload(平滑重启) 或 service nginx reload
重载指定配置文件 .nginx -c /usr/local/nginx/conf/nginx.conf
查看 nginx 版本 nginx -v
检查配置文件是否正确 nginx -t
显示帮助信息 nginx -h
35、什么是反向代理，什么是正向代理，以及区别？
正向代理：
所谓的正向代理就是： 需要在用户端去配置的。配置完再去访问具体的服务，这叫正向代理
正向代理，其实是"代理服务器"代理了"客户端"，去和"目标服务器"进行交互。
正向代理的用途：
1、提高访问速度
2、隐藏客户真实IP
所谓的正向代理就是： 需要在用户端去配置的。配置完再去访问具体的服务，这叫正向代理
正向代理，其实是"代理服务器"代理了"客户端"，去和"目标服务器"进行交互。
正向代理的用途：
1、提高访问速度
2、隐藏客户真实IP
反向代理：
反向代理是 在服务端的，不需要访问用户关心。用户访问服务器A, A服务器是代理服务器，将用户服务
再转发到服务器B.这就是反向代理
反向代理的作用：
1.缓存，将服务器的响应缓存在自己的内存中，减少服务器的压力。
2.负载均衡，将用户请求分配给多个服务器。
3.访问控制
反向代理是 在服务端的，不需要访问用户关心。用户访问服务器A, A服务器是代理服务器，将用户服务
再转发到服务器B.这就是反向代理
反向代理的作用：
1.缓存，将服务器的响应缓存在自己的内存中，减少服务器的压力。
2.负载均衡，将用户请求分配给多个服务器。
3.访问控制
36、Squid、Varinsh、Nginx 有什么区别？
三者都实现缓存服务器的作用
Nginx本来是反向代理/web服务器，用了插件可以做做这个副业(缓存服务器)。但本身支持的特性不是很多，只能缓存静态文件
varinsh 和squid是专业的cache服务，而nginx这些需要使用第三方模块
varnish本身在技术上的优势要高于squid，它采用了可视化页面缓存技术。
在内存的利用上，Varnis h比 Squid 具有优势，性能要比 Squid 高。
还有强大的通过 Varnish 管理端口，可以使用正则表达式快速、批量地清除部分缓存
Varnish 是内存缓存，速度一流，但是内存缓存也限制了其容量，缓存页面和图片一般是挺好的。
要做 cache 服务的话，我们肯定是要选择专业的 cache 服务，优先选择Squid 或者 Varnish
Nginx本来是反向代理/web服务器，用了插件可以做做这个副业(缓存服务器)。但本身支持的特性不是很多，只能缓存静态文件
varinsh 和squid是专业的cache服务，而nginx这些需要使用第三方模块
varnish本身在技术上的优势要高于squid，它采用了可视化页面缓存技术。
在内存的利用上，Varnis h比 Squid 具有优势，性能要比 Squid 高。
还有强大的通过 Varnish 管理端口，可以使用正则表达式快速、批量地清除部分缓存
Varnish 是内存缓存，速度一流，但是内存缓存也限制了其容量，缓存页面和图片一般是挺好的。
要做 cache 服务的话，我们肯定是要选择专业的 cache 服务，优先选择Squid 或者 Varnish
37、nginx是如何处理http请求的
四个步骤：
读取解析请求行；
读取解析请求头；
开始最重要的部分，即多阶段处理；
nginx把请求处理划分成了11个阶段，也就是说当nginx读取了请求行和请求头之后，将请求封装了结构体ngx_http_request_t，然后每个阶段的handler都会根据这个ngx_http_request_t，对请求进行处理，例如重写uri，权限控制，路径查找，生成内容以及记录日志等等；最后将结果放回给客户单。
也可以这么回答：
首先，Nginx 在启动时，会解析配置文件，得到需要监听的端口与 IP 地址，然后在 Nginx 的Master 进程里面先初始化好这个监控的Socket(创建 S ocket，设置 addr、reuse 等选项，绑定到指定的 ip 地址端口，再 listen 监听)。然后，再 fork(一个现有进程可以调用 fork 函数创建一个新进程。由 fork 创建的新进程被称为子进程 )出多个子进程出来。之后，子进程会竞争 accept 新的连接。此时，客户端就可以向 nginx 发起连接了。当客户端与nginx进行三次握手，与 nginx 建立好一个连接后。此时，某一个子进程会 accept 成功，得到这个建立好的连接的 Socket ，然后创建 nginx 对连接的封装，即 ngx_connection_t 结构体。接着，设置读写事件处理函数，并添加读写事件来与客户端进行数据的交换。
最后，Nginx 或客户端来主动关掉连接，到此，一个连接就寿终正寝了。
读取解析请求行；
读取解析请求头；
开始最重要的部分，即多阶段处理；
nginx把请求处理划分成了11个阶段，也就是说当nginx读取了请求行和请求头之后，将请求封装了结构体ngx_http_request_t，然后每个阶段的handler都会根据这个ngx_http_request_t，对请求进行处理，例如重写uri，权限控制，路径查找，生成内容以及记录日志等等；最后将结果放回给客户单。
也可以这么回答：
首先，Nginx 在启动时，会解析配置文件，得到需要监听的端口与 IP 地址，然后在 Nginx 的Master 进程里面先初始化好这个监控的Socket(创建 S ocket，设置 addr、reuse 等选项，绑定到指定的 ip 地址端口，再 listen 监听)。然后，再 fork(一个现有进程可以调用 fork 函数创建一个新进程。由 fork 创建的新进程被称为子进程 )出多个子进程出来。之后，子进程会竞争 accept 新的连接。此时，客户端就可以向 nginx 发起连接了。当客户端与nginx进行三次握手，与 nginx 建立好一个连接后。此时，某一个子进程会 accept 成功，得到这个建立好的连接的 Socket ，然后创建 nginx 对连接的封装，即 ngx_connection_t 结构体。接着，设置读写事件处理函数，并添加读写事件来与客户端进行数据的交换。
最后，Nginx 或客户端来主动关掉连接，到此，一个连接就寿终正寝了。
38、nginx虚拟主机有哪些？
基于域名的虚拟主机
基于端口的虚拟主机
基于IP的虚拟主机
基于域名的虚拟主机
基于端口的虚拟主机
基于IP的虚拟主机
39、nginx怎么实现后端服务的健康检查
方式一，利用 nginx 自带模块 ngx_http_proxy_module 和 ngx_http_upstream_module 对后端节点做健康检查。
方式二，利用 nginx_upstream_check_module 模块对后端节点做健康检查。（推荐此方法）
方式一，利用 nginx 自带模块 ngx_http_proxy_module 和 ngx_http_upstream_module 对后端节点做健康检查。
方式二，利用 nginx_upstream_check_module 模块对后端节点做健康检查。（推荐此方法）
40、apache中的Worker 和 Prefork 之间的区别是什么?
它们都是MPM, Worker 和 prefork 有它们各自在Apache上的运行机制. 它们完全依赖于你想要以哪一种模式启动你的Apache.
1、Worker 和 MPM基本的区别在于它们产生子进程的处理过程. 在Prefork MPM中, 一个主httpd进行被启动，这个主进程会管理所有其它子进程为客户端请求提供服务. 而在worker MPM中一个httpd进程被激活，则会使用不同的线程来为客户端请求提供服务.
2、Prefork MPM 使用多个子进程，每一个进程带有一个线程而 worker MPM 使用多个子进程，每一个进程带有多个线程.
3、Prefork MPM中的连接处理, 每一个进程一次处理一个连接而在Worker mpm中每一个线程一次处理一个连接.
4、内存占用 Prefork MPM 占用庞大的内存, 而Worker占用更小的内存.
1、Worker 和 MPM基本的区别在于它们产生子进程的处理过程. 在Prefork MPM中, 一个主httpd进行被启动，这个主进程会管理所有其它子进程为客户端请求提供服务. 而在worker MPM中一个httpd进程被激活，则会使用不同的线程来为客户端请求提供服务.
2、Prefork MPM 使用多个子进程，每一个进程带有一个线程而 worker MPM 使用多个子进程，每一个进程带有多个线程.
3、Prefork MPM中的连接处理, 每一个进程一次处理一个连接而在Worker mpm中每一个线程一次处理一个连接.
4、内存占用 Prefork MPM 占用庞大的内存, 而Worker占用更小的内存.
41、Tomcat缺省端口是多少，怎么修改
找到Tomcat目录下的conf文件夹
进入conf文件夹里面找到server.xml文件
打开server.xml文件
在server.xml文件里面找到下列信息
把Connector标签的8080端口改成你想要的端口
找到Tomcat目录下的conf文件夹
进入conf文件夹里面找到server.xml文件
打开server.xml文件
在server.xml文件里面找到下列信息
把Connector标签的8080端口改成你想要的端口
42、Tomcat的工作模式是什么？
Tomcat作为servlet容器，有三种工作模式：
1、独立的servlet容器，servlet容器是web服务器的一部分；
2、进程内的servlet容器，servlet容器是作为web服务器的插件和java容器的实现，web服务器插件在内部地址空间打开一个jvm使得java容器在内部得以运行。反应速度快但伸缩性不足；
3、进程外的servlet容器，servlet容器运行于web服务器之外的地址空间，并作为web服务器的插件和java容器实现的结合。反应时间不如进程内但伸缩性和稳定性比进程内优；
进入Tomcat的请求可以根据Tomcat的工作模式分为如下两类：
Tomcat作为应用程序服务器：请求来自于前端的web服务器，这可能是Apache, IIS, Nginx等；
Tomcat作为独立服务器：请求来自于web浏览器；
1、独立的servlet容器，servlet容器是web服务器的一部分；
2、进程内的servlet容器，servlet容器是作为web服务器的插件和java容器的实现，web服务器插件在内部地址空间打开一个jvm使得java容器在内部得以运行。反应速度快但伸缩性不足；
3、进程外的servlet容器，servlet容器运行于web服务器之外的地址空间，并作为web服务器的插件和java容器实现的结合。反应时间不如进程内但伸缩性和稳定性比进程内优；
进入Tomcat的请求可以根据Tomcat的工作模式分为如下两类：
Tomcat作为应用程序服务器：请求来自于前端的web服务器，这可能是Apache, IIS, Nginx等；
Tomcat作为独立服务器：请求来自于web浏览器；
43、Web请求在Tomcat请求中的请求流程是怎么样的?
浏览器输入URL地址;
查询本机hosts文件寻找IP;
查询DNS服务器寻找IP;
向该IP发送Http请求;
Tomcat容器解析主机名;
Tomcat容器解析Web应用;
Tomcat容器解析资源名称;
Tomcat容器获取资源;
Tomcat响应浏览器。
浏览器输入URL地址;
查询本机hosts文件寻找IP;
查询DNS服务器寻找IP;
向该IP发送Http请求;
Tomcat容器解析主机名;
Tomcat容器解析Web应用;
Tomcat容器解析资源名称;
Tomcat容器获取资源;
Tomcat响应浏览器。
44、怎么监控Tomcat的内存使用情况
使用JDK自带的jconsole可以比较明了的看到内存的使用情况，线程的状态，当前加载的类的总量等；JDK自带的jvisualvm可以下载插件（如GC等），可以查看更丰富的信息。如果是分析本地的Tomcat的话，还可以进行内存抽样等，检查每个类的使用情况在java/bin目录下
使用JDK自带的jconsole可以比较明了的看到内存的使用情况，线程的状态，当前加载的类的总量等；JDK自带的jvisualvm可以下载插件（如GC等），可以查看更丰富的信息。如果是分析本地的Tomcat的话，还可以进行内存抽样等，检查每个类的使用情况在java/bin目录下
45、nginx的优化你都做过哪些？
优化点如下：
gzip压缩优化
expires缓存有还
网络IO事件模型优化
隐藏软件名称和版本号
防盗链优化
禁止恶意域名解析
禁止通过IP地址访问网站
HTTP请求方法优化
防DOS攻击单IP并发连接的控制，与连接速率控制
严格设置web站点目录的权限
将nginx进程以及站点运行于监牢模式
通过robot协议以及HTTP_USER_AGENT防爬虫优化
配置错误页面根据错误码指定网页反馈给用户
nginx日志相关优化访问日志切割轮询，不记录指定元素日志、最小化日志目录权限
限制上传到资源目录的程序被访问，防止木马入侵系统破坏文件
FastCGI参数buffer和cache配置文件的优化
php.ini和php-fpm.conf配置文件的优化
有关web服务的Linux内核方面深度优化（网络连接、IO、内存等）
nginx加密传输优化（SSL）
web服务器磁盘挂载及网络文件系统的优化
使用nginx cache
gzip压缩优化
expires缓存有还
网络IO事件模型优化
隐藏软件名称和版本号
防盗链优化
禁止恶意域名解析
禁止通过IP地址访问网站
HTTP请求方法优化
防DOS攻击单IP并发连接的控制，与连接速率控制
严格设置web站点目录的权限
将nginx进程以及站点运行于监牢模式
通过robot协议以及HTTP_USER_AGENT防爬虫优化
配置错误页面根据错误码指定网页反馈给用户
nginx日志相关优化访问日志切割轮询，不记录指定元素日志、最小化日志目录权限
限制上传到资源目录的程序被访问，防止木马入侵系统破坏文件
FastCGI参数buffer和cache配置文件的优化
php.ini和php-fpm.conf配置文件的优化
有关web服务的Linux内核方面深度优化（网络连接、IO、内存等）
nginx加密传输优化（SSL）
web服务器磁盘挂载及网络文件系统的优化
使用nginx cache
一： 配置文件中对优化有明显效果的：
1、worker_processes 8;
nginx 进程数，建议按照cpu 数目来指定，一般为它的倍数 (如,2个四核的cpu计为8)。
2、worker_cpu_affinity 00000001 00000010 00000100 00001000 00010000 00100000 01000000 10000000;
为每个进程分配cpu，上例中将8 个进程分配到8 个cpu，当然可以写多个，或者将一个进程分配到多个cpu。
3、worker_rlimit_nofile 65535;
这个指令是指当一个nginx 进程打开的最多文件描述符数目，理论值应该是最多打开文件数（ulimit-n）与nginx 进程数相除，但是nginx 分配请求并不是那么均匀，所以最好与ulimit -n 的值保持一致。
现在在linux 2.6内核下开启文件打开数为65535，worker_rlimit_nofile就相应应该填写65535。
这是因为nginx调度时分配请求到进程并不是那么的均衡，所以假如填写10240，总并发量达到3-4万时就有进程可能超过10240了，这时会返回502错误。
4. use epoll
5. worker_connections 65535
每个进程允许的最多连接数， 理论上每台nginx 服务器的最大连接数为 worker_processes*worker_connections。
6. keepalive_timeout 60;
7. client_header_buffer_size 4k;
客户端请求头部的缓冲区大小，这个可以根据你的系统分页大小来设置，一般一个请求头的大小不会超过1k
8. open_file_cache max=65535 inactive=60s;
这个将为打开文件指定缓存，默认是没有启用的，max 指定缓存数量，建议和打开文件数一致，inactive 是指经过多长时间文件没被请求后删除缓存。
9. open_file_cache_valid 80s;
这个是指多长时间检查一次缓存的有效信息。
10. open_file_cache_min_uses 1;
open_file_cache 指令中的inactive 参数时间内文件的最少使用次数，如果超过这个数字，文件描述符一直是在缓存中打开的，如上例，如果有一个文件在inactive 时间内一次没被使用，它将被移除。
1、worker_processes 8;
nginx 进程数，建议按照cpu 数目来指定，一般为它的倍数 (如,2个四核的cpu计为8)。
2、worker_cpu_affinity 00000001 00000010 00000100 00001000 00010000 00100000 01000000 10000000;
为每个进程分配cpu，上例中将8 个进程分配到8 个cpu，当然可以写多个，或者将一个进程分配到多个cpu。
3、worker_rlimit_nofile 65535;
这个指令是指当一个nginx 进程打开的最多文件描述符数目，理论值应该是最多打开文件数（ulimit-n）与nginx 进程数相除，但是nginx 分配请求并不是那么均匀，所以最好与ulimit -n 的值保持一致。
现在在linux 2.6内核下开启文件打开数为65535，worker_rlimit_nofile就相应应该填写65535。
这是因为nginx调度时分配请求到进程并不是那么的均衡，所以假如填写10240，总并发量达到3-4万时就有进程可能超过10240了，这时会返回502错误。
4. use epoll
5. worker_connections 65535
每个进程允许的最多连接数， 理论上每台nginx 服务器的最大连接数为 worker_processes*worker_connections。
6. keepalive_timeout 60;
7. client_header_buffer_size 4k;
客户端请求头部的缓冲区大小，这个可以根据你的系统分页大小来设置，一般一个请求头的大小不会超过1k
8. open_file_cache max=65535 inactive=60s;
这个将为打开文件指定缓存，默认是没有启用的，max 指定缓存数量，建议和打开文件数一致，inactive 是指经过多长时间文件没被请求后删除缓存。
9. open_file_cache_valid 80s;
这个是指多长时间检查一次缓存的有效信息。
10. open_file_cache_min_uses 1;
open_file_cache 指令中的inactive 参数时间内文件的最少使用次数，如果超过这个数字，文件描述符一直是在缓存中打开的，如上例，如果有一个文件在inactive 时间内一次没被使用，它将被移除。
46、Tomcat你做过哪些优化
Tomcat的运行模式 ： bio,nio, apr
一般使用nio模式，bio效率低，apr对系统配置有一些更高的要求
一般使用nio模式，bio效率低，apr对系统配置有一些更高的要求
关键配置
maxThreads： 最大线程数，默认是200，
minspareThread： 最小活跃线程数，默认是25
maxqueuesize: 最大等待队列个数
maxThreads： 最大线程数，默认是200，
minspareThread： 最小活跃线程数，默认是25
maxqueuesize: 最大等待队列个数
影响性能的配置
compression 设置成on，开启压缩
禁用AJP连接器： 用nginx+Tomcat的架构，用不到AJP
enableLookups=false 关闭反查域名，直接返回ip，提高效率
disableUploadTimeou=false上传是否使用超时机制
acceptCount=300 , 当前所有可以使用的处理请求都被使用时，传入请求连接最大队列长队，超过个数不予处理，默认是100
keepalive timeout=120000 场链接保持时间
compression 设置成on，开启压缩
禁用AJP连接器： 用nginx+Tomcat的架构，用不到AJP
enableLookups=false 关闭反查域名，直接返回ip，提高效率
disableUploadTimeou=false上传是否使用超时机制
acceptCount=300 , 当前所有可以使用的处理请求都被使用时，传入请求连接最大队列长队，超过个数不予处理，默认是100
keepalive timeout=120000 场链接保持时间
优化jvm
/bin/catalina.sh
-server：jvm的server工作模式，对应的有client工作模式。使用“java -version”可以查看当前工作模式
-Xms1024m：初始Heap大小，使用的最小内存
-Xmx1024m：Java heap最大值，使用的最大内存。经验: 设置Xms大小等于Xmx大小
-XX:NewSize=512m：表示新生代初始内存的大小，应该小于 -Xms的值
-XX:MaxNewSize=1024M：表示新生代可被分配的内存的最大上限，应该小于 -Xmx的值
-XX:PermSize=1024m：设定内存的永久保存区域,内存的永久保存区域，VM 存放Class 和 Meta信息，JVM在运行期间不会清除该区域
-XX:MaxPermSize=1024m：设定最大内存的永久保存区域。经验: 设置PermSize大小等于MaxPermSize大小
-XX:+DisableExplicitGC：自动将System.gc() 调用转换成一个空操作，即应用中调用System.gc()会变成一个空操作，避免程序员在代码里进行System.gc()这种危险操作。System.gc()除非是到了万不得也的情况下使用，都应该交给 JVM。
/bin/catalina.sh
-server：jvm的server工作模式，对应的有client工作模式。使用“java -version”可以查看当前工作模式
-Xms1024m：初始Heap大小，使用的最小内存
-Xmx1024m：Java heap最大值，使用的最大内存。经验: 设置Xms大小等于Xmx大小
-XX:NewSize=512m：表示新生代初始内存的大小，应该小于 -Xms的值
-XX:MaxNewSize=1024M：表示新生代可被分配的内存的最大上限，应该小于 -Xmx的值
-XX:PermSize=1024m：设定内存的永久保存区域,内存的永久保存区域，VM 存放Class 和 Meta信息，JVM在运行期间不会清除该区域
-XX:MaxPermSize=1024m：设定最大内存的永久保存区域。经验: 设置PermSize大小等于MaxPermSize大小
-XX:+DisableExplicitGC：自动将System.gc() 调用转换成一个空操作，即应用中调用System.gc()会变成一个空操作，避免程序员在代码里进行System.gc()这种危险操作。System.gc()除非是到了万不得也的情况下使用，都应该交给 JVM。
47、nginx的session不同步怎么办
我们可以采用ip_hash指令解决这个问题，如果客户已经访问了某个服务器，当用户再次访问时，会将该请求通过哈希算法，自动定位到该服务器。即每个访客固定访问一个后端服务器，可以解决session的问题。
其他办法：那就是用spring_session+redis，把session放到缓存中实现session共享。
我们可以采用ip_hash指令解决这个问题，如果客户已经访问了某个服务器，当用户再次访问时，会将该请求通过哈希算法，自动定位到该服务器。即每个访客固定访问一个后端服务器，可以解决session的问题。
其他办法：那就是用spring_session+redis，把session放到缓存中实现session共享。
48、nginx的常用模块有哪些？
1、ngx_http_core_module #包括一些核心的http参数配置，对应Nginx的配置为HTTP区块部分
2、ngx_http_access_module #访问控制模块，用来控制网站用户对Nginx的访问
3、ngx_http_gzip_module #压缩模块，对Nginx返回的数据压缩，属于性能优化模块
4、ngx_http_fastcgi_module #FastCGI模块，和 动态应用相关的模块，例如PHP
5、ngx_http_proxy_module #Proxy代理模块
6、ngx_http_upstream_module #负载均衡模块，可以实现网站的负载均衡功能及节点的健康检查
7、ngx_http_rewrite_module #URL地址重写模块
8、ngx_http_limit_conn_module #限制用户并发连接数及请求数模块（防止ddos）
9、ngx_http_limit_req_module #根据定义的key限制Nginx请求过程的速率
10、ngx_http_log_module #访问日志模块，以指定的格式记录Nginx客户访问日志等信息
11、ngx_http_auth_basic_module #Web认证模块，设置Web用户通过账号、密码访问Nginx
12、ngx_http_ssl_module #ssl模块，用于加密的http连接，如https
13、ngx_http_stub_status_module #记录Nginx基本访问状态信息等模块
1、ngx_http_core_module #包括一些核心的http参数配置，对应Nginx的配置为HTTP区块部分
2、ngx_http_access_module #访问控制模块，用来控制网站用户对Nginx的访问
3、ngx_http_gzip_module #压缩模块，对Nginx返回的数据压缩，属于性能优化模块
4、ngx_http_fastcgi_module #FastCGI模块，和 动态应用相关的模块，例如PHP
5、ngx_http_proxy_module #Proxy代理模块
6、ngx_http_upstream_module #负载均衡模块，可以实现网站的负载均衡功能及节点的健康检查
7、ngx_http_rewrite_module #URL地址重写模块
8、ngx_http_limit_conn_module #限制用户并发连接数及请求数模块（防止ddos）
9、ngx_http_limit_req_module #根据定义的key限制Nginx请求过程的速率
10、ngx_http_log_module #访问日志模块，以指定的格式记录Nginx客户访问日志等信息
11、ngx_http_auth_basic_module #Web认证模块，设置Web用户通过账号、密码访问Nginx
12、ngx_http_ssl_module #ssl模块，用于加密的http连接，如https
13、ngx_http_stub_status_module #记录Nginx基本访问状态信息等模块
49、nginx常用状态码
200 （成功） 服务器已成功处理了请求。 通常，这表示服务器提供了请求的网页。
201 （已创建） 请求成功并且服务器创建了新的资源。
202 （已接受） 服务器已接受请求，但尚未处理。
203 （非授权信息） 服务器已成功处理了请求，但返回的信息可能来自另一来源。
204 （无内容） 服务器成功处理了请求，但没有返回任何内容。
205 （重置内容） 服务器成功处理了请求，但没有返回任何内容。
206 （部分内容） 服务器成功处理了部分 GET 请求。
300 （多种选择） 针对请求，服务器可执行多种操作。 服务器可根据请求者 (user agent) 选择一项操作，或提供操作列表供请求者选择。
301 （永久移动） 请求的网页已永久移动到新位置。 服务器返回此响应（对 GET 或 HEAD 请求的响应）时，会自动将请求者转到新位置。
302 （临时移动） 服务器目前从不同位置的网页响应请求，但请求者应继续使用原有位置来进行以后的请求。
303 （查看其他位置） 请求者应当对不同的位置使用单独的 GET 请求来检索响应时，服务器返回此代码。
304 （未修改） 自从上次请求后，请求的网页未修改过。 服务器返回此响应时，不会返回网页内容。
305 （使用代理） 请求者只能使用代理访问请求的网页。 如果服务器返回此响应，还表示请求者应使用代理。
307 （临时重定向） 服务器目前从不同位置的网页响应请求，但请求者应继续使用原有位置来进行以后的请求。
400 （错误请求） 服务器不理解请求的语法。
401 （未授权） 请求要求身份验证。 对于需要登录的网页，服务器可能返回此响应。
403 （禁止） 服务器拒绝请求。
404 （未找到） 服务器找不到请求的网页。
405 （方法禁用） 禁用请求中指定的方法。
406 （不接受） 无法使用请求的内容特性响应请求的网页。
407 （需要代理授权） 此状态代码与 401（未授权）类似，但指定请求者应当授权使用代理。
408 （请求超时） 服务器等候请求时发生超时。
409 （冲突） 服务器在完成请求时发生冲突。 服务器必须在响应中包含有关冲突的信息。
410 （已删除） 如果请求的资源已永久删除，服务器就会返回此响应。
411 （需要有效长度） 服务器不接受不含有效内容长度标头字段的请求。
412 （未满足前提条件） 服务器未满足请求者在请求中设置的其中一个前提条件。
413 （请求实体过大） 服务器无法处理请求，因为请求实体过大，超出服务器的处理能力。
414 （请求的 URI 过长） 请求的 URI（通常为网址）过长，服务器无法处理。
415 （不支持的媒体类型） 请求的格式不受请求页面的支持。
416 （请求范围不符合要求） 如果页面无法提供请求的范围，则服务器会返回此状态代码。
417 （未满足期望值） 服务器未满足"期望"请求标头字段的要求。
500 （服务器内部错误） 服务器遇到错误，无法完成请求。
501 （尚未实施） 服务器不具备完成请求的功能。 例如，服务器无法识别请求方法时可能会返回此代码。
502 （错误网关） 服务器作为网关或代理，从上游服务器收到无效响应。
503 （服务不可用） 服务器目前无法使用（由于超载或停机维护）。 通常，这只是暂时状态。
504 （网关超时） 服务器作为网关或代理，但是没有及时从上游服务器收到请求。
505 （HTTP 版本不受支持） 服务器不支持请求中所用的 HTTP 协议版本。
200 （成功） 服务器已成功处理了请求。 通常，这表示服务器提供了请求的网页。
201 （已创建） 请求成功并且服务器创建了新的资源。
202 （已接受） 服务器已接受请求，但尚未处理。
203 （非授权信息） 服务器已成功处理了请求，但返回的信息可能来自另一来源。
204 （无内容） 服务器成功处理了请求，但没有返回任何内容。
205 （重置内容） 服务器成功处理了请求，但没有返回任何内容。
206 （部分内容） 服务器成功处理了部分 GET 请求。
300 （多种选择） 针对请求，服务器可执行多种操作。 服务器可根据请求者 (user agent) 选择一项操作，或提供操作列表供请求者选择。
301 （永久移动） 请求的网页已永久移动到新位置。 服务器返回此响应（对 GET 或 HEAD 请求的响应）时，会自动将请求者转到新位置。
302 （临时移动） 服务器目前从不同位置的网页响应请求，但请求者应继续使用原有位置来进行以后的请求。
303 （查看其他位置） 请求者应当对不同的位置使用单独的 GET 请求来检索响应时，服务器返回此代码。
304 （未修改） 自从上次请求后，请求的网页未修改过。 服务器返回此响应时，不会返回网页内容。
305 （使用代理） 请求者只能使用代理访问请求的网页。 如果服务器返回此响应，还表示请求者应使用代理。
307 （临时重定向） 服务器目前从不同位置的网页响应请求，但请求者应继续使用原有位置来进行以后的请求。
400 （错误请求） 服务器不理解请求的语法。
401 （未授权） 请求要求身份验证。 对于需要登录的网页，服务器可能返回此响应。
403 （禁止） 服务器拒绝请求。
404 （未找到） 服务器找不到请求的网页。
405 （方法禁用） 禁用请求中指定的方法。
406 （不接受） 无法使用请求的内容特性响应请求的网页。
407 （需要代理授权） 此状态代码与 401（未授权）类似，但指定请求者应当授权使用代理。
408 （请求超时） 服务器等候请求时发生超时。
409 （冲突） 服务器在完成请求时发生冲突。 服务器必须在响应中包含有关冲突的信息。
410 （已删除） 如果请求的资源已永久删除，服务器就会返回此响应。
411 （需要有效长度） 服务器不接受不含有效内容长度标头字段的请求。
412 （未满足前提条件） 服务器未满足请求者在请求中设置的其中一个前提条件。
413 （请求实体过大） 服务器无法处理请求，因为请求实体过大，超出服务器的处理能力。
414 （请求的 URI 过长） 请求的 URI（通常为网址）过长，服务器无法处理。
415 （不支持的媒体类型） 请求的格式不受请求页面的支持。
416 （请求范围不符合要求） 如果页面无法提供请求的范围，则服务器会返回此状态代码。
417 （未满足期望值） 服务器未满足"期望"请求标头字段的要求。
500 （服务器内部错误） 服务器遇到错误，无法完成请求。
501 （尚未实施） 服务器不具备完成请求的功能。 例如，服务器无法识别请求方法时可能会返回此代码。
502 （错误网关） 服务器作为网关或代理，从上游服务器收到无效响应。
503 （服务不可用） 服务器目前无法使用（由于超载或停机维护）。 通常，这只是暂时状态。
504 （网关超时） 服务器作为网关或代理，但是没有及时从上游服务器收到请求。
505 （HTTP 版本不受支持） 服务器不支持请求中所用的 HTTP 协议版本。
50、. 访问一个网站的流程
用户输入网站按回车， 查找本地缓存，如果有就打开页面，如果没有，利用DNS做域名解析，递归查询，一级一级的向上提交查询请求，知道查询到为止
HOSTS表--> 本地DNS -->上层DNS（包括根DNS）
经过了DNS解析，知道了网站的IP地址，然后建立tcp三次握手； 建立请求后，发送请求报文，默认请求的是index.html
传送完毕，断开连接
用户输入网站按回车， 查找本地缓存，如果有就打开页面，如果没有，利用DNS做域名解析，递归查询，一级一级的向上提交查询请求，知道查询到为止
HOSTS表--> 本地DNS -->上层DNS（包括根DNS）
经过了DNS解析，知道了网站的IP地址，然后建立tcp三次握手； 建立请求后，发送请求报文，默认请求的是index.html
传送完毕，断开连接
51、三次握手，四次挥手
三次握手
01）由客户端（用户）发送建立TCP连接的请求报文，其中报文中包含seq序列号，是由发送端随机生成的。并且还将报文中SYN字段置为1，表示需要建立TCP连接请求。
02）服务端（就是百度服务器）会回复客户端（用户）发送的TCP连接请求报文，其中包含seq序列号，也是由回复端随机生成的，并且将回复报文的SYN字段置1，而且会产生ACK验证字段，ACK验证字段数值是在客户端发过来的seq序列号基础上加1进行回复：并且还会回复ack确认控制字段，以便客户端收到信息时，知晓自己的TCP建立请求已得到了确认。
03）客户端收到服务端发送的TCP建立请求后，会使自己的原有序列号加1进行再次发送序列号，并且再次回复ACK验证请求，在B端发送过来的seq基础上加1，进行回复；同时也会回复ack确认控制字段，以便B收到信息时，知晓自己的TCP建立请求已经得到了确认。
01）由客户端（用户）发送建立TCP连接的请求报文，其中报文中包含seq序列号，是由发送端随机生成的。并且还将报文中SYN字段置为1，表示需要建立TCP连接请求。
02）服务端（就是百度服务器）会回复客户端（用户）发送的TCP连接请求报文，其中包含seq序列号，也是由回复端随机生成的，并且将回复报文的SYN字段置1，而且会产生ACK验证字段，ACK验证字段数值是在客户端发过来的seq序列号基础上加1进行回复：并且还会回复ack确认控制字段，以便客户端收到信息时，知晓自己的TCP建立请求已得到了确认。
03）客户端收到服务端发送的TCP建立请求后，会使自己的原有序列号加1进行再次发送序列号，并且再次回复ACK验证请求，在B端发送过来的seq基础上加1，进行回复；同时也会回复ack确认控制字段，以便B收到信息时，知晓自己的TCP建立请求已经得到了确认。
四次挥手
第一次挥手：
Client发送一个FIN，用来关闭Client到Server的数据传送，Client进入FIN_WAIT_1状态。
第二次挥手：
Server收到FIN后，发送一个ACK给Client，确认序号为收到序号+1（与SYN相同，一个FIN占用一个序号），Server进入CLOSE_WAIT状态。
第三次挥手：
Server发送一个FIN，用来关闭Server到Client的数据传送，Server进入LAST_ACK状态。
第四次挥手：
Client收到FIN后，Client进入TIME_WAIT状态，接着发送一个ACK给Server，确认序号为收到序号+1，Server进入CLOSED状态，完成四次挥手。
第一次挥手：
Client发送一个FIN，用来关闭Client到Server的数据传送，Client进入FIN_WAIT_1状态。
第二次挥手：
Server收到FIN后，发送一个ACK给Client，确认序号为收到序号+1（与SYN相同，一个FIN占用一个序号），Server进入CLOSE_WAIT状态。
第三次挥手：
Server发送一个FIN，用来关闭Server到Client的数据传送，Server进入LAST_ACK状态。
第四次挥手：
Client收到FIN后，Client进入TIME_WAIT状态，接着发送一个ACK给Server，确认序号为收到序号+1，Server进入CLOSED状态，完成四次挥手。
52、什么是动态资源，什么是静态资源
动态资源
一般客户端请求的动态资源，先将请求交于web容器，web容器连接数据库，数据库处理数据之后，将内容交给web服务器，web服务器返回给客户端解析渲染处理。
一般客户端请求的动态资源，先将请求交于web容器，web容器连接数据库，数据库处理数据之后，将内容交给web服务器，web服务器返回给客户端解析渲染处理。
55、什么叫网站灰度发布？
也叫金丝雀发布
AB test就是一种灰度发布方式，让一部用户继续用A，一部分用户开始用B；如果用户对B没有什么反对意见，那么逐步扩大范围，把所有用户都迁移到B上面来；灰度发布可以保证整体系统的稳定，在初始灰度的时候就可以发现、调整问题，以保证其影响度
也叫金丝雀发布
AB test就是一种灰度发布方式，让一部用户继续用A，一部分用户开始用B；如果用户对B没有什么反对意见，那么逐步扩大范围，把所有用户都迁移到B上面来；灰度发布可以保证整体系统的稳定，在初始灰度的时候就可以发现、调整问题，以保证其影响度
静态资源
可以理解为前端的固定页面，这里面包含HTML、CSS、JS、图片等等，不需要查数据库也不需要程序处理，直接就能够显示的页面，如果想修改内容则必须修改页面，但是访问效率相当高。
可以理解为前端的固定页面，这里面包含HTML、CSS、JS、图片等等，不需要查数据库也不需要程序处理，直接就能够显示的页面，如果想修改内容则必须修改页面，但是访问效率相当高。
53、worker支持的最大并发数是什么？
worker的连接数是2个时，最大并发数：(worker_connection * worker_processes) /2；worker的连接数是4个时，最大并发数：(worker_connection * worker_processes) /4
worker的连接数是2个时，最大并发数：(worker_connection * worker_processes) /2；worker的连接数是4个时，最大并发数：(worker_connection * worker_processes) /4
54、Tomcat和Resin有什么区别，工作中你怎么选择？
工作中选择
现在大公司都是用resin，追求性能；而中小型公司都是用Tomcat，追求稳定和程序的兼容
现在大公司都是用resin，追求性能；而中小型公司都是用Tomcat，追求稳定和程序的兼容
区别
Tomcat用户数多，可参考文档多，Resin用户数少，可考虑文档少
最主要区别则是Tomcat是标准的java容器，不过性能方面比resin的要差一些，但稳定性和java程序的兼容性，应该是比resin的要好
Tomcat用户数多，可参考文档多，Resin用户数少，可考虑文档少
最主要区别则是Tomcat是标准的java容器，不过性能方面比resin的要差一些，但稳定性和java程序的兼容性，应该是比resin的要好
56、统计ip访问情况，要求分析nginx访问日志，找出访问页面数量在前十位的ip
cat access.log | awk '{print $1}' | uniq -c | sort -rn | head -10
cat access.log | awk '{print $1}' | uniq -c | sort -rn | head -10
57、nginx各个版本的区别
Nginx官网提供了三个类型的版本
Mainline version：Mainline 是 Nginx 目前主力在做的版本，可以说是开发版
Stable version：最新稳定版，生产环境上建议使用的版本
Legacy versions：遗留的老版本的稳定版
Nginx官网提供了三个类型的版本
Mainline version：Mainline 是 Nginx 目前主力在做的版本，可以说是开发版
Stable version：最新稳定版，生产环境上建议使用的版本
Legacy versions：遗留的老版本的稳定版
58、nginx最新版本
版本：1.25.0
版本：1.25.0
59、关于nginx access模块的面试题
编写一个Nginx的access模块，要求准许192.168.3.29/24的机器访问，准许10.1.20.6/16这个网段的所有机器访问，准许34.26.157.0/24这个网段访问,除此之外的机器不准许访问。
location/{
access 192.168.3.29/24;
access 10.1.20.6/16;
access 34.26.157.0/24;
deny all;
}
编写一个Nginx的access模块，要求准许192.168.3.29/24的机器访问，准许10.1.20.6/16这个网段的所有机器访问，准许34.26.157.0/24这个网段访问,除此之外的机器不准许访问。
location/{
access 192.168.3.29/24;
access 10.1.20.6/16;
access 34.26.157.0/24;
deny all;
}
60、nginx默认配置文件
在 nginx 的配置文件中，大概分为几个区域：events {}、http {}、和没有被 {}包裹的区域。而 http {}中还有 server {}，以及 server {} 中的 location {}。结构如下：
...
worker_processes 1;
events {
worker_connections 1024;
}
http {
...
server {
...
location {
...
}
}
server {
...
}
}
没有被 {} 包裹的部分为全局配置，如 worker_processes 1; 设置工作进程（子进程）数为 1
events {} 为 nginx 连接配置的模块，如 worker_connections 1024; 设置每一个子进程最大允许连接 1024 个连接
http {} 为 nginx http 核心配置模块
server {} 为虚拟主机配置模块，包括监听端口、监听域名等
location {} URI 匹配
在 nginx 的配置文件中，大概分为几个区域：events {}、http {}、和没有被 {}包裹的区域。而 http {}中还有 server {}，以及 server {} 中的 location {}。结构如下：
...
worker_processes 1;
events {
worker_connections 1024;
}
http {
...
server {
...
location {
...
}
}
server {
...
}
}
没有被 {} 包裹的部分为全局配置，如 worker_processes 1; 设置工作进程（子进程）数为 1
events {} 为 nginx 连接配置的模块，如 worker_connections 1024; 设置每一个子进程最大允许连接 1024 个连接
http {} 为 nginx http 核心配置模块
server {} 为虚拟主机配置模块，包括监听端口、监听域名等
location {} URI 匹配
61、 location的规则
nginx 处理localtion区块的顺序
每一个请求进来 Nginx 之后，Nginx 就会选择一个 Location 的最佳匹配项进行响应，处理的具体流程是逐一跟 location 的配置进行比对，这个步骤可以分为以下几步：
先进行前缀式的匹配（也就是 location 的 optional_modifier 为空的配置）。
Nginx 其次会根据 URI 寻找完全匹配的 location 配置（也就是 location 的 optional_modifier为 = 的配置）.
如果还是没有匹配到，那就先匹配 ^~ 配置，如果找到一个配置的话，则会停止寻找过程，直接返回响应内容。
如果还是没有找到匹配项的话，则会先进行大小写敏感的正则匹配，然后再是大小不写敏感的正则匹配
每一个请求进来 Nginx 之后，Nginx 就会选择一个 Location 的最佳匹配项进行响应，处理的具体流程是逐一跟 location 的配置进行比对，这个步骤可以分为以下几步：
先进行前缀式的匹配（也就是 location 的 optional_modifier 为空的配置）。
Nginx 其次会根据 URI 寻找完全匹配的 location 配置（也就是 location 的 optional_modifier为 = 的配置）.
如果还是没有匹配到，那就先匹配 ^~ 配置，如果找到一个配置的话，则会停止寻找过程，直接返回响应内容。
如果还是没有找到匹配项的话，则会先进行大小写敏感的正则匹配，然后再是大小不写敏感的正则匹配
举例子：
location = / {
# = 等号配置符，只匹配 / 这个路由
}
location /data {
# 留空配置，会匹配有 /data 开始的路由，后续有匹配会往下匹配。
}
location ^~ /img/ {
# 注意 ^~ 配置，这里匹配到 /img/ 开始的话，直接就返回了。
}
location ~* .(png|gif|ico|jpg|jpeg)$ {
# 匹配以 png, gif, ico, jpg or jpeg 结尾的请求；这个通常用来设置图片的请求响应。
}
location = / {
# = 等号配置符，只匹配 / 这个路由
}
location /data {
# 留空配置，会匹配有 /data 开始的路由，后续有匹配会往下匹配。
}
location ^~ /img/ {
# 注意 ^~ 配置，这里匹配到 /img/ 开始的话，直接就返回了。
}
location ~* .(png|gif|ico|jpg|jpeg)$ {
# 匹配以 png, gif, ico, jpg or jpeg 结尾的请求；这个通常用来设置图片的请求响应。
}
62、配置nginx防盗链
Nginx的防盗链原理是加入location项，用正则表达式过渡图片类型文件，对于信任的网址可以正常使用，对于不信任的网址则返回相应的错误图片，在源主机（bt.com）的配置文件中加入以下代码：
vi /usr/local/nginx/conf/nginx.conf
location ~*\.(jpg|gif|swf)$ {
valid_referers none blocked *.test.com test.com;
if ($invalid_referer) {
rewrite ^/http://www.bt.com/error.png;
}
}
下面分析一下这段代码：
~*\.(jpg|gif|swf)$：这段正则表达式表示匹配不区分大小写，以.jpg或.gif或.swf结尾的文件。
valid_referers：设置信任的网站，可以正常使用图片。
none：浏览器中referer为空的情况，这就是直接在浏览器访问图片。
blocked：浏览器中referer不可空的情况，但是值被代理或防火墙删除了，这些值不以http://或https://开头。
后面的网站或者域名：referer中包含相关字符串的网址。
if语句：如果链接的来源域名不在valid_referers所列出的列表中，$invalid_referer为1，则执行后面的操作，即进行重写或返回403页面。
把图片error.png放到源主机（bt.com）的工作目录下。
ls /usr/local/nginx/html
50x.html index.html logo.jpg error.png
这是重启服务器，重新访问http://www.test.com/index.html，显示的是被重写的图片。
Nginx的防盗链原理是加入location项，用正则表达式过渡图片类型文件，对于信任的网址可以正常使用，对于不信任的网址则返回相应的错误图片，在源主机（bt.com）的配置文件中加入以下代码：
vi /usr/local/nginx/conf/nginx.conf
location ~*\.(jpg|gif|swf)$ {
valid_referers none blocked *.test.com test.com;
if ($invalid_referer) {
rewrite ^/http://www.bt.com/error.png;
}
}
下面分析一下这段代码：
~*\.(jpg|gif|swf)$：这段正则表达式表示匹配不区分大小写，以.jpg或.gif或.swf结尾的文件。
valid_referers：设置信任的网站，可以正常使用图片。
none：浏览器中referer为空的情况，这就是直接在浏览器访问图片。
blocked：浏览器中referer不可空的情况，但是值被代理或防火墙删除了，这些值不以http://或https://开头。
后面的网站或者域名：referer中包含相关字符串的网址。
if语句：如果链接的来源域名不在valid_referers所列出的列表中，$invalid_referer为1，则执行后面的操作，即进行重写或返回403页面。
把图片error.png放到源主机（bt.com）的工作目录下。
ls /usr/local/nginx/html
50x.html index.html logo.jpg error.png
这是重启服务器，重新访问http://www.test.com/index.html，显示的是被重写的图片。
在 Nginx 的配置文件中，通常会用两个常用的区块(Block)来进行设置：
1.Server 区块
2.Localtion 区块
sever 区块主要是真的主机的配置，比如配置主机的域名，IP，端口等内容。当然，在一个 Nginx 的配置文件里面，我们是可以指定多个 Sever 区块的配置的。而 Location 区块则是在 Sever 区块里面，细分到针对不同的路径和请求而进行的配置。因为一个站点中的 URI 通常会非常多，所以在 Location 区块设置这部分，你也是可以写多个 Location 的配置的。
location optional_modifier location_match {
# 这个 {} 里面的配置内容就是一个区块 Block
}
上面的 optional_modifier 配置项是可以使用正则表达式的。常用的几种如下:
留空。在留空的情况下，配置表示请求路径由 location_match 开始。
= ，等于号还是非常容易理解的：就是请求路径正好等于后面的 location_match 的值；跟第一项留空还是有区别的。
~，飘号（注意是英文输入的飘号）表示大小写敏感的正则匹配。
~*表示大小写不敏感的正则匹配。
^~ 表示这里不希望有正则匹配发生。
1.Server 区块
2.Localtion 区块
sever 区块主要是真的主机的配置，比如配置主机的域名，IP，端口等内容。当然，在一个 Nginx 的配置文件里面，我们是可以指定多个 Sever 区块的配置的。而 Location 区块则是在 Sever 区块里面，细分到针对不同的路径和请求而进行的配置。因为一个站点中的 URI 通常会非常多，所以在 Location 区块设置这部分，你也是可以写多个 Location 的配置的。
location optional_modifier location_match {
# 这个 {} 里面的配置内容就是一个区块 Block
}
上面的 optional_modifier 配置项是可以使用正则表达式的。常用的几种如下:
留空。在留空的情况下，配置表示请求路径由 location_match 开始。
= ，等于号还是非常容易理解的：就是请求路径正好等于后面的 location_match 的值；跟第一项留空还是有区别的。
~，飘号（注意是英文输入的飘号）表示大小写敏感的正则匹配。
~*表示大小写不敏感的正则匹配。
^~ 表示这里不希望有正则匹配发生。
0 条评论
下一页
