企业官网建设流程全解析

1. 面试官到底在考什么：这道题不是单纯考算法，而是考工程权衡

简历上写了 Redis，面试官十有八九会追问一句：聊聊你的 Redis 限流实现方案。我听过太多次“我用 Redis 做过限流”的开场，接下来要么卡在固定窗口的边界问题上，要么根本说不清为什么自己的脚本在并发下不会出错。这题表面看是限流算法，实际上考的是你对 Redis 单线程模型、原子性、内存成本和生产容灾的理解到了哪一层。

限流本身是后端高并发绕不开的手段，计数器、滑动窗口、漏桶、令牌桶各有各的适用面。在 Redis 里怎么把这些算法落成可执行的脚本、怎么保证并发下不出竞态、Redis 挂了业务侧怎么办，才是面试官真正想听的东西。下面我会以面试问答的视角，把实现代码、核心原理和易错点完整过一遍，基础薄一点的读者也能顺着理解。

1.1 表面考限流，实际在验证三件事

很多候选人准备这道题时，习惯把精力放在背限流算法定义上：固定窗口是什么、滑动窗口怎么划、令牌桶怎么补充令牌。这些概念当然要懂，但面试官看到太多“背得滚瓜烂熟、一问生产细节就沉默”的候选人。放在 Redis 这个前提下面试，题目真正想验证的是三件事。

第一，你对限流算法本身的理解是否停留在概念层。能不能说出每个算法适用的流量特征，更重要的是能不能说出它的边界：固定窗口为什么有“窗口边界突发”问题、滑动窗口如何解决、令牌桶为什么允许突发、漏桶为什么不允许。这些边界直接决定一个算法在真实流量下的表现，不是背定义能糊弄过去的。

第二，你对 Redis 作为“限流组件”的特质有没有感觉。限流本质是“在共享状态上做判断和修改”，Redis 单线程执行命令，天生适合充当一个共享计数器；但它也有自己的约束：多条命令之间可能出现竞态、内存会随 key 增长、Lua 脚本执行耗时过长会阻塞整个 Redis 进程。这些问题不会出现在算法伪代码里，却会在生产环境真实发生。

第三，你是否有工程权衡意识。生产限流不是“选个算法写个脚本”就结束：限流阈值怎么定、Redis 不可用时放行还是拒绝、多实例之间状态是否一致、并发峰值下脚本是否会拖垮 Redis。面试官通过追问这些点，能快速判断你是只写过 Demo，还是真正压测过并看过线上监控。

1.2 三分钟的回答和三十分钟的回答差在哪

我通常把合格回答分成三个层次。第一层是“知道有哪些方案”，能说出固定窗口、滑动窗口、令牌桶这些名词，能说出大概命令，基础面可以过。第二层是“能写对脚本”，会用 Lua 把判断和计数合并成一次原子调用，能解释清楚为什么要绕开 GET 再 SET 的竞态，这一层可以进入深度讨论。第三层是“能讲清楚取舍”，能把每个方案的内存成本、精确度、对突发的容忍度都摆在台面上，结合业务场景给结论，甚至主动提到限流器自身的高可用问题。

为了更直观，我把它拆成一张对照表。面试官听到第一层，大概率会继续往第二层追问；听到第二层，可能会抛分布式问题；听到第三层，基本就变成聊天式讨论了，这种状态对候选人是最有利的。

我的个人判断是：面试官问 Redis 限流，并不是要求你把每种方案的源码都默写出来，而是想找一个能在真实系统里做出合理限流设计的人。所以回答时的顺序和执行侧重点，比“记没记全”更重要。

2. 四种 Redis 限流实现的具体拆解：原理、脚本与适用边界

2.1 固定窗口计数器：最经典的 INCR + EXPIRE

先看最基础的实现。以“每分钟最多 100 次”为例，常见做法是为每个用户或每个接口维护一个 key，比如rate:user:1024，每次请求执行 INCR，如果增长后的值超过阈值就拒绝，否则放行，同时在 key 不存在时设置过期时间。

逻辑大致是：

• 计算限流 key，通常是“业务维度 + 时间窗口单位”；
• 执行 INCR(key)；
• 如果返回值为 1，说明 key 是新建的，再设置 EXPIRE(key, 60)；
• 如果 INCR 的结果超过 limit，拒绝请求，否则放行。

