中间件体系（Middleware Platform）
目标：为业务系统提供统一、稳定、高可用、可治理的基础运行能力
P0（运行基础）
├── 网关（Kong / APISIX）
├── 配置中心（Nacos）
├── RPC 平台（Dubbo）
├── 数据存储（MySQL / PostgreSQL / Mongo）
P1（解耦与性能）
├── MQ（Kafka / RabbitMQ）
├── 缓存平台（Redis / Memcached）
├── 搜索（Elasticsearch）
├── 文件存储（MinIO）
P2（治理与稳定）
├── 缓存失效监控 & 一致性
├── 任务调度（Airflow / XXLJob）
├── 中间件监控与告警
P3（平台化）
├── 中间件统一管控台
├── 多租户 / 资源隔离
├── 成本 & 容量管理
中间件体系的本质不是“技术选型”，而是“运行能力抽象”：
缓存失效监控 & 一致性
下面我从企业级缓存平台与分布式系统架构的视角，系统性、工程化、可落地地详细展开 缓存失效监控 & 缓存一致性。这不是“Redis 用法”，而是缓存作为系统能力如何被正确设计、治理和监控的问题。
一、先给结论（非常重要）
缓存问题从来不是“有没有缓存”，而是： 缓存什么时候失效、为什么失效、失效是否可控、失效后系统是否安全。
缓存治理的两大核心目标：
- 缓存失效可观测
- 缓存与源数据的一致性可证明
二、缓存失效的全景分类（先把敌人认清）
2.1 缓存为什么会“失效”
| 类型 | 说明 | 风险 |
|---|---|---|
| TTL 到期 | 正常过期 | 瞬时穿透 |
| 主动删除 | 数据更新 | 一致性问题 |
| 淘汰（LRU/LFU） | 内存不足 | 不可预测 |
| 重启 / Failover | 节点故障 | 全量失效 |
| 热 Key 抖动 | 高并发 | 雪崩 |
2.2 哪些是“危险失效”
- ❌ 大批 key 同时 TTL 到期
- ❌ 缓存 miss → DB QPS 激增
- ❌ 删除缓存失败 / 延迟
- ❌ 脏缓存长期存在
三、缓存失效监控（核心能力）
没有缓存监控 = 你根本不知道缓存有没有在“帮你”。
3.1 缓存命中率（最基础，但不够）
必须细分
| 维度 | 说明 |
|---|---|
| 全局命中率 | 总体 |
| 按业务 | 哪个系统在浪费 |
| 按 Key 类型 | 配置 / 会话 / 数据 |
| 按接口 | 哪些接口不适合缓存 |
反模式：
只看 Redis overall hit rate
3.2 缓存失效事件监控（非常关键）
你必须知道这些事件发生了多少次
| 事件 | Redis 示例 |
|---|---|
| TTL 过期 | expired_keys |
| 淘汰 | evicted_keys |
| key 删除 | del / unlink |
| 重载 | restart |
evicted_keys > 0 是一级告警
3.3 缓存穿透 / 击穿 / 雪崩监控
指标组合（而不是单点）
cache_miss ↑
DB QPS ↑
接口 RT ↑
三者同时发生 = 缓存失效事故
3.4 热 Key & 大 Key 监控
热 Key
- QPS 异常集中
- 单 Key 占比过高
大 Key
- value 过大
- 序列化慢
- 网络慢
3.5 缓存一致性监控（进阶）
方式一：影子校验（抽样）
cache_value == db_value ?
- 异步
- 低频
- 报告不一致率
方式二：版本号校验
cache.version < db.version
四、缓存一致性模型（非常重要）
4.1 常见一致性策略对比
| 策略 | 一致性 | 复杂度 |
|---|---|---|
| Cache Aside | 最常见 | 中 |
| Read Through | 强 | 高 |
| Write Through | 强 | 高 |
| Write Behind | 弱 | 高 |
4.2 Cache Aside（工程首选）
写流程（推荐）
1. 更新 DB
2. 删除 Cache
注意：不是更新缓存
为什么“删缓存”比“更新缓存”好？
- 避免并发覆盖
- 简化逻辑
- 失败可重试
4.3 双删策略（重要）
1. delete cache
2. update db
3. delay 500ms
4. delete cache again
用于解决：
- 并发读写
- 脏数据回写
五、缓存一致性的工程级方案
5.1 基于 MQ 的最终一致性（强烈推荐）
DB Update
↓
Transaction Commit
↓
Emit Event
↓
Async Cache Invalidate
优点
- 解耦
- 可重放
- 可监控
5.2 Binlog / CDC 驱动
- MySQL Binlog
- Canal / Debezium
DB → Binlog → Cache Delete
用于：
- 多缓存系统
- 跨语言
5.3 版本号 + CAS
{
"value": "...",
"version": 1024
}
- 防止旧数据覆盖新数据
- 热点 key 必备
六、缓存失效防护机制（止血方案）
6.1 逻辑过期（非常重要）
{
"data": "...",
"expire_at": 1700000000
}
- 允许短暂脏
- 防止击穿
6.2 单飞（SingleFlight）
cache miss
↓
only one thread loads DB
6.3 随机 TTL
TTL = base ± random
防止雪崩
6.4 本地缓存 + 分布式缓存
Local Cache → Redis → DB
七、缓存平台级治理设计（企业级）
Cache Platform
├── Key 规范 & Namespace
├── TTL 策略模板
├── 热 Key 保护
├── 失效事件监控
├── 一致性校验
├── 限流 & 熔断
├── 审计 & 回放
└── 演练（Chaos）
八、典型事故 & 复盘要点
事故 1：TTL 同时到期
根因
- 固定 TTL
- 无随机
改进
- TTL Random
- 逻辑过期
事故 2：缓存删失败
根因
- 网络抖动
- 非事务
改进
- MQ 重试
- CDC 补偿
事故 3：缓存脏数据
根因
- 并发写
- 更新缓存
改进
- 只删不写
- 双删
九、Checklist（你可以直接用）
缓存失效监控
- evicted_keys 告警
- 热 Key 监控
- 大 Key 扫描
- cache_miss + DB QPS 联动
- 缓存一致性抽样
