别把 Redis 只当“分布式缓存”

原创已于 2025-09-24 10:25:40 修改 · 827 阅读

CC 4.0 BY-SA版权

文章标签：

#缓存 #redis #分布式 #spring boot #java #spring cloud

于 2025-09-19 12:25:37 首次发布

很多团队在做架构设计时，本能地把 Redis 放在“缓存层”。这么做当然没错，但如果只把它当缓存，是在浪费它的潜力。下面系统梳理：除了缓存之外，Redis 在生产环境还能胜任哪些关键职责、各自适用场景、实现要点与踩坑提示。文末还补充一份“常见非缓存用法速记表”和落地建议，便于直接套用。

1）分布式锁（Distributed Lock）

1.1 基础做法：SET NX（带过期、带唯一值）

命令：SET key value NX PX <ttl-ms>（或 EX ）
关键要点
- 必须设置过期时间，防止持锁进程崩溃造成死锁。
- value 必须是唯一随机值（如 UUID），释放锁时用 Lua 校验“我加的锁只能我解”，避免误删他人锁。
- 释放锁示例脚本（原子校验+删除）：
```
-- KEYS[1]=lockKey, ARGV[1]=requestId
if redis.call("GET", KEYS[1]) == ARGV[1] then
  return redis.call("DEL", KEYS[1])
else
  return 0
end
```
缺点与风险
- 主从复制存在复制延迟，在极端情况下会造成“锁短暂失效”的窗口。
- 过期时间设置不当会出现“业务没执行完锁先到期”的问题，需自动续期（如守护线程）。

工程化提示：在 Java 里可使用 Redisson 的 RLock（内置看门狗自动续期、原子解锁脚本），减少自研坑位。

1.2 Redlock（“红锁”）的来龙去脉

思路：在 N 个彼此独立的 Redis 实例上竞争同名锁，多数派成功才算加锁成功，以此缓解单实例复制延迟带来的问题。
争议：学界与业界对其安全假设是否满足强一致存在分歧（比如网络分区、时钟漂移等假设是否合理）。
实践建议
- 金融级强一致建议优先选用 etcd/ZooKeeper 等共识存储。
- 若使用 Redlock，请确保独立实例、不同故障域，并评估业务对“短暂同时持有锁”的容忍度。

2）简化的发布/订阅（Pub/Sub）

Redis 6 引入 RESP3 协议与推送帧，配合 Pub/Sub/键空间通知更顺手。用法简单、延迟极低，适合轻量级通知广播、UI 实时刷新等。

优势：零依赖、极低时延、上手即用。
硬伤：无持久化、无消费位点。订阅者宕机或暂时离线，消息会丢，因此不能替代专业 MQ。

如果需要至少一次投递与消费位点，优先考虑 Redis Streams（XADD/XREADGROUP/XACK）。它是 Redis 阵营里更接近 MQ 的组件：支持消费组、挂起队列（PEL）、重投递。但也请牢记：Streams 仍是内存系统，不是要取代 Kafka/RabbitMQ 的全能武器。

3）高并发且需要一致性的场景：Lua 原子脚本

自 Redis 2.6 起支持 Lua 脚本（EVAL/EVALSHA）。Redis 单线程+脚本原子执行，使读改写的复合操作具备事务性与高性能，常用于：

库存扣减/秒杀、防超卖
乐观锁 CAS、抢红包等原子转移
复杂计数与限流（一次完成多 key 更新）

注意事项

脚本要短小，长脚本会阻塞事件循环（所有请求被排队）。
参数通过 KEYS/ARGV 传入，避免在脚本里发起网络 I/O。
结合 SCRIPT LOAD + EVALSHA 提升复用率与性能。

4）把 Redis 当“计算引擎”：ZSET、Bitmap 等

4.1 有序集合（Sorted Set，ZSET）：时间线/排行榜/滑动窗口

插入：ZADD timeline <timestamp> <member>
区间查询：ZRANGEBYSCORE / ZREVRANGEBYSCORE 可按时间段取数据
维护：ZREMRANGEBYSCORE 滚动清理过期段，轻松做 T 日留存 与 滑窗统计
典型场景：事件重排序（乱序上报按时间归并）、Top-N 排行榜、去重时间线

4.2 位图（Bitmap）：布尔矩阵的极致压缩

单 bit 表示“是否”发生，适合签到、活跃、课程安排、特征开关等。
常用：
- SETBIT key offset 1/0、GETBIT、BITCOUNT
- BITOP AND/OR/XOR 进行集合交并（例如“周一到周三都上某门课”的交集）
优势：超省内存+运算极快（C 层位运算）

4.3 近似统计与流量分析（模块）

