亿级流量下的缓存架构设计:Redis+Caffeine多级缓存实战

亿级流量下的缓存架构设计:Redis+Caffeine多级缓存实战

一、为什么需要多级缓存?

在亿级流量场景下,单纯依赖Redis会遇到三大瓶颈:

  • 网络延迟:Redis远程访问通常需要1-5ms,QPS超过10万时成为瓶颈

  • 资源成本:高频读取导致Redis CPU飙升至80%+

  • 可用性风险:Redis集群故障时数据库直接被击穿

多级缓存架构正是破局关键:
客户端 浏览器本地缓存 CDN缓存 Nginx代理缓存 应用层Caffeine缓存 Redis分布式缓存 MySQL数据库

二、Caffeine+Redis核心架构设计

2.1 组件定位

组件 特性 适用场景
Caffeine 进程内缓存,访问速度纳秒级 高频热key(如秒杀商品)
Redis 分布式缓存,数据一致性高 全量数据缓存层

2.2 数据流转流程

java 复制代码
public Product getProduct(Long id) {
    // 1. 查询Caffeine
    Product product = caffeineCache.getIfPresent(id);
    if (product != null) {
        return product; 
    }
    
    // 2. 查询Redis(加分布式锁防击穿)
    product = redisUtil.getWithLock("product:" + id, 
             lockKey -> loadFromDB(id),  // 缓存未命中时查DB
             3, TimeUnit.SECONDS);
    
    // 3. 回填Caffeine(设置短过期时间)
    caffeineCache.put(id, product, 30, TimeUnit.SECONDS);
    return product;
}

三、关键技术实现

3.1 Caffeine高效配置

java 复制代码
Caffeine<Object, Object> caffeine = Caffeine.newBuilder()
    .maximumSize(10_000)                 // 基于容量淘汰
    .expireAfterWrite(30, TimeUnit.SECONDS) // 写后过期
    .refreshAfterWrite(5, TimeUnit.SECONDS) // 异步刷新
    .recordStats();                      // 开启监控统计

LoadingCache<Long, Product> cache = caffeine.build(id -> {
    // 异步加载函数(避免阻塞请求线程)
    return loadFromRedis(id); 
});

3.2 Redis热点Key处理

java 复制代码
// 使用Redis集群分片+本地缓存分摊压力
public Product getProduct(Long id) {
    int slot = id % 100; // 分片逻辑
    String key = "product:" + slot + ":" + id;
    
    // 先读本地缓存再读Redis...
}

3.3 缓存一致性保障

双删策略+版本号控制:

java 复制代码
// 更新数据时
public void updateProduct(Product product) {
    // 1. 更新数据库
    db.update(product);
    
    // 2. 删除Redis(失败重试3次)
    redis.deleteWithRetry("product:"+product.getId());
    
    // 3. 延迟500ms二次删除(防旧数据回填)
    scheduleTask(() -> {
        redis.delete("product:"+product.getId());
        caffeine.invalidate(product.getId());
    }, 500);
    
    // 4. 设置版本号(解决并发更新)
    redis.incr("version:"+product.getId());
}

四、性能压测对比

使用JMeter模拟100万QPS:

方案 平均响应时间 Redis CPU 数据库QPS
纯Redis 12ms 92% 1800
多级缓存 1.8ms 35% <10

性能提升点:

  • 99%的热点请求被Caffeine拦截

  • Redis负载下降60%

五、避坑指南

缓存污染问题

解决方案:Caffeine配置weakKeys+softValues

java 复制代码
.weakKeys().softValues()  // 启用弱引用+软引用

冷启动雪崩

预热方案:使用Guava的CacheLoader预加载热数据

java 复制代码
CacheLoader.asyncReloading((id) -> loadFromDB(id), executor)

监控告警体系

java 复制代码
// 通过Micrometer暴露指标
CaffeineMetrics.monitor(monitorRegistry, cache, "productCache");

监控看板需包含:

Caffeine命中率(Hit Ratio)

Redis连接池等待时间

六、扩展优化方向

热点探测:基于Redis的hotkeys命令动态识别热数据

分级存储:

  • L1:Caffeine(最新数据)

  • L2:Redis(全量数据)

  • L3:磁盘缓存(历史数据)

流量调度:根据用户IP路由到就近缓存节点

相关推荐
姓蔡小朋友35 分钟前
SpringDataRedis
java·开发语言·redis
喝杯牛奶丶1 小时前
MySQL隔离级别:大厂为何偏爱RC?
java·数据库·mysql·面试
一 乐1 小时前
二手车销售|汽车销售|基于SprinBoot+vue的二手车交易系统(源码+数据库+文档)
java·前端·数据库·vue.js·后端·汽车
Databend1 小时前
BendSQL v0.30.3 Web UI 功能介绍
数据库
gAlAxy...1 小时前
Spring 从 0 → 1 保姆级笔记:IOC、DI、多配置、Bean 生命周期一次讲透
数据库·sqlserver
苦学编程的谢2 小时前
Redis_5_单线程模型
数据库·redis·缓存
xuejianxinokok2 小时前
可能被忽略的 pgvector 各种坑
数据库·后端
拾忆,想起2 小时前
TCP粘包拆包全解析:数据流中的“藕断丝连”与“一刀两断”
java·网络·数据库·网络协议·tcp/ip·哈希算法
serve the people2 小时前
Formatting Outputs for ChatPrompt Templates(two)
前端·数据库
JanelSirry3 小时前
Java + Spring Boot + Redis技术栈,在实际使用缓存时遇到 缓存击穿、缓存穿透、缓存雪崩
java·spring boot·缓存