百万架构师亲码的亿级流量下的分布式限流解决方案

在互联网应用中，高并发系统会面临一个重大的挑战，那就是大量流高并发访问，比如：天猫的双十一、京东 618、秒杀、抢购促销等，这些都是典型的大流量高并发场景。

高并发系统限流

短时间内巨大的访问流量，我们如何让系统在处理高并发的同时还能保证自身系统的稳定性？有人会说，增加机器就可以了，因为我的系统是分布式的，所以可以只需要增加机器就可以解决问题了。但是，如果你通过增加机器还是不能解决这个问题怎么办呢？而且这种情况下又不能无限制的增加机器，服务器的硬件资源始终都是有限的，在有限的资源下，我们要应对这种大流量高并发的访问，就不得不采取一些其他的措施来保护我们的后端服务系统了，比如：缓存、异步、降级、限流、静态化等。

这里，我们先说说如何实现限流。

什么是限流？

在高并发系统中，限流通常指的是：对高并发访问或者请求进行限速或者对一个时间内的请求进行限速来保护我们的系统，一旦达到系统的限速规则（比如系统限制的请求速度），则可以采用下面的方式来处理这些请求。

• 拒绝服务（友好提示或者跳转到错误页面）

• 排队或等待（比如秒杀系统）

• 服务降级（返回默认的兜底数据）

其实，就是对请求进行限速，比如 10r/s，即每秒只允许 10 个请求，这样就限制了请求的速度。从某种意义上说，限流，其实就是在一定频率上进行量的限制。

限流一般用来控制系统服务请求的速率，比如：天猫双十一的限流，京东 618 的限流，12306 的抢票等。

限流有哪些使用场景？

这里，我们来举一个例子，假设你做了一个商城系统，某个节假日的时候，突然发现提交订单的接口请求比平时请求量突然上涨了将近 50 倍，没多久提交订单的接口就超时并且抛出了异常，几乎不可用了。而且，因为订单接口超时不可用，还导致了系统其它服务出现故障。

我们该如何应对这种大流量场景呢？一种典型的处理方案就是限流。当然了，除了限流之外，还有其他的处理方案，我们这篇文章就主要讲限流。

• 对稀缺资源的秒杀、抢购

• 对数据库的高并发读写操作，比如提交订单，瞬间往数据库插入大量的数据

限流可以说是处理高并发问题的利器，有了限流就可以不用担心瞬间高峰流量压垮系统服务或者服务雪崩，最终做到有损服务而不是不服务。

使用限流同样需要注意的是：限流要评估好，测试好，否则会导致正常的访问被限流。

由于内容较多，以下将只展示部分内容，需要完整文档阅读的小伙伴点赞+转发【直接点击此处】即可免费获取！！

常见的限流算法

HTTP 接口限流实战

Redis+Lua 脚本实现分布式限流案例

测试分布式限流

Nginx+Lua 实现分布式限流

说到这里，相信有很多小伙伴可能会问：如果应用并发量非常大，那么，Redis 或者 Nginx 能不能扛的住呢？

可以这么说：Redis 和 Nginx 基本都是高性能的互联网组件，对于一般互联网公司的高并发流量是完全没有问题的。为什么这么说呢？咱们继续往下看。

如果你的应用流量真的非常大，可以通过一致性哈希将分布式限流进行分片，还可以将限流降级为应用级限流；解决方案也非常多，可以根据实际情况进行调整，使用 Redis+Lua 的方式进行限流，是可以稳定达到对上亿级别的高并发流量进行限流的（笔者亲身经历）。

需要注意的是：面对高并发系统，尤其是这种流量上千万、上亿级别的高并发系统，我们不可能只用限流这一招，还要加上其他的一些措施，

对于分布式限流，目前遇到的场景是业务上的限流，而不是流量入口的限流。对于流量入口的限流，应该在接入层来完成。