Amazon  ElastiCache  蓝绿升级方案

1.1 升级需求

随着业务的发展和技术的迭代，ElastiCache部分版本(如：Redis OSS 5)已经不能满足业务对性能、安全性和新特性的需求，升级Redis的版本成为必然。ElastiCache for Redis OSS 6.2.6 版本引入了许多重要改进，同时为后续升级到 Redis 7.x 和 Valkey 引擎做好准备，包括但不限于：

• 客户端缓存功能，显著提升读取性能
• ACL（访问控制列表）增强安全性
• 改进的集群管理功能
• 更高效的内存使用和性能优化
• 多项 Bug 修复和稳定性改进
• 为 Redis 7.x 的 Functions 和 Sharded Pub/Sub 特性奠定基础
• 兼容 Valkey 引擎的多线程 I/O 和改进的内存管理
• 支持未来 Redis 7.x 的 ACL 增强功能和 RESP3 协议

1.2 挑战与风险

ElastiCache for Redis OSS 作为核心数据存储服务，其升级面临以下挑战：

• 服务连续性：升级过程中需要保证业务服务不中断
• 数据完整性：确保所有数据在迁移过程中不丢失、不损坏
• 性能影响：数据同步过程可能对源 ElastiCache for Redis OSS 实例性能产生影响
• 回滚能力：在升级失败时能够快速回滚到原始状态
• 兼容性问题：新版本可能存在的 API 兼容性问题

1.3 蓝绿部署策略选择

考虑到上述挑战，选择采用蓝绿部署策略进行 ElastiCache for Redis OSS 升级成为必然：

• 最小化风险：通过在生产环境外构建和验证新版本，降低对生产环境的影响
• 灵活切换：可以在蓝色（旧版本）和绿色（新版本）之间快速切换
• 简化回滚：如果发现问题，可以立即切换回蓝色环境
• 充分测试：在切换流量前，可以全面验证绿色环境的功能和性能

2. 架构设计

2.1 蓝绿部署架构与组件说明

架构图

说明：

• 蓝色集群：现有 ElastiCache for Redis OSS 集群（旧版本），地址是redis-blue.abcdef.ng.0001.use1.cache.amazonaws.com:6379
• 绿色集群：新 ElastiCache for Redis OSS 集群（新版本），地址是redis-green.abcdef.ng.0001.use1.cache.amazonaws.com:6379

Redis-Shake

Redis-Shake 是一个开源的高性能 Redis 数据迁移工具，用于 ElastiCache for Redis OSS 数据同步，具有以下优势：

• 支持全量和增量同步
• 高效的数据传输机制
• 丰富的过滤和转换功能
• 实时监控和状态报告
• 支持多种 Redis 部署模式（单机、集群、哨兵）

⚠️ 重要提示：ElastiCache 需要开通 PSYNC 支持
默认情况下，AWS ElastiCache for Redis OSS 不允许使用 PSYNC 命令，而 Redis-Shake 的增量同步功能依赖于此命令。在使用 Redis-Shake 进行数据迁移前，需要联系 AWS Support 申请开通 PSYNC 命令支持：

1、登录 AWS Support Center Console。

2、创建技术支持案例，选择 ElastiCache 服务.

3、在案例描述中明确说明需要为特定 ElastiCache 集群开通 PSYNC 命令支持，用于数据迁移。

4、提供集群 ID、区域信息以及计划的迁移时间窗口。

AWS 通常会在 1-3 个工作日内处理此类请求。

未开通 PSYNC 支持前，只能使用全量同步模式，这可能会对源集群性能产生更大影响，并且无法实现实时增量数据同步。

版本支持：

• Redis-Shake v2.1.0+ 支持 ElastiCache 5.X及其以上版本的数据迁移
• 支持从低版本 Redis 向高版本 Redis 迁移（如0.6 到 6.2.6）
• 支持 ElastiCache for Redis OSS 的所有主要功能，包括加密传输和认证
• 兼容 AWS ElastiCache 的网络和安全设置
• 支持 RDB 和 AOF 两种同步模式，适用于不同规模的数据集

