亿级流量缓存架构：多级缓存（本地→分布式→CDN）的一致性挑战

亿级流量缓存架构多级缓存本地→分布式→CDN的一致性挑战一、引言缓存是应对高并发的第一道防线但多级缓存的引入也带来了一个经典难题同一个数据在本地缓存、分布式缓存和CDN中可能存在三个不同的版本。当数据更新时如何保证各层缓存的一致性同时不损耗缓存带来的性能收益是架构设计的核心挑战。本文将设计一套Caffeine本地→ Redis分布式→ CDN边缘的三级缓存架构重点探讨各级间的更新策略和最终一致性方案。graph TB CLIENT[客户端请求] CDN[CDN边缘节点br/TTL: 30s-5min] LB[负载均衡] APP1[应用实例-A] APP2[应用实例-B] LOCAL1[Caffeine本地缓存br/实例Abr/TTL: 5s] LOCAL2[Caffeine本地缓存br/实例Bbr/TTL: 5s] REDIS[(Redis集群br/分布式缓存br/TTL: 30s-1h)] DB[(MySQL主库)] CANAL[Canal监听binlog] MQ[Kafka消息队列] CLIENT -- CDN CDN --|Cache Miss| LB LB -- APP1 LB -- APP2 APP1 -- LOCAL1 APP2 -- LOCAL2 LOCAL1 --|Cache Miss| REDIS LOCAL2 --|Cache Miss| REDIS REDIS --|Cache Miss| DB DB --|binlog| CANAL CANAL --|数据变更事件| MQ MQ --|缓存失效通知| REDIS MQ --|广播失效| APP1 MQ --|广播失效| APP2 style CDN fill:#e74c3c,color:#fff style REDIS fill:#f39c12,color:#fff style LOCAL1 fill:#3498db,color:#fff style LOCAL2 fill:#3498db,color:#fff二、三级缓存架构设计2.1 本地缓存层CaffeineCaffeine作为JVM内缓存提供微秒级访问延迟。其W-TinyLFU驱逐策略在高命中率和低内存占用之间取得了优秀的平衡。/** * 本地缓存管理器 - 基于Caffeine * 关键设计短TTL 主动失效通知 */ Component public class LocalCacheManager { private final CacheString, CacheEntry? cacheStore; private final RedisMessageListener redisListener; // 本地缓存TTL设为5秒——短到足以让最终一致性收敛 private static final Duration LOCAL_TTL Duration.ofSeconds(5); // 最大缓存条目数 private static final long MAX_SIZE 10_000; public LocalCacheManager(RedisMessageListener redisListener) { this.redisListener redisListener; this.cacheStore Caffeine.newBuilder() .maximumSize(MAX_SIZE) .expireAfterWrite(LOCAL_TTL) .recordStats() // 开启统计用于监控命中率 .removalListener((key, value, cause) - { if (cause RemovalCause.EXPIRED) { metricsCollector.incrementLocalCacheExpired(); } }) .build(); // 订阅Redis的失效通知频道 this.redisListener.subscribe(cache:invalidate, this::onInvalidationEvent); } /** * 读取缓存带降级策略 */ SuppressWarnings(unchecked) public T OptionalT get(String key, ClassT type) { CacheEntry? entry cacheStore.getIfPresent(key); if (entry null) { return Optional.empty(); } // 逻辑过期检查即使物理未过期标记为stale的数据也需要异步刷新 if (entry.isStale()) { asyncRefresh(key); // 仍然返回旧值避免缓存击穿 } return Optional.ofNullable((T) entry.getData()); } public void put(String key, Object data, Duration ttl) { cacheStore.put(key, new CacheEntry(data, ttl)); } /** * 处理来自Redis广播的失效事件 */ private void onInvalidationEvent(String message) { try { InvalidationEvent event objectMapper.readValue(message, InvalidationEvent.class); cacheStore.invalidate(event.getCacheKey()); log.debug(Local cache invalidated: key{}, event.getCacheKey()); } catch (JsonProcessingException e) { log.error(Failed to parse invalidation event: {}, e.getMessage()); } } private T void asyncRefresh(String key) { CompletableFuture.runAsync(() - { try { // 从Redis重新加载最新数据 T freshData redisCache.get(key, type); if (freshData ! null) { put(key, freshData, LOCAL_TTL); } } catch (Exception e) { log.warn(Async refresh failed for key{}: {}, key, e.getMessage()); } }, refreshExecutor); } }2.2 分布式缓存层RedisRedis层承担着跨实例共享缓存和读流量削峰的角色/** * Redis分布式缓存管理层 * 实现Cache Aside模式 逻辑过期双检 */ Component public class RedisCacheManager { private final StringRedisTemplate redis; private final RedissonClient redisson; private static final String LOCK_PREFIX lock:cache:rebuild:; private static final String STALE_PREFIX stale:; /** * 带逻辑过期的缓存查询防止缓存击穿 */ public T T getWithLogicalExpire(String key, ClassT type, FunctionString, T dbLoader, Duration physicalTtl, Duration logicalTtl) { String cacheKey key; String staleKey STALE_PREFIX key; String lockKey LOCK_PREFIX key; // 1. 查询缓存 String cachedJson redis.opsForValue().get(cacheKey); if (cachedJson ! null) { // 检查逻辑过期标记 Boolean isStale redis.hasKey(staleKey); if (Boolean.TRUE.equals(isStale)) { // 异步重建当前返回旧值 asyncRebuildCache(key, dbLoader, physicalTtl, logicalTtl, lockKey); } return objectMapper.readValue(cachedJson, type); } // 2. 缓存未命中——加锁重建防止缓存击穿和雪崩 RLock lock redisson.getLock(lockKey); try { if (lock.tryLock(3, 10, TimeUnit.SECONDS)) { // 双重检查 cachedJson redis.opsForValue().get(cacheKey); if (cachedJson ! null) { return objectMapper.readValue(cachedJson, type); } // 从数据库加载 T data dbLoader.apply(key); if (data ! null) { String json objectMapper.writeValueAsString(data); redis.opsForValue().set(cacheKey, json, physicalTtl); // 设置逻辑过期时间短于物理TTL redis.opsForValue().set(staleKey, 1, logicalTtl); } return data; } } catch (InterruptedException e) { Thread.currentThread().interrupt(); } catch (Exception e) { log.error(Cache rebuild failed for key{}: {}, key, e.getMessage()); } finally { if (lock.isHeldByCurrentThread()) { lock.unlock(); } } // 3. 获取锁失败返回null由上层降级处理 return null; } }三、缓存更新策略对比flowchart LR subgraph CacheAside CA1[更新DB] -- CA2[删除缓存] CA3[读取] -- CA4{缓存命中?} CA4 --|Yes| CA5[返回缓存] CA4 --|No| CA6[查DB] -- CA7[写缓存] -- CA5 end subgraph WriteBehind WB1[更新DB] -- WB2[记录变更日志] WB2 -- WB3[异步批量写缓存] end subgraph WriteThrough WT1[更新DB 同步写缓存] end策略适用场景优点缺点Cache Aside读多写少实现简单缓存只存热数据首次查询可能穿透需处理并发Write Through强一致性需求缓存始终与DB同步写入延迟加倍写多时性能差Write Behind写密集、可容忍短期不一致写入性能最高缓存与DB短暂不一致丢失风险对于三级缓存架构推荐Cache Aside Canal监听binlog的组合策略应用层更新DB后删除Redis缓存Cache AsideCanal异步监听binlog变更通过MQ广播失效通知到各应用实例的本地缓存。四、缓存穿透、击穿与雪崩的治理/** * 缓存异常场景防御组件 */ Component public class CacheDefenseComponent { private final StringRedisTemplate redis; private final BloomFilterString bloomFilter; // 布隆过滤器容量1000万条 private static final long BLOOM_EXPECTED_INSERTIONS 10_000_000L; private static final double BLOOM_FPP 0.001; // 0.1%误判率 public CacheDefenseComponent() { this.bloomFilter BloomFilter.create( Funnels.stringFunnel(StandardCharsets.UTF_8), BLOOM_EXPECTED_INSERTIONS, BLOOM_FPP ); } /** * 穿透防御布隆过滤器 空值缓存 */ public T OptionalT getWithPenetrationDefense(String key, ClassT type, FunctionString, T dbLoader) { // 第一道防线布隆过滤器判断key是否可能存在 if (!bloomFilter.mightContain(key)) { return Optional.empty(); // 一定不存在直接返回 } // 第二道防线空值缓存防止恶意查询不存在的key穿透到DB String nullKey null: key; if (Boolean.TRUE.equals(redis.hasKey(nullKey))) { return Optional.empty(); } T data dbLoader.apply(key); if (data null) { // 缓存空值TTL较短30秒 redis.opsForValue().set(nullKey, NULL, Duration.ofSeconds(30)); return Optional.empty(); } bloomFilter.put(key); return Optional.of(data); } /** * 雪崩防御过期时间加随机偏移 */ public Duration withJitter(Duration baseTtl, double jitterRatio) { long baseMs baseTtl.toMillis(); long jitterMs (long) (baseMs * jitterRatio * Math.random()); return Duration.ofMillis(baseMs jitterMs); } // 使用示例TTL 30min [0, 6min] 随机偏移 // Duration ttl withJitter(Duration.ofMinutes(30), 0.2); }五、总结三级缓存的一致性本质上是CAP理论在缓存层的体现——我们需要在一致性、可用性和性能延迟之间做权衡。CaffeineRedisCDN的架构中Caffeine层5秒TTL加上Redis广播失效提供了一个最终一致性窗口最长5秒CDN层30秒到5分钟的TTL适用于对一致性敏感度低但访问量大的静态资源。生产实践中的两个关键数字Caffeine本地命中率应维持在85%以上否则说明TTL过短或缓存容量不足Redis命中率应维持在95%以上否则需要检查缓存预热策略。缓存穿透的布隆过滤器误判率建议控制在0.1%以内对应的位数组大小约为插入量的10倍。这些数字不是绝对的但可以作为架构评审时的参考基线。