Proxy 模式 Redis 集群跨云迁移至 Amazon ElastiCache：Valkey 9.0 集群多 DB 能力落地实践

摘要：将 Proxy 模式多 DB Redis 集群迁移至 Amazon ElastiCache：基于 Valkey 9.0 集群多 DB 能力，覆盖架构选型、数据同步、Redisson 适配与跨 Slot 兼容性实测。

一、背景与需求

在企业级缓存服务的实际使用中，多 DB（多数据库）隔离是一种常见的架构模式。通过将不同业务的数据存放在不同的 DB 编号中，团队可以实现逻辑隔离而无需部署多个独立实例，降低运维成本的同时保持命名空间清晰。

在跨云迁移场景中，一类常见的源端形态是 Proxy 模式的 Redis 兼容集群服务：Proxy 层透明支持多个 DB，应用通过 Redisson SingleServer 模式连接 Proxy 端点，使用 SELECT 命令切换 DB，代码中无需感知后端集群拓扑。我们在一个真实的企业客户迁移项目中就遇到了这一典型架构，客户在其他云平台运行着多个采用该模式的缓存实例。

在向亚马逊云科技迁移时，这类架构会遇到一个核心技术约束：开源 Redis Cluster 从 3.0 版本（2015 年）起仅支持 SELECT DB0（参见 Redis SELECT 命令文档）。这意味着如果使用传统的 Redis 集群方案，原本用 DB 编号隔离的多个业务需要拆成与 DB 数量相当的多个独立集群，显著增加运维复杂度与成本。

Valkey 9.0 在集群模式下原生支持多 DB，社区版于 2025 年 10 月 21 日正式发布（GA）。2026 年 5 月 5 日，亚马逊云科技宣布 Amazon ElastiCache 支持 Valkey 9.0，Serverless 缓存和 Node-based 集群均可使用。关于该功能的详细介绍，请参阅 Amazon ElastiCache now supports Valkey 9.0 和 Valkey 9.0 Numbered Databases。这一能力通过新增的 cluster-databases 配置参数实现，为 Proxy 模式 Redis 集群的迁移提供了原生的目标方案。

本文详细介绍 Proxy 模式 Redis 集群跨云迁移到 Amazon ElastiCache Valkey 9.0 的迁移方案，涵盖目标架构选型、集群配置、数据同步、Redisson 客户端适配与集群模式兼容性验证等关键环节。

二、为什么是 Amazon ElastiCache Valkey 9.0

Valkey 9.0 的关键变化：集群模式原生支持多 DB

Redis/Valkey 在非集群（单分片）模式下一直原生支持多 DB 和 SELECT；真正的空白在于集群（分片）模式（如第一章所述，开源实现自 2015 年起仅保留 DB0）。Valkey 9.0 填补的正是这个空白：数据的物理位置依然只由 key 名决定（CRC16(key) % 16384 计算 Slot），DB 编号则提供正交的命名空间——同一个 key 可以在不同 DB 各存一份，且始终落在同一个 Slot。

对迁移而言，这意味着 ElastiCache Valkey 9.0 提供了“集群 + 多 DB” 的原生方案：从 Proxy 模式多 DB 集群迁移时，既可以保持 DB 编号 1:1 映射、应用逻辑基本不变，也无需再依赖私有代理层。

实践中的判断标尺是单分片容量：容量可容纳时，迁移到 Node-based（CMD）即可原生使用多 DB；数据量超出单分片上限、必须横向分片时，才进入本文重点讨论的集群多 DB 场景。

三、三条迁移路线：目标架构选型

基于上述前提，从 Proxy 模式 Redis 迁移到 Amazon ElastiCache 有三条目标路线：

三条路线的本质差异在于协议语义：

• Node-based（CMD）：非集群模式，跨 Slot 限制不存在；只能纵向扩展到单个最大节点规格，不支持数据分区
• Serverless：集群模式，底层拓扑由服务托管并以单一虚拟节点呈现；客户端无需处理节点拓扑，但多 key 操作仍受跨 Slot 限制（详见第八章）
• Node-based（CME）：集群模式，客户端通过 ClusterServers 处理节点发现与路由；支持多分片横向扩展，客户端需支持集群模式指定 DB（详见第七、八章）

本文后续的配置、同步与验证以 Node-based（CME）为主。

