熔断器学习

熔断器的作用

在分布式系统中，请求下游系统时，如果下游系统响应慢，或者直接hang住请求，可能会拖垮上游系统，产生雪崩效应。因此希望在下游系统不稳定或者不可用时，不调用下游系统，直接报错返回

熔断器的设计

熔断器的三种状态

1. closed，正常情况，熔断器关闭，请求放行
2. open，异常情况，熔断器打开，拒绝所有请求
3. halfopen，由closed到open状态后，不能一直拒绝所有的调用，得有一个halfopen状态，需要尝试恢复至closed状态，即放行部分调用试试，看下游系统是不是正常的

熔断器状态转移

1. open状态，此时认为下游系统不可用，从进入open状态的那一刻起，经过一个指定的冷却时间，会进入halfopen状态
2. halfopen状态，下游系统异常了这么久，可能已经恢复了，此时隔段时间尝试请求一下。如果请求成功累计超过一定次数，则恢复至closed状态，认为下游系统已经恢复正常；一旦请求失败一次，直接再进入open状态
3. closed状态，此时认为下游系统正常，当请求下游失败时，也不能直接就认为下游系统异常，可能是网络抖动。因此需要有一个策略，例如失败次数/失败率到达一定阈值，才认为下游系统真正异常了，才进入open状态

怎么定义下游系统真正处于异常状态？（何时熔断？）

衡量指标

一段时间内请求的失败率或失败数

大致思路

将时间划分为多个段，分段统计每个段内的请求失败数，同时定义一个时间窗口：从当前时间（决定是否向下游发起调用）往前回溯固定的间隔，汇总这个窗口内全部时间段中的失败请求数

举例：定义段大小为2s，窗口大小为12s，12s内连续失败8次则认为下游系统异常，需要进入open状态
分别在1s/1.5s/2.2s/5s/6s/9s发生了失败调用（仍处于closed状态），则
时间段[1,3]内的失败数为3
时间段[5,7]内的失败数为2
时间段[9,11]内的失败数为1
12s时若又发生了失败调用，计算发现12s内失败次数为3+2+1+1=7<8，则仍然放行所有请求，熔断器处于open状态
在15.1s/15.2s/15.3s/16s分别又发生了失败调用
15.1s时，最近12s内失败次数为2+1+1+1=5<8
15.2s时，最近12s内失败次数为2+1+1+1+1=6<8
…
16s时，最近12s内失败次数为2+1+1+1+1+1+1=8，此时失败请求数达到阈值，熔断

并非真正记录每个连续时间段内失败请求数，因为可能很长时间都没有请求发生，只有当时刻n请求失败时，才记录[n,n+时间段大小]内的失败请求数，如果n已经存在于某个记录过的区间，则简单的将该区间的请求数自增
随着时间的推移，开始记录的时间段会逐步过期（只关注从当前时间回溯固定间隔后，所产生窗口内的失败请求）

大致实现

每个时间段

type bucket struct {
	failure int64
	success int64

	timeStamp int64 // 第一个失败请求发生时，会创建一个bucket，该值即为创建时间
}

窗口，采用数组存放每个时间段，随着时间的推移，越来越多的时间段会存在数组中，但真正有效的时间段其实不多，那些不在当前时间窗口内的时间段是失效的。因此可将数组‘首尾相连’，当作环形数组

type window struct {
	oldest  int       // 环形数组的起点
	latest  int       // 环形数组的终点
	buckets []*bucket // 存放窗口内的每个时间段（包括当前可能已失效的）

	bucketTime time.Duration // 每个时间段的长度
	bucketNums int           // len(buckets)
	expireTime time.Duration // 窗口大小
	inWindow   int           // 环形数组的有效长度
}

• 调用失败时，取buckets[latest]，若当前时间位于[buckets[latest].timeStamp, buckets[latest].timeStamp+bucketTime]内，则buckets[latest].failure++，否则新创建一个bucket来记录当前失败请求
• 判断是否需要熔断时，从buckets[oldest]往前遍历，过滤掉[now-expireTime, now]之外的数据，统计失败次数

不足之处

如果失败请求不能在各个时间段内均匀分布，会导致失败率计算不准确，如定义时间段为2s，在1-2s内失败了200次，在2-3s内只失败1次，只会记录1-3s时间段内的失败次数为201次，统计窗口1-4s和2-5s内的失败次数结果一样，但直观来看2-5s内的失败数应该远小于这个数字
可以将时间段设的尽可能小来使计算结果更精确