常见的硬件负载均衡器有：F5，A10，Citrix
常见的软件负载均衡器有：nginx（七层），lvs（四层），haproxy（四层七层都可以）
四层和七层有什么区别：四层设备只解析四层协议，所以对于应用层协议是什么内容不做处理，由于不解析更高层次协议，所以工作性能更好，所以例如不能根据用户的URL/URI来做负载均衡。
工作在七层的反向代理负载均衡设备，它是为某些特定协议提供的，因此他能精确解码该协议，而且还能再该协议上作出修改之后做出负载均衡，操纵能力更强。
--------------------
LVS简介：
LVS-Linux Virtual Server
它能够接受用户请求，根据用户地址提供的IP和端口号来判定是不是需要转发至后端Real server，因为它是一个四层设备，他能够解析三层和四层请求，所以能够识别用户请求的IP和端口。
LVS工作机制：
LVS工作在Input链上，当用户的请求到达本机之后，一旦发现是本机（地址加端口）的请求，立即转到Input链上，而LVS就监控在Input链上，并且在input链上设置规则，一旦发现用户请求的是一个集群服务，会强行修改报文的行程，本来过了input该去用户空间了，强行将该报文送往forward链，并通过forward送往postrouting，转发至其他主机，所以LVS不能和iptables同时使用。
防火墙是使用iptables管理工具来管理内核模块netfilter，LVS是使用ipvsadm管理工具来管理内核模块ipvs。
ipvsadm：管理集群服务的命令行工具
ipvs：内核模块
注意：此处不经过forward链
所以只要你在内核中编译已经支持了ipvs的功能，并且你在用户空间已经安装了ipvsadm，那么就能够实现负载均衡集群的调度器。
那怎么转发到后端服务器呢？
根据调度算法，就是挑选一个后端服务器接受一个新请求的计算机制，如果一个用户请求的是这个调度器的22端口，报文到达input链上，ipvs发现用户请求不是这个集群服务，那么这个请求就到达用户空间，所以它（ipvs）只对定义了集群服务的服务像后端转发，而非集群服务的服务不转发，一个服务的监听通常都是一个套接字，所以根据套接字来判断是不是向后转发，以及转发到什么地方去，这种设备叫四层交换或者四层路由。
一个调度器可以调度多个集群，比如两个集群使用同一个调度器，当用户请求80的时候，有一组real server，如果用户请求的是一个443端口（https）/25端口（邮件服务）的服务，就行向另外一个集群调度。
LVS的类型：
NAT：地址转换
前端的Director需要两个网络接口（至少），一个网络接口面向于互联网，另外一个接口以内网形式面向于各个real server，用户请求到达的时候，它是将用户请求的目标地址转换为real server中的某一个地址的方式来实现的。
Director不仅要处理用户入站的请求，还要将出去的请求做地址转换，进出的连接都要经过Director，所以他能带动的real server是有限的。
real server的网关要指向DIP，要不然报文没办法出去。
什么是端口映射？
用户请求的是80端口的服务，但在后端没有工作在80上，而是工作在8080上。前端请求一个端口，后端使用不同的端口来响应。
工作在NAT模式下的几个基本法则：
1、集群节点（real server和Director）必须在同一网络中
2、RIP通常都是私有IP，而且仅用于各集群节点之间的通信
3、Director位于client和real server之间，将负责处理所有的通信
4、real server必须将网关指向DIP
5、Director支持端口映射
6、real server可以使用任意操作系统，只要Director自身是Linux就可以了，因为要使用LVS
7、较大规模的应用场景中，一个单独的Director很有可能成为系统瓶颈。
----------------------
TUN ：IP隧道
工作原理类似于DR模型，但是区别就是Director转发给real server时方式的不同，在到达Director之前，源IP是CIP，目标IP是VIP，经过Director转发之后，源地址和目标地址不变，在原有IP头部上在封装一层IP首部，源IP为DIP，目标IP 为RIP，RIP收到之后拆掉外层封装，发现里边还有一层IP首部，就知道用IP报文再来发送另外一个IP报文，就叫隧道，借助于IP报文，再发送一个IP报文。
拆掉之后，源IP为CIP，目标IP为VIP，自己有VIP，从而创建响应报文，源地址是VIP，目标地址是CIP。
TUN模型基本法则：
1、各集群节点可以不再同一物理网络
2、real server必须是公网地址
3、Director仅处理入站请求
4、real server网关不能指向Director
5、只有支持隧道功能的OS才能用于real server
6、不支持端口映射
----------------------
DR：直接路由
用户请求来了之后通过交换机到达Director，Director知道自己有三个real server，根据调度算法挑选一个real server，将请求直接转发给real server，real server直接创建回应报文，通过交换机回应给客户端，不再需要经过Director，所以Director只需要处理进来的请求。
用户请求过程：
但是用户请求的时候，源IP是CIP，目标IP是VIP，real server回应的源IP是RIP，目标IP是CIP，Client根本没有请求RIP，所以不会接受该报文。那响应报文应该是VIP，所以在DR模型中，Director和real server都配有VIP，但是四个主机都有同一个VIP就出现地址冲突了，所以每个主机都有两个地址，一个配置在网卡（DIP/RIP）上，一个配置在网卡别名（VIP）上，VIP是配置在网卡别名的，并且是隐藏的，所在在整个网络上广播以下，问问谁是VIP？他们是不会回答的，只有在响应客户端请求的时候作为源地址使用。
客户端请求的时候，路由器将用户请求封装成帧，源MAC是路由器MAC，目标MAC是DirectorVIP所在的网卡的MAC地址，他怎么知道Director上VIP的MAC呢？通过ARP地址解析（广播方式），每一个real server不能受到，不会响应，只有Director上的VIP响应。
那Director怎么发给各个real server呢？
不需要修改目标地址，在DR模型中，Director转发报文到各real server时候，不需要修改目标地址的方式来实现的，而是仅仅修改了MAC地址。
所以每个DIP和RIP都可以通过ARP解析得到相应的MAC地址，所以当用户的请求到达Director上之后，Director发现请求的是一个集群服务，所以他不会拆IP首部的，只是把MAC首部拆了，在重新封装：源MAC改为Director的MAC，目标MAC就是调度算法挑出来的RMAC，real server收到之后发现MAC是自己的，拆掉之后IP也是自己的，由此，报文接受下来，响应时候人家请求的是VIP，用VIP响应，所以源IP是VIP，目标IP是CIP。
DR模型遵循的基本法则：
1、各集群节点必须跟Director在同一物理网络中
2、RIP地址可以不用是私有IP，好处就是如果Director坏了，你可以直接访问RIP，也可以获得服务，如果使用公网地址，可以直接连接进来进行管理。
3、Director仅处理入站请求，响应报文则由real server直接发往客户端
4、real server不能将网关指向DIP
5、Director无法实现端口映射
6、大多数操作系统都可以用在real server上，因为real server必须要能够隐藏VIP
7、DR中的Director能够处理更多的real server
----------------------
LVS的调度算法：
固定调度方法：
根据算法本身进行调度，不考虑服务器当前正在建立的或者已经建立的活动连接和非活动连接的状况。
活动连接：已经接受用户请求，正在进行数据传输。
非活动连接：连接建立，数据传输已经完毕，但尚未断开。
rr：轮询
wrr：加权轮询
sh：source hash，源地址hash，只要是来自同一个客户端的用户请求，都发至同一个real server，在调度器内部保存了一张表，哪一个源地址的hash结果挑选了哪一个服务器，每一个用户请求来了之后，计算一些hash结果，并比较hash表，只要有对应的条目，就转发至该服务器。破坏了负载均衡的效果。那为什么要用这种方式？
假如是一个商品服务器，这个服务器需要追踪用户以前都浏览了一些什么商品，这些商品保存在一个session中，那什么是session？
web（http）协议是无状态怎么办？后来的web服务器就引入了cookie的机制，cookie是用来让服务器端追踪客户端的一种机制，当用户第一个请求服务器的时候，服务器会返回一个身份标识信息给客户端，客户端会保存在本地（浏览器）的cookie文件里边，而后在请求该服务器的时候，会将该cookie信息附加在信息里边发送给该服务器，服务器借此来追踪客户端身份。
现在的cookie都是轻cookie，不包含用户用户以前的浏览信息，仅仅用来标识用户身份，而用户的浏览信息都保存在服务器端，服务器端在内存中会为每一个cookie关联一段内存区域，这段内存区域叫做session。当一个用户一段时间不再访问，就会将session信息清除。
但是该服务器挂了，用户加入的商品信息全没有了，为了避免这种情况的发生，导致session’4丢失该怎么办？将session永久存储，将所有的session保存在一个共享存储中（Redis/Memcached，因为session要保存在内存中），或者将服务器做成一个集群，各自共享自己内存中的session信息。
如果我们引入session共享了，就不需要sh算法了.
dh：目标地址hash，他也是将来自于同一个地址的请求，发送给同一个服务器。（hash圆）
最长用于缓存服务器的场景当中
第一个用户请求了，这个请求轮到了第一个cache server，cacheserver上没有，就去realserver中找，找到了，先缓存一份至本地，然后再发送一份给客户端，当第二个用户请求来了之后，请求的是同一个内容，应该发往同一个cacheserver 上去，为了提高缓存命中率，只能发往同一个cacheserver。
动态调度方法：
lc：最少连接，怎么计算谁的连接少，谁的连接多呢？是通过计算当前后端每一个活动连接以及非活动链接的总数并作比较之后，哪一个最少就使用哪一个。
active*256+inactive谁的小就选谁。
wlc：加权最少连接，谁小给谁
（active*256+inactive）/weight
不能确定第一次就选中最优秀的
sed：最短期望延迟：谁小给谁（忽略inactive）
（active+1）*256/weight
只能确定第一次挑中的是最优秀的，而后可能其他的服务器都要忙死了，可能有的服务器还没有连接请求
nq：never queue用不排队（基于sed算法的，不考虑inactive）
如上图，c有了，B有了，所以，第三个肯定给A，然后再根据权重进行计算。
LBLC：基于本地的最少连接（动态的dh）
类似于dh算法，但是来了一个新请求之后，会挑选一个最闲的服务器，并不是按次序轮流，有可能会破坏命中率。
LBLCR：基于本地的带复制功能的最少链接
只要是个新请求，一定会发给连接数最少的real server，这样会破坏缓存命中率，并不会，cache中会通过内容分发协议实现缓存共享的，如果一个请求在cache上没有，它不会去后端数据服务器上去找，而是去另外一个cache server上去找，找了的给自己缓存一份。
但是并不是我将所有的共享给你，而是你没有了，你来我这要，我有了我给你一份。它可以保证同一个请求尽量去同一个服务器上去，只有新请求才会进行挑选。
ipvs默认方法是：wlc
--------------------------
keepalived：
keepalived是用C语言编写的路由软件，该项目的主要目标是为Linux系统和基于Linux的基础结构提供负载均衡和高可用的简单而强大的功能。负载均衡框架依赖于提供第四层负载平衡的著名而广泛使用的Linux虚拟服务器（IPVS）内核模块。keepalived实现了一组检查器，以根据其运动状态动态，自适应的维护和管理负载平衡的服务器池。另一方面，VRRP实现了高可用性协议，VRRP是路由器故障转移的基础。此外，Keepalived还实现了一组VRRP有限状态机的挂钩，从而提供了低级和高速协议交互。为了提供最快的网络故障检测，Keepalived实施BFD协议。VRRP状态转换可以考虑BFD提示来驱动快速状态转换。Keepalived框架可以独立使用，也可以一起使用以提供弹性基础架构。
VRRP：虚拟路由冗余协议
虚拟路由冗余协议，为了解决局域网中配置静态网关出现单点失效现象的路由协议。广泛应用在边缘网络中，设计目标是支持特定情况下IP数据流量失败转移不会引起混乱，允许主机使用单路由器，以及及时在实际第一跳路由器使用失败的情形下仍能维护路由器件的连通性。
BFD：双向转发检测
双向转发检测，BFD是一种全网同意的检测机制，用于快速检测，监控网络中链路或者IP路由的转发连通状况。BFD控制报文封装在UDP报文中传送，对于单挑检测其UDP目的端口号为3784，对于多条检测其UDP目的端口号为4784或3784.
面试题：请解答一下keepalived的工作原理。
keepalived高可用对之间是通过VRRP通信的，因此，我从VRRP开始给您讲起：
1）VRRP，虚拟路由冗余协议，VRRP的出现是为了解决静态路由的单点故障。
2）VRRP是通过一种竞选协议机制来将路由任务交给某台VRRP路由器的。
3）VRRP用IP多播的方式（默认多播地址224.0.0.18）实现高可用对之间通信
4）工作时主节点发包，备节点收包，当备节点接收不到主节点发的数据包时，就启动接管程序接管主节点的资源。备节点可以有多个，通过优先级竞选，但一般keepalived系统运维中都是一对
5）VRRP使用了加密协议加密数据，keepalived官方目前还是推荐用明文的方式配置认证类型和密码。
介绍完VRRP，接下来我再介绍一下keepalived服务的工作原理：
keepalived高可用对之间通过VRRP进行通信的，VRRP是通过竞选机制来确定主备的，主的优先级高于备，因此，工作时主会优先获得所有的资源，备节点处于等待状态，当主挂了的时候，备节点就会接管主节点的资源，然后顶替主节点对外提供服务。
在keepalived服务对之间，只要作为主的服务器会一直发送VRRP广播包，告诉备他还活着，此时备不会抢占主，当主不可用时，备就会启动相关服务接管资源，保证业务的连续性，接管速度最快可以小于1秒。