AWS ElastiCache vs MemoryDB：到底该选哪一个？

Source: Dev.to

这篇文章最初发布在 Jo4 Blog 上。

TL;DR 决策树

Is your data ephemeral (can be regenerated/lost)?
├── YES → ElastiCache (~$12/month for cache.t4g.micro)
└── NO → MemoryDB (~$25+/month, durable storage)

我的使用案例：速率限制

对于 jo4.io，我需要 Redis 用于：

• 速率限制计数器（user:123:requests:minute）
• 会话缓存
• 临时功能标记

如果 Redis 挂掉并且我失去所有这些数据：

• 速率限制计数器会重置为 0（用户获得新的一分钟，不是大问题）
• 会话失效（用户需要重新登录，略有不便）
• 功能标记从数据库重新加载（短暂的卡顿）

结论：ElastiCache – 数据是短暂的。

何时使用 MemoryDB

MemoryDB 适用于 Redis 数据是您的 唯一可信来源 的场景：

• 排行榜/排名，无法重新计算
• 实时库存，Redis 本身即为数据库
• 会话数据，不能丢失（例如金融应用）
• 消息队列，丢失消息即导致交易丢失

MemoryDB 提供：

• 多可用区持久性（数据在节点故障时仍然保留）
• 事务日志持久性（写入被持久化）
• 时间点恢复

成本比较

MemoryDB 没有微型层级，因此最低成本更高。

我的 ElastiCache 设置

resource "aws_elasticache_cluster" "redis" {
  cluster_id           = "jo4-prod-redis"
  engine               = "redis"
  engine_version       = "7.1"
  node_type            = "cache.t4g.micro"
  num_cache_nodes      = 1
  port                 = 6379
  parameter_group_name = "default.redis7"

  subnet_group_name    = aws_elasticache_subnet_group.redis.name
  security_group_ids   = [aws_security_group.redis.id]

  # Daily snapshot, 7‑day retention (even ephemeral data is nice to have)
  snapshot_retention_limit = 7
  snapshot_window          = "02:00-03:00"
  maintenance_window       = "sun:03:00-sun:04:00"
}

In‑VPC 优势

我喜欢 ElastiCache 的一点是：在 VPC 内部时无需身份验证。

# application-redis.yaml
spring:
  data:
    redis:
      host: ${REDIS_HOST}
      port: ${REDIS_PORT}
      timeout: 5000
      # No password needed – security group controls access

相较于需要以下的 Redis Cloud：

• 用户名/密码
• TLS 配置
• 凭证轮换
• 与外部服务的网络连接

使用 In‑VPC ElastiCache，您将获得：

• 仅对您的 EC2 实例开放的安全组限制访问
• 无需管理凭证
• 无外部网络依赖
• 更低的延迟

从 Redis Cloud 迁移

如果您正从 Redis Cloud 迁移到 ElastiCache：

1. 更新连接配置 – 主机、端口，并移除认证。
2. 接受数据丢失 – ElastiCache 初始为空。
3. 确保 fail‑open 行为 – 您的应用应能优雅地处理空缓存。

对于速率限制和缓存来说，此迁移是微不足道的，因为数据本身就是临时的。

常见错误

1. 将 MemoryDB 用作缓存

大材小用。你在为不需要的持久性付费。

2. 将 ElastiCache 用于关键数据

如果在 Redis 中存储购物车或用户偏好而没有数据库备份，请改用 MemoryDB 或重新考虑架构。

3. 在生产环境中使用单可用区（Single‑AZ）ElastiCache

在生产工作负载中至少使用跨可用区的复制组。

4. 规模过大

从 cache.t4g.micro 开始。你随时可以向上扩展。监控内存使用和驱逐情况。

决策矩阵

摘要

• ElastiCache：快速、廉价、短暂。非常适合缓存和速率限制。
• MemoryDB：持久、更昂贵。适用于 Redis 作为主要数据库的情况。

别想太多。如果可以重新生成数据，使用 ElastiCache。

构建 jo4.io – 一个带分析功能的 URL 缩短服务。访问 jo4.io.