盘点Redis的常见使用场景，拜托不要再只会Get&Set一坨数据啦！

概述

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

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

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

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

业务应用

缓存

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

使用 get 和 set 命令即可。

bash 复制代码

set key $value
get key

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

点击量：

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

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

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

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

bash 复制代码

INCR click:article:123

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

Key 设计：

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

Hash中的字段：

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

使用 HINCRBY 来增加点击量：

bash 复制代码

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：

bash 复制代码

SETBIT sign:2025-08-31 123 1

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

bash 复制代码

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 适合购物车的原因：

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

典型流程：

加入购物车写 Redis
浏览购物车直接读 Redis
结算时同步到数据库
过期策略（如 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
调用方读取服务列表

例如：

bash 复制代码

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：

bash 复制代码

INCR order_id

优点：

简单可靠
单调递增

优化方向：

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

适合：

订单号
用户ID
业务流水号

限流器

Redis 限流常见两种方案：

1. 计数器模式

bash 复制代码

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 建立倒排索引
查询时做交集或排序

例如：

txt 复制代码

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 交集：

bash 复制代码

SINTER user_tags ad_target_tags

命中则投放广告。

工程上通常还会加：

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

职位搜索

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

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

例如：

java → job1, job3
shanghai → job2, job3

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

实际系统中通常：

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

总结

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

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

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

如果用一句话总结：

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