2.3 java面试题：sentinel

好的，Sentinel 的自动降级是微服务稳定性保障的核心手段，也是面试中衡量你是否具备高可用设计能力的关键考点。下面我从原理、策略、实现、配置、银行场景实践等多个维度，给你一个能体现四年老手经验的全面回答。

一、什么是 Sentinel 降级？

降级是指在系统面临高负载、依赖服务不稳定或自身资源紧张时，主动放弃非核心功能或快速返回一个预设的兜底结果，从而保护系统不被拖垮，保证核心链路的可用性。

Sentinel 的降级是自动化的：它基于实时指标统计，当某个资源的调用满足预设的阈值条件时，自动触发降级，不再调用实际业务逻辑，而是执行降级处理函数（blockHandler 或 fallback）。

二、自动降级的三种策略

策略	指标	判断逻辑	适用场景
慢调用比例 (SLOW_REQUEST_RATIO)	响应时间	当慢调用（超过最大RT）的比例超过阈值，且请求数大于最小请求数时触发	下游服务变慢，需要快速释放线程资源
异常比例 (ERROR_RATIO)	异常数/总调用数	当异常比例超过阈值，且请求数大于最小请求数时触发	下游服务异常率飙升，如数据库死锁
异常数 (ERROR_COUNT)	一分钟内异常数	当一分钟内异常数超过阈值，且请求数大于最小请求数时触发	精确控制异常数量，适合低流量接口

降级状态 ：触发降级后进入降级模式，在接下来的时间窗口（可配置）内，所有请求直接走降级逻辑，不会调用真实资源。时间窗口结束后自动恢复，若再次触发则再次降级（断路器模型）。

三、自动降级的工作机制

Sentinel 基于滑动窗口 实时统计每个资源的调用数据（RT、异常、成功/失败）。

当资源被调用时：

统计窗口记录每次调用的结果。
判断规则：遍历该资源配置的降级规则，根据当前统计数据计算指标（慢调用比例、异常比例等）。
如果满足规则条件，将资源状态标记为 降级状态（DEGRADED），并进入降级时间窗口。
降级窗口内，直接执行降级处理逻辑（@SentinelResource 的 fallback / blockHandler 或 UrlBlockHandler）。
窗口结束后，自动尝试下一次真实调用（半开状态），如果成功则退出降级；如果仍失败则继续降级。

源码核心 ：DegradeSlot 拦截调用，调用 DegradeRuleManager 检查规则，触发放行或抛出 DegradeException。

四、如何在 Spring Cloud Alibaba 项目中使用自动降级（代码案例）

1. 引入依赖

xml 复制代码

<dependency>
    <groupId>com.alibaba.cloud</groupId>
    <artifactId>spring-cloud-starter-alibaba-sentinel</artifactId>
</dependency>

2. 在控制层或服务层使用 `@SentinelResource` 定义降级方法

java 复制代码

@RestController
public class LoanController {

    @GetMapping("/loan/info/{loanId}")
    @SentinelResource(value = "loanInfo", 
                      fallback = "getLoanInfoFallback",
                      blockHandler = "getLoanInfoBlockHandler")
    public LoanInfoDTO getLoanInfo(@PathVariable String loanId) {
        // 真实业务逻辑，可能调用远程服务
        return loanService.query(loanId);
    }

    // 业务异常 fallback（降级后或业务异常时执行）
    public LoanInfoDTO getLoanInfoFallback(String loanId, Throwable e) {
        log.error("贷款查询降级: loanId={}, error={}", loanId, e.getMessage());
        return LoanInfoDTO.fallback();  // 返回缓存或默认值
    }

    // 流控/降级 blockHandler（仅限流或降级触发）
    public LoanInfoDTO getLoanInfoBlockHandler(String loanId, BlockException e) {
        log.warn("贷款查询被限流/降级: loanId={}", loanId);
        return LoanInfoDTO.busy();  // 返回系统繁忙提示
    }
}

3. 配置降级规则（可在 Sentinel 控制台动态配置，也可代码硬编码）

在 Sentinel 控制台（localhost:8080）中为资源 loanInfo 添加降级规则：

