亚马逊云科技为ElastiCache for Valkey推出持久化存储选项

亚马逊云科技最近为 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 "