导火索

　　由于产品特性(例如提前通知大量用户，未来某某时刻将进行一项活动;类似奥运门票，大量用户提前得知信息：某日开始发售门票)，大量的用户聚集在同一时刻发起了大量请求，超出了后台serverD的大负载能力。操作响应失败的用户又重试， 中间系统的重试，进一步带来了更大量的请求(正常情况下的9倍)。导致所有用户操作都是失败的。

　　过载分析

　　只是导火索不一样，同案例一，巨大的请求和处理能力之间的鸿沟，导致后端serverD的4M大小的接收缓冲区迅速填满(4秒填满)，且过载时间内，接收缓冲区一直都是满的。而处理完缓冲区内的请求，ServerD需要6秒以上(4MB / 400 / 1500 = 6.7S)。所以serverD处理的请求都是6s之前放入缓冲区的，而该请求在前端早已经超时。雪球形成了。

　　启示

　　1、 每个系统，自己的大处理能力是多少要做到清清楚楚。例如案例一中的前端进程A，他的大处理能力不是50次/s，也不是20次/S，而是10次/S。因为它是单进程同步的访问后端B， 且访问后端B的超时时间是100ms，所以他的处理能力是1S/100ms=10次/S。而平时处理能力表现为50次/S，只是运气好。

　　2、 每个系统要做好自我保护，量力而为，而不是尽力而为。对于超出自己处理能力范围的请求，要勇于拒绝。

　　3、 每个系统要有能力发现哪些是有效的请求，哪些是无效的请求。上面两个案例中，过载的系统都不具备这中慧眼，逮着请求做死的处理，雪球时其实是做无用功。

　　4、 前端系统有保护后端系统的义务，sla中承诺多大的能力，只给到后端多大的压力。这要求每一个前后端接口的地方，都有明确的负载约定，一环扣一环。

　　5、 当过载发生时，该拒绝的请求(1、超出整个系统处理能力范围的;2、已经超时的无效请求)越早拒绝越好。像上海机场到市区的高速上，刚出机场有电子公示牌显示，进入市区某某路段拥堵，请绕行。

　　6、 对于用户的重试行为，要适当的延缓。例如登录发现后端响应失败，再重新展现登录页面前，可以适当延时几秒钟，并展现进度条等友好界面。当多次重试还失败的情况下，要安抚用户。

　　7、 产品特性设计和发布上，要尽量避免某个时刻导致大量用户集体触发某些请求的设计。发布的时候注意灰度。

　　8、 中间层server对后端发送请求，重试机制要慎用，一定要用的话要有严格频率控制。

　　9、 当雪球发生了，直接清空雪球队列(例如重启进程可以清空socket 缓冲区)可能是快速恢复的有效方法。

　　10、过载保护很重要的一点，不是说要加强系统性能、容量，成功应答所有请求，而是保证在高压下，系统的服务能力不要陡降到0，而是顽强的对外展现大有效处理能力。

 　　对于“每个系统要有能力发现哪些是有效的请求，哪些是雪球无效的请求”，这里推荐一种方案：在该系统每个机器上新增一个进程：interface进程。Interface进程能够快速的从socket缓冲区中取得请求，打上当前时间戳，压入channel。业务处理进程从channel中获取请求和该请求的时间戳，如果发现时间戳早于当前时间减去超时时间(即已经超时，处理也没有意义)，直接丢弃该请求，或者应答一个失败报文。

　　Channel是一个先进先出的通信方式，可以是socket，也可以是共享内存、消息队列、或者管道，不限。

　　Socket缓冲区要设置合理，如果过大，导致及时interface进程都需要处理长时间才能清空该队列，不合适了。建议的大小上限是：缓存住超时时间内interface进程能够处理掉的请求个数(注意考虑网络通讯中的元数据)。