慢调用比例：最大 RT 200ms，比例 0.2，窗口 10s → 当 20% 请求超过 200ms 时降级 10s。
异常比例：比例 0.1，窗口 30s → 当异常率超过 10% 时降级 30s。

或者通过代码配置（用于测试或不需要控制台的场景）：

java 复制代码

@Component
public class SentinelRuleConfig {
    @PostConstruct
    public void initDegradeRules() {
        List<DegradeRule> rules = new ArrayList<>();
        DegradeRule rule = new DegradeRule("loanInfo")
            .setGrade(RuleConstant.DEGRADE_GRADE_EXCEPTION_RATIO)
            .setCount(0.1)        // 异常比例 10%
            .setTimeWindow(30)    // 降级窗口 30s
            .setMinRequestAmount(5);
        rules.add(rule);
        DegradeRuleManager.loadRules(rules);
    }
}

4. 整合 Feign 实现远程调用的自动降级

java 复制代码

@FeignClient(name = "deposit-service", fallbackFactory = DepositClientFallbackFactory.class)
public interface DepositClient {
    @GetMapping("/balance/{accountId}")
    BalanceDTO getBalance(@PathVariable("accountId") String accountId);
}

@Component
public class DepositClientFallbackFactory implements FallbackFactory<DepositClient> {
    @Override
    public DepositClient create(Throwable cause) {
        log.error("存款服务调用异常，进入降级: {}", cause.getMessage());
        return accountId -> new BalanceDTO(0); // 返回空余额或缓存值
    }
}

同时，在 Feign 的配置中开启 Sentinel 支持：

yaml 复制代码

feign:
  sentinel:
    enabled: true

这样，当存款服务出现慢调用、异常比例等符合降级规则时，自动执行 fallbackFactory 中的逻辑。

5. 集成 Sentinel 与 Gateway 网关降级

在网关层也可以配置降级规则，针对路由做全局保护：

yaml 复制代码

spring:
  cloud:
    sentinel:
      scg:
        fallback:
          response-status: 429
          response-body: "{\"code\":429,\"message\":\"服务降级中\"}"

然后在控制台为路由 ID 设置降级规则。

五、银行核心场景下的降级实践与注意事项

1. 案例：贷款审批查询降级

场景：贷款审批服务依赖核心征信系统，当征信系统响应变慢（RT > 1s），大量线程阻塞，拖垮审批服务。
降级策略 ：
- 使用慢调用比例规则，最大 RT 1s，比例 0.3，窗口 60s。
- 降级后，返回缓存的征信评分或提示"征信查询繁忙，请稍后重试"。
- 配置 blockHandler 返回友好信息，同时记录事件。

2. 资金交易类接口的降级注意事项

写操作慎用降级 ：转账、放款等接口降级会导致交易丢失或状态不一致。我们通常不对写操作配置自动降级，而是通过限流（QPS 控制）和快速失败来保护，并依赖事务和幂等机制保证一致性。
读操作优先降级：查询余额、历史明细等读操作可以安全降级，返回缓存数据或空列表。
结合 TCC 的降级：在 TCC 分布式事务中，如果 Confirm/Cancel 阶段调用远程服务触发降级，不能简单返回降级值，而应重试或进入人工处理队列。我们为 Confirm 接口设置了更高的超时和降级阈值，并开启重试。

3. 动态配置降级规则

生产环境通过 Sentinel 控制台实时修改降级阈值，无需重启服务。比如大促期间适当放宽降级条件，优先保证可用性。
使用 Nacos 持久化 降级规则，防止控制台重启后规则丢失：

yaml 复制代码

spring:
  cloud:
    sentinel:
      datasource:
        degrade:
          nacos:
            server-addr: localhost:8848
            dataId: ${spring.application.name}-degrade-rules
            groupId: SENTINEL_GROUP
            rule-type: degrade

4. 监控与告警

监控 Sentinel 日志（${user.home}/logs/csp/sentinel-record.log）中的降级事件。
通过 Sentinel 的 Prometheus 集成，在 Grafana 中创建降级大盘，对频繁降级的资源告警。
日志记录降级详情，包括资源名、触发规则、时间窗口，便于事后分析。

