1. 为什么突然要动 Redis 的版本旧版本吃内存、迟迟等不来的新特性先说结论这次升级的起因不是追求新版本漂亮数字而是某个 Redis 数据节点长期运行后内存增长曲线越来越难看哪怕业务量没有明显变化RSS 却一路走高。排查一圈发现内存碎片率在部分实例上稳定在 1.5 以上某些时刻甚至逼近 2.0这基本就是旧版本内存分配器行为保守、碎片整理能力弱导致的典型症状。我这边维护的是一批 Linux 服务器上的 Redis 实例版本一直停在 5.0.x有些甚至还是 4.x 时代遗留的配置。业务方反馈的主要痛点有三类一是上述内存碎片问题二是keys这类危险命令没有真正的治理手段旧版的rename-command配置改起来要动配置文件再重启太粗暴三是官方在 6.x 之后对 ACL、多线程 IO、RESP3 协议等的改进实在眼馋。加上安全公告里陆陆续续提到旧版存在的一些漏洞风险管理层一纸邮件要求限期完成 Redis 版本升级这个任务就落到了我头上。这篇内容不是教你怎么无脑make make install而是把我在实际操作中遇到的坑、做的选型、以及最后稳定运行的经验完整记录下来。直接升级到最新版不一定适合所有人尤其是线上有存量数据、有主从复制、有持久化策略的部署每个环节都可能翻车。如果你也是负责 Linux 服务器上 Redis 维护的工程师或者正准备把零散实例规范化升级这篇应该能帮你省不少时间。适合谁看长期维护 Redis 5.x/6.x、被内存碎片问题困扰、需要平滑升级而不是简单替换、以及想了解新版特性到底值不值得升级的人。2. 升级前必须先搞清楚的三件事版本选型、数据兼容性、回滚预案2.1 版本选型不要盲目追最新先看你的部署形态Redis 官方的版本节奏大致是大版本之间会隔一到两年后续还有补丁版本持续维护。以 5.x 直接跳到 6.x 或者 7.x 为例跨了两个大版本配置文件格式、默认参数、甚至部分命令行为都有变化这个跨度必须认真对待。我的选型思路很简单不选很新的 minor 版本等它发布两三个补丁后再上。比如 6.2 系列相对成熟7.x 系列在内存优化上确实强但对操作系统内核、glibc 版本也有隐藏要求。如果你的服务器还是 CentOS 7 或者老一点的 Ubuntu直接上 7.x 后某些特性比如 io_threads、新的内存分配策略可能发挥不出来甚至可能踩到坑。所以我的建议是存量业务优先考虑 6.2.x 或 7.0.x不要一上来就追 7.2 之后的新大版本除非你有专门的测试环境验证。如果业务场景对内存碎片极其敏感可以考虑 7.x 系列它内部默认启用了更积极的内存碎片整理策略。一定要看官方 Release Notes 里关于操作系统依赖的描述特别是jemalloc版本、glibc的要求。我在测试环境做过一次对照实验同一批数据、同样的 workload5.0.14 和 7.0.12 在内存碎片率指标上后者平均要低 20% 到 30%而且大 key 删除时卡顿明显更轻微。这也是我最终决定跨到 7.x 的核心原因。2.2 数据兼容性RDB 和 AOF 的版本差异很多人升级时最担心的就是数据文件能不能直接读。Redis 在这块的兼容性做得算不错RDB 格式从 5.x 到 7.x 基本可以平滑加载只要不是那种改了底层编码格式的极端场景。但有一个前提准备升级前必须做好一次最新的 RDB 备份和 AOF 重写。实际操作中别只看 RDB 文件能不能加载还要注意以下细节如果你的 AOF 文件是混合持久化模式默认aof-use-rdb-preamble那文件头部会有一个 RDB 格式段新版本读取没问题。但如果你之前手动改过这个参数建议升级前先确认。老版本 RDB 里可能存有一些特殊编码的 key比如带过期时间的、带 module 扩展的虽然新版本理论上都能读但保险起见还是要跑一次redis-check-rdb工具做完整检查。主从复制环境更要注意升级顺序应该是先升级从库观察复制是否正常再逐台切换主库。千万不要想着所有节点一次性全升级Redis 主从之间版本差距过大时部分复制指令可能不兼容导致 SYN 失败。2.3 回滚预案留一条真正能跑通的后路所谓的回滚预案不是你写一句如果出问题装回旧版而是要在动手前就把旧版本的二进制、配置文件、数据目录完整归档下来保证任何一个时刻都能快速恢复。我这次的做法是在升级前对每台实例都打一份 RDB 快照存到一个独立目录保留至少 72 小时。把旧版本 Redis 的编译产物完整拷贝到/opt/redis-backup/而不是只存源码包。配置文件做 git 版本管理每个实例的改动都能追溯。在回滚文档里写明每一步命令特别是主从切换命令的顺序避免紧急情况下手忙脚乱。这里要特别强调回滚预案不是给万一失败准备的而是给升级完一段时间后才发现隐性性能劣化准备的。很多问题不会在升级后五分钟内暴露可能要跑几天才出现那时如果你已经清理了旧版本备份再想回头就晚了。3. 从编译到安装我在 Linux 上完整执行过的升级链路3.1 编译环境检查比想象中更容易踩坑的依赖问题很多人觉得 Redis 编译很简单就是make一下但实际上在较新的 Linux 发行版上缺少gcc、make、pkg-config这些基础工具太常见了。我在某台刚初始化的服务器上就遇到过make报错说找不到cc编译器当时还以为是配置问题查了半天才发现是新机器的开发工具链没装。我整理了一份依赖检查清单可以在编译前一条命令跑完yum groupinstall Development Tools # 或者 Ubuntu 上 apt-get install build-essential之后确认gcc --version、make --version正常即可。如果是 7.x 系列还会用到openssl开发库来编译 TLS 支持这一步很多教程都没提但如果你打算开启 Redis 的 TLS 通信我这边内部网络暂时不启用但考虑到后续安全要求还是加上了编译参数yum install openssl-devel # Ubuntu apt-get install libssl-dev编译命令我用的是make distclean make MALLOCjemalloc -j4 make install PREFIX/usr/local/redis7指定MALLOCjemalloc是有讲究的。Redis 官方推荐用 jemalloc 作为内存分配器因为它对内存碎片控制更好尤其配合 Redis 自身的内存统计和碎片整理功能效果比系统默认的 glibc malloc 要明显。我在 5.x 时代其实也可以用 jemalloc但当时没太在意这个参数导致一直用 libc 分配器内存碎片率高也有一部分这个原因。升级到 7.x 后我特意把MALLOCjemalloc作为标准配置。3.2 配置迁移不要直接复制旧配置文件逐项核对新参数这里是最容易出问题的一环。旧版配置文件直接拿给新版用Redis 会提示大量参数过期或已改名虽然默认情况下不一定报错但会让你的实例实际运行参数和预期不一致。我做了这样一份对照表实际操作时逐一核对的Redis 5.x 参数Redis 7.x 参数注意事项hash-max-zipmap-entrieshash-max-listpack-entries编码名称变了语义类似但默认值不同list-max-ziplist-sizelist-max-listpack-size同样改名protected-mode保留默认值变了必须显式确认appendfsync保留无变化但推荐everysecmaxmemory-policy保留新增强力淘汰策略但旧策略语义不变rename-command保留7.x 更推荐 ACLactiverehashing保留默认仍是 yes有些参数在新版本里已经变成废弃状态比如zset-max-ziplist-entries这类的老编码参数新版会建议你移除。用新版本启动时最好看一眼日志中是否有Warning或deprecated提示逐条处理。我自己核对配置的顺序是先拿旧配置文件redis-server /path/to/old.conf启动新版看启动日志里的 warning 信息。对照官方redis.conf里的默认值搜索每个旧参数的意义。保留那些确实需要的业务配置如内存上限、持久化策略、慢查询日志阈值删除那些已废弃的参数。新的 ACL 相关、IO 线程相关参数先不要动保持默认等实例稳定运行后再评估是否开启。3.3 启动验证从单实例到读流量接入编译完成、配置整理好之后不要急着重启生产实例。先在备用端口上启动一个测试实例比如 6380加载一份生产数据的 RDB 副本验证三件事数据是否完整加载dbsize和源实例是否一致。是否出现 RDB 加载报错如果有立刻停下来排查。简单执行几条业务查询确认连线返回的数据结构和内容与升级前一致。我习惯用以下命令启动测试实例/usr/local/redis7/bin/redis-server /path/to/redis-test.conf --port 6380 --daemonize yes然后对比redis-cli -p 6380 dbsize和原实例的dbsize确认一致后再拿几个代表性的 key 做类型和值对比。这一步通过后才考虑把实例正式切换。4. 主从集群升级顺序从库先行、逐个切换、稳中求快4.1 为什么不能所有节点一起升复制协议兼容性的现实约束Redis 的主从复制虽然设计得非常成熟但跨版本的主从之间尤其是从 5.x 直接跳到 7.x部分内部复制指令和同步机制已经发生了细微变化。如果所有节点同时升级一旦新版本在加载旧数据、重建复制流时出现问题你连个对照样本都没有排查会非常困难。反过来如果先升级从库主库还是旧版你就能直观验证新从库接受旧主库复制流时是否有异常。我这次操作的结构是一个最简单的主从拓扑一个主节点三个从节点其中一个从节点同时作为本地备份节点开着 AOF 和定时 RDB。整个升级顺序是这样的升级第一个从节点启动新版本实例观察主从复制状态是否为up连续观察至少 10 分钟确认master_link_status保持正常。确认数据同步无延迟后再升级第二个从节点、第三个从节点。全部从节点稳定后选择业务低峰期将主节点以redis-cli -p port shutdown方式安全关闭然后从节点自动切换如果配置了哨兵或集群模式或者手动升级原主节点并重新建立复制关系。如果拓扑简单也可以在升级原主节点后让它重新以从库角色挂到某个已升级节点上再根据负载情况切回主库。4.2 复制状态检查别只盯master_link_status还要看偏移量很多人看复制状态只看master_link_status:up就觉得没问题了实际上这只是最基本的一层。如果主从之间的复制偏移量不一致说明同步流还存在未消费的数据此时立刻用这个从库承接读流量可能出现数据缺失。我的检查命令是redis-cli -p port info replication重点看两个值master_repl_offset和slave_repl_offset在稳定状态下应该相等如果在持续追平过程中差值一直在减小也可以接受。另外要关注repl_backlog_active确认 backlog 没有被意外清空。正常观察几分钟内偏移量对平后才算复制链路完全健康。升级第一个从节点时我就遇到过复现偏移量始终差一点的情况仔细查后发现是那条实例的 AOF 重写任务还在执行导致响应变慢复制延迟吞了不少写入。等重写结束后偏移量几秒内就追平了。这个经验提醒我升级窗口要避开 AOF 重写、RDB 保存等重操作。4.3 故障模拟验证这一步很多人偷懒但我强烈建议做一次不要觉得升级完能跑就完事了。我在测试环境专门做了一次故障模拟把新版从库通过redis-cli debug sleep 3模拟阻塞几秒然后查看主从重连是否顺利、复制是否恢复到最新偏移量。这一步能验证新版实例在复制链路异常恢复时的表现避免真出事时才发现重连逻辑有问题。同样的我还模拟了网络闪断直接停掉从库实例再启动观察它重连时是否快速从 backlog 恢复或者触发全量重同步。这一步让我发现新版从库在某些情况下会更快地决定全量重同步如果数据量大这是一个不小的代价因此升级后我调整了复制 backlog 大小repl-backlog-size 256mb这个参数在 5.x 时代我完全没关注过升级到 7.x 后发现默认 1MB 在增量数据较大时很容易触发全量重同步浪费很多带宽和 IO。在线业务中如果重同步频繁主节点的 fork 负担也会增加甚至出现毫秒级卡顿。适当调大 backlog 后这类情况明显减少。5. 升级后必做的三项调优内存分配器、IO 线程、ACL 治理5.1 换个内存分配器视角jemalloc与碎片率的真实改善上面提到我编译时指定了MALLOCjemalloc升级完成后我用info memory观察几个关键指标直接对比升级前后的差异used_memory_rss进程实际占用的物理内存。mem_fragmentation_ratioRSS 与使用内存的比值。used_memory_lua、used_memory_scripts分别对应 Lua 脚本和脚本缓存的占用。在 5.x 时代我维护的实例中mem_fragmentation_ratio经常在 1.5 上下波动偶尔接近 2.0升级到 7.x 并指定 jemalloc 后相同业务负载下这个值降到了 1.1 到 1.3 之间。内存碎片问题改善的另一个直观表现是原先定期需要重启来回收内存的实例现在连续运行一个多月 RSS 增长也很平缓。原因在于 jemalloc 对 Redis 这种大量小对象、高频分配释放的负载更友好它会按大小类管理 chunk减少外部碎片。同时 7.x 内置的自动碎片整理不再像旧版那样保守它周期性尝试将数据重新紧凑排列但这个过程本身也消耗 CPU所以在低峰期开启比较合适。我这边没有在高峰期刻意调整activedefrag参数而是让它保持默认节奏触发。5.2 IO 线程开启前先评估你的瓶颈是 CPU 还是网络Redis 6.0 引入的 IO 线程一直是大家关注的亮点但并不是所有场景都适合开启。它的作用是让网络 IO 的读写操作分摊到多个线程减少主线程在收发数据上的时间占用从而提升整体吞吐。如果你的瓶颈本来就不在 CPU而是在网络带宽、或者大量的慢查询上开 IO 线程帮助有限反而可能引入额外的上下文切换开销。我的判断方法是先跑redis-cli --latency和redis-cli --stat观察当前实例平均时延和 QPS。如果 QPS 很高几万甚至十万以上且 CPU 时间主要消耗在sys上说明有部分网络收发开销可以尝试交给 IO 线程。如果本身 QPS 不高追求低延迟最好不要开太多 IO 线程保持默认的io-threads 1。我这边几台核心业务实例在调整前 CPU 使用率已经接近 80%单实例 QPS 能稳定在 5 万以上。我把io-threads调整到 4 后整体吞吐确实涨了约 20%但时延分布也略微变宽。后来根据机器 CPU 核数16 核把io-threads保持为 4、并开启io-threads-do-reads yes才算达到接受的效果。建议你也先小流量观察几天不要一次性配置得太激进。配置示例io-threads 4 io-threads-do-reads yes注意io-threads超过 1 后执行redis-benchmark等工具测试时结果可能比实际生产场景更乐观因为测试工具本身可能没有模拟真实的并发层次要结合线上指标看结论。5.3 ACL比rename-command优雅得多的权限治理方式升级前我清理危险命令基本靠rename-command把keys、flushall改名成一串随机字符串然后业务侧就很痛苦运维排查时想看一眼 key 分布还得翻配置。新版 Redis 的 ACL 机制彻底解决了这个痛点它可以把命令权限精确到用户级别业务账号和运维账号分开。我做的第一件事就是把默认用户设置为只能执行常规命令并单独创建管理用户redis-cli -p 6379 ACL SETUSER default off ACL SETUSER admin on StrongPassword123 allkeys allcommands ACL SETUSER readonly on ReadonlyUser456 ~* read connection然后通过ACL SAVE把规则持久化到配置文件。升级后业务侧客户端如果还想着执行keys会直接收到权限错误排障时很容易识别而运维此刻用管理用户则可以按需开启临时权限。这些小改动在 5.x 时代想做都不太方便升级后是一次比较明显的体验提升。6. 升级后踩到的实际坑与排查过程全记录6.1 坑一AOF 文件格式变更触发的兼容性警告我第一台从库升级完成后启动时日志里出现了一条警告提示 AOF 文件头部包含旧的 RDB preamble新版本可以处理但建议在下次重写时刷新格式。我一开始没当回事但后来发现这台实例的 AOF 文件在每次重写之后体积都比别的实例要大一些。深入排查后才发现旧版本生成 RDB preamble 时某些元数据字段填充方式不同新版重写时会重新生成一份更干净的头部但中间的转换过程会带来额外的临时文件占用。解决办法很简单在低峰期手动执行一次bgrewriteaof让新版本重写整个 AOF 文件即可。命令执行后观察日志确认没有报错AOF 文件恢复正常大小。经验是所有节点升级完成后统一安排一次 AOF 重写可以一次性消除这类残留差异。6.2 坑二maxmemory策略在 7.x 下的行为差异我有一台实例配置的是maxmemory-policy allkeys-lru升级后发现缓存命中率在某个时段出现轻微下降排查半天才意识到是 7.x 对 LRU 采样的默认实现做了调整采样池变大后淘汰更精准但也更敏感。数据量不变、访问模式稍变时淘汰行为可能和旧版不同。这种情况没有对错之分关键是业务方要先知道升级后淘汰策略的实际行为变化。我的处理方式是先用redis-cli config get maxmemory-policy确认策略仍是我想要的。用info stats里的evicted_keys对比升级前后同时间段的淘汰数量趋势。如果淘汰量明显增大优先检查近期业务访问模式是否变化不要一上来就调采样参数。这类隐性差异通过日志和监控指标更容易定位而不是凭感觉调参。6.3 坑三系统 OOM 风险排查与overcommit_memory的老问题重提升级后我习惯性地检查了一下vm.overcommit_memory发现有几台机器这个参数居然还是 0这意味着 Redis 在做fork持久化时系统可能因为内存不足直接杀掉 Redis 进程。新版 Redis 在启动日志里会明确建议你设置成 1但很多人忽略了这个提示。我统一调整的方式sysctl -w vm.overcommit_memory1 echo vm.overcommit_memory1 /etc/sysctl.conf另外还检查了transparent_hugepage它会让 Redis 在 fork 时出现明显的延迟尖刺需要关闭echo never /sys/kernel/mm/transparent_hugepage/enabled这两项都属于老生常谈但确实影响稳定性的系统级优化升级后顺手处理一遍能省掉未来很多莫名其妙的故障。7. 实战验证数据升级后一周的内存表现对比这里给一组我在真实部署中的统计数字虽然不是非常庞大的集群但足够说明趋势变化。对比的对象是同一批业务实例升级前运行 5.0.14升级后运行 7.0.12业务流量模型基本一致。指标升级前5.0.14升级后7.0.12变化内存碎片率mem_fragmentation_ratio均值1.521.18降低约 22%单实例 QPS 峰值4.8 万6.1 万提升约 27%keyspace_hits命中率98.2%98.6%略有提升时延 p992.8ms2.1ms改善明显周内重启次数2 次因内存碎片过高手动重启0 次显著改善强调一下QPS 提升不完全只是版本升级的功劳也和 IO 线程开启、内存碎片改善有一定关系。真正让我放心的其实不是性能数字而是那台曾经每周要重启一次的实例升级后连续运行了 20 多天RSS 增长始终非常缓慢内存碎片指标也稳定在健康水平这才是这次升级最大的收益。8. 最后的个人体会与几点忠告这次升级做下来我的感受是Redis 版本升级不是单纯的二进制替换而是一次对部署架构、内存使用策略、权限模型和系统底座的综合检查。它逼着我把很多以前忽略的隐性配置彻底看了一遍不只是为了升版本而升版本。如果让我总结几个最重要的经验大概是这些先做小范围验证再大规模铺开。单实例先跑几天比盲目全量替换稳得多。升级前后一定要有完整的监控数据记录否则你根本不知道升级到底改进了什么、带来了什么回退。配置文件迁移不是复制粘贴新版参数的变化值得花时间逐项核对。ACL 和rename-command的体验差距很大尽快切到 ACL。系统级优化overcommit_memory、transparent_hugepage、jemalloc往往比版本号本身更影响稳定性。最后再分享一个小技巧升级完成后我习惯跑一次redis-cli info保存全量指标然后在运行一周后再次保存一份对比evicted_keys、rejected_connections、内存碎片率这些值得长期关注的指标。如果你能坚持做这个对比下一次再升级任何组件时你的判断依据就会扎实很多而不只是感觉快了、感觉稳定了。