亚马逊AWS官方博客

Amazon ElastiCache 版本升级指南

1. 升级原因

1.1 背景

Amazon ElastiCache 是 亚马逊云科技提供的一项完全托管的内存数据存储服务，广泛应用于缓存、会话存储、实时分析等场景。随着技术的不断发展，AWS 定期推出新版本以提供更好的性能、安全性和功能特性 ，以满足用户不断增长的需求。建议用户及时关注版本更新信息，在版本End of Life(EOL)前完成升级规划。  以下是关于ElastiCache for Redis OSS版本EOL时间表 ：

Major Engine Version End of Standard Support Start of Extended Support Y1 Premium Start of Extended Support Y2 Premium Start of Extended Support Y3 Premium End of Extended Support and version EOL
1 Redis OSS v4 1/31/2026 2/1/2026 2/1/2027 2/1/2028 1/31/2029
2 Redis OSS v5 1/31/2026 2/1/2026 2/1/2027 2/1/2028 1/31/2029
3 Redis OSS v6 1/31/2027 2/1/2027 2/1/2028 2/1/2029 1/31/2030

例如:

ElastiCache 5.x 版本生命周期

  • ElastiCache 5.x 版本End of Standard Support 时间：2026年01月31日
  • 扩展支持：如希望EOL后仍停留在ElastiCache 5，可选择Extended Support 来继续停留在 ElastiCache 5长达3年的时间。
  • 版本历史：ElastiCache 5.x 基于 Redis OSS 5.0.6，于2019年11月首次发布，已服务用户多年
  • Redis 官方EOL时间：Redis OSS 5.0.x 已于2023年9月达到官方生命周期结束(EOL)，不再接收安全更新和bug修复

有关更多详细信息，请参阅ElastiCache versions for Redis OSS EOL。

升级必要性

  • 业务影响：
    • 无法利用新版本提供的成本优化功能，如数据分层和内存优化
    • 与新开发的应用和服务集成时可能面临兼容性挑战
    • 性能瓶颈无法通过版本升级解决，可能需要增加硬件资源
  • 行业趋势：
    • 云原生应用对缓存服务的要求不断提高，特别是在性能和可扩展性方面
    • 微服务架构下，缓存服务需要支持更灵活的访问控制和安全机制
    • 大数据和AI应用场景对缓存性能和功能提出更高要求
  • 风险提示：
    • 新功能和性能优化将无法使用
    • 技术债务积累，未来升级难度和风险将进一步增加

1.2 ElastiCache 7及以上版本主要特性与优势

升级到更高版本的 ElastiCache 不仅是为了避免支持终止的风险，更重要的是能够利用新版本带来的显著性能提升、增强的安全特性和更灵活的管理功能。以下是升级的核心优势：

类别 关键优势 业务价值
1 性能提升 • 多核CPU性能优化
• TLS性能显著提升
• 增强型 I/O 多线程处理
• 优化的内存访问模式		 • 相同硬件上处理更高吞吐量
• 降低延迟，提升用户体验
• 减少资源成本，提高投资回报率
2 安全增强 • 访问控制列表 (ACL)
• 基于角色访问控制 (RBAC)
• 增强的 TLS/SSL 支持
• 细粒度权限控制		 • 满足合规要求
• 防止未授权访问
• 实现最小权限原则
3 成本优化 • 数据分层存储
• 内存效率提升
• Serverless 按使用付费模式		 • 降低存储成本
• 减少实例规格需求
• 优化资源利用率
4 运维简化 • 自动扩缩容
• Serverless 选项
• 增强的监控指标		 • 减少人工干预
• 简化容量规划
• 提高系统可靠性
5 功能扩展 • 客户端缓存
• 分片 Pub/Sub
• RESP3 协议支持
• 更丰富的命令集		 • 减少网络往返
• 提高消息传递效率
• 支持更丰富的数据类型

2. 升级准备

2.1 升级准备工作概述

在进行ElastiCache版本升级前，建议DBA/运维团队和业务研发团队紧密合作，完成以下准备工作：

  1. 梳理待升级集群：全面梳理待升级ElastiCache集群/实例并与业务场景进行映射，明确每个集群的业务重要性和依赖关系
  2. 兼容性评估：进行详细的兼容性评估，搜集对升级操作和停机时间的要求，确保新版本与现有应用兼容
  3. 依赖组件分析：梳理ElastiCache升级对于上下游依赖组件影响，如上游Proxy和下游keyspace消费，确保整体系统协调升级
  4. 运行状况分析：结合业务场景和数据库监控，分析数据库运行情况，并规划升级方式和回滚方案，确保升级过程可控
  5. 升级测试：启动全面的升级测试，包含业务研发侧兼容性调整和运维侧升级方式演练，验证升级流程的可行性
  6. 升级计划制定：完成详细的整体升级计划，包含业务升级顺序、升级方式、升级时间安排，并获得所有相关方的确认
  7. 分批升级执行：根据业务重要性，分批次完成数据库升级，确保每批升级后有足够的观察期

