对于一个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库。对于上游程序来说，他是一个观察者，套进设计模式就是观察者模式，好莱坞有句名言. “不要给我打电话， 我会给你打电话”.我们暂且叫这种策略为“被动实时感知下游变化”。
先写到这里（也只想到了这些），后续有所想法再补充吧，也欢迎各位看官留言，过去的博文都长篇大论，以后尽量做到简约不简单吧。毕竟时间精力有限。
相关文章