六、面试模板话术

"Sentinel 的自动降级我主要用于保护服务依赖的稳定性。核心是慢调用比例、异常比例、异常数三种策略，基于滑动窗口统计，触发后进入时间窗口降级，窗口结束自动恢复。

在银行项目中，我对所有查询类接口都配置了降级规则，比如贷款详情查询当异常比例超过 10% 时降级 30 秒，返回缓存或友好提示。通过 Feign 的 fallbackFactory 实现远程调用的降级，并集成 Nacos 动态配置规则。

写操作如转账，我不敢用自动降级，而是通过限流和事务保证一致性。降级事件必须监控，我们通过 Prometheus 采集 Sentinel 指标，配置了降级次数的告警，确保故障时第一时间介入。

最重要的是，降级不是目的，是保命手段，需要定期演练和调优阈值。"

这套回答，既有理论，又有结合金融场景的谨慎权衡，再加上具体的配置和代码案例，足以证明你对 Sentinel 的自动降级已经掌握到可独立设计高可用系统的程度。

好的，Sentinel 的限流是保障系统稳定性的第一道防线，也是面试中衡量你是否具备高可用设计能力的高频考点。下面我从限流算法、Sentinel 实现原理、规则配置、与 Spring Cloud 集成、银行生产实践五个维度，给出一个能体现你四年老手经验的深度回答。

一、Sentinel 限流解决了什么问题？

在高并发场景下，如果不对请求进行控制，瞬时流量会打垮系统（如数据库连接池耗尽、线程池满载、CPU 100%）。限流的本质是控制访问速率，超过阈值的请求直接拒绝或排队等待，从而保护系统在合理负载下运行。

Sentinel 的限流是细粒度、自动化、实时生效的，它可以对任意资源（URL、方法、RPC 接口）设置 QPS 或并发线程数限制。

二、Sentinel 限流的核心算法

Sentinel 默认使用滑动窗口计数器 算法，同时也支持漏桶（排队等待）效果。

1. 滑动窗口计数器（默认，用于 QPS 限流）

原理：将时间划分为多个小窗口（默认 2 个窗口，每个窗口 500ms），每个窗口独立计数。
判断：当前时间窗口的计数 + 前一个窗口的计数是否超过阈值。
优势：解决了简单固定窗口的"临界突刺"问题，精度高，内存占用少。
Sentinel 实现 ：LeapArray 滑动窗口数组，底层用 MetricBucket 统计成功/异常/RT 等。

2. 漏桶（排队等待，用于流量整形）

原理：请求进入队列，以固定速率出队执行，超过队列最大等待时间则拒绝。
适用场景：需要平滑突发流量，如对下游数据库的保护，避免瞬间冲击。
Sentinel 实现 ：RateLimiterController，可设置 slowRatioThreshold 参数。

3. 并发线程数限流

原理：控制同一时刻访问该资源的线程数，超过阈值立即拒绝。
适用场景：对异步或长耗时操作的保护，避免线程资源耗尽。
Sentinel 实现 ：SimpleHttpInterceptor 统计当前并发数。

三、Sentinel 限流规则的配置

限流规则通过 FlowRule 对象定义，支持控制台动态配置、代码硬编码或 Nacos 持久化。

规则参数详解

参数	说明
`resource`	资源名（如 URL 路径、`@SentinelResource` 的 value）
`grade`	限流模式：`FLOW_GRADE_QPS` (QPS 限制) 或 `FLOW_GRADE_THREAD` (线程数限制)
`count`	阈值
`strategy`	调用关系限流策略：直接、关联、链路
`controlBehavior`	流量控制行为：直接拒绝、Warm Up（预热）、匀速排队
`warmUpPeriodSec`	预热时间（秒）
`maxQueueingTimeMs`	匀速排队最大等待时间（ms）

直接拒绝模式（默认）

超过阈值立即抛出 FlowException，调用 blockHandler 处理。

Warm Up（预热）

当系统刚启动时，允许缓慢增加流量，避免冷系统被瞬间大流量压垮。例如阈值 100，预热 10 秒，则初始只有 100/3 ≈ 33，逐步增加。

