转自：https://cloud.tencent.com/developer/article/1329609

https://www.361shipin.com/blog/1552697548710346752，讲的很好

1.介绍 

过载： 系统负载超过系统最大的处理能力。

服务器雪崩： 服务器的处理能力陡降，低于系统原本能达到的最大处理能力。

关系：

系统过载处理不当会造成服务器雪崩： 系统过载时，CPU、内存等资源达到瓶颈，系统响应会变慢。这时可能会发生大量的请求重试或系统内部重试，进一步加剧系统负载，产生恶性循环，导致系统处理能力急剧下降（服务器雪崩）。

过载原因：

1. 访问量过大，（某个时间内访问量过大，或突增）
2. 系统内部瓶颈、故障。（系统内部故障会导致系统的处理能力下降，从而容易引发过载。）
3. 后端故障、延迟。（后端处理能力的下降会影响到本系统的响应能力）

2.接口延时优化 

https://blog.csdn.net/VitaminX181/article/details/117490627

优化有三个维度：分别是吞吐量、时延、系统容量。

• 吞吐量：指的是单位时间内系统能完成多少操作；
• 时延：指的是操作的响应时间，比如说搜索商品的结果必须在200ms内展示给用户；
• 系统容量：指的是在吞吐量和时延达标的情况下，对硬件环境的额外约束。

 从系统层面看：CPU、内存、网络、磁盘这几个维度。

• sql查询语句如果结果返回的对象过大，可能会影响内存占用。
• sql慢查询，没有使用索引会影响cpu使用率。

3.过载保护

前端系统C通过udp请求访问后端serverD，后端server D的udp套接字缓冲区为4MB，每个请求大小约400字节。后端serverD偶尔处理超时情况下，前端系统C会重试，最多重试2次。

假设一个业务场景，秒杀门票，大量的用户聚集在同一时刻发起了大量请求，超出了后台serverD的最大负载能力。操作响应失败的用户又重试， 中间系统的重试，进一步带来了更大量的请求，导致所有用户操作都是失败的。

大量请求会马上将4MB大小的缓冲区堆满，请求可能会丢失，而且D在处理排队的请求时，处理到的时候可能该请求就已经超时了，已经被用户重试了，那么D所做的处理就是无用功。

• 所以，每个系统，自己的最大处理能力是多少要做到清清楚楚。如上图，前端进程C处理能力要取决于后端D。
• 前端要保护后段；重试要慎重；过载时，该拒绝的请求就拒绝；用户重试时，适当延缓；

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

推荐解决方案：

对于“每个系统要有能力发现哪些是有效的请求，哪些是雪球无效的请求”。

•  在系统每个机器上都部署一个interface实例，它能够快速的从socket缓冲区中取得请求，打上当前时间戳，压入channel。
• 业务处理进程从channel中获取请求和该请求的时间戳，如果发现时间戳早于当前时间减去超时时间（即已经超时，处理也没有意义），就直接丢弃该请求，或者应答一个失败报文。

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