直接裸用 std::unordered_map 做 L1 缓存存在三大硬伤：无过期淘汰、无法感知 L2 变更、并发读写不安全；需封装为带 TTL、原子读写、版本控制及双检锁加载的线程安全容器。
为什么不能直接用 std::unordered_map 做 L1 缓存
本地内存缓存（L1）如果只是裸用 std::unordered_map，会立刻暴露三个硬伤：没有过期淘汰、无法感知远程 L2 缓存变更、并发读写不安全。尤其在分布式场景下，多个进程/线程同时发现 key 不存在而穿透到后端，就是典型的击穿——哪怕你加了 std::shared_mutex，也只解决读写互斥，不解决「雪崩式重复加载」。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 用带 TTL 和原子读写的封装容器，比如基于
folly::ConcurrentHashMap+folly::TimeoutQueue自研，或直接集成absl::flat_hash_map配合独立的定时清理线程 - L1 的 key 必须包含版本号或更新时间戳（如
"user:123_v2"），否则 L2 回源更新后，L1 无法主动失效 - 禁止在 L1 查不到时直接放行请求去查 L2；必须走「双检锁 + 单次加载」流程，确保同一 key 在 L1 未命中期间，最多只有一个线程加载并回填两级缓存
如何让 L2 缓存（Redis/Memcached）支持 L1 的协同失效
标准 Redis 客户端（如 hiredis 或 redis-plus-plus）本身不提供「通知本地缓存失效」的能力。靠轮询 TTL 或被动等待 L1 过期，延迟高、一致性差。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 在写 L2 时，同步推送一条失效消息到 Pub/Sub 通道（如 Redis 的
PUBLISH cache_invalidate user:123），所有客户端订阅该 channel 并清除对应 L1 条目 - 若用 Memcached，没有原生 Pub/Sub，可退而求其次：写入时额外 set 一个带短 TTL 的失效标记 key（如
invalidate:user:123），L1 每次读前先 check 该标记是否存在 - 务必给失效消息加签名或序列号，防止网络重传导致重复清除；推荐用
cache_key + version + timestamp拼接后 SHA256 截断作为校验字段
击穿防护的核心：加载过程必须原子且可取消
常见错误是用 std::mutex 锁住整个加载函数，结果一个慢查询卡住所有同 key 请求。更糟的是，没考虑超时和取消——当 L2 已经响应缓慢，L1 不该继续傻等。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 用
std::shared_mutex实现读写分离：读路径无锁（只读 L1），写路径分两段——先占位（insert_or_assign一个空/占位值），再异步加载并更新 - 加载逻辑必须支持 cancellation token（如
std::stop_token），一旦发现其他线程已成功回填，立即中止当前加载并返回 - 对高危 key（如热点用户资料）启用「逻辑过期」：L2 存的 value 是
{data: "...", expire_ts: 1717023456}，L1 加载时检查expire_ts是否临近，提前触发异步刷新，而不是等到过期才查
实际部署时最容易被忽略的兼容性点
多级缓存不是功能开关，而是数据生命周期的耦合系统。线上出问题往往不在代码逻辑，而在环境错配。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- L1 和 L2 的序列化协议必须一致：如果 L2 存的是 JSON 字符串，L1 就不能反序列化成
protobuf::Message后再塞进去，否则类型不匹配导致后续 compare-and-swap 失败 - 客户端启动时，必须强制清空 L1（或至少清空旧版本缓存），否则升级后新老结构体二进制不兼容，
memcpy解析会 crash - 监控必须打点到具体层级：区分
l1_hit/l1_miss_l2_hit/l1_miss_l2_miss，光看「缓存命中率」会掩盖 L1 失效策略缺陷
真正难的不是实现两级结构，而是让 L1 的生存周期、失效语义、加载契约，和 L2 的持久性、传播机制、序列化边界严丝合缝地咬合。少一个环节对齐，就会在凌晨三点弹出告警。