匀速排队（漏桶）

将请求以固定间隔放入队列，平滑输出流量。

四、在 Spring Cloud Alibaba 中如何使用限流（代码案例）

1. 依赖与配置

xml 复制代码

<dependency>
    <groupId>com.alibaba.cloud</groupId>
    <artifactId>spring-cloud-starter-alibaba-sentinel</artifactId>
</dependency>

yaml 复制代码

spring:
  cloud:
    sentinel:
      transport:
        dashboard: localhost:8080   # 控制台地址
      datasource:
        flow:
          nacos:                    # 规则持久化到 Nacos
            server-addr: localhost:8848
            dataId: ${spring.application.name}-flow-rules
            groupId: SENTINEL_GROUP
            rule-type: flow

2. 使用 `@SentinelResource` 定义资源与限流处理

java 复制代码

@RestController
public class DepositController {

    @GetMapping("/deposit/balance/{accountId}")
    @SentinelResource(value = "getBalance", blockHandler = "handleFlow")
    public BalanceDTO getBalance(@PathVariable String accountId) {
        // 实际业务逻辑
        return depositService.queryBalance(accountId);
    }

    // 限流/降级时执行的方法，必须与原方法参数一致并增加 BlockException
    public BalanceDTO handleFlow(String accountId, BlockException e) {
        log.warn("查询余额被限流: accountId={}", accountId);
        return new BalanceDTO("系统繁忙，请稍后重试");
    }
}

3. 在 Sentinel 控制台动态配置规则

访问 http://localhost:8080，找到 getBalance 资源，添加流控规则：

QPS 100，直接拒绝 → 当 QPS 超过 100 时返回限流提示。
或选择Warm Up，阈值 200，预热 5 秒 → 适合服务刚重启时逐步放量。

4. 代码硬编码配置（测试场景或初始化）

java 复制代码

@Component
public class FlowRuleInit {
    @PostConstruct
    public void init() {
        List<FlowRule> rules = new ArrayList<>();
        FlowRule rule = new FlowRule("getBalance")
            .setGrade(RuleConstant.FLOW_GRADE_QPS)
            .setCount(100)
            .setLimitApp("default")
            .setControlBehavior(RuleConstant.CONTROL_BEHAVIOR_DEFAULT);
        rules.add(rule);
        FlowRuleManager.loadRules(rules);
    }
}

5. 网关层限流

yaml 复制代码

spring:
  cloud:
    sentinel:
      scg:
        fallback:
          response-status: 429
          response-body: '{"code":429,"message":"请求过多"}'

然后在控制台为网关路由设置限流规则，支持按 QPS 或线程数限流。

五、限流在银行核心系统中的应用实践

1. 场景 1：保护核心账务接口

资源：/core/account/debit（扣款）
配置：QPS 500，控制行为为匀速排队，最大排队 200ms。
目的：平滑流量，避免扣款操作瞬间打满数据库连接池。
兜底：超出排队时间直接拒绝，返回"系统繁忙"，同时调用方做重试。

2. 场景 2：服务预热（Warm Up）

场景：存款服务重启后，本地缓存（Caffeine、Redis 连接池）未完全就绪，若瞬间涌入全量流量会导致超时。
配置：Warm Up 模式，初始 QPS 50，预热 30s 逐渐升到 500。
效果：配合健康检查和权重控制，优雅上线。

3. 场景 3：关联限流

资源：/loan/disburse 和 /loan/approve，两者共用相同的额度查询接口。
策略：设置关联限流，当 /loan/approve 的 QPS 超过 200 时，自动限制 /loan/disburse，保证审批优先。

4. 写操作限流的特殊处理

对于转账、放款等关键写操作，我们不使用简单拒绝 ，而采用排队等待 或 MQ 异步削峰。直接拒绝可能导致交易丢失，因此限流配合持久化队列和重试机制。

5. 动态调整规则

通过 Nacos 持久化限流规则，并在 Sentinel 控制台实时调整。双十一、国债发行期间，临时调高限额；促销结束后恢复默认。

6. 监控

