1. 为什么值得专门花时间梳理Redis各版本演进如果你们的业务还在跑Redis 2.8甚至3.0或者刚从单机主从切换到集群模式那你对这篇文章的需求应该很直接搞清楚从Redis 2.6到Redis 7.0之间每一次大版本更新到底带来了什么、改变了什么、又埋了什么坑。这个版本区间跨度很大几乎覆盖了Redis从“缓存工具”变成“数据基础设施”的完整过程。我见过不少团队因为版本太老遇到问题只能靠重启、换机器、堆内存来硬扛也见过团队升级到新版本后把过去用脚本拼凑的功能直接用原生特性替代运维成本降了一大截。把这些版本变化整理成一条线意义不在于背版本号而在于知道每一版解决了什么底层问题哪些新能力可以改善现有架构哪些“新特性”其实会导致意想不到的兼容性问题。这篇文章适合正在做Redis版本升级选型的人也适合接手了老旧Redis实例、想快速判断哪些特性值得用的运维和开发。我会按版本线梳理重点讲清每个版本的关键变更、适用场景、以及我在实际操作中遇到的坑。即使你只是写业务代码把这些版本演进背后的“为什么”搞明白和同事聊方案的时候也更有底气。需要提前说明这不是官方文档的逐字翻译。我关注的是三条主线内存与持久化、高可用与复制、数据结构的丰富度。另外还有近几个版本里明显加强的管理能力比如ACL、多线程IO和可编程性。抓住这些主线版本号对你来说就只是时间戳了。2. 版本演进主线条从脚本到集群再到现代数据服务2.1 Redis 2.6脚本能力与监控管理的补课2.6版本典型的“补课”版本。在此之前Redis要完成“读-改-写”的原子操作只能靠单个命令配合MULTI/EXEC事务。但事务能做到原子性却很难处理条件判断和级联更新。比如你要实现一个分布式限流器先读当前计数判断是否超阈值再决定是否自增这种逻辑用事务写起来很别扭。2.6带来的Lua脚本支持允许你把一串操作打包成一段服务端脚本用EVAL或EVALSHA执行。脚本在Redis内部是原子的中间不会被其他客户端命令插入这就给复杂业务逻辑提供了非常顺手的实现方式。Lua脚本虽好但它有个天然缺陷脚本执行期间Redis主线程被占用其他所有命令都在排队。我遇到过把耗时循环、正则匹配、甚至JSON解析写进Lua的案例一条脚本能跑几百毫秒直接把实例的p99延迟打崩。所以2.6同时引入慢查询日志SLOWLOG非常关键。你可以在redis.conf里设置slowlog-log-slower-than单位是微秒默认10000。线上排查卡顿的时候先执行SLOWLOG GET 10看看有没有异常耗时命令比乱抓包效率高很多。还有一点从2.6开始过期精度从秒变为毫秒缓存过期策略可以做得更精细比如热点数据错峰过期不再只能精确到秒级。2.6还让字符串数据变成真正的二进制安全BITCOUNT、BITOP等位图命令也完备了。位图在做日活统计、在线状态跟踪时非常节省内存。虽然这些单点功能看着不大但把基础夯实了后续的很多玩法才有落地的可能性。2.2 Redis 2.8哨兵与增量同步把高可用落地2.8版本有两个影响深远的特性PSYNC部分同步和Sentinel哨兵的成熟。先说PSYNC。Redis主从复制在2.8之前只有全量重同步从节点和主节点只要断线重连主库就要生成一份完整的RDB快照传给从库。数据量小的时候还能忍数据上了几十GB甚至上百GBfork操作会消耗大量内存和CPU传输过程还会把带宽打满。从库恢复期间也不能正常对外提供读服务。PSYNC通过复制积压缓冲区backlog记录最近执行的写命令从节点重连后带上自己的复制偏移量主库只要判断偏移量还在backlog范围内就只把增量部分补发给从节点。这个改动非常实用我过去处理过不少主从不同步问题升级到2.8以上之后很多断线场景都能自动续传不用再全量拷贝。Sentinel则是把高可用从“手动”变成“自动”。单体主从方案最头痛的就是主库突然挂掉业务写入直接失败。2.8之前的Sentinel不稳定很多团队不敢在生产用2.8之后基本达到了生产可用。Sentinel会持续监控主从节点状态主库被判定为客观下线后会在从节点里选举一个新主库并通知客户端切换地址。但这不意味着数据零丢失主库宕机瞬间的少量写命令仍可能丢失。我通常给团队强调的是Sentinel解决的是服务连续性持久性还是要靠备份机制兜底两者不能混为一谈。2.8还有一个容易被忽略但很救命的功能SCAN系列命令。旧版想遍历所有key只能用KEYS线上一个实例几千万个key一次KEYS就会把Redis阻塞好几秒。SCAN使用游标迭代每次返回少量key并且通过COUNT参数控制单次扫描数量。我现在看到任何人写代码用KEYS都会下意识提醒他改成SCAN除非你确定实例里只有几百个key。2.3 Redis 3.0与3.2集群化与地理位置能力的成熟3.0的核心是Redis Cluster。它把整个key空间切成16384个哈希槽槽被分配到一个或多个主节点上每个主节点可以带从节点。客户端计算key的CRC16值并对16384取模得到槽位后决定请求到哪个节点。如果请求发到了不含该槽的节点节点会返回MOVED错误并告知正确的节点地址客户端据此更新路由缓存。这样的设计让Redis从单机内存数据库真正变成了可以横向扩展的分布式存储。Cluster给运维带来的最大变化是“分片”不用手动做了。以前数据量一到瓶颈就得搞多个独立实例然后按业务拆分客户端还要自己维护路由逻辑非常痛苦。Cluster把不同key分布在多个主节点上即使某个主节点挂掉它下面的从节点也可以被提升为新的主节点数据面故障转移变得自动。不过Cluster也有不少限制。最典型的是多key操作要求所有key的哈希槽一致也就是key里要包含相同的哈希标签比如{user:1000}name和{user:1000}age这样它们才会落到同一个槽。这几乎是每个从单机迁移到Cluster的团队都会踩的坑要么事务失效要么Lua脚本报错CROSSSLOT。3.2版本的重量级功能是GEO地理位置。它底层是用有序集合Zset加经纬度编码实现的对外暴露GEOADD、GEORADIUS、GEOPOS等命令。做附近的人、门店检索、派单距离计算这类功能时可以直接用Redis完成省掉额外引入空间索引组件。3.2还重构了列表类型的底层结构引入quicklist来替代旧的ziplist和linkedlist搭配方案。quicklist本质上由多段压缩链表组成既减少了内存碎片又保留了高效的顺序访问。对于列表长度变化大的业务这个改进明显更友好。2.4 Redis 4.0模块化、删除不阻塞与混合持久化4.0是我个人认为现代Redis真正成型的版本。它做了四个非常重要的改变模块系统、异步删除、内存碎片整理、混合持久化。模块系统是Redis第一次开放给C语言扩展的能力。开发者可以通过插件给Redis增加新命令、新数据结构甚至新的存储引擎。社区基于它做了布隆过滤器、倒排索引、时序数据模块等重要扩展。模块确实强大但也意味着稳定性风险一个不成熟的模块可能导致内存泄漏甚至崩溃。我的建议是优先选择官方维护或生产环境验证充分的模块并且一定要在压测环境里验证后再上生产。异步删除是运维同学的福音。过去对一个包含上百万元素的大集合执行DEL命令主线程需要逐个释放节点内存这段时间里整个实例就像卡住了一样。4.0引入UNLINK它先把key从键空间解除引用真正回收内存交给后台进程处理FLUSHDB和FLUSHALL也支持ASYNC参数。这解决了大key清理的阻塞问题。我后来处理线上数据清理任务一律使用UNLINK不再碰DEL。同时4.0引入了内存碎片整理功能可以通过activedefrag配置开启自动整理。但开启前要谨慎它对glibc内存分配器的行为有一定依赖建议先做AB对比观察对latency的影响。混合持久化是个很实在的进步。之前的持久化要么用RDB快照恢复快但可能会丢失最近几分钟的数据要么用AOF日志数据完整但重放耗时很长。4.0支持在AOF文件头部先写一份RDB快照再追加增量的AOF日志。重启时先加载RDB再回放少量增量既快又不容易丢数据。对追求快速故障恢复的系统这个模式几乎是首选。另外4.0还增强了PSYNC能够在故障切换后尽量利用backlog做部分重同步而不是让新主库被从库们拉全量。这个优化在主从规模大时效果特别明显。2.5 Redis 5.0Stream解决了消息队列的经典之争5.0版本的绝对主角是Stream数据结构。在它之前用Redis做消息队列一直很拧巴。用List做队列LPUSH/BRPOP简单直接但缺少消息确认和消费组的概念消费者如果中途崩溃消息就丢了or重复消费很难管理。用Pub/Sub做实时广播延迟很低但消息不持久客户端断线期间的消息直接错过。Stream把这两种场景融合了它像一份只追加的日志文件每条消息都有唯一ID支持消费者组消息可以被多个消费者并行处理处理完需要XACK确认万一消费者挂了可以从XPENDING里找到未确认消息重新消费。实际使用中Stream完全可以替代一部分轻量消息队列。我在内部做过一个通知系统用XGROUP CREATE通知消费组多个消费者实例通过XREADGROUP读取属于自己的消息处理完成后XACK。客户端崩溃时通过XAUTOCLAIM重新认领超时的消息。这套方案极大减少了外部中间件的依赖消息还能落盘重启不丢。当然Stream不是万能的复杂路由、延迟队列、消息回滚等场景还需要专业消息队列。但在大多数“队列持久化消费组”的需求里Stream已经够了。5.0也对集群运维工具做了大量完善。redis-cli增加了--cluster子命令创建集群、检查槽位分配、在线reshard扩容缩容都可以直接命令行操作比过去手工脚本靠谱很多。此外有序集合增加了ZPOPMIN等命令HyperLogLog和Bitmap也有不少细节优化。整体来看5.0是介于4.0和6.0之间很平稳的一版适合所谓“保守型升级”的团队。2.6 Redis 6.0与6.2多线程IO、ACL和RESP3是分水岭6.0把管理工作又往上抬了一层。第一个让人关注的是多线程IO。注意Redis的命令执行依然是单线程多线程只用于网络数据的读写和协议解析也就是说真正执行命令的部分仍然是一个主线程串行处理。这样做的好处是能利用多核CPU处理海量连接的收发数据包但又不会破坏主线程内部的无锁特性。官方默认是关闭的因为连接数少时未必有收益。如果连接数很高并且能明显观察到协议解析占用了较多CPU可以在redis.conf里设置io-threads 4然后用基准工具对比吞吐量。不过别一上来就盲目开锁竞争和缓存失效在特定场景可能反而变慢。ACL是6.0给运维带来的大礼物。之前的Redis只有requirepass一个密码登录后就是超级权限可执行所有命令。ACL允许为不同用户配置不同权限可以限制能执行的命令和能访问的key前缀。比如只给某个报表程序开放“读cache:”和“写cache:”的权限不允许执行FLUSHALL、EVAL、CONFIG这些命令。这个能力在多人共用一个Redis实例时尤其重要。很多线上事故其实不是外部攻击而是内部误操作ACL把这些风险大幅降低。6.0还支持RESP3协议它提供了服务端主动推送的能力配合客户端缓存Client Side Caching可以让客户端把热点数据缓存到本地服务端在数据变化时通过失效消息通知客户端清理缓存。这个机制能明显减少读多写少场景下的网络开销但要注意RESP3需要新版客户端库支持升级时要先确认客户端版本。6.2版本虽然不算大版本但补了很多细腻的能力。它新增了GETDEL、SMISMEMBER、BLMPOP等命令让一些常见操作更原子或者更批量CLIENT LIST支持过滤字段便于排查连接来源发布订阅和阻塞命令的权限控制也更细。6.2更像是一个“稳定性和体验打磨”版本很多长期跑在6.0线上的团队会优先选择6.2作为生产基准版本。2.7 Redis 7.0函数、AOF重构与运维体验再升级7.0是目前Redis系列里最新的一个大版本它围绕“可编程性”和“持久化工程”做了大量改造。先说Redis Functions。过去Lua脚本虽然好用但脚本是零散存在的不同的业务脚本逻辑如果想复用公共函数只能到处复制粘贴集群环境下维护难度更大。Functions让脚本以“函数库”的形式注册到Redis服务端可以像存储过程一样被调用带参数、带权限校验并且适合在集群多个节点间统一管理。这对于把业务规则下沉到服务端的场景价值非常直接。持久化方面7.0重构了AOF重写机制提出Multi-part AOF。旧版的AOF重写过程里父进程和子进程可能因为共享文件描述符、写时复制页表等产生额外内存开销重写大文件时还是会扰动主线程。新的AOF把文件拆成多个片段重写过程更轻量也减少了对主线程的干扰。同时7.0增加了更多的持久化校验和故障恢复细节比如RDB文件的校验强度更高。集群方面也优化了节点故障后的数据追赶流程尽量避免不必要的全量复制。还有一个小命令值得提SINTERCARD它是集合交集命令的增强版只统计交集个数而不返回交集元素处理大型集合的基数统计场景时非常快。如果是从老版本迁移到7.0新项目可以直接用老项目则需要先确认客户端库和驱动是否完全兼容。整体来说7.0更像面向未来的基础设施版本适合新项目或有计划系统性升级的团队。3. 核心细节解析与实操要点3.1 持久化机制演进RDB、AOF、混合与Multi-part持久化是整个Redis稳定性的地基。我见过很多团队把appendonly yes当成标准配置却不知道不同版本的持久化策略差异很大。旧版本RDB就是全量快照通过fork子进程把内存状态序列化成dump.rdb恢复速度快但可能丢最近几分钟的数据AOF则把每次写命令追加到文件恢复时全量回放能丢的数据量取决于fsync策略。4.0开始支持的混合持久化相当于在AOF文件头部存一份RDB快照后面再追加增量日志也就是说恢复时先加载快照再回放增量速度和完整性都有保障。7.0的Multi-part AOF把重写过程拆得更细进一步降低了父进程参与重写的负担。实际操作中我给业务定配置都是按数据等级来分。纯缓存、允许丢失那甚至可以不开持久化减少磁盘IO对延迟的影响。核心业务、不允许丢重要数据就必须开启appendonly yes同时配置appendfsync everysec而不是always。everysec极端情况下也可能丢一秒数据但换来的是高吞吐always数据最安全但每次写都强制刷盘性能下降明显。选型看业务对数据丢失的容忍度没有绝对正确的配置。每次升版本前必须做一次持久化文件恢复演练。做法很简单在测试环境写入一批有规律的数据然后直接kill -9模拟宕机重启后用INFO persistence和redis-check-rdb/redis-check-aof检查文件状态对比恢复后key数量和数据完整性。我踩过一次坑线上从3.2升到4.0后直接加载旧RDB没问题但旧版本Redis加载新版本生成的混合AOF却报错所以升级方向必须是低版本往高版本单向走降级随时可能踩兼容性雷。3.2 复制与高可用PSYNC、Sentinel、Cluster三者怎么选很多新手会把主从复制、Sentinel和Cluster混为一谈。用工作分工来理解会简单主从复制是数据备份从节点同步主节点的写操作保证主挂了有热备份Sentinel是监控和故障转移组件观察主从关系主挂了自动提升一个从节点Cluster则是分布式分片架构天然多主多从自带故障转移和槽位路由不需要再额外配Sentinel。选择方案时我建议按数据规模和服务等级来。如果单机内存都够用核心诉求是“主挂了要能自动切换”那就用一主多从Sentinel配置简单运维清晰。如果单机容量和并发已经到顶必须把数据分散到多台机器那就走Cluster让槽位自动分布和迁移。Cluster虽然运维门槛高一些但能突破单机资源上限。无论哪种方案都要保证主节点有至少一个健康的从节点。因为发生故障转移时从节点要晋升为主节点如果它数据落后太多会导致大量写命令丢失。主从同步的效率还和repl-backlog-size直接相关。这个参数是复制积压缓冲区大小默认只有1MB写入频率高的实例很快就会把旧内容挤出缓冲区一旦从节点断线时间稍长偏移量不在区间内就只能全量重同步。建议根据峰值写速率乘以预期的网络中断容忍时间来设置。比如高峰期每秒写入100KB想容忍10秒断线那就至少设置1MB以上稳妥点给64MB也常见。设置过大会额外浪费内存太小又起不到作用可以用CONFIG SET动态调整完观察再写进配置文件固定下来。3.3 数据结构底层的版本迭代与使用注意Redis对外暴露的数据结构相对稳定但底层编码在不断变化。例如早期列表用ziplist和linkedlist3.2之后改成quicklist集合和哈希在元素数量少、元素长度短时使用紧凑编码超过阈值后会转成hashtable有序集合则用ziplist和skiplist的组合。业务代码通常不需要关心编码但运维排查时需要会用OBJECT ENCODING命令查看某个key的实际编码这能帮助判断内存是否浪费在低效结构上。我印象最深的问题是“大key”处理。曾经有个业务在Redis里塞了一个包含上百万条记录的list再用LRANGE做分段读取结果每次读取都会阻塞Redis数十毫秒甚至上百毫秒。后来把单key拆成多个小key或者干脆换成Stream阻塞问题立刻消失。所以大key检查应该成为常规巡检内容定时用SCAN遍历所有key并根据key类型执行HLEN、LLEN、SCARD等操作当长度超过阈值就告警。不要用KEYS不要在主节点全量遍历更不要在线上直接执行LRANGE 0 -1。还有一个关于过期策略的细节Redis过期key清理是惰性和周期两种方式结合。如果大量key在同一时间过期主线程的清理压力会很大导致延迟抖动。实践中我习惯给key的过期时间加上一个随机偏差比如在基础过期时间上增加[0, 30]秒的随机数把集中过期打散。这个技巧在2.6时期就存在但真正值得严格执行是在缓存雪崩频发的业务中。3.4 性能优化从单线程到多线程IO的边界在哪Redis的单线程模型使它在并发场景下的延迟非常稳定也消除了锁竞争。但同样是因为单线程任何O(N)复杂度的命令都会拖慢整个实例。6.0引入多线程IO后这种状况并没有彻底改变多线程只负责网络包的收发和解码真正的命令执行仍然在单线程里串行。所以命令本身的复杂度才是性能的核心瓶颈。我见过几个典型的性能杀手SMEMBERS读取超大集合的全体成员SUNIONSTORE生成一个超大的新集合SORT命令做复杂排序KEYS做全量匹配HGETALL读取超大哈希的所有字段。遇到这些场景能分批就分批能改数据结构就改数据结构。比如排行榜可以用ZSET范围读取用ZRANGEBYSCORE不要用ZREVRANGE 0 -1取全量。再比如一些统计类需求用HyperLogLog代替SET可以大大压缩内存。开启多线程IO之前先确认瓶颈是不是网络协议解析。怎么判断用redis-cli --stat观察请求速率和延迟再用系统工具看CPU分布。如果多个连接都在等待写入业务侧CPU不高Redis进程CPU也不高但吞吐上不去那很可能就是网络读写占用了太多单线程时间。设置io-threads 4并重启后对比P99和吞吐再决定去留。核心原则是默认设置不要乱动实际压测数据说了算。4. 常见问题与排查技巧实录4.1 老版本升级到新版本的兼容性清单升级Redis版本最大的风险不是Redis本身而是业务代码和客户端库的兼容性。6.0引入ACL后如果你之前只配置了requirepass升级后会发现默认用户的行为有变化尤其是某些老客户端在AUTH后依然拥有全部权限但如果你配置了ACL规则旧连接可能会因为权限不足而报错。建议升级前把所有客户端统一到支持RESP3或至少支持ACL的新版本。命令层面有不少变化需要回归。旧脚本里如果大量使用KEYS升级后要改成SCAN阻塞操作如BLPOP/BRPOP在6.0之后对权限控制更敏感Lua脚本在7.0之后推荐迁移到Functions但这不是强制老脚本还能运行。数据结构编码在不同版本之间也可能变化升级后内存占用可能出现波动这属于正常现象但要监控碎片率。RDB/AOF文件的兼容性是方向性问题。低版本Redis加载高版本生成的文件可能直接失败高版本加载低版本文件通常没问题。所以线上升级时先备份好当前RDB和AOF再让新版本以从库方式追平主库数据最后再切换写流量这个过程能最大程度降低风险。注意从2.8跳4.0再跳7.0文件格式有两道变化中间版本的过渡步骤不能省。4.2 在线上如何快速识别当前版本和关键配置排查任何Redis问题第一步一定是确认版本和运行状态。连接redis-server后执行INFO server可以很快看到redis_version、uptime_in_seconds等信息。接着看INFO replication检查主从角色和master_link_status如果显示down说明同步链路已经断开。再看INFO memory关注used_memory_human、mem_fragmentation_ratio、maxmemory_policy这些指标。慢命令的排查用SLOWLOG GET N是最高效的手段。它能直接列出最近N条超过慢日志阈值的命令并显示耗时微秒数。我发现很多延迟问题不是网络慢而是某个热点命令执行时间特别长。比如一个SORT命令可能跑几十毫秒在低QPS下感觉不出来但在高并发下就会把事件循环拖住。如果内存增长异常除了看used_memory还要用MEMORY DOCTOR给出诊断建议4.0。它有时代入官方默认阈值对某些高分配场景会误报但用来做初筛很有参考价值。结合INFO keyspace看key总数再配合SCAN脚本统计各类型key的数量基本上就能定位内存是大key造成的还是过期key堆积造成的。4.3 大key删除、碎片和内存问题三板斧线上最常见的内存问题分三类大key没被清理、内存碎片率高、过期key堆积。大key删除绝对不能再用DEL要用UNLINKUNLINK能异步回收内存不会阻塞主线程。如果实例中有多个超大key可以写一个SCAN脚本分批找到它们逐个转成UNLINK操作。注意UNLINK也不是完全没有风险它释放内存的后台线程也会消耗IO和CPU最好在业务低峰期执行。碎片率可以用INFO memory里的mem_fragmentation_ratio查看。正常在1.0到1.5之间超过1.8就值得关注。4.0开始的activedefrag yes可以自动整理碎片但它会带来额外的CPU开销如果对延迟很敏感建议在低峰期临时开启做完后关闭。如果碎片问题长期存在不妨考虑重启实例来重置内存布局但一定要先做好主从切换和持久化备份。过期key堆积也是个隐性问题。Redis删除过期key是惰性加周期删除如果大量key的TTL很长或者根本没有设置TTL内存会持续增长。排查时用SCAN遍历key看TTL为-1的key占比同时找业务方确认哪些key应当设置过期时间。另外可以调整过期扫描频率但我不建议太小否则清理滞后更明显。4.4 版本升级后容易忽视的配置差异升级后的配置并非都能原样继承。比如2.8时代maxmemory-policy可能用的是volatile-lru4.0以后新增allkeys-lfu如果你已经在用LFU淘汰但实例还开着老配置内存回收就可能不符合预期。再比如io-threads参数只存在于6.0以上老配置里没有这个项不会报错但你要明确它有默认关闭状态。还有慢日志阈值、repl-backlog-size、proto-max-bulk-len这些参数每个版本默认值可能不同。升级前后最好用CONFIG GET把关键配置导出一份然后和新版本默认值做diff除了主动修改过的项其他不建议沿用旧值。我遇到过的一件事旧实例为了业务把hash-max-ziplist-entries调得特别大升级后因为编码阈值变化小哈希占用的内存反而上升了。这类细节只有通过对比配置和观察内存指标才能发现。5. 版本选型与升级路径建议5.1 新项目直接选哪个版本如果是新项目我建议直接选当前最新的稳定大版本现在就是7.0.x。这不仅是“新就一定好”的心态而是因为ACL、Functions、Multi-part AOF这些能力未来会成为标准从老版本起步会欠技术债。当然如果团队对Redis的运维经验不足也可以选6.2.x它经过了大量生产验证社区资料也多风险更低。2.8、3.2这类版本只适合“还在跑、又不能马上动”的历史项目新系统不要往旧版本里扎。新项目选型时还要看客户端库。7.0的RESP3和客户端缓存需要新客户端支持如果你用的驱动太旧可能享受不到这些新能力。所以选版本之前先查你所用编程语言的Redis客户端最新版本确认它支持哪些RESP3能力。如果客户端不支持那7.0很多优势会打折这时候选6.2反而更务实。5.2 老项目如何制定升级路线老项目升级千万不要一步跨太大。从2.8直接升到7.0风险和改动量都差不多等于重构系统。建议按里程碑切分2.8先升到3.2掌握集群和GEO能力再从3.2升到4.0引入异步删除和混合持久化稳定运行后再考虑6.2和7.0。每次升级只跨一两个大版本逐步验证兼容性一旦出问题可以快速回滚。每个里程碑都做好预案。回滚不是简单换回旧版本就行因为新版本可能已经写入旧版本无法读取的数据所以升级前必须先备份并在升级后保持旧版本二进制留档一段时间。如果升级后发现严重问题且新版本已经产生新格式文件传统的“降级”就不会安全必须从备份恢复。5.3 上线前的回归用例要覆盖哪些点最后给一份我多年升级过程中沉淀的回归清单覆盖了大多数问题第一基础读写与过期。验证String、Hash、List、Set、Zset五种基础类型的写入、读取、删除和过期功能。第二多key操作与事务。确认MSET、MGET、事务MULTI/EXEC、WATCH在目标版本或集群环境中是否按预期工作。第三Lua脚本与函数。如果涉及EVAL/EVALSHA升级后必须重跑脚本逻辑7.0还应验证Functions的注册和调用。第四消息队列场景。如果用到Stream重点测试消费者组的创建、消费、确认、pending重试。第五集群与故障转移。在测试集群里做一次主节点宕机演练观察从节点能否自动晋升、槽位是否重分配。第六持久化恢复。备份RDB和AOF用新版本启动并加载文件对比数据完整性。第七慢命令和大key扫查。升级后用之前提到的方法做全面检查确保没有隐藏的大key问题。按这个清单走即使不能保证100%无雷但至少能把99%的升级兼容性问题拦截在上线之前。我在实际升级过程中反复感受到一件事Redis版本升级最坑的往往不是命令不兼容而是“老思维兼容”。很多团队明明升到了新版本还在用老办法写缓存、删大key、拼消息队列。所以整理这份版本脉络不只是为了知道Redis的变化更是为了提醒自己基础设施在进步我们手里的工具也该跟着换代了。
