概述

Redis 在系统设计中通常不只是“缓存工具”，而是一个高性能的内存数据结构服务。很多中大型系统都会把 Redis 当作“基础能力层”来使用，用它承接高并发读写、弱一致性数据、临时状态数据以及部分分布式能力。

从使用方式来看，大致可以分成三类：

• 业务层数据加速（缓存、列表、状态数据）
• 分布式系统基础能力（锁、ID、限流、队列）
• 数据结构型能力扩展（排序、索引、简单搜索）

下面按常见场景展开说明。

业务应用

缓存

缓存这个最简单，也是最常见的应用。把经常访问数据保存到 Redis 以提高访问速度，因为 Redis 基于内存读写效率高。比如访问权限、菜单列表等等。

使用 get 和 set 命令即可。

set key $value
get key

计数器和统计数据（点赞、签到）

点击量：

Redis 用来作统计点击量也很方便。

Key 设计：click:{resource}:{id}

resource 为资源类型，id 为资源的 id。

可以使用 INCR 和 INCRBY 命令来递增点击量：

INCR click:article:123

如果你想要在一个 key 下存储多个统计数据（比如同时统计点击量、分享量、评论数等），可以使用 Hash 类型。

Key 设计：

stats:{resource_id}：同样是使用资源的 ID 作为标识符，存储该资源的多个统计数据。

Hash中的字段：

• clicks: 点击量
• shares: 分享量
• comments: 评论量

使用 HINCRBY 来增加点击量：

HINCRBY stats:article:123 clicks 1

签到功能：

BitMap 可以在内存中高效地表示大量的签到数据，适合需要处理大量用户签到的场景。每一位(bit)表示一个用户的签到状态。

Key 设计：

sign:{date} — 每个日期一个 key，用户 ID 通过映射成 bit 位置来记录。

示例：

• sign:2025-08-31 记录 2025 年 8 月 31 日的签到状态。
• 假设用户 ID 是 123，那么用户 ID 对应一个唯一的 bit 位置（比如映射算法可以把用户 ID 123 映射为 bit 位置 123）。

操作：

• 使用 SETBIT 将用户签到状态设置为1：

SETBIT sign:2025-08-31 123 1

• 判断用户是否签到，使用 GETBIT：

GETBIT sign:2025-08-31 123

排行榜

排行榜是 Redis 最典型的应用场景之一，核心依赖的是 Sorted Set（ZSet） 。

ZSet 的特点是每个元素都有一个 score，可以自动排序，非常适合做实时排名系统。

比如游戏积分榜、直播打赏榜、电商销量榜：

• 用户ID作为 member
• 分数（积分、金额、点击数）作为 score
• 通过 ZINCRBY 实时更新分数
• 通过 ZRANGE / ZREVRANGE 获取排名

工程中常见优化点：

• 热榜和全量榜分离（只维护 Top N）
• 分段存储（按日榜 / 周榜 / 总榜）
• 定时快照落库，防止内存数据丢失

排行榜的本质其实就是“实时排序 + 快速读取前 N”。

购物车

购物车通常适合用 Redis 做“临时状态存储”。

常见实现方式：

• Hash：userId -> {productId: quantity}
• 或 String + JSON（较少使用）

Redis 适合购物车的原因：

• 读写频繁
• 不需要强持久化
• 用户未登录或会话状态依赖

典型流程：

1. 加入购物车写 Redis
2. 浏览购物车直接读 Redis
3. 结算时同步到数据库
4. 过期策略（如 7 天未活跃自动清理）

工程上常见问题：

• 多端同步（手机/PC）
• 数据一致性（Redis 与 DB）
• 购物车合并策略（游客 → 登录用户）

附近的人

“附近的人”本质是 地理位置索引问题，Redis 使用 Geo 数据结构解决。

核心能力：

• GEOADD：添加经纬度
• GEORADIUS：查询一定范围内的人
• GEOHASH：编码优化

例如：

• 用户上线时更新位置
• 查询 3km 内在线用户
• 排序可按距离或活跃度调整

注意点：

• 需要定期更新位置（否则位置过期）
• 精度与性能权衡（Geo 是近似算法）
• 通常只做“在线人群过滤”，复杂逻辑交给后端

自动补全

自动补全（Search Suggestion）一般使用 Redis 的 ZSet + 前缀匹配 或 Trie + Redis 混合方案。

常见做法：

• 用户输入前缀
• 查询候选词集合
• 按热度排序返回

例如电商搜索框：

• “iph” → iphone / iphonex / ipad
• score = 搜索频率或点击率

优化方式：

• 分词 + 前缀索引
• 多级缓存（热门词直接缓存结果）
• 本地缓存 + Redis 双层结构

