英语 keep alive 翻译为中文意思是点火电极；保持生机；使……活着。例如，This would keep alive the hope of a two-state solution. 这会让解决两个国家问题的希望永远都在。
Keepalive和lvs
1.两台业务系统启动着相同的服务，如果有一台故障，另一台自动接管，我们将中国称之为高可用。
2.系统可用率算法例：
-1个9：（1-90%）*365=36.5天 —->表示该系统1年时间里最多可能的业务中断时间是36.5天
-2个9：（1-99%）*365=3.65天 —-> 表示该系统1年时间里最多可能的业务中断时间是3.65天
保证系统可实时不间断的使用。
软件：keepalive
keepalive是通过vrrp（虚拟路由冗余协议）实现高可用。
通常业务系统需要保证7X24小时不down机。比如公司内部OA系统，每天公司人员都需要使用，则不允许down机。作为业务系统来说随时随地地都要求可用。
1.安装
2.配置[root@lb01 ~]#
3.启动
4.测试：keepalive高可用地址漂移
（1）keepalive提供一个VIP（虚拟IP）和vmac（虚拟Mac地址）
（2）抓包测试
（1）默认配置为抢占式：
master挂掉，backup上台，master重新启动则讲IP抢占过去。
（2）非抢占式配置：
两台均为backup，在优先级上做区分，如master挂掉，backup上台，则backup变成master，master变为backup。
a.两个节点的state均为backup(官方建议)
b.两个节点都在vrrp_instance中添加nopreempt
c.其中一个节点的优先级要高于另外一个节点
两台服务器角色都启用了nopreempt后，必须修改角色状态统一为backup，唯一的区别就是优先级不同。
keepalive高可用故障脑裂
由于某些原因，导致两台keepalive高可用服务器在指定时间内，无法检测到对方的心跳消息，各自取得资源及服务的所有权，而此时的两台高可用服务器又都还活着。
a.服务器网线松动等网络故障
b.服务器硬件故障发生损坏现象而奔溃
c.主备服务器都开启了firewalld防火墙
解决方法：
配置keepalived使用
Keep-Alive
keepalive起初是为LVS设计的，专门用来监控lvs各个服务节点的状态，后来加入了vrrp的功能，因此除了lvs，也可以作为其他服务（nginx，haproxy）的高可用软件。VRRP是virtual router redundancy protocal（虚拟路由器冗余协议）的缩写。VRRP的出现就是为了解决静态路由出现的单点故障，它能够保证网络可以不间断的稳定的运行。所以keepalive一方面具有LVS cluster node healthcheck功能，另一方面也具有LVS director failover。
keepalive的两大功能：
healthcheck和failover
LVS cluster node healthcheck
keepalive高可用服务原理介绍:
keepalive director高可用之间的故障切换转移，是通过VRRP协议实现的。
在keepalive director工作时，主节点会不断的向备节点发送心跳消息，告知自己还活着，当主节点故障时，备节点无法接收主节点的心跳消息，此时就会启用自身的服务接管程序将主节点的IP和服务资源接管过来。当主节点恢复工作之后，又会释放IP资源和服务，恢复至备节点的角色。
VRRP协议原理简单介绍：
VRRP是通过一种竞选协议协议机制来将路由的任务交给VRRP的路由器。在一VRRP的虚拟路由中，有多台物理的VRRP路由器，但是这多台路由器不同时工作，而是由一台Master负责路由工作，其他的都是backup，master是由backup竞争而来的，当master失去响应时，会从余下的backup中选出master来接管IP地址和服务资源。
VRRP协议的所有报文都是通过IP多播的形式传递消息，在一个虚拟路由器中，只有作为Master的VRRP路由器会一直发送VRRP广播包，当其他backup没有收到广播包时候，会迅速抢占master（谁的有限级高，谁就会抢占成功），处于安全性考虑VRRP协议传输数据时候进行了加密。
VRRP是virtual router redundancy protocal（虚拟路由器冗余协议）的缩写。
小结：
1，VRRP是virtual router redundancy protocal（虚拟路由器冗余协议）的缩写。
2，VRRP是通过一种竞选协议协议机制来将路由的任务交给VRRP的路由器。
3，VRRP协议的所有报文都是通过IP多播的形式传递消息
4，处于安全性考虑VRRP协议传输数据时候进行了加密。
官方网站： http://www.keepalived.org/
编译安装yum安装都可
全局配置:
VRRPD 配置:
virtual_server
VRRP同步组
两个vrrp_instance同属于一个vrrp_rsync_group，那么其中一个vrrp_instance发生故障切换时，另一个vrrp_instance也会跟着切换（即使这个instance没有发生故障）。
VRRP实例
1，Round-robin（RR）轮询：当新请求到达时候，从服务列表中选择一个Real Server，将请求重定向给这台Real Server。
2，Weighted round-robin（WRR）加权轮询：给每台Real Server分配一个权重/位列，权重越大，分到的请求数越多。
3，Destination hashing （DH）目标散列：来自于同一个IP地址的请求都被重定向到同一台Real Server上（保证目标地址不变）。
4，Source hashing（SH）源地址散列：Director必须确保响应的数据包必须通过请求数据包所经过的路由器或者防火墙（保证原地址不变）。
动态调度算法：通过检查服务器上当前连接的活动状态来重新决定下一步调度方式该如何实现。
5，Lease Connection （LC） 最少连接 哪一个Real Server上的连接数少就将下一个连接请求定向到那台Real Server上去。
【算法：连接数=活动连接数 256+非活动连接数】
6，Weight Least-Connection（WLC） 加权最少连接 在最少连接的基础上给每台Real Server分配一个权重。
【算法：连接数=（活动连接数 256+非活动连接数）÷权重】 一种比较理想的算法。
7，Shortest Expected Delay (SED) 最短期望延迟 不再考虑非活动连接数
【算法：连接数=(活动连接数+1) *256 ÷权重】
8，Never Queue (NQ) 永不排队算法，对SED的改进，当新请求过来的时候不仅要取决于SED算法所得到的值，还要取决于Real Server上是否有活动连接。
9，Locality-Based Least-Connection (LBLC) 基于本地状态的最少连接，在DH算法的基础上还要考虑服务器上的活动连接数。
10，Locality-Based Least-Connection with Replication Scheduling (LBLCR) 带复制的基于本地的最少连接 LBLC算法的改进
TCP
UDP
ESP (Encapsulation Security Payload)
IPsec 封装安全负载
AH (Authentication Header)
keepalived是实现服务器级别的接管，服务不可用无法切换keepalive，所以需要做好应用层的监控
参考链接：
https://www.cnblogs.com/qq78292959/archive/2012/05/31/2528524.html
http://www.keepalived.org/
Httpd守护进程，一般都提供了keep-alive timeout时间设置参数。比如nginx的keepalive_timeout，和Apache的KeepAliveTimeout。这个keepalive_timout时间值意味着：一个http产生的tcp连接在传送完最后一个响应后，还需要hold住keepalive_timeout秒后，才开始关闭这个连接。
当httpd守护进程发送完一个响应后，理应马上主动关闭相应的tcp连接，设置 keepalive_timeout后，httpd守护进程会想说：”再等等吧，看看浏览器还有没有请求过来”，这一等，便是keepalive_timeout时间。如果守护进程在这个等待的时间里，一直没有收到浏览发过来http请求，则关闭这个http连接。
测试结果证实是后者
http keep-alive与tcp keep-alive，不是同一回事，意图不一样。http keep-alive是为了让tcp活得更久一点，以便在同一个连接上传送多个http，提高socket的效率。而tcp keep-alive是TCP的一种检测TCP[连接]状况的保鲜机制。tcp keep-alive保鲜定时器，支持三个系统内核配置参数：
echo 1800 >/proc/sys/net/ipv4/tcp_keepalive_time
echo 15 >/proc/sys/net/ipv4/tcp_keepalive_intvl
echo 5 >/proc/sys/net/ipv4/tcp_keepalive_probes
keepalive是TCP保鲜定时器，当网络两端建立了TCP连接之后，闲置idle（双方没有任何数据流发送往来）了tcp_keepalive_time后，服务器内核就会尝试向客户端发送侦测包，来判断TCP连接状况(有可能客户端崩溃、强制关闭了应用、主机不可达等等)。如果没有收到对方的回答(ack包)，则会在 tcp_keepalive_intvl后再次尝试发送侦测包，直到收到对对方的ack,如果一直没有收到对方的ack,一共会尝试 tcp_keepalive_probes次，每次的间隔时间在这里分别是15s, 30s, 45s, 60s, 75s。如果尝试tcp_keepalive_probes,依然没有收到对方的ack包，则会丢弃该TCP连接。TCP连接默认闲置时间是2小时，一般设置为30分钟足够了。
使用http keep-alvie，可以减少服务端TIME_WAIT数量(因为由服务端httpd守护进程主动关闭连接)。道理很简单，相较而言，启用keep-alive，建立的tcp连接更少了，自然要被关闭的tcp连接也相应更少了。
HTTP 1.0中默认是关闭的，需要在http头加入”Connection: Keep-Alive”，才能启用Keep-Alive；HTTP 1.1中默认启用Keep-Alive，如果加入”Connection: close”，才关闭。
在HTTP/1.0版本中，并没有官方的标准来规定Keep-Alive如何工作，因此实际上它是被附加到HTTP/1.0协议上，如果客户端浏览器支持Keep-Alive，那么就在HTTP请求头中添加一个字段 Connection: Keep-Alive，当服务器收到附带有Connection: Keep-Alive的请求时，它也会在响应头中添加一个同样的字段来使用Keep-Alive。这样一来，客户端和服务器之间的HTTP连接就会被保持，不会断开（超过Keep-Alive规定的时间，意外断电等情况除外），当客户端发送另外一个请求时，就使用这条已经建立的连接。
从HTTP/1.1起，默认都开启了Keep-Alive，保持连接特性，简单地说，当一个网页打开完成后，客户端和服务器之间用于传输HTTP数据的TCP连接不会关闭，如果客户端再次访问这个服务器上的网页，会继续使用这一条已经建立的连接
Keep-Alive不会永久保持连接，它有一个保持时间，可以在不同的服务器软件（如Apache）中设定这个时间
心跳包
很多应用层协议都有HeartBeat机制，通常是客户端每隔一小段时间向服务器发送一个数据包，通知服务器自己仍然在线，并传输一些可能必要的数据。使用心跳包的典型协议是IM，比如QQ/MSN/飞信等协议。
心跳包 之所以叫心跳包是因为：它像心跳一样每隔固定时间发一次，以此来告诉服务器，这个客户端还活着。事实上这是为了保持长连接，至于这个包的内容，是没有什么特别规定的，不过一般都是很小的包，或者只包含包头的一个空包。
在TCP的机制里面，本身是存在有心跳包的机制的，也就是TCP的选项：SO_KEEPALIVE。系统默认是设置的2小时的心跳频率。但是它检查不到机器断电、网线拔出、防火墙这些断线。而且逻辑层处理断线可能也不是那么好处理。一般，如果只是用于保活还是可以的。
心跳包一般来说都是在逻辑层发送空的echo包来实现的。下一个定时器，在一定时间间隔下发送一个空包给客户端，然后客户端反馈一个同样的空包回来，服务器如果在一定时间内收不到客户端发送过来的反馈包，那就只有认定说掉线了。
其实，要判定掉线，只需要send或者recv一下，如果结果为零，则为掉线。但是，在长连接下，有可能很长一段时间都没有数据往来。理论上说，这个连接是一直保持连接的，但是实际情况中，如果中间节点出现什么故障是难以知道的。更要命的是，有的节点（防火墙）会自动把一定时间之内没有数据交互的连接给断掉。在这个时候，就需要我们的心跳包了，用于维持长连接，保活。
在获知了断线之后，服务器逻辑可能需要做一些事情，比如断线后的数据清理呀，重新连接呀……当然，这个自然是要由逻辑层根据需求去做了。
总的来说，心跳包主要也就是用于长连接的保活和断线处理。一般的应用下，判定时间在30-40秒比较不错。如果实在要求高，那就在6-9秒。
TCP协议的KeepAlive机制
学过TCP/IP的同学应该都知道，传输层的两个主要协议是UDP和TCP，其中UDP是无连接的、面向packet的，而TCP协议是有连接、面向流的协议。
所以非常容易理解，使用UDP协议的客户端（例如早期的“OICQ”，听说OICQ.com这两天被抢注了来着，好古老的回忆）需要定时向服务器发送心跳包，告诉服务器自己在线。
然而，MSN和现在的QQ往往使用的是TCP连接了，尽管TCP/IP底层提供了可选的KeepAlive（ACK-ACK包）机制，但是它们也还是实现了更高层的心跳包。似乎既浪费流量又浪费CPU，有点莫名其妙。
具体查了下，TCP的KeepAlive机制是这样的，首先它貌似默认是不打开的，要用setsockopt将SOL_SOCKET.SO_KEEPALIVE设置为1才是打开，并且可以设置三个参数tcp_keepalive_time/tcp_keepalive_probes/tcp_keepalive_intvl，分别表示连接闲置多久开始发keepalive的ack包、发几个ack包不回复才当对方死了、两个ack包之间间隔多长，在我测试的Ubuntu Server 10.04下面默认值是7200秒（2个小时，要不要这么蛋疼啊！）、9次、75秒。于是连接就了有一个超时时间窗口，如果连接之间没有通信，这个时间窗口会逐渐减小，当它减小到零的时候，TCP协议会向对方发一个带有ACK标志的空数据包（KeepAlive探针），对方在收到ACK包以后，如果连接一切正常，应该回复一个ACK；如果连接出现错误了（例如对方重启了，连接状态丢失），则应当回复一个RST；如果对方没有回复，服务器每隔intvl的时间再发ACK，如果连续probes个包都被无视了，说明连接被断开了。
Ref：
以上就是关于英语keep alive怎么翻译？全部的内容，如果了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！