多 DB 的适用边界：无论哪条路线，多 DB 都只是逻辑命名空间，规划时需了解其固有局限。Redis 与 Valkey 官方文档均建议多 DB 用于隔离同一应用内的 key，而非在单一实例中承载多个无关应用。更多设计说明详见 Valkey 官方博客 Numbered Databases in a Cluster。

在 Valkey 9.0 之前，这类迁移的通行做法为：按 DB 拆分为多个独立实例，统一使用 DB0。这条传统路线今天依然成立——它是唯一提供物理资源隔离的方案，适合各 DB 需强隔离或分属不同团队的场景，代价是实例数与连接配置成倍增加。Valkey 9.0 的意义在于让”拆分”从唯一选项变成可权衡的选项之一（选型对比见第九章）。

四、整体迁移架构

[架构图 1：Proxy 模式 Redis 集群跨云迁移至 Amazon ElastiCache 的迁移路线]

图示说明：左侧为源环境（Proxy 模式 Redis 兼容集群及以 SingleServer 模式连接的微服务）；右侧 AWS Cloud 内，EC2 上的同步工具作为迁移通道，执行全量 RDB + 增量持续同步（支持按 DB 过滤）。实线箭头指向三条主路线 ①②③（橙色高亮为本文重点路线 ③），虚线为传统拆分路线（DB 编号归 0）。应用切换仅需修改 endpoint 并启用 TLS。

五、Amazon ElastiCache Valkey 9.0 集群配置

5.1 自定义参数组

启用集群模式多 DB 需要创建自定义参数组，核心是设置 cluster-databases 参数：

# 创建参数组
aws elasticache create-cache-parameter-group \
  --cache-parameter-group-family valkey9 \
  --cache-parameter-group-name valkey9-cluster-multidb \
  --description "Valkey 9 cluster mode with multi-DB support"
# 配置集群模式与多 DB
aws elasticache modify-cache-parameter-group \
  --cache-parameter-group-name valkey9-cluster-multidb \
  --parameter-name-values \
    "ParameterName=cluster-enabled,ParameterValue=yes" \
    "ParameterName=cluster-databases,ParameterValue=16"

注意点：

• 默认参数组 default.valkey9.cluster.on 未启用多 DB（默认值下集群仅有 DB0），必须使用自定义参数组才能启用。
• 最大 DB 数 cluster-databases 仅在创建集群时生效，建成后不可修改，建议按”源端最大 DB 编号 + 余量”一次规划到位。范围允许（1-10000）。Serverless 固定 1024，不可配置。

各参数取值范围请参阅 ElastiCache 引擎参数文档；cluster-databases 的协议层定义参见 Valkey Cluster Spec。

5.2 创建集群

Node-based 模式（大容量场景，成本更优）：

aws elasticache create-replication-group \
  --replication-group-id valkey9-multidb-node \
  --replication-group-description "Valkey 9.0 cluster with multi-DB" \
  --engine valkey \
  --engine-version 9.0 \
  --cache-parameter-group-name valkey9-cluster-multidb \
  --cache-node-type cache.r7g.large \
  --num-node-groups 2 \
  --replicas-per-node-group 1 \
  --transit-encryption-enabled \
  --auth-token <your-auth-token> \
  --cache-subnet-group-name <your-subnet-group> \
  --security-group-ids <your-security-group-id> \
  --automatic-failover-enabled \
  --multi-az-enabled

注：--auth-token 即后文数据同步与客户端配置中使用的访问密码（使用它的前提是启用传输加密）

5.3 验证多 DB 功能

# 连接 Node-based（CME）（-c 跟随集群重定向；连接 Serverless 时可省略 -c）
redis-cli -c -h <endpoint> -p 6379 --tls -a <your-auth-token>
# 验证 SELECT 在集群模式下正常工作
SELECT 5
SET mykey "db5_value"
SELECT 10
SET mykey "db10_value"
SELECT 5
GET mykey   # 返回 "db5_value"，DB 间完全隔离
# 验证 Slot 计算与 DB 编号无关：同一 key 在任何 DB 下 Slot 恒等
CLUSTER KEYSLOT mykey

六、数据同步

将源端多 DB 数据迁移到 Valkey 9.0，关键诉求是：全量 + 增量持续同步、保持 DB 编号不变、以及在同步时按 DB 选择性过滤临时数据。可借助成熟的开源同步工具（如 redis-shake）完成，整体流程如下：

