1. 课程导学：为什么需要缓存一致性？gRPC在分布式缓存中的角色
1.1 缓存一致性问题：从单机到分布式的挑战
在单机应用中，缓存与数据库之间的一致性通常由本地事务和锁机制保障。然而，当系统演进为分布式架构后，缓存节点、数据库实例与应用服务分散在不同进程甚至不同物理机器上，缓存一致性问题便成为影响数据正确性的核心挑战。
核心矛盾： 缓存层追求高性能（低延迟、高吞吐），数据库层追求强持久化与事务性。两者之间的数据同步一旦出现延迟或失败，就会导致客户端读到“脏数据”或“过期数据”。
以下表格总结了分布式缓存场景中常见的三种不一致现象：
| 不一致类型 | 现象描述 | 典型后果 |
|---|---|---|
| 缓存与数据库不一致 | 数据库已更新，缓存仍返回旧值 | 用户看到过时信息，如库存显示错误 |
| 多级缓存间不一致 | 本地缓存与分布式缓存（如Redis）数据不同步 | 同一用户在不同节点上看到不同数据 |
| 跨副本缓存不一致 | 缓存集群中不同副本持有不同版本的数据 | 读写分离场景下读取到过期副本 |
1.2 为什么需要缓存一致性？—— 业务与架构的双重驱动
缓存一致性并非一个纯理论问题，它直接决定了分布式系统的正确性、可用性与可维护性。从业务视角看，以下场景对一致性有刚性需求：
- 电商库存系统： 扣减库存操作必须保证缓存与数据库的最终一致，否则会导致超卖或少卖。
- 社交Feed流： 用户发布动态后，缓存中的关注列表必须及时更新，避免“发布后自己看不到”的体验问题。
- 配置中心： 配置变更需要立即推送到所有缓存节点，否则服务会基于过期配置运行，引发连锁故障。
从架构视角看，引入缓存一致性机制可以带来以下收益：
- 提升数据可信度： 减少因缓存脏数据导致的线上故障排查成本。
- 降低系统耦合： 通过明确的同步协议，解耦缓存层与存储层的变更逻辑。
- 支撑水平扩展： 一致性协议（如Quorum、Lease）为缓存集群的弹性伸缩提供基础保障。
课程观点： 缓存一致性不是“要不要”的问题，而是“在什么粒度、什么延迟下达成一致”的工程权衡。本课程将围绕gRPC这一高效通信框架，构建一套可落地的一致性解决方案。
1.3 gRPC在分布式缓存中的角色定位
gRPC作为高性能、跨语言的RPC框架，在分布式缓存一致性场景中承担着通信基础设施与协议契约层的双重角色。其核心优势体现在以下三个层面：
| 角色维度 | gRPC能力 | 缓存一致性场景价值 |
|---|---|---|
| 通信层 | 基于HTTP/2的多路复用、双向流、头部压缩 | 低延迟、高吞吐的缓存同步请求；支持Watch/Notify模式 |
| 契约层 | Protocol Buffers定义强类型接口与数据结构 | 缓存操作（Get/Set/Delete/Invalidate）接口标准化，避免序列化歧义 |
| 治理层 | 内置负载均衡、健康检查、拦截器（Interceptor） | 缓存节点动态发现、故障转移、一致性协议元数据注入 |
下图展示了gRPC在缓存一致性架构中的核心位置：
1.4 本课程的技术栈与学习路径
本课程将围绕Go语言 + gRPC + Redis这一主流技术栈，从零构建一套具备缓存一致性保障的分布式系统。课程覆盖以下关键技术点：
- gRPC服务定义： 使用Protocol Buffers定义缓存操作接口（Get/Set/Delete/Watch）。
- 一致性协议实现： 基于gRPC双向流实现Lease租约机制与失效通知（Invalidation）。
- Go并发模型： 利用goroutine和channel处理缓存同步的异步回调与超时控制。
- 测试与验证： 通过gRPC拦截器注入模拟延迟与故障，验证一致性协议的正确性。
前置要求： 建议学习者具备Go语言基础（goroutine、channel、interface）、基本的gRPC使用经验以及Redis常用命令知识。本课程将提供完整的代码示例与可运行的测试用例。