转载

网易视频云：也谈过载保护和隔离

什么是过载，会有什么危害? 腾讯后台开发技术总监bison[1]给出了一个很好的定义：“对于时延敏感的服务，当外部请求超过系统处理能力，如果系统没有做相应保护，可能导致历史累计的超时请求达到一定规模，像雪球一样形成恶性循环。由于系统处理的每个请求都因为超时而无效，系统对外呈现的服务能力为0，且这种情况下不能自动恢复”。

过载的这么危险，应该怎么处理？我认为应该从”过载保护“和”过载隔离“两个方面来解决。

一、过载保护

“过载保护”的关注点是在过载情况下，如何尽其所能对外服务。

bison提供了一个很棒的过载保护方案，其基本思想是区别有效请求和无效请求，系统只处理有效请求，不处理无效请求，不做无用功。主要特点是使用请求队列，每个请求带上时间戳。业务逻辑从队列取出请求之后，检查时间戳，若请求已经超时，则直接丢弃，或者返回一个失败应答。

James Hamilton[2]提供了“big red buttion”方法，即为单个功能或者服务器提供关闭启动按钮，当系统过载时，管理员可关闭一些非核心业务，从而保障核心业务的服务质量。

二、过载隔离

复杂的分布式系统由多个子系统组成，一个子系统过载可能拖慢其他子系统，甚至导致整个系统不可用，因此隔离与过载保护是息息相关的。隔离有哪些常见做法？

超时。超时机制是隔离的外部服务的首要方法，可防止一个子系统阻塞相关的子系统。这听起来简单，但没遇故障的时候，往往不受重视。

防水隔板。防水隔板将船隔离成多个独立的空间，当船漏水时，水无进入其他空间，从而避免沉船事故。防水隔板设计模式的要点是对系统进行分区，为重要服务、重要客户、重要业务预留独立资源（譬如物理服务器，CPU核，线程池等），确保不受其他子系统影响。

Michael T. Nygard在一书中还提到了“保险丝”设计模式，其核心思想是监控外部依赖服务的调用情况，如果外部服务调用超时或者失败超过一定比率，则断开“保险丝“，即不再调用外部服务而直接返回失败。”保险丝”断开状态会持续一段时间，超时之后才重新允许调用外部服务，此时若发现外部服务可用，则合上”保险丝“，恢复到原始状态。否则“保险丝”一直保持断开状态。 “保险丝“模式的主要好处是：

１）快速失败，当系统依赖的外部服务过载时，不必每次等到超时，不至于拖慢整个系统。

２）保护了外部服务。外部服务过载时，系统停止发送更多请求，降低了负载，给外部服务更多喘息机会。

原文 http://dockone.io/article/1390

正文到此结束