TL;DR
- 场景: 想学习 Netflix 的 EVCache 系统进行自研，但只了解它是「基于 Memcached 的分布式缓存」
- 结论: 拆解 EVCache/Rend/Memcached/Mnemonic 四层来理解缓存层职责、性能天花板与多可用区复制模型
- 产出: 实用架构理解框架 + 典型部署路径 + 常见错误速查卡
EVCache
EVCache 是 Netflix 开源的高性能分布式缓存系统，基于 Memcached 的内存存储架构，使用 Spymemcached 客户端实现。
EVCache 名称含义:
- E: Ephemeral（短暂的）- 数据存储有 TTL
- V: Volatile（易失的）- 强调非持久化
- Cache: 内存键值存储
主要特性:
- 通过一致性哈希实现线性扩展能力
- 多区域部署支持跨数据中心复制
- 完整的监控集成
- 智能客户端路由，自动处理节点故障和网络分区
性能指标:
- 单 EVCache 节点集群峰值: 200KB 请求/秒
- 全球部署: 数千个 memcached 服务器节点
- 每日峰值: 超过 3000 万次操作
- 存储对象: 50-1000 亿
- 每日请求: 近 2 万亿
- 正常负载下响应延迟: 1-5ms
- 99% 请求在 20ms 内完成
- 命中率: 维持在 99%
架构组件
Rend Service
- Go 语言编写的高性能代理服务
- 使用 goroutine 和 channel 机制实现轻量级并发处理
- 内置智能连接池
- 支持 Memcached 二进制和文本协议
- 使用一致性哈希做后端节点分布
Memcached
- 内存分布式键值存储系统
- 所有数据存储在 RAM 中，响应时间微秒级
- LRU 淘汰机制
- 单节点 QPS: 最高 50 万次/秒
Mnemonic
- 基于 SSD 的嵌入式键值存储引擎
- 深度集成 RocksDB
- 优化 SSD 的 Direct I/O
- 支持 WAL 数据持久化
- 随机读取延迟 < 1ms
典型部署
单可用区部署
集群启动阶段:
- EVCache 服务器实例自动注册到服务注册表
- 每个实例携带元数据：IP、端口、内存容量、负载状态、集群名称
- 客户端初始化阶段读取服务器列表，建立 TCP 长连接池
- 使用一致性哈希环进行虚拟节点分布
多可用区部署
跨可用区复制流程:
- 初始写入阶段: 应用发起 SET 操作，数据首先写入本地可用区缓存节点
- 元数据复制准备: EVCache 客户端生成包含 Key、操作类型、时间戳、源可用区的复制元数据消息
- 跨可用区数据传输: Propagator 通过内部网络向目标区域的 Replication Agent 发送 SET 请求
- 目标区域数据更新: Replication Agent 验证请求，在本地缓存集群执行相同的 SET 操作
错误速查
| 症状 | 根因 | 解决方案 |
|---|---|---|
| 业务将 EVCache 当作强一致持久存储 | EVCache 本质是 TTL + 易失内存缓存 | 使用数据库作为数据源，缓存仅用于加速 |
| 缓存命中率远低于预期 | Key 设计无热点复用、TTL/容量过小 | 优化 key 设计，设置合理 TTL |
| 可用区故障后其他区域读写延迟飙升 | 多可用区拓扑设计问题 | 本地读取，跨区域仅用于复制 |
| 增加或减少节点后缓存命中率显著下降 | 一致性哈希虚拟节点配置不当 | 调整虚拟节点数，使用滚动扩缩容 + 预热策略 |