Redis 是我这两年后端开发里用得最多的中间件没有之一。以前很长时间我对它的理解只停留在set和get上直到在几个项目里接连踩了缓存雪崩、内存暴涨、持久化丢数据的坑才意识到自己根本没把这个东西搞透。这篇笔记不像官方文档那样列命令而是我边学边用边排查问题的全过程沉淀我会从为什么非要选 Redis、五种核心数据结构怎么选、持久化机制怎么取舍、缓存三类致命问题怎么破再到线上常见故障的排查思路逐个讲清楚适合刚接触 Redis 打算系统过一遍的开发者也适合用了一段时间但总觉得哪里没搞透的朋友。1. 先搞懂 Redis 为什么值得学1.1 它解决的根本问题是什么传统关系型数据库把数据放在磁盘上虽然 SSD 已经把随机读性能拉高了不少但和内存比还是有量级差距。Redis 把数据放在内存里读写速度通常在微秒级别单线程也能轻松跑出十万级 QPS这在很多业务场景里直接把接口响应时间从几百毫秒压到个位数毫秒。不过要理解它的价值不能只看到“快”这个词。我自己的理解是Redis 解决的其实是热点数据的访问路径问题。数据库再快也扛不住所有流量直接打上去尤其是读多写少的场景比如用户信息查询、商品详情展示、排行榜列表这些数据有一大部分是不常变化的把它们放到 Redis 里做一个前置缓冲层数据库压力能降一个数量级。所以它的本质是个中间缓存层解决的问题是“让绝大多数请求不要落到磁盘上”。1.2 为什么是 Redis 而不是别的方案你可能会说项目里用本地缓存 Map 不也行吗确实单机部署的时代本地缓存因为零网络开销性能反而比 Redis 更高。但一上多实例就麻烦大了——不同机器上的缓存各自为政数据不一致更新一个 key 还得考虑广播通知所有节点。Redis 是独立部署的集中式缓存天然解决了多实例共享的问题而且自带过期策略、持久化、集群方案这是一套完整的能力不是一个简单的哈希表能比的。那 Memcached 呢我说个真实感受虽然老牌项目里见过它的身影但它只能存字符串数据结构的表达能力太弱存一个对象还得自己序列化拼 key做排行榜、去重、消息队列这类需求根本没法弄。Redis 提供五种基础数据结构一个命令就可能完成过去需要写几百行业务代码才能做的事所以在实践中 Redis 基本成了事实标准。提示选型的时候不要只看基准测试的数字要看数据模型能不能支撑你的业务表达。Redis 的优势从来不只是快五个数据类型才是它最难被替代的部分。2. 五种核心数据结构的实战理解2.1 String 不只是简单的字符串String 是 Redis 最基本的类型但它的玩法远不止存字符串。很多教程只告诉你SET和GET实际开发里真正高频的是这几个能力INCR、DECR做计数器SETNX结合EX参数做分布式锁SETEX做带过期的键值存储。比如一个点赞接口用INCR post:like:{id}就能在内存里完成计数数据库里只需要做异步落账这是典型的用 Redis 扛热点写的例子。我在某电商项目中就吃过 String 使用不当的亏——把整个用户信息序列化成 JSON 塞进一个 key每次只改其中一个字段也要整存整取。后来才知道这种场景应该用 Hash一个字段独立更新既省网络开销又避免并发覆盖。String 适合存简单的值、计数器、令牌以及临时需要原子操作的场景不适合存结构化对象这是新手最容易犯的错误。2.2 Hash 才是存对象的第一选择Hash 是键值对嵌套结构对应到业务里就是一个对象的多字段。比如用户对象你可以存HSET user:1001 name 张三 age 20 city 北京查询任意字段只需要一条HGET更新字段也只是HINCRBY或者HSET单独操作。这在大对象频繁小范围更新的场景里优势非常明显避免了 String 整串序列化带来的序列化开销和内存浪费。另一个我常踩的场景是短链接或库存扣减这类需要同时维护多个属性的数据。Hash 可以把多个关联属性放在同一个 key 下管理配合HGETALL可以一次取回配合HINCRBY还能做字段级原子操作。要注意的是 Hash 底层有两种编码数据量小时用 ziplist 节省内存字段多或 value 长时自动转 hashtable所以尽量不要在 Hash 里塞几百个字段否则底层编码切换后内存消耗会有明显变化。2.3 List 做消息队列时的小心机List 的LPUSHBRPOP组合是很多人拿来当消息队列用的方案。我在早期确实也这么干过直到遇到消费者重启丢消息才明白BRPOP弹出后如果处理进程崩溃这条消息就永远找不回来了。真要用 List 做队列得配合RPOPLPUSH这种安全弹出命令先把消息从一个列表转移到备份列表处理成功后再删除备份这样才能保证“至少一次”的投递语义。另外 List 的另一个用途是时间线/消息流比如用户关注动态按时间倒序排列LPUSH新内容到列表头部然后用LRANGE做分页。这里有个细节LRANGE用 O(N) 复杂度列表越长开销越大所以时间线数据建议只保留最近几百条再老的数据落到数据库查询就行。List 是个好东西但别拿它当分布式队列用真正需要 ack 机制、消息回溯的场景还是得上专业的消息中间件。2.4 Set 和 ZSet 的隐藏用法Set 的无序去重特性最典型的应用是标签系统、好友关系和抽奖去重。SINTER求交集很适合做“共同关注的人”SUNION求并集可以算“可能认识的人”。这里我想强调一个冷门用法抽奖系统的中奖名单去重SADD一个用户 ID 进去如果返回 0 说明已经中过奖天然挡住了重复中奖的问题不需要额外查库。ZSet 是我个人觉得 Redis 最被低估的类型它的每个成员都带一个 score内部用跳跃表实现排序。用它做排行榜、延时队列都比手写业务代码舒服太多。做排行榜时ZADD更新分数ZREVRANGE取前 N 名ZSCORE查单个人排名一套下来全是原子操作。做延时队列时把任务执行时间戳当 score用ZRANGEBYSCORE拉取当前时间之前的任务处理完删除再配合一个轮询定时器就能实现可靠的延时任务。ZSet 能让你省掉大量 SQL 代码这是我在实际项目中体会最深的一点。3. 持久化机制数据安全的重中之重3.1 RDB 快照什么时候用才合理RDB 是把某一时刻的内存数据全量保存到磁盘的二进制快照文件。触发时机通过配置文件里的save指令控制比如save 900 1表示 900 秒内有 1 次写操作就触发一次快照。它的优点是恢复速度快文件紧凑适合备份和迁移缺点是它会丢两次快照之间的数据——假如 15 分钟前做了一次快照刚刚写进去的一批订单数据在宕机后就没了。我在某个交易类项目里试过纯 RDB 方案当时图的是恢复快结果一次意外宕机导致几个小时的订单缓存数据全丢虽然数据库还能查回来但缓存里大量的统计值和临时结果集需要慢慢回源线上接口立刻出现雪崩。所以我现在对 RDB 的定位就两条一是做冷备份二是做主从同步的初始数据源不适合做实时数据恢复的唯一保障。注意RDB 触发是有开销的写快照时会 fork 子进程如果内存很大fork 本身可能耗时几百毫秒甚至更久。配置save 可以完全关闭 RDB但如果主从复制也靠 RDB 传数据关掉之后全量同步会变得很麻烦要结合场景权衡。3.2 AOF 日志如何做到尽量不丢数据AOF 以追加日志的方式记录每一条写命令重启时重放命令就能恢复数据。它的可靠性取决于appendfsync策略always每条命令都刷盘最安全但性能差everysec每秒刷一次最多丢一秒数据性能与安全兼顾no交给操作系统决定刷盘时机性能最好但可能丢大量数据。生产环境我基本都设成everysec很少用always因为单线程的 Redis 如果每条命令都同步刷盘QPS 会直接从十万掉到几万。AOF 的另一个坑是文件无限增长。日志越写越大重启恢复的时间就越长所以必须有aof rewrite机制它会生成一条命令把当前数据集的状态重新写成最小化的 AOF 文件。Redis 会自动触发重写也能用BGREWRITEAOF手动执行。我在很早的项目里就因为没关自动重写某次流量高峰时磁盘被 AOF 撑满最终连接直接拒绝。现在我会监控 AOF 文件增长率和磁盘剩余空间重写时会临时占用约一倍的文件大小空间这个余量得提前预留。3.3 混合持久化才是当前的最优解Redis 4.0 之后引入了混合持久化就是把 RDB 快照和 AOF 增量日志结合重写时先写入一份 RDB 全量数据再追加重写之后的新命令到 AOF 尾部。这样重启时先加载 RDB 快速恢复再用 AOF 补齐数据加载速度远快于纯 AOF数据完整度又比纯 RDB 高。配置项是aof-use-rdb-preamble yes默认开启强烈建议保持开启。我在本地压测过同样包含几百万 key 的数据集纯 AOF 恢复花了接近一分钟混合持久化只要十几秒差距非常明显。所以现在的推荐组合是RDB 做定期全量备份AOF everysec 保证秒级数据不丢两者同时开启AOF 优先于 RDB 加载。这里有个小细节如果线上开了混合持久化redis-check-aof修复工具也支持这种混合文件崩溃恢复时其实很少需要手动修但至少要知道这个工具的存在。4. 缓存三大经典问题的成因与破解4.1 缓存穿透查询一个不存在的东西缓存穿透指的是请求查询的数据在数据库里根本不存在所以缓存永远没有机会命中每次请求都会直接打到数据库攻击者利用这一点可以瞬间打垮数据库。解决思路有两层第一层是缓存空值查询不到数据也往缓存里写一个 null 值加短过期时间比如 60 秒这样后续同样的请求直接命中缓存空值第二层是布隆过滤器在缓存前加一层过滤器判断 key 是否存在不存在的直接拦截但布隆过滤器本身也有误判率和维护成本通常用于 key 数量大且规律明显的场景。我线上遇到过一个真实案例某开放接口可以被外部请求随意传入用户 ID没有做参数合法性校验攻击者构造一批不存在的 ID 直接绕过缓存打到数据库数据库 CPU 立刻飙升。当时的处理是两步走一是对入参加正则校验和黑白名单二是增加缓存空值策略两个一起上才把数据库压下去。记住缓存穿透的本质不是缓存的问题是入口校验的问题先堵入口再谈优化。4.2 缓存击穿热点 key 过期的瞬间缓存击穿和穿透一字之差含义完全不同。击穿说的是某个热点 key 在缓存过期的那一瞬间大量请求同时涌入直接打到数据库。比如秒杀商品的详情页缓存过期之前一切正常过期后一毫秒内有上千个请求同时发现缓存落空全部回源数据库数据库当场被打垮。破解主流方案是互斥锁——缓存过期后不直接查库而是先获取一个分布式锁拿到锁的线程才去查库并回写缓存其他线程短暂等待后重试读取缓存。锁可以用 Redis 自己的命令实现SET lock:hotkey 1 NX EX 5抢锁成功就查库失败则 sleep 几十毫秒再查缓存。还有逻辑过期的思路缓存不设置物理过期时间而是在 value 里存一个逻辑过期时间比如 5 分钟读取时发现逻辑过期就异步重建缓存虽然可能短暂读到旧数据但请求永远不会打到数据库。两方案各有侧重追求强一致选互斥锁追求高可用选逻辑过期。4.3 缓存雪崩大面积同时过期或节点宕机雪崩说的是大量 key 在同一时间过期或者 Redis 节点直接宕机导致所有请求同时回源数据库。前者容易处理建缓存时把过期时间加一个随机值比如5 分钟 0-60 秒随机数让过期时间分散开这是最常用也最便宜的一招。后者就比较麻烦了需要从架构层面兜底服务降级、限流熔断、多级缓存本地缓存 Redis 兜底、数据预热等组合拳。我见过一个教训某次大促活动把所有商品详情缓存统一设置成早上 8 点整过期结果 8 点一过所有用户请求同时打向数据库数据库连接池瞬间耗尽整个服务直接雪崩。后来修复的时候除了加随机过期时间还专门做了一个缓存预热的定时任务在高峰期前 10 分钟用数据库快照重建热点数据的缓存保证高峰期缓存一定是命中的。雪崩不是概率问题是不注意就必现的问题方案一定得提前留好。5. 过期删除与内存淘汰策略5.1 过期的 key 到底什么时候被删给 key 设置了TTL之后它并不是时间一到就立刻从内存里消失。Redis 的过期删除策略是惰性删除 定期删除的配合。惰性删除是指当有请求访问一个 key 时先检查它是否过期过期则删除并返回空定期删除则是 Redis 每隔一段时间随机抽一批 key 检查是否过期过期就删掉。这套策略为什么这么设计原因很简单如果用一个后台线程实时扫描所有 key那内存越大越慢单线程模型会被拖死所以只能随机抽检加访问时顺带删。实际生产中这个设计会带来一个隐藏问题大量已经过期的 key 可能一直占着内存尤其是那种设置了很长 TTL 的冷 key很少被访问定期删除又抽查不到内存会缓慢增长。所以我建议定期用redis-cli --scan --pattern搭配TTL命令检查过期命中率也可以直接用redis-cli --stat看expired_keys的数量变化如果发现过期释放不积极可能需要调大hz参数比如从默认 10 调到 50但这会增加 CPU 消耗得权衡着来。5.2 内存淘汰策略怎么选才不踩坑当 Redis 内存满了之后写命令会报OOM command not allowed when used memory maxmemory只有配置了maxmemory-policy才会开始淘汰数据。Redis 提供了多个策略noeviction不淘汰直接报错allkeys-lru从所有 key 中淘汰最久没用的allkeys-random随机淘汰任何 keyvolatile-lru只从设置了过期时间的 key 里淘汰volatile-ttl优先淘汰剩余 TTL 最短的 key。实际项目里我推荐allkeys-lru因为它最符合缓存的使用语义——数据不重要只用它做加速不重要的旧数据被淘汰是合理的。volatile-lru看着像只淘汰可过期的 key但如果你的业务大量 key 都没设过期时间内存满了之后 Redis 也会开始淘汰这些没有 TTL 的 key 吗不会它只扫过期 key 集合扫完了内存还是满的接下来所有写操作继续报错很容易出事故。所以不要用 volatile 开头的策略除非你能保证所有 key 必然设置了过期时间。提示这里面的 LRU 是近似 LRURedis 不会真的维护一个全局访问链表而是用采样方式估算。默认采样数是 5调大maxmemory-samples能提高淘汰准确率但也会增加一点 CPU 开销一般保持默认就行。6. 线上实战常见问题排查与性能调优6.1 慢查询日志怎么才能真正帮到你Redis 是单线程的一条慢命令会把整个实例拖慢所有请求都得排队等它。所以排查性能问题第一步就是看慢查询日志。配置里slowlog-log-slower-than设置阈值单位是微秒默认 1000010 毫秒我会在线上调低到 2000 或 5000太敏感会有很多噪音slowlog-max-len决定日志条数上限默认 128我一般调到 512。拿到慢查询之后常见的元凶是KEYS *、SMEMBERS、HGETALL这种遍历大集合的命令还有MGET拼了特别多的参数、ZRANGE取范围太大。我的习惯是先用redis-cli --bigkeys找出哪些 key 的体积特别大再针对性地把大的集合类型改用SCAN分批迭代或者精简返回值。扫库命令KEYS线上一定禁用用SCAN命令配合游标分批扫这是我在一次线上事故里用宕机换来的教训。6.2 大 Key 和热 Key 的定位与处理思路大 Key 指的是单个 key 存储的 value 特别大比如有几百万个元素的 Set、几十 MB 的 String它会导致内存不均、网络阻塞、阻塞删除等问题。执行DEL一个超大 key 时Redis 单线程同步删除可能会卡住几十毫秒甚至更久正确做法是用UNLINK命令异步删除或者用SCAN分批删。定位大 Key 我平时就用redis-cli --bigkeys跑一遍这个命令会扫描全部 key 并分别找出每种类型里体积最大的几个虽然它本身也消耗性能建议在低峰期执行。热 Key 则是访问量特别集中的 key比如爆款商品、明星微博。它的问题在于单分片流量打满其他分片空空如也整体资源利用率失衡。定位方法可以用redis-cli --hotkeys需要开启 LFU 策略也可以自己在客户端统计 key 访问次数。处理热 Key 有两个方向本地缓存挡第一层Redis 只用做回源兜底或者把热 Key 复制成 N 份比如加后缀:0到:N随机读把请求分散到不同分片代价是更新时得同步写 N 份。6.3 连接数暴涨和内存碎片问题连接数暴涨是运维 Redis 最常见的一个故障。客户端连接池配置过大或者应用没做好连接复用每次请求都新建连接Redis 最大连接数默认 10000很快就会打满新连接直接拒绝服务。我遇到过一次压测事故应用端的连接池 maxTotal 设置成 500起了 200 个容器实例每个实例请求高峰时都创建大量短连接Redis 的连接数瞬间飙到一万多。后来把连接池 maxTotal 压到 100开启连接空闲回收配合客户端报错重试机制才算把这个隐患按下去。内存碎片也是很多人忽略的点。Redis 频繁增删改数据内存分配器和释放后的空洞会形成碎片INFO memory里mem_fragmentation_ratio指标可以看碎片率正常在 1 到 1.5 之间超过 1.5 说明碎片严重。处理方式是重启实例或者在低峰期执行memory purge等待碎片回收但 Redis 不能强制整理碎片重启是最直接的手段。所以内存指标的监控和告警一定要配好别等问题爆发才回头看监控图。7. 我踩过的坑和留下的经验最后聊几个纯干活才碰得到的小细节。第一连接 Redis 一定要设置超时时间包括连接超时和读写超时不然客户端线程会一直阻塞数据库和 Redis 同时抖动时整个应用就被拖死。第二命令超时需要考虑网络延迟本地测试通过不代表跨机房没问题跨地域访问 Redis 的 RT 会高一个量级该做读写分离或者同机房部署就要早做。第三Redis 版本升级前先读 release notes有些命令的语义在版本间会变化比如SET在 2.6 到 4.0 的几个版本里过期参数都略有差异跳版本升级踩坑概率极高。关于学习路径我个人最推荐的不是抱着命令手册啃而是先把 Redis 官网的文档配合源码读一遍尤其是那篇关于内部数据结构的文章搞懂 ziplist、quicklist、hashtable、skiplist 这些底层结构很多“为什么这个命令性能倒退”“为什么内存突然暴涨”的问题就迎刃而解了。然后一定要自己动手搭一个主从加哨兵的环境亲手把节点 failover 一遍如果条件允许再起一个三节点集群把redis-trib.rb或redis-cli --cluster的命令都走一遍比看任何教程都管用。我在实际项目里体会到的一点是Redis 看起来简单但每个细节背后都是一套深思熟虑的工程权衡。单线程模型、惰性删除配合定期删除、近似 LRU、RDB 配合 AOF这些设计单独看都不完美组合在一起却足够能在绝大多数业务场景里交出满意的答卷。把这些问题想透你对 Redis 的掌控力会有肉眼可见的提升。如果在你的业务里也遇到了类似的问题欢迎用这篇笔记里的排查思路走一遍我相信会比盲目试命令高效很多。 
长河君 · 2026/10/23 8:11:51 · 阅读 1.2k Redis核心数据结构与生产实践：从持久化到缓存三大问题全解析
Redis 是我这两年后端开发里用得最多的中间件没有之一。以前很长时间我对它的理解只停留在set和get上直到在几个项目里接连踩了缓存雪崩、内存暴涨、持久化丢数据的坑才意识到自己根本没把这个东西搞透。这篇笔记不像官方文档那样列命令而是我边学边用边排查问题的全过程沉淀我会从为什么非要选 Redis、五种核心数据结构怎么选、持久化机制怎么取舍、缓存三类致命问题怎么破再到线上常见故障的排查思路逐个讲清楚适合刚接触 Redis 打算系统过一遍的开发者也适合用了一段时间但总觉得哪里没搞透的朋友。1. 先搞懂 Redis 为什么值得学1.1 它解决的根本问题是什么传统关系型数据库把数据放在磁盘上虽然 SSD 已经把随机读性能拉高了不少但和内存比还是有量级差距。Redis 把数据放在内存里读写速度通常在微秒级别单线程也能轻松跑出十万级 QPS这在很多业务场景里直接把接口响应时间从几百毫秒压到个位数毫秒。不过要理解它的价值不能只看到“快”这个词。我自己的理解是Redis 解决的其实是热点数据的访问路径问题。数据库再快也扛不住所有流量直接打上去尤其是读多写少的场景比如用户信息查询、商品详情展示、排行榜列表这些数据有一大部分是不常变化的把它们放到 Redis 里做一个前置缓冲层数据库压力能降一个数量级。所以它的本质是个中间缓存层解决的问题是“让绝大多数请求不要落到磁盘上”。1.2 为什么是 Redis 而不是别的方案你可能会说项目里用本地缓存 Map 不也行吗确实单机部署的时代本地缓存因为零网络开销性能反而比 Redis 更高。但一上多实例就麻烦大了——不同机器上的缓存各自为政数据不一致更新一个 key 还得考虑广播通知所有节点。Redis 是独立部署的集中式缓存天然解决了多实例共享的问题而且自带过期策略、持久化、集群方案这是一套完整的能力不是一个简单的哈希表能比的。那 Memcached 呢我说个真实感受虽然老牌项目里见过它的身影但它只能存字符串数据结构的表达能力太弱存一个对象还得自己序列化拼 key做排行榜、去重、消息队列这类需求根本没法弄。Redis 提供五种基础数据结构一个命令就可能完成过去需要写几百行业务代码才能做的事所以在实践中 Redis 基本成了事实标准。提示选型的时候不要只看基准测试的数字要看数据模型能不能支撑你的业务表达。Redis 的优势从来不只是快五个数据类型才是它最难被替代的部分。2. 五种核心数据结构的实战理解2.1 String 不只是简单的字符串String 是 Redis 最基本的类型但它的玩法远不止存字符串。很多教程只告诉你SET和GET实际开发里真正高频的是这几个能力INCR、DECR做计数器SETNX结合EX参数做分布式锁SETEX做带过期的键值存储。比如一个点赞接口用INCR post:like:{id}就能在内存里完成计数数据库里只需要做异步落账这是典型的用 Redis 扛热点写的例子。我在某电商项目中就吃过 String 使用不当的亏——把整个用户信息序列化成 JSON 塞进一个 key每次只改其中一个字段也要整存整取。后来才知道这种场景应该用 Hash一个字段独立更新既省网络开销又避免并发覆盖。String 适合存简单的值、计数器、令牌以及临时需要原子操作的场景不适合存结构化对象这是新手最容易犯的错误。2.2 Hash 才是存对象的第一选择Hash 是键值对嵌套结构对应到业务里就是一个对象的多字段。比如用户对象你可以存HSET user:1001 name 张三 age 20 city 北京查询任意字段只需要一条HGET更新字段也只是HINCRBY或者HSET单独操作。这在大对象频繁小范围更新的场景里优势非常明显避免了 String 整串序列化带来的序列化开销和内存浪费。另一个我常踩的场景是短链接或库存扣减这类需要同时维护多个属性的数据。Hash 可以把多个关联属性放在同一个 key 下管理配合HGETALL可以一次取回配合HINCRBY还能做字段级原子操作。要注意的是 Hash 底层有两种编码数据量小时用 ziplist 节省内存字段多或 value 长时自动转 hashtable所以尽量不要在 Hash 里塞几百个字段否则底层编码切换后内存消耗会有明显变化。2.3 List 做消息队列时的小心机List 的LPUSHBRPOP组合是很多人拿来当消息队列用的方案。我在早期确实也这么干过直到遇到消费者重启丢消息才明白BRPOP弹出后如果处理进程崩溃这条消息就永远找不回来了。真要用 List 做队列得配合RPOPLPUSH这种安全弹出命令先把消息从一个列表转移到备份列表处理成功后再删除备份这样才能保证“至少一次”的投递语义。另外 List 的另一个用途是时间线/消息流比如用户关注动态按时间倒序排列LPUSH新内容到列表头部然后用LRANGE做分页。这里有个细节LRANGE用 O(N) 复杂度列表越长开销越大所以时间线数据建议只保留最近几百条再老的数据落到数据库查询就行。List 是个好东西但别拿它当分布式队列用真正需要 ack 机制、消息回溯的场景还是得上专业的消息中间件。2.4 Set 和 ZSet 的隐藏用法Set 的无序去重特性最典型的应用是标签系统、好友关系和抽奖去重。SINTER求交集很适合做“共同关注的人”SUNION求并集可以算“可能认识的人”。这里我想强调一个冷门用法抽奖系统的中奖名单去重SADD一个用户 ID 进去如果返回 0 说明已经中过奖天然挡住了重复中奖的问题不需要额外查库。ZSet 是我个人觉得 Redis 最被低估的类型它的每个成员都带一个 score内部用跳跃表实现排序。用它做排行榜、延时队列都比手写业务代码舒服太多。做排行榜时ZADD更新分数ZREVRANGE取前 N 名ZSCORE查单个人排名一套下来全是原子操作。做延时队列时把任务执行时间戳当 score用ZRANGEBYSCORE拉取当前时间之前的任务处理完删除再配合一个轮询定时器就能实现可靠的延时任务。ZSet 能让你省掉大量 SQL 代码这是我在实际项目中体会最深的一点。3. 持久化机制数据安全的重中之重3.1 RDB 快照什么时候用才合理RDB 是把某一时刻的内存数据全量保存到磁盘的二进制快照文件。触发时机通过配置文件里的save指令控制比如save 900 1表示 900 秒内有 1 次写操作就触发一次快照。它的优点是恢复速度快文件紧凑适合备份和迁移缺点是它会丢两次快照之间的数据——假如 15 分钟前做了一次快照刚刚写进去的一批订单数据在宕机后就没了。我在某个交易类项目里试过纯 RDB 方案当时图的是恢复快结果一次意外宕机导致几个小时的订单缓存数据全丢虽然数据库还能查回来但缓存里大量的统计值和临时结果集需要慢慢回源线上接口立刻出现雪崩。所以我现在对 RDB 的定位就两条一是做冷备份二是做主从同步的初始数据源不适合做实时数据恢复的唯一保障。注意RDB 触发是有开销的写快照时会 fork 子进程如果内存很大fork 本身可能耗时几百毫秒甚至更久。配置save 可以完全关闭 RDB但如果主从复制也靠 RDB 传数据关掉之后全量同步会变得很麻烦要结合场景权衡。3.2 AOF 日志如何做到尽量不丢数据AOF 以追加日志的方式记录每一条写命令重启时重放命令就能恢复数据。它的可靠性取决于appendfsync策略always每条命令都刷盘最安全但性能差everysec每秒刷一次最多丢一秒数据性能与安全兼顾no交给操作系统决定刷盘时机性能最好但可能丢大量数据。生产环境我基本都设成everysec很少用always因为单线程的 Redis 如果每条命令都同步刷盘QPS 会直接从十万掉到几万。AOF 的另一个坑是文件无限增长。日志越写越大重启恢复的时间就越长所以必须有aof rewrite机制它会生成一条命令把当前数据集的状态重新写成最小化的 AOF 文件。Redis 会自动触发重写也能用BGREWRITEAOF手动执行。我在很早的项目里就因为没关自动重写某次流量高峰时磁盘被 AOF 撑满最终连接直接拒绝。现在我会监控 AOF 文件增长率和磁盘剩余空间重写时会临时占用约一倍的文件大小空间这个余量得提前预留。3.3 混合持久化才是当前的最优解Redis 4.0 之后引入了混合持久化就是把 RDB 快照和 AOF 增量日志结合重写时先写入一份 RDB 全量数据再追加重写之后的新命令到 AOF 尾部。这样重启时先加载 RDB 快速恢复再用 AOF 补齐数据加载速度远快于纯 AOF数据完整度又比纯 RDB 高。配置项是aof-use-rdb-preamble yes默认开启强烈建议保持开启。我在本地压测过同样包含几百万 key 的数据集纯 AOF 恢复花了接近一分钟混合持久化只要十几秒差距非常明显。所以现在的推荐组合是RDB 做定期全量备份AOF everysec 保证秒级数据不丢两者同时开启AOF 优先于 RDB 加载。这里有个小细节如果线上开了混合持久化redis-check-aof修复工具也支持这种混合文件崩溃恢复时其实很少需要手动修但至少要知道这个工具的存在。4. 缓存三大经典问题的成因与破解4.1 缓存穿透查询一个不存在的东西缓存穿透指的是请求查询的数据在数据库里根本不存在所以缓存永远没有机会命中每次请求都会直接打到数据库攻击者利用这一点可以瞬间打垮数据库。解决思路有两层第一层是缓存空值查询不到数据也往缓存里写一个 null 值加短过期时间比如 60 秒这样后续同样的请求直接命中缓存空值第二层是布隆过滤器在缓存前加一层过滤器判断 key 是否存在不存在的直接拦截但布隆过滤器本身也有误判率和维护成本通常用于 key 数量大且规律明显的场景。我线上遇到过一个真实案例某开放接口可以被外部请求随意传入用户 ID没有做参数合法性校验攻击者构造一批不存在的 ID 直接绕过缓存打到数据库数据库 CPU 立刻飙升。当时的处理是两步走一是对入参加正则校验和黑白名单二是增加缓存空值策略两个一起上才把数据库压下去。记住缓存穿透的本质不是缓存的问题是入口校验的问题先堵入口再谈优化。4.2 缓存击穿热点 key 过期的瞬间缓存击穿和穿透一字之差含义完全不同。击穿说的是某个热点 key 在缓存过期的那一瞬间大量请求同时涌入直接打到数据库。比如秒杀商品的详情页缓存过期之前一切正常过期后一毫秒内有上千个请求同时发现缓存落空全部回源数据库数据库当场被打垮。破解主流方案是互斥锁——缓存过期后不直接查库而是先获取一个分布式锁拿到锁的线程才去查库并回写缓存其他线程短暂等待后重试读取缓存。锁可以用 Redis 自己的命令实现SET lock:hotkey 1 NX EX 5抢锁成功就查库失败则 sleep 几十毫秒再查缓存。还有逻辑过期的思路缓存不设置物理过期时间而是在 value 里存一个逻辑过期时间比如 5 分钟读取时发现逻辑过期就异步重建缓存虽然可能短暂读到旧数据但请求永远不会打到数据库。两方案各有侧重追求强一致选互斥锁追求高可用选逻辑过期。4.3 缓存雪崩大面积同时过期或节点宕机雪崩说的是大量 key 在同一时间过期或者 Redis 节点直接宕机导致所有请求同时回源数据库。前者容易处理建缓存时把过期时间加一个随机值比如5 分钟 0-60 秒随机数让过期时间分散开这是最常用也最便宜的一招。后者就比较麻烦了需要从架构层面兜底服务降级、限流熔断、多级缓存本地缓存 Redis 兜底、数据预热等组合拳。我见过一个教训某次大促活动把所有商品详情缓存统一设置成早上 8 点整过期结果 8 点一过所有用户请求同时打向数据库数据库连接池瞬间耗尽整个服务直接雪崩。后来修复的时候除了加随机过期时间还专门做了一个缓存预热的定时任务在高峰期前 10 分钟用数据库快照重建热点数据的缓存保证高峰期缓存一定是命中的。雪崩不是概率问题是不注意就必现的问题方案一定得提前留好。5. 过期删除与内存淘汰策略5.1 过期的 key 到底什么时候被删给 key 设置了TTL之后它并不是时间一到就立刻从内存里消失。Redis 的过期删除策略是惰性删除 定期删除的配合。惰性删除是指当有请求访问一个 key 时先检查它是否过期过期则删除并返回空定期删除则是 Redis 每隔一段时间随机抽一批 key 检查是否过期过期就删掉。这套策略为什么这么设计原因很简单如果用一个后台线程实时扫描所有 key那内存越大越慢单线程模型会被拖死所以只能随机抽检加访问时顺带删。实际生产中这个设计会带来一个隐藏问题大量已经过期的 key 可能一直占着内存尤其是那种设置了很长 TTL 的冷 key很少被访问定期删除又抽查不到内存会缓慢增长。所以我建议定期用redis-cli --scan --pattern搭配TTL命令检查过期命中率也可以直接用redis-cli --stat看expired_keys的数量变化如果发现过期释放不积极可能需要调大hz参数比如从默认 10 调到 50但这会增加 CPU 消耗得权衡着来。5.2 内存淘汰策略怎么选才不踩坑当 Redis 内存满了之后写命令会报OOM command not allowed when used memory maxmemory只有配置了maxmemory-policy才会开始淘汰数据。Redis 提供了多个策略noeviction不淘汰直接报错allkeys-lru从所有 key 中淘汰最久没用的allkeys-random随机淘汰任何 keyvolatile-lru只从设置了过期时间的 key 里淘汰volatile-ttl优先淘汰剩余 TTL 最短的 key。实际项目里我推荐allkeys-lru因为它最符合缓存的使用语义——数据不重要只用它做加速不重要的旧数据被淘汰是合理的。volatile-lru看着像只淘汰可过期的 key但如果你的业务大量 key 都没设过期时间内存满了之后 Redis 也会开始淘汰这些没有 TTL 的 key 吗不会它只扫过期 key 集合扫完了内存还是满的接下来所有写操作继续报错很容易出事故。所以不要用 volatile 开头的策略除非你能保证所有 key 必然设置了过期时间。提示这里面的 LRU 是近似 LRURedis 不会真的维护一个全局访问链表而是用采样方式估算。默认采样数是 5调大maxmemory-samples能提高淘汰准确率但也会增加一点 CPU 开销一般保持默认就行。6. 线上实战常见问题排查与性能调优6.1 慢查询日志怎么才能真正帮到你Redis 是单线程的一条慢命令会把整个实例拖慢所有请求都得排队等它。所以排查性能问题第一步就是看慢查询日志。配置里slowlog-log-slower-than设置阈值单位是微秒默认 1000010 毫秒我会在线上调低到 2000 或 5000太敏感会有很多噪音slowlog-max-len决定日志条数上限默认 128我一般调到 512。拿到慢查询之后常见的元凶是KEYS *、SMEMBERS、HGETALL这种遍历大集合的命令还有MGET拼了特别多的参数、ZRANGE取范围太大。我的习惯是先用redis-cli --bigkeys找出哪些 key 的体积特别大再针对性地把大的集合类型改用SCAN分批迭代或者精简返回值。扫库命令KEYS线上一定禁用用SCAN命令配合游标分批扫这是我在一次线上事故里用宕机换来的教训。6.2 大 Key 和热 Key 的定位与处理思路大 Key 指的是单个 key 存储的 value 特别大比如有几百万个元素的 Set、几十 MB 的 String它会导致内存不均、网络阻塞、阻塞删除等问题。执行DEL一个超大 key 时Redis 单线程同步删除可能会卡住几十毫秒甚至更久正确做法是用UNLINK命令异步删除或者用SCAN分批删。定位大 Key 我平时就用redis-cli --bigkeys跑一遍这个命令会扫描全部 key 并分别找出每种类型里体积最大的几个虽然它本身也消耗性能建议在低峰期执行。热 Key 则是访问量特别集中的 key比如爆款商品、明星微博。它的问题在于单分片流量打满其他分片空空如也整体资源利用率失衡。定位方法可以用redis-cli --hotkeys需要开启 LFU 策略也可以自己在客户端统计 key 访问次数。处理热 Key 有两个方向本地缓存挡第一层Redis 只用做回源兜底或者把热 Key 复制成 N 份比如加后缀:0到:N随机读把请求分散到不同分片代价是更新时得同步写 N 份。6.3 连接数暴涨和内存碎片问题连接数暴涨是运维 Redis 最常见的一个故障。客户端连接池配置过大或者应用没做好连接复用每次请求都新建连接Redis 最大连接数默认 10000很快就会打满新连接直接拒绝服务。我遇到过一次压测事故应用端的连接池 maxTotal 设置成 500起了 200 个容器实例每个实例请求高峰时都创建大量短连接Redis 的连接数瞬间飙到一万多。后来把连接池 maxTotal 压到 100开启连接空闲回收配合客户端报错重试机制才算把这个隐患按下去。内存碎片也是很多人忽略的点。Redis 频繁增删改数据内存分配器和释放后的空洞会形成碎片INFO memory里mem_fragmentation_ratio指标可以看碎片率正常在 1 到 1.5 之间超过 1.5 说明碎片严重。处理方式是重启实例或者在低峰期执行memory purge等待碎片回收但 Redis 不能强制整理碎片重启是最直接的手段。所以内存指标的监控和告警一定要配好别等问题爆发才回头看监控图。7. 我踩过的坑和留下的经验最后聊几个纯干活才碰得到的小细节。第一连接 Redis 一定要设置超时时间包括连接超时和读写超时不然客户端线程会一直阻塞数据库和 Redis 同时抖动时整个应用就被拖死。第二命令超时需要考虑网络延迟本地测试通过不代表跨机房没问题跨地域访问 Redis 的 RT 会高一个量级该做读写分离或者同机房部署就要早做。第三Redis 版本升级前先读 release notes有些命令的语义在版本间会变化比如SET在 2.6 到 4.0 的几个版本里过期参数都略有差异跳版本升级踩坑概率极高。关于学习路径我个人最推荐的不是抱着命令手册啃而是先把 Redis 官网的文档配合源码读一遍尤其是那篇关于内部数据结构的文章搞懂 ziplist、quicklist、hashtable、skiplist 这些底层结构很多“为什么这个命令性能倒退”“为什么内存突然暴涨”的问题就迎刃而解了。然后一定要自己动手搭一个主从加哨兵的环境亲手把节点 failover 一遍如果条件允许再起一个三节点集群把redis-trib.rb或redis-cli --cluster的命令都走一遍比看任何教程都管用。我在实际项目里体会到的一点是Redis 看起来简单但每个细节背后都是一套深思熟虑的工程权衡。单线程模型、惰性删除配合定期删除、近似 LRU、RDB 配合 AOF这些设计单独看都不完美组合在一起却足够能在绝大多数业务场景里交出满意的答卷。把这些问题想透你对 Redis 的掌控力会有肉眼可见的提升。如果在你的业务里也遇到了类似的问题欢迎用这篇笔记里的排查思路走一遍我相信会比盲目试命令高效很多。