答完这些Redis服务熔断的面试题，基本上你对它也算是摸透了吧，别说没准备过redis服务熔断相关知识

（引用来源：网络技术社区与面试题汇总）

先别急着说熔断，咱们先聊聊，如果没有熔断，Redis挂了会怎么样？

想象一下这个场景：你的电商网站，用户下单、查看商品详情、秒杀活动，所有这些操作都离不开后端的Redis，因为它太快了，能抗住高并发，突然，因为网络波动或者Redis服务器本身出了点问题，Redis服务响应变得极慢,甚至完全没响应了。

这时候，最可怕的事情发生了：你的应用服务器（比如Java程序）还在傻傻地、不停地向Redis发送请求，每一个请求都会卡在那里，等待Redis的超时（这个超时时间可能设置了几秒钟），很快地，应用服务器的线程池就会被这些“等待中”的请求全部占满，再也没有多余的线程去处理新的用户请求了，结果就是，整个网站的服务都被拖垮，雪崩式地崩溃，连那些不依赖Redis的简单页面也打不开了，这就叫“雪崩效应”。

那到底什么是服务熔断？能打个比方吗？

服务熔断,其实就跟家里的电闸开关一模一样。

当你家里某个电器短路，电流过载时，电闸会“啪”一声自动跳闸，切断整个电路，它这么做不是为了捣乱，而是为了保护整个家的电路不被烧毁,你总不能眼睁睁看着电线起火吧？

服务熔断也是这个道理，当系统检测到访问Redis的失败率（比如错误次数、超时次数）达到一个你设定的阈值时，熔断器就会自动“跳闸”，进入熔断开启状态，在这个状态下，对于后续所有访问Redis的请求，熔断器会立刻将其“拦下”，并直接返回一个失败结果（比如一个默认值、一个错误提示）,而根本不会真的把请求发到已经病恹恹的Redis服务器上去。

这样做的好处是：

• 保护Redis：给Redis喘息的机会，让它有机会从故障中恢复,而不是被持续的海量请求压死。
• 保护应用系统：应用服务器的线程资源不会被无限占用，整个系统还能保持部分可用性，至少能返回给用户一个友好的提示（如“系统繁忙，请稍后重试”）,而不是让用户一直白屏等待。

熔断器的工作流程，是不是跳闸后就一直断着？

不是的，一个成熟的熔断器一般有三种状态,它们之间会智能切换：

• 熔断关闭状态： 这是正常状态，请求可以自由地通过熔断器，访问Redis，熔断器会像一个会计一样,持续统计最近一段时间的请求成功和失败的数量。
• 熔断开启状态： 当失败率超过阈值，熔断器跳闸，进入这个状态，所有请求都会被快速失败,根本不会去访问Redis。
• 半开状态： 熔断器不会永远断着，在开启状态持续一段时间后（比如5秒），它会自动进入一个“半开”状态，这个状态可以理解为“试探性恢复”，熔断器会允许少量的、有限个请求通过，去尝试访问Redis，如果这些试探请求都成功了，说明Redis服务可能已经恢复了，那么熔断器就自动关闭，系统恢复正常，如果这些试探请求还是失败，那就说明Redis没好利索，熔断器会再次跳闸，继续待在开启状态,等待下一个周期再来试探。

这个过程是自动化的,不需要人工干预。

熔断和降级老是一起被提到，它俩是啥关系？

它们俩是亲密无间的搭档，都是为了在系统出问题时保证核心业务还能转,但分工不同：

• 熔断是“诊断医生”和“总开关”：它的核心工作是检测故障并果断切断流量，是一种被动防御机制，它判断“下游服务（Redis）不行了，不能再让它祸害大家了”。
• 降级是“应急预案”：它的核心工作是提供备用方案，当熔断器切断了对Redis的访问后，你的业务代码不能就这么报错啊？这时候降级策略就要上场了。
  • 本来从Redis查用户信息的，现在Redis熔断了，降级策略可以改为去数据库查（虽然慢点，但数据准）。
  • 或者，对于一些非核心数据，比如商品推荐列表,降级策略可以直接返回一个空的列表或者一套提前准备好的静态默认数据。
  • 再或者，直接返回一个“服务暂时不可用”的友好提示。

熔断是触发条件，降级是熔断后的处理手段，通常先有熔断,然后执行降级逻辑。

在实际项目中，怎么实现Redis的熔断？

你自己从零手写一个熔断器是比较复杂的，要考虑状态切换、时间窗口统计、并发控制等,通常我们都是用现成的轮子：

• 使用微服务框架内置的熔断器：比如在Java生态中，如果你用了Spring Cloud，那么Hystrix（虽然现在维护模式）或Resilience4j就是非常流行的选择，你只需要通过简单的注解（如 @HystrixCommand）配置在访问Redis的方法上，并指定失败率阈值、降级方法等,框架就帮你自动完成了所有熔断逻辑。
• 使用代理中间件：在一些架构中，也会通过服务网格（如Istio）或者API网关（如Spring Cloud Gateway）层面统一配置熔断规则,对所有通往Redis服务的流量进行管控。

配置熔断要注意哪些关键参数？

不是开了熔断就万事大吉,参数配置不对可能适得其反：

• 时间窗口：统计失败率的时间范围是多久？是最近10秒还是最近1分钟？这影响熔断触发的灵敏度。
• 失败阈值：比如在时间窗口内，请求失败比例超过50%就触发熔断，这个比例设得太低，可能因为偶尔的网络抖动就熔断；设得太高,又起不到保护作用。
• 熔断持续时间：跳闸后，要等多久才进入半开状态去试探？太短了，可能Redis还没恢复；太长了,用户体验差。
• 半开状态下的试探请求数：允许通过几个请求去试探？试探成功几个才算恢复？

这些参数没有银弹,需要根据实际业务的压力测试和监控指标来慢慢调整优化。

答完这些题，你应该明白了，Redis服务熔断不是一个高深莫测的黑科技，它就是一个朴素的“保护机制”，它的核心思想是“牺牲小我，保全大我”——宁可暂时牺牲掉对Redis的访问（提供有损服务），也要保住整个应用系统不崩溃，理解了它的工作原理、状态流转以及与降级的关系，并在项目中能正确地和相关组件（如Hystrix）结合起来使用，那么面试中关于Redis高可用、系统稳定性这块的知识点,你就算是真正摸透了。