多级缓存故障时需通过显式、可观测、可验证的异常处理契约保障系统韧性：每级失效场景须定义受控异常及对应兜底行为，各层标注fallback语义标签（如[[fallback-to: redis]]），确保降级路径可预期、状态可回滚、日志可追溯，并通过静态扫描、混沌注入与线上熔断联动三重机制验证契约有效性。

这个问题其实是在问：当多级缓存（比如本地缓存 + redis）出现故障时，如何用一套清晰、可验证的异常处理契约，确保系统不崩溃、数据不乱、用户无感。核心不是“要不要降级”，而是“降级过程本身是否受约束、可预期、可验证”。

明确“受检异常规范”的真实含义

这里说的“受检异常”并非 Java 那种编译强制捕获的 checked exception，而是指在架构设计层面**显式声明、可观测、可验证的异常路径**。它要求：每个缓存层级的失效场景（如本地缓存加载失败、Redis 连接超时、序列化异常）都必须被明确定义为一类受控异常，并绑定对应的兜底行为和状态承诺。

• 例如：Guava Cache 的 CacheLoader 抛出 ExecutionException，不能简单吞掉或转成 RuntimeException，而应映射为 LocalCacheFailureException，并注明该异常发生时，调用方必须切换至下一级缓存，且不得修改任何共享状态
• 再如：Redis 客户端抛出 JedisConnectionException，需统一包装为 DistributedCacheUnavailableException，并约定此异常触发后，系统自动启用“只读降级模式”——允许读数据库，但禁止写操作，避免脏写

把降级行为写进缓存层契约

多级缓存的每一级都应携带轻量级运行时契约，描述“我挂了之后，你该怎么办”。这不是注释，而是可被监控系统或断言框架识别的语义标签。

• 本地缓存层标注 [[fallback-to: redis]]，表示其失效唯一合法后路是查 Redis；若 Redis 同时不可用，则触发全局降级开关
• Redis 客户端配置中嵌入 on-failure-policy="read-through-db, no-write"，即故障时允许穿透查库，但所有写缓存操作必须静默丢弃，防止缓存与 DB 状态错位
• 数据库访问层需声明 [[guarantees: eventual-consistency-after-recovery]]，说明一旦缓存恢复，DB 中的临时写入可通过异步补偿同步回缓存，而非强一致覆盖

用状态一致性锚定过渡边界

安全过渡的关键，是定义清楚“哪一部分状态可以变、哪一部分绝不能变”。这直接对应 C++27 提出的 observable-consistent 和 rollback-safe 思想——只不过落地到缓存场景：

• 对外接口必须保持 observable-consistent：比如 getProductDetail(userId) 在降级时仍返回完整结构体，只是部分字段（如“推荐商品列表”）为空数组或默认值，而不是抛 NPE 或返回 500
• 内部副作用需满足 rollback-safe 原则：若本地缓存加载失败后触发了 Redis 查询，而 Redis 又超时，此时已发起的 Redis 请求必须被 cancel 或 timeout，不能滞留连接、不能堆积 pending callback，否则会拖垮线程池
• 所有降级路径上的日志必须包含 fallback_trace_id，串联起从本地缓存 → Redis → DB 的每一步决策，便于事后验证是否严格遵循了契约

验证机制比策略本身更重要

没有验证的契约等于没有契约。建议在测试和上线阶段嵌入三类检查：

• 静态契约扫描：CI 流程中用自定义注解处理器检查所有缓存访问方法是否标注了 @FallbackContract(level="redis", strict=true) 类似元数据
• 混沌注入验证：在预发环境定期模拟本地缓存 OOM、Redis 网络分区、DB 连接池耗尽，观测系统是否按契约进入指定降级路径，且健康分（如 SysOM 所示）仅短暂落入“亚健康”而非跌穿“不健康”阈值
• 线上熔断联动：当某级缓存错误率连续 1 分钟 >5%，自动触发断路器打开，并向配置中心推送 cache.level1.enabled=false，强制所有流量跳过该层——这是对契约失效的兜底干预，而非替代契约