Redis 缓存一致性方案：从缓存穿透到数据同步，分布式系统的缓存治理
Redis 缓存一致性方案：从缓存穿透到数据同步，分布式系统的缓存治理
一、缓存一致性的本质矛盾：性能与一致性的不可能三角
Redis 缓存的核心价值是提升读取性能，但引入缓存后，数据存储在两个位置：数据库和 Redis。任何写操作都需要同时更新两份数据，而两步操作无法在分布式环境中原子执行。这就产生了缓存一致性问题——数据库和 Redis 中的数据可能不一致。
更具体地，一致性问题的场景包括：写操作先更新数据库再删缓存，在删除缓存前读请求可能读到旧缓存；写操作先删缓存再更新数据库，在更新数据库前读请求可能将旧数据重新写入缓存；并发写场景下，后发的写请求可能先完成数据库更新，先发的写请求后完成，导致缓存与数据库顺序不一致。
不存在完美的缓存一致性方案，每种方案都是在性能、一致性、复杂度之间的权衡。理解这些权衡，才能为不同业务场景选择合适的方案。
二、缓存一致性方案对比与架构设计
常见的缓存一致性方案有四种：Cache Aside、Read/Write Through、Write Behind、Refresh Ahead。每种方案的一致性保证和适用场景不同。
flowchart TD A[缓存一致性方案] --> B[Cache Aside: 旁路缓存] A --> C[Read/Write Through: 读写穿透] A --> D[Write Behind: 异步写入] A --> E[Refresh Ahead: 预刷新] B --> B1[读: 先缓存→未命中查DB→写缓存] B --> B2[写: 先更新DB→删缓存] B --> B3[一致性: 最终一致, 延迟秒级] C --> C1[读: 缓存层代理读] C --> C2[写: 缓存层代理写] C --> C3[一致性: 强一致, 性能低] D --> D1[写: 先写缓存→异步写DB] D --> D2[风险: 宕机丢数据] D --> D3[一致性: 弱一致, 吞吐高] E --> E1[读: 预加载即将过期数据] E --> E2[写: 同 Cache Aside] E --> E3[一致性: 最终一致, 读延迟低] style B fill:#e8f5e9 style D fill:#ffcdd22.1 Cache Aside 方案的延迟双删
// CacheAsideManager.java — Cache Aside 延迟双删方案 // 设计意图：通过"先删缓存→更新DB→延迟再删缓存"的三步操作， // 解决并发读写导致的缓存不一致问题 import redis.clients.jedis.Jedis; import redis.clients.jedis.JedisPool; public class CacheAsideManager { private final JedisPool jedisPool; private final DatabaseAccessor dbAccessor; private final long delayDeleteMs; // 延迟删除的等待时间 public CacheAsideManager(JedisPool jedisPool, DatabaseAccessor dbAccessor, long delayDeleteMs) { this.jedisPool = jedisPool; this.dbAccessor = dbAccessor; this.delayDeleteMs = delayDeleteMs; } // 读操作：先查缓存，未命中查数据库并回填 public String get(String key) { try (Jedis jedis = jedisPool.getResource()) { // 1. 查询缓存 String cachedValue = jedis.get(key); if (cachedValue != null) { return cachedValue; } // 2. 缓存未命中，查询数据库 String dbValue = dbAccessor.query(key); if (dbValue == null) { // 防止缓存穿透：空值也缓存，设置短过期时间 jedis.setex(key, 60, "NULL"); return null; } // 3. 回填缓存，设置过期时间作为兜底 jedis.setex(key, 3600, dbValue); return dbValue; } } // 写操作：延迟双删 public void put(String key, String value) { // 第 1 步：先删除缓存 try (Jedis jedis = jedisPool.getResource()) { jedis.del(key); } // 第 2 步：更新数据库 dbAccessor.update(key, value); // 第 3 步：延迟再次删除缓存 // 解决：步骤 1 删缓存后、步骤 2 更新 DB 前， // 并发读请求将旧数据重新写入缓存的问题 scheduleDelayedDelete(key); } private void scheduleDelayedDelete(String key) { Thread.ofVirtual().start(() -> { try { Thread.sleep(delayDeleteMs); try (Jedis jedis = jedisPool.getResource()) { jedis.del(key); } } catch (InterruptedException e) { Thread.currentThread().interrupt(); } }); } }2.2 基于 Canal 的数据库变更监听
// CanalCacheSync.java — 基于 Canal 的缓存同步 // 设计意图：监听 MySQL Binlog 变更，自动删除或更新对应缓存， // 实现数据库与缓存的最终一致性，无需在业务代码中处理缓存删除 import com.alibaba.otter.canal.client.*; import com.alibaba.otter.canal.protocol.*; import com.alibaba.otter.canal.protocol.exception.CanalClientException; public class CanalCacheSync { private final CanalConnector connector; private final JedisPool jedisPool; private volatile boolean running = true; public CanalCacheSync(String canalHost, int canalPort, String destination, JedisPool jedisPool) { this.connector = CanalConnectors.newSingleConnector( new InetSocketAddress(canalHost, canalPort), destination, "", "" ); this.jedisPool = jedisPool; } public void start() { Thread.ofPlatform().start(() -> { connector.connect(); connector.subscribe(".*\\..*"); // 订阅所有库所有表 connector.rollback(); while (running) { try { Message message = connector.getWithoutAck(100); long batchId = message.getId(); List<RowData> rows = message.getEntries().stream() .filter(e -> e.getEntryType() == EntryType.ROWDATA) .flatMap(e -> e.getRowDatas().stream()) .toList(); for (RowData row : rows) { processRowChange(row); } connector.ack(batchId); } catch (CanalClientException e) { // Canal 连接异常，重试 try { Thread.sleep(1000); connector.reconnect(); } catch (InterruptedException ie) { Thread.currentThread().interrupt(); break; } } } connector.disconnect(); }); } public void stop() { running = false; } private void processRowChange(RowData row) { // 根据变更的表和主键，构建缓存 key 并删除 // 这里需要建立 表名+主键 → 缓存 key 的映射规则 String tableName = extractTableName(row); String primaryKey = extractPrimaryKey(row); String cacheKey = buildCacheKey(tableName, primaryKey); try (Jedis jedis = jedisPool.getResource()) { jedis.del(cacheKey); } } private String extractTableName(RowData row) { // 从 RowData 中提取表名 return "table"; // 简化 } private String extractPrimaryKey(RowData row) { // 从 RowData 中提取主键值 return "pk"; // 简化 } private String buildCacheKey(String tableName, String primaryKey) { return String.format("cache:%s:%s", tableName, primaryKey); } }三、缓存异常场景处理
3.1 缓存穿透防护
// PenetrationGuard.java — 缓存穿透防护 // 设计意图：防止大量请求查询不存在的数据，绕过缓存直接打到数据库 import redis.clients.jedis.Jedis; import redis.clients.jedis.JedisPool; import java.util.*; public class PenetrationGuard { private final JedisPool jedisPool; private final BloomFilter<String> bloomFilter; // 布隆过滤器 private final String nullValueMarker = "NULL_CACHE"; public PenetrationGuard(JedisPool jedisPool, int expectedInsertions) { this.jedisPool = jedisPool; // 使用布隆过滤器预判数据是否存在 this.bloomFilter = BloomFilter.create( Funnels.stringFunnel(), expectedInsertions, 0.01 ); } public String getWithGuard(String key, DatabaseAccessor dbAccessor) { // 第 1 层防护：布隆过滤器判断数据是否可能存在 if (!bloomFilter.mightContain(key)) { return null; // 数据一定不存在，直接返回 } try (Jedis jedis = jedisPool.getResource()) { // 第 2 层防护：查询缓存 String cached = jedis.get(key); if (cached != null) { if (nullValueMarker.equals(cached)) { return null; // 空值缓存命中 } return cached; } // 第 3 层：查询数据库 String dbValue = dbAccessor.query(key); if (dbValue == null) { // 空值缓存：防止重复穿透 jedis.setex(key, 60, nullValueMarker); return null; } // 正常回填缓存 jedis.setex(key, 3600, dbValue); return dbValue; } } // 新数据写入时，同步更新布隆过滤器 public void addToBloomFilter(String key) { bloomFilter.put(key); } } // 简化的布隆过滤器接口 interface BloomFilter<T> { static <T> BloomFilter<T> create(com.google.common.hash.Funnel<T> funnel, int expectedInsertions, double fpp) { return null; // 实际使用 Guava BloomFilter } boolean mightContain(T key); void put(T key); }3.2 缓存雪崩防护
// AvalancheGuard.java — 缓存雪崩防护 // 设计意图：防止大量缓存同时过期，导致请求全部穿透到数据库 import redis.clients.jedis.Jedis; import redis.clients.jedis.JedisPool; import java.util.Random; public class AvalancheGuard { private final JedisPool jedisPool; private final Random random = new Random(); private final int baseExpireSeconds; private final int expireJitterSeconds; // 过期时间抖动范围 public AvalancheGuard(JedisPool jedisPool, int baseExpireSeconds, int expireJitterSeconds) { this.jedisPool = jedisPool; this.baseExpireSeconds = baseExpireSeconds; this.expireJitterSeconds = expireJitterSeconds; } // 设置带随机抖动的过期时间 public void setWithJitter(String key, String value) { int expireSeconds = baseExpireSeconds + random.nextInt(expireJitterSeconds); try (Jedis jedis = jedisPool.getResource()) { jedis.setex(key, expireSeconds, value); } } // 互斥锁重建缓存：防止并发请求同时重建 public String getWithMutex(String key, DatabaseAccessor dbAccessor) { try (Jedis jedis = jedisPool.getResource()) { String cached = jedis.get(key); if (cached != null) { return cached; } // 尝试获取互斥锁 String lockKey = "lock:" + key; String lockValue = String.valueOf(System.currentTimeMillis()); String result = jedis.set(lockKey, lockValue, "NX", "EX", 10); if ("OK".equals(result)) { try { // 获取锁成功，查询数据库并重建缓存 String dbValue = dbAccessor.query(key); if (dbValue != null) { setWithJitter(key, dbValue); } return dbValue; } finally { // 释放锁（使用 Lua 脚本保证原子性） releaseLock(jedis, lockKey, lockValue); } } else { // 获取锁失败，短暂等待后重试 try { Thread.sleep(50); } catch (InterruptedException e) { Thread.currentThread().interrupt(); } return jedis.get(key); // 再次查询缓存 } } } private void releaseLock(Jedis jedis, String lockKey, String lockValue) { String script = "if redis.call('get', KEYS[1]) == ARGV[1] then " + "return redis.call('del', KEYS[1]) else return 0 end"; jedis.eval(script, 1, lockKey, lockValue); } }四、边界分析与架构权衡
延迟双删的时间窗口：延迟删除的等待时间需要大于一次读请求的完整耗时（查缓存→查DB→写缓存），否则无法覆盖并发读场景。但等待时间过长会增加不一致窗口。通常设置为 500ms-1s，需要根据 P99 读延迟调整。
Canal 的可靠性：Canal 监听 Binlog 的方式依赖 MySQL 的 Binlog 配置。如果 Binlog 被清理或 Canal 消费延迟，缓存删除可能丢失。必须监控 Canal 的消费延迟，设置延迟告警。同时，Canal 本身是单点，需要部署高可用集群。
布隆过滤器的误判率：布隆过滤器判断"可能存在"时，有一定概率是误判（数据实际不存在）。误判率与过滤器大小和插入数量有关。对于缓存穿透防护，误判意味着少量请求仍会穿透到数据库，这是可接受的。
互斥锁的竞争：缓存重建时的互斥锁会导致同一时刻只有一个请求查询数据库，其他请求等待。如果数据库查询耗时较长，等待的请求可能超时。需要设置合理的锁超时时间和等待重试次数。
五、总结
Redis 缓存一致性方案的核心是在性能与一致性之间找到平衡。Cache Aside + 延迟双删是最常用的方案，适用于大多数业务场景；Canal 监听 Binlog 实现自动缓存同步，减少业务代码的侵入性；布隆过滤器和空值缓存防止穿透，随机过期时间和互斥锁防止雪崩。落地建议：读多写少的场景使用 Cache Aside + 延迟双删；对一致性要求高的场景引入 Canal 监听；缓存过期时间加随机抖动，避免雪崩；空值缓存设置短过期时间，防止穿透同时避免内存浪费。