[服务器雪崩是怎么造成的]服务器雪崩的场景与服务器雪崩的场景与解决方案

如果缓存服务器重新启动或在一段时间内大量缓存失败，这将给后端系统带来很大压力，导致数据库后端故障，从而导致应用程序服务器雪崩。

流量激增：异常流量用户重试会增加系统负载。

缓存刷新：假设a是客户端，b是服务器端，假设a系统请求全部流向b系统，如果超出b系统的容量，则可能会发生b系统崩溃。

程序存在Bug:代码循环调用的逻辑问题资源未释放导致的内存泄漏等问题。

硬件故障：停机机房断电光纤损坏等。

严重的数据库瓶颈，如长事务SQL超时等。

线程同步等待：同步服务调用模式经常在系统之间使用，核心服务和非核心服务共享线程池和消息队列。如果核心业务线程调用的线程不是核心，则非核心线程将由第三方系统完成。第三方系统本身出现问题，核心线程被阻塞，处于待机状态，进程间调用有超时限制。最终，这条线程可能会断裂或引发雪崩。大卫亚设，你知道吗？。

缓存失败案例：

1缓存服务器已断开。

2峰值缓存本地故障

3热点缓存失败。

解决方案：

1避免缓存集故障，为每个密钥设置不同的超时时间

2添加mutex控制数据库请求重新配置缓存。

3增强缓存HA，如redis群集。

一般来说，服务依赖保护有三个主要解决方案。

这种模式主要是基准电路熔化，如果线路电压过高，保险丝就会熔化，防止火灾。如果大象服务调用缓慢或超时较多，则可以拦截对该服务的调用，对于后续调用请求，不继续调用大象服务，而是直接返回，从而快速释放资源。目标服务情况好转后恢复呼叫。

机械性能指标的主要监测

Cpu CPU利用率/负载

内存

Mysql监视长事务(此处与sql查询超时紧密结合，需要重点监视)

Sql逾时

线程数等

这个模型相当于按类型将对系统的请求划分为小岛。一个岛被火烧得少，对另一个岛没有影响。。

例如，对于不同类型的请求，可以使用线程池来分离资源。每种请求类型互不影响，当一种类型的请求线程资源用完时，不会调用后续资源，而是直接返回给后续请求类型。这个模型使用很多场景，例如分解服务对重要服务使用单独的服务器进行分发，或者最近公司宣传的多中心。

以上保险丝模式和隔离模式都是故障后容错处理机制，限流模式可以说是预防模式。流限制模式主要是为每种类型的请求预先设置最高的QPS阈值，如果高于设置的阈值，则不会调用后续资源。该模型不能解决服务依赖问题，没有有限流量的请求仍然会引发雪崩，因此只能解决系统的总体资源分配问题。

隔离通常以两种方式使用

线程池隔离模式：使用一个线程池存储当前请求，线程池处理请求，设置作业返回处理超时时间，并将累积的请求累积到线程池队列中。这种方法需要为各从属服务申请线程池，优点是有一定的资源消耗，能够应对突发流量。(如果流量激增，处理没有结束，可以在线程池团队中存储数据，这样可以慢慢处理。）

信号量隔离模式：使用原子计数器记录当前正在运行的线程数。请求首先确定计数器数，如果超过设置的最大线程数，则删除更改类型的新请求；如果没有超过，则运行计数任务请求以返回计数器1；请求返回计数器-1。这种方法是严格控制线程，立即返回模式，无法应对突发流量(如果流量峰值暂时处理的线程超过数量，其他请求将直接返回，而不是继续请求从属服务)

超时有两种。一个是请求的等待超时，另一个是请求运行超时。

等待逾时：设定工作排入伫列时的排入工作伫列时间，检查伫列标头中的工作排入伫列时间是否大于逾时，并在超过时删除工作。

执行超时：可以直接使用线程池提供的get方法。

首先确保系统不会发生雪崩，然后通过监测来监测请求接近或超过阈值，然后根据情况处理的过程可以说是“提前发现雪崩”。(威廉莎士比亚，雪崩，雪崩，雪崩，雪崩，雪崩，雪崩，雪崩，雪崩，雪崩)

这是应用服务雪崩的场景和技术方案的总结。

Java并发Redis高并发