Resilicence4j中的熔断机制（CircuitBreaker）关于slidingWindowSize(滑动窗口大小)和minimumNumberOfCalls（计算失败率最小调用数）的讲解

关于Resilicence4j中的熔断机制（CircuitBreaker）部分这里不再讲解，不懂得同学们可以查看以下几篇优秀的博客以及B站尚硅谷相关的教学视频。

• SpringCloud搭建微服务之Circuit Breaker断路器
• CircuitBreaker–Resilience4J介绍和使用
• CircuitBreaker断路器（服务熔断,服务降级）

该篇博客记录自己学习Resilicence4j中的熔断机制（CircuitBreaker时关于slidingWindowSize(滑动窗口大小)和minimumNumberOfCalls（计算失败率最小调用数）这两个参数的解惑过程。也可以看看我录制的讲解视频

Resilicence4j中的熔断机制（CircuitBreaker）关于slidingWindowSize(滑动窗口大小)和minimumNumberOfCa

疑惑：他们俩的作用分别是什么？

答：slidingWindowSize设置滑动窗口的大小，当需要计算是否达到熔断开启的阈值时，样本从该大小的窗口中取出计算。
minimumNumberOfCalls设置计算失败率最小调用数。
第一次听以上概念估计很懵，似懂非懂，但是好像不知道具体如何设置，以及设置怎样的值才能取得自己想要的效果。没事，请接着往下继续阅读。

实践出真知

既然不知道他们的作用是什么，那么不妨设置几个值去实践看看到底如何他们俩起了什么作用。

slidingWindowSize

准备条件：

• 设置滑动窗口的类型为基于数量的
• 同时自定义滑动窗口大小slidingWindowSize为6
• 失败阈值为50%，即有一半数量的请求失败了则熔断
• 从开启到半开状态等待时间设置为5秒
• 半开状态运行通过的请求数为2
• minimumNumberOfCalls不设置，即为系统默认

如下图所示：

测试：
以下表格中1表示成功的请求，0表示故意发送的一个失败的请求用于模拟失败请求。红色格子表示发送正常的请求却失败了，即表示熔断机制已经开启了。黄色单元格表示当前的滑动窗口中的数据。绿色格子表示发送正常的请求被正确接收了

实验结果记录如上。
现在一条一条分析结果，每一行表示一次实验。

• 第1次实验：先发送3次正确的请求，再发送3次失败的请求。可以看到，目前滑动窗口中有3次正确和3次失败，失败率达到50%，即开启熔断。
• 第2次实验：先发送6次正确的请求，再发送1次失败的请求。可以看到，目前滑动窗口中有5次正确和1次失败，失败率没有达到50%，即继续正常执行。
• 第3次实验：先发送6次正确的请求，再发送2次失败的请求。可以看到，目前滑动窗口中有4次正确和2次失败，失败率没有达到50%，即继续正常执行。
• 第4次实验：先发送6次正确的请求，再发送3次失败的请求。可以看到，目前滑动窗口中有3次正确和3次失败，败率达到50%，开启熔断。
• 第5次实验：先发送3次失败的请求，再发送3次正确的请求。可以看到，目前滑动窗口中有3次正确和3次失败，败率达到50%，开启熔断。
• 第6次实验：先发送4次正确的请求，再发送3次失败的请求。可以看到，目前滑动窗口中有3次正确和3次失败，失败率达到50%，即开启熔断。
• 第7次实验：先发送4次正确的请求，再发送2次失败的请求。可以看到，目前滑动窗口中有4次正确和2次失败，失败率没有达到50%，即继续正常执行。

以上结果验证了如果只设置slidingWindowSize的大小，那么只要滑动窗口中的失败数达到设定的比例，则会开启熔断，好像minimumNumberOfCalls没啥用呀？

minimumNumberOfCalls

以上既然已经验证了slidingWindowSize可以控制什么时候开始熔断，那还要minimumNumberOfCalls干什么呢？这也是我当时很困惑的一个点。于是继续实验，这次在上述实验的前提条件下，设置minimumNumberOfCalls为4，故意让他比slidingWindowSize小，看看有什么影响吗？
实验结果如下：

分析结果：

• 第1次实验：先发送3次正确的请求，再发送3次失败的请求。可以看到，目前滑动窗口中有3次正确和3次失败，失败率达到50%，即开启熔断。
• 第2次实验：先发送2次失败的请求，再发送2次成功的请求。可以看到，目前滑动窗口中一共有4个请求记录，达到了设定了的minimumNumberOfCalls为4，则开始计算失败率，达到50%，虽然滑动窗口还有两个空的，但是依旧立即开启熔断。
• 第3次实验：先发送3次正确的请求，再发送1次失败的请求。可以看到，目前滑动窗口中有3次正确和1次失败，达到了设定了的minimumNumberOfCalls4，则开始计算失败率，失败率没有达到50%，即继续正常执行。
• 第4次实验：先发送3次失败的请求，再发送1次正确的请求。可以看到，目前滑动窗口中有1次正确和3次失败，败率达到50%，开启熔断。
• 第5次实验：先发送6次正确的请求，再发送2次正确的请求。可以看到，目前滑动窗口中有3次正确和3次失败，数量为6也超过minimumNumberOfCalls设定的4，同时失败率达到50%，开启熔断。
• 第6次实验：先发送3次正确的请求，再发送2次失败的请求。可以看到，目前滑动窗口中有3次正确和2次失败，失败率没有达到50%，即正常执行。

上述结果分析我只分析了最后的情况，其实在超过4次请求的实验中，只要超过第4次的请求，系统都会进行一次计算，也就是在实验1，5，6的第五次请求、实验1，5的第六次请求以及实验5的第七次请求都会进行以及失败率的计算和是否熔断的判定。因为滑动窗口中的数量已经达到了设定的minimumNumberOfCalls最小触发次数。