服务器雪崩场景及解决方案

1.何为服务器雪崩?

分布式系统的存在、网络不稳定性决定服务的可用性决计达不到100%，网络不稳定、作为服务提供者自己可能会挂掉，导致服务调用者阻塞，最终可能导致雪崩效应。

雪崩效应产生场景:

流量激增：异常流量、用户频繁重试导致系统负载上升。

缓存失效：缓存服务器重启/大量缓存集中在某一时间段失效，会给DB系统等带来压力，引起数据库故障进而导致应用服务器雪崩。

数据库端压力：长事物、sql超时等。

线程同步调用：核心服务和非核心服务共用一个线程池和消息队列，如果一个核心业务线程调用非核心线程，该非核心线程由第三方系统完成，第三方系统故障时导致核心线程阻塞，处于死等状态，线程滴哦用达到超时限制之后，最终该线程崩溃，也可引起雪崩。

程序Bug：循环调用等逻辑问题，资源申请后未释放引起内存泄露等。

服务器故障：宕机、机房断电、网络延迟等。

缓存失效场景:

1.0 缓存服务器挂掉。2.0 热点缓存失效 3.0 高峰期缓存局部失效。

解决方案：

1.0 增加互斥锁，控制数据库请求，重建缓存。

2.0 避免缓存集中失效、设置不同的失效时间。

3.0 提高缓存HA，redis集群等。

---

雪崩的解决方案（熔断、限流、隔离）

1.0 熔断模式

容错处理机制，参考保险丝达到阈值后会熔断以防止火灾。某个服务调用过慢、大量超时，此时熔断该服务，对于后续调用请求直接返回，快速释放资源，当服务器状态好转则恢复该服务调用。

是否熔断所依赖的指标

cpu使用率/负载

内存

sql超时

线程数

mysql监控长事务

2.0 限流模式

此为预防模式，针对各个类型请求设置最高的查询率/s即QPS阈值，高于阈值之后的请求直接返回，不再调用资源

3.0 隔离模式

容错处理机制，对系统请求按照类型划分，例如使用线程池来资源隔离，一种类型的请求结束之后，后续该请求直接返回不予处理。

熔断设计

(1) 熔断请求判断机制算法：使用无锁循环队列计数，每个熔断器默认维护10个bucket，每1秒一个bucket，每个bucket记录请求的成功、失败、超时、拒绝状态，默认非成功状态超过50%且10秒内超过20个请求进行中断拦截。 

(2) 熔断回复：对于被熔断的请求，每隔5s允许部分请求通过，若请求均为健康(换而言之响应时间RT<250ms)则对请求健康回复。

(3) 熔断报警：对于熔断的请求打日志，异常请求超过某些限定时则报警。

隔离设计

(1) 线程池隔离模式：使用一个线程池来存储当前的请求，线程池对请求处理，设置任务返回处理超时时间，堆积的请求入线程池队列。需要为每个服务申请线程池，有资源消耗，优点为可以应对突发流量(流量高峰来临时处理不完的数据可暂存至缓存池)

(2) 信号量隔离模式：使用一个原子计数器(信号量等)来记录当前运行线程数，请求来判断计数器数值，超过最大线程数则丢弃该类型的后续请求，不超过执行计数器加1。

超时机制设计

(1) 等待超时：有任务入队列时设置任务入队列时间，并判断对头的任务入队列时间是否大于超时时间，是则丢弃任务。

(2) 运行超时：使用线程池的get方法依次获取任务执行结果。

提前发现雪崩：需要监控请求接近或超过阈值的过程，具体情况具体处理。