Redis-FullCheck

Redis-FullCheck 是专为 Redis 数据验证设计的工具，用于 ElastiCache for Redis OSS 数据一致性验证，可以：

• 全面比较源和目标 ElastiCache for Redis OSS 中的数据
• 验证键值一致性
• 检查数据类型匹配
• 验证过期时间设置
• 生成详细的差异报告

版本支持：

• Redis-FullCheck 支持验证 Redis 2.8 至 Redis 7.0 之间的数据一致性
• 能够处理不同 Redis 版本之间的数据结构差异
• 支持大规模数据集的高效验证，采用多线程并行处理
• 提供可配置的采样率，适用于超大规模数据集的快速验证
• 兼容 ElastiCache for Redis OSS 的所有数据类型和特性

2.2 升级流程图

3. 详细步骤

3.1 验证环境和连接

目标：确保所有必要的环境和连接都正常工作。

步骤：

1. 验证本地环境配置
2. 验证远程 EC2 连接
3. 验证蓝色集群（源 ElastiCache for Redis OSS）连接
4. 验证绿色集群（目标 ElastiCache for Redis OSS）连接
5. 检查 Redis-Shake 是否已安装

验证标准：

• 所有检查项显示”验证通过”或”连接成功”
• 日志文件中无错误信息

3.2 设置 Redis-Shake

目标：准备数据同步工具。

步骤：

1. 安装 Redis-Shake（如果尚未安装）
2. 创建 Redis-Shake 配置文件
3. 创建 Redis-FullCheck 配置文件
4. 创建启动脚本

配置文件示例（shake.toml）：

# Redis-Shake同步配置文件
[sync_reader]
cluster = false
address = "redis-blue.abcdef.ng.0001.use1.cache.amazonaws.com:6379"
username = ""
password = ""
tls = false
sync_rdb = true
sync_aof = false
prefer_replica = false
try_diskless = true
[redis_writer]
cluster = false
address = "redis-green.abcdef.ng.0001.use1.cache.amazonaws.com:6379"
username = ""
password = ""
tls = false
off_reply = true
[filter]
allow_keys = []
allow_key_prefix = []
allow_key_suffix = []
allow_key_regex = []
block_keys = []
block_key_prefix = []
block_key_suffix = []
block_key_regex = []
allow_db = []
block_db = []
[advanced]
dir = "data"
ncpu = 8
pprof_port = 0
status_port = 8001
log_file = "redis-shake.log"
log_level = "info"
log_interval = 5
log_rotation = true
log_max_size = 512
log_max_age = 7
log_max_backups = 3
log_compress = true
rdb_restore_command_behavior = "rewrite"
pipeline_count_limit = 4096
target_redis_client_max_querybuf_len = 2147483648
target_redis_proto_max_bulk_len = 512000000
empty_db_before_sync = true
# AWS ElastiCache特定配置
# 如果源是AWS ElastiCache，可以设置此项
# aws_psync = ""      # 示例: "10.0.0.1:6379@nmfu2sl5osync"

3.3 启动数据同步

目标：开始将数据从蓝色集群同步到绿色集群。

步骤：

1. 确认 Redis-Shake 已设置
2. 启动 Redis-Shake 数据同步
3. 检查初始同步状态

3.4 监控同步进度

目标：确保数据同步正常进行并最终完成。

步骤：

1. 检查 Redis-Shake 是否正在运行
2. 监控同步进度和预计剩余时间
3. 查看同步日志

监控指标：

• 全量同步进度百分比
• 预计剩余时间
• 同步总量、RDB同步量、AOF同步量

3.5 验证数据一致性

目标：确认两个集群的数据完全一致。

步骤：

1. 启动 Redis-FullCheck 进行全面数据验证
2. 分析验证结果
3. 处理任何数据不一致问题

