缓存与 KV 工具
缓存位于应用与权威数据源之间，用更短的访问路径换取更低延迟和更高吞吐。这个交换会引入旧值、双写、淘汰、热点、容量、冷启动和故障转移问题，因此缓存不是“更快的数据库”，也不能因为部署了集群就自动获得正确的数据语义。
这一知识域包含三个主工具：Redis、Valkey 和 Memcached。三篇文章分别讲清产品、命令、部署、项目接入、性能容量、安全、高可用和故障处理；本页只负责确定应该读哪一篇以及选择前必须验证什么。
三种工具分别解决什么问题
| 工具 | 核心定位 | 数据与内存模型 | 可用性与分片 | 最重要的边界 |
|---|---|---|---|---|
| Redis | 支持多种数据结构、原子命令、Lua、持久化、复制和集群的内存数据存储 | String、Hash、List、Set、Sorted Set、Stream 等对象共享实例内存，过期和淘汰策略由服务端执行 | 单机、主从、Sentinel、Cluster；Cluster 由服务端维护槽位与节点关系 | 持久化不等于零丢失，副本不等于备份，复杂命令、大 Key 和热点 Key 仍会阻塞或压垮节点 |
| Valkey | 延续 Redis 协议生态并采用开源社区路线的内存数据存储 | 与 Redis 具有较高兼容基础，但命令、模块、版本能力和客户端认证必须逐项验证 | 支持复制、Sentinel 和 Cluster，迁移时还要验证槽位、持久化文件和运维工具 | “协议兼容”不代表所有命令、配置、模块、客户端和故障行为永久相同 |
| Memcached | 以简单 Key/Value、低协议开销和易失缓存池为核心的分布式内存缓存 | item 进入 slab class，由分段 LRU 管理；服务端不提供 Redis 式丰富数据结构 | 常见方式是客户端分片，也可使用内置 proxy；没有服务端复制和自动数据恢复 | 节点变化会造成重映射和大面积 miss，重启即冷缓存，不能承担唯一 Session 或事实数据 |
选择顺序
先判断数据能否丢失。缓存全失后如果不能从数据库、对象存储、搜索索引或其他权威来源重建，就不应把它只放在 Redis、Valkey 或 Memcached 中；需要先建立事实存储、日志或可靠消息链路。
数据允许丢失后，再判断是否需要服务端数据结构、原子脚本、持久化、复制和自动分片。需要这些能力时优先进入 Redis 与 Valkey 的版本、许可、兼容和运维比较；只需要简单易失 Key/Value，并愿意由客户端承担路由、故障和回源保护时，再评估 Memcached。
最后判断团队能否承担故障成本。功能最多的方案不一定最合适：Redis Cluster 带来槽位、拓扑和重定向复杂度；Valkey 迁移带来版本与生态兼容验证；Memcached 的简单性则把节点路由、缓存重建和高可用责任转移给应用。
架构决策不能只看功能表
| 决策问题 | 需要得到的证据 | 证据不足时的后果 |
|---|---|---|
| 缓存数据允许旧多久 | 业务 TTL、主动失效链路、读取一致性实验 | 用户持续读到旧状态，删除或更新后无法收敛 |
| 缓存全失如何恢复 | 峰值回源 QPS、预热速度、数据库限流和熔断实验 | 重启或故障转移后形成缓存雪崩 |
| Key 如何分布 | Key 规范、对象尺寸、热点分布、真实客户端路由测试 | 单节点热点、内存倾斜或跨语言访问不同节点 |
| 内存如何退出 | 最大容量、过期率、淘汰策略、Value 尺寸和碎片指标 | 内存未按预期释放、写入失败或频繁 eviction |
| 故障后允许丢多少 | RPO、持久化与复制配置、客户端确认语义 | 把异步复制或缓存持久化误当成零丢失保证 |
| 多久恢复服务 | RTO、探测窗口、切换链、连接刷新和下游余量 | 节点已切换但应用仍访问旧主或持续重试 |
| 谁能访问和管理 | 网络边界、认证授权、TLS、危险命令和密钥轮换 | 缓存暴露、数据泄露或误执行全量清理 |
三种典型使用方式
Cache Aside 由应用先读缓存，miss 后读取权威数据源并回填；更新时先提交权威数据，再删除或更新缓存。它最常见，也最容易受到并发回填、双写窗口和删除失败影响，需要单飞、短 TTL、重试边界和消息补偿。
读穿与写穿把缓存操作封装到统一数据访问层，业务代码更简单，但缓存层必须明确事务边界、错误传播和事实数据归属。写回模式把修改延迟写入权威存储，能够合并写入，却会显著增加数据丢失、顺序、幂等和恢复复杂度，不能因为性能压力就直接采用。
本地缓存与分布式缓存组合可以降低网络开销和热点压力，但会增加一层失效传播。必须为本地缓存设置更短 TTL 或版本标识，并验证实例之间的旧值窗口，而不是只观察整体命中率。
阅读路径
第一次建立缓存系统时，先阅读 Redis 的单机部署、数据结构、TTL、Cache Aside、持久化和故障处理，再根据真实需求进入主从、Sentinel 或 Cluster。目标是从 Redis 迁移或评估开源社区路线时，继续阅读 Valkey 的版本兼容、命令差异、持久化文件、客户端、Sentinel 与 Cluster 迁移实验。
业务只需要简单易失 KV，或者正在维护 Memcached 缓存池时，直接阅读 Memcached 的 Basic/Meta 协议、item/slab、分段 LRU、客户端分片、built-in proxy、冷启动和 30 类故障闭环。不能接受 Session 丢失、没有稳定权威数据源或无法保护下游时，应回到存储架构重新选型，而不是继续增加缓存节点。