3. 报表系统架构概览：典型报表系统的分层架构、数据流与回放场景
在深入缓存一致性方案之前，必须先理解报表系统的整体骨架。报表系统并非简单的“查数据库→画图表”，而是一个包含数据采集、加工、存储、调度、渲染的复杂管道。本章从分层架构、数据流和回放场景三个维度拆解典型报表系统，为后续缓存策略的讨论奠定基础。
3.1 典型分层架构
现代报表系统通常采用四层架构，各层职责清晰、解耦独立。下表总结了每一层的核心组件与典型技术选型：
| 层次 | 核心职责 | 典型组件 / 技术 | 关键关注点 |
|---|---|---|---|
| 数据源层 | 对接业务数据库、日志、消息队列等原始数据 | MySQL、PostgreSQL、Kafka、HDFS | 数据格式异构、采集延迟 |
| 计算加工层 | ETL 清洗、聚合、维度建模、预计算 | Spark、Flink、MapReduce、SQL on Hadoop | 计算资源消耗、数据一致性 |
| 存储服务层 | 存储预计算结果、明细快照、元数据 | ClickHouse、Doris、Redis、MySQL | 查询性能、缓存策略、数据新鲜度 |
| 展示调度层 | 报表渲染、权限控制、定时调度、回放触发 | Grafana、Superset、自研前端 + 调度引擎 | 用户体验、回放一致性、并发控制 |
架构要点： 存储服务层是缓存一致性的主战场。预计算后的结果集、中间聚合表、热点查询结果都会在此层被缓存，而回放场景要求这些缓存必须与数据源层的原始状态严格对齐。
3.2 数据流全景
数据从产生到最终呈现在报表上，经历了一条清晰的管道。下图展示了核心数据流与各层之间的交互关系：
数据流关键特征：
- 正向流（蓝色/红色/绿色）： 数据从源层经过计算加工后写入存储层，展示层从存储层读取查询结果。
- 回放流（橙色虚线）： 展示调度层发起回放指令，驱动计算加工层重新拉取数据源并刷新存储层缓存。
- 缓存一致性冲突点： 正向流写入存储层后，若回放流尚未完成，展示层可能读到旧缓存，导致报表数据与数据源不一致。
3.3 回放场景分类
回放并非单一操作，根据触发原因和数据范围，可划分为以下三类典型场景：
| 场景类型 | 触发条件 | 数据范围 | 一致性要求 | 典型示例 |
|---|---|---|---|---|
| 全量回放 | 数据源结构变更、历史数据修复 | 全表 / 全分区 | 最终一致（允许短暂不一致） | 月度财务对账报表重新生成 |
| 增量回放 | 定时调度（如每小时）、数据源增量更新 | 最近时间窗口 | 弱一致（允许分钟级延迟） | 实时销售看板每小时刷新 |
| 精确回放 | 用户手动触发、审计需求、故障恢复 | 指定时间点 / 指定维度 | 强一致（必须与数据源完全对齐） | 监管报表回查、异常数据追溯 |
缓存一致性陷阱： 精确回放场景对缓存一致性要求最高。如果回放过程中存储层的缓存未被正确失效或锁定，用户可能在回放完成前看到“新旧数据混合”的报表，导致决策错误。后续章节将重点讨论如何通过 Go 语言实现精确回放下的缓存一致性保障。
3.4 回放流程的时序拆解
一次典型的精确回放流程包含以下步骤，其中缓存一致性控制穿插在多个环节中：
- 触发回放请求： 展示调度层接收用户或定时任务发起的回放指令，携带回放时间点、维度条件。
- 锁定缓存键： 存储服务层对涉及的回放数据缓存键加分布式锁（如 Redis Redlock），防止回放过程中被其他查询污染。
- 重新拉取数据源： 计算加工层根据回放条件从数据源层拉取原始数据，执行 ETL 和聚合计算。
- 写入新结果： 将计算后的新结果写入存储层，此时旧缓存仍被锁定，外部查询不可见。
- 原子切换缓存： 使用原子操作（如 Redis SETNX 或 CAS）将缓存指针从旧结果切换到新结果，然后释放锁。
- 查询恢复： 后续查询命中新缓存，报表数据与数据源完全一致。
下图展示了精确回放流程中缓存状态的变化：