1. 为什么Redis选型让后端开发者头疼?
上周帮一个做社交APP的团队排查性能问题,发现他们用错了Redis服务——把需要持久化的会话数据放在了ElastiCache上,结果一次AZ故障导致三天数据丢失。这不是个例,我见过太多团队在AWS的Redis服务选型上踩坑。
AWS提供了两种全托管的Redis服务:ElastiCache和MemoryDB。表面看都是Redis,但底层架构和适用场景天差地别。选错不仅浪费钱,更可能引发数据丢失、性能抖动这些生产级事故。今天我们就从实战角度,拆解这两个服务的核心差异。
需要模型API调用? 免费领10W Token,多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 架构原理深度对比
2.1 ElastiCache:为性能而生的缓存服务
ElastiCache采用经典的主从复制架构。当你创建一个Redis集群时,AWS会在后台做这些事:
- 在指定AZ启动主节点
- 自动配置1-5个只读副本(可跨AZ)
- 通过Sentinel管理故障转移
但关键点在于:所有写入仅存在于内存中。虽然支持RDB快照和AOF持久化,但:
- 默认情况下RDB快照间隔长达5分钟
- AOF日志需要手动开启
- 持久化文件存储在EC2实例的临时存储(节点终止即消失)
bash复制# 典型ElastiCache配置示例(CloudFormation片段)
Resources:
MyCacheCluster:
Type: "AWS::ElastiCache::CacheCluster"
Properties:
Engine: "redis"
CacheNodeType: "cache.r6g.large"
NumCacheNodes: 3
SnapshotRetentionLimit: 3 # 仅保留3个备份快照
AutomaticFailoverEnabled: true
重要提示:ElastiCache的Multi-AZ功能仅保证服务可用性,不保证数据持久性。去年我们有个客户在us-east-1遇到AZ级故障,虽然服务秒级切换,但未持久化的15分钟数据全部丢失。
2.2 MemoryDB:真正的持久化数据库
MemoryDB的架构颠覆了传统Redis实现:
- 每个分片包含1个主节