这段逻辑可以直接写在应用层，用 RedisTemplate 依次调 INCR 和 EXPIRE；也可以包一个 Lua 脚本一次性提交。我建议哪怕这么简单的逻辑也走 Lua，原因放到第三节专门讲。先看脚本：

-- KEYS[1]: 限流 key -- ARGV[1]: 窗口内最大请求数 -- ARGV[2]: 窗口时间（秒） local count = redis.call('INCR', KEYS[1]) if count == 1 then redis.call('EXPIRE', KEYS[1], ARGV[2]) end if count > tonumber(ARGV[1]) then return 0 end return 1

这个实现最大的优点是简单：key 数量少，内存开销几乎可以忽略，单位时间内的请求量基本可控。但它有一个面试里几乎必被点名的缺陷——窗口边界突发：相邻两个窗口的交界处，比如 09:00:59 的请求被放行，09:01:01 的请求因为落在新 key 里又被放行，流量可能瞬时冲破限流阈值近两倍。对很多内部接口来说可以接受，但对严格要求平滑限流的场景不适用。

另外注意，固定窗口如果完全不做脚本封装，在新建 key 的瞬间还会有并发问题：多个请求同时 INCR，发现返回结果都是 1，然后各自设置 EXPIRE，可能把过期时间刷新到窗口之后很久。换成 Lua 之后，INCR 和 EXPIRE 合并为一个原子操作，这个隐患自然消失。

2.2 滑动窗口：用 ZSET 把时间边界磨平

为了解决固定窗口的边界问题，更自然的思路是：不按分钟或秒硬切窗口，而是统计“当前时间往前推一个窗口长度”内到底有多少请求。Redis 里做这件事最直观的数据结构是 ZSET：成员是每次请求的唯一标识，分值 score 是请求到达的时间戳，窗口范围就是分数区间。

每次请求到达时：

• 先清理窗口外的旧记录：ZREMRANGEBYSCORE key 0 (now - window)；
• 统计当前窗口内数量：ZCARD key；
• 判断是否超过阈值，没超过则 ZADD key now uniqueMember。

清理、统计、添加这三步如果分多条命令执行，中间会插入并发请求，造成统计不准，所以必须用 Lua。下面是我在项目里用过的一版脚本：

-- KEYS[1]: 限流 key -- ARGV[1]: 窗口长度（毫秒） -- ARGV[2]: 窗口内最大请求数 -- ARGV[3]: 当前时间戳（毫秒） -- ARGV[4]: 本次请求唯一标识 local key = KEYS[1] local window = tonumber(ARGV[1]) local limit = tonumber(ARGV[2]) local now = tonumber(ARGV[3]) local member = ARGV[4] redis.call('ZREMRANGEBYSCORE', key, 0, now - window) local current = redis.call('ZCARD', key) if current >= limit then return 0 end redis.call('ZADD', key, now, member) redis.call('PEXPIRE', key, window * 2) return 1

写这个脚本有几个细节要留心。第一，member 必须唯一，直接用时间戳容易重复，一般拼一个随机串由客户端生成传入。第二，PEXPIRE 的过期时间我习惯设为窗口的两倍，保证清理逻辑和统计不会因为 key 提前消失而漏算。第三，每次请求都往 ZSET 里写一个 member，所以这个方案的内存成本明显更高：一个 key 里的 member 数量等于窗口内请求总量，高并发下 Redis 内存和网络开销都要算清楚。

滑动窗口的优势是精确，几乎消除了边界突发；劣势是成本高。真实系统里还有一种优化思路——把窗口切成若干个小桶，每个桶只存一个计数，而不存每次请求的明细，精度降低一些，内存能省一大截。面试聊到这里，你可以主动提“时间桶”优化，通常会让面试官觉得你真的算过性能账。

2.3 漏桶和令牌桶：从“限数量”进阶到“限速率”

前面两种方案都在统计“窗口内请求总数”，属于计数型限流。还有一类方案希望限制请求的速率，而不只是总数量，于是有了漏桶和令牌桶。这两个算法并不依赖 Redis 的特殊魔法，Redis 只是充当状态存储，核心是“增量状态计算”。

