3. 聚合查询场景分析：多维度聚合、跨表聚合、实时聚合与离线聚合的区别

聚合查询是缓存一致性闭环架构中最具挑战的场景之一。与单行查询不同，聚合操作通常涉及大量数据的扫描、分组、计算与排序，其缓存命中率低、更新频率高、一致性窗口难以控制。本章从四个核心维度拆解聚合查询的缓存场景，帮助架构师在设计缓存策略时做出精准判断。

3.1 聚合查询的四类核心场景

根据数据源范围、计算时效性和维度复杂度，聚合查询可划分为以下四种典型场景：

3.2 多维度聚合：组合爆炸与缓存碎片化

多维度聚合是指对同一数据集按多个维度（时间、地域、品类、渠道等）进行分组汇总。其核心挑战在于维度组合的指数级增长导致缓存键数量爆炸，且任意维度值变更都可能引发大量缓存失效。

3.2.1 典型场景示例

• 电商销售看板： 按「日期 × 省份 × 商品类目」聚合 GMV、订单量、客单价。
• 广告投放报表： 按「小时 × 广告位 × 创意ID」聚合曝光、点击、转化率。
• 运维监控大盘： 按「服务 × 接口 × 状态码」聚合请求量、错误率、P99延迟。

3.2.2 缓存策略要点

3.3 跨表聚合：分布式事务与缓存一致性鸿沟

跨表聚合涉及多张物理表甚至多个数据库实例的 JOIN 或 UNION 操作。缓存一致性面临的核心问题是：一次聚合结果依赖多张表的数据，任何一张表的数据变更都可能导致缓存失效，而分布式环境下很难保证所有相关表的变更与缓存失效在同一个事务边界内。

3.3.1 跨表聚合的典型架构

3.3.2 跨表聚合的缓存一致性方案对比

3.4 实时聚合与离线聚合：时效性与一致性的两极

实时聚合与离线聚合代表了缓存一致性闭环中时效性与一致性的两个极端。理解两者的本质差异，是设计混合缓存架构的前提。

3.4.1 实时聚合：毫秒级响应下的最终一致性

实时聚合通常基于流式计算引擎（Flink、Spark Streaming）或内存计算（Redis 聚合、Caffeine 窗口聚合），数据从产生到聚合结果可见的延迟在毫秒到秒级。缓存一致性策略必须接受最终一致性，因为流式数据天然存在乱序、延迟和重复。

• 典型场景： 实时大屏、秒杀库存聚合、实时风控指标。
• 缓存策略： 滑动窗口 + 增量合并 + 定期快照。
• 一致性保障： 幂等写入 + 去重机制 + 水位线对齐。

3.4.2 离线聚合：强一致性快照下的批量刷新

离线聚合基于全量历史数据，通过 MapReduce、Spark Batch、Hive 等批处理引擎计算，产出 T+1 或小时级的聚合结果。缓存一致性要求为快照强一致——在数据加载完成前，缓存保持旧版本；加载完成后，原子切换至新版本。

• 典型场景： 财务月报、年度经营分析、历史趋势对比。
• 缓存策略： 全量预计算 + 版本号切换 + 双缓冲。
• 一致性保障： 原子引用替换 + 读锁保护 + 回滚机制。

3.4.3 实时 vs 离线：核心差异对比

3.5 场景选择矩阵：如何为聚合查询选择缓存策略

以下矩阵帮助架构师根据业务需求快速定位缓存策略：