数据库 + Redis + Caffeine（多级缓存）。
典型结构：

• 读：先读 Caffeine（本地），读不到再读 Redis，再读不到查数据库

• 写：要保证所有缓存层都失效或更新

在这个结构里，延迟双删仍然只针对 Redis，因为：

• Caffeine 是本地缓存，每个应用节点独立。
  如果每个节点都自己做延迟双删，第二次删除时只能删自己节点里的 Caffeine，删不到别的节点。
  所以对 Caffeine 的失效需要用 广播 机制（比如通过 Redis Pub/Sub、MQ、RPC 通知等）让所有节点同时删除本地的 Caffeine 缓存。

因此组合策略往往是：

1. 写操作：

   • 先失效本地 Caffeine（可选）

   • 删除 Redis 缓存（第一次）

   • 更新数据库

   • 发送广播消息（通知所有其他节点失效 Caffeine）

   • 延迟一段时间后，再次删除 Redis（第二次） —— 这就是延迟双删中的第二次删除

2. 广播负责让所有节点的 Caffeine 缓存被清除，保证本地缓存一致。

3. 延迟双删 保证 Redis 不会因为并发读写入旧数据而长期不一致。