HyperLogLog：PFADD/PFCOUNT 做 UV 估算（误差可控、12KB 固定内存）。
Bloom/Count-Min/Top-K（RedisBloom 模块）：去重探测、热词识别、频率估算。
Geo 系列：GEOADD/GEOSEARCH 实现周边搜索/地理围栏。

5）全文检索：Redis Stack（RediSearch）

如果你想在内存层实现小而美的全文检索，Redis Stack 自带 RediSearch 模块，可对 Hash/JSON 建索引。

建索引（示意）：

FT.CREATE idx ON HASH PREFIX 1 doc:
  SCHEMA title TEXT body TEXT author TAG

检索：

FT.SEARCH idx "架构|设计 @author:{alice|bob}" RETURN 2 title body LIMIT 0 10

优点：内存级低延迟、语法直观、与 Redis 类型天然融合。
权衡：占内存；对复杂检索能力不及 ES/OpenSearch，更适合中小规模、低时延场景或功能内嵌。

6）分布式主键/序列号生成器

6.1 基本法：`INCR/INCRBY`

依赖 Redis 单线程，天然全局唯一：

INCR emp:id:seq   # -> 100182  （举例）

适合生成订单号、发号器、流水号等。

6.2 提升吞吐：号段缓存（Range/Segment）

思想：一次从 Redis 领取一段号（如 [100100,100199]），在应用本地发号；用完再领下一段，极大减少网络往返。
号段领取（Lua/事务）确保无重叠与崩溃安全；可做双缓冲（一个在用一个预取）。
边界：允许空洞（应用崩溃未用完的号会浪费），但通常业务可接受。

进阶：用 Redis 分配 Snowflake 的 workerId，本地再按时间位+序列位拼装，更便于排序与容量规划。

7）“非缓存”常见用法速记表

限流
- 计数器：INCR key + 首次 EXPIRE key window → 简单固定窗口
- 滑动窗口：ZSET 存时间戳，ZREMRANGEBYSCORE 清理窗口外数据，再 ZCARD 判阈值
排行榜/积分体系：ZSET 分值即积分，ZINCRBY 自增，ZREVRANGE 取 Top-N
去重：SET/BF.ADD（布隆）
会话/验证码/短信频控：SETEX/INCR + TTL
分布式信号量/闸门：SETNX + 计数器（或 Lua 原子组合）
键空间通知：监听过期/新增事件做异步流程（注意可靠性）

8）工程落地与选型建议

数据可靠性
- 缓存型：RDB 定时快照足矣；数据型建议开启 AOF（appendfsync everysec），并定期 BGREWRITEAOF。
- 避免把 Redis 当唯一真相源，关键主数据仍应落地到持久化数据库。
部署形态
- 高可用：Sentinel（主从切换）或 Cluster（分片+高可用）。
- 跨机房：强一致要求请慎重，Redis 复制是异步的；跨地域建议把锁/协调交给 etcd/ZK。
内存与 key 设计
- 控制 big key（大字符串/海量成员集合），拆分或分页；
- 合理的 过期策略（TTL + 预估峰值），避免 过期风暴；
- 选用合适的 淘汰策略（volatile-lru/allkeys-lfu 等）并配合监控。
性能
- 用 Pipeline 降低 RTT；批处理/号段化减少网络抖动；
- Lua 脚本/事务避免长阻塞；
- 监控 latency, evicted_keys, keyspace_misses, used_memory 等核心指标。
安全与协议
- Redis 6+ 使用 ACL 做账号/命令粒度权限；
- 尽量跑在内网；外网必须加隧道/白名单/密码与防爆破。

9）易踩坑清单

把 Pub/Sub 当 MQ → 宕机即丢消息；需要持久请用 Streams 或真正的 MQ。
锁无 TTL / 释放不校验 → 死锁或“误删他人锁”。
长 Lua 脚本阻塞 → 峰值时延飙升。
无过期策略 → 内存不可控，触发淘汰导致不可预期的“丢缓存/丢索引”。
全表扫描（KEYS *）在线上使用 → 阻塞。生产请用 SCAN。
复制延迟 → 锁/计数跨节点读写的读到旧值风险。
Streams 不限长度 → 内存暴涨，务必 MAXLEN 或定期修剪。

10）小结

Redis 远不止“分布式缓存”。在分布式锁、轻量消息、原子脚本、内存计算、全文检索、分布式发号等方面，它都能成为系统关键组件。选择哪一种用法，取决于你的一致性/可靠性诉求、延迟目标、数据规模与成本约束。
建议从“是否需要持久化与位点”“是否能接受近似/内存代价”“是否会被长尾阻塞”三个维度做技术取舍，并优先使用成熟的现成实现（如 Redisson 的锁、Redis Stack 的模块），把工程风险降到最低。