架构师之路八分布式系统下大流量限流与消峰的方案

前面架构师之路1到4个章节简述了架构师所具备的思考维度，关键能力，设计图，以及架构设计五视图等常用的思考方案与必备能力。5到7，3个章节演示了具体的秒杀系统，分布式理论研究，以及dubbo的失败重试与链路追踪机制;

---

在提到具体的解决方案的时候，我们需要了解2个算法，一个是令牌桶算法，一个是漏桶算法；令牌桶算法: 就是限制平均流入速率，假如令牌桶内放置10个令牌，每次拿走1个令牌，但同时也支持突发流量进入，一次拿走5个令牌，桶内如果没有令牌，则后续等待的任务直接废弃; 漏桶算法: 是限制流出速率；因为桶内的流水是恒定的，只管流出的速率

---

第一种方案: Guava方案

其底层使用的是令牌桶算法，在引入guava依赖后，我们假设先往桶内放置5个令牌
使用 final RateLimiter limiter = RateLimiter.create(5)
使用limiter.acquire()，从桶内获取一个令牌，当然也支持
limiter.acquire(5),直接从桶内获取5个令牌，主要是应对突发流量
假设桶内没有令牌，我们也可以使用limiter.tryAcquire()尝试从桶内获取，当然如果此时仍然没有令牌，我们也可以，使用limiter.tryAcquire(5,毫秒)再次获取

---

第二种方案: nginx

此种方案处理http请求，当请求过来的时候，我们直接设置limit-req-zone,设置每秒IP允许发起的请求数;
limit-req 设置缓冲的连接数
limit-conn 并发连接数
limit-zone 设置每个session的空间大小

---

第三种方案:使用计数器的方式

首先查看开关是否开启，还是关闭;
其次 设置的sku，在循环依赖种依次递减的方式直至为0；

---

第四种方案 时间分片的方式

前面三种方案基本上可以说是 从技术角度去解决这些问题
而当前这种方案是从业务上去解决限流与消峰的案例
比如12306网站，我们经常需要填写验证码来拉长战线，就是限流的一个举措；再比如分时段出票，也是按照时间分片的功能来实现限流与消峰

---

总结一句话: 从技术，业务，前端，后端等不同维度去解决大流量带来的限流与消峰的方案

---

更多内容，请关注博客