如何保证系统不被突发的流量压垮？

[ 用大白话讲解复杂的技术 ]

这是我的第44篇原创文章

作者 l 会点代码的大叔（CodeDaShu）

确保系统的高可用，要做的事情非常多，比如使用 Redis 缓存数据库的数据，降低数据库的压力，同时也要注意缓存穿透、雪崩、击穿等问题；但要是说到“不被突发的流量压垮”，通常就会到我们常说的分布式架构三板斧：限流、熔断、降级。

01

限流

限流理解起来很简单，比如故宫每天只卖八万张票，超过八万的游客，无法买票进入，因为如果超过八万人，景点的工作人员可能就忙不过来，过于拥挤的景点也会影响游客的体验和心情，并且还会有安全隐患；只卖N张票，这就是一种限流的手段。

软件架构中的限流也一样，就是流量徒增的时候，只允许一部分流量进来，而多余的那部分，就拒绝掉。

通常我们可以通过限流算法达到这样的效果，比如计数器法、滑动窗口法、漏桶算法、令牌桶算法，每个算法的详解之前的文章有介绍过，这里就不在占用篇幅了。上面的例子中，故宫每天只卖八万张票，有点儿类似于令牌桶算法，票就相当于令牌，只有拿到令牌的请求，才能访问到服务。

另外限流可以针对不同的系统或业务流程限流，比如核心系统 A 要做限流，B 系统调用 A 系统很重要，C 系统调用 A 系统相对来说不是那么重要，所以当 A 系统有些扛不住的时候，可以限制 C 系统的调用次数，保证 B 系统的稳定运行。

02

熔断

现实生活中，保险丝的作用就是熔断，可以在发生短路的时候自动跳闸，保护家电。

在我们大部分应用场景中，A 系统调 B 系统接口，B 系统再调 C 系统接口这样的场景非常多，这就是调用链路：A->B->C->D；每个系统的承载上限肯定是不一样的，比如流量徒增，D 系统达到承载上限了，D 系统的接口响应非常慢，这样可能会导致 A/B/C 调用它时出现超时等待的情况；如果进一步恶化，会导致链路雪崩，从一个服务的故障，变成了多个系统的故障。

这时候熔断就派上用场了，如果短时间内有大量的请求超时，那么就意味着这个系统出现了故障，那么就没有必要再去访问这个服务了，这时候就要使用熔断，断开这条链路。

熔断器还可以自动诊断下游服务的状态，如果服务恢复的话，那么再慢慢释放请求，直到故障发生前的状态。

03

降级

服务降级既可以通过代码自动判断，比如上文的服务限流中说到，当流量徒增，可以限制不重要的系统或服务的访问量，这里的哪个系统重要，哪个系统不重要，就是服务等级、级别的区分，当访问量徒增，低级别的系统是可以自动降级的。

服务降级也可以人工根据突发情况切换；比如在某些服务节点的时候（例如双 11, 618），为了保证购物和支付的正常运行，会禁用一些不重要的服务；甚至是在极端情况下，购物和支付只能二选一的时候，购物更重要，所以可以提前预付或者延迟支付。

总之，限流、熔点和降级都是在流量徒增、过大时，保证系统稳定的手段。

期待分享

如果您喜欢本文，请点个“在看”或分享到朋友圈，这将是对我最大的鼓励。