Sentinel 限流熔断在营销活动中的落地

1. 对应简历段落

对应简历中可以这样描述：

在营销活动和商机转化系统中，负责基于 Sentinel 建设接口级限流、热点参数限流、熔断降级和系统自适应保护能力。针对活动报名、线索导入、报价试算、销售分配、短信触达等高峰场景，配置 QPS、并发线程数、慢调用比例、异常比例和热点客户参数规则，结合降级兜底、排队削峰、监控告警和压测基线，降低活动峰值对核心客户、商机和出单系统的冲击。

这段简历要讲清楚两个关键词：营销活动的流量不可预测，以及稳定性治理要保护核心链路。Sentinel 的价值不只是“拦请求”，而是让系统在高峰和下游异常时有秩序地退化。

2. 业务背景

营销活动系统经常呈现典型峰值特征。运营会在固定时间群发短信、企微推送或投放广告，客户在短时间内集中访问活动页、提交报名、领取权益、试算报价。销售团队也可能在活动后集中导入线索、批量分配商机、触发短信回访。

如果没有流量治理，入口流量会一路穿透到客户中心、商机中心、报价系统、库存权益系统、短信平台和数据库。一个慢接口可能占满 Tomcat 线程，一个外部短信平台超时可能拖垮活动报名，一个热门活动 ID 可能把某张库存表锁住。

项目目标不是让所有请求都成功，而是在资源有限时保证最重要的请求成功。比如活动页静态内容可以降级，重复点击可以限流，报表统计可以延迟，权益领取要严格保护库存和幂等，出单链路要优先保障。

3. 核心原理

Sentinel 以资源为维度做流量控制。资源可以是 HTTP 接口、Dubbo 方法、Spring Cloud OpenFeign 调用，也可以是代码中手动定义的一段逻辑。每个资源都可以配置规则。

常用规则包括：

  1. 流控规则：按 QPS 或并发线程数限制访问量。
  2. 热点参数规则：针对某些参数值单独限流，比如热门活动 ID、热门产品 ID。
  3. 熔断规则：根据慢调用比例、异常比例或异常数触发降级。
  4. 系统规则：根据系统 Load、CPU、入口 QPS、线程数等做整体保护。
  5. 授权规则：按来源控制黑白名单。

限流解决的是“流量太大”，熔断解决的是“下游或自身已经不健康”，降级解决的是“失败时给出可接受的兜底”。这三者要一起设计。

4. 项目落地

以活动报名链路为例，入口请求会经过活动服务、客户中心、商机服务、权益库存、短信通知和报表埋点。我们可以把链路拆分为三类资源：

第一类是入口资源，例如 /api/activity/register。它直接面对用户，需要设置入口 QPS 上限和排队等待策略，避免瞬时流量打满线程池。

第二类是核心依赖资源，例如 customerService.getOrCreateCustomer、benefitService.lockQuota、opportunityService.createLead。这些调用需要配置慢调用比例和异常比例熔断，下游异常时快速失败，避免请求长期阻塞。

第三类是非核心资源，例如短信通知、运营埋点、报表刷新。它们可以异步化或降级，不能影响报名主链路。

热点参数限流在营销活动里非常重要。活动列表可能有多个活动，但只有一个爆款活动瞬间被大量访问。如果只对整个报名接口限流，会影响其他活动；按 activityId 做热点限流，可以只保护爆款活动对应的库存、规则和数据库行。

项目里还应建立规则分级：

场景规则兜底
活动页查询QPS 限流、缓存兜底返回缓存或稍后重试
活动报名QPS + 热点参数限流提示排队或报名繁忙
权益库存并发线程数限制返回权益领取中
报价试算慢调用比例熔断返回简化报价或稍后查看
短信通知异常比例熔断写入补发任务

5. 关键配置或伪代码

代码中定义资源：

@SentinelResource(
        value = "activityRegister",
        blockHandler = "registerBlocked",
        fallback = "registerFallback")
public RegisterResult register(ActivityRegisterCommand command) {
    Customer customer = customerClient.getOrCreate(command);
    BenefitResult benefit = benefitService.lockQuota(command.getActivityId(), customer.getId());
    Opportunity opp = opportunityService.createFromActivity(command, customer, benefit);
    messagePublisher.publishRegisterSuccess(opp);
    return RegisterResult.success(opp.getId());
}

限流兜底：

public RegisterResult registerBlocked(ActivityRegisterCommand command, BlockException ex) {
    metrics.counter("activity.register.block", command.getActivityId()).increment();
    return RegisterResult.busy("当前报名人数较多，请稍后重试");
}