Redis-FullCheck 配置文件（check.toml）：

# Redis-FullCheck配置文件
[source]
address = "redis-blue.abcdef.ng.0001.use1.cache.amazonaws.com:6379"
username = ""
password = ""
tls = false
[target]
address = "redis-green.abcdef.ng.0001.use1.cache.amazonaws.com:6379"
username = ""
password = ""
tls = false
[comparison]
result_file = "diff.log"
comparision_type = "value"

验证方法：
Redis-FullCheck 工具会执行以下验证：

1. 键存在性验证：确保源 ElastiCache for Redis OSS 中的每个键在目标 ElastiCache for Redis OSS 中都存在
2. 键类型验证：确保键的类型一致
3. 键值验证：确保键的值完全一致
4. TTL 验证：确保键的过期时间设置一致

验证结果分析：

• 检查log 文件中是否有差异报告
• 如果发现差异，决定是否需要修复或重新同步
• 只有在数据完全一致的情况下才继续下一步

3.6 切换流量

目标：将应用流量从蓝色集群切换到绿色集群。

步骤：

1. 停止向蓝色集群写入数据
2. 等待 Redis-Shake 完成剩余数据同步
3. 再次验证数据一致性
4. 更新应用配置，将连接切换到绿色集群
5. 停止 Redis-Shake

应用配置更新示例：

# 更新应用配置
sed -i 's/redis-blue.abcdef.ng.0001.use1.cache.amazonaws.com/redis-green.abcdef.ng.0001.use1.cache.amazonaws.com/g' app_config.json

3.7 回滚（如需）

目标：在升级失败时将流量从绿色集群切换回蓝色集群。

⚠️ 警告：版本兼容性风险

从高版本 Redis (6.2.6) 向低版本 Redis (5.0.6) 回滚时，存在数据结构和功能不兼容的风险：

• 新版本中使用的数据结构可能在旧版本中不受支持
• 新版本特有的命令和功能在旧版本中不可用
• 某些数据类型的内部表示可能发生变化，导致数据不一致
• 在回滚前必须进行全面的兼容性评估和测试
• 建议使用 Redis-FullCheck 工具验证数据兼容性

步骤：

1. 创建回滚同步配置（从绿色集群到蓝色集群）
2. 启动回滚同步
3. 停止向绿色集群写入数据
4. 等待回滚同步完成
5. 验证数据一致性
6. 将应用连接切换回蓝色集群

回滚配置文件（rollback.toml）：

# Redis-Shake回滚配置文件
[sync_reader]
cluster = false
address = "redis-green.abcdef.ng.0001.use1.cache.amazonaws.com:6379"
username = ""
password = ""
tls = false
sync_rdb = true
sync_aof = false
prefer_replica = false
try_diskless = true
[redis_writer]
cluster = false
address = "redis-blue.abcdef.ng.0001.use1.cache.amazonaws.com:6379"
username = ""
password = ""
tls = false
off_reply = true
[filter]
allow_keys = []
allow_key_prefix = []
allow_key_suffix = []
allow_key_regex = []
block_keys = []
block_key_prefix = []
block_key_suffix = []
block_key_regex = []
allow_db = []
block_db = []
# 回滚时的特殊过滤设置
# 可以在这里添加过滤规则，排除高版本特有的数据结构或命令
# 例如：block_key_prefix = ["6.2_feature_"]
[advanced]
dir = "data"
ncpu = 8
pprof_port = 0
status_port = 8002
log_file = "rollback_sync.log"
log_level = "info"
log_interval = 5
log_rotation = true
log_max_size = 512
log_max_age = 7
log_max_backups = 3
log_compress = true
rdb_restore_command_behavior = "rewrite"
pipeline_count_limit = 4096
target_redis_client_max_querybuf_len = 2147483648
target_redis_proto_max_bulk_len = 512000000
empty_db_before_sync = true
# AWS ElastiCache特定配置
# 如果源是AWS ElastiCache，可以设置此项
# aws_psync = ""     # 示例: "10.0.0.1:6379@nmfu2sl5osync"

