ElastiCache 与 Valkey 的无序扩张问题
当您刚开始小规模使用时，ElastiCache 看起来简单明了。每个工作负载都绑定到其自己的集群，因此团队会随着应用的扩展而启动新集群。久而久之，这就造成了“无序扩张”：数十甚至数百个集群散布在不同的账户和环境中。
无序扩张主要带来四大挑战：
- 运维开销：需要预配、修补、监控、备份和测试故障转移的集群越来越多，每个集群都有其独立的安全组和参数组。
- 资源浪费：未使用的计算和内存资源被困在相互隔离的集群内部。
- 更高的云账单：为无法共享或重用的容量付费。
- 规模优化的阻力：部署时所做的选择，如节点类型、分片数量和参数组，日后难以更改，否则将面临风险、需要多方协调并安排停机窗口。团队往往宁愿维持次优的资源占用，也不愿进行重构，这随着时间的推移进一步加剧了 ElastiCache 的无序扩张。此外，每个集群的 CPU、内存和网络 I/O 都需要预先规划，这通常意味着要么进行负载测试，要么就只能过度估算和超额支出。
ElastiCache 的无序扩张起初看起来并无大碍。一个团队为每个应用启动一个集群以保持简单，但这种简单状态并不会持续太久。开发、预发和生产环境接踵而至。流量变化和季节性波动迫使容量出现峰值，团队因此不得不建立额外的集群。随着应用的演进，团队会隔离具有不同需求的工作负载，将用户会话数据、缓存和流数据分离开来，以便它们可以独立扩展。接着，资源足迹遍布全球。一个部署在多个区域的应用也需要在这些区域建立本地缓存，于是这种模式在地理上被成倍复制。
随后，组织层面的无序扩张开始显现。不同的业务部门各自预配自己的集群。一个他们在 2024 年为某次活动而扩容的集群至今仍在以当时的规模运行，因为更改节点类型、分片数量或参数组这些工作的优先级低且耗时。整合工作被一再推迟，于是昨天的部署决策变成了今天的固定成本。最终结果便是一个碎片化的集群舰队，伴随着数据孤岛、飙升的成本以及开发与运维团队之间持续不断的摩擦。
AWS 在 ElastiCache 中从 Redis 转向 Valkey 并不能解决这个问题。Valkey 遵循同样的“每个工作负载一个集群”的模型，因此随着部署规模的增长，用户将继续面临无序扩张和同样的规模优化惯性。
AWS 从 Redis 转向 Valkey 的风险
ElastiCache 用户还需要权衡 AWS 从 Redis 转向 Valkey 所带来的影响。尽管 Valkey 与 Redis 7+ 保持了基本的 API 兼容性，但仍存在风险：
- 兼容性差距：Valkey 不支持更新的 Redis 版本，这些新版本带来了超过 150 个新命令和 8 个新数据结构。不仅如此，Valkey 在创新方面也落后于 Redis 8 和 Redis 8.2，例如哈希字段过期、向量搜索、向量集、广泛的性能提升以及流处理的改进。
- 创新放缓：除了开源社区，Redis 还得到一家资金雄厚、专注于 Redis 且拥有明确路线图的公司支持。而 Valkey 依赖于社区贡献，这些贡献来去不定，交付新功能的速度也更慢。
- 锁定风险：AWS 优化 ElastiCache 的目的是向您销售更多的 AWS 基础设施，而不是为了推动 Valkey 的发展。对于那些希望在多云或混合环境中保持可移植性的组织而言，这种利益冲突限制了其灵活性。
对于依赖 ElastiCache 的团队来说，这意味着今天需要管理更多的集群，而明天则要面对兼容性的不确定性。
Redis 架构的战略优势
Redis 通过将高效率与弹性运维、全面的安全性以及针对复杂环境的优化相结合，避免了这种无序扩张。我们的目标是让管理 Redis 和使用 Redis 一样简单。
架构师和开发者将获得：
- 资源效率：多租户与集中式管理。
- 前沿创新：用于二级索引和搜索的 Redis 查询引擎、用于 AI 工作负载的向量搜索、语义缓存以及智能体记忆模式。
- 可移植性：在 Redis Cloud 和 Redis Software 之间、在不同云厂商之间以及在各种部署环境中提供一致的 Redis 体验。
对于架构师而言：这意味着更简洁的设计和更低的成本。对于开发和运维团队而言：这意味着活动部件更少，交付新应用和服务的速度更快。
结论
ElastiCache 和 Valkey 要求为每个工作负载建立独立的集群，这必然导致无序扩张。Redis 通过多租户和集中式管理减少了无序扩张，从而在规模化时提供了更高的效率。我们不断在缓存之外进行创新以支持现代工作负载，而 AWS 转向 Valkey 则给用户留下了兼容性风险和更多的运维开销。