public RegisterResult registerFallback(ActivityRegisterCommand command, Throwable ex) {
    compensationRepository.save(command, ex.getMessage());
    return RegisterResult.accepted("报名请求已受理，请稍后查看结果");
}

热点参数规则思路：

ParamFlowRule rule = new ParamFlowRule("activityRegister")
        .setParamIdx(0)
        .setCount(200)
        .setDurationInSec(1);

实际项目里规则通常放在 Nacos 或 Sentinel Dashboard 中动态维护，而不是写死在代码里。活动上线前根据压测结果设置基线，例如单实例报名入口 300 QPS，权益库存资源并发 50，报价试算慢调用比例超过 50% 且持续 10 秒触发熔断。

6. 常见坑

第一个坑是只做入口限流。入口限流能挡一部分流量，但如果内部某个依赖特别脆弱，还是可能被打穿。核心依赖也要作为 Sentinel 资源保护。

第二个坑是阈值拍脑袋。限流阈值必须来自压测、历史峰值和下游容量，而不是随便写 1000。阈值太低会误伤业务，太高则没有保护效果。

第三个坑是降级文案和业务兜底缺失。限流后如果直接返回异常栈，用户体验和排查都很差。应该明确哪些场景返回“稍后重试”，哪些场景写补偿任务。

第四个坑是熔断后没有恢复观察。下游短暂异常恢复后，系统要逐步恢复调用，不能在熔断和放量之间来回抖动。要关注熔断时长、最小请求数和统计窗口。

第五个坑是热点参数没做。营销活动最容易出现单活动、单产品、单客户经理、单渠道热点，只看接口总 QPS 会掩盖局部热点。

第六个坑是把 Sentinel 当权限系统。Sentinel 可以做来源授权，但它不是认证鉴权方案，不能替代登录态、签名和权限校验。

7. 面试追问

常见追问包括：

  1. Sentinel 和 Hystrix 的区别是什么？
  2. QPS 限流和并发线程数限流怎么选？
  3. 熔断规则中的慢调用比例如何配置？
  4. 热点参数限流怎么落到方法参数？
  5. 被限流的请求如何保证业务可接受？
  6. Sentinel 规则是写死还是动态推送？
  7. 如果 Sentinel Dashboard 挂了，规则还生效吗？
  8. 活动高峰前如何确定阈值？

回答时不要只背概念，要结合活动报名、权益库存、报价试算这些具体资源讲。

8. 推荐回答

可以这样回答：

“我们在营销活动里用 Sentinel，不是单纯为了拒绝请求，而是为了保护核心链路。活动开始时流量会集中涌入，如果全部打到客户、商机、权益库存和报价系统，很容易把线程池和数据库连接耗尽。所以我们把入口接口、核心下游调用、热点活动参数都定义成资源，分别配置 QPS、并发线程数、慢调用比例和异常比例规则。”

“QPS 限流适合入口流量，比如活动报名接口每秒最多接收多少请求；并发线程数更适合保护慢资源，比如权益库存或外部报价接口，防止慢调用占满业务线程。热点参数限流按 activityId 做，避免一个爆款活动影响其他活动。熔断规则主要用于下游不健康时快速失败，比如报价接口慢调用比例超过阈值，就短时间返回兜底结果或提示稍后查看。”

“规则我们没有写死在代码里，而是通过 Nacos 动态配置。活动上线前会做压测，得到单实例容量和下游容量，再结合实例数设置阈值。被限流的请求会返回业务可理解的提示，关键请求会写入排队或补偿表，非核心动作如短信和报表走 MQ 异步补偿。监控上关注通过量、拒绝量、异常比例、平均 RT 和熔断次数，活动期间有人值守调整规则。”

9. 延伸学习路线

第一步，掌握 Sentinel 的资源、规则、Slot Chain、统计窗口和 Dashboard 基本模型。

第二步，分别练习 QPS 限流、并发线程数限流、热点参数限流、慢调用比例熔断和异常比例熔断。

第三步，把 Sentinel 与 Spring Cloud Gateway、OpenFeign、Dubbo、Nacos 动态规则结合起来，理解网关层和服务层保护的差异。

第四步，学习稳定性工程方法，包括压测、容量评估、降级预案、故障演练、监控告警和活动保障。

第五步，结合真实业务复盘一次高峰链路，画出每个资源的容量、依赖和兜底策略。面试时能讲出“保护谁、牺牲谁、怎么恢复”，比只会配置规则更有说服力。