4. 主动失效策略：基于事件驱动的缓存失效

在分布式系统中，缓存与数据库之间的数据一致性是核心挑战之一。被动失效（如 TTL 过期）虽然简单，但无法保证在写操作后立即消除脏数据。主动失效策略通过事件驱动机制，在数据发生变更时立即通知缓存层清除对应条目，从而将不一致窗口压缩到毫秒级。

4.1 Cache-Aside 模式下的主动失效语义

Cache-Aside（旁路缓存）是最常用的缓存读写模式。在该模式下，应用程序负责同时管理缓存和数据库。主动失效策略在此模式中的核心原则是：写操作后立即失效缓存，而非更新缓存。

为什么选择“失效”而非“更新”？

• 避免并发写覆盖： 如果两个并发写操作分别更新缓存，后一个写可能覆盖前一个写的结果，导致缓存与数据库最终状态不一致。
• 简化业务逻辑： 失效操作是幂等的，多次失效同一键不会产生副作用；而更新操作需要读取最新数据，增加了写路径的复杂度。
• 减少写放大： 更新缓存需要额外的序列化和网络开销，失效仅需一个删除命令，延迟更低。

4.2 基于事件驱动的失效架构

事件驱动失效的核心组件包括：事件生产者（写操作服务）、事件通道（消息队列或变更数据捕获管道）、事件消费者（缓存失效处理器）。下图展示了标准的事件驱动失效流程。

4.3 写操作后立即失效的机制

写操作后立即失效（Immediate Invalidation）是主动失效策略中最直接、最常用的实现方式。其核心流程可分解为以下步骤：

1. 业务写操作： 应用程序执行数据库写入（INSERT / UPDATE / DELETE）。
2. 事务提交： 确保数据库写入成功并提交事务。
3. 发送失效事件： 在事务提交后的回调或监听器中，向消息队列发送一条包含缓存键的失效事件。
4. 异步消费： 缓存失效处理器从队列中拉取事件，执行 DEL 或 UNLINK 命令删除缓存键。
5. 读时回填： 后续读请求发现缓存缺失，重新从数据库加载数据并写入缓存。

4.4 失效策略对比：立即失效 vs. 延迟失效 vs. 批量失效

4.5 事件驱动失效的可靠性保障

事件驱动架构中，消息丢失、重复消费、消费顺序错乱是常见问题。针对缓存失效场景，需要建立以下保障机制：

• 至少一次投递： 消息队列必须配置持久化（如 Kafka 的 acks=all，RabbitMQ 的 publisher confirms），确保事件不丢失。
• 幂等消费： 缓存失效操作天然幂等（多次 DEL 同一键效果相同），但需注意通配符失效（如 DEL user:*）的幂等性。
• 死信队列： 对于消费失败的事件（如缓存连接超时），应转入死信队列进行重试或人工干预。
• TTL 兜底： 即使事件驱动失效失败，缓存条目仍应设置合理的 TTL（如 5~10 分钟），作为最终一致性兜底。

4.6 性能优化：批量失效与管道化

在高并发写场景下，大量独立的失效事件可能导致缓存层连接开销剧增。以下优化手段可显著提升失效吞吐：

1. 管道化（Pipelining）： 将多个 DEL 命令通过 Redis Pipeline 批量发送，减少网络往返次数。
2. 异步批量消费： 失效处理器从消息队列中拉取一批事件（如 100 条），合并为一次批量删除操作。
3. 键前缀分组： 对于同一业务实体的多个缓存键（如 user:123:profile、user:123:orders），使用 UNLINK 或 Lua 脚本一次性删除。

// 示例：使用 Redis Pipeline 批量失效
Pipeline pipeline = jedis.pipelined();
for (String key : batchKeys) {
    pipeline.unlink(key);  // UNLINK 非阻塞删除，优于 DEL
}
pipeline.sync();

4.7 事件驱动失效的监控与治理

为了确保主动失效策略持续可靠运行，需要建立以下监控指标：

通过以上指标，可以快速定位失效链路中的瓶颈或故障，确保缓存一致性治理的可观测性。