failover机制的小讨论

时间:2021-09-30 01:03:40

  对于一个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库。对于上游程序来说,他是一个观察者,套进设计模式就是观察者模式,好莱坞有句名言. “不要给我打电话, 我会给你打电话”.我们暂且叫这种策略为“被动实时感知下游变化”

  先写到这里(也只想到了这些),后续有所想法再补充吧,也欢迎各位看官留言,过去的博文都长篇大论,以后尽量做到简约不简单吧。毕竟时间精力有限。