一、版本排查与风险评估
当前运行版本与生命周期状态
在运维日常中，准确获取当前 Redis 版本和生命周期状态是排查的第一步。通过版本号与发布阶段判断是否需要升级以及升级的紧迫性。
具体操作应涵盖对 redis_version、redis_build_id、系统兼容性与生命周期的确认，以便与官方维护策略进行比对，避免落入仍在维护中的版本。
redis-server -v
# 示例输出：Redis server v=7.0.11 sha=00000000:0 malloc=libc-2.31 bits=64 build=abcdef123456
redis-cli INFO server | grep -E 'redis_version|redis_git_sha1|redis_build_id'
同时可以通过系统包管理器查看所部署的包版本，例如 apt-cache policy redis-server 或 yum info redis，以判断是否存在可用的官方修补版本。
apt-cache policy redis-server
风险与合规性分析
版本过时通常伴随安全漏洞、已知缺陷、弃用功能和配置项不再兼容等风险。需要将风险按业务影响划分为低、中、高，并结合演练场景设定升级优先级。
在评估中应关注：已修复的 CVE、内存使用波动、持久化格式变更、ACL/认证行为以及模块兼容性等因素，以便决定是否立即升级或分阶段推进。
grep -i 'CVE-20' /var/log/redis/*.log || true
二、升级前的准备工作
数据备份与故障演练
升级前必须完成完整的数据备份，并且通过演练确认回滚路径。先触发一次可靠的持久化快照，确保在升级后可以无损恢复。
备份的要点包括：RDB、AOF、以及当前内存状态的快照一致性，并在异地签出备份以防单点故障。
# 触发后台 RDB 快照
redis-cli BGSAVE
# 监控直至完成
redis-cli INFO persistence | grep 'rdb_bgsave_in_progress'
# 备份 dump 文件（路径可能因系统而异）
cp /var/lib/redis/dump.rdb /backup/redis/dump-$(date +%F-%H%M%S).rdb
# 如果启用 AOF，可另外备份 aof 文件
cp /var/lib/redis/appendonly.aof /backup/redis/aof-$(date +%F-%H%M%S).aof
兼容性与变更评估
在升级前，必须完成对新版本的兼容性评估，尤其是配置项变化、数据结构变更、模块兼容等风险点。
建议在测试环境中运行💡自动化回归测试、基线性能对比、以及功能健壮性检查，以避免生产环境突发问题。
# 用测试环境对新版本执行基本功能测试
redis-server --test-memory 2
redis-benchmark -n 100000 -t set,get -q
三、升级路径与操作步骤
小版本升级（平滑升级）
对于同一大版本号内的小版本升级，通常可以实现无痛式、滚动式升级，降低系统停机风险。
执行前应确保下游客户端连接数在可控范围，并在升级过程中保持现有副本的写入能力，以实现最小化的数据丢失。
# 更新软件包索引
sudo apt-get update
# 仅升级 redis-server 到最新的小版本
sudo apt-get install --only-upgrade redis-server
# 重启 Redis 服务使改动生效
sudo systemctl restart redis
# 升级后快速验证
redis-cli INFO server | grep 'redis_version'
大版本升级策略
从一个大版本跳到另一个大版本（如 6.x 到 7.x）通常涉及兼容性审查、配置项变更与模块兼容性评估。建议采取“分阶段、分环境”的升级策略，包括在测试环境、预生产环境逐步放开流量。
典型流程包括：在新版本上部署独立实例、数据迁移、功能性对比、以及平滑切换，避免一次性全面切换带来的不可控风险。
# 在新版本上安装并配置一个独立实例（端口与数据目录分离）
# 将旧数据迁移到新实例（RDB/AOF 或近实时的复制关系）
redis-server /etc/redis/redis-7.conf
# 设定主从/主从复制关系，完成数据对齐
redis-cli -p 6380 INFO replication
# 在生产环境进行灰度发布前的回归测试
redis-benchmark -n 500000 -t set,get -q
滚动升级与零停机切换
若需要实现零停机切换，可以采用滚动升级、逐步替换节点、再进行主从切换和流量切换的策略。确保在切换过程中所有副本能保持一致性。
# 将一个节点升至新版本并把流量切换给它
# 假设已有从新版本的副本，逐步提升主节点并切换写入
redis-cli -p 6380 INFO replication
# 将应用的写入指向新主节点，待新主节点稳定后完成最终切换
四、升级后的验证与持续维护
健康与性能验证
升级完成后，进行全面的健康检查与性能基线对比。重点关注 延迟、吞吐、持久化成功率、内存使用和连接数等指标的变化。
为了快速发现潜在问题，可以执行基线对比与回放场景测试，确认新版本在高并发场景下的稳定性。
redis-cli INFO all | grep -E 'redis_version|uptime_in_days|connected_clients|used_memory|rdb_last_load_status'
redis-benchmark -n 1000000 -t set,get -q
持续监控与告警策略
将新版本纳入常态化监控，调整告警阈值以适应新的性能基线。重点关注 内存使用、持久化时延、复制延迟、客户端连接数的变动，并在告警策略中考虑回滚触发条件。
redis-cli INFO all | grep -E 'used_memory|rdb_bgsave_in_progress|late_sync_seconds|master_repl_offset'
