Redis请求频率限制实现方案，如何用Redis控制接口访问频率，防止恶意请求

最简单的实现是使用Redis的INCR命令，为每个用户和接口设置一个键，记录单位时间内的请求次数，超过设定阈值就拒绝访问。

使用Redis的INCR命令实现基础计数

核心思路很简单：当用户访问某个接口时，我们生成一个唯一的Redis键，比如'rate_limit:user123:/api/data'，然后对这个键执行INCR操作，将值加1。如果是第一次访问，Redis会自动创建这个键并设置值为1。同时，我们需要给这个键设置一个过期时间，比如60秒，这样60秒后这个计数就会自动清除。在INCR之前或之后，我们检查这个键的值，如果超过了我们设定的限制，比如一分钟最多10次，那么就直接返回错误，告诉用户请求太频繁了。这种方法直接明了，能快速实现基本的频率控制。

利用EXPIRE确保时间窗口重置

设置过期时间（EXPIRE）是关键一步，它保证了我们的计数不会无限增长，并且自动定义了“单位时间”这个概念。一个常见的技巧是，在第一次设置键的时候（即INCR返回值是1的时候），立刻给这个键设置过期时间。这样可以确保时间窗口准确。如果后续的请求在过期时间之内，计数继续增加；一旦过期，键被删除，下次请求又从1开始计数，这样就实现了一个滑动的时间窗口控制。

更精细化的控制：令牌桶算法思路

单纯计数有时不够灵活。我们可以用Redis模拟“令牌桶”算法。想象一个桶，里面放着一些令牌，每来一个请求就消耗一个令牌，同时系统会以固定速率往桶里添加新令牌。用Redis实现时，可以设置一个键存储当前令牌数，另一个键存储最后一次补充令牌的时间。每次请求时，先计算从上一次到现在应该补充多少新令牌（但不能超过桶的容量），然后检查当前令牌是否大于0，如果是则减少一个令牌并允许请求，否则拒绝。这种方法允许短时间的突发流量（只要桶里有令牌），而不仅仅是严格的平均速率限制。

在代码中的应用示例

以Python为例，使用redis-py库。假设我们要限制用户对'/api/test'接口每分钟最多5次请求。用户ID可以从session或token中获取。伪代码逻辑是：先组合出Redis键名，然后用`incr`命令增加计数，如果返回值为1（说明是时间窗口内的第一次请求），紧接着用`expire`命令设置60秒过期。然后判断`incr`的返回值是否大于5，如果大于5，就返回“频率超限”的错误。这样，一个简单的频率限制中间件就完成了。在实际的Web框架（如Flask、Django）中，可以把这个逻辑写成装饰器或中间件，方便地应用到需要保护的接口上。

处理分布式和多服务器情况

如果你的应用部署在多台服务器上，频率限制必须要在所有服务器之间保持一致。这正是Redis的用武之地。因为所有服务器都连接同一个Redis实例，用户的请求计数被集中存储和判断，无论请求打到哪台服务器，看到的都是统一的计数状态，这样就完美解决了分布式环境下的同步问题。这是使用Redis做频率限制相比使用本地内存计数最大的优势。

FAQ

问：如果Redis宕机了，频率限制功能失效怎么办？
答：这是一个需要考虑的风险点。一种常见的降级策略是，在无法连接到Redis时，可以选择暂时不进行频率限制（记录日志并放行请求），或者退回到使用本地内存进行一个宽松的限制，以保证核心业务不中断。同时，必须确保Redis本身的高可用性，比如采用主从复制或集群模式。

问：如何针对不同的用户或接口设置不同的频率限制规则？
答：可以将规则（如时间窗口大小、最大请求次数）配置在数据库或配置文件中。在生成Redis键和进行判断时，动态地读取对应用户或接口的规则。例如，普通用户键可能是'rate_limit:普通用户:/api/A'，VIP用户键是'rate_limit:VIP用户:/api/A'，它们可以关联不同的计数阈值和过期时间。

问：INCR和EXPIRE命令不是原子操作，会不会有并发问题？
答：确实，如果INCR后、EXPIRE前程序出现问题，可能导致键没有设置过期时间而永久存在。可以使用Redis的Lua脚本将这两个操作原子性地执行，或者在更高版本的Redis中使用`SET key 1 EX 60 NX`这样的命令组合来一步完成。许多客户端库也提供了像`incr_with_expire`这样的封装方法。

引用来源：基于Redis官方文档关于INCR、EXPIRE命令的说明，以及常见的API速率限制设计模式（如固定窗口计数器、令牌桶算法）在社区中的实践总结。