2.2 详细准备工作

2.2.1 各版本详细特性

了解各版本的详细特性对于规划升级至关重要。以下是ElastiCache各版本的主要功能和改进：

Redis OSS 版本特性

主要版本 主要特性
1 版本 6 • 支持auto-scaling，可根据负载自动调整集群大小
• 客户端缓存功能，减少客户端与服务器之间的通信
• 支持 TLS 的集群的性能改进，将加密转移到其他 vCPUs 来提高吞吐量并缩短客户端连接建立时间
• 支持使用访问控制列表 (ACL) 规则管理对 Pub/Sub 频道的访问权限
• 支持数据分层，优化存储成本
2 版本 7 • 支持函数，使开发人员能够使用存储在 ElastiCache集群中的应用程序逻辑执行 LUA 脚本
• 访问控制列表 (ACLs) 的支持粒度更小
• 引入Sharded Pub/Sub，提高大规模部署的消息传递效率
• 扩展了增强型 I/O 线程功能.
• 引入了RESP3协议支持，提供更丰富的数据类型和更高效的客户端-服务器通信

Valkey 版本特性

主要版本 主要特性
1 版本 7 7.2 相较Redis OSS 的 7.1 ElastiCache 版本:
• 各种数据类型的性能和内存优化：列表和集合类型键的内存优化、排序集命令的速度优化、集群模式下具有多个键的命令的性能优化、pub/sub 性能改进、SCAN、HSCAN、ZSCAN 命令的性能优化以及许多其他较小的优化
• ZRANK 和 ZREVRANK 命令有新的 WITHSCORE 选项，减少客户端需要的往返次数
• CLIENT NO-TOUCH 让客户端可以在不影响键的 LRU/LFU 的情况下运行命令，提高缓存效率
• 新命令 CLUSTER MYSHARDID 返回节点的分片 ID，以便根据复制在集群模式下对节点进行逻辑分组
• 与Redis OSS相比，在相同硬件上提供30-50%的性能提升
• 完全兼容Redis OSS 6.2 API，确保应用程序无需修改即可迁移
2 版本 8 • 内存效率提高，允许用户在不更改任何应用程序的情况下在每个节点上存储多达 20% 的数据，降低存储成本
• 新推出的每插槽指标基础架构，用于自行设计的缓存，可详细了解各个插槽的性能和资源使用情况，便于精确调优
• ElastiCache 适用于 Valkey 8.0 的无服务器可以每 2-3 分钟将支持的每秒请求数 (RPS) 翻一番，在不到 13 分钟的时间内从零达到每个缓存 500 万 RPS，读取延迟始终保持亚毫秒 p50
• 改进的内存分配器，减少内存碎片
• 优化的命令处理流程，降低CPU使用率
• 增强的集群管理功能，提高稳定性和可靠性

Serverless 特性（7.x及以上版本）

主要版本 主要特性
1 Redis OSS 7
Valkey 7.2、8.0		 • 自动扩缩容：无需管理节点和集群，系统根据负载自动调整资源
• 高性能：在 Valkey 8.0 中，从零达到500万RPS 仅需要13分钟
• 低延迟：读取延迟保持亚毫秒级p50，即使在高负载下也能保持稳定
• 成本优化：按实际使用量付费
• 适用场景：特别适用于负载波动大、开发测试等场景，无需预先规划容量
• 高可用性：自动化的高可用性和容错能力，无需手动配置复制和故障转移
• 简化运维：简化的监控和运维管理，减少管理开销
• 多区域支持：支持在多个AWS区域部署，实现全球分布式缓存架构

2.2.2 版本升级注意事项

在升级过程中，需要特别关注不同版本间的行为变化和兼容性问题。以下是各升级路径的关键注意事项：

