EAV模型如何做缓存

EAV（Entity–Attribute–Value）模型因为“行即字段”的特性，查询时通常要做大量 JOIN 或行转列，性能天然偏弱，所以缓存是 EAV 系统优化的核心手段之一。下面从「缓存什么、怎么缓存、注意事项」三个层面说明。

一、EAV 模型适合缓存什么

1. 实体完整快照（最推荐）

把一个 Entity 的所有 Attribute–Value 聚合成一个对象/Map 缓存起来。

例如：

{
  "user_id": 1001,
  "attributes": {
    "age": 30,
    "city": "Beijing",
    "vip": true
  }
}

✅ 优点

• 避免多次 JOIN
• 读取一次即可拿到全部属性

❌ 缺点

• 属性更新时要失效/重建缓存

2. 热门属性组合（宽表视图缓存）

把常用查询的“伪宽表”结果缓存：

SELECT e.id, a1.value, a2.value
FROM entity e
JOIN eav a1 ON ...
JOIN eav a2 ON ...

缓存为：

{
  "user_id": 1001,
  "age": 30,
  "city": "Beijing"
}

适合：

• 列表页
• 搜索结果
• 报表

3. 元数据缓存（Attribute 定义）

EAV 的 attribute 表通常变化极少：

• attribute_id
• type
• validation
• label

✅ 适合：

• 本地缓存（Caffeine / Guava）
• 永不过期 + 主动刷新

二、常见缓存方案

方案 1：Redis + 实体级缓存（最主流）

读：
1. 查 Redis
2. 未命中 → 查 DB（EAV JOIN）
3. 聚合后写 Redis

写：
1. 更新 EAV 表
2. 删除 / 重建 Redis Key

Key 设计：

entity:{type}:{id}

方案 2：本地缓存 + Redis（双级缓存）

Local Cache (Caffeine)
   ↓ miss
Redis
   ↓ miss
DB

适合：

• 读多写少
• 延迟敏感

方案 3：物化视图 + 定时缓存

• 定时任务把 EAV 转成宽表
• 缓存宽表结果

适合：

• 报表
• 分析型数据

三、EAV 缓存的关键问题

1. 缓存失效困难

EAV 一行一个属性 → 一个实体可能几百行

✅ 解决：

• 以「实体」为最小缓存单元
• 不单独缓存某个 attribute

2. 写放大

更新一个字段 → 整个实体缓存重建

✅ 缓解：

• 冷数据不缓存
• 使用异步刷新

3. 一致性

EAV 常用于配置/元数据

✅ 策略：

• 写后删缓存（Cache Aside）
• 重要场景加版本号

四、一个典型架构示例

Client
  ↓
API
  ↓
Local Cache → Redis → DB(EAV)
                  ↑
             Binlog / MQ 失效

五、什么时候不该用 EAV 缓存

• 属性极度动态且低频
• 强事务一致性
• 简单系统（直接宽表更好）

如果你愿意，可以告诉我：

• 用的是 MySQL / PG / ES？
• 读多还是写多？
• 是否允许最终一致？

我可以直接给你一套可用的缓存设计方案或代码模板。