• 同步工具连接源端，触发全量 RDB 传输
• 全量数据按 DB 过滤后写入目标 Valkey 集群，DB 编号保持不变（自动路由到正确分片）
• 全量完成后切换为增量模式，实时同步后续写入
• 在迁移窗口内完成数据核对，确认后切换流量

以 redis-shake v4.6 为例，多 DB 同步的最小配置如下（源端为 Proxy 端点时按单机模式读取；目标端为 Node-based 集群时开启 cluster 写入；按 DB 过滤使用 [filter] 段的 allow_db，例如仅迁移业务 DB、跳过存放临时数据的 DB）：

[sync_reader]
cluster = false                             # 源端 Proxy 端点，按单机模式读取
address = "source-redis.example.com:6379"
password = "<source-password>"

[redis_writer]
cluster = true                              # 目标为集群模式
address = "clustercfg.valkey9-xxx.cache.amazonaws.com:6379"
tls = true                                  # 目标集群已启用传输加密（对应第五章配置）
password = "<your-auth-token>"

[filter]
allow_db = [5, 10, 14]                      # 仅同步业务 DB，其余 DB 跳过

需要更复杂的过滤逻辑（如按 DB 组合 key 前缀规则）时，可改用 [filter] 段内的 function Lua 脚本实现。

分片源端的同步

当源端本身就是分片集群（每个分片承载多 DB）时，同步方式一致：将同步工具配置为集群模式直连源端各分片节点（cluster 读取），从多个主节点并行拉取，源端 key 经重新计算 Slot 后写入目标集群对应分片，DB 编号保持不变。

七、客户端适配

Node-based（CME）需要客户端支持集群连接并指定 database；Node-based（CMD）使用 SingleServer；Serverless 可使用 SingleServer 或 ClusterServers，两种连接模式的跨 Slot 行为不同（见第八章）。

7.1 存量应用的典型现状 （示例）

以一个典型的存量应用为例：Redisson 3.17.3 + Spring Boot 2.x，通过 useSingleServer() 模式连接源端 Proxy：

config.useSingleServer()
    .setAddress(prefix + host + ":" + port)
    .setDatabase(redisProperties.getDatabase())  // 如 DB14
    .setPassword(redisProperties.getPassword())
    .setConnectionMinimumIdleSize(5);

由于源端 Proxy 屏蔽了集群细节，对 Redisson 来说就像连接一台单机 Redis。

7.2 方案 A：Node-based（CMD）或 Serverless（SingleServer）

Node-based（CMD）和 Serverless 都可以保持 Redisson SingleServer 配置，更换 endpoint 并启用 TLS。两者协议语义不同：Node-based（CMD）没有 Slot 限制；Serverless 属于集群模式，跨 Slot 有限制，具体行为见第八章。

# 迁移前（源端 Proxy 模式 Redis）
spring:
  redis:
    host: source-redis.example.com
    port: 6379
    password: <password>
    database: 14
# 迁移后（Amazon ElastiCache Valkey 9.0 Serverless）
spring:
  redis:
    host: valkey-xxx.serverless.usw2.cache.amazonaws.com
    port: 6379
    password: <password>
    database: 14      # DB 编号不变
    ssl: true         # 新增：ElastiCache Serverless 默认强制传输加密

7.3 方案 B：Node-based（CME，需升级 Redisson 4.x）

对于大容量实例，Node-based 集群模式成本更优。但此时客户端需要从 SingleServer 切换到 ClusterServers 模式，并且需要在集群模式下指定 DB。

背景：在集群模式只支持 SELECT 0 的十年间，主流集群客户端（Redisson、Jedis、Lettuce）均未实现集群 database 能力；Valkey 9.0 解除该限制后，Redisson 在 4.0 大版本中新增了 clusterServersConfig.database 参数。

7.3.1 升级路径：从 3.17.3 升级到 4.5.0

7.3.2 Redisson 4.x 集群 + 多 DB 配置

