1、你概述一下这个判题接口的业务特点和你设置限流规则的考量。比如，你设置的是 QPS 还是并发数？限流阈值是多少？是基于用户、IP 还是整个服务的全局限流？
这个判题接口是我们在线编程平台的核心接口，特点是计算密集型和资源消耗大。每次提交的代码都需要在沙盒环境中编译、运行并对比输出结果，对 CPU 和内存的压力很大。基于这个特点，我的限流规则主要考虑以下几点：
- 类型：我设置的是 QPS（每秒查询率） 限流。因为判题服务的瓶颈在于单位时间内能处理的任务数量，而不是并发连接数。
- 层级：我采用了 两级限流 策略。
2.1 全局级：对整个判题服务集群设置一个总 QPS 上限，例如 1000 QPS。这是为了保护后端判题机和数据库等共享资源不被突发流量冲垮。
2.2 用户级：对每个用户 ID 设置一个个人 QPS 上限，例如 5 QPS。这是为了防止单个用户（无论是恶意还是脚本错误）过度占用资源，保证服务公平性。 - 阈值：全局阈值是通过压测和监控后端服务的负载能力得出的；用户级阈值则是根据业务场景（正常用户不可能每秒提交5次以上）设定的。
2、为什么你选择了“令牌桶+Redis + Lua”这个技术组合？ 请重点说明，在判题这个具体场景下，这个方案解决了哪些其他方案解决不了的核心问题？
- 中心化状态存储：Redis 作为所有判题服务实例共享的存储，可以精确地维护一个全局统一的令牌桶状态，确保无论请求被路由到哪个实例，限流都是准确的。
- 业务灵活性：我们可以将任何业务标识（如用户ID、接口路径）作为 Redis Key 的一部分，轻松实现用户级、接口级等任意维度的精细限流。
- 性能与轻量：Redis 性能极高，且作为现有基础设施，无需引入新的重型组件。
3、你刚才提到了原子性，这是一个关键点。为什么必须使用 Lua 脚本？ 如果不用 Lua，而是用普通的 Redis 命令通过客户端逻辑计算或者是redisson，会带来什么问题？
如果不用 Lua 脚本，我们会面临 “竞态条件” 和 “性能损耗” 两个致命问题。客户端实现需要至少两次 Redis 往返（GET + SET）。在高并发下，网络延迟会成为巨大的性能瓶颈，并且加重 Redis 本身的连接负担。同时不需要额外引入其他的组件和依赖。
4、在实际运行中，你是如何处理各种异常情况的？如果 Redis 本身宕机或网络超时，你的限流服务会如何表现？ 是 fail-open 还是 fail-close？
- 这是一个非常重要的容错设计问题。我们的策略是 Fail-Open。
- 理由：这是一个典型的 “保全核心业务” 和 “降低影响面” 的权衡。
2.1 判题服务不可用是 P0 级别 的故障，直接影响用户核心体验。
2.2 限流是一个 保护性措施。如果因为保护层（限流）的故障导致核心业务（判题）被完全拒绝，那就本末倒置了。我们宁愿在保护层暂时失效时承担一些过载风险（这通常有其它底层基础设施如负载均衡器兜底），也不能让服务完全不可用。 - 补充措施：当然，Fail-Open 不是放任不管。我们会配备强大的监控：
实时监控 Redis 集群的健康状态。
当限流服务触发 Fail-Open 模式时，会触发 P1 级别告警，通知运维和开发人员立即介入处理。
同时，我们会在应用层和系统层设置一些基础的熔断降级策略，作为最后的防线。
5、那有没有考虑如果说有一个突然的特别大的流量，那么你的redis限流应该怎么去做
表现：
一、 当前方案在特大流量下的表现和瓶颈：
首先，我们需要正视当前方案在极端情况下的瓶颈：
1、Redis 成为性能瓶颈：所有判题服务的实例都会并发地对同一个或某几个 Redis Key 执行 Lua 脚本。Redis 是单线程处理命令的，这会导致：
1.1 命令队列堆积：大量的 EVAL 命令在 Redis 服务端排队，等待执行。
1.2 响应延迟激增：每个限流请求的响应时间（RT）变长，从毫秒级可能上升到秒级。
1.3 连接资源耗尽：应用端 Redis 连接池因等待响应而被占满，进而导致新的业务请求被阻塞或失败。
2、“惊群效应”：当令牌桶为空时，所有请求都会被拒绝。但每秒仍有海量请求涌入，持续冲击 Redis，试图获取令牌，直到流量洪峰过去。这是一种资源的浪费。
3、限流策略的“冷酷”性：令牌桶算法会严格按照规则拒绝超限的请求。对于突如其来的、可能是正常的业务高峰（例如热门比赛开场），这种直接拒绝的体验并不友好。
二、 我的防御性架构与优化策略
a) 前置削峰与异步化
- 请求队列：当用户点击“提交”后，服务会立即向一个 高吞吐量的消息队列（如 Kafka 或 RabbitMQ） 发送一个判题任务消息，然后立刻返回给用户“提交成功，正在排队判题”。
2)限流位置后移：限流组件不放在 HTTP 接口入口，而是放在 消息的消费者端（即从队列中取出任务进行处理的判题服务）。这样，HTTP 接口只负责快速接收和投递消息，抗冲击能力极强。真正的限流在消费者端，控制的是从队列中拉取任务的速度，从而保护了后端的判题资源。
b)分层与分片限流
针对您提到的 Redis 热 Key 问题，我会采用分片策略： - 全局限流分片：不使用单一的 rate_limit:global，而是使用多个，例如 rate_limit:global_shard_0 到 rate_limit:global_shard_9。每次限流时，使用一个随机数或者对用户ID取模，来决定操作哪一个分片。这将一个热 Key 的压力分散到了 10 个 Key 上。
- 多级限流：正如我之前提到的，用户级限流和全局级限流是并存的。用户级限流首先挡掉大部分异常用户，减轻对全局限流 Key 的冲击。
c) 本地缓存 + 中心校验（二级缓存策略）
为了进一步减轻 Redis 的压力，我可以在应用层引入一个短时间的本地缓存。 - 当某个用户被限流后，我在本地内存（如 Guava Cache）中记录该用户 ID 和一个短暂的过期时间（例如 1 秒）。
- 在接下来的 1 秒内，该用户的所有请求，直接在应用层就被拒绝，无需访问 Redis。
- 这个策略能极大地过滤掉高频重复的请求，特别适用于防止恶意刷接口。它是一种用内存换 Redis 资源和网络开销的权衡。