我自己一般在笔记里分两条线走第一条线是把知识点串成体系第二条线是挖那些“面试常问、实战常踩”的细节。单纯把书的目录抄一遍没用得能回答“为什么”。这篇复习笔记我按自己的理解整理尽量把每个知识点背后的取舍也讲清楚不是罗列命令和参数。1. 为什么Redis复习要有“第二篇”基础篇聊完五大类型、过期策略、内存模型之后真正决定能不能在生产环境站稳的其实是高可用、持久化、集群、缓存一致性这些进阶话题。很多项目Redis一上线就出问题不是crud写错而是主从切换慢了、缓存穿透把数据库打挂了、内存淘汰把热点key清掉了。这些恰恰是“第二篇”要解决的问题。这篇笔记覆盖的核心范围持久化机制RDB、AOF、混合持久化的原理与选型逻辑主从复制与数据一致性全量同步、增量同步、复制积压缓冲区的边界哨兵高可用主观下线、客观下线、故障转移的完整链路集群模式槽位分配、重定向与在线扩缩容缓存三大问题与数据库一致性方案内存淘汰策略与过期键删除的配合事务与Lua脚本的原子性边界性能排查big key、hot key、慢查询、内存碎片这篇适合谁已经会Redis基本操作、想在项目里做高可用设计的人准备面试想系统梳理Redis进阶知识点的人还有跟我一样“用过但没细究过原理”的开发者。复习不代表从头学而是把平时模糊的认知补成完整链路。2. 持久化不是RDB和AOF二选一很多人一被问Redis持久化就条件反射说“RDB快照、AOF日志”但再问一句“为什么有AOF了还要RDB”就卡壳。两个机制解决的问题有重叠但设计思路完全不同实际部署时是协同关系不是竞争关系。2.1 RDB快照内存数据的“全量存档”RDB是某个时间点的内存数据全量二进制快照触发方式有三类配置项定时触发、手动save/bgsave、主从复制或关闭服务时自动触发。定时触发的经典配置就是Redis安装目录里那段默认规则save 900 1 save 300 10 save 60 10000含义是“900秒内至少有1次写操作就生成快照”“300秒内至少有10次写操作就生成快照”“60秒内有10000次写操作就生成快照”。三条规则是或的关系谁先满足谁触发。要注意save和bgsave的区别save直接在主进程里做会阻塞所有客户端命令生产环境基本不用bgsavefork子进程在后台生成快照主进程继续服务bgsave最关键的点是fork的成本。fork瞬间会拷贝页表内存越大fork时间越长极端情况下也可能卡住主进程几十毫秒甚至更久。所以别把RDB当成“随时随地可以生成”的东西大内存实例的fork耗时得提前测。RDB的优势是恢复速度快二进制格式加载比AOF逐条重放快很多很适合做冷备份、数据迁移、启动恢复。缺点就是两次快照之间的数据会丢即使配置了save 60 10000极端情况下也可能丢60秒的写入量。有一个点必须说bgsave和主从全量复制的关系。从节点第一次连主节点时主节点也会生成一次RDB传给从节点这个操作同样占用磁盘IO和网络带宽。大实例做全量同步的时候主节点在读磁盘、写网络有可能造成主线程阻塞或者延迟升高这就是为什么有需求要配repl-diskless-sync来尝试无盘复制。2.2 AOF日志命令的“增量流水账”AOF记录的是“写操作命令”而不是最终数据。它保存的是类似SET key value这样的命令文本恢复时重放一遍相当于把操作过程重演一次。三个关键配置appendonly yes appendfsync everysec auto-aof-rewrite-percentage 100 auto-aof-rewrite-min-size 64mbappendfsync决定命令写入AOF缓冲区后何时调用fsync落盘always每条写命令都同步刷盘最安全但性能损失明显everysec每秒刷一次盘最多丢一秒数据均衡方案no交给操作系统决定何时落盘性能最好但可能丢更多数据实际项目中用everysec最多性能和安全相对折中。注意即使配置了everysec在进程被强制kill时也可能丢一秒内的写命令如果某些业务对数据安全极其敏感再考虑always但一定要有性能预算。AOF文件有个必须处理的问题会无限增长。所以有重写机制。重写不是单纯把文件删一半而是基于当前内存里的最新数据生成一份恢复当前状态所需的最小命令集。比如业务里对同一个key写了100次重写后只保留最后一次的结果。重写默认在AOF文件增长到上次重写后大小的100%即文件翻倍且至少64mb时触发。上面配置的意思是文件超过64mb之后又比上次重写时膨胀了一倍就触发重写。重写过程中的新写命令会先缓存到重写缓冲区重写完成后再追加到新文件不会丢数据。2.3 Redis 4.0混合持久化快照和日志“合并”Redis 4.0前要么RDB要么AOF各有各的伤。混合持久化配置是aof-use-rdb-preamble yes。它的思路是AOF文件开头放一段RDB格式的数据后面再追加增量命令日志。这样结合了两者的优势加载的前半段用RDB格式快速恢复后半段用AOF命令补全增量恢复速度比纯AOF快很多数据安全性又比纯RDB高。现在新版本Redis默认开启混合持久化旧项目升级时要注意确认这个配置否则AOF功能等于用了最原始的方式。关于“到底是RDB还是AOF”如果只保数据完整性选AOF如果追求恢复速度和备份便利选RDB但生产环境我建议混合持久化。同时RDB文件仍然要定期备份到异地AOF只是本地恢复手段不能替代冷备份。恢复优先级要记清Redis重启时如果检测到AOF存在会优先加载AOF没有AOF才加载RDB。因为AOF的数据完整性通常高于RDB。这个顺序来自启动加载逻辑不是人为约定。3. 主从复制数据高可用的第一步单机Redis再稳也是单点机器一挂就全完。主从复制是后面所有高可用方案的基础。理解复制关键是理解全量同步和增量同步是怎么分工的。3.1 复制链路拆解配置方式非常简单在从节点上执行replicaof master-ip 6379从节点连接主节点后会发送psync命令请求同步数据。psync的参数有两个复制ID和offset。复制ID区分是哪一条复制链路的版本offset是当前复制的字节位置。全量同步的流程从节点发送psync ? -1表示需要全量同步主节点执行bgsave生成RDB快照主节点把RDB文件发送给从节点从节点清空旧数据加载RDB主节点把生成RDB之后收到的写命令用复制积压缓冲区同步给从节点这里有个关键点从节点一开始会清空自己的数据。所以不能让一个存了重要数据的Redis实例随便变成某个大实例的从节点数据会被清掉。增量同步的依据是复制积压缓冲区repl_backlog一个固定大小的环形缓冲区默认1MB。主节点把写命令写进缓冲区从节点带着自己的offset请求“从offset之后的数据”。如果从节点的offset还在缓冲区内主节点就把delta数据发给它如果offset已经在缓冲区之外比如断了很久缓冲区的数据被覆盖了那就只能重新全量同步。Repl_backlog大小直接决定“断线多久还能增量同步”。如果网络抖动恢复时间小于缓冲区存满的时间就能走增量否则全量。生产环境建议调大这个值。repl-backlog-size 64mb这个数据是估出来的。假如主节点每秒写入2000条命令每条平均100字节每秒就是200KB。如果希望容忍断线5分钟需要200KB * 300秒 60MB留一点余量就是128MB。算清楚这个数远比默认值更贴合场景。3.2 复制链路上的常见坑第一个坑是复制延迟。主节点写入后从节点一直收数据网络好的时候延迟很低不是零。主从延迟会导致“写主读从”的业务读到旧数据。如果业务对一致性敏感要么强制读主库要么等从库追上。排查时用INFO replication看从节点的lag值这个值持续走高说明网络或磁盘IO出了问题。第二个坑是主节点内存使用。全量同步在主节点上会触发bgsave如果主节点内存大、写入频繁加上从节点数量多可能同时触发多次bgsave内存和磁盘都会告警。建议同一主节点挂的从节点控制在2到3个以内或者用树形结构让从节点再挂子从节点分担主节点的压力。第三个坑是配置变化后的新从节点。加了新从节点必然全量同步这是不可避免的但可以在业务低峰期加避免全量同步高峰堵死主节点。3.3 无盘复制和读写分离repl-diskless-sync可以让主节点不落盘直接把RDB数据通过网络流式传给从节点。文件小的时候差别不大但大实例、SSD磁盘IO紧张的时候能明显减少磁盘负载。注意从节点仍然需要落盘加载无盘只是省了主节点的写盘动作。很多项目做“一主多从读写分离”这个方向的收益在下行流量大、读多写少的场景明显。但同样引入了数据延迟问题如果从节点被用于频道订阅或聚合分析共享同一套Redis实例那么这个从节点只覆盖自己的内存数据AOF和主从复制带来的开销需要规划清楚。我曾经在旧项目里遇到过一个问题从节点内存比主节点小一截刚开始是能正常同步的但主节点内存涨上来之后从节点触发内存淘汰把部分key清掉导致和主节点数据不一致。主从节点的maxmemory必须设置一致淘汰策略也必须一样否则从节点极有可能“被淘汰掉”一部分本应保留的数据运行时间越长偏差越大。4. 哨兵扛住故障和自动切换主从复制解决了数据冗余但主节点挂了以后从节点不会自己变成主节点流量就瘫痪了。哨兵Sentinel就是替人做“检测、选主、切换、通知”的自动化组件。4.1 哨兵部署的几个要点哨兵本身是独立进程部署时至少要3个实例且哨兵和Redis节点的分布不能全在同一个机器上。三节点的原因是故障切换决策需要多数派同意如果只有两个哨兵一个挂了就组不成多数派等于没有高可用。哨兵工作的核心配置sentinel monitor mymaster 127.0.0.1 6379 2 sentinel down-after-milliseconds 5000 sentinel failover-timeout 15000 sentinel parallel-syncs 1monitor那行最后的2是quorum表示至少几个哨兵同意“主节点挂了”才会触发故障切换down-after-milliseconds是判断节点down的时间阈值parallel-syncs是故障切换后同时有几个从节点去同步新主节点设为1避免瞬间把新主压垮哨兵和主节点之间用命令连接和发布订阅连接两种通信方式。哨兵会每10秒向被监控节点发送INFO命令每1秒对节点发送ping判断存活。故障检测准确性的基础就是这些周期性的心跳反馈。4.2 主观下线与客观下线这是一个非常重要的区分主观下线只是单个哨兵认为节点不可达客观下线是多个哨兵达成一致。主观下线sdown单挑哨兵在down-after-milliseconds时间内ping不通主节点它自己先标记主节点主观下线客观下线odown主观下线之后哨兵会请求其它哨兵确认主节点状态quorum数量的哨兵都确认不可达才转成客观下线这里必须理解一个场景网络抖动可能导致某些哨兵ping不通主节点但它其实是活着的。如果只是某一台哨兵sdown就立刻切换就会造成“本来没真挂却被强制切换”的误判。引入quorum机制就是为了过滤这种情况。客观下线之后哨兵们要推选一个leader来执行故障转移。选举机制用的Raft算法思想哪个哨兵先拿到多数派选票谁就执行。推选leader这件事本身也需要多数派这就是为什么不能只有两个哨兵的原因。两个哨兵一个挂了另一个即使发现主节点挂了也无法获得多数派票什么都干不了。4.3 故障转移的完整流程主节点被判定客观下线后哨兵leader开始干活从从节点里筛掉不健康的节点根据优先级、复制偏移量、运行ID选择一个从节点升级为新主节点通知其它从节点replicaof新主节点重新建立复制关系连接原主节点等它恢复后把它降级为新主节点的从节点通过发布订阅通知客户端“地址变了”客户端侧要接住这个变化。如果客户端连的是老的主节点地址切换后需要感知新地址大多数客户端通过哨兵的订阅事件来做比如Lettuce和Jedis都支持配置Sentinel集群的方式。故障转移时间大致估算发现故障按down-after-milliseconds设置如5秒 主观确认 客观确认 选举 切换通常在10到30秒这个级别。所以不要期待秒级自动恢复业务侧应该做好“短时间不可用”的容忍设计。哨兵运维里我碰到比较多的坑是一台机器同时跑数据和哨兵或者哨兵的日志没人看主节点发生SLAVEOF变更也没人关注。哨兵所有动作都有日志故障切换前一定有日志沉淀。把sentinel的日志接到日志系统里比事后抓瞎强很多。5. 集群模式分片不是加个参数就完事单机再强也有天花板垂直扩展总有到头的时候。Redis Cluster是分布式方案的分内之事它把数据打散到多个主节点上每个主节点挂若干从节点。5.1 哈希槽的计算和分配Redis Cluster没有用一致性哈希而是把整个键空间划分成16384个哈希槽计算公式是CRC16(key) % 16384。每个节点负责一段槽位区间。为什么是16384这是工程权衡的结果。CRC16只有16位最大值65535但16384在满足分散性的同时能把节点间槽位映射信息压缩得很小。集群节点之间要通过心跳消息交换槽位信息槽位数越少通信包越小。实际上心跳包要携带本节点负责的槽位bitmap16384位就是2KB65536位就是8KB网络开销差异在节点多的时候非常明显。建集群时槽位要手工分配比如redis-cli --cluster create \ 192.168.1.100:7001 \ 192.168.1.100:7002 \ 192.168.1.101:7003 \ --cluster-replicas 1这个命令会创建三主三从的结构每个主节点约5461个槽位。客户端操作某个key时先计算它属于哪个槽位再查找这个槽位由哪个节点负责直接连对应节点执行命令。注意普通命令只在自己负责的槽位上操作跨多个key的多键操作只有当这些key的槽位在同一个节点上时才支持。5.2 重定向机制客户端访问了不属于当前节点的key时集群会返回重定向信息。两种重定向MOVEDkey的槽位确实在别的节点上客户端需要更新缓存并把命令转发过去ASK槽位正在迁移过程中数据可能还在旧节点请求需要带ASK参数跳转一次实际操作中这层逻辑客户端SDK基本都封装好了。你用JedisCluster、Lettuce的Cluster模式时SDK会缓存槽位和节点的映射关系MOVED会让它更新本地映射ASK则是一次性跳转不更新映射。但要注意集群模式不支持跨slot的mget、mset、pipeline、事务。哪怕几个key在同一个节点只要槽位不同这些命令就可能报错。比如在运维或者其他工具里一次性读多个key会出现CROSSSLOT错误。很多项目改造集群时第一刀就砍在这里业务代码里这些操作必须拆开。5.3 集群模式的使用边界Redis Cluster解决的是容量扩容问题不是高可用问题的全面方案。集群模式下每个主节点都有从节点主节点挂了它的从节点会被提升为新主节点继续服务这就是高可用的实现方式。哨兵不需要在集群模式里再配一套。集群的问题集中在几个方面数据分布无法按业务做冷热分离所有主节点都是平等的无法单独把某个热点key分片大key问题会被放大一个key超过单节点内存水平时整个集群都扛不住批量操作受限前置评估业务时就要想清楚集群扩缩容会触发槽位迁移迁移过程中数据会阻塞要避开业务高峰槽位迁移的操作可以用cluster setslot和cluster getkeysinslot官方还提供了redis-cli --cluster reshard进行交互式迁移。扩容新节点的本质就是把一部分slot从旧节点搬过去。迁移过程中key的读写会走ASK重定向只影响涉及迁移槽位的key不是全网停顿但涉及的那些key会有短暂性能抖动。如果只是读多写少的场景主从哨兵完全够用。数据量超过单机比如超过几十GB或者写入量单机扛不住的时候再上集群。别为了“显得高级”就整齐群成本完全不一样。6. 缓存三大问题与一次性写数据库的平衡分布式缓存里最频繁讨论的三个问题穿透、击穿、雪崩。不只是八股实际运维每天都有可能在日志里看到对应的表现。6.1 穿透、击穿、雪崩的区别和应对缓存穿透查询一个根本不存在的key缓存里没有数据库里也没有请求直接打到数据库。如果有人恶意用不存在的ID循环请求数据库压力瞬间爆掉。应对穿透参数校验非法参数直接拦截缓存空值把null结果也缓存起来设置较短的过期时间布隆过滤器把所有可能存在的key预先放到布隆过滤器里查询前先判断“可能不存在”就直接返回布隆过滤器的原理是多个哈希函数映射到一个bit数组判断key不存在是准确的判断存在则有误判率。用它挡穿透时要做两层判断过滤器说有才继续查缓存和数据库。布隆过滤器有个缺陷删除更新成本高不适合频繁变化的key集合。缓存击穿某个热点key在过期瞬间大量请求同时打到数据库。关键在于这是单个key的“热点失效”。应对击穿互斥锁发现缓存没有先尝试获取分布式锁拿到锁的线程才去数据库查并回填缓存其它线程等待逻辑过期热点key不设过期时间而是在value里写入逻辑过期时间戳后台异步刷新互斥锁要防止死锁和雪崩效应锁的超时时间必须合理否则锁还没释放其他线程已经等超时了。缓存雪崩大量key在同一时刻过期或者缓存节点崩溃导致请求全部打到数据库。本质是“大面积失效”。应对雪崩过期时间加随机值比如基础过期时间300秒再加0到60秒的随机值避免成片失效多级缓存本地缓存比如进程内缓存 Redis 数据库逐级回源降级方案缓存大面积失效时直接返回默认值或限流不让所有请求穿透到数据库我个人在项目里配置过期时间时习惯写成“基础值 RandomUtil.nextInt(600)”代码看起来不复杂但在防雪崩上真的有效。真实环境里一批活动商品同时上下架如果不加随机值整点那一下数据库就能收到一大波热点查询。6.2 缓存与数据库的一致性取舍强一致性在缓存系统里做不到因为缓存和数据库是两个存储任何更新都存在时间窗口。实际工程里一般是最终一致性。主流方案是Cache Aside旁路缓存模式读的时候先读缓存没有就查数据库并回填写的时候更新数据库然后删除缓存而不是更新缓存。为什么删除而不是更新更新缓存有一个致命问题如果新值写入数据库后发现写缓存失败缓存里永远是旧值而且更新缓存涉及缓存重建成本在某些“缓存里存的是经过复杂计算的数据”的场景一次更新代价极高。删除缓存则相反即使删除失败也只是相当于缓存穿透一次下次再回填。那先删缓存再更新数据库还是先更新数据库再删缓存先删缓存再更新数据库更新数据库期间读请求发现缓存没数据去数据库读到旧值回填缓存里又变成旧值数据不一致先更新数据库再删缓存如果删缓存失败缓存里是旧值读请求读旧值但这时只有“删除失败”这一个窗口才可能不一致所以通常选“先更新数据库再删缓存”配合延迟双删进阶方案先更新数据库删除缓存过几百毫秒再删一次兜底并发脏读。注意延迟双删里的等待时间需要大于一次读操作加回填缓存的时间具体几毫秒还是几百毫秒要压测。我用过的另一个方案是版本号或更新时间戳缓存value里保存数据版本写数据库时版本加1读取时比较版本不一致就用数据库数据覆盖缓存。这个方案适合数据结构清晰的场景不完全依赖删除缓存。还有一点要诚实说明缓存一致性永远做不到绝对强一致所谓最优方案只是把不一致窗口缩到业务能接受的程度。设计时先想清楚业务到底能不能容忍秒级不一致而不是一上来就上重型方案。7. 内存有上限淘汰策略怎么选Redis存数据本质是快但内存不是无限的。配置maxmemory之后Redis处理写命令时会检查内存使用超过上限就按策略淘汰某些key。不配置maxmemory的话内存可以被占满然后系统开始swap性能断崖下跌这是最危险的情况。7.1 过期键删除有两种策略Redis删除过期key不是到了时间立刻删而是两种策略配合惰性删除客户端读取key时如果发现已经过期才删除。节省CPU但会让过期key占着内存不释放定期删除每隔一段时间默认100ms随机抽取一部分设置了过期时间的key进行检查过期则删除定期删除是全量扫描而是采样。如果过期key比例很高会分多次循环处理每次限制扫描耗时避免阻塞主线程。但会有漏网的key最终还得依赖惰性删除兜底。这个机制带来一个经验判断如果一个key到期了但还没被访问它的内存不会立刻释放。大量临时key要清理不能只设过期时间还要定期监控内存必要时手动执行scandel。7.2 淘汰策略的关键区别maxmemory-policy有八种配置按行为分成几类策略作用范围行为noeviction全局不淘汰写命令直接报错volatile-lru仅设过期时间的key按最近最少使用淘汰volatile-ttl仅设过期时间的key按剩余寿命最短淘汰volatile-random仅设过期时间的key随机淘汰volatile-lfu仅设过期时间的key按最近最少最频繁使用淘汰allkeys-lru所有key按最近最少使用淘汰allkeys-random所有key随机淘汰allkeys-lfu所有key按最近最少最频繁使用淘汰按场景选缓存业务选allkeys-lru或allkeys-lfu让最常访问的key留下需要保证某些key不被淘汰如分布式锁、任务标记选volatile系列那些“永久key”不会被扫到纯内存数据库no expire只能选noeviction写满后宁可报错也不能丢数据LRU和LFU的区别LRU看的是“多久没访问”LFU看的是“一段时间内访问频率”。热点key访问频率稳定时LFU更准但LFU有“新key刚加入就被淘汰”的问题所以要配好lfu-decay-time和lfu-log-factor。我曾经踩过一个大坑某个项目把Redis当数据库存了全量业务配置key都没有设置过期时间结果maxmemory-policy配成了allkeys-lru。某天配置数据量飙升LRU开始淘汰最旧配置结果一些不常访问但很重要的配置key被清掉了线上业务数据缺失一片。后来改成volatile-lru又给所有业务配置key设了不超过30天的逻辑过期才算根治。淘汰策略测试也很重要线上环境改策略之前先在预发环境设置一个小容量压测观察哪些key最先被淘汰这个操作能避免很多低级事故。8. 事务与Lua原子性的两条实现路线Redis事务和关系型数据库的事务不是一个东西理解这个本质是复习这一节的关键。8.1 MULTI/EXEC的局限Redis事务用MULTI开启命令入队EXEC一起执行。事务内的所有命令会顺序执行不会被其他客户端命令插队但Redis不支持回滚。为什么Redis不支持回滚官方给出的理由是编译期错误命令不存在、参数不对应该在开发期就被发现运行时错误通常是因为使用了错误类型操作而这些错误不是系统故障不应当用复杂的回滚机制去处理。缓存场景本来就允许部分失败回滚反而增加复杂度。所以命令入队时如果语法错误整个事务不会被执行命令执行时如果某一条报错前面命令已经执行后面命令继续执行不会回滚WATCH命令提供一定程度的乐观锁能力EXEC前如果被WATCH的key被其他客户端修改事务会被自动放弃。这在库存扣减、状态流转场景很有用。MULTI/EXEC解决的是“批量执行不被插队”的问题但不解决“先检查再写入”的原子性。例如“判断key是否存在再赋值”这个逻辑用GETSET存在一个时间窗口WATCH可以拦截并发写但多客户端同时操作时会有大量重试体验不友好。8.2 Lua脚本为什么常常更合适Lua脚本由Redis服务端执行整个脚本是原子的相当于一个人闷头把所有命令执行完再返回。它天然解决了“多条命令合并执行时被插队”的问题更致命的一点是Lua脚本内部可以读取和写入多个key而且是事务性的。经典示例库存扣减local stock tonumber(redis.call(get, KEYS[1])) if stock and stock 0 then redis.call(decr, KEYS[1]) return 1 end return 0这个脚本执行时其他客户端无法插入一个check-then-act的命令并发扣减也不会超卖。用Lua要注意几个细节脚本里访问的key和参数只能通过KEYS和ARGV传入不允许在脚本内拼接动态key这是为了集群模式下都能确定哈希槽脚本在Redis中会缓存重复调用用EVALSHA避免每次都传脚本体脚本本身不能做耗时操作比如循环几万次、调用可能导致阻塞的命令。Redis主线程是单线程脚本阻塞等于Redis阻塞集群模式下Lua脚本更严格一个脚本涉及的key必须落在同一个节点上否则会报CROSSSLOT错误。因为脚本要在单个节点上执行跨节点脚本没法保证原子性。设计时要把相关key放到同一个hash tag里比如{user:1001}:orders和{user:1001}:carts共享一个hash tag。事务和Lua怎么选如果是企业级信息需要“不被打断地执行多条命令”Lua更通用如果只是乐观锁控制并发修改用WATCH也行。但Lua会把带条件判断的业务逻辑推到Redis端做得好可以减少大量网络往返做得不好也会引入难以排查的复杂脚本。建议脚本保持短小复杂逻辑留在应用层。9. 复习时容易被忽略的性能细节Redis高性能不是“反正很快”而是建立在一堆约束被遵守的基础上。很多生产事故都不是Redis本身慢而是使用方式让Redis变慢。9.1 big key和hot key的排查big key指单个key的value特别大比如一个大Hash有几百万字段或者一个String存了几MB。big key的危害删除时阻塞主线程DEL一个超大key可能卡住Redis数百毫秒不只是这个key而是整个Redis上的所有请求都卡住网络传输也慢反序列化也慢内存碎片率升高因为大块内存难以复用排查大key用scan而非keys *keys *会阻塞Redis。Redis 4.0以后推荐用unlink异步删除它把释放内存的操作交给后台线程不会阻塞主线程。我每次在大key清理由时都先把unlink流程跑一遍只对真正的热点小key用del。hot key是某个key被超高频率访问比如某个活动ID被并发刷。hot key同样不难排查INFO keyspace或redis-cli --hotkeys能给出参考。解决hot key的思路本地缓存把热点key放在应用进程内请求不进Redis副本扩展把热key复制到多个节点上读请求分散拆key把一个key拆成多个带后缀的key比如key:0到key:99但要注意一致性维护成本9.2 慢查询日志和内存碎片Redis慢查询由阈值和队列决定slowlog-log-slower-than 10000 slowlog-max-len 128slowlog-log-slower-than单位是微秒。10000表示超过10毫秒的命令会被记录。slowlog最多保留128条。想确认什么命令在拖慢Redis就查slowlog get。常见导致慢查询的命令keys *、hgetall一个大hash、sort排序复杂度高、smembers一个超大set。解决方式就是尽量避免在生产环境执行这些命令用scan代替keys *用hscan代替hgetall。内存碎片率是另一个需要盯的指标INFO memory里的mem_fragmentation_ratio。used_memory: 2048000 mem_fragmentation_ratio: 1.4碎片率大于1.5说明内存浪费严重经常加载删除大key会造成碎片。主动碎片整理配置activedefrag yes active-defrag-threshold-lower 10 active-defrag-ignore-bytes 100mbactive-defrag在后台整理碎片但也会消耗CPU。要观察它在提升碎片率的同时给主线程带来的额外延迟。碎片率在1到1.5之间是正常区间大于1.5再考虑开整理不要无条件开启。9.3 info命令是一次性能巡检的入口复习到最后我推荐每次排查性能问题第一步执行redis-cli INFO。几个重点块Server版本、运行天数、进程IDClients当前连接数、阻塞客户端数Memory内存使用、峰值、碎片率Persistence上次RDB/AOF操作的状态Stats每秒命令数、hit/miss比例Replication角色、从节点数、offsetKeyspace每个库的key数量和过期key数量这些信息组合起来能快速定位大部分问题连接数高配合主线程blocked可能是慢查询碎片率高配合大key存在可能是内存碎片hit比例极低配合过期key多可能是缓存类的失效策略失误。10. 复习之后我给自己留的几条建议这篇笔记写完之后我自己复盘了一下。Redis进阶知识的核心不只在于会配置而在于清楚每一个机制背后的取舍和代价。持久化选型是数据安全和性能之间的平衡主从复制是可用性和一致性之间的平衡集群是扩展性和复杂度之间的平衡淘汰策略是命中率和数据安全之间的平衡。第一件重要的事是不要盲目照搬网上的“最佳实践”。比如网上都建议appendfsync everysec但你如果做的是金融级交易流水缓存每丢失一秒数据都可能造成事故那就必须上always同时用性能测试数据说服团队接受吞吐下降。第二件重要的事是任何方案都要有回退路径。主从切换、集群迁移、缓存降级都要演练过不能只在文档上画架构图。我用模拟故障脚本每隔两周做一次主节点kill演练确保哨兵能在预期时间内切换。第三件是被我忽略过、现在无比重视的是监控。没有监控的Redis跑得再好都是碰运气。至少把内存、连接数、命中率、慢查询、主从延迟、碎片率、哨兵状态这几项盯起来告警阈值宁可先紧后松不要把“Redis还活着”当成唯一标准。我建议任何一个做后端开发的人都以“复习”的方式把这些知识点再过一遍工作三五年以后你会发现当年背下来的东西在真实环境里全都有对应的故事可以讲而那些故事才是真正的经验。
我自己一般在笔记里分两条线走第一条线是把知识点串成体系第二条线是挖那些“面试常问、实战常踩”的细节。单纯把书的目录抄一遍没用得能回答“为什么”。这篇复习笔记我按自己的理解整理尽量把每个知识点背后的取舍也讲清楚不是罗列命令和参数。1. 为什么Redis复习要有“第二篇”基础篇聊完五大类型、过期策略、内存模型之后真正决定能不能在生产环境站稳的其实是高可用、持久化、集群、缓存一致性这些进阶话题。很多项目Redis一上线就出问题不是crud写错而是主从切换慢了、缓存穿透把数据库打挂了、内存淘汰把热点key清掉了。这些恰恰是“第二篇”要解决的问题。这篇笔记覆盖的核心范围持久化机制RDB、AOF、混合持久化的原理与选型逻辑主从复制与数据一致性全量同步、增量同步、复制积压缓冲区的边界哨兵高可用主观下线、客观下线、故障转移的完整链路集群模式槽位分配、重定向与在线扩缩容缓存三大问题与数据库一致性方案内存淘汰策略与过期键删除的配合事务与Lua脚本的原子性边界性能排查big key、hot key、慢查询、内存碎片这篇适合谁已经会Redis基本操作、想在项目里做高可用设计的人准备面试想系统梳理Redis进阶知识点的人还有跟我一样“用过但没细究过原理”的开发者。复习不代表从头学而是把平时模糊的认知补成完整链路。2. 持久化不是RDB和AOF二选一很多人一被问Redis持久化就条件反射说“RDB快照、AOF日志”但再问一句“为什么有AOF了还要RDB”就卡壳。两个机制解决的问题有重叠但设计思路完全不同实际部署时是协同关系不是竞争关系。2.1 RDB快照内存数据的“全量存档”RDB是某个时间点的内存数据全量二进制快照触发方式有三类配置项定时触发、手动save/bgsave、主从复制或关闭服务时自动触发。定时触发的经典配置就是Redis安装目录里那段默认规则save 900 1 save 300 10 save 60 10000含义是“900秒内至少有1次写操作就生成快照”“300秒内至少有10次写操作就生成快照”“60秒内有10000次写操作就生成快照”。三条规则是或的关系谁先满足谁触发。要注意save和bgsave的区别save直接在主进程里做会阻塞所有客户端命令生产环境基本不用bgsavefork子进程在后台生成快照主进程继续服务bgsave最关键的点是fork的成本。fork瞬间会拷贝页表内存越大fork时间越长极端情况下也可能卡住主进程几十毫秒甚至更久。所以别把RDB当成“随时随地可以生成”的东西大内存实例的fork耗时得提前测。RDB的优势是恢复速度快二进制格式加载比AOF逐条重放快很多很适合做冷备份、数据迁移、启动恢复。缺点就是两次快照之间的数据会丢即使配置了save 60 10000极端情况下也可能丢60秒的写入量。有一个点必须说bgsave和主从全量复制的关系。从节点第一次连主节点时主节点也会生成一次RDB传给从节点这个操作同样占用磁盘IO和网络带宽。大实例做全量同步的时候主节点在读磁盘、写网络有可能造成主线程阻塞或者延迟升高这就是为什么有需求要配repl-diskless-sync来尝试无盘复制。2.2 AOF日志命令的“增量流水账”AOF记录的是“写操作命令”而不是最终数据。它保存的是类似SET key value这样的命令文本恢复时重放一遍相当于把操作过程重演一次。三个关键配置appendonly yes appendfsync everysec auto-aof-rewrite-percentage 100 auto-aof-rewrite-min-size 64mbappendfsync决定命令写入AOF缓冲区后何时调用fsync落盘always每条写命令都同步刷盘最安全但性能损失明显everysec每秒刷一次盘最多丢一秒数据均衡方案no交给操作系统决定何时落盘性能最好但可能丢更多数据实际项目中用everysec最多性能和安全相对折中。注意即使配置了everysec在进程被强制kill时也可能丢一秒内的写命令如果某些业务对数据安全极其敏感再考虑always但一定要有性能预算。AOF文件有个必须处理的问题会无限增长。所以有重写机制。重写不是单纯把文件删一半而是基于当前内存里的最新数据生成一份恢复当前状态所需的最小命令集。比如业务里对同一个key写了100次重写后只保留最后一次的结果。重写默认在AOF文件增长到上次重写后大小的100%即文件翻倍且至少64mb时触发。上面配置的意思是文件超过64mb之后又比上次重写时膨胀了一倍就触发重写。重写过程中的新写命令会先缓存到重写缓冲区重写完成后再追加到新文件不会丢数据。2.3 Redis 4.0混合持久化快照和日志“合并”Redis 4.0前要么RDB要么AOF各有各的伤。混合持久化配置是aof-use-rdb-preamble yes。它的思路是AOF文件开头放一段RDB格式的数据后面再追加增量命令日志。这样结合了两者的优势加载的前半段用RDB格式快速恢复后半段用AOF命令补全增量恢复速度比纯AOF快很多数据安全性又比纯RDB高。现在新版本Redis默认开启混合持久化旧项目升级时要注意确认这个配置否则AOF功能等于用了最原始的方式。关于“到底是RDB还是AOF”如果只保数据完整性选AOF如果追求恢复速度和备份便利选RDB但生产环境我建议混合持久化。同时RDB文件仍然要定期备份到异地AOF只是本地恢复手段不能替代冷备份。恢复优先级要记清Redis重启时如果检测到AOF存在会优先加载AOF没有AOF才加载RDB。因为AOF的数据完整性通常高于RDB。这个顺序来自启动加载逻辑不是人为约定。3. 主从复制数据高可用的第一步单机Redis再稳也是单点机器一挂就全完。主从复制是后面所有高可用方案的基础。理解复制关键是理解全量同步和增量同步是怎么分工的。3.1 复制链路拆解配置方式非常简单在从节点上执行replicaof master-ip 6379从节点连接主节点后会发送psync命令请求同步数据。psync的参数有两个复制ID和offset。复制ID区分是哪一条复制链路的版本offset是当前复制的字节位置。全量同步的流程从节点发送psync ? -1表示需要全量同步主节点执行bgsave生成RDB快照主节点把RDB文件发送给从节点从节点清空旧数据加载RDB主节点把生成RDB之后收到的写命令用复制积压缓冲区同步给从节点这里有个关键点从节点一开始会清空自己的数据。所以不能让一个存了重要数据的Redis实例随便变成某个大实例的从节点数据会被清掉。增量同步的依据是复制积压缓冲区repl_backlog一个固定大小的环形缓冲区默认1MB。主节点把写命令写进缓冲区从节点带着自己的offset请求“从offset之后的数据”。如果从节点的offset还在缓冲区内主节点就把delta数据发给它如果offset已经在缓冲区之外比如断了很久缓冲区的数据被覆盖了那就只能重新全量同步。Repl_backlog大小直接决定“断线多久还能增量同步”。如果网络抖动恢复时间小于缓冲区存满的时间就能走增量否则全量。生产环境建议调大这个值。repl-backlog-size 64mb这个数据是估出来的。假如主节点每秒写入2000条命令每条平均100字节每秒就是200KB。如果希望容忍断线5分钟需要200KB * 300秒 60MB留一点余量就是128MB。算清楚这个数远比默认值更贴合场景。3.2 复制链路上的常见坑第一个坑是复制延迟。主节点写入后从节点一直收数据网络好的时候延迟很低不是零。主从延迟会导致“写主读从”的业务读到旧数据。如果业务对一致性敏感要么强制读主库要么等从库追上。排查时用INFO replication看从节点的lag值这个值持续走高说明网络或磁盘IO出了问题。第二个坑是主节点内存使用。全量同步在主节点上会触发bgsave如果主节点内存大、写入频繁加上从节点数量多可能同时触发多次bgsave内存和磁盘都会告警。建议同一主节点挂的从节点控制在2到3个以内或者用树形结构让从节点再挂子从节点分担主节点的压力。第三个坑是配置变化后的新从节点。加了新从节点必然全量同步这是不可避免的但可以在业务低峰期加避免全量同步高峰堵死主节点。3.3 无盘复制和读写分离repl-diskless-sync可以让主节点不落盘直接把RDB数据通过网络流式传给从节点。文件小的时候差别不大但大实例、SSD磁盘IO紧张的时候能明显减少磁盘负载。注意从节点仍然需要落盘加载无盘只是省了主节点的写盘动作。很多项目做“一主多从读写分离”这个方向的收益在下行流量大、读多写少的场景明显。但同样引入了数据延迟问题如果从节点被用于频道订阅或聚合分析共享同一套Redis实例那么这个从节点只覆盖自己的内存数据AOF和主从复制带来的开销需要规划清楚。我曾经在旧项目里遇到过一个问题从节点内存比主节点小一截刚开始是能正常同步的但主节点内存涨上来之后从节点触发内存淘汰把部分key清掉导致和主节点数据不一致。主从节点的maxmemory必须设置一致淘汰策略也必须一样否则从节点极有可能“被淘汰掉”一部分本应保留的数据运行时间越长偏差越大。4. 哨兵扛住故障和自动切换主从复制解决了数据冗余但主节点挂了以后从节点不会自己变成主节点流量就瘫痪了。哨兵Sentinel就是替人做“检测、选主、切换、通知”的自动化组件。4.1 哨兵部署的几个要点哨兵本身是独立进程部署时至少要3个实例且哨兵和Redis节点的分布不能全在同一个机器上。三节点的原因是故障切换决策需要多数派同意如果只有两个哨兵一个挂了就组不成多数派等于没有高可用。哨兵工作的核心配置sentinel monitor mymaster 127.0.0.1 6379 2 sentinel down-after-milliseconds 5000 sentinel failover-timeout 15000 sentinel parallel-syncs 1monitor那行最后的2是quorum表示至少几个哨兵同意“主节点挂了”才会触发故障切换down-after-milliseconds是判断节点down的时间阈值parallel-syncs是故障切换后同时有几个从节点去同步新主节点设为1避免瞬间把新主压垮哨兵和主节点之间用命令连接和发布订阅连接两种通信方式。哨兵会每10秒向被监控节点发送INFO命令每1秒对节点发送ping判断存活。故障检测准确性的基础就是这些周期性的心跳反馈。4.2 主观下线与客观下线这是一个非常重要的区分主观下线只是单个哨兵认为节点不可达客观下线是多个哨兵达成一致。主观下线sdown单挑哨兵在down-after-milliseconds时间内ping不通主节点它自己先标记主节点主观下线客观下线odown主观下线之后哨兵会请求其它哨兵确认主节点状态quorum数量的哨兵都确认不可达才转成客观下线这里必须理解一个场景网络抖动可能导致某些哨兵ping不通主节点但它其实是活着的。如果只是某一台哨兵sdown就立刻切换就会造成“本来没真挂却被强制切换”的误判。引入quorum机制就是为了过滤这种情况。客观下线之后哨兵们要推选一个leader来执行故障转移。选举机制用的Raft算法思想哪个哨兵先拿到多数派选票谁就执行。推选leader这件事本身也需要多数派这就是为什么不能只有两个哨兵的原因。两个哨兵一个挂了另一个即使发现主节点挂了也无法获得多数派票什么都干不了。4.3 故障转移的完整流程主节点被判定客观下线后哨兵leader开始干活从从节点里筛掉不健康的节点根据优先级、复制偏移量、运行ID选择一个从节点升级为新主节点通知其它从节点replicaof新主节点重新建立复制关系连接原主节点等它恢复后把它降级为新主节点的从节点通过发布订阅通知客户端“地址变了”客户端侧要接住这个变化。如果客户端连的是老的主节点地址切换后需要感知新地址大多数客户端通过哨兵的订阅事件来做比如Lettuce和Jedis都支持配置Sentinel集群的方式。故障转移时间大致估算发现故障按down-after-milliseconds设置如5秒 主观确认 客观确认 选举 切换通常在10到30秒这个级别。所以不要期待秒级自动恢复业务侧应该做好“短时间不可用”的容忍设计。哨兵运维里我碰到比较多的坑是一台机器同时跑数据和哨兵或者哨兵的日志没人看主节点发生SLAVEOF变更也没人关注。哨兵所有动作都有日志故障切换前一定有日志沉淀。把sentinel的日志接到日志系统里比事后抓瞎强很多。5. 集群模式分片不是加个参数就完事单机再强也有天花板垂直扩展总有到头的时候。Redis Cluster是分布式方案的分内之事它把数据打散到多个主节点上每个主节点挂若干从节点。5.1 哈希槽的计算和分配Redis Cluster没有用一致性哈希而是把整个键空间划分成16384个哈希槽计算公式是CRC16(key) % 16384。每个节点负责一段槽位区间。为什么是16384这是工程权衡的结果。CRC16只有16位最大值65535但16384在满足分散性的同时能把节点间槽位映射信息压缩得很小。集群节点之间要通过心跳消息交换槽位信息槽位数越少通信包越小。实际上心跳包要携带本节点负责的槽位bitmap16384位就是2KB65536位就是8KB网络开销差异在节点多的时候非常明显。建集群时槽位要手工分配比如redis-cli --cluster create \ 192.168.1.100:7001 \ 192.168.1.100:7002 \ 192.168.1.101:7003 \ --cluster-replicas 1这个命令会创建三主三从的结构每个主节点约5461个槽位。客户端操作某个key时先计算它属于哪个槽位再查找这个槽位由哪个节点负责直接连对应节点执行命令。注意普通命令只在自己负责的槽位上操作跨多个key的多键操作只有当这些key的槽位在同一个节点上时才支持。5.2 重定向机制客户端访问了不属于当前节点的key时集群会返回重定向信息。两种重定向MOVEDkey的槽位确实在别的节点上客户端需要更新缓存并把命令转发过去ASK槽位正在迁移过程中数据可能还在旧节点请求需要带ASK参数跳转一次实际操作中这层逻辑客户端SDK基本都封装好了。你用JedisCluster、Lettuce的Cluster模式时SDK会缓存槽位和节点的映射关系MOVED会让它更新本地映射ASK则是一次性跳转不更新映射。但要注意集群模式不支持跨slot的mget、mset、pipeline、事务。哪怕几个key在同一个节点只要槽位不同这些命令就可能报错。比如在运维或者其他工具里一次性读多个key会出现CROSSSLOT错误。很多项目改造集群时第一刀就砍在这里业务代码里这些操作必须拆开。5.3 集群模式的使用边界Redis Cluster解决的是容量扩容问题不是高可用问题的全面方案。集群模式下每个主节点都有从节点主节点挂了它的从节点会被提升为新主节点继续服务这就是高可用的实现方式。哨兵不需要在集群模式里再配一套。集群的问题集中在几个方面数据分布无法按业务做冷热分离所有主节点都是平等的无法单独把某个热点key分片大key问题会被放大一个key超过单节点内存水平时整个集群都扛不住批量操作受限前置评估业务时就要想清楚集群扩缩容会触发槽位迁移迁移过程中数据会阻塞要避开业务高峰槽位迁移的操作可以用cluster setslot和cluster getkeysinslot官方还提供了redis-cli --cluster reshard进行交互式迁移。扩容新节点的本质就是把一部分slot从旧节点搬过去。迁移过程中key的读写会走ASK重定向只影响涉及迁移槽位的key不是全网停顿但涉及的那些key会有短暂性能抖动。如果只是读多写少的场景主从哨兵完全够用。数据量超过单机比如超过几十GB或者写入量单机扛不住的时候再上集群。别为了“显得高级”就整齐群成本完全不一样。6. 缓存三大问题与一次性写数据库的平衡分布式缓存里最频繁讨论的三个问题穿透、击穿、雪崩。不只是八股实际运维每天都有可能在日志里看到对应的表现。6.1 穿透、击穿、雪崩的区别和应对缓存穿透查询一个根本不存在的key缓存里没有数据库里也没有请求直接打到数据库。如果有人恶意用不存在的ID循环请求数据库压力瞬间爆掉。应对穿透参数校验非法参数直接拦截缓存空值把null结果也缓存起来设置较短的过期时间布隆过滤器把所有可能存在的key预先放到布隆过滤器里查询前先判断“可能不存在”就直接返回布隆过滤器的原理是多个哈希函数映射到一个bit数组判断key不存在是准确的判断存在则有误判率。用它挡穿透时要做两层判断过滤器说有才继续查缓存和数据库。布隆过滤器有个缺陷删除更新成本高不适合频繁变化的key集合。缓存击穿某个热点key在过期瞬间大量请求同时打到数据库。关键在于这是单个key的“热点失效”。应对击穿互斥锁发现缓存没有先尝试获取分布式锁拿到锁的线程才去数据库查并回填缓存其它线程等待逻辑过期热点key不设过期时间而是在value里写入逻辑过期时间戳后台异步刷新互斥锁要防止死锁和雪崩效应锁的超时时间必须合理否则锁还没释放其他线程已经等超时了。缓存雪崩大量key在同一时刻过期或者缓存节点崩溃导致请求全部打到数据库。本质是“大面积失效”。应对雪崩过期时间加随机值比如基础过期时间300秒再加0到60秒的随机值避免成片失效多级缓存本地缓存比如进程内缓存 Redis 数据库逐级回源降级方案缓存大面积失效时直接返回默认值或限流不让所有请求穿透到数据库我个人在项目里配置过期时间时习惯写成“基础值 RandomUtil.nextInt(600)”代码看起来不复杂但在防雪崩上真的有效。真实环境里一批活动商品同时上下架如果不加随机值整点那一下数据库就能收到一大波热点查询。6.2 缓存与数据库的一致性取舍强一致性在缓存系统里做不到因为缓存和数据库是两个存储任何更新都存在时间窗口。实际工程里一般是最终一致性。主流方案是Cache Aside旁路缓存模式读的时候先读缓存没有就查数据库并回填写的时候更新数据库然后删除缓存而不是更新缓存。为什么删除而不是更新更新缓存有一个致命问题如果新值写入数据库后发现写缓存失败缓存里永远是旧值而且更新缓存涉及缓存重建成本在某些“缓存里存的是经过复杂计算的数据”的场景一次更新代价极高。删除缓存则相反即使删除失败也只是相当于缓存穿透一次下次再回填。那先删缓存再更新数据库还是先更新数据库再删缓存先删缓存再更新数据库更新数据库期间读请求发现缓存没数据去数据库读到旧值回填缓存里又变成旧值数据不一致先更新数据库再删缓存如果删缓存失败缓存里是旧值读请求读旧值但这时只有“删除失败”这一个窗口才可能不一致所以通常选“先更新数据库再删缓存”配合延迟双删进阶方案先更新数据库删除缓存过几百毫秒再删一次兜底并发脏读。注意延迟双删里的等待时间需要大于一次读操作加回填缓存的时间具体几毫秒还是几百毫秒要压测。我用过的另一个方案是版本号或更新时间戳缓存value里保存数据版本写数据库时版本加1读取时比较版本不一致就用数据库数据覆盖缓存。这个方案适合数据结构清晰的场景不完全依赖删除缓存。还有一点要诚实说明缓存一致性永远做不到绝对强一致所谓最优方案只是把不一致窗口缩到业务能接受的程度。设计时先想清楚业务到底能不能容忍秒级不一致而不是一上来就上重型方案。7. 内存有上限淘汰策略怎么选Redis存数据本质是快但内存不是无限的。配置maxmemory之后Redis处理写命令时会检查内存使用超过上限就按策略淘汰某些key。不配置maxmemory的话内存可以被占满然后系统开始swap性能断崖下跌这是最危险的情况。7.1 过期键删除有两种策略Redis删除过期key不是到了时间立刻删而是两种策略配合惰性删除客户端读取key时如果发现已经过期才删除。节省CPU但会让过期key占着内存不释放定期删除每隔一段时间默认100ms随机抽取一部分设置了过期时间的key进行检查过期则删除定期删除是全量扫描而是采样。如果过期key比例很高会分多次循环处理每次限制扫描耗时避免阻塞主线程。但会有漏网的key最终还得依赖惰性删除兜底。这个机制带来一个经验判断如果一个key到期了但还没被访问它的内存不会立刻释放。大量临时key要清理不能只设过期时间还要定期监控内存必要时手动执行scandel。7.2 淘汰策略的关键区别maxmemory-policy有八种配置按行为分成几类策略作用范围行为noeviction全局不淘汰写命令直接报错volatile-lru仅设过期时间的key按最近最少使用淘汰volatile-ttl仅设过期时间的key按剩余寿命最短淘汰volatile-random仅设过期时间的key随机淘汰volatile-lfu仅设过期时间的key按最近最少最频繁使用淘汰allkeys-lru所有key按最近最少使用淘汰allkeys-random所有key随机淘汰allkeys-lfu所有key按最近最少最频繁使用淘汰按场景选缓存业务选allkeys-lru或allkeys-lfu让最常访问的key留下需要保证某些key不被淘汰如分布式锁、任务标记选volatile系列那些“永久key”不会被扫到纯内存数据库no expire只能选noeviction写满后宁可报错也不能丢数据LRU和LFU的区别LRU看的是“多久没访问”LFU看的是“一段时间内访问频率”。热点key访问频率稳定时LFU更准但LFU有“新key刚加入就被淘汰”的问题所以要配好lfu-decay-time和lfu-log-factor。我曾经踩过一个大坑某个项目把Redis当数据库存了全量业务配置key都没有设置过期时间结果maxmemory-policy配成了allkeys-lru。某天配置数据量飙升LRU开始淘汰最旧配置结果一些不常访问但很重要的配置key被清掉了线上业务数据缺失一片。后来改成volatile-lru又给所有业务配置key设了不超过30天的逻辑过期才算根治。淘汰策略测试也很重要线上环境改策略之前先在预发环境设置一个小容量压测观察哪些key最先被淘汰这个操作能避免很多低级事故。8. 事务与Lua原子性的两条实现路线Redis事务和关系型数据库的事务不是一个东西理解这个本质是复习这一节的关键。8.1 MULTI/EXEC的局限Redis事务用MULTI开启命令入队EXEC一起执行。事务内的所有命令会顺序执行不会被其他客户端命令插队但Redis不支持回滚。为什么Redis不支持回滚官方给出的理由是编译期错误命令不存在、参数不对应该在开发期就被发现运行时错误通常是因为使用了错误类型操作而这些错误不是系统故障不应当用复杂的回滚机制去处理。缓存场景本来就允许部分失败回滚反而增加复杂度。所以命令入队时如果语法错误整个事务不会被执行命令执行时如果某一条报错前面命令已经执行后面命令继续执行不会回滚WATCH命令提供一定程度的乐观锁能力EXEC前如果被WATCH的key被其他客户端修改事务会被自动放弃。这在库存扣减、状态流转场景很有用。MULTI/EXEC解决的是“批量执行不被插队”的问题但不解决“先检查再写入”的原子性。例如“判断key是否存在再赋值”这个逻辑用GETSET存在一个时间窗口WATCH可以拦截并发写但多客户端同时操作时会有大量重试体验不友好。8.2 Lua脚本为什么常常更合适Lua脚本由Redis服务端执行整个脚本是原子的相当于一个人闷头把所有命令执行完再返回。它天然解决了“多条命令合并执行时被插队”的问题更致命的一点是Lua脚本内部可以读取和写入多个key而且是事务性的。经典示例库存扣减local stock tonumber(redis.call(get, KEYS[1])) if stock and stock 0 then redis.call(decr, KEYS[1]) return 1 end return 0这个脚本执行时其他客户端无法插入一个check-then-act的命令并发扣减也不会超卖。用Lua要注意几个细节脚本里访问的key和参数只能通过KEYS和ARGV传入不允许在脚本内拼接动态key这是为了集群模式下都能确定哈希槽脚本在Redis中会缓存重复调用用EVALSHA避免每次都传脚本体脚本本身不能做耗时操作比如循环几万次、调用可能导致阻塞的命令。Redis主线程是单线程脚本阻塞等于Redis阻塞集群模式下Lua脚本更严格一个脚本涉及的key必须落在同一个节点上否则会报CROSSSLOT错误。因为脚本要在单个节点上执行跨节点脚本没法保证原子性。设计时要把相关key放到同一个hash tag里比如{user:1001}:orders和{user:1001}:carts共享一个hash tag。事务和Lua怎么选如果是企业级信息需要“不被打断地执行多条命令”Lua更通用如果只是乐观锁控制并发修改用WATCH也行。但Lua会把带条件判断的业务逻辑推到Redis端做得好可以减少大量网络往返做得不好也会引入难以排查的复杂脚本。建议脚本保持短小复杂逻辑留在应用层。9. 复习时容易被忽略的性能细节Redis高性能不是“反正很快”而是建立在一堆约束被遵守的基础上。很多生产事故都不是Redis本身慢而是使用方式让Redis变慢。9.1 big key和hot key的排查big key指单个key的value特别大比如一个大Hash有几百万字段或者一个String存了几MB。big key的危害删除时阻塞主线程DEL一个超大key可能卡住Redis数百毫秒不只是这个key而是整个Redis上的所有请求都卡住网络传输也慢反序列化也慢内存碎片率升高因为大块内存难以复用排查大key用scan而非keys *keys *会阻塞Redis。Redis 4.0以后推荐用unlink异步删除它把释放内存的操作交给后台线程不会阻塞主线程。我每次在大key清理由时都先把unlink流程跑一遍只对真正的热点小key用del。hot key是某个key被超高频率访问比如某个活动ID被并发刷。hot key同样不难排查INFO keyspace或redis-cli --hotkeys能给出参考。解决hot key的思路本地缓存把热点key放在应用进程内请求不进Redis副本扩展把热key复制到多个节点上读请求分散拆key把一个key拆成多个带后缀的key比如key:0到key:99但要注意一致性维护成本9.2 慢查询日志和内存碎片Redis慢查询由阈值和队列决定slowlog-log-slower-than 10000 slowlog-max-len 128slowlog-log-slower-than单位是微秒。10000表示超过10毫秒的命令会被记录。slowlog最多保留128条。想确认什么命令在拖慢Redis就查slowlog get。常见导致慢查询的命令keys *、hgetall一个大hash、sort排序复杂度高、smembers一个超大set。解决方式就是尽量避免在生产环境执行这些命令用scan代替keys *用hscan代替hgetall。内存碎片率是另一个需要盯的指标INFO memory里的mem_fragmentation_ratio。used_memory: 2048000 mem_fragmentation_ratio: 1.4碎片率大于1.5说明内存浪费严重经常加载删除大key会造成碎片。主动碎片整理配置activedefrag yes active-defrag-threshold-lower 10 active-defrag-ignore-bytes 100mbactive-defrag在后台整理碎片但也会消耗CPU。要观察它在提升碎片率的同时给主线程带来的额外延迟。碎片率在1到1.5之间是正常区间大于1.5再考虑开整理不要无条件开启。9.3 info命令是一次性能巡检的入口复习到最后我推荐每次排查性能问题第一步执行redis-cli INFO。几个重点块Server版本、运行天数、进程IDClients当前连接数、阻塞客户端数Memory内存使用、峰值、碎片率Persistence上次RDB/AOF操作的状态Stats每秒命令数、hit/miss比例Replication角色、从节点数、offsetKeyspace每个库的key数量和过期key数量这些信息组合起来能快速定位大部分问题连接数高配合主线程blocked可能是慢查询碎片率高配合大key存在可能是内存碎片hit比例极低配合过期key多可能是缓存类的失效策略失误。10. 复习之后我给自己留的几条建议这篇笔记写完之后我自己复盘了一下。Redis进阶知识的核心不只在于会配置而在于清楚每一个机制背后的取舍和代价。持久化选型是数据安全和性能之间的平衡主从复制是可用性和一致性之间的平衡集群是扩展性和复杂度之间的平衡淘汰策略是命中率和数据安全之间的平衡。第一件重要的事是不要盲目照搬网上的“最佳实践”。比如网上都建议appendfsync everysec但你如果做的是金融级交易流水缓存每丢失一秒数据都可能造成事故那就必须上always同时用性能测试数据说服团队接受吞吐下降。第二件重要的事是任何方案都要有回退路径。主从切换、集群迁移、缓存降级都要演练过不能只在文档上画架构图。我用模拟故障脚本每隔两周做一次主节点kill演练确保哨兵能在预期时间内切换。第三件是被我忽略过、现在无比重视的是监控。没有监控的Redis跑得再好都是碰运气。至少把内存、连接数、命中率、慢查询、主从延迟、碎片率、哨兵状态这几项盯起来告警阈值宁可先紧后松不要把“Redis还活着”当成唯一标准。我建议任何一个做后端开发的人都以“复习”的方式把这些知识点再过一遍工作三五年以后你会发现当年背下来的东西在真实环境里全都有对应的故事可以讲而那些故事才是真正的经验。
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