漏桶的思路是把请求先放进桶里，桶底按固定速率漏水，请求以恒定速率被处理，超过桶容量的请求直接丢弃。Redis 里可以用一个 LIST 模拟桶：LLEN 判断桶是否已满，不满就 LPUSH 请求进桶，后台消费者按固定速率 RPOP。它的特点是绝对匀速，即使上游突发，下游看到的依然是恒定速率；缺点也很明显，流量被压平后，实时性高的请求可能等待，超时风险上升。

令牌桶在工程上更常见，因为它既限速率，又允许一定的短时突发。算法维护两个状态：当前令牌数和上次补充时间。每次请求到达时，先根据“距离上次补充的时间 × 每秒补充速率”算出新增令牌，加上现有令牌后不能超过桶容量，然后判断是否有至少一个令牌可取。在 Redis 里读写两个状态必须要用 Lua，脚本如下：

-- KEYS[1]: 令牌数 key -- KEYS[2]: 上次补充时间 key -- ARGV[1]: 每秒补充速率 -- ARGV[2]: 桶容量 -- ARGV[3]: 当前时间戳（毫秒） local tokensKey = KEYS[1] local tsKey = KEYS[2] local rate = tonumber(ARGV[1]) local capacity = tonumber(ARGV[2]) local now = tonumber(ARGV[3]) local tokens = tonumber(redis.call('GET', tokensKey) or capacity) local lastRefill = tonumber(redis.call('GET', tsKey) or now) local elapsed = math.max(0, now - lastRefill) local add = math.floor(elapsed * rate / 1000) tokens = math.min(capacity, tokens + add) redis.call('SET', tsKey, now) if tokens >= 1 then tokens = tokens - 1 redis.call('SET', tokensKey, tokens) return 1 end redis.call('SET', tokensKey, tokens) return 0

这个脚本的关键是“惰性补充”：不是放一个定时任务给所有 key 批量补令牌，而是每次请求进来时按时间差算应补的量，高并发下不会产生额外的 Redis 后台任务。要注意 rate 的精度换算，如果速率很小，elapsed * rate / 1000可能长期小于 1，这时可以把 rate 定义为每毫秒补充多少令牌，或使用浮点运算后在应用层做取整控制。这个精度问题调试起来很隐蔽，我踩过，先标个记号。

面试里聊令牌桶和漏桶时，最怕把算法描述和 Redis 实现混在一起。我建议先用算法本体的语言讲清“补令牌、扣令牌、突发、匀速”这些抽象概念，再切到 Redis 的 key 设计和 Lua 脚本，面试官更容易跟上思路。

2.4 四个方案放在同一张表里比

归纳一下四种方案在工程维度上的差异：

这张表我在面试里几乎必用，因为它能快速展示你不仅记得算法，还知道怎么选。选型逻辑一般是：完全不允许边界突刺就选滑动窗口；下游要求匀速处理就选漏桶；既要长期可控又要允许突发就选令牌桶；只是粗略挡一下峰值，固定窗口加 Lua 就够。

3. 生产必踩的原子性之争：为什么多命令方案在并发下会翻车

3.1 还原一段真实竞态现场

我在带新人时常问一个问题：你在应用层先 INCR 再 EXPIRE 有什么问题？多数人第一反应是“没有，Redis 命令单线程执行，没有并发”。这句话对了一半：Redis 确实是一个命令一个命令串行执行的，但“INCR 和 EXPIRE 是两条命令”，中间可以插入其他客户端的任何命令，这就是竞态窗口。

拿固定窗口的经典写法来说，请求 A 执行 INCR 得到 1，请求 B 执行 INCR 得到 2，计数本身是串行的。可如果 A 在 INCR 之后、EXPIRE 之前进程崩溃，key 永远不会被设置过期时间，这个 key 就变成“永久不过期”的限流器，时间一长内存泄漏是小事，关键是计数永远不为零，所有请求被永久拒绝。

更隐蔽的是“先 GET 再 SET”这种自实现计数器。有人嫌 INCR 不够可控，先读当前值、判断、再 SET 新值，于是写出 GET → 判断 → SET 三段代码。单客户端看起来没问题，高并发下两个请求同时读到同一个旧值，各自加 1 后 SET，最终只加 1 而不是 2。在限流场景下，这个错误的直接表现是“限流失效”，大量请求绕过限制涌向业务系统，非常危险。

