【后端高阶面经：架构篇】47、缓存架构面试模拟：通读缓存 vs. 旁路缓存，你会选谁？-优快云博客

本文链接：https://blog.youkuaiyun.com/RickyIT/article/details/148252537

在这里插入图片描述

一、缓存架构核心概念：通读与旁路缓存深度解析

（一）面试级概念对比：从原理到场景

1. 通读缓存（Read-Through Cache）：智能的数据管家

定义：当应用请求数据时，缓存系统自动处理数据加载逻辑。若缓存命中，直接返回数据；若未命中，则由缓存主动从数据源加载数据并写入缓存，对应用完全透明。
典型实现：

CDN缓存：如阿里云CDN将静态资源（图片/JS/CSS）存储在全球边缘节点，用户请求时直接从最近节点获取，减少源站压力（命中率可达90%以上）。

反向代理缓存：Nginx通过proxy_cache模块实现动态内容缓存，示例配置：

proxy_cache_path /data/nginx/cache levels=1:2 keys_zone=my_cache:10m max_size=10g inactive=60m;
server {
    location / {
        proxy_cache my_cache;
        proxy_cache_valid 200 304 12h;
        proxy_pass http://backend;
    }
}

适用场景：适合对实时性要求不高、数据源稳定的场景，如新闻资讯、静态页面。

2. 旁路缓存（Cache-Aside）：灵活的数据助手

定义：应用程序负责维护缓存，先查询缓存，若未命中则查询数据源，再将结果写入缓存。缓存仅作为数据存储层，不主动干预数据加载。
典型实现：

本地缓存：Guava Cache通过LoadingCache实现按需加载：

LoadingCache<String, User> cache = CacheBuilder.newBuilder()
    .maximumSize(1000)
    .expireAfterAccess(10, TimeUnit.MINUTES)
    .build(key -> db.queryUser(key)); // 应用负责数据源查询

分布式缓存：Redis结合Spring Cache注解实现：

@Cacheable(value = "users", key = "#id")
public User getUserById(String id) {
    return userRepository.findById(id); // 应用主动查询数据库
}

适用场景：适合业务逻辑复杂、需要精细控制缓存策略的场景，如电商订单、用户个性化数据。

3. 核心区别对比表

维度	通读缓存	旁路缓存
数据加载方	缓存系统自动完成	应用程序负责
应用侵入性	低（透明化）	高（需编写缓存逻辑）
一致性保障	依赖缓存更新策略	依赖应用层逻辑
典型场景	静态资源、公共配置	动态业务数据、个性化内容
代表技术	CDN、Nginx proxy_cache	Guava Cache、Spring Cache + Redis

（二）缓存的核心价值与风险控制

1. 三大核心优势

性能加速：通过内存存储减少IO耗时，如Redis读取延迟约1ms，比MySQL快100倍以上。
计算复用：缓存预计算结果（如商品总价=单价×数量+运费），避免重复CPU计算。
负载分流：拦截80%以上的读请求，如电商详情页缓存可使数据库QPS从10万降至2万。

2. 五大注意事项与解决方案

问题	风险描述	解决方案
脏读	数据源更新后缓存未同步	① TTL过期（Redis设置EXPIRE） ② 事件驱动失效（监听Binlog删除缓存）
缓存穿透	大量无效请求击穿缓存直达数据库	① BloomFilter过滤不存在Key ② 布隆过滤器拦截（误判率控制在0.1%以内）
缓存雪崩	大量缓存同时失效导致数据库崩溃	① 随机TTL（300-600s随机值） ② 二级缓存（Caffeine+Redis分层保护）
缓存击穿	热点Key失效瞬间大量请求直达数据库	① 互斥锁（Redisson分布式锁） ② 提前预热（活动前加载热点数据到缓存）
内存溢出	缓存数据量超过内存限制	① LRU淘汰策略（Guava Cache默认策略） ② 定期清理（凌晨低峰期全量扫描）

二、多级缓存架构设计：从客户端到服务端的分层拦截

（一）典型四层缓存模型

graph TD
    A[用户请求] --> B{浏览器缓存}
    B -->|命中(200 OK)| C[返回数据]
    B -->|未命中| D{CDN缓存}
    D -->|命中(304 Not Modified)| C
    D -->|未命中| E{应用层缓存}
    E -->|命中| C
    E -->|未命中| F[分布式缓存(Redis)]
    F -->|命中| C
    F -->|未命中| G[数据源计算并回填]

（二）各层缓存技术实现

1. 浏览器缓存：前端性能优化首道防线

强缓存：通过Cache-Control: max-age=3600让浏览器直接使用本地缓存，无需发起请求。
协商缓存：通过ETag和If-None-Match校验数据是否更新，返回304状态码减少流量：
```
// 服务端响应头
ETag: "abc123"

// 客户端请求头
If-None-Match: "abc123"
```

2. 边缘缓存（CDN）：全球流量分发

配置示例：阿里云CDN配置静态资源缓存规则：
- 图片文件（.jpg/.png）缓存30天
- JS/CSS文件缓存7天
- 动态接口不缓存（URL包含/api/）

3. 进程内缓存：JVM级快速访问

Guava Cache高性能配置：

Cache<String, Object> cache = CacheBuilder.newBuilder()
    .maximumSize(10_000) // 最大容量1万条
    .concurrencyLevel(4) // 并发级别4（分段锁优化）
    .expireAfterAccess(5, TimeUnit.MINUTES) // 5分钟未访问则过期
    .recordStats() // 开启统计（命中率、逐出次数等）
    .build();

4. 分布式缓存：跨节点数据共享

