项目基于kafka项目中有使用到这个keepalived的工作原理机制，所以在这里简单介绍一下keepalived，详细的可以查看官方文档。
官方地址：https://keepalived.readthedocs.io/en/latest/introduction.html
负载均衡是一种在真实服务器集群之间分配ip流量的方法，可以提供一个或者多个高度可用的虚拟服务。在设计负载均衡拓扑的时候，必须考虑到负载均衡器本身以及背后的真实服务器的可用性。
keepalived为负载均衡和高可用性提供了框架。负载均衡框架依赖于众所周知而且广泛使用的Linux虚拟服务器（IPVS）内核模块，该模块提供第4层负载均衡。
keepalived实现了一组运行状况检测器，以根据其运行状况动态、自适应地维护和管理负载均衡的服务器池。高可用性是通过虚拟冗余路由协议（VRRP）实现的。
每个 Keepalived 框架可以单独使用，也可以一起使用，以提供弹性基础架构。
在这种情况下，负载平衡器也可以称为控制器或LVS路由器。
简单而言，keepalived提供了两个主要功能：
- LVS系统的运行状况检查
- 实现VRRPv2堆栈以处理负载均衡器故障转移。
1、keepalived简介
keepalived是Linux下一个轻量级的高可用的解决方案。高可用（High Avalilability,HA），其中有两种不同的含义：广义来讲，是指整个系统的高可用，狭义来讲就是主机的冗余和接管。
它与HeartBeat RoseHA实现相同类似的功能，都可以实现服务或者网络的高可用，但是又有差别，HeartBeat是一个专业的、功能完善的高可用软件。它提供了HA软件所需的基本功能，比如：心跳检测、资源接管、检测集群中的服务，在集群节点转移共享ip地址的所有者等等。HeartBeat的功能很强大，但是部署和使用都相对比较麻烦。
Keepalived主要是通虚拟路由冗余来实现高可用功能，功能虽然没有Heart RoseHA强大，但是keepalived的部署和使用都非常简单，所有的配置都只需要一个配置文件就可以完成。
2、Keepalived是什么？
keepalived首先是为LVS设计的，专门用来监控集群系统中各个服务器节点的状态，它根据TCP/IP参考模型的第三、第四层、第五层交换机机制检测各个节点的状态，如果某个服务器节点出现异常，或者是工作出现故障，Keepalived将会检测出来，并将检测出的故障的服务器节点从集群系统中剔除，这些工作全部是自动完成的，不需要人工干涉，需要人工完成的只是修复出现故障的服务节点。
Keepalived中又加入了VRRP的功能，VRRP（Vritual Router Redudancy Protocol），虚拟路由冗余协议，出现的目的就是解决静态路由出现的单点故障问题，通过VRRP可以实现网络间不断稳定运行，因此Keepalived一方面具有服务器状态检测和故障隔离功能，另外一方面也有HA cluster功能。
3、VRRP协议的工作原理
在现实的网络环境中。主机之间的通信都是通过配置静态路由或者（默认网关）来完成的，而主机之间的路由器一旦发生故障，通信就会失效。因此在这种通信模式下，路由器就成了一个单点瓶颈，而引入了VRRP协议就可以解决这个问题。
VRRP协议是一种主备模式的协议，通过VRRP可以在网络发生故障的时候透明的进行设备之间的切换而不影响到主机之间的数据通信，这其中的涉及到的：物理路由器和虚拟路由器。
VRRP可以将两台或者多台物理路由器设备虚拟成一个虚拟路由，这个虚拟路由通过虚拟IP（一个或者多个）对外提供服务，而在虚拟路由器内部十多个物理路由器协同工作，同一时间只有一台物理路由器对外提供服务，这台物理路由设备被成为：主路由器（Master角色），一般情况下Master是由选举算法产生的，它拥有对外服务的虚拟IP，提供各种网络功能，如：ARR请求、icmp数据转发等，而且其它的物理路由器不拥有对外的虚拟IP，也不提供对外网络功能，仅仅接收MASTER的VRRP状态通告信息，这些路由器被统称为“BACKUP"的角色，当主路由器失败时，处于BACKUP角色的备份路由器将重新进行选举，产生一个新的主路由器进入MASTER角色，继续对外提供服务，整个切换对用户来说是完全透明的。
每个虚拟路由器都有一个唯一的标识号，称为VRID，一个VRID与一组ip地址构成一个虚拟路由器，在VRRP协议中，所有的报文都是通过IP多播方式发送的，而在一个虚拟路由器中，只有处于Master角色的路由器会一直发送VRRP数据包，处于BACKUP角色的路由器只会接受可用时，BACKUP也就无法收到Master发过来的信息，于是就认定Master出现故障，接着多台BACKUP就会进行选举，优先级最高的BACKUP将称为新的MASTER，这种选举角色切换是非常快的，因而保证了服务的持续可用性。
4、keepalived的工作原理？
为LVS负载均衡软件设计的keepalived正常启动的时候，共启动3个进程，一个是父进程，负责监控其子进程，一个是vrrp子进程，另外一个是checkers子进程两个子进程都被系统watchdog看管，两个子进程各自负责自己的事。
三个进程：
- 父进程：内存管理，负责监控其子进程
- 子进程：
- vrrp子进程，用来实现vrrp协议。
- checkers子进程，负责healthchecker（健康检查）包括了各种健康检查方式，以及对应的配置文件的解析（healthchecker是检查后端的real server是否宕机，如果出现问题了，keepalived在做负载均衡的时候，就不再给这台服务器转发请求）。
Keepalived高可用对之间是通过 VRRP进行通信的， VRRP是通过竞选机制来确定主备的，主的优先级高于备，因此，工作时主会优先获得所有的资源，备节点处于等待状态，当主宕机的时候，备节点就会接管主节点的资源，然后顶替主节点对外提供服务。在 Keepalived服务对之间，只有作为主的服务器会一直发送 VRRP广播包,(VRRP通告(advertisement)。它使用IP多播数据包进行封装，组播地址为224.0.0.18告诉备它还活着，此时备不会枪占主，当主不可用时，即备监听不到主发送的广播包时，就会启动相关服务接管资源，保证业务的连续性.接管速度最快；
keepalived主要有三个模块，分别是core、check和vrrp。
core：是keepalived的核心，负责主进程的启动和维护，全局配置文件的加载解析等
check：负责healthchecker(健康检查)，包括了各种健康检查方式，以及对应的配置的解析包括LVS的配置解析；可基于脚本检查对IPVS后端服务器健康状况进行检查。
vrrp：VRRPD子进程，VRRPD子进程就是来实现VRRP协议的。
负载均衡和高可用性是2个概念。
负载均衡：将很多的请求分散到后端很多的服务器上是为了化解压力的一个软件
高可用： 有2个或者多个服务器（人）做相同的事情，互相备份。
5、keepalived的配置
启动一个vrrp的实例 VI_1 实例名，可以自定义
vrrp_instance VI_1 { state MASTER --》角色是master i nterface ens33 --》在哪个接口上监听vrrp协议，同时绑定vip到那个接口 virtual_router_id 105 --》虚拟路由id（帮派） 0~255范围 priority 120 ---》优先级 0~255 advert_int 1 --》advert interval 宣告消息 时间间隔 1秒 authentication { 认证 auth_type PASS 认证的类型是密码认证 auth_pass 11112222 具体的密码，可以自己修改 } virtual_ipaddress { --》vip的配置，vip可以是多个ip 192.168.200.16 192.168.200.17 } }
配置双vip，两台LB都要配置成互为主备。
6、keepalived的脑裂现象
在高可用（HA）系统中，当联系2个节点的“心跳线”(vrrp原理)断开时，本来为一整体、动作协调的HA系统，就分裂成为2个独立的个体。由于相互失去了联系，都以为是对方出了故障。两个节点就会去抢master，从而形成脑裂。
出现的原因：根本原因就是两台机器之间失去了联系，收不到vrrp广播，就会去竞争master。
具体原因：高可用服务器对之间心跳线链路发生故障，导致无法正常通信。因心跳线坏了（包括断了，老化）。因网卡及相关驱动坏了，ip配置及冲突问题（网卡直连）因心跳线间连接的设备故障（网卡及交换机）因仲裁的机器出问题（采用仲裁的方案，这个不知道百度一下）高可用服务器上开启了 iptables防火墙阻挡了心跳消息传输。高可用服务器上心跳网卡地址等信息配置不正确，导致发送心跳失败其他服务配置不当等原因，如心跳方式不同，心跳广插冲突、软件Bug等。
后果：在实际应用中会导致数据完整性遭到破坏！！！但是在我们的项目(web集群)实验中没有什么影响，反而会达到一种负载均衡的效果。
7、keepalived的健康检测
keepalived主要有三个模块，分别是core、check和vrrp。core模块为keepalived的核心，负责主进程的启动、维护以及全局配置文件的加载和解析。check负责健康检查，包括常见的各种检查方式。vrrp模块是来实现VRRP协议的。
对后端realserver的健康检查方式：
TCP_CHECK：工作在第4层，keepalived向后端服务器发起一个tcp连接请求，如果后端服务器没有响应或超时，那么这个后端将从服务器池中移除。
HTTP_GET：工作在第5层，向指定的URL执行http请求，将得到的结果用md5加密并与指定的md5值比较看是否匹配，不匹配则从服务器池中移除；此外还可以指定http返回码来判断检测是否成功。
HTTP_GET：可以指定多个URL用于检测，这个一台服务器有多个虚拟主机的情况下比较好用。SSL_GET：跟上面的HTTP_GET相似，不同的只是用SSL连接
MISC_CHECK：用脚本来检测，脚本如果带有参数，需将脚本和参数放入双引号内。
脚本的返回值为：
0： 检测成功 ；
1： 检测失败，将从服务器池中移除；
2－255：检测成功；
如果有设置misc_dynamic，权重自动调整为 退出码-2，如退出码为200，权重自动调整为198=200-2。
SMTP_CHECK：用来检测邮件服务的smtp的。
