Failover失效转移详解

    

定义：

    失效转移通俗地说，即当A无法为客户服务时，系统能够自动地切换，使B能够及时地顶上继续为客户提供服务，且客户感觉不到这个为他提供服务的对象已经更换。

这里的A和B可以存在于各种领域，但一般fail-over特指计算机领域的数据库、应用服务、硬件设备等的失效转移。

心跳线
连接工作机与备份机的网线,通过软件的方式监视工作机,备份机一旦发现工作机由于某种原因停止服务,则立即投入使用,以保证网络的畅通和服务的正常运行.
心跳线是用于连接A、B两台服务器间的网线。在这两台服务器A、B中，A为工作机，B为备份机，它们之间通过一根心跳线来连接。一般在服务器上都配有两块网卡，其中一块专门用于两台服务器（节点）间的通讯。安装在服务器上的软件通过心跳线来实时监测对方的运行状态。一旦正在工作的主机A因为各种硬件故障，如电源失效、主要部件失效或者启动盘失效等导致系统发生故障，心跳线会反映给互为备份的另外一台主机，主机B可以立即投入工作。这样可以在最大限度上保证网络的正常运行。这也称为“心跳检测”。心跳线主要利用一条RS-233检测链路来完成，采用Ping方式检测验证系统Down机检测的准确性。

对于一个7*24小时无间断的线上服务来说，在服役时间内难免会遇到一些fail，例如db断开连接且短暂连接不上了, 下游的某个节点忽然挂了，运维部署上依赖的某一个东西不存在了等等场景。本文主要来讨论一下这些场景使用怎样的策略会比较好。

　　最简单的方法，While(true) + sleep(固定时间)  不断的重试，直到成功为止。这个方法的优点就是简单,可依赖。缺点就是对于感知延迟要求比较严格的程序，会消耗大量的CPU，甚至因为一些不合理的逻辑导致CPU满载等等情况发生.这种简单粗暴的方法应用广泛，并且能解决实际问题，在很多场合还是非常可取. 我们暂且叫这种策略为”粗暴法”.

　　我曾经在一个实时文件抓取程序中（类似于scribe这样的实时日志传输方案），使用了这样的策略，当fstat源文件发现文件不存在的时候，我会重试1000次，每次间隔sleep 10ms, 其间程序会输出很多warnning信息来支持一些报警等，重试完1000次之后（10s之后），将sleep间隔设置为固定时间，例如1s,在降低程序对CPU的消耗的同时，保证了一定的实时性，源文件无论什么时候出现都能够确保在1s内cover进来，而且这样的策略对于日志切分场景也非常实用,普通的日志切分（如切分nginx为每小时一个文件,crontab每小时mv access.log access.log.$date再 kill -USR1等）程序能够立马感知到并作出相应的策略调整。我们暂且叫这种策略为”重试N次后，将间隔时间调整为最大的可接受值”.

　　再看看另外一种方法，最近看了下facebook scribe的源码（感兴趣的自己google,大家可以姑且的认为是一个多下游的日志转发工具）,他在下游死掉了之后选择对sleep时间循序渐进的策略，每次将retryInterval *1.414; (sqrt(2)),再加上一个范围随机数（如1-100ms）,同时来设定了一个最大值的方式来相对动态的判断下游状态. 为什么一定要设置最大值呢？因为这个策略在异常时间久了之后，滞后性会非常大，当一场恢复时，可能不能及时感知，所以需要一个最大值做保证。我们暂且叫这种策略为“重试时间循序渐进, 且确保不大于最大可接受值“.

　　近两年来使用zookeeper（以下简称zk）的公司越来越多,很多公司都用zk来做大型分布式系统的协调，他的模式类似于：下游通过在zk上注册一个临时节点，告诉大家，我活着呢, 上游通过watch这个节点的变化来感知下游的变化。模式很简单，但是大家都是用zk是因为他提供了很多额外的东西，例如下游注册的临时节点在下游宕机，或者网络不可达（反正就是挂了）等等情况下会自动清除，并且通过回调函数实时让上游程序感知，作出相应变化，当下游活了之后，又注册一个临时节点宣称自己活了，上游程序也能通过回调函数实时感知。上游程序依赖zookeeper的一个Lib库。对于上游程序来说，他是一个观察者，套进设计模式就是观察者模式，好莱坞有句名言. “不要给我打电话， 我会给你打电话”.我们暂且叫这种策略为“被动实时感知下游变化”。

参考网站：http://www.open-open.com/lib/view/open1426302208701.html