高并发系统中的多级缓存架构设计与实践

1. 项目背景与需求分析

在霸王餐这类高并发活动系统中，活动配置信息（如参与规则、库存总量、有效期等）的读取频率极高，但更新频率相对较低。每次请求都直接访问数据库会导致严重的IO压力，影响系统整体性能。我们实测发现，在未引入缓存前，数据库在活动高峰期CPU使用率经常超过80%，响应时间波动明显。

活动配置数据具有以下特点：

• 读多写少：配置变更频率低（每天约1-5次），但读取QPS可达5000+
• 数据量适中：单条配置约1KB，总活动数通常在1000个以内
• 强一致性要求：配置变更需要及时生效，不能出现长时间延迟

2. 缓存架构设计与选型

2.1 多级缓存架构

我们采用了两级缓存架构：

1. L1本地缓存：使用Caffeine实现，提供纳秒级访问速度
2. L2分布式缓存：使用Redis实现，保证多节点间数据一致性
3. S源数据库：MySQL作为最终数据源

为什么不使用三级缓存（如再加一层CDN）？因为活动配置数据量小且变化频繁，CDN的更新延迟可能无法满足业务需求。

2.2 技术选型依据

Caffeine选择理由：

• 相比Guava Cache，提供了更好的命中率和更灵活的淘汰策略
• 支持异步刷新，避免缓存失效时的请求风暴
• 丰富的监控指标，便于性能调优

Redis选择理由：

• 单线程模型保证原子性操作
• 丰富的数据结构和过期机制
• 成熟的集群方案支持水平扩展

3. 核心实现细节

3.1 缓存数据结构设计

Redis中采用String类型存储序列化后的JSON数据，键格式为：

code复制activity:config:{activityId}

这种设计考虑：

1. 简单直接，符合Redis最佳实践
2. 易于设置过期时间
3. 序列化/反序列化开销可接受

3.2 缓存加载流程

完整的数据加载流程如下：

java复制public TrialActivity get(String activityId) {
    // 1. 检查本地缓存
    TrialActivity activity = localCache.getIfPresent(activityId);
    if (activity != null) {
        cacheHitCounter.increment("local");
        return activity;
    }

    // 2. 检查Redis缓存
    String redisKey = REDIS_KEY_PREFIX + activityId;
    String json = redisTemplate.opsForValue().get(redisKey);
    if (json != null) {
        activity = deserialize(json);
        localCache.put(activityId, activity);
        cacheHitCounter.increment("redis");
        return activity;
    }

    // 3. 从数据库加载
    activity = dbRepository.findByActivityId(activityId);
    if (activity != null) {
        String serialized = serialize(activity);
        redisTemplate.opsForValue().set(
            redisKey, 
            serialized, 
            REDIS_TTL, 
            TimeUnit.MINUTES
        );
        localCache.put(activityId, activity);
        cacheLoadCounter.increment("db");
    }
    return activity;
}

3.3 缓存失效策略

当后台修改活动配置时，需要主动清除缓存：

java复制public void evict(String activityId) {
    // 立即失效本地缓存
    localCache.invalidate(activityId);
    
    // 异步删除Redis缓存
    redisTemplate.delete(REDIS_KEY_PREFIX + activityId);
    
    // 记录操作日志
    cacheEvictCounter.increment();
}

4. 高级优化技巧

4.1 防止缓存击穿

对于特别热点的活动，我们实现了带锁的加载机制：

java复制public TrialActivity getWithLock(String activityId) {
    return localCache.get(activityId, key -> {
        String redisKey = REDIS_KEY_PREFIX + key;
        
        // 双重检查
        String json = redisTemplate.opsForValue().get(redisKey);
        if (json != null) return deserialize(json);
        
        // 获取分布式锁
        String lockKey = "lock:" + redisKey;
        boolean locked = false;
        try {
            locked = redisTemplate.opsForValue()
                .setIfAbsent(lockKey, "1", 30, TimeUnit.SECONDS);
            
            if (locked) {
                TrialActivity fromDb = dbRepository.findByActivityId(key);
                if (fromDb != null) {
                    redisTemplate.opsForValue().set(
                        redisKey, 
                        serialize(fromDb), 
                        10, 
                        TimeUnit.MINUTES
                    );
                }
                return fromDb;
            }
            // 等待并重试
            Thread.sleep(100);
            return getWithLock(key);
        } catch (InterruptedException e) {
            Thread.currentThread().interrupt();
            return null;
        } finally {
            if (locked) redisTemplate.delete(lockKey);
        }
    });
}

4.2 缓存预热策略

在活动开始前30分钟，我们会主动预热缓存：

1. 扫描即将开始的活动ID列表
2. 批量从数据库加载配置
3. 并行写入Redis和本地缓存
4. 记录预热日志用于后续分析

5. 监控与调优

5.1 关键监控指标

我们监控以下核心指标：

1. 各级缓存命中率
2. 缓存加载耗时分布
3. 缓存内存使用情况
4. Redis连接池状态

5.2 性能调优经验

Caffeine配置优化：

java复制Cache<String, TrialActivity> localCache = Caffeine.newBuilder()
    .maximumSize(2000)  // 根据JVM堆内存调整
    .expireAfterWrite(5, TimeUnit.MINUTES)
    .refreshAfterWrite(1, TimeUnit.MINUTES)  // 后台刷新
    .recordStats()  // 开启统计
    .build();

Redis优化建议：

1. 使用连接池并合理设置参数
2. 对大value考虑压缩
3. 监控慢查询日志

6. 实际效果与经验总结

6.1 性能提升

实施多级缓存后：

• 平均响应时间从120ms降至8ms
• 数据库负载下降90%
• 高峰期系统稳定性显著提升

6.2 踩坑记录

1. 本地缓存不一致问题：早期没有及时清除本地缓存，导致节点间数据不一致。解决方案是引入Redis Pub/Sub通知机制。

2. 缓存雪崩风险：大量缓存同时失效导致数据库压力骤增。通过设置随机过期时间（±10%）来分散失效时间。

3. 序列化性能瓶颈：JSON序列化在高并发下成为瓶颈。改用Protobuf后性能提升30%。

7. 扩展思考

这种架构还可以应用于：

1. 商品详情页缓存
2. 用户基础信息缓存
3. 系统配置项管理

未来可能的优化方向：

1. 引入BloomFilter减少无效查询
2. 实现动态TTL策略
3. 探索新一代缓存技术如KeyDB