1.1 课程导论：熔断机制与限流算法概述
在微服务与高并发系统中，熔断与限流是保障服务稳定性的两大核心手段。熔断关注调用链的故障隔离，限流关注入口流量的平滑控制。本课程将围绕“熔断窗口”与“Redis令牌桶”展开实战讲解。
1.1.1 熔断机制：快速失败与恢复
熔断机制借鉴了电路断路器的思想：当某个下游服务持续超时或异常时，熔断器打开，直接拒绝后续请求，避免级联故障。熔断器通常包含三种状态：
- 关闭（Closed）：正常调用，统计失败次数。
- 打开（Open）：失败阈值达到，直接拒绝请求。
- 半开（Half-Open）：经过熔断窗口时间后，放行少量探测请求，判断服务是否恢复。
关键指标：熔断窗口（窗口时长）、失败阈值（次数或比例）、半开探测数。
1.1.2 限流算法：令牌桶与漏桶对比
限流算法决定了请求被允许通过的速率。下表对比了两种主流算法：
| 对比维度 | 令牌桶（Token Bucket） | 漏桶（Leaky Bucket） |
|---|---|---|
| 核心思想 | 以恒定速率生成令牌，请求需获取令牌才能通过 | 请求以固定速率流出，超出桶容量的请求被丢弃 |
| 突发处理 | 允许一定程度的突发（桶内可累积令牌） | 严格平滑，不允许突发 |
| 实现复杂度 | 中等，需维护令牌生成与消费 | 较低，队列+定时器即可 |
| 适用场景 | 允许短时突发的业务（如秒杀、API调用） | 流量必须绝对平滑的场景（如数据库写入） |
| Redis实现 | 常用Lua脚本+有序集合或String | 可用List+定时任务模拟 |
选型建议：本课程选择令牌桶作为核心算法，因为它更贴合互联网业务“允许突发、控制平均速率”的需求，且Redis实现灵活高效。
1.1.3 Redis在限流中的角色
Redis凭借其单线程模型、原子操作和丰富的数据结构，成为分布式限流的事实标准。在令牌桶场景中，Redis承担以下职责：
- 令牌存储：使用String或Hash存储当前令牌数、上次刷新时间。
- 原子扣减：通过Lua脚本保证“获取令牌”操作的原子性。
- 分布式共享：所有服务实例共享同一个Redis实例，实现全局限流。
- 熔断窗口：利用Redis的TTL或ZSet实现滑动窗口统计。
1.1.4 熔断窗口与令牌桶的协同
熔断窗口与令牌桶并非独立工作，而是形成双层防护：
- 第一层：令牌桶限流 — 控制入口QPS，防止流量洪峰冲垮系统。
- 第二层：熔断窗口 — 监控调用失败率，当下游异常时快速熔断。
- 协同点：熔断打开期间，令牌桶依然可以拒绝请求，但熔断半开时需放行少量探测请求，此时令牌桶需配合放行。
常见误区：限流不能替代熔断，熔断不能替代限流。限流是主动防御，熔断是被动保护。两者结合才能构建高可用的分布式系统。
1.1.5 课程实战路线
本课程将从零搭建一个基于Redis的熔断窗口+令牌桶限流系统，涵盖以下核心模块：
- Redis令牌桶实现：Lua脚本原子操作、令牌预取与补偿。
- 滑动窗口熔断：基于Redis ZSet的滑动窗口统计与状态切换。
- Spring Boot集成：自定义注解+AOP实现声明式限流与熔断。
- 压测与调优：JMeter压测、Redis性能优化、参数调优。
前置知识：熟悉Java基础、Spring Boot基础、Redis基本操作（String、ZSet、Lua脚本）。无需分布式系统经验，课程会从原理讲起。