什么是过载,会有什么危害? 腾讯后台开发技术总监bison[1]给出了一个很好的定义:“对于时延敏感的服务,当外部请求超过系统处理能力,如果系统没有做相应保护,可能导致历史累计的超时请求达到一定规模,像雪球一样形成恶性循环。由于系统处理的每个请求都因为超时而无效,系统对外呈现的服务能力为0,且这种情况下不能自动恢复”。
过载的这么危险,应该怎么处理?我认为应该从”过载保护“和”过载隔离“两个方面来解决。
一、过载保护
“过载保护”的关注点是在过载情况下,如何尽其所能对外服务。
bison提供了一个很棒的过载保护方案,其基本思想是区别有效请求和无效请求,系统只处理有效请求,不处理无效请求,不做无用功。主要特点是使用请求队列,每个请求带上时间戳。业务逻辑从队列取出请求之后,检查时间戳,若请求已经超时,则直接丢弃,或者返回一个失败应答。
James Hamilton[2]提供了“big red buttion”方法,即为单个功能或者服务器提供关闭启动按钮,当系统过载时,管理员可关闭一些非核心业务,从而保障核心业务的服务质量。
二、过载隔离
复杂的分布式系统由多个子系统组成, 一个子系统过载可能拖慢其他子系统,甚至导致整个系统不可用,因此隔离与过载保护是息息相关的。隔离有哪些常见做法?
超时。超时机制是隔离的外部服务的首要方法,可防止一个子系统阻塞相关的子系统。这听起来简单,但没遇故障的时候,往往不受重视。
防水隔板。防水隔板将船隔离成多个独立的空间,当船漏水时,水无进入其他空间,从而避免沉船事故。防水隔板设计模式的要点是对系统进行分区,为重要服务、重要客户、重要业务预留独立资源(譬如物理服务器,CPU核,线程池等),确保不受其他子系统影响。
Michael T. Nygard在一书中还提到了“保险丝”设计模式,其核心思想是监控外部依赖服务的调用情况,如果外部服务调用超时或者失败超过一定比率,则断开“保险丝“,即不再调用外部服务而直接返回失败。”保险丝”断开状态会持续一段时间,超时之后才重新允许调用外部服务,此时若发现外部服务可用,则合上”保险丝“,恢复到原始状态。否则“保险丝”一直保持断开状态。 “保险丝“模式的主要好处是:
1) 快速失败,当系统依赖的外部服务过载时,不必每次等到超时,不至于拖慢整个系统。
2)保护了外部服务。外部服务过载时,系统停止发送更多请求,降低了负载,给外部服务更多喘息机会。