1. 缓存基础概念：为什么需要缓存、缓存与数据库的差异、缓存带来的挑战
在构建高并发 Go 业务接口时，缓存是提升系统吞吐量与降低响应延迟的核心手段。本节从缓存存在的根本原因出发，厘清缓存与数据库的本质差异，并正视引入缓存后必须应对的三大挑战：一致性、穿透与雪崩。
1.1 为什么需要缓存
数据库（尤其是关系型数据库）的磁盘 I/O 与行级锁机制决定了其并发上限。当业务接口面临每秒数千甚至数万次请求时，直接查询数据库会导致连接池耗尽、响应时间飙升。缓存通过将热点数据存储在内存中，实现以下目标：
- 降低延迟：内存读取延迟通常在微秒级，而磁盘 I/O 在毫秒级，差距可达 1000 倍以上。
- 提升吞吐：单机 Redis 可支撑 10 万+ QPS，而单机 MySQL 通常在 1 万 QPS 左右即出现瓶颈。
- 保护后端：缓存作为流量缓冲层，防止突发流量直接冲击数据库，避免系统雪崩。
- 减少计算开销：对复杂聚合查询或计算结果进行缓存，避免重复计算。
性能对比参考： 一次 Redis 查询平均耗时 0.1~1ms，一次 MySQL 查询平均耗时 5~50ms（含网络与磁盘 I/O）。缓存命中率每提升 10%，接口平均延迟可降低 30%~50%。
1.2 缓存与数据库的差异
下表从多个关键维度对比缓存系统与关系型数据库，帮助架构师在设计时做出正确选择：
| 对比维度 | 缓存（如 Redis / Memcached） | 数据库（如 MySQL / PostgreSQL） |
|---|---|---|
| 存储介质 | 内存为主，部分支持持久化 | 磁盘为主，内存为缓冲池 |
| 数据模型 | Key-Value、简单结构 | 关系表、索引、事务 |
| 读写性能 | 极高（微秒级） | 中等（毫秒级） |
| 数据一致性 | 最终一致性为主 | 强一致性（ACID） |
| 持久化能力 | 弱（宕机可能丢数据） | 强（WAL、备份恢复） |
| 查询能力 | 简单键值查询 | 复杂 SQL、多表关联 |
| 容量成本 | 高（内存昂贵） | 低（磁盘廉价） |
| 典型用途 | 热点数据、会话、计数器 | 持久化存储、事务操作 |
架构原则： 缓存是数据库的加速层，而非替代层。所有写入操作应以数据库为准，缓存只承担读加速与临时写缓冲的角色。
1.3 缓存带来的三大挑战
引入缓存并非没有代价。以下三个问题在 Go 业务接口设计中必须提前规划应对策略。
1.3.1 缓存与数据库的一致性
当数据在数据库中被更新后，缓存中对应的旧数据需要同步失效或更新。常见的策略包括：
- Cache-Aside（旁路缓存）：读时先查缓存，未命中则查库并回写；写时先更新数据库，再删除缓存。
- 延迟双删：写操作先删除缓存，再更新数据库，延迟几百毫秒后再删除一次缓存，解决并发读写导致的脏数据。
- 订阅 Binlog 同步：通过 Canal / Debezium 监听数据库变更日志，异步刷新缓存。
常见陷阱： 先更新数据库再更新缓存，在高并发下会导致缓存与数据库数据不一致。推荐采用“先更新数据库，再删除缓存”的 Cache-Aside 模式。
1.3.2 缓存穿透
缓存穿透指请求查询一个既不在缓存中也不在数据库中的数据（如不存在的用户 ID）。由于缓存未命中，每次请求都直接打到数据库，导致数据库压力骤增。
解决方案：
- 缓存空值：将查询结果为 null 的 key 也缓存起来，设置较短的 TTL（如 60 秒）。
- 布隆过滤器：在缓存层之前加一层布隆过滤器，快速判断 key 是否可能存在。
- 参数校验：在接口层对非法参数（如负数 ID、超长字符串）直接拒绝。
1.3.3 缓存雪崩
缓存雪崩指大量缓存 key 在同一时间过期失效，或缓存节点宕机，导致所有请求瞬间涌入数据库，造成数据库崩溃。
解决方案：
- 过期时间加随机偏移：基础 TTL + 随机 0~300 秒，避免大量 key 同时过期。
- 多级缓存：本地缓存（如 Go map / freecache）作为 L1，Redis 作为 L2，分散压力。
- 缓存高可用：Redis 主从 + Sentinel / Cluster，避免单点故障。
- 限流降级：在缓存失效时，对数据库查询进行限流，保护后端。
1.4 缓存架构总览
下图展示了 Go 业务接口中缓存层的典型位置与数据流向：
1.5 缓存策略选择矩阵
根据业务场景的不同，选择合适的缓存策略至关重要。下表总结了常见策略及其适用场景：
| 策略 | 读流程 | 写流程 | 一致性强度 | 适用场景 |
|---|---|---|---|---|
| Cache-Aside | 先查缓存，未命中查库并回写 | 更新库，删除缓存 | 最终一致 | 通用读多写少场景 |
| Read-Through | 缓存组件自动回源加载 | 直接写库 | 最终一致 | 需要统一缓存入口 |
| Write-Through | 同 Read-Through | 先写缓存，同步写库 | 强一致（有性能损失） | 对一致性要求极高 |
| Write-Behind | 同 Read-Through | 先写缓存，异步批量写库 | 弱一致 | 写密集型、可容忍丢数据 |
Go 项目推荐： 绝大多数业务接口采用 Cache-Aside 模式，配合 TTL 过期与延迟双删策略，在性能与一致性之间取得平衡。