3.2 Lua 脚本为什么能解决：从“多条命令”变成“一个原子操作”

Redis 从较早期版本开始支持执行 Lua 脚本。调用 EVAL 或 EVALSHA 时，整个脚本在 Redis 进程中作为一个整体运行，由于 Redis 本身是单线程事件循环，脚本执行期间不会有其他客户端的命令插入，所以脚本里的所有读改写天然串行，正好消灭了上一节提到的竞态窗口。

这也是我坚持限流逻辑必须走 Lua 的核心原因。对比普通写法：RedisTemplate 依次执行三条命令，应用层要面对网络断开、部分成功、并发交错各种问题；脚本方式只需要一次网络往返，Redis 内部确保脚本整体执行。额外的好处是减少 RTT，高并发下每个请求省两三次往返，效果很明显。

不过要严谨一点：Lua 脚本的原子性不等于数据库事务。如果脚本中间执行了会失败的命令，已经完成的写操作不会自动回滚。限流脚本结构简单，一般不会触发这种情况，但回答面试官时不要说成“Lua 就是事务”，更准确的说法是“脚本在 Redis 单线程模型中被原子地执行”。

3.3 超过单实例后：多节点、时钟和一致性的新考题

面试推进到分布式，话题就从原子性转向一致性。第一个问题，多个业务实例共享同一个 Redis key 时，限流逻辑天然是全局的；但如果每个实例各自用独立的 key 限流，那么 10 个实例并发时总流量可能放大 10 倍。所以设计上通常会收敛到“同一业务维度共享 key”，这是分布式限流的基本前提。

第二个问题是时钟。滑动窗口脚本里传入的是应用层生成的时间戳，如果业务机器和 Redis 机器之间时钟偏差几秒，窗口边界会出现明显误差；令牌桶的补充计算同样依赖时间差。生产上一般要做时钟同步，只要精度要求不是毫秒级，几秒误差可以接受。关键是面试里要主动提这一点，因为很多人根本意识不到时间戳是从客户端传进去的。

第三个问题是 Redis 本身的高可用。主从切换、故障恢复都可能导致限流 key 丢失或短暂不可用，限流状态清零后流量会短暂涌向业务系统。限流器的设计原则通常是“宁可误放，不可误杀”，这和缓存刚好相反。回答完分布式问题后，主动补一句“Redis 不可用时我会选择放行而不是拒绝所有请求”，往往能直接命中面试官心中的生产意识加分项。

4. 从能跑到能上线：一个可落地的 Spring Boot 限流封装

4.1 为什么选择注解 + AOP + Lua，而不是在业务方法里写模板代码

面试聊到原理清楚已经不错，但真正能拉开深度的是能不能落地。我的习惯是把限流做成一个注解，配合 Spring AOP 切面执行 Lua 脚本，这样业务代码里只需要一行注解，不侵入核心逻辑。

选择 AOP 而不是拦截器或过滤器，主要是因为限流通常要精确到某个用户、某个接口的组合维度，注解能直接把参数传给切面，比如在 key 里拼上 userId 做用户维度限流。过滤器也能做，但粒度越细，字符串解析和 if/else 就越多。AOP 在这个场景下语义更干净，配合 RedisTemplate 执行 Lua 脚本，业务代码完全不感知 Redis 的存在，限流策略变化时也不需要改业务方法。

为什么不直接用现成的限流组件？答案很现实：面试场景里你会写原因为加分，工程上则是因为现成组件往往绑定特定框架版本，或者封装比较重，排查问题不如自己这一二十行 Lua 透明。自己维护脚本不是重复造轮子，而是保证日后看一个脚本文件就能完全掌握限流行为。

4.2 核心实现：注解、切面与 Lua 脚本

先定义注解：

