「产品矩阵平台」数据与缓存架构

第七章 数据与缓存架构

数据架构决定平台能跑多远。早期系统可以靠 MySQL 单库支撑，但产品矩阵一旦出现多应用、多租户、内容增长、行为分析和 AI 调用，数据会迅速分层。

建议把数据分成四类：

7.1 数据库分层架构

基础形态：

graph TD
    A[Application] --> B[Repository]
    B --> C[Primary DB]
    B --> D[Read Replica]
    B --> E[Redis Cache]
    C --> F[Binlog / CDC]
    F --> G[Search Index]
    F --> H[Analytics Store]

读写分离要谨慎。并不是所有读请求都能走从库，例如刚创建订单后立即查询订单详情，如果读到延迟从库，会出现“下单成功但看不到订单”的体验。

推荐策略：

7.2 ORM Hook 实践

GORM Hook 可以增强一致性，但要控制边界。

适合放在 Hook 的逻辑：

不适合放在 Hook 的逻辑：

Hook 应该像安全带，而不是方向盘。

7.3 缓存策略

常见缓存模式：

Cache Aside 的关键不是“加 Redis”，而是处理缓存击穿、穿透和雪崩。

7.4 多级缓存设计

多级缓存适合高读场景，例如配置、权限、商品详情、内容详情。

Local Cache -> Redis -> Database

本地缓存可以用 Ristretto，Redis 用于跨实例共享。配置变更后通过 Pub/Sub 或事件通知各实例失效本地缓存。

缓存 key 设计：

tenant:{tenant_id}:app:{app_id}:content:{content_id}:v{version}

key 中带版本号，可以让发布和回滚更可控。

7.5 数据一致性策略

产品矩阵平台中，强一致只保留给关键交易链路。其他场景优先采用最终一致。

分布式事务不要轻易引入。多数业务可以通过本地事务 + Outbox + 补偿任务解决。

7.6 搜索与分析系统

搜索和分析是两个不同系统：

不要用 ElasticSearch 做长期 BI，也不要用 ClickHouse 承担实时全文搜索。工具选错，会让维护成本持续上升。

7.7 大数据与埋点管道

埋点事件建议使用统一结构：

{
  "event": "content_viewed",
  "tenant_id": "t_001",
  "app_id": "app_001",
  "user_id": "u_001",
  "anonymous_id": "anon_001",
  "timestamp": "2025-10-16T16:28:36+08:00",
  "properties": {
    "content_id": "c_001",
    "source": "feed"
  }
}

事件进入 Kafka 后，按用途分流：

7.8 数据脱敏与隐私保护

敏感数据要先分类：

常见脱敏：

手机号：138****5678
邮箱：le***@example.com
身份证：110***********1234

日志中禁止直接打印高敏数据。对调试确实需要的字段，应使用 token 化后的引用 ID。

7.9 数据架构落地清单