分布式应用雪崩效用

分布式应用雪崩效用

 

 

对雪崩效用的理解

 

       服务C依赖服务B，服务B依赖服务A，当服务A挂掉，这样服务B的请求一直等待，到超时为止，导致服务B的资源耗尽。

 

 

 

 

雪崩效用的原因

 

• 服务提供者不可用
• 重试加大流量
• 服务调用者不可用

 

 

服务提供者不可用的原因

 

• 硬件故障：服务器宕机或者网络故障
• 程序bug
• 缓存击穿：一般发生在缓存应用重启, 所有缓存被清空时, 以及短时间内大量缓存失效时。大量的缓存不命中, 使请求直击后端, 造成服务提供者超负荷运行, 引起服务不可用。
• 用户大量请求：在秒杀和大促开始前, 如果准备不充分, 用户发起大量请求也会造成服务提供者的不可用。

 

重试加大流量的原因

 

• 用户重试：在服务提供者不可用后, 用户由于忍受不了界面上长时间的等待, 而不断刷新页面甚至提交表单。
• 代码逻辑重试：这是程序自己做的重试

 

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

 

同步等待造成资源耗尽：

 

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

 

 

 

 

解决方案

 

• 超时机制：设置超时时间
• 服务限流
• 防止缓存击穿
• 服务熔断：服务B检查到服务A的接口不稳定时（如：10次出错5次），然后就断开服务A的访问
• 服务降级：服务B准备一个回退机制，备用接口
• 将同步等待改成异步：防止长时间占用资源导致耗尽
• 服务器自动扩容：这个最好使用云服务器（AWS的auto scaling、Azure），能够有大量冗余，也能实现自动扩容

 

限流的解决方法

 

• 程序限流：信号量、线程池 + 队列

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

• 用户交互限流：1. 采用加载动画,提高用户的忍耐等待时间. 2. 提交按钮添加强制等待时间机制.

 

防止缓存击穿的方法

 

• 当多个线程进来查缓存的时候，因为这时缓存中无数据
• 那用setNx()做一个互斥锁，只有一个线程能够拿到这个锁
• 拿到锁的线程就查DB，然后将DB数据放回到缓存
• 拿不到锁的线程，就先等待一段时间（如：5秒），然后再进行第一步的查询

 

熔断和降级的方法

 

Hystrix：可以实现限流、熔断、降级

 

限流：

配置properties

继承HystrixCommoned

重写run方法中实现要限流的服务请求

 

熔断：

配置properties，满足条件后就会断绝run方法

 

降级：

配置properties

重写fallback方法，在里面写降级时要调用的方法