构建服务支持程序

这一部分 Redis 更多扮演“基础设施层”的角色。

服务发现与注册

在一些轻量级微服务体系中，可以用 Redis 做服务注册中心：

• 服务启动 → 写入 Redis（带 TTL）
• 心跳更新 TTL
• 调用方读取服务列表

例如：

service:user -> ["ip1:port", "ip2:port"]

优点：

• 简单
• 依赖少
• 启动快

缺点：

• 不如 ZooKeeper / etcd 强一致
• 容灾能力有限

一般适用于内部系统或轻量微服务。

分布式锁

Redis 分布式锁是经典用法。

核心命令：

• SET key value NX PX 30000

关键点：

• NX 保证只有一个客户端能设置成功
• PX 设置过期时间避免死锁

进阶问题：

• 锁误释放（必须 value 校验）
• 超时续期（watch dog机制）
• RedLock 算法（多节点）

实际工程建议：

• 简单业务用单 Redis 锁即可
• 高一致性场景谨慎使用

分布式ID

Redis 常用 INCR 实现全局唯一 ID：

INCR order_id

优点：

• 简单可靠
• 单调递增

优化方向：

• 按业务分段（user_id / order_id）
• 批量预取（减少 Redis 压力）
• 结合时间戳生成雪花 ID

适合：

• 订单号
• 用户ID
• 业务流水号

限流器

Redis 限流常见两种方案：

1. 计数器模式

INCR key
EXPIRE key 1

用于简单 QPS 控制。

2. 滑动窗口

使用 ZSet 记录时间戳：

• score = 请求时间
• value = 请求ID

优点：

• 更平滑
• 抗突刺能力强

适合：

• API 限流
• 防刷接口

计数信号量

信号量用于控制资源并发访问，比如：

• 限制同一时间最多 100 个任务执行

实现方式：

• INCR + DECR
• 或 Lua 脚本保证原子性

典型场景：

• 线程池控制
• 外部 API 调用限制

任务队列

Redis 可以作为轻量级队列：

• List：LPUSH + BRPOP
• Stream（更现代）

特点：

• 异步处理
• 削峰填谷

例如：

• 发短信任务
• 订单处理
• 日志消费

Stream 方案更适合复杂消费组模型。

消息队列

Redis Stream 已经可以支持类似 MQ 的能力：

• 消费组
• ACK 确认
• 重试机制

相比 Kafka：

• 优点：轻量、部署简单
• 缺点：吞吐和可靠性较弱

适合：

• 中小规模系统
• 辅助消息通道

文件分发

Redis 常用于“文件元信息分发”，而不是直接存文件：

• 存储文件 URL 列表
• 存储版本信息
• 存储下载任务状态

例如：

• OTA 更新
• 客户端资源包更新

Redis 负责“状态同步”，文件本体通常在对象存储（OSS / S3）。

作为搜索中间件使用

Redis 在搜索系统中通常不是“全文搜索引擎”，而是做索引加速层。

使用Redis进行搜索及原理

核心思路是：

• 将搜索词拆成 token
• 用 Set / ZSet 建立倒排索引
• 查询时做交集或排序

例如：

keyword: "java redis tutorial"
索引：
java -> doc1 doc3
redis -> doc1 doc2
tutorial -> doc1

查询时：

• SINTER / ZINTERSTORE

本质是“轻量倒排索引”。

有序索引

ZSet 可以实现“带权重的搜索结果”：

• score = 相关性 / 点击率 / 时间衰减
• member = docID

适用于：

• 热门内容排序
• 文章推荐
• 商品排序

可以实现类似“简单版搜索引擎排序层”。

广告定向

广告投放系统中 Redis 常用于：

• 用户标签存储
• 人群圈选
• 实时匹配

例如：

• user:1001 → ["sports", "tech"]
• ad:2001 → ["tech"]

通过 Set 交集：

SINTER user_tags ad_target_tags

命中则投放广告。

工程上通常还会加：

• 权重排序
• 曝光控制
• 点击率统计

职位搜索

招聘系统中 Redis 可以作为“轻索引层”：

• 城市维度索引
• 技能标签索引
• 薪资区间索引

例如：

• java → job1, job3
• shanghai → job2, job3

查询时做多条件交集，再排序输出。

实际系统中通常：

• Redis 负责快速过滤
• Elasticsearch 负责全文检索

总结

Redis 的本质不是“缓存”，而是一个高性能的内存数据结构引擎。

它在系统设计中扮演的角色可以概括为三点：

• 提速：缓存、索引、热点数据
• 解耦：队列、注册、限流
• 增强能力：排序、Geo、实时计算

如果用一句话总结：

Redis 做的是“把复杂问题变成简单数据结构问题”。