后端开发者的 AWS Redis 避坑指南：ElastiCache 与 MemoryDB 该怎么选？

China_Yanhy · 2026-01-09 15:54:57 发布

当你打开 AWS 控制台搜索 "Redis" 时，迎面而来的选项——ElastiCache (Redis OSS/Valkey)、MemoryDB、Memcached——往往让人困惑。

作为一个习惯了 "Spring Boot + Redis" 的后端开发者，你可能会问：“不就是一个 KV 缓存吗？为什么要分这么细？我的业务到底该用哪个？”

本文将从引擎层（软件）和架构层（服务定位）两个维度，为你拆解这些选项背后的技术逻辑与业务场景。

在 ElastiCache 服务下，你需要先决定用什么“软件”来跑你的缓存。

这是最关键的选择：ElastiCache vs. Amazon MemoryDB。

虽然它们连上去都像 Redis，但在对待**“数据丢不丢”**这件事上，它们有着本质的区别。

“我是短跑运动员，追求极致速度，身上不带包袱。”

技术原理：
- 数据主要存在 RAM (内存) 中。
- 虽然有主从复制（Replication）和 AOF/RDB 备份，但在极端故障（如机房断电）的瞬间，可能会丢失最近 1秒的数据。
- 它假设你的数据在 MySQL/S3 里有“兜底”。
你的 Java 代码心态：
- “Redis 里没查到？没事，我去查数据库，然后回写到 Redis。” (Cache-Aside Pattern)
典型场景：
- Session 存储：丢了用户重新登录就行。
- 页面/API 缓存：丢了重新计算就行。
- 非关键排行榜：丢了重新统计就行。

“我是运钞车，虽然比短跑慢一点点，但一分钱都不会丢。”

技术原理：
- 它是一个兼容 Redis 协议的数据库。
- 分布式事务日志：当你执行 SET 或 DECR 时，它不仅写内存，还会强制把操作记录写入跨 3 个可用区（AZ）的硬盘日志中。只有日志落盘成功，才给你返回 OK。
- 持久性：它承诺的数据安全性 = Amazon RDS (MySQL)。
你的 Java 代码心态：
- “写进这里就安全了，不用再写 MySQL 了。” (Redis as a Primary DB)
典型场景：
- 秒杀库存扣减 (DECR inventory)：绝对不能超卖，不能回滚。
- 游戏/金融账户余额：钱的事，一分都不能差。
- 高频状态机：订单流转状态，它是唯一的真理源。

为了帮你做最终决定，我们将两者进行硬核对比：

你可能会问：“我为什么要花大价钱用 MemoryDB？我原来的架构（Redis + MySQL）不是挺好吗？”

原因在于：消除“双写一致性”的噩梦。

传统做法 (ElastiCache + MySQL)：
1. 你先在 Redis 扣库存（快）。
2. 然后你试图异步把库存写回 MySQL（为了持久化）。
3. 风险：如果 Redis 扣完挂了，还没来得及写 MySQL。重启后 Redis 库存回滚，导致你多卖了货（超卖）。或者你需要写极其复杂的补偿逻辑（Lua 脚本 + 消息队列）。
现代做法 (MemoryDB)：
1. 你直接在 MemoryDB 扣库存。
2. 结束。
3. 优势：MemoryDB 保证了只要 DECR 成功，数据就永久存下来了。你不需要维护 MySQL，不需要处理双写，代码逻辑瞬间简化。

如果你决定在你的 EKS 环境中使用它们，请注意以下工程细节：

VPC 网络：
- 这两者默认都跑在 VPC 内部。你的 EKS Pod 必须在同一个 VPC，或者通过 VPC Peering 连接。公网是连不上的。
安全组 (Security Group)：
- 记得在 ElastiCache/MemoryDB 的安全组入站规则里，放行来自 EKS 节点安全组 的 6379 端口流量。
连接模式：
- ElastiCache：通常可以选“非集群模式”，Java 配置简单。
- MemoryDB：强制开启集群模式 (Cluster Mode Enabled)。你的 Java 配置文件（如 application.yml）里必须配置为 Redis Cluster 模式，且客户端建议开启 TLS (SSL) 加密。