1. 课程导论：OpenAPI限流熔断的背景与挑战，缓存一致性问题的引入
1.1 为什么需要限流与熔断？
在微服务架构与开放平台高速发展的今天，企业将核心业务能力封装为 OpenAPI 对外暴露。当 API 流量在短时间内爆发式增长（如秒杀、大促、爬虫攻击），后端服务极易因资源耗尽而雪崩。限流（Rate Limiting）与熔断（Circuit Breaking）成为保障系统稳定性的第一道防线。
核心矛盾： 既要允许突发流量在阈值内正常通过，又要在超限时快速拒绝请求并保护下游；同时，限流策略的实时性与准确性高度依赖分布式缓存（如 Redis）中的计数器与令牌桶状态。
1.2 典型限流熔断架构与缓存角色
现代 API 网关（如 Kong、APISIX、Zuul、Spring Cloud Gateway）通常采用 分布式缓存 + 本地缓存 两级架构来实现限流熔断。缓存承担着状态存储与快速判定的核心职责。
1.3 缓存一致性问题的引入
在上述两级缓存架构中，缓存一致性 成为限流熔断治理中最隐蔽也最具破坏力的技术债。当多个网关节点并发修改 Redis 中的限流计数器，或本地缓存与 Redis 中的令牌桶状态出现偏差时，系统将面临以下严重问题：
| 问题场景 | 具体表现 | 业务影响 |
|---|---|---|
| 计数器超卖 | 本地缓存未及时同步 Redis 扣减结果，多个节点同时认为配额充足 | 实际通过请求量超过限流阈值，后端被击穿 |
| 令牌桶不同步 | 某节点本地桶已空，但 Redis 桶仍有令牌；或反之 | 部分请求被错误拒绝（误杀），部分请求被错误放行（漏网） |
| 熔断状态滞后 | Redis 已标记熔断开启，但部分节点本地缓存仍为关闭状态 | 熔断窗口期内仍有流量涌入下游，雪崩风险加剧 |
| 降级策略冲突 | 不同节点对同一 API 执行不同的降级动作 | 用户体验割裂，调用方无法预期行为 |
关键认知： 缓存一致性不是“要不要”的问题，而是“在限流熔断场景下，不一致的代价有多高”。毫秒级的偏差就可能导致限流阈值失效，进而引发生产级故障。
1.4 从数据一致性看限流熔断的 CAP 权衡
分布式系统中的 CAP 定理同样适用于限流熔断缓存设计。在 API 网关场景下，我们通常需要做出以下权衡：
- 一致性（Consistency）： 所有网关节点看到的限流状态完全一致。强一致性意味着每次请求都要同步等待 Redis 确认，延迟增加。
- 可用性（Availability）： 即使 Redis 短暂不可用，网关仍能基于本地缓存继续限流判定，保证请求不被阻塞。
- 分区容忍性（Partition Tolerance）： 网络分区时，各节点独立运行，本地缓存与 Redis 必然出现分歧。
实际生产中，绝大多数团队选择了 最终一致性 + 本地缓存快速降级 的策略。但“最终”的窗口期多长？如何量化？这正是本课程要解决的核心问题。
1.5 本课程要解决的核心问题
本课程将围绕以下三个维度展开深度优化实践：
- 缓存同步策略选型： 对比 Redis Pub/Sub、Redis Stream、ZooKeeper Watch、本地广播等同步机制在限流场景下的优劣。
- 一致性协议定制： 基于 Redis Lua 脚本实现原子性限流操作，结合本地缓存 TTL 与版本号机制，将不一致窗口压缩到可控范围。
- 熔断状态传播： 设计熔断器状态变更的可靠广播与确认回执机制，确保所有网关节点在熔断窗口内同步切换。
课程收益： 学完本课程后，你将能够设计一套在 高并发（10万+ QPS） 场景下，缓存不一致窗口 < 50ms，且具备自动降级与自愈能力的限流熔断治理方案。