分布式系统有哪些原理（如何理解分布式系统架构的雪崩效应）

分布式系统有哪些原理（如何理解分布式系统架构的雪崩效应）（服务雪崩的参与者简化为 服务提供者 和 服务调用者 ）4、B服务提供者不可用后，A首先会在设定的超时时间内重试，重试不成功后也会导致A服务器的崩溃（服务提供者不可用导致重试加大流量，导致服务调用者也不可用），最终导致了整个分布式系统的崩溃；即称之为服务的雪崩效应；1、C是B的服务提供者（即B是C的服务调用者）2、B是A的服务提供者（即A是B的服务调用者）3、如果C服务提供者出现不可用的情况，B首先会在设定的超时时间内重试，重试不成功后会就导致B服务提供者的不可用；

什么是雪崩？

指分布式系统中经常会出现某个基础服务不可用造成整个系统不可用的情况 这种现象被称为服务雪崩效应。雪崩分为离线雪崩和在线雪崩：

1、离线雪崩，指新数据无法更新，导致队列的堵塞。

2、在线雪崩指，在线无法提供正常的检索服务，从外部看整个系统不可用。通常雪崩都是说的在线架构；

即服务雪崩效应是一种因 服务提供者 的不可用导致 服务调用者 的不可用 并将不可用 逐渐放大 的过程，根据图示分析如下：

1、C是B的服务提供者（即B是C的服务调用者）

2、B是A的服务提供者（即A是B的服务调用者）

3、如果C服务提供者出现不可用的情况，B首先会在设定的超时时间内重试，重试不成功后会就导致B服务提供者的不可用；

4、B服务提供者不可用后，A首先会在设定的超时时间内重试，重试不成功后也会导致A服务器的崩溃（服务提供者不可用导致重试加大流量，导致服务调用者也不可用），最终导致了整个分布式系统的崩溃；即称之为服务的雪崩效应；

服务雪崩形成的原因:

（服务雪崩的参与者简化为 服务提供者 和 服务调用者 ）

1、服务提供者不可用的原因

• 硬件故障

硬件故障可能为硬件损坏造成的服务器主机宕机 网络硬件故障造成的服务提供者的不可访问.

• 程序Bug

程序编程导致的问题

• 缓存击穿

缓存击穿一般发生在缓存应用重启 所有缓存被清空时 以及短时间内大量缓存失效时. 大量的缓存不命中 使请求直击后端 造成服务提供者超负荷运行 引起服务不可用.

• 用户大量请求

在秒杀和大促开始前 如果准备不充分 用户发起大量请求也会造成服务提供者的不可用.

2、重试加大流量 的原因

• 用户重试
• 代码逻辑重试

在服务提供者不可用后 用户由于忍受不了界面上长时间的等待 而不断刷新页面甚至提交表单.服务调用端的会存在大量服务异常后的重试逻辑. 这些重试都会进一步加大请求流量.

3、服务调用者不可用 产生的主要原因

同步等待造成的资源耗尽

当服务调用者使用 同步调用 时 会产生大量的等待线程占用系统资源. 一旦线程资源被耗尽 服务调用者提供的服务也将处于不可用状态 于是产生了服务雪崩效应.

服务雪崩的应对策略

1、流量控制

流量控制 的具体措施包括:

• 网关限流
• 用户交互限流
• 关闭重试

因为Nginx的高性能 目前一线互联网公司大量采用Nginx Lua的网关进行流量控制 由此而来的OpenResty也越来越热门.

用户交互限流的具体措施有:

1. 采用加载动画 提高用户的忍耐等待时间.

2. 提交按钮添加强制等待时间机制.

2、改进缓存模式

措施包括

缓存预加载

同步改为异步刷新

服务自动扩容 的措施主要有:

AWS的auto scaling

服务调用者降级服务 的措施包括:

资源隔离

对依赖服务进行分类

不可用服务的调用快速失败

资源隔离主要是对调用服务的线程池进行隔离.我们根据具体业务 将依赖服务分为: 强依赖和弱依赖. 强依赖服务不可用会导致当前业务中止 而弱依赖服务的不可用不会导致当前业务的中止.不可用服务的调用快速失败一般通过 超时机制 熔断器 和熔断后的 降级方法 来实现.