@Target(ElementType.METHOD) @Retention(RetentionPolicy.RUNTIME) public @interface RateLimit { String key(); // 限流维度，例如 "user:create" long window(); // 窗口毫秒数 long limit(); // 窗口内最大请求数 }

然后是 Lua 脚本，我直接用滑动窗口版本。简单起见，脚本先清理过期记录，再判断窗口内数量：

redis.call('ZREMRANGEBYSCORE', KEYS[1], 0, tonumber(ARGV[1]) - tonumber(ARGV[2])) local current = redis.call('ZCARD', KEYS[1]) if current >= tonumber(ARGV[3]) then return 0 end redis.call('ZADD', KEYS[1], tonumber(ARGV[1]), ARGV[4]) redis.call('PEXPIRE', KEYS[1], tonumber(ARGV[2]) * 2) return 1

切面代码大致这样：

@Aspect @Component public class RateLimitAspect { private static final DefaultRedisScript<Long> RATE_LIMIT_SCRIPT; static { RATE_LIMIT_SCRIPT = new DefaultRedisScript<>(); RATE_LIMIT_SCRIPT.setScriptText( "redis.call('ZREMRANGEBYSCORE', KEYS[1], 0, tonumber(ARGV[1]) - tonumber(ARGV[2])) " + "local current = redis.call('ZCARD', KEYS[1]) " + "if current >= tonumber(ARGV[3]) then return 0 end " + "redis.call('ZADD', KEYS[1], tonumber(ARGV[1]), ARGV[4]) " + "redis.call('PEXPIRE', KEYS[1], tonumber(ARGV[2]) * 2) " + "return 1"); RATE_LIMIT_SCRIPT.setResultType(Long.class); } @Around("@annotation(rateLimit)") public Object around(ProceedingJoinPoint joinPoint, RateLimit rateLimit) throws Throwable { String key = buildKey(rateLimit.key()); long now = System.currentTimeMillis(); String member = UUID.randomUUID().toString(); Long allowed = redisTemplate.execute( RATE_LIMIT_SCRIPT, Collections.singletonList(key), String.valueOf(now), String.valueOf(rateLimit.window()), String.valueOf(rateLimit.limit()), member ); if (allowed == null || allowed == 0L) { throw new RateLimitExceededException("请求过于频繁"); } return joinPoint.proceed(); } }

这里有三个容易踩的编码坑。第一个，DefaultRedisScript 只传一个 KEYS 时，后面传入的所有参数都是 ARGV，不要再往里塞 key。第二个，时间单位要统一，注解 window 用毫秒，换算时不要和秒混淆。第三个，ZADD 的 member 必须每次都不一样，否则同一毫秒两个请求在 ZSET 里会变成同一个成员，直接少计一次。这几个问题我在调试中都遇到过，写出来提醒一下。

4.3 上线前必须回答的三个工程问题

脚本能跑只是第一步，上线前我会再问自己三个问题。

一是限流阈值到底怎么定。有人拍脑袋定“100 次/分钟”，压测发现峰值才到 80 就开始误伤，这个阈值没有意义。我的做法是先压测拿到服务的真实容量，比如单实例稳定支撑 200 QPS，再留 30% 冗余，把最终阈值写进配置中心。限流阈值应该来自容量评估而不是直觉，这句话在面试里也很有分量。

二是 Redis 不可用怎么办。限流器本身不能成为新的单点故障。我给 Redis 限流操作设置单独的超时时间，比如连接超时 200ms、命令超时 100ms；执行 Lua 脚本抛出异常时，根据业务选择“快速失败”还是“放行”。对核心交易链路，我倾向快速失败保护主流程；对不重要的埋点接口，则选择放行避免影响主链路。一定要把这个决策讲清楚，而不是含糊说“Redis 挂了就挂了”。

三是不要忽视连接池和线程池。限流请求如果都挤在同一个 Redis 连接池，高并发下连接池本身的等待队列会变成新瓶颈。我会给限流器配置独立的连接池，不让它和业务缓存混用，避免某个大流量业务把连接池占满连累全局。这个细节听着很小，但上线后常常决定限流器本身稳不稳。

5. 面试官追问九连：把它们接住，这场面试就赢了

5.1 追问：限流、熔断、降级是一回事吗？

如果只答“限流是限流，熔断是熔断”就没有意思。我通常从目标来解释：限流保护的是自己或下游不被超出预期的流量击穿，思考维度是速率；熔断保护的是“调用一个已经不健康的依赖”时不再浪费资源，思考维度是失败状态；降级是“系统容量不足时主动放弃部分功能或降低服务质量”，思考维度是优先级。

三者经常联动：先限流挡住冲进来的流量，再熔断阻断对故障依赖的后续调用，最后对非核心功能降级。举个例子，某个外部接口超时率飙升，限流器先把对这个接口的流量限制住，熔断器检测到错误率超过阈值后打开，请求直接走本地兜底逻辑返回降级数据。能把这条链路讲清楚，比单纯背定义强很多。

5.2 追问：为什么不用网关自带的限流，还要在应用层做？

网关限流更适合全局入口层的统一防护，比如限制某个 IP、某个服务的总吞吐；应用层限流适合更细粒度的业务维度，比如“某个用户创建订单不能超过 N 次”。两者不是替代关系，而是分层关系。

我在实际系统里通常两层都做：网关做粗粒度入口限流，拦住大流量冲击和异常爬虫；应用层做业务维度的精细限流，比如防刷单、防重复提交。面试官若继续追问“在网关层怎么限流”，你可以说网关基于 Redis 的限流算法和前面讲的是一致的，只是部署位置不同；如果说“应用层多余”，你就举防刷单例子证明两层关注点不同。

5.3 追问：ZSET 滑动窗口在高并发下内存扛得住吗？

这是我最希望候选人多想一步的问题。一个 ZSET key 的 member 数量等于窗口内请求总量。假设一个接口 1000 QPS，滑动窗口 1 分钟，key 里大约有 6 万个 member，每个 member 包括分值和唯一字符串，粗略估算几十 MB 级别。单接口已经偏重，如果接口多、再按用户维度拆分，内存会非常夸张。

所以真实场景我不会对每个用户都用 ZSET 做一分钟滑动窗口。常见优化是“小桶”方案：把一分钟拆成 60 个一秒桶，每个桶只存一个计数，比如用 HASH 存储，内存从几十万 member 降到几十个计数，代价是精度从瞬时变成秒级。面试时主动讲这个取舍，说明你算过账，印象分很高。

5.4 追问：现成的限流算法实现你没用过吗？

这个问题往往是想确认你有没有停留在纸面。如果没实际用过，我会诚实说“自己封装过一套小脚本，原理和现成实现一致”，然后从三个点对比：成熟实现通常要考虑脚本注册、原子性、多语言客户端兼容，并且内置多种算法；自研实现的好处是轻量、可控、排障路径短，坏处是要自己维护边界。

其实很多开源限流组件的底层思路就是我前面写的 Lua 脚本，可能多了一层封装或更高效的数据结构。面试里完全不用贬低自研或盲目吹捧现成组件，把两边优劣讲清楚，面试官反而觉得你见得多、也认得清。

5.5 追问：如果限流器所在的 Redis 是集群模式，你的脚本还能跑吗？

Redis Cluster 模式下，一个 Lua 脚本涉及的多个 key 必须落在同一个 slot，否则会报错。解决办法有两个：一是脚本只操作一个 key，把多个状态放进同一个 HASH；二是使用 hash tag，比如rate:{userId}:tokens、rate:{userId}:ts，让大括号内的部分参与哈希分片。

更深的体会是：限流脚本尽量设计成单 key 可完成。如果一个脚本需要读两个 key，数据迁移和重新分片都会让脚本稳定性变差。我现在的令牌桶实现会把令牌数和时间戳放进同一个 HASH，而不是两个独立 key，这样集群模式下的兼容性最好。这个回答能直接闭环整个分布式问题。

5.6 追问：限流被触发后，客户端体验怎么设计？

聊到这里基本进入落地层面。先说返回结果：HTTP 场景通常返回 429 Too Many Requests，并在响应头加 Retry-After 告诉客户端多久后再试；同时可以在限流 key 上记录剩余可请求数和重置时间，方便客户端做退避。

然后是重试策略。客户端无脑重试会把限流器变成放大器，正确做法是指数退避加随机抖动。服务端还可以给被限流的请求一个降级响应体，而不是直接抛 500，方便监控告警把限流和真实错误区分开。这个细节虽然小，但能体现你考虑过“限流后的闭环”，而不只是挡住流量。

5.7 追问：固定窗口的双倍突发，在什么场景下又其实没关系？

这个反问很能区分层级。我经历过一个真实场景：后台报表接口，凌晨批量任务集中拉数据，偶尔冲破限流阈值没有大影响，但绝对不能把服务压崩。这种场景用固定窗口就够了，简单、轻量、几乎不增加 Redis 压力。

反过来，面向用户的抢购接口就不能容忍双倍突发，因为缓存系统已经扛着很高流量，任何超出预期的放大都可能引发雪崩。我的结论是：算法没有绝对优劣，取决于你保护的对象能容忍什么样的流量形状。面试里主动给出这个判断框架，通常能获得不错的反馈。

5.8 追问：有没有遇到过限流器引起的生产事故？

这是压力题，也可能是节奏变松的信号。我会讲一个自己遇到过的细节：早期令牌桶脚本用浮点计算令牌数，Lua 里的浮点取整和预期有偏差，导致速率在高并发下偏差接近 10%。最后我把时间差换算前置到应用层，脚本里只做整数运算，问题才稳定下来。

发生事故不可怕，重要的是描述你怎么发现、怎么定位、怎么根治。面试官要看到的是完整排查路径：先看监控发现限流阈值异常，再结合日志猜测是脚本计算问题，最后简化脚本做压测复现。能完整讲出这个链条的人，通常真的有线上经验。

5.9 追问：如果 Redis 和业务不在同一个机房，限流时延会变成瓶颈吗？

跨机房访问 Redis 的往返时延通常有几毫秒到几十毫秒，高并发下把所有请求都打到远程 Redis 做限流，时延本身就会成为瓶颈。我的对策是分层限流：网关层先做本地内存级别的粗限流，比如每个实例每秒最多处理多少请求，先挡住容易识别的大流量；真正到业务层的精细限流再走 Redis。

本地限流牺牲了全局统计的精确性，但因为容量评估时已经留了冗余，实例级限额之和略高于全局限额是可以接受的。面试官听到你能区分本地限流和分布式限流，并主动做取舍，说明你不是只会套脚本。

6. 我的选型习惯和一套可以直接用的回答话术

6.1 不同业务场景我默认怎么选

把实践收拢成几条习惯：保护数据库、内部轮询任务这类场景，固定窗口加 Lua 就足够，不要用 ZSET 白白消耗内存；对外用户接口防刷，用滑动窗口，按用户维度拆分 key，同时评估 key 的规模；对接下游需要匀速处理的场景，用令牌桶甚至漏桶，避免突发把对端拒掉；需要精确到每个用户的可视化配额管理时，我再考虑用成熟的限流库配合配置中心。

这里有个反向经验：不要一上来就选最复杂的方案。限流器本身越复杂，出问题的面就越广，我在生产里见过因为精细限流脚本 bug 导致接口不可用的情况。越简单的脚本越容易 review，越容易压测。先用粗粒度方案把系统保护住，再根据监控逐步细化，才是最稳的路径。

6.2 面试时推荐按这条主线组织答案

如果只表达一次，我会按“目的 → 算法 → 脚本 → 生产问题 → 选型”的顺序说。开场直接给结论：“限流本质是在 Redis 里维护一个共享状态，核心难点是判断和修改必须原子，所以生产实现离不开 Lua 脚本。” 接着讲固定窗口和它的边界问题，顺势引出滑动窗口；再讲令牌桶与漏桶各自解决什么新问题；最后回到原子性、分布式和降级策略。

这套表达通常能占用十分钟左右，面试官听下来会觉得你有方法论而不是在背题。特别要注意不要堆术语，每提到一个方案就立刻接一句“它解决什么问题”，因为名词轰炸最招人烦。

6.3 一个小细节：拒绝后的状态码和响应头值得背下来

技术讲完，我会顺手给面试官一个业务闭环：被限流时返回 429，带 Retry-After 头，客户端和网关都能识别；内部调用则抛限流异常并记录指标，监控告警单独配置一个“限流次数”指标，避免和真实错误混在一起。这些小细节在面试末尾往往成为加分点，因为它证明你不只是写了个判断，而是想清楚了“限流之后怎么办”。

我自己在面试新人时，最愿意听到的回答往往不是多炫的技术，而是清楚地说出“我选这个方案是因为它匹配当前场景，它的缺点我用什么手段接住了”。Redis 限流这个话题尤其如此。与其把一堆方案的名字都背下来，不如把一套滑动窗口讲透，再把原子性和降级策略讲明白，后者才是真正能落到系统里的能力。