聊聊 Redis 使用场景
- 缓存
- 会话缓存
- 时效性
- 访问频率
- 计数器
- 社交列表
- 记录用户判定信息
- 交集、并集和差集
- 热门列表与排行榜
- 最新动态
- 消息队列
十一项场景清单覆盖了 Redis 的常见用法，但清单式罗列缺两块：每个场景对应哪种数据结构与命令组合（落地能力），以及哪些场景今天已有更优替代（边界认知）。本文把清单升级为”场景 → 结构 → 命令 → 注意事项”的四元组手册。
场景-结构-命令映射表
| 场景 | 结构 | 核心命令 | 注意 |
|---|---|---|---|
| 缓存（对象/页面） | String | SET/GET/SETEX | 过期策略+穿透/击穿/雪崩三防 |
| 会话缓存 | String/Hash | SET session:uid / HSET | 多节点共享会话；敏感信息脱敏存储 |
| 时效性（过期业务） | String TTL / Zset | EXPIRE/TTL、ZRANGEBYSCORE | 延迟队列用 Zset score=时间戳 |
| 访问频率限流 | String+TTL / Zset | INCR+EXPIRE、滑动窗口 ZADD+ZREMRANGEBYSCORE | 固定窗口有临界突刺，滑动窗口更平滑 |
| 计数器 | String | INCR/INCRBY（原子） | 点赞/浏览/库存预扣；持久化要求高需异步落库 |
| 社交列表（关注/粉丝） | Set | SADD/SREM/SISMEMBER | 亿级大 Set 注意内存与 bigkey |
| 共同好友/差异 | Set | SINTER/SDIFF/SUNION | 服务端集合运算免拉取客户端 |
| 排行榜 | Zset | ZADD/ZINCRBY/ZREVRANGE/ZREVRANK | score 复合（时间戳做次级序）技巧 |
| 最新动态（Feed） | List/Zset | LPUSH+LTRIM / ZADD 时间戳 | 推拉模式抉择：粉丝量分级推拉结合 |
| 消息队列 | List/Stream | LPUSH+BRPOP / XADD+XREADGROUP | 简单队列用 List；需消费组/ack/回溯用 Stream |
| 位图统计（签到/活跃） | Bitmap | SETBIT/BITCOUNT/BITOP | 亿级用户日活仅 12MB |
| UV 统计 | HyperLogLog | PFADD/PFCOUNT | 0.81% 误差换 12KB 固定内存 |
| 附近的人 | Geo | GEOADD/GEOSEARCH | 底层 Zset，半径/多边形查询 |
清单中三项的深入说明
时效性：两类用法——key 级 TTL（验证码 5 分钟、限流窗口）与 Zset 时间轴（延迟任务、过期事件轮询）。注意 TTL 只在 key 级；hash 内字段过期需拆 key 或 Zset 辅助。
记录用户判定信息（如”是否已点赞/已读”）：Bitmap 按位存（user:liked:articleId 的 bit=uid）比 Set 存 uid 省两个数量级内存；判定位 GETBIT O(1)。
交集并集差集：Set 运算在服务端 O(较小集合) 完成；大集合 SINTER 会阻塞单线程——亿级集合交集应离线计算或分片预处理，别让 bigkey 运算跑在主线程（与 KEYS * 同类风险）。
边界：哪些场景今天有更优替代
- 消息队列：List 版无 ack/重试/消费组语义，生产级应上 Stream 或专业 MQ（Kafka/RocketMQ）——Redis 队列适合轻量内部任务
- 持久化要求高的计数/库存：Redis 异步持久化可能丢秒级数据，核心账目以 DB 为准、Redis 做前置缓冲与异步对账
- 全文检索：RediSearch 模块可用，但生态与能力不及 ES
- 大对象存储：Redis 内存贵，图片/文件走对象存储，Redis 只存元数据/URL
使用红线（场景成立的共同前提）
- 拒绝 bigkey（单 key >10MB 或元素 >10 万）：删除阻塞、迁移卡顿、带宽尖刺
- 拒绝 hotkey 单点：本地缓存（Caffeine）+ 多副本分散
- 过期打散：批量 key 的 TTL 加随机抖动防雪崩
- 内存监控：maxmemory + 淘汰策略明确（缓存场景 allkeys-lru）
Redis 场景手册的正确用法：先按四元组表选结构与命令，再对照边界清单确认”这个场景是否该用 Redis”，最后过一遍红线检查——场景、结构、边界三层齐备，清单才从”知道”变成”会用”。
本博客所有文章除特别声明外，均采用 CC BY-NC-SA 4.0 许可协议。转载请注明来源 非鱼小站！
相关推荐
2022-07-22
缓存降级
页面降级在大促或者某些特殊情况下，某些页面占用了一些稀缺服务资源，在紧急情况下可以对其整个降级，以达到丢卒保帅； 页面片段降级比如商品详情页中的商家部分因为数据错误了，此时需要对其进行降级； 页面异步请求降级比如商品详情页上有推荐信息/配送至等异步加载的请求，如果这些信息响应慢或者后端服务有问题，可以进行降级； 服务功能降级比如渲染商品详情页时需要调用一些不太重要的服务：相关分类、热销榜等，而这些服务在异常情况下直接不获取，即降级即可； 读降级比如多级缓存模式，如果后端服务有问题，可以降级为只读缓存，这种方式适用于对读一致性要求不高的场景； 写降级比如秒杀抢购，我们可以只进行Cache的更新，然后异步同步扣减库存到DB，保证最终一致性即可，此时可以将DB降级为Cache。 爬虫降级在大促活动时，可以将爬虫流量导向静态页或者返回空数据，从而保护后端稀缺资源。 自动开关降级自动降级是根据系统负载、资源使用情况、SLA等指标进行降级。 超时降级当访问的数据库/http服务/远程调用响应慢或者长时间响应慢，且该服务不是核心服务的话可以在超时后自动降级；比如商...
2022-07-18
Redis 内存淘汰机制
Redis 内存淘汰指的是用户存储的一些键被可以被 Redis 主动地从实例中删除，从而产生读 miss 的情况，那么 Redis 为什么要有这种功能？这就是我们需要探究的设计初衷。Redis 最常见的两种应用场景为缓存和持久存储，首先要明确的一个问题是内存淘汰策略更适合于那种场景？是持久存储还是缓存？ 假设我们有一个 Redis 服务器，服务器物理内存大小为 1G 的，我们需要存在 Redis 中的数据量很小，这看起来似乎足够用很长时间了，随着业务量的增长，我们放在 Redis 里面的数据越来越多了，数据量大小似乎超过了 1G，但是应用还可以正常运行，这是因为操作系统的可见内存并不受物理内存限制，而是虚拟内存，物理内存不够用没关系，操作系统会从硬盘上划出一片空间用于构建虚拟内存，比如32位的操作系统的可见内存大小为 2^32，而用户空间的可见内存要小于 2^32 很多，大概是 3G 左右。好了，我们庆幸操作系统为我们做了这些，但是我们需要知道这背后的代价是不菲的，不合理的使用内存有可能发生频繁的 swap，频繁 swap 的代价是惨痛的。所以回过头来看，作为有追求的程序员，我们...
2022-07-21
Redis 为什么是单线程的
因为 CPU 不是 Redis 的瓶颈。Redis 的瓶颈最有可能是机器内存或者网络带宽。（以上主要来自官方 FAQ）既然单线程容易实现，而且 CPU 不会成为瓶颈，那就顺理成章地采用单线程的方案了。但这个回答只解决了”为什么敢”，没解决”为什么快”，本文把这两层都拆开讲。 “单线程”到底指什么先澄清概念：Redis 的单线程指的是网络 I/O 解析与命令执行由同一个主线程串行完成（accept 读取请求、解析命令、执行、写回响应都在一个线程里）。它并不是说整个进程只有一个线程——持久化的 fork、异步删除（unlink）、集群同步等都有后台线程参与。Redis 6.0 之后引入的”多线程”，也仅仅是把网络数据的读写和协议解析交给多个 I/O 线程，命令执行依然在主线程串行完成。 为什么单线程反而快直觉上多线程才能榨干 CPU，但 Redis 的场景特殊： 纯内存操作：一次命令执行通常是微秒级的哈希表/跳表查找，CPU 计算量极小，真正的时间花在网络 I/O 和内存带宽上 多路复用：主线程用 epoll（IO multiplexing）...
2022-07-20
Redis 持久化机制
Redis 有两种持久化机制： RDBRDB 持久化方式会在一个特定的间隔保存那个时间点的一个数据快照 AOFAOF 持久化方式则会记录每一个服务器收到的写操作。在服务启动时，这些记录的操作会逐条执行从而重建出原来的数据。写操作命令记录的格式跟 Redis 协议一致，以追加的方式进行保存 Redis 的持久化是可以禁用的，就是说你可以让数据的生命周期只存在于服务器的运行时间里。两种方式的持久化是可以同时存在的，但是当 Redis 重启时，AOF 文件会被优先用于重建数据。 RDB/AOF 的定义与”重启优先 AOF”的规则正确，但生产决策还需要四层细节：RDB 的 fork-COW 机制与代价、AOF 三种刷盘策略与重写、混合持久化、以及故障恢复的取舍矩阵。本文补全。 RDB：快照的 fork + 写时复制 触发：save（阻塞，禁用）/ bgsave（后台）/ 配置 save 900 1 等阈值 / 主从全量同步 机制：主进程 fork 子进程，子进程共享父进程内存页（COW copy-on-write）：父进程继续服务写请求，写到某页时...
2022-07-17
Redis 内部结构
Redis 内部使用一个 redisObject 对象来表示所有的 key 和 value。 type ：代表一个 value 对象具体是何种数据类型。 encoding ：是不同数据类型在 redis 内部的存储方式，比如：type=string 代表 value 存储的是一个普通字符串，那么对应的 encoding 可以是 raw 或者是 int，如果是 int 则代表实际 redis 内部是按数值型类存储和表示这个字符串的，当然前提是这个字符串本身可以用数值表示，比如：”123” “456”这样的字符串。 vm 字段：只有打开了 Redis 的虚拟内存功能，此字段才会真正的分配内存，该功能默认是关闭状态的。 Redis 使用 redisObject 来表示所有的 key/value 数据是比较浪费内存的，当然这些内存管理成本的付出主要也是为了给 Redis 不同数据类型提供一个统一的管理接口，实际作者也提供了多种方法帮助我们尽量节省内存使用。 redisObject 的 type/encoding 二层结构是理解 Redis 内存行为的钥匙...
2022-07-16
Redis 有哪些类型
在 Redis 中有五种数据类型 String：字符串 Hash：字典 List：列表 Set：集合 Sorted Set：有序集合 背出这五种只算及格。真正决定使用效果的是两个更深的问题：每种类型底层用什么编码实现（决定内存与性能），以及什么业务场景该选哪种类型（决定设计质量）。本文按”类型 → 底层编码 → 典型场景”三层展开。 String：不只是字符串String 是最基础的类型，值可以是字符串、整数或浮点数，底层编码有三种： int：值是能 long 表示的整数，直接存数值，可做原子自增 embstr：短字符串（≤44 字节），对象头与数据一次分配，读快但修改会转 raw raw：长字符串，SDS 实现，O(1) 取长度、二进制安全 典型场景：缓存对象（序列化后整存）、计数器（INCR 原子性天然适合点赞数/限流）、分布式锁（SET key val NX PX）。注意整存整取意味着局部字段更新要全量重写，字段多时优先考虑 Hash。 Hash：对象的结构化存储Hash 是 field-value 字典，底层编码： ziplist（listpack）：...
评论
WalineDisqus