3.8 完成升级

目标：确认升级成功并完成最终清理工作。

步骤：

1. 确认应用正常运行在绿色集群上
2. 停止所有 Redis-Shake 进程
3. 备份日志文件以供参考
4. 清理临时文件

4. 注意事项与最佳实践

4.1 前期准备

• 确保绿色集群（新版本 ElastiCache for Redis OSS）已正确配置并启动
• 确保有足够的磁盘空间用于数据同步和日志
• 在非高峰期执行升级操作
• 对应用程序进行新版本 Redis 兼容性验证，确保所有功能正常工作
• 在绿色集群上执行必要的性能压测，验证新版本在高负载下的稳定性
• 评估应用程序关键指标（如响应时间、吞吐量）在新版本上的表现
• 准备详细的回滚计划和应急预案
• 提前通知相关团队，确保技术支持人员在升级期间待命

4.2 数据同步

• 对于大型数据集，预留足够的同步时间：
  • 根据数据量大小和网络带宽，提前估算同步所需时间
  • 对于 TB 级数据，可能需要数小时甚至数天的同步时间
  • 考虑使用数据采样测试来评估实际同步速率
  • 在项目计划中为数据同步预留充足的缓冲时间
  • 建立同步进度监控机制，及时发现同步异常或速度下降情况
  • 对于特别大的数据集，考虑分批次迁移或使用增量同步策略
• 监控网络带宽和系统资源使用情况
• 考虑使用增量同步减少数据传输量

4.3 数据验证

• 使用 Redis-FullCheck 进行全面的数据验证
• 对于特别重要的数据，考虑进行抽样手动验证
• 验证不仅包括键值，还包括过期时间和数据类型

4.4 流量切换

• 实施灰度发布策略，逐步将流量切换到绿色集群
• 准备回滚计划和脚本
• 切换后密切监控应用性能和错误日志

4.5 回滚策略

• 设定明确的回滚触发条件
• 确保回滚脚本经过测试并随时可用
• 记录每次操作，便于问题排查
• 版本兼容性评估：在回滚前评估高版本到低版本的兼容性问题
• 数据过滤机制：配置 Redis-Shake 过滤规则，排除高版本特有的数据结构
• 功能降级计划：制定应用程序功能降级计划，处理低版本不支持的特性
• 分阶段回滚：考虑分批次回滚数据，降低风险
• 全面测试：在生产环境回滚前，在测试环境验证回滚流程

5. 故障排查

5.1 常见问题及处理方式

1.Redis-Shake 连接失败

• 现象：Redis-Shake 无法连接到源或目标 Redis 实例，日志中出现连接超时或拒绝错误
• 可能原因：
  • 安全组配置错误，未开放必要端口
  • Redis 实例认证设置不正确
  • 网络连接问题或 VPC 配置错误
• 处理方式：
  • 验证安全组入站规则是否允许 Redis-Shake 服务器的连接
  • 检查 Redis 认证配置，确保密码正确
  • 使用 redis-cli 工具直接测试连接
  • 检查网络 ACL 和路由表配置

2.数据同步速度过慢

• 现象：数据同步进度缓慢，预计完成时间远超预期
• 可能原因：
  • 源 Redis 实例负载过高
  • 网络带宽限制
  • Redis-Shake 配置不当，如并发度设置过低
  • 大量大键值对同步效率低下
• 处理方式：
  • 调整 Redis-Shake 配置，增加 pipeline_count_limit 参数值
  • 在低峰期执行同步操作
  • 考虑使用更高规格的 EC2 实例运行 Redis-Shake
  • 对大键值对进行拆分或使用增量同步策略

3.数据验证不一致

• 现象：Redis-FullCheck 报告源和目标数据不一致
• 可能原因：
  • 同步过程中源数据发生变化
  • Redis-Shake 同步过程中出现错误
  • 键过期时间设置不一致