监控 Sentinel 的 block_count、pass_count、qps 指标，通过 Prometheus + Grafana 展示。
配置告警：当某个核心接口的限流拒绝次数 > 0 持续 1 分钟，立即通知开发。

六、面试模板话术

"Sentinel 限流我理解核心是滑动窗口计数器算法，支持 QPS 和并发线程数两种模式，还有 Warm Up 预热和匀速排队。在项目中，我们为所有核心接口配置了限流规则，通过控制台动态管理，并持久化到 Nacos。

对于查询类接口，我们用直接拒绝快速返回；对于扣款等写操作，我用匀速排队平滑流量，保证数据库压力可控。上线时用 Warm Up 预热，防止冷启动雪崩。我们还用关联限流保证核心审批优先于放款。

限流不是阻断，而是保护系统稳定，配合降级、熔断和 MQ 削峰组成完整的高可用体系。监控上通过 Prometheus 采集 Sentinel 指标，对拒绝次数配置了告警，确保第一时间响应。"

这套回答既有算法原理，又有实战配置和银行场景的谨慎考量，能充分展示你对 Sentinel 限流的深入理解和生产经验。

在微服务架构中，熔断是防止级联故障的核武器。Sentinel 的熔断机制基于"断路器"模型，能实时监控下游依赖的调用状态，一旦达到阈值就自动切断流量，快速失败并执行降级逻辑，经过一段恢复期后再尝试放行。下面我从原理、规则、实现、银行实践四个层面帮你彻底吃透。

一、熔断解决的问题

假设贷款服务调用征信接口。如果征信系统突然变慢或出错，贷款服务的线程会大量阻塞等待，最终导致线程池耗尽、整个服务不可用，进而拖垮上游网关，形成雪崩。

熔断的作用就是：当下游不可靠时，立即切断调用，快速失败，避免故障扩散。

二、Sentinel 熔断的三种策略

策略	判定指标	触发条件	适用场景
慢调用比例	响应时间 > 最大 RT 的调用比例	比例 > 阈值，且统计窗口内请求数 ≥ 最小请求数	下游变慢，需快速释放线程
异常比例	异常调用数 / 总调用数	比例 > 阈值，且请求数 ≥ 最小请求数	下游出错率高
异常数	1 分钟内异常调用绝对数	异常数 > 阈值，且请求数 ≥ 最小请求数	低流量接口，精确控制

熔断状态机 ：

关闭(Closed) → 满足条件触发 → 打开(Open，拒绝所有请求并执行降级) → 经过熔断时长后 → 半开(Half-Open，放行一个请求试探) → 成功则关闭，失败则继续打开。

三、Sentinel 熔断的工作原理

Sentinel 使用滑动窗口 （LeapArray）对每个资源独立统计指标（RT、成功/异常数）。工作流程：

请求进入时，先检查该资源是否处于熔断打开状态 → 如果是，直接调用降级方法，抛出 DegradeException。
如果不是，放行请求，记录本次调用的结果（成功、异常、RT）。
统计模块实时计算慢调用比例、异常比例等，与配置的规则比较。
若满足触发条件，将资源状态切换为 熔断打开 ，并启动一个定时任务，在 timeWindow 后自动切换到半开状态。
半开状态下，只允许一个请求通过，如果成功则关闭熔断，失败则重新打开。

关键类 ：DegradeSlot（Slot Chain 中的一环）→ DegradeRuleManager → CircuitBreaker 实例（ExceptionCircuitBreaker / ResponseTimeCircuitBreaker）。

四、Spring Cloud Alibaba 中实现熔断（代码案例）

1. 启用 Sentinel 并配置规则持久化

yaml 复制代码

spring:
  cloud:
    sentinel:
      transport:
        dashboard: localhost:8080
      datasource:
        degrade:
          nacos:
            server-addr: localhost:8848
            dataId: ${spring.application.name}-degrade-rules
            groupId: SENTINEL_GROUP
            rule-type: degrade

2. 使用 `@SentinelResource` 定义资源与降级处理

java 复制代码

@RestController
public class LoanController {

