1. 课程导论：聚合查询的定义、缓存一致性的挑战、闭环架构的核心思想
1.1 聚合查询的定义与业务特征
聚合查询（Aggregation Query）是指对多个数据源、多个维度或大量明细数据进行汇总、统计、分组、排序后返回单一结果集的查询模式。与单行查询（Point Query）不同，聚合查询通常涉及全表扫描、多表 Join、实时计算或预聚合，其响应时间与数据量呈非线性增长。
| 对比维度 | 单行查询 | 聚合查询 |
|---|---|---|
| 数据范围 | 单条或少量记录 | 大量记录（万～亿级） |
| 计算复杂度 | O(1) 或 O(logN) | O(N) 或 O(NlogN) |
| 典型场景 | 用户详情、订单详情 | 日活统计、销售报表、排行榜 |
| 缓存命中率 | 高（Key-Value 直接命中） | 低（维度组合爆炸） |
| 一致性敏感度 | 高（用户直接感知） | 中（允许短暂偏差） |
业务特征总结：聚合查询具有“读多写少、计算密集、维度组合多、容忍短时不一致”的特点，这为缓存引入提供了空间，但也带来了缓存一致性维护的复杂性。
1.2 缓存一致性的核心挑战
在聚合查询场景下，缓存一致性面临三大核心挑战：
- 写后读不一致：业务数据更新后，缓存中的聚合结果未及时失效或刷新，导致用户读到旧数据。
- 多维度组合爆炸：同一份底层数据可能被数十种聚合维度缓存，更新时难以精准定位所有相关缓存键。
- 并发更新与缓存击穿：高并发下，缓存失效瞬间大量请求同时回源数据库，导致数据库压力骤增甚至雪崩。
常见误区：很多团队试图用“设置短过期时间”来解决一致性问题。这只能降低不一致窗口，无法根除；且过期时间越短，缓存命中率越低，回源压力越大。
1.3 闭环架构的核心思想
闭环架构（Closed-Loop Architecture）的核心思想是：将缓存视为一个有状态的计算层，通过事件驱动、增量计算和一致性校验，形成“数据变更 → 缓存更新 → 一致性验证 → 异常补偿”的完整闭环。它不再依赖被动过期或手动刷新，而是主动维护缓存与数据源之间的最终一致性。
闭环架构的四大核心组件
| 组件 | 职责 | 关键技术 |
|---|---|---|
| 变更捕获层 | 监听数据源变更事件（Insert/Update/Delete） | CDC（Change Data Capture）、Binlog、消息队列 |
| 增量计算层 | 将变更事件转化为聚合结果的增量更新 | 流式计算、增量聚合算子、状态管理 |
| 缓存存储层 | 存储聚合结果，支持高效读写与过期策略 | Redis、Tair、本地缓存 + 分布式缓存 |
| 一致性校验层 | 定期或按需校验缓存与数据源的一致性 | 对账任务、差异检测、自动补偿 |
核心思想总结：从“被动失效”转向“主动闭环”。每一次数据变更都触发精确的缓存更新，而不是清空整个缓存；同时通过校验层兜底，确保即使出现漏更新也能自动修复。
1.4 闭环架构与传统方案的对比
| 对比维度 | 传统方案（被动过期） | 闭环架构（主动闭环） |
|---|---|---|
| 一致性保障 | 弱一致性，依赖过期时间 | 最终一致性，主动更新 + 校验兜底 |
| 缓存命中率 | 低（过期时间越短命中率越低） | 高（精确更新，无需频繁过期） |
| 数据库压力 | 高（缓存击穿风险大） | 低（增量计算，回源次数少） |
| 实现复杂度 | 低（简单设置 TTL） | 中高（需要 CDC、流计算、校验组件） |
| 适用场景 | 低一致性要求、低频更新 | 高一致性要求、高频更新、复杂聚合 |