• 处理方式：
  • 分析log 文件，确定不一致的具体键和原因
  • 对于关键数据不一致，考虑手动修复
  • 如果不一致数量较多，重新启动同步过程
  • 确保在最终切换前再次执行完整验证

4.应用连接失败

• 现象：应用无法连接到新的 Redis 集群，或连接后出现异常
• 可能原因：
  • 应用配置未正确更新
  • 新版本 Redis 的兼容性问题
  • 连接池配置不当
• 处理方式：
  • 验证应用配置中的 Redis 连接信息是否已更新
  • 检查应用日志中的具体错误信息
  • 测试应用使用的 Redis 客户端库是否支持新版本
  • 调整连接池参数，如最大连接数、超时设置等

5.2 排查步骤

1. 检查网络连接和安全组设置
2. 查看 Redis-Shake 和 Redis-FullCheck 日志
3. 验证 ElastiCache for Redis OSS 实例的资源使用情况
4. 检查应用配置是否正确更新

5.3 应急措施

• 立即回滚：如遇严重问题，立即执行回滚操作
  • 使用预先准备的回滚脚本将流量切回蓝色集群
  • 确保回滚过程中的数据一致性，必要时进行数据修复
  • 通知所有相关团队回滚决定和原因
• 问题隔离：
  • 识别并隔离受影响的服务或功能
  • 考虑临时降级非关键功能，确保核心业务正常运行
  • 实施流量限制，减轻系统压力
• 数据保护：
  • 在任何操作前备份当前状态的数据
  • 避免在问题排查过程中执行可能导致数据丢失的操作
  • 记录所有手动干预步骤，以便后续重现或回滚
• 沟通与协作：
  • 保持与关键利益相关者的实时沟通
  • 组建应急响应团队，明确职责分工
  • 建立问题升级机制，确保及时获得必要支持
• 文档与分析：
  • 保留所有日志和配置文件，用于后续分析
  • 记录问题发现、处理和解决的完整时间线
  • 事后进行根本原因分析，避免类似问题再次发生
• 专业支持：
  • 必要时开启 AWS 支持案例，获取专业技术援助

6. 附录

6.1 术语表

6.2 参考资料

1. Amazon ElastiCache 文档
2. Redis-Shake GitHub 仓库

7. 相关内容推荐

7.1数据库产品最新动态

• 亚马逊ElastiCache向量搜索功能现已在亚马逊云科技中国区域推出
• 全新 Graviton4 实例，提升 Valkey 性价比
• Amazon Quick Sight announces the general availability of a new data preparation experience
• Amazon RDS for MariaDB 现在支持 MariaDB 11.8 并支持 MariaDB Vector
• Amazon ElastiCache now supports Valkey 8.1

7.2 AWS Marketplace 合作伙伴推荐

• Bytebase 是一款协同式数据库管理工具，提供 schema 协同、版本控制及支持权限管理的嵌入式 SQL 编辑器。该工具可无缝集成至数据库 CI/CD 流程，支持基于 GitLab 的数据库任务管理，并遵循 GitOps 理念实现版本可控、操作可溯的数据库管理。
• SphereEx-DBPlusEngine 作为分布式计算平台，支持跨云环境的数据库弹性分片与管理，具备自动扩缩容、流量治理、企业级安全、高性能集群、高可用集群等核心功能，可为 Java 同构/异构语言场景及云原生环境提供标准化数据扩展、分布式事务与分布式治理能力。
• 观测云 是一款面向云原生时代的云服务平台，致力于解决云计算环境下的可观测性需求，为云端完整应用链路的每一环节构建全链路可观测能力。

*前述特定亚马逊云科技生成式人工智能相关的服务目前在亚马逊云科技海外区域可用。亚马逊云科技中国区域相关云服务由西云数据和光环新网运营，具体信息以中国区域官网为准。

本篇作者