    @GetMapping("/loan/info/{loanId}")
    @SentinelResource(value = "loanInfo", 
                      fallback = "getLoanInfoFallback",
                      blockHandler = "getLoanInfoBlockHandler")
    public LoanInfoDTO getLoanInfo(@PathVariable String loanId) {
        // 实际调用征信或其他依赖
        return loanService.queryLoanInfo(loanId);
    }

    // 业务异常或熔断降级时执行
    public LoanInfoDTO getLoanInfoFallback(String loanId, Throwable e) {
        log.error("贷款信息查询降级: loanId={}, reason={}", loanId, e.getMessage());
        // 返回缓存或默认值
        return cacheService.getLoanInfoFromCache(loanId);
    }

    // 限流/熔断 blockHandler
    public LoanInfoDTO getLoanInfoBlockHandler(String loanId, BlockException e) {
        log.warn("贷款信息查询被熔断: loanId={}", loanId);
        return new LoanInfoDTO("系统繁忙，请稍后重试");
    }
}

3. 在 Sentinel 控制台配置熔断规则

例如对资源 loanInfo：

慢调用比例 ：最大 RT 500ms，慢调用比例 0.5，最小请求数 5，熔断时长 30s
当 50% 以上的请求响应时间超过 500ms 时，熔断 30 秒。
异常比例 ：异常比例 0.3，最小请求数 10，熔断时长 20s
当 30% 的请求抛出异常时熔断 20 秒。

4. Feign 集成熔断（远程调用自动降级）

java 复制代码

@FeignClient(name = "deposit-service", fallbackFactory = DepositClientFallbackFactory.class)
public interface DepositClient {
    @GetMapping("/balance/{accountId}")
    BalanceDTO getBalance(@PathVariable("accountId") String accountId);
}

@Component
public class DepositClientFallbackFactory implements FallbackFactory<DepositClient> {
    @Override
    public DepositClient create(Throwable cause) {
        log.error("存款服务调用异常，熔断降级: {}", cause.getMessage());
        return accountId -> new BalanceDTO(0); // 返回默认值
    }
}

Feign 开启 Sentinel 支持：

yaml 复制代码

feign:
  sentinel:
    enabled: true

这样当调用存款服务失败率或慢调用达到阈值时，自动走 fallback，避免阻塞。

5. 代码方式配置规则（初始化或测试）

java 复制代码

@Component
public class DegradeRuleInit {
    @PostConstruct
    public void init() {
        List<DegradeRule> rules = new ArrayList<>();
        DegradeRule rule = new DegradeRule("loanInfo")
            .setGrade(RuleConstant.DEGRADE_GRADE_EXCEPTION_RATIO)
            .setCount(0.3)
            .setTimeWindow(20)
            .setMinRequestAmount(10);
        rules.add(rule);
        DegradeRuleManager.loadRules(rules);
    }
}

五、银行核心场景下的熔断实践

1. 案例：征信服务变慢

场景：征信接口因第三方网络波动，RT 从 200ms 飙升至 2s，导致贷款审批线程池满。
熔断策略 ：配置慢调用比例，最大 RT 800ms，比例 0.4，熔断时长 60s。
降级逻辑：返回缓存的征信评分（Redis，5 分钟有效期），并提示"征信查询稍慢，使用缓存数据"。
效果：线程池立刻释放，审批服务恢复，客户体验略有下降但可接受。

2. 案例：核心账务服务异常

场景：核心账务系统因日切跑批，短时间内返回大量系统错误。
熔断策略 ：异常比例 0.2，最小请求数 50，熔断时长 120s。
降级逻辑：对于查询类请求，返回上次缓存；对于扣款类写请求，进入重试队列，由后台 Job 补偿。

3. 写操作熔断的特殊处理

原则：写操作（转账、放款）不轻易熔断 ，否则会导致业务中断、数据不一致。我们通常只对读操作启用自动熔断。
写操作的保护 ：用限流而非熔断，通过排队等待或 MQ 削峰保证最终一致性。
必须熔断时 ：当依赖的核心系统出现全面崩溃（如主机宕机），并且我们有明确的事务补偿方案（如 TCC 的 Cancel 接口、冲正），才启用熔断，并配合重试和人工干预。

