OpenResty 限流方案对比：lua_shared_dict vs Redis
在高并发场景下，限流（Rate Limiting） 是保护系统稳定的重要手段。
OpenResty 提供了多种实现方式，常见的有：
- 基于
lua_shared_dict的本地内存限流 - 基于 Redis 的分布式限流
两者各有优缺点，适用场景也不同。本文将从性能、复杂度、可扩展性等角度进行对比，并给出选型指南。
一、lua_shared_dict 限流
工作原理
lua_shared_dict 是 OpenResty 提供的共享内存字典，所有 worker 进程可以共享访问。常见做法是实现 令牌桶 或 固定窗口 算法，直接存储在共享内存中。
优点
- 高性能：本地内存操作，无需网络 IO，速度极快。
- 低延迟：读写内存开销微乎其微，适合高并发场景。
- 实现简单：配置少，依赖少，无需部署额外组件。
- 容错性高：不依赖外部服务，Redis 崩溃时不会影响限流逻辑。
缺点
- 仅限单机：无法跨节点共享限流状态。
- 内存有限 ：受 Nginx 配置中
lua_shared_dict大小限制。 - 数据不持久化：Nginx 重启后数据丢失。
适用场景
- 单机部署的 API 网关
- Web 服务接口限流（无需跨节点同步）
- 对性能要求极高的场景
二、Redis 限流
工作原理
利用 Redis 的原子操作（如 INCR、EVAL），可以在分布式环境下实现 令牌桶 、滑动窗口 等限流算法。由于 Redis 支持集群部署，因此可实现跨节点共享的全局限流。
优点
- 支持分布式：可在多台服务器之间共享限流状态。
- 灵活性强：支持更复杂的限流规则（如用户级、接口级限流）。
- 可持久化：Redis 支持 RDB/AOF，限流状态可持久保存。
- 生态丰富：可以直接用成熟的 Lua 脚本限流实现。
缺点
- 性能略低：相比本地内存，多了一次网络 IO。
- 复杂度高：需要运维 Redis 集群，配置更复杂。
- 单点依赖：如果 Redis 出现故障，可能影响限流功能。
适用场景
- 分布式 API 网关
- 多台节点需要共享限流状态
- 精细化限流：例如按用户、按接口、按租户
三、对比总结
| 维度 | lua_shared_dict | Redis 限流 |
|---|---|---|
| 性能 | 极高（内存级） | 较高（网络 IO 开销） |
| 延迟 | 微秒级 | 毫秒级 |
| 分布式 | 不支持 | 支持 |
| 复杂度 | 低 | 高（需 Redis 部署/维护） |
| 持久化 | 不支持（重启丢失） | 支持（RDB/AOF） |
| 灵活性 | 一般（适合简单令牌桶） | 高（支持多维度精细限流） |
| 适用场景 | 单机高性能限流 | 集群全局限流、多维度限流 |
四、选型指南
使用 lua_shared_dict 的情况
- 单机部署，API 流量集中在一台或少量服务器
- 追求极致性能，延迟敏感
- 限流逻辑简单，例如单接口 QPS 限制
使用 Redis 的情况
- 分布式部署，需要全局统一的限流策略
- 希望支持多维度限流（用户、租户、接口等）
- 能接受稍高的延迟和 Redis 运维成本
混合模式（推荐）
- 本地快速限流 ：使用
lua_shared_dict实现单机级别的速率控制 - 全局一致性限流：再结合 Redis 做集群级别的整体限流
- 优点：减少 Redis 压力，同时保证全局控制
五、总结
- lua_shared_dict：性能最佳，适合单机限流。
- Redis 限流：支持分布式，适合集群场景。
- 混合方案：兼顾性能与全局控制，适合大多数互联网系统。
在实际项目中，单机限流首选 lua_shared_dict，跨节点限流则结合 Redis，这样既能保持性能，又能保证一致性。