一杯咖啡的时间，聊聊技术与成长
Sentinel 实战：注解一贴，熔断上线
手写熔断器搞懂了原理，生产要的是注解一贴就能用、规则不发版就能改、监控不用自己搭——Sentinel 用 @SentinelResource 一个注解接住拒绝与异常，用一条 DegradeRule 把上篇的参数表翻译成配置，再用控制台把跳闸变成看得见的事。轻量派 Resilience4j 是另一个答案。
熔断判定：错误率、慢调用与统计窗口
三态骨架搭好了，判定标准还没定——什么时候该跳闸？错误率与慢调用比例是两根体温计，最小请求数防止小样本误诊，滑动统计窗口让指标看「最近」而非「远古」。判得准，断路器是保险丝；判不准，它自己就是故障源。
熔断器：三态模型的断路哲学
下游病了还持续叩门，线程一样被拖死——限流管进来的流量，熔断管出去的调用。Closed、Open、Half-Open 三个状态构成一台自动断路器：病了快断、断了快探、好了快合，家里的空气开关早就想明白了这件事。
限流算法对比与选型：一张表定案
固定窗口、滑动窗口、漏桶、令牌桶，单机与分布式两组旋钮——限流篇的算法备齐了，本篇一张总表定选型，再用 503 咖啡馆的完整方案演示「混合使用才是常态」，顺带清算四个常见误区。
多级限流：三层防线的额度分配
网关、应用、数据库各一道闸，但阈值不是随手拍——外层要略宽于内层，拒绝的对象各有分工：网关挡恶意，应用管配额，数据库做保险丝。额度分配错一层，整条防线就互相打架。
网关层限流：Nginx 与 Spring Cloud Gateway
闸门装在入口最划算：流量还没进业务就被拦下，省下的是整条链路的资源。Nginx 的漏桶匀速放行，Spring Cloud Gateway 的 Redis 令牌桶按维度发牌——但网关看不见业务上下文，粗与细要分层配合。
分布式限流：Redis 加 Lua 的原子计数
计数器集中到 Redis，「读-判断-写」的竞态跟着一起搬了过去——老坑新填，还得 Lua。本篇把固定窗口、令牌桶、滑动窗口三个算法的 Redis 版一次讲透，顺带解决时间源统一与 Redis 故障时的放行策略。
单机限流落地：注解、AOP 与那些工程细节
算法备齐只是第一步，接进业务代码才有战斗力。手写 if 侵入太重，注解加切面才是工程正解：一个 @RateLimit 走天下，SpEL 动态拼 key，限流触发转友好提示，触发率指标上监控——四件套缺一不可。
漏桶与令牌桶：匀速与突发的两种哲学
滑动窗口数的是历史，漏桶与令牌桶管的是节奏。漏桶把流量剁成绝对匀速的水滴，令牌桶匀速发牌、允许攒额度打突发——一个做整形，一个做控制，Nginx 与 Guava 各站一队。