共计 1691 个字符，预计需要花费 5 分钟才能阅读完成。
仅从设计优化、服务拆分、主动扩容等方面进行优化，有时候并不能齐全解决问题。比方，有时流量增长过快，扩容流程还来不及实现，服务器可能就曾经抗不住了
既然突发流量咱们没法预测，业务上也不可能不依赖任何内部服务和资源，那么有什么方法能尽量避免，或者升高呈现这些问题时对外围业务的影响呢？
流量管制
01. 流控罕用的算法
目前业内罕用的流控办法有两种：漏桶算法 和令牌桶算法
- 漏桶算法
“漏桶算法”的次要目标是控制数据注入到网络的速率，平滑网络上的突发流量。“漏桶算法”在实现上文如其名：它模仿的是一个漏水的桶，所有内部的水都先放进这个水桶，而这个桶以匀速往外平均漏水，如果水桶满了，内部的水就不能再往桶里倒了。这里你能够把这些内部的水设想成原始的申请，桶里漏出的水就是被算法平滑过后的申请。从这里也能够看进去，漏桶算法能够比拟好地管制流量的访问速度。
- 令牌算法
令牌桶算法是流控中另一种罕用算法，管制的是一个工夫窗口内通过的数据量。令牌桶算法大略实现是这样的：
- 每 1/r 秒往桶里放入一个令牌，r 是用户配置的均匀发送速率（也就是每秒会有 r 个令牌放入）。
- 桶里最多能够放入 b 个令牌，如果桶满了，新放入的令牌会被抛弃。
- 如果来了 n 个申请，会从桶里消耗掉 n 个令牌。
- 如果桶里可用令牌数小于 n，那么这 n 个申请会被抛弃掉或者期待新的令牌放入。
算法按肯定速度平均往桶里放入令牌，原始申请进入后，依据申请量从令牌桶里取出须要的令牌数，如果令牌数不够，会间接摈弃掉超限的申请或者进行期待，能胜利获取到令牌的申请才会进入到后端服务器。
与漏桶算法“准确管制速率”不太一样的是，因为令牌桶的桶自身具备肯定的容量，能够容许一次把桶里的令牌全都取出，因而，令牌桶算法在限度申请的均匀速率的同时，还容许肯定水平的突发流量。
算法按肯定速度平均往桶里放入令牌，原始申请进入后，依据申请量从令牌桶里取出需
02. 全局流控
在分布式服务的场景下，很多时候的瓶颈点在于全局的资源或者依赖，这种状况就须要分布式的全局流控来对整体业务进行爱护。
业界比拟通用的全局流控计划，个别是通过地方式的资源（如：Redis、Nginx）配合脚本来实现全局的计数器，或者实现更为简单的漏桶算法和令牌桶算法，比方能够通过 Redis 的 INCR 命令配合 Lua 实现一个限度 QPS（每秒查问量）的流控组件。
一个须要留神的细节是：在每次创立完对应的限流 Key 后，你须要设置一个过期的工夫。整个操作是原子化的，这样能防止分布式操作时设置过期工夫失败，导致限流的 Key 始终无奈重置，从而使限流性能不可用。此外，在实现全局流控时还有两个问题须要留神：一个是流控的粒度问题，另一个是流控依赖资源存在瓶颈的问题。上面咱们别离来看一下，在实现全局流控时是如何解决这两个问题的。
03. 细粒度管制
首先是针对流控的粒度问题。举个例子：在限度 QPS 的时候，流控粒度太粗，没有把 QPS 平均摊派到每个毫秒里，而且边界解决时不够平滑，比方上一秒的最初一个毫秒和下一秒的第一个毫秒都呈现了最大流量，就会导致两个毫秒内的 QPS 翻倍。
一个简略的解决形式是把一秒分成若干个 N 毫秒的桶，通过滑动窗口的形式，将流控粒度细化到 N 毫秒，并且每次都是基于滑动窗口来统计 QPS，这样也能防止边界解决时不平滑的问题。
主动熔断机制
雪崩效应在多依赖服务中往往会导致一个服务出问题，从而拖慢整个零碎的状况。
为了便于管理和隔离，咱们常常会对服务进行解耦，独立拆合成耦到不同的微服务中，微服务间通过 RPC 来进行调用和依赖:
- 手动通过开关来进行依赖的降级
- 主动熔断机制次要是通过继续收集被依赖服务或者资源的拜访数据和性能指标，当性能呈现肯定水平的好转或者失败量达到某个阈值时，会主动触发熔断，让以后依赖疾速失败（Fail-fast），并降级到其余备用依赖，或者暂存到其余中央便于后续重试复原。在熔断过程中，再通过不停探测被依赖服务或者资源是否复原，来判断是否主动敞开熔断，复原业务。
往期举荐
- Redis 删除数据后，为什么内存占用率还是很高？
- Redis 三种长久化形式
- 音讯模型：主题和队列有什么区别？
- Hash 算法原理解析
- MySQL 中乐观锁和乐观锁到底是什么？