4. 动态配置与监控

所有熔断规则持久化到 Nacos，通过 Sentinel 控制台实时调整。
监控 Sentinel 的 degrade_open_count、degrade_half_open_count，在 Grafana 中展示。
告警：当某个核心接口熔断打开超过 5 分钟，立即电话通知值班人员。

六、熔断与降级、限流的关系（面试必问）

限流：控制访问速率（流量整形），超过阈值拒绝或排队，保护自身服务。
熔断：当下游依赖故障时，自动切断调用，快速失败，防止级联雪崩。
降级：熔断/限流后执行的兜底逻辑，返回缓存、默认值或友好提示。
它们是微服务稳定性的"三剑客"：限流是主动防御，熔断是止损，降级是托底。

七、面试模板话术

"Sentinel 的熔断我使用慢调用比例、异常比例、异常数三种策略，基于滑动窗口统计，触发后进入熔断打开状态，执行降级逻辑，经过熔断时长后半开试探，成功关闭。

在银行项目中，对查询类接口我启用自动熔断，比如征信服务慢调用比例超过 50% 时熔断 30 秒，返回缓存数据。对写操作我谨慎使用熔断，更依赖限流和 MQ 保证交易安全。

熔断规则通过 Nacos 持久化，控制台动态调整，所有熔断事件都记日志并接入 Prometheus 告警。熔断不是目的，是系统自保护的底线机制，需要结合补偿和监控才能用得放心。"

2.3 java面试题：sentinel

一、什么是 Sentinel 降级？

二、自动降级的三种策略

三、自动降级的工作机制

四、如何在 Spring Cloud Alibaba 项目中使用自动降级（代码案例）

1. 引入依赖

2. 在控制层或服务层使用 @SentinelResource 定义降级方法

3. 配置降级规则（可在 Sentinel 控制台动态配置，也可代码硬编码）

4. 整合 Feign 实现远程调用的自动降级

5. 集成 Sentinel 与 Gateway 网关降级

五、银行核心场景下的降级实践与注意事项

1. 案例：贷款审批查询降级

2. 资金交易类接口的降级注意事项

3. 动态配置降级规则

4. 监控与告警

六、面试模板话术

一、Sentinel 限流解决了什么问题？

二、Sentinel 限流的核心算法

1. 滑动窗口计数器（默认，用于 QPS 限流）

2. 漏桶（排队等待，用于流量整形）

3. 并发线程数限流

三、Sentinel 限流规则的配置

规则参数详解

直接拒绝模式（默认）

Warm Up（预热）

匀速排队（漏桶）

四、在 Spring Cloud Alibaba 中如何使用限流（代码案例）

1. 依赖与配置

2. 使用 @SentinelResource 定义资源与限流处理

3. 在 Sentinel 控制台动态配置规则

4. 代码硬编码配置（测试场景或初始化）

5. 网关层限流

五、限流在银行核心系统中的应用实践

1. 场景 1：保护核心账务接口

2. 场景 2：服务预热（Warm Up）

3. 场景 3：关联限流

4. 写操作限流的特殊处理

5. 动态调整规则

6. 监控

六、面试模板话术

一、熔断解决的问题

二、Sentinel 熔断的三种策略

三、Sentinel 熔断的工作原理

四、Spring Cloud Alibaba 中实现熔断（代码案例）

1. 启用 Sentinel 并配置规则持久化

2. 使用 @SentinelResource 定义资源与降级处理

3. 在 Sentinel 控制台配置熔断规则

4. Feign 集成熔断（远程调用自动降级）

5. 代码方式配置规则（初始化或测试）

五、银行核心场景下的熔断实践

1. 案例：征信服务变慢

2. 案例：核心账务服务异常

3. 写操作熔断的特殊处理

4. 动态配置与监控

六、熔断与降级、限流的关系（面试必问）

七、面试模板话术

2. 在控制层或服务层使用 `@SentinelResource` 定义降级方法

2. 使用 `@SentinelResource` 定义资源与限流处理

2. 使用 `@SentinelResource` 定义资源与降级处理