过载保护

1. 每 个系统，自己的最大处理能力是多少要做到清清楚楚。
   
2. 每个系统要做好自我保护，量力而为，而不是尽力而为。对于超出自己处理能力范围的请求，要勇于拒绝
   
3.  每个系统要有能力发现哪些是有效的请求，哪些是无效的请求。过载的系统都不具备这中慧眼，逮着请求做死的处理，雪球时其实是做无用功。
   
4. 前端系统有保护后端系统的义务，sla中承诺多大的能力，就只给到后端多大的压力。这就要求每一个前后端接口的地方，都有明确的负载约定，一环扣一环。
   
5. 当过载发生时，该拒绝的请求（1、超出整个系统处理能力范围的；2、已经超时的无效请求）越早拒绝越好。就像上海机场到市区的高速上，刚出机场就有电子公示牌显示，进入市区某某路段拥堵，请绕行。
   
6. 对于用户的重试行为，要适当的延缓。例如登录发现后端响应失败，再重新展现登录页面前，可以适当延时几秒钟，并展现进度条等友好界面。当多次重试还失败的情况下，要安抚用户。
   
7. 产品特性设计和发布上，要尽量避免某个时刻导致大量用户集体触发某些请求的设计。发布的时候注意灰度。
   
8. 中间层server对后端发送请求，重试机制要慎用，一定要用的话要有严格频率控制。
   
9. 当雪球发生了，直接清空雪球队列（例如重启进程可以清空socket 缓冲区）可能是快速恢复的有效方法。
   
10. 过载保护很重要的一点，不是说要加强系统性能、容量，成功应答所有请求，而是保证在高压下，系统的服务能力不要陡降到0，而是顽强的对外展现最大有效处理能力。
    
11. 对于“每个系统要有能力发现哪些是有效的请求，哪些是雪球无效的请求”，这里推荐一种方案：在该系统每个机器上新增一个进程：interface进程。 Interface进程能够快速的从socket缓冲区中取得请求，打上当前时间戳，压入channel。业务处理进程从channel中获取请求和该请 求的时间戳，如果发现时间戳早于当前时间减去超时时间（即已经超时，处理也没有意义），就直接丢弃该请求，或者应答一个失败报文。
12. Channel是一个先进先出的通信方式，可以是socket，也可以是共享内存、消息队列、或者管道，不限。Socket缓冲区要设置合理，如果过大，导致及时interface进程都需要处理长时间才能清空该队列，就不合适了。建议的大小上限是：缓存住超时时间内interface进程能够处理掉的请求个数（注意考虑网络通讯中的元数据）。

From：http://blogread.cn/it/article/5318?f=wb