Redis不只是一个缓存：核心数据结构、持久化与高可用实战

1. 从一次事故说起Redis不只是一个缓存1.1 先讲一个让我对缓存改观的事故我接触到 Redis 的时间不算短但真正开始认真理解它是从一次事故开始的。某个项目里有个查询接口平时 QPS 也只有两三千某次大促模拟流量一上接口耗时突然从个位数毫秒涨到几秒数据库连接数瞬间打满整个服务跟着抖。排查到最后问题不在代码而在一批 Key 同时过期所有请求穿透缓存直接落到了数据库。那次事故让我明白一个道理Redis 这类基础组件难点从来不是怎么用而是怎么用得对。很多人嘴上说用了好几年 Redis实际上只用过 GET 和 SET对它的数据结构、持久化机制、集群方案、淘汰策略都没有系统认识。这篇文章我打算把这些年跟 Redis 打交道的理解整理一遍覆盖常见的坑、设计思路和高频场景给想系统认识 Redis 的同学搭一个完整的框架。1.2 远程字典服务的本质是什么Redis 全称是 Remote Dictionary Server翻译过来是远程字典服务。这个概念值得细品它本质上是把一个字典结构搬到了独立的进程里通过网络对外提供读写能力。这里的字典不只是 KV而是包含多种数据结构的复合体。和每个项目里随手写的那种本地 Map 相比Redis 最大的差异有三个地方。第一它是独立进程多个应用实例可以共享同一份数据而本地 Map 的数据只属于当前进程。第二它通过网络访问天然支持跨实例、跨机器的数据交换。第三它带持久化能力进程重启后数据还能恢复不是一挂全没。所以我一直不太喜欢把 Redis 简单叫做缓存。缓存只是它最出名的用法不是它的全部。Redis 还能做分布式锁、排行榜、限流器、消息队列、实时统计核心原因就是它把内存当存储用同时提供了非常丰富的数据结构和原子操作能力。理解了这一点你才算真正认识了 Redis。2. 五大数据结构不只是Key-Value2.1 String二进制安全和原子自增String 是 Redis 最基础的结构命令也最简单就是 SET 和 GET。但简单不代表没有深度有两个特性值得强调。第一个特性是二进制安全。String 存的不是文本字符串而是任意字节序列。序列化对象、图片的压缩块、协议报文都可以直接放进去。单个 Value 最大 512MB实际使用中基本不会触顶。第二个特性是原子自增自减。INCR、DECR、INCRBY 这几个命令天然支持并发安全的自增因为 Redis 单线程执行命令多客户端同时 INCR 不会出现互相覆盖。做接口调用次数统计、库存扣减、点赞数这类场景时一行命令就够不需要额外加锁。String 最常见的误用是把整个对象塞成 JSON。比如存用户信息把 name、age、level 全拼进一个 JSON 字符串后面只改一个 level 字段也要 GET 整个对象、反序列化、改字段、再序列化写回。在高并发下这是极大的浪费。这种场景应该用 Hash 结构。2.2 Hash对象存储的正确打开方式Hash 结构相当于一个 Key 下面挂了一组 field-value 映射非常适合存对象。还是用户信息的例子可以把 name、age、level 分别当作不同的字段存进去更新 level 只需要一个 HSET不用把整个对象读出来再写回去读取单字段也只需要 HGET省掉反序列化的开销。Hash 底层有两种编码方式。字段数量少、字段值短的时候使用紧凑的内存布局整个对象占用连续内存读写效率很高当字段数量变多或者某个 value 变长会升级成真正的哈希表。因为升级不可逆如果一开始就知道字段会很多建议直接在业务上控制在一个稳定范围内一般几百个字段以内性能都很稳。实际项目中很多人喜欢 Hash 存对象、Hash 存配置、Hash 存计数却忽略了一个问题单个 Hash 里的字段如果太多比如几十万个Redis 的操作延迟会明显抬升内存碎片也更严重。经验值是把单个 Hash 的字段控制在 1000 以内量大就拆多个 Key用哈希取模分摊。2.3 List队列场景下的边界List 是双向链表结构左右两端都可以插入和弹出头部和尾部的操作复杂度都是 O(1)。LPUSH 配合 BRPOP 的组合可以搭出一个简单的阻塞队列BRPOP 在队列为空时会阻塞等待新消息不会空转这比应用层轮询更省资源。但我必须说清楚一个边界Redis List 并不适合承担严格的业务消息队列。原因有三个。第一消息确认机制不完整消费者从 List 弹出消息后如果处理失败消息就丢了或者需要自己重新放回去。第二没有重投机制消费端崩溃时无法按序重放。第三多个消费者同时 BRPOP 同一个 List虽然消息不会重复被取但没法做广播和订阅式消费。我的建议是List 适合做临时任务队列、延迟不敏感的任务池、或者作为消息推送前的待发送列表。一旦涉及可靠的业务消息、需要死信队列、需要分组消费就用 Redis Stream 或者成熟的消息中间件不要在 List 上硬堆。2.4 Set去重、交集与随机抽取Set 是无序、元素唯一的集合底层是哈希表所以添加、删除、判断是否存在的复杂度都是 O(1)。它的核心价值在于集合运算交集、并集、差集全都是一行命令。经典场景是社交关系里的共同好友两个用户分别是两个 Set用 SINTER 直接取交集抽奖活动把参与者放进 Set用 SPOP 随机弹出一个不重复的候选人点赞场景里用 SISMEMBER 判断某个用户是否点过赞一个命令就返回结果。Set 的边界也要说清楚它是无序的不存在按加入时间排序的能力。如果需要按时间顺序展示用 List如果需要按分数排序用 ZSet。不要试图在 Set 外面自己做排序那会丢掉 Redis 的价值。2.5 ZSet排行榜背后的排序奥秘ZSet 全称是 Sorted Set每个元素关联一个 double 类型的 score元素按 score 升序排列score 相同则按字典序。排行榜业务几乎都建立在 ZSet 上用户 ID 当 member积分当 scoreZADD 写入ZREVRANGE 取倒序前 N 名ZRANGE 取正序前 N 名ZSCORE 查单人分数ZINCRBY 给某人加分。ZSet 底层用哈希表加跳表实现查询单个元素是 O(1)按分数区间取元素是 O(logN)。几百万成员的排行榜每次插入和查询都很快这也是它被大规模使用的根本原因。实际项目里有个高频问题排行榜只存分数不存业务标识展示的时候还要回数据库做一次映射。正确做法是 member 直接用业务主键 ID需要展示昵称头像时再按 ID 批量查询补充信息一次拿几百个 ID 做 IN 查询对数据库压力很小。3. 单线程为什么这么快内存、事件循环与原子性3.1 内存访问速度快的最根本原因聊到 Redis绕不开为什么那么快这个问题。最根本的原因是数据存储在内存里。内存的随机访问延迟大约在 100ns 量级而磁盘的随机访问延迟在 1ms 量级两者相差几万倍。Redis 把全量数据放在内存读写操作不涉及磁盘寻址天然就比传统数据库快一个数量级以上。但放内存里只是一个前提还不至于撑起百万量级的 QPS。后面还有两个因素分别是事件循环和单线程模型。3.2 IO多路复用一个线程管上万连接Redis 的网络层用的是 IO 多路复用机制。一个线程可以同时监听成千上万个客户端连接哪个连接有可读事件就处理哪个没有事件就阻塞等待。这样避免了为每个连接开一个线程的模型也规避了线程切换的高昂开销。这里有个容易误解的点Redis 6 引入了 IO 多线程很多人以为 Redis 变成了多线程数据库。实际上Redis 的多线程只负责网络数据包的读取和写入真正执行命令的过程依然是单线程。从命令执行的视角看Redis 依然是一次只会有一个命令在跑。3.3 命令的原子性单线程带来的隐藏福利单线程执行命令带来一个极其重要的特性命令天然原子。多个客户端同时执行 INCR不会出现互相覆盖或者半加的状态因为同一时刻只会有一个命令在运行。这也是很多分布式场景敢直接依赖 Redis 的原因。如果希望把多个命令作为一个整体原子执行可以用 MULTI/EXEC 事务也可以用 Lua 脚本。事务在 Redis 里不支持回滚遇到运行时错误其他命令依然会继续执行所以不要把它和关系数据库的事务等同。更推荐的是 Lua 脚本Redis 会保证整个脚本的执行过程不会被其他命令插队这是实现复杂限流、分布式锁续期、多字段更新原子化的核心手段。4. 重启后数据还在吗RDB和AOF的取舍4.1 RDB快照恢复快但要接受丢数据RDB 是 Redis 默认开启的持久化方式之一。原理是定期把内存里的全量数据以压缩的二进制格式写入 .rdb 文件。触发条件可以配置比如900 秒内至少 1 次写操作300 秒内至少 10 次写操作60 秒内至少 10000 次写操作满足任一条件就会触发一次快照。快照生成采用 fork 子进程的方式子进程负责把内存数据写入临时文件父进程继续对外服务所以多数情况下不会阻塞主流程。RDB 文件的优点很明显文件小、恢复快启动时一次性加载。但它的缺点也很直接两个快照之间的数据可能全部丢失。比如 14:00 生成了一次快照14:30 进程突然崩溃这半小时内写入的数据全没了。如果是纯缓存场景丢一部分无所谓但如果承担了计数、会话、订单状态这类数据就绝对不能只用 RDB。4.2 AOF日志更可靠但要控制膨胀AOF 的思路是追加写日志把每一条写命令以文本协议的形式追加到文件末尾。实际落地时由 appendfsync 配置控制刷盘频率always 是每条写命令都调用 fsync 同步到磁盘数据最安全但性能最差everysec 是每秒刷一次盘最多丢最后一秒的数据性能和安全比较均衡生产环境基本都选这个no 则交给操作系统决定什么时候刷盘可能丢的数据最多。AOF 最大的问题是文件膨胀。同一个 Key 被写一万次AOF 里就会有一万条写命令随着时间推移文件越来越大恢复时回放也越来越慢。所以需要定期执行 BGREWRITEAOF 重写日志把内存当前状态转换成一串最精简的写命令再追加后续新增命令相当于做了一次日志压缩。4.3 混合持久化与fork的隐患Redis 4.0 之后推出了混合持久化目的是兼得 RDB 和 AOF 的优点。开启后AOF 文件的头部是一个较新的 RDB 二进制快照快照之后追加增量写命令重启恢复时先加载快照部分再回放少量增量命令既比纯 AOF 恢复快又比纯 RDB 丢的数据少。这是当前生产环境比较合理的持久化组合。最后想提一个调用 fork 时的隐患生成快照和重写 AOF 都需要 fork 子进程fork 的一瞬间要复制父进程的页表如果内存写的频率很高父进程会短暂出现内存和 CPU 的波峰。所以给 Redis 预留内存时不能刚好顶满通常建议 maxmemory 设置不超过物理内存的 70%给 fork 留出缓冲。5. 缓存三大灾穿透、击穿、雪崩及根治思路5.1 缓存穿透不停查询不存在的数据缓存穿透是指请求绕过缓存直接打到数据库典型场景是查询一个不存在的 ID。恶意请求拿随机 ID 反复访问缓存里查不到数据库里也没有每次请求都穿透缓存打数据库很快就能打满数据库连接。常见的根治方案有三类。第一空值缓存查数据库发现不存在时把这个不存在的 Key 在缓存里放一个空值设置较短的过期时间比如 30 秒这样后续同样的请求会命中空值不再打到数据库。代价是缓存里会出现大量空 Key占用内存适合不存在的数据量有限的场景。第二布隆过滤器在缓存前加一层布隆过滤器把可能存在的数据 ID 放进去请求来了先问过滤器不存在就直接返回不用进缓存也不进数据库。布隆过滤器有误判率但不会漏判适合 ID 集合大、不能容忍大量空值缓存的情况。第三参数校验把明显非法的请求在入口拦截掉这最简单也最容易被忽略。5.2 缓存击穿热点Key失效的那几毫秒缓存击穿和穿透不同它针对的是某个热点 Key。这个 Key 平时扛着大量请求突然到了过期时间缓存里没有了一瞬间所有并发请求全部落到底层数据库。可能只是几毫秒但如果是超高热度的 Key这几毫秒足够让数据库崩溃。解决思路主要有两个方向。第一个是互斥锁缓存失效后只有一个请求能成功加锁并去查询数据库、重新写缓存其他请求要么短暂等待要么直接返回旧数据。实现上可以用 SETNX 命令做加锁处理时注意锁的过期时间和等待时间避免请求排队太久。第二个是逻辑过期不在 Redis 上设置真实过期时间而是把过期时间放在 value 里由后台线程发现逻辑过期后主动刷新缓存。这样做请求永远走不到数据库解决的是缓存过期瞬间的并发冲击。5.3 缓存雪崩大批Key同时失效引发的连锁反应缓存雪崩比击穿更严重它涉及的不是单个 Key而是一大批 Key 在同一时刻过期。最常见的原因是设置过期时间时全部用了同一个固定值比如缓存一小时就统一设成 3600 秒结果一到点一波集中请求全部穿透到数据库。应对方案也比较成熟。第一过期时间加随机偏移基础过期时间加一个随机量比如 3600 秒加 0 到 300 秒的随机值让 Key 的过期时间均匀散开。第二多级缓存在 Redis 前面加一层本地缓存就算 Redis 大批量失效本地缓存也能扛住一部分流量。第三入口限流降级在数据库访问层加限流超过阈值直接返回默认数据或降级提示保证系统不整体崩溃。5.4 三者的区别与统一预案三个问题经常被混淆简单归纳一下穿透是查了一个根本不存在的数据击穿是一个热点 Key 过期瞬间,雪崩是大量 Key 同时过期。穿透的关键在源头拦截和空值处理击穿的关键在热点隔离和互斥重建雪崩的关键在过期时间的随机化和兜底降级。从实践角度看提前做好预案远比事后补救重要。大促前压测时我通常会专门检查三件事缓存 Key 的过期时间是否足够分散、热点 Key 是否有重建保护、数据库入口有没有限流兜底。这三件事做扎实了缓存层出大问题的概率会小很多。6. 从单机到集群高可用与内存管理6.1 主从复制读写分离与容灾的起点Redis 生产环境很少跑单机单机一旦宕机在恢复期间所有读写都不可用这对线上服务是不能接受的。主从复制解决了这个问题一台主库负责写多台从库同步数据并负责读主库挂掉后从库可以顶上。配置主从关系很简单从库执行一条命令或者改配置文件即可数据会异步拷贝过去。但你需要接受一个事实主从复制是异步的从库的数据可能存在少量延迟。做读写分离之前一定要想清楚业务能不能容忍读到旧数据如果容忍不了就不要让读请求走从库。6.2 哨兵机制自动切换主库主从复制解决了数据冗余但主库挂掉后仍然需要人工干预。哨兵Sentinel就是一个独立的监控进程它持续监测主库和从库的状态当主库不可达时通过投票机制从从库里选出一个提升为主库同时通知客户端更新指向。哨兵本身也有单点问题所以要部署多个哨兵节点互相监控避免哨兵自己挂了无人管理。注意哨兵负责的是故障发现和自动切换不是数据强一致。主从切换的短暂窗口内写请求可能失败业务侧要设计好重试机制。6.3 Redis Cluster数据分片与横向扩容当单实例内存不够用或者写性能出现瓶颈就需要横向扩展。Redis Cluster 是官方集群方案核心思路是把 16384 个哈希槽均匀分配到每个节点上每个 Key 经过 CRC16 计算后映射到其中一个槽节点只负责自己范围内的槽。客户端可以连接任意节点如果命令涉及其他节点负责的槽节点会返回 MOVED 重定向由客户端重新请求正确节点。Cluster 同时内置了主从冗余每个分片可以配一个从节点自动故障转移。Cluster 有一个明显限制多键操作要求所有 Key 必须在同一个槽里。如果你在 Lua 脚本或事务里同时操作多个 Key设计 Key 时就要用 hash tag 语法比如 {user:1}:profile 和 {user:1}:orders保证两个 Key 计算出来的槽位相同。6.4 内存淘汰策略内存不足时的兜底方案Redis 把数据放在内存里内存是稀缺资源必须提前想好内存满了怎么办。通过 maxmemory 配置设上限后可以按策略淘汰数据常用情况如下策略含义适用场景noeviction不淘汰写命令直接报错数据不允许丢但必须持续监控内存allkeys-lru从所有 Key 里淘汰最久未使用的通用缓存场景使用最多volatile-lru只在设了过期时间的 Key 里淘汰缓存 Key 居多时allkeys-lfu淘汰访问频率最低的 Key热点集中且明显的业务volatile-ttl优先淘汰剩余存活时间最短的 Key可依赖 TTL 控制生命周期有两个容易被忽略的细节。第一Redis 的 LRU 是近似 LRU不是精确的通过采样一部分 Key 来推测最久未使用的那一个但效果在绝大多数场景下足够。第二纯缓存场景建议用 allkeys-lru因为就算误淘汰了还能回源重建如果 Redis 里存了不可丢失的数据要选 noeviction 并搭配监控告警防止内存满后写失败。7. 进阶实战分布式锁、限流和热Key治理7.1 分布式锁SETNX之后还有哪些坑分布式锁是 Redis 最实用也最容易出错的用法。基础写法是这一条命令SET lock_key unique_value NX PX 30000NX 表示只有 Key 不存在时才设置PX 设置过期时间 30 秒。unique_value 是用来标识持有者的随机值释放锁时要先比对再删除避免误删掉别人刚拿到的锁。比对和删除这两步必须用 Lua 脚本原子完成否则中途可能被其他请求插队。实际使用中的坑非常多。第一锁过期时间设太短业务还在执行锁就释放了设太长持有者如果崩溃锁要等很久才能自动释放。业界有一种续期机制由一个后台线程在持有期间定期续期相当于看门狗。第二主从架构下的经典问题主库加锁成功但还没同步到从库主库挂了从库上锁不存在另一个进程也能加锁成功。这就是 RedLock 争论的起点。我的建议是如果业务允许极小的误差直接 SETNX 加锁就够了绝大多数业务其实在这个范围内。如果业务严格要求互斥最好不要在 Redis 上堆砌复杂度优先考虑具备强一致协议的分布式协调工具。7.2 基于Redis的限流器计数器与滑动窗口Redis 做限流非常自然。最简单的固定窗口限流用 INCR 加 EXPIRE 就能实现以用户 ID 或 IP 作为 Key第一次请求时 INCR 后设置过期时间后续请求先 INCR 再判断值有没有超过阈值超过就拒绝。固定窗口有个问题窗口切换的那一秒可能出现两倍的突发流量。更平滑的做法是滑动窗口用 ZSet 记录每次请求的时间戳每次请求先删除窗口外的旧记录再加入当前请求时间戳最后统计窗口内请求总数。这三个操作涉及多个命令必须放进 Lua 脚本里原子执行否则高并发下统计会不准。一个实际经验不要只为每一个用户单独存 ZSet如果用户量很大内存会涨得很快。可以按用户维度做哈希拆分同时评估这个 Redis 实例承载限流的总内存开销是否可接受。7.3 热Key治理从监控到本地缓存高并发系统里总会有那么几个 Key 被反复访问比如秒杀商品、热门话题、直播间在线人数。所有请求都集中在一个 Key 上即使 Redis 再快单节点带宽和 CPU 也会成为瓶颈更严重的是会让缓存失去作用因为每次访问都是热点。常见的治理手段有三类。第一本地缓存把热数据在应用进程内缓存一小段时间读请求优先走本地内存Redis 只作为最终数据来源。这样做最彻底能大幅减少对 Redis 的请求量但要处理本地内存和 Redis 之间的短暂不一致。第二Key 拆分把一个大 Key 拆成多个子 Key比如商品库存拆成多段每次只访问其中一段分散压力。第三多副本同一个 Key 复制多份放到不同实例客户端随机选副本访问。写时需要同步更新所有副本处理不好会引入一致性问题。这些方案没有银弹。更重要的前置工作是监控提前识别哪些 Key 可能是热 Key给 Redis 加上慢查询、节点 CPU、带宽的监控告警。热 Key 出现时能几分钟内发现、几分钟内切换比任何方案都实用。我在实际操作中的体会是认识 Redis 不需要把所有命令都背下来关键是形成一套判断框架——什么数据该放进内存、能不能接受丢数据、单线程模型下哪些操作是原子的、热点流量应该隔离在哪一层。把这些想清楚Redis 在你的系统里就不再是一个黑盒而是一个真正可控的组件。