升级路径 主要变化与注意事项
1 从Redis 5.0升级到Redis 6.0 • 数据库数量限制：从120万减少到1万个(默认值为16)，需检查应用是否使用大量数据库
• 自动升级参数：引入AutoMinorVersionUpgrade参数，设置为yes时ElastiCache将通过自助更新管理次要版本升级
• ACL支持：引入访问控制列表功能，需确保客户端驱动支持
• 客户端缓存：新增客户端缓存功能，可考虑调整应用以利用此特性
• SSL/TLS支持：增强的加密传输支持，需确保客户端驱动兼容
2 从Redis 6.0升级到Redis 6.2 • ACL变更：TIME、ECHO、ROLE和LASTSAVE命令的ACL标志发生变化，需检查现有ACL规则
• Lua脚本行为变更：从映射响应返回到lua脚本的键/值对的顺序发生了变化，需测试依赖键顺序的脚本
• TLS性能改进：对于8+ vCPU的x86或4+ vCPU的Graviton2节点，TLS性能显著提升，可考虑调整实例类型
• 数据分层：支持数据分层功能，可评估是否适合您的工作负载
• HyperLogLog改进：提高了HyperLogLog数据结构的性能，使用此功能的应用可能获得性能提升
3 从Redis 6.2升级到Redis 7.0 • 脚本传播变更：SCRIPT LOAD和SCRIPT FLUSH不再传播到副本，需调整依赖此行为的应用
• ACL默认值变更：新的ACL用户的发布订阅通道默认处于屏蔽状态，需检查现有权限设置
• 命令替换：STRALGO命令替换为LCS命令；ACL GETUSER的格式变更，需更新使用这些命令的应用
• ACL类别变更：SELECT、WAIT、ROLE等命令的ACL类别发生变化，需审核现有ACL规则
• INFO命令增强：INFO命令现在显示每个子命令的统计信息，可能需要调整解析逻辑
• 命令返回值变化：LPOP、RPOP、ZPOPMIN和ZPOPMAX命令在某些边缘情况下的返回值变化，需测试应用兼容性
• SORT命令权限变更：SORT和SORT_RO命令需要访问整个键空间才能使用GET和BY参数，可能需要调整ACL权限
• I/O多路复用：增强的I/O多路复用能力，可能需要调整连接池配置以充分利用
• 分片Pub/Sub：支持分片的发布订阅功能，可考虑迁移现有Pub/Sub实现以提高性能
4 从Redis OSS 7.0/7.1升级到Valkey 7.2.6 • Valkey背景：Valkey 7.2是基于Redis OSS 7.2开发的开源兼容Redis的数据库，保持API兼容性的同时提供性能优化
• 开源特性：Valkey是开源项目，代码库托管在GitHub (https://github.com/valkey-io)，遵循BSD-3许可证
• 性能优化：多种数据类型和命令的性能显著提升，在相同硬件上提供30-50%的性能提升，需重新评估性能基准
• 内存效率：改进的内存管理和分配策略，减少内存碎片，可能影响内存使用监控和告警阈值
• 时间采样变更：冻结时间采样在命令执行期间和脚本中进行，可能影响依赖精确时间的应用
• 错误代码变更：阻塞的流命令在解除阻塞时返回不同的错误代码，需测试错误处理逻辑
• 客户端跟踪增强：脚本的客户端跟踪现在可以跟踪脚本读取的键值，可能影响缓存失效行为
• 命令优化：ZRANK和ZREVRANK命令新增WITHSCORE选项，减少客户端往返次数；CLIENT NO-TOUCH命令允许在不影响LRU/LFU的情况下运行命令
• 集群功能增强：新增CLUSTER MYSHARDID命令，便于在集群模式下根据复制对节点进行逻辑分组

在进行升级前，建议在测试环境中验证这些变化对应用的影响，并相应地调整应用代码或配置。特别是对于关键业务应用，应进行全面的功能和性能测试，确保升级后系统能够正常运行。

2.2.3 驱动兼容性检查

  • 通用注意事项：
    • RESP3： Redis 7.0引入了RESP3协议支持，需要检查客户端驱动的兼容性
    • TLS 支持：所有驱动需更新至推荐版本以支持加密连接，旧版本驱动可能不支持TLS/SSL
    • ACL 兼容性：确保驱动支持用户名/密码认证（如 user:pass 格式），Redis 6.0+需要此功能
    • Valkey 适配：上述驱动均兼容 Valkey（因其与 Redis 6.2 API 兼容），无需特殊适配
    • 驱动维护：优先选择活跃维护的仓库（如 Lettuce > Jedis），以确保安全补丁和性能优化
    • 连接池配置：升级后可能需要调整连接池参数以适应新版本的性能特性
    • 重试机制：确保驱动具有适当的重试机制，以处理升级过程中可能出现的短暂连接中断
  • 常见驱动兼容性列表:
语言 驱动 推荐版本 备注
1 Java Lettuce（推荐） 6.2.4+ • 支持RESP3协议
• 完全支持集群模式和TLS
• 支持反应式编程模型
• 支持主从复制和哨兵模式
• 内置连接池和重试机制
2 Java Jedis 4.3.1+ • 较简单的API
• 支持基本集群功能
• 需要额外配置连接池
3 Python redis-py 5.0.0+ • 支持 TLS、集群模式、异步（asyncio）
• Valkey 兼容性：完全兼容
• 支持连接池和哨兵模式
• 支持Lua脚本和管道操作
4 JavaScript/Node.js ioredis 5.3.2+ • 支持集群、Pipeline、TLS
• Valkey 兼容性：完全兼容
• 内置重试和错误处理
• 支持Lua脚本和事务
• 支持发布/订阅功能
5 Golang go-redis v9.0.0+ • 支持 RESP3、集群、哨兵模式
• Valkey 兼容性：官方测试通过
• 支持上下文控制和超时设置
• 支持连接池管理
• 支持TLS和管道操作
6 PHP predis/predis v2.1.2+ • phpredis（扩展，需 5.3.0+）
• 纯PHP实现，无需扩展
• 支持集群和哨兵模式
• 支持Lua脚本和事务
7 .NET (C#) StackExchange.Redis 2.6.66+ • 支持 TLS、多路复用、集群
• 高性能连接复用
• 支持发布/订阅和Lua脚本
• 内置分析和监控功能
8 Ruby redis-rb 5.0.0+ • 支持集群和哨兵模式
• 支持连接池和管道操作
• 支持Lua脚本和发布/订阅
9 Rust redis-rs 0.23.0+ • 支持异步操作
• 支持集群和TLS
• 支持连接池和管道操作

2.2.4 升级兼容性检查

  • 命令兼容性:
    • 检查弃用命令：检查应用是否使用了在新版本中被弃用或修改的命令，如STRALGO在0中被替换为LCS
    • 验证脚本执行：验证复杂脚本在新版本中的执行情况，特别是依赖于键/值对顺序的脚本
    • ACL规则验证：检查现有ACL规则在新版本中是否仍然有效，特别是0到6.2和6.2到7.0的升级
    • 命令返回值变化：测试应用对命令返回值格式变化的适应性，如LPOP/RPOP在0中的变化
    • 命令执行方式：检查批量命令和事务在新版本中的行为，特别是在集群模式下
  • 参数兼容性:
    • 参数组迁移：检查自定义参数组设置在新版本中是否仍然有效，创建适用于新版本的参数组
    • 默认值变化：确认默认参数值的变化是否会影响应用行为，如maxclients和databases的默认值
    • 新参数配置：规划新版本特有参数的配置，如I/O线程参数和内存优化参数
    • 参数依赖关系：检查参数之间的依赖关系，确保配置一致性
  • 功能依赖性:
    • 特性依赖分析：识别应用对特定Redis功能的依赖，如Lua脚本、事务或特定数据结构
    • 行为变化确认：确认这些功能在新版本中的行为变化，特别是边缘情况下的处理
    • 客户端缓存：评估是否可以利用新版本的客户端缓存功能提高性能
    • 分片Pub/Sub：检查应用是否可以从0的分片Pub/Sub功能中受益
    • 内存效率：评估新版本的内存优化对应用的影响，特别是对于内存受限的工作负载

2.2.5 性能测试

  • ElastiCache性能优化:
    • 2版本优化：增强了多线程处理能力，改进了线程调度算法，在8+vCPU（x86）或4+vCPU（Graviton2）时性能提升明显
    • 0版本优化：增强型I/O复用能力，显著提高并发处理能力和响应时间
    • Valkey 7.2优化：与Redis OSS 6.2相比，在相同硬件上提供30-50%的性能提升
    • 实测数据：与Redis OSS 6版本相比，使用xlarge节点组成的集群并运行5200个并发客户端时，吞吐量（每秒读取和写入操作数）最多可增加72%，P99延迟最多可减少71%
    • Valkey 8.0优化：内存效率提高，允许在每个节点上存储多达20%的额外数据，同时保持或提高性能
  • 测试方法:
    • 工作负载模拟：使用生产环境的真实工作负载模式进行测试，确保测试结果具有实际参考价值
    • 并发测试：测试不同并发连接数下的性能表现，从低并发到高并发（如100到10000连接）
    • 读写比例测试：测试不同读写比例下的性能表现，包括读密集型(4:1)、写密集型(1:4)和平衡型(1:1)
    • 数据大小测试：测试不同数据大小和访问模式下的性能表现，从小键值对(几字节)到大对象(几MB)
    • 延迟测试：测量不同操作的延迟分布，包括P50、P95、P99延迟
    • 持久化影响：评估不同持久化设置(如AOF、RDB)对性能的影响
    • 网络延迟：测试不同网络条件下的性能表现，特别是跨可用区访问
  • 测试工具推荐:
    • memtier_benchmark：Redis官方推荐的基准测试工具，支持多种工作负载模式
    • redis-benchmark：Redis自带的基准测试工具，适合快速测试
    • YCSB：Yahoo!云服务基准测试，适合模拟真实应用场景
    • 自定义测试脚本：根据实际业务场景开发的测试脚本，最能反映实际性能
  • 注意事项:
    • 环境一致性：性能测试结果依客户场景不同而有所差异，建议以用户实际测试表现为准
    • 测试环境配置：确保测试环境与生产环境配置相似，包括网络、安全组和参数组设置
    • 基准记录：记录基准测试结果，以便与升级后进行比较，包括吞吐量、延迟和资源利用率
    • 长时间测试：进行长时间运行的测试(如24小时)，以发现潜在的内存泄漏或性能下降问题
    • 故障恢复测试：测试节点故障和自动恢复场景下的性能和数据一致性

2.3 通过变更机型和版本来提高性能

  • 前置条件:
    • ElastiCache版本: Redis 6.2.6\Valkey 7.2.6
    • 机型: .large(r6g/r7g).xlarge(r6g/r7g).2xlarge(r6g/r7g)
    • 架构: Multi-AZ
    • memtier_benchmark: random-data,读写比例（1:4,4:1,1:1）
  • 压测结果
  • 性能结论:
    1. 在同样版本、同样的vCPU情况下R7g机型性能均高于R6g，提升比例至少10%以上
    2. 在测试用例相同的情况下，（R7g/R6g）xlarge较large性能的提升约100%
    3. 相关规格的情况下，Valkey 7.2的性能比Redis OSS 6.2的提升至少30%
  • 实例类型说明：
    • large对应2vCPU
    • xlarge对应4vCPU
    • 2xlarge对应8vCPU
  • 升级便利性：目前，实例和版本升级可以在控制台中的一次修改中完成
  • 性能与成本对比 (读写比例：4:1):
配置 性能总结（7g比其他） OD (USD hourly) OD价差（7g比其它） OD性价比（7g对比其他） 1Y no-upfront RI (USD hourly) RI价差（7g比其它） RI性价比（7g比其它）
1 Valkey 7.2 cache.r7g.xlarge – 0.3496 – – 0.238 – –
2 Valkey 7.2 cache.r6g.xlarge 19.7 ~ 31.4% 0.3288 5.90% 18.8 ~ 29.9% 0.225 5.40% 17.2 ~ 27.4%
3 Redis OSS 6.2 cache.r7g.xlarge 28.2 ~ 39.5% 0.437 -25% 88.7 ~ 63.3% 0.297 -24.70% 87.6 ~ 62.5%
4 Redis OSS 6.2 cache.r6g.xlarge 33.9 ~ 45.2% 0.411 -17.60% 51.9 ~ 38.9% 0.281 -18.10% 53.4 ~ 40.1%
  • 选择建议：
    • Valkey 7.2 r7g 的吞吐量更高
    • 从性价比角度来看，在吞吐要求不高的情况下，valkey 7.2版本下r6g是不错的选择

3. 升级方案

3.1 升级方案汇总

属性 系统自动/人工点击升级 备份恢复新集群 蓝绿(需人工搭建环境) 业务双写
1 操作复杂度 低 中 高 高
2 中断时间 短 长 中 极短（理论上可以实现无中断）
3 适用场景 • 对于缓存场景, 可根据业务评估是否需要停止应用, 业务低峰期操作
• 对于数据存储场景, 建议升级期间停止应用, 除非业务侧具备数据的补偿能力并且能接受短时间内的集群访问中断		 • 对于写请求的中断窗口时间比较长, 或者数据本身处于静止状态
• 数据量比较大, 担心原集群升级的回滚方案耗时过长		 • 业务重要度较高
• 期望在切换之前进行充分的测试验证, 并且测试期间不影响到旧集群的业务使用
• 期望业务层控制切换时间		 • 数据一致性要求极高
• 业务重要度极高
• 期望在切换之前进行充分的测试验证, 并且测试期间不影响到旧集群的业务使用
• 期望业务层控制切换时间

备注：

  • 相关方案不涉及非Serverless集群
  • Redis-Shake对ElastiCache 4.x版本支持报错

3.1.1 方案1：原地升级

升级步骤

1. 停止业务(可选)
2. 创建旧集群的快照(可选)
3. 按照下图步骤操作

4. 对新集群进行测试验证工作
5. 验证无异常后, 开启业务(可选)

操作流程

  • 准备阶段:
    • 创建详细的升级计划和回滚计划
    • 通知相关团队升级时间和预期影响
    • 确保有足够的监控措施来观察升级过程
  • 执行阶段:
    • 在AWS控制台选择目标集群
    • 点击”Modify”按钮
    • 在引擎版本下拉菜单中选择目标版本
    • 选择”Apply immediately”选项
    • 确认并提交更改
  • 验证阶段:
    • 监控集群状态变化
    • 验证集群参数和配置
    • 测试基本连接和操作
    • 验证应用功能和性能

注意事项

  • 如果升级期间不停止业务, 请确保:
    • 业务可接受升级期间集群的短暂中断(failover)
    • 快照点之后业务的变更数据可再造(回滚场景需要)
  • 升级过程由系统自动完成，用户无法中断
  • 原地升级对主从集群的影响持续时间大约在3-5s

3.1.2 方案2：备份恢复新集群

升级步骤

  1. 停止业务写操作
  2. 创建旧集群的快照
  3. 利用快照还原到具有目标版本的新集群
  4. 对新集群进行测试验证工作
  5. 无异常后, 修改业务的 endpoint 指向新集群, 开始业务读写操作

操作流程

  • 准备阶段:
    • 估算快照创建和恢复时间
    • 规划业务停机窗口
    • 准备新集群的参数组和子网组
  • 执行阶段:
    • 在AWS控制台创建源集群的手动快照
    • 使用快照创建新集群，选择目标引擎版本
    • 配置新集群的网络、安全组和参数组
    • 等待新集群创建完成并变为可用状态
  • 切换阶段:
    • 验证新集群的数据完整性
    • 更新应用配置，将连接指向新集群
    • 重启应用或刷新连接池
    • 监控应用性能和错误率

优势与劣势

  • 优势:
    • 风险较低，可以在新旧集群间进行比较
    • 可以同时更改集群配置（如节点类型、分片数等）
    • 回滚简单，只需将应用指回原集群
  • 劣势:
    • 需要额外的AWS资源（双倍集群）
    • 停机时间较长，取决于数据量
    • 可能需要更新DNS或应用配置

3.1.3 方案3：蓝绿部署

升级步骤

以下为简化步骤，详细过程可以参考博客：ElastiCache for Redis OSS 蓝绿升级方案

  1. 创建与当前生产环境（blue）同规格高版本一个集群（green），作为未来生产环境
  2. 在blue和green环境中间配置Redis-shake复制
  3. 修改green环境，增减读副本，切换之前充分测试
  4. 修改应用的配置文件 endpoint 指向新集群, 观察延迟并重新启动应用
  5. 应用完成新的配置发布后，部署Redis-shake反向同步

操作流程

  • 准备阶段:
    • 部署和配置Redis-shake
    • 创建与生产环境相同配置的目标集群，但选择更高版本
    • 测试Redis-shake复制功能和性能
  • 同步阶段:
    • 启动Redis-shake，开始数据同步
    • 监控同步进度和延迟
    • 验证数据一致性
  • 切换阶段:
    • 在业务低峰期计划切换
    • 更新应用配置，将连接指向新集群
    • 滚动重启应用或刷新连接池
    • 监控应用性能和错误率

优势与劣势

  • 优势:
    • 可以在切换前充分测试新环境
    • 切换时间可控，可以选择业务低峰期
    • 回滚方便，只需将应用指回原集群
  • 劣势:
    • 需要额外的AWS资源和Redis-shake部署
    • 配置复杂度高
    • 需要管理数据同步和一致性

蓝绿切换 Tips

  • 在业务低峰期进行
  • 程序端驱动应当有超时机制和重连机制
  • 复制延迟应当小于切换超时时间
  • 考虑使用DNS切换来简化应用配置更改
  • 准备详细的回滚计划

Redis-shake配置建议

  • 优化批量同步参数以减少延迟
  • 配置适当的缓冲区大小
  • 启用校验功能确保数据一致性
  • 监控同步进度和性能指标

3.1.4 方案4：业务双写

升级步骤

  1. 创建目标版本的新集群
  2. 修改应用程序，实现双写逻辑（同时写入旧集群和新集群）
  3. 部署支持双写的应用版本，但仍从旧集群读取数据
  4. 验证新集群数据一致性和性能
  5. 修改应用配置，切换为从新集群读取数据
  6. 稳定运行一段时间后，移除双写逻辑，仅写入新集群

操作流程

  • 准备阶段:
    • 开发和测试应用双写逻辑
    • 创建目标版本的新集群
    • 设计监控和验证机制，确保数据一致性
  • 实施阶段:
    • 分阶段部署支持双写的应用版本
    • 监控双写性能和资源消耗
    • 验证新集群数据与旧集群一致
  • 切换阶段:
    • 修改应用配置，从新集群读取数据
    • 监控应用性能和错误率
    • 稳定后移除双写逻辑，完成迁移

优势与劣势

  • 优势:
    • 理论上可以实现零停机时间升级
    • 数据一致性高，风险低
    • 切换过程可完全控制
  • 劣势:
    • 需要修改应用代码，开发成本高
    • 双写期间资源消耗增加
    • 需要处理双写失败和数据不一致的情况
    • 实现复杂度高，需要仔细设计和测试

双写实现建议

  • 使用异步写入减少性能影响
  • 实现写入失败的重试和补偿机制
  • 开发数据一致性验证工具
  • 设计灵活的配置开关，便于控制读写行为
  • 考虑使用消息队列作为中间层，提高可靠性

3.2 升级过程常见问题与解决方案

3.2.1 技术异常与排查

参数组不兼容

  • 现象：
    • 升级后集群状态显示”incompatible-parameters”
    • 日志中出现参数验证错误
    • 某些功能无法正常工作
  • 可能原因：
    • 自定义参数组包含新版本不支持的参数
    • 参数值超出新版本允许的范围
    • 参数组版本与引擎版本不匹配
    • 新版本引入的必需参数未设置
  • 解决方案：
    • 创建与新版本兼容的参数组
    • 比较新旧参数组差异，迁移自定义设置
    • 特别注意以下参数变化：
      • maxclients：x版本默认值和最大值可能不同
      • databases：从x的120万减少到6.x的1万
      • timeout：默认值可能更严格
      • 安全相关参数（如TLS和ACL配置）
    • 修改参数后重启集群（可能需要计划维护窗口）

连接问题

  • 现象：
    • 应用无法连接到升级后的集群
    • 连接间歇性断开
    • 连接建立缓慢
    • 身份验证错误
  • 可能原因：
    • 客户端驱动不兼容新版本
    • TLS/SSL配置变更
    • ACL规则变更
    • DNS缓存问题
    • 连接池配置不当
  • 解决方案：
    • 更新客户端驱动到兼容版本（参考兼容性矩阵）
    • 验证TLS证书和配置
    • 检查ACL规则，特别是x和7.x版本的变化
    • 刷新DNS缓存或使用直接IP连接
    • 调整连接池参数：
      • 增加连接超时时间
      • 实现指数退避重试
      • 优化连接池大小
    • 检查安全组和网络ACL设置
    • 对于DNS缓存问题，可调整JVM DNS TTL设置，使用IP直连或配置更短的DNS缓存时间

3.2.2 业务影响与预防措施

 回源压力问题

  • 问题描述：
    • 缓存不可用期间，可能对下游数据库造成额外的回源压力
    • 可能导致数据库性能过载，影响整体系统稳定性
  • 预防措施：
    • 在业务低峰期执行升级操作
    • 实施应用层限流措施，控制回源请求量
    • 准备额外的数据库容量应对可能的流量高峰
    • 考虑使用多级缓存策略，减轻主数据库压力
    • 对关键业务实施熔断机制，保护核心功能

TTL问题

  • 问题描述：
    • 对于蓝绿或备份恢复新集群的方案，Key的TTL时间可能导致问题
    • 新集群由于过久未访问可能导致key被淘汰，影响业务可用性
  • 预防措施：
    • 在切换前检查和调整关键Key的TTL
    • 实施集群预热策略，确保关键数据在切换前已加载
    • 考虑使用持久化存储关键数据
    • 实施监控机制，及时发现并恢复丢失的键
    • 对于关键业务数据，考虑禁用或延长TTL

4. 回滚方案

4.1 回滚方案汇总

回滚方式 前置(升级期间)准备 还原过程 RPO 与 RTO
1 快照还原 • 升级前创建快照 1. 通过快照还原新集群
2. 应用程序修改 endpoint		 • RPO: 升级之后的增量数据
• RTO: 恢复快照时间 + 应用重启时间
2 Redis-shake复制 • 部署新的redis-shake
• sync_rdb设置为false
• sync_aof设置为true
• 不启动Redis-shake服务		 1. 应用发布后，启动redis-shake追齐增量数据
2. 应用程序修改 endpoint		 • RPO:应用发版期间的增量数据
• RTO: 应用发版时间
3 keyspace notifications • 升级前编写好keyspace notifications的应用程序（数据写入到kafka和从kafka消费）
• 准备升级前，将该程序指向新集群并启动		 1. 启动程序消费kafka中的数据
2. 应用程序修改 endpoint		 • RPO:理论上可以实现0数据丢失
• RTO: 应用发版时间+增量数据同步时间
4 双写切换 • 应用侧支持主备集群切换 1. 应用程序通过切换开关将就集群重新设置为主集群 • RPO: 0
• RTO: 应用开关切换时间

备注： 相关方案不涉及非Serverless集群

4.1.1 方案1：快照还原回滚

回滚步骤

  1. 停止业务写操作
  2. 使用升级前创建的快照还原到新集群，选择原始版本
  3. 对还原的集群进行测试验证
  4. 修改应用的endpoint指向还原的集群
  5. 恢复业务读写操作

操作流程

  • 准备阶段:
    • 确认升级前快照可用性和完整性
    • 估算快照还原时间
    • 规划业务停机窗口
  • 执行阶段:
    • 在AWS控制台使用快照创建新集群，选择原始引擎版本
    • 配置与原集群相同的网络、安全组和参数组
    • 等待新集群创建完成并变为可用状态
  • 切换阶段:
    • 验证还原集群的数据完整性
    • 更新应用配置，将连接指向还原的集群
    • 重启应用或刷新连接池
    • 监控应用性能和错误率

注意事项

  • 快照还原会丢失升级后写入的数据
  • 还原时间取决于数据量大小
  • 考虑使用DNS切换简化应用配置更改

4.1.2 方案2：蓝绿部署回滚（反向复制）

升级前准备

  • 和相关业务部门评估并确认应用发版所需时间, 评估可能丢失的数据
  • 需注意RTO (可以前置搭建反向同步以减少RTO)
  • 准备详细的回滚触发条件和决策流程

回滚步骤

  1. 搭建绿环境(新主)到蓝环境(旧主)的复制
  2. 等待复制延迟追齐
  3. 停止写入, 切换业务侧endpoint并重启业务
  4. 验证业务功能和性能

操作流程

  • 准备阶段:
    • 配置从绿环境到蓝环境的Redis-shake复制
    • 确保复制正常运行并监控延迟
    • 准备应用配置更改和重启计划
  • 执行阶段:
    • 通知相关团队即将执行回滚
    • 在确认复制延迟最小时，暂停业务写入
    • 更新应用配置，将连接指回蓝环境
    • 重启应用或刷新连接池
  • 验证阶段:
    • 确认应用正常连接到蓝环境
    • 验证数据完整性和一致性
    • 监控应用性能和错误率

注意事项

  • 期间可能存在不兼容的事务导致高版本向低版本的复制中断(通常是不兼容的语法), 需人工介入处理
  • 准备处理复制错误的脚本或工具
  • 考虑使用过滤器排除不兼容的命令

4.1.3 方案3：消息队列回滚

升级前准备

  • 和相关业务部门评估并确认应用发版所需时间, 评估可能丢失的数据
  • 如果要求数据无丢失，可以在应用发版前对新的集群的keyspace notifications同步到消息队列
  • 需注意RTO (可以前置搭建反向同步以减少RTO)
  • 配置和测试消息队列系统

升级中

  • 部署消费消息队列的程序，待应用发版结束后，启动该程序将增量数据同步到旧集群
  • 监控消息队列长度和处理延迟
  • 确保消息处理程序正常运行

回滚步骤

  1. 等待复制延迟追齐
  2. 停止写入, 切换业务侧endpoint并重启业务
  3. 验证业务功能和数据一致性

操作流程

  • 准备阶段:
    • 配置keyspace notifications和消息队列
    • 开发和测试消息处理程序
    • 监控消息队列和处理状态
  • 执行阶段:
    • 确认所有消息已处理完成
    • 暂停业务写入
    • 更新应用配置，将连接指回蓝环境
    • 重启应用或刷新连接池
  • 验证阶段:
    • 确认应用正常连接到蓝环境
    • 验证关键数据的一致性
    • 监控应用性能和错误率

注意事项

  • 期间可能存在不兼容的事务导致高版本向低版本的复制中断(通常是不兼容的语法), 需人工介入处理
  • 消息队列需要足够的容量处理峰值负载
  • 消息处理程序需要处理重复消息和错误情况

5. 附录

5.1 相关AWS文档链接

5.2 术语表

术语 描述
1 EOL End of Life，产品生命周期结束
2 EOS End of Support，支持服务结束
3 ACL Access Control List，访问控制列表，用于管理Redis用户权限
4 Failover 故障转移，当主节点不可用时自动切换到副本节点
5 Multi-AZ 多可用区部署，提高可用性和容错能力
6 Sharding 分片，将数据分布在多个节点上以提高扩展性
7 Pub/Sub 发布/订阅模式，用于消息传递
8 TTL Time To Live，键的生存时间
9 RDB Redis Database Backup，Redis的快照持久化机制
10 AOF Append Only File，Redis的增量持久化机制
11 OPS Operations Per Second，每秒操作数，性能指标
12 P99延迟 99%请求的响应时间低于此值
13 RPO Recovery Point Objective，恢复点目标，可能丢失的数据量
14 RTO Recovery Time Objective，恢复时间目标，服务恢复所需时间

5.3 版本兼容性矩阵

客户端/驱动版本 Redis 5.0 Redis 6.0 Redis 6.2 Redis 7.0 Valkey 7.2 Valkey 8.0
1 Lettuce 5.x ✓ ✓ ✓ ⚠️ 部分支持 ⚠️ 部分支持 ❌ 不支持
2 Lettuce 6.x ✓ ✓ ✓ ✓ ✓ ✓
3 Jedis 3.x ✓ ⚠️ 部分支持 ⚠️ 部分支持 ❌ 不支持 ❌ 不支持 ❌ 不支持
4 Jedis 4.x ✓ ✓ ✓ ✓ ✓ ⚠️ 部分支持
5 redis-py 3.x ✓ ⚠️ 部分支持 ⚠️ 部分支持 ❌ 不支持 ❌ 不支持 ❌ 不支持
6 redis-py 4.x+ ✓ ✓ ✓ ✓ ✓ ✓
7 ioredis 4.x ✓ ✓ ✓ ✓ ✓ ✓
8 ioredis 5.x+ ✓ ✓ ✓ ✓ ✓ ✓
9 go-redis v8 ✓ ✓ ✓ ⚠️ 部分支持 ⚠️ 部分支持 ⚠️ 部分支持
10 go-redis v9+ ✓ ✓ ✓ ✓ ✓ ✓
11 StackExchange.Redis 2.5.x ✓ ✓ ✓ ⚠️ 部分支持 ⚠️ 部分支持 ❌ 不支持
12 StackExchange.Redis 2.6.x+ ✓ ✓ ✓ ✓ ✓ ✓

6. 相关内容推荐

6.1数据库产品最新动态

6.2 AWS Marketplace 合作伙伴推荐

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

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

本篇作者

王志广

亚马逊云科技数据库专家，十余年数据库行业经验，具有丰富的大规模数据库架构的设计和运维经验。

陈阳

亚马逊云科技数据库专家架构师，十余年数据库行业经验，主要负责基于亚马逊云计算数据库产品的解决方案与架构设计工作。