亚马逊云科技最近为Amazon ElastiCache for Valkey引入了持久化功能，支持在故障情况下可靠地保留数据，并将适用场景从缓存扩展到持久化工作负载。该功能提供优先最小化数据丢失或维持更低写入延迟的选项，扩展了该 Redis 分支的使用场景，包括 AI 内存、会话存储和实时应用等。

ElastiCache for Valkey现在既支持缓存也支持持久化数据工作负载。开发者可以选择同步持久化以在故障时将数据丢失降到最低，，也可以选择异步持久性以获得更低的延迟。对于可以从数据源重建数据的缓存场景，传统不带持久化功能的 ElastiCache 仍然是默认且最便宜的选项。亚马逊云科技的软件工程师Jules Lasarte与高级产品经理Karthik Konaparthi这样说到：

许多组织发现 ElastiCache 中的多可用区复制和自动故障切换满足了他们的韧性需求，但随着客户越来越多地将 ElastiCache 作为持久化数据存储而不仅仅是缓存，数据丢失成为首先要关注的问题。

除缓存外，ElastiCache 现在也可用于持久化数据工作负载，包括 AI 智能体的内存、工作流状态、RAG 知识库、支付令牌化以及库存管理。

来源：亚马逊云科技博客

虽然这两种持久化模式均能保持微秒级的读取延迟，但同步写在数据被复制到至少两个可用区后才会被确认，从而以更高的写入延迟换取更低的数据丢失风险。异步写在复制完成前就会被确认，保留了较低的写入延迟，但存在最多丢失最近约 10 秒数据的风险。Lasarte 与 Konaparthi 补充说：

为了约束异步写入可能导致的数据丢失，ElastiCache 强制执行最多 10 秒的持久性缓冲区。主节点会持续追踪已被接受但尚未持久化到多可用区事务日志的最陈旧写操作的年龄，并将该值作为 DurabilityLag 指标发布到 Amazon CloudWatch。（...）如果缓冲区增长超过 10 秒，例如，由于到事务日志的瞬时网络拥塞，主节点会临时拒绝传入的写命令，直到追上进度为止。

读取延迟保持不变，但如果复制延迟过大，写入可能会被临时拒绝。集群赶上进度后会自动恢复正常运行，团队建议像Valkey GLIDE这样的客户端开启自动重试和指数退避（exponential backoff）。The Duckbill Group 的首席云经济学家 Corey Quinn 在他的通讯中警告说：

我再次恳求你们不要把“缓存（cache）”与“主数据存储（primary data store）”混淆。你们依然会忽视我的建议，因为有些教训只能通过 SLA 违规来学习和内化。

虽然 ElastiCache 支持 Valkey、Memcached 和 Redis，但这个新功能仅对 Valkey 可用。在 Reddit 上，开发者对该选项表示欢迎，但也质疑它是否会取代专门面向需要低延迟与持久化数据存储的应用的 Redis 兼容内存数据库 Amazon MemoryDB（参见相关的讨论）。

从 Valkey 9.0 起，ElastiCache 的持久化功能在所有区域均可用。

查看英文原文：AWS Introduces Durable Storage Option for ElastiCache for Valkey