# redisson-cluster.yml
clusterServersConfig:
  nodeAddresses:
    - "valkeys://clustercfg.valkey9-xxx.cache.amazonaws.com:6379"
  password: <your-auth-token>
  database: 14         # Redisson 4.0 新增，保持原 DB 编号
  scanInterval: 2000
  slaveConnectionMinimumIdleSize: 4
  slaveConnectionPoolSize: 16
  masterConnectionMinimumIdleSize: 4
  masterConnectionPoolSize: 16
  readMode: "SLAVE"
  timeout: 3000
  connectTimeout: 5000
  retryAttempts: 3

若应用有自定义的 Redisson 配置类，Cluster 分支相应增加 setDatabase()：

// 原代码（3.17.3，Cluster 分支无 database）
config.useClusterServers()
    .addNodeAddress(nodes)
    .setConnectTimeout(timeout)
    .setPassword(redisProperties.getPassword());
// 升级后（4.X+，新增 database）
config.useClusterServers()
    .addNodeAddress(nodes)
    .setConnectTimeout(timeout)
    .setPassword(redisProperties.getPassword())
    .setDatabase(redisProperties.getDatabase());  // 新增

八、集群模式兼容性验证

集群协议的基本规则是：一条命令、EVAL 脚本或事务涉及的多个 key 必须位于同一 Slot，否则返回 CROSSSLOT。Serverless 与 Node-based（CME）均遵循该规则；差异主要来自 Redisson 连接模式对部分操作的封装。

本文使用 Redisson 4.5.0，以 foo（Slot 12182）和 bar（Slot 5061）完成以下实测：

redis-cli 原生命令在 Serverless 与 Node-based（CME） 上表现一致：跨 Slot 的 MGET、WATCH、RENAME 均返回 CROSSSLOT。Redisson RBucket.rename() 在 ClusterServers 模式下可以成功，但这属于客户端 API 行为，不能据此判断原生 RENAME 支持跨 Slot。

跨 Slot 操作有三种处理方式：

• hash tag：使用 {user:1001}:profile、{user:1001}:orders 将相关 key 固定到同一 Slot；tag 粒度应足够分散，避免热点
• Pipeline / Batch：适用于可拆成彼此独立、且不要求原子性的批量读写；不能替代集合运算、Lua 或事务
• ClusterServers：Redisson 可处理跨 Slot MGET；不适用于 SINTER、EVAL 多 key 和事务

Serverless 的 cluster-enabled 固定为 yes（ElastiCache 配置与限制），并非单机协议。官方文档也明确规定 WATCH 仅作用于单一 Slot（ElastiCache Serverless WATCH）。另一个需要区分的行为是全库命令：Node-based（CME）的 FLUSHDB/FLUSHALL 需发送到每个主节点；Serverless 会清空全集群，但不保证跨 Slot 原子性。

迁移后使用生产客户端配置复测多 DB 隔离、分布式锁、业务涉及的多 key 操作及 Pipeline 吞吐，并使用与生产一致的节点规格和分片数进行压测。

九、迁移方案总览

Valkey 9.0 解决了集群模式无法使用多 DB 的问题，但没有取消集群协议的 Slot 约束。目标架构应先按容量和隔离需求选型，再依据第八章的实测结果处理多 key 操作。

十、相关链接

• Amazon ElastiCache 开发者指南
• Amazon ElastiCache 部署选项（含 Serverless）
• ElastiCache 引擎参数文档
• Valkey 9.0 Numbered Databases 功能介绍
• Valkey Cluster Spec
• Redis SELECT 命令文档（多 DB 使用建议）
• Valkey SELECT 命令文档（多 DB 使用建议）
• redis-shake 数据同步工具
• Valkey GLIDE 官方客户端
• Redisson 官方文档

➡️ 下一步行动：

相关产品：

• Amazon ElastiCache — 无服务器缓存
• Amazon Connect — AI 客户体验解决方案
• Amazon Batch — 完全托管式批处理
• Amazon EC2 — 安全且可调整大小的计算容量

相关文章：

• 构建 Amazon ElastiCache OSS Caches 慢查询监控方案
• Valkey 为什么这么快？盘点 Valkey 中提升性能的黑科技
• 基于 Amazon Bedrock AgentCore 与 AWS DevOps Agent 打造对话式多账户运维助手
• 从自建 Elasticsearch 迁移到 Amazon OpenSearch Service 实践（一）：数据迁移与同步

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

本篇作者

AWS 架构师中心：云端创新的引领者 探索 AWS 架构师中心，获取经实战验证的最佳实践与架构指南，助您高效构建安全、可靠的云上应用