Redis Pipeline批量操作：

# 一次性获取100个Key，减少网络RTT
with redis.pipeline(transaction=False) as pipe:
    for key in ["user:1", "user:2", ..., "user:100"]:
        pipe.get(key)
    results = pipe.execute()

三、预计算与异步更新：将计算前移的艺术

（一）事件驱动预计算架构

（二）增量计算优化：从全量到增量的跨越

1. 传统全量更新问题

# 全量计算用户积分（每天凌晨执行，耗时2小时）
def recalculate_all_scores():
    for user in all_users():
        score = calculate_score(user.id)
        redis.set(f"score:{user.id}", score)

2. 增量计算解决方案

-- 使用PostgreSQL触发器记录积分变更
CREATE TRIGGER update_score_trigger
AFTER INSERT ON orders
FOR EACH ROW
EXECUTE FUNCTION update_user_score();

-- 实时累加积分（仅计算变更数据）
CREATE OR REPLACE FUNCTION update_user_score()
RETURNS TRIGGER AS $$
BEGIN
    UPDATE users
    SET score = score + NEW.amount * 0.1  -- 消费1元积0.1分
    WHERE id = NEW.user_id;
    RETURN NEW;
END;
$$ LANGUAGE plpgsql;

四、智能缓存失效机制：精准控制数据新鲜度

（一）三大失效策略对比

策略	实现复杂度	一致性等级	典型场景
TTL过期	★☆☆☆☆	最终一致性	日志数据、非核心业务数据
版本号失效	★★★☆☆	强一致性	金融交易数据、库存信息
事件驱动失效	★★★★☆	准实时一致性	商品价格变更、用户信息修改

（二）事件驱动失效实战：基于Binlog的缓存清理

// 使用Debezium监听MySQL库存表变更
@KafkaListener(topics = "inventory.changes")
public void handleInventoryUpdate(ChangeEvent event) {
    String cacheKey = "product:" + event.getProductId();
    
    // 1. 立即删除旧缓存
    redis.del(cacheKey);
    
    // 2. 异步触发新数据计算（线程池处理）
    executorService.submit(() -> {
        Product newProduct = loadFromDatabase(event.getProductId());
        redis.set(cacheKey, newProduct, 3600); // TTL设置1小时
    });
}

五、计算复用与分布式锁：避免重复劳动的关键

（一）公共计算中间件架构

（二）分布式锁防重计算实现（Redisson）

public Object compute(String key) {
    RLock lock = redisson.getLock("compute_lock:" + key);
    try {
        // 尝试获取锁，最多等待10秒，锁自动释放时间30秒
        boolean isLocked = lock.tryLock(10, 30, TimeUnit.SECONDS);
        if (isLocked) {
            Object result = redis.get(key);
            if (result == null) {
                result = expensiveCompute(key); // 执行复杂计算
                redis.setex(key, 3600, result);
            }
            return result;
        } else {
            // 其他线程正在计算，重试3次
            for (int i = 0; i < 3; i++) {
                result = redis.get(key);
                if (result != null) return result;
                Thread.sleep(500);
            }
            throw new ComputeTimeoutException();
        }
    } catch (InterruptedException e) {
        Thread.currentThread().interrupt();
        throw new RuntimeException("Compute interrupted", e);
    } finally {
        if (lock.isHeldByCurrentThread()) {
            lock.unlock(); // 确保释放锁
        }
    }
}

六、监控与持续优化：数据驱动的缓存调优

（一）四大核心监控指标

指标	健康阈值	优化手段
缓存命中率	>90%	① 扩大热点数据缓存 ② 调整淘汰策略
计算重复率	<5%	① 优化失效策略 ② 增强缓存穿透防护
缓存内存使用率	<75%	① 数据压缩（Protobuf序列化） ② 集群扩容
预计算覆盖率	>80%	① 扩展预计算场景 ② 优化事件驱动链路

（二）热点Key实时监控（Redis 6.0+）

# 实时扫描热点Key（每100ms采样一次）
redis-cli --hotkeys --intrinsic-latency 100

# 输出示例：
# HOTKEY: tag:user:12345 (count=12345, type:string)
# HOTKEY: product:56789 (count=9876, type:hash)

七、实战案例：电商价格计算的92%计算量 reduction

（一）优化前流程（高计算成本）

（二）三级优化方案

1. 预计算价格快照

// 商品价格或促销变更时触发
@EventListener
public void onPriceOrPromotionChange(ChangeEvent event) {
    // 计算所有可能的价格组合（如满减、折扣、赠品）
    Map<String, BigDecimal> priceMap = calculateAllPriceVariants(event.getSku());
    
    // 写入Redis（Key包含促销版本号，如price:12345:v202310）
    redis.pipelined((pipe) -> {
        priceMap.forEach((promoKey, price) -> 
            pipe.setex("price:" + event.getSku() + ":" + promoKey, 86400, price)
        );
    });
}

2. 客户端缓存协商

// 客户端请求携带上次缓存的促销版本号
GET /api/price/12345?promo=v202310
If-None-Match: "5f4dcc3b5aa765d61d8327deb882cf99b"

// 服务端响应（未变更时返回304）
HTTP/1.1 304 Not Modified
ETag: "5f4dcc3b5aa765d61d8327deb882cf99b"

3. 结果复用中间件

（三）优化效果对比

指标	优化前	优化后	提升幅度
每次请求计算耗时	320ms	38ms	88%下降
数据库QPS	5000次/秒	1200次/秒	76%下降
重复计算次数	10万次/天	8000次/天	92%减少
缓存命中率	65%	95%	提升46%