在前面的博文中， 我们聊过系统过载、雪崩和过载保护， 今天继续聊聊， 顺便看看一个实例。
过载： 超过系统负载。
雪崩： 系统过载导致不可用，系统对外的服务能力通常急剧降为零。
过载保护： 剔除过载或者已经超时（过时）的请求，从而保证系统尽可能能用。
举个例子：
你每天只能处理1项任务， 然后领导每天给你塞1项任务， 你可以很轻松地应对， 领导也很高兴，因为每天给你任务后， 你都在1天之内给他结果。但是，我们来考虑两种情况：
（1）如果某天你生病了， 处理能力下降， 任务没法在当天内完成， 而领导第2天继续给你任务，你会感觉到任务堆积， 不堪重负， 对于你来说， 其实就是过载了。
（2）如领导每天给你10项任务， 那么每天会有9项任务处理不完， 而领导第2天又给你10项任务， 这样你的任务列表就一直在不断堆积和增长， 尽管你辛辛苦苦地每天还在继续处理1项任务， 但是， 由于任务堆积和排队， 在领导看来， 每次交给你任务后， 你都没法在预定的1天之内给他这项任务的结果。 其实，这就是过载了。
上面两种情况会导致过载， 久而久之， 任务队列越来越长， 堆积的任务越来越多， 你自己越来越不堪重负。那么， 对你而言， 你每天还是处理任务， 而在领导看来， 你每天都没有达到他的要求（他给你任务时，预期1天就有结果， 但由于排队，所以达不到时间要求）， 领导认为你的能力是零. 这就是雪球越滚越大导致的雪崩。
怎么办呢？ 要么让领导不要给你派发那么多任务， 要么自己丢下沉积的的过时任务，只处理新来的任务， 做到部分达到要求，不至于完全雪崩。 这就是过载保护。当然， 肯定有其他更多的思路和方法来实现过载保护。
在实际的后台开发中， 要注意防止雪崩。 对有些业务来说， 高峰时期的请求量可能瞬间涨到平时的10倍以上。比如， 大家都在元旦的凌晨零点零分发朋友圈， 表达新年愿望， 那么， 在短短的几秒内， 微信后台的请求量就是平时的n倍， 如果不提前做好压测、扩容、柔性等准备， 那么系统失败率就会上升， 此时用户那边看到失败后， 就立即重试， 不断重试， 请求量又翻倍， 雪球又在滚， 直到最后服务失败率急剧上升。
最近呢， 在我负责的业务中， 出现了一个性能瓶颈， 业务高峰期， 流量飙升到前一时刻的3-4倍， 失败率迅速上升， 一时间， 大家都没有找到原因， 最开始以为是坏人每天准时刷我们的系统， 也猜测是不是有脚本在跑， 查了很长时间。 后来发现是数据库瓶颈的问题， 于是进行了sql优化， 还是不能解决问题， mysql怎么会那么慢呢？ 最后发现， 是qps到了瓶颈， 需要对mysql进行扩容， 扩容后， 就一切OK.
原来， 是这样的：后台的mysql出现了qps瓶颈， 后台服务的延时上升， 单纯扩容后台逻辑层机器没有什么卵用。 延时上升导致客户端失败率增加， 而客户端又有自动重试3次的逻辑， 所以流量急剧飙升， 请求流量的飙升又导致了后台mysql的更大压力， 于是雪崩。 好在后台框架有过载保护机制， 勉强能提供小部分正常服务。
好了， 来看看图： 绿线是出问题的全天监控， 红线是扩容mysql后的全天监控， 可以看到， 问题搞定：
总算搞定了。