短信业务再受暴击，会不会从此走向消亡？

「物理公式」 电功率 P = I^2 * R，I 代表电流，元器件的电阻 R 不变的情况下，电流越大，电功率约大，电阻做的电功大部分都用来发热了，所以电功率越大，发热越严重。(还好高中物理没忘。)

放到我们系统中，怎么理解熔断?

如果在某段时间内，调用某个服务非常慢甚至超时，就可以将这个服务熔断，后续其他服务再调用这个服务就直接返回，告诉其他服务：「“已经熔断了，你别调用我了，过段时间再来试下吧。”」

1.6.2 如何熔断

「熔断有个原则」 一段时间内，统计失败的次数或者失败请求的占比超过一定阈值，就进行熔断。

详细的原理如下图所示：
 

• 我们系统中三个服务：订单服务、商品服务、库存服务。
• 下单场景：用户下单了一个商品，客户端调用订单服务来生成预付款订单，订单服务调用商品服务查看下单的哪款商品，商品服务调用库存服务判断这款商品是否有库存，如有库存，则可以生成预付款订单。
• 假定因双十一流量暴增，库存服务不可用(如响应超时等)，库存服务收到的很多请求都未处理完，它将无法处理更多请求。
• 而上游的商品服务依赖库存服务，商品服务的超时和重试机制会被执行。商品服务新的调用不断产生，会导致商品服务的调用被大量积压，产生大量的调用等待和重试调用，慢慢耗尽商品服务的资源，比如内存，结果导致商品服务也宕机了。

而订单服务也会重走商品服务的老路。结果就是三个服务都不可用了。

四、造成雪崩的真实场景

1.4.1 服务提供者不可用

• 硬件故障:如网络故障、硬盘损坏等。
• 程序的 bug:如算法需要占用大量 CPU 的计算时间导致 CPU 使用率过高。
• 缓存击穿:比如应用刚重启，短时间内缓存是失效的，导致大量请求直接访问到了数据库，数据库不堪重负，服务不可用。
• 秒杀和大促:服务短时间承载不了那么多请求量。

1.4.2 重试加大流量

• 用户连续重试:比如用户看到界面上没有响应，所以又操作了一遍，结果又增加了一倍请求量。
• 程序重试机制:比如代码中有多次重试的逻辑，一次失败后，过几秒后再重试，重试个三次就取消重试，走异常处理分支了。也是增加了请求量。

五、如何防止雪崩

方案

出问题前预防：限流、主动降级、隔离

出问题后修复：熔断、被动降级

六、熔断原理和算法

1.6.1 熔断概念

（编辑：淮安站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!