导读：反向海淘系统在大促期间的单量可能是平时的几十倍。如何支撑高并发场景下的稳定运行？缓存是关键。本文结合taocarts的多级缓存架构，聊聊CDN、Redis、本地缓存三级策略的设计与实现。
一、反向海淘的并发挑战
代购系统的流量波动特征很明显。平时可能几千单很平稳，但一到黑五或者双十一大促当天，商品采集的请求量和对1688下单的并发请求量都会急剧攀升。1688接口本身有调用频率的限制，如果系统层面没有做好的缓存和限流策略，一旦请求量冲上去，不仅自己的系统可能会被打崩，1688账号还可能因为调用频率过高被临时封禁。
taocarts应对高并发场景的方案是做一个多级缓存架构。第一层用CDN来缓存静态资源，所有图片、CSS、JS文件都走CDN分发，减少源服务器的压力。第二层用Redis来做商品信息的缓存，TTL按30分钟来设置，大促期间为了数据新鲜度会缩短到5分钟。第三层用Caffeine做本地缓存，进一步降低访问Redis的网络开销。
二、多级缓存架构详解
2.1 整体架构层级
这个三级缓存架构的设计逻辑是逐层拦截请求。热点商品数据的读取请求，会先在第一级CDN或者浏览器缓存那里命中，没有命中的话再落到第二级Redis集群，依然没命中的话再去查第三级本地缓存，最后才落到数据库去查询。
层级分工上，CDN主要缓存静态资源和API响应的结果，适合那些不怎么变化的内容。Redis集群存的是热门的商品信息、汇率数据、运费模板这些变化频率适中但被频繁访问的数据。Caffeine本地缓存放的是超级热点数据，比如首页Banner的商品列表、大促期间主推的商品详情，在单个服务实例内部做缓存可以减少大量网络开销。
2.2 三级缓存协同代码实现
java
@Component
public class TaocartsCacheService {
@Autowired
private RedisTemplate<String, Object> redisTemplate;
@Autowired
private ProductRepository productRepository;
private final Cache<String, ProductDTO> caffeineCache = Caffeine.newBuilder()
.maximumSize(10000)
.expireAfterWrite(5, TimeUnit.MINUTES)
.recordStats()
.build();
private static final String PRODUCT_CACHE_PREFIX = "product:detail:";
public ProductDTO getProductWithMultiLevelCache(Long productId, String userId) {
String cacheKey = PRODUCT_CACHE_PREFIX + productId;
// L1: 检查用户级缓存（基于用户偏好）
String userCacheKey = cacheKey + ":user:" + userId;
ProductDTO userCached = (ProductDTO) redisTemplate.opsForValue().get(userCacheKey);
if (userCached != null && isCacheValid(userCached)) {
return userCached;
}
// L2: 检查Redis集群缓存
ProductDTO redisCached = (ProductDTO) redisTemplate.opsForValue().get(cacheKey);
if (redisCached != null && isCacheValid(redisCached)) {
// 异步预热用户级缓存
asyncWarmUpUserCache(cacheKey, userId, redisCached);
return redisCached;
}
// L3: 检查Caffeine本地缓存
ProductDTO localCached = caffeineCache.getIfPresent(cacheKey);
if (localCached != null && isCacheValid(localCached)) {
// 回写Redis（避免下次再次穿透）
redisTemplate.opsForValue().set(cacheKey, localCached, 30, TimeUnit.MINUTES);
return localCached;
}
// L4: 查数据库（防穿透处理）
ProductDTO product = getProductWithBloomFilter(productId);
if (product != null) {
// 逐级回填缓存
caffeineCache.put(cacheKey, product);
redisTemplate.opsForValue().set(cacheKey, product, 30, TimeUnit.MINUTES);
return product;
}
// 空值缓存，防止缓存穿透
redisTemplate.opsForValue().set(cacheKey, NULL_PLACEHOLDER, 5, TimeUnit.MINUTES);
return null;
}
// 布隆过滤器防止缓存穿透
private ProductDTO getProductWithBloomFilter(Long productId) {
if (!bloomFilter.mightContain(productId)) {
return null; // 一定不存在
}
return productRepository.findById(productId).orElse(null);
}
}三、热点数据预加载与防缓存击穿
大促期间，某个爆款商品被几万个用户同时访问的概率很高，如果缓存刚好在这个时间点过期，大量请求会同时穿透到数据库，可能导致数据库瞬时负载过高甚至宕机。这种现象叫做缓存击穿，和缓存雪崩（多个key同时过期）的问题是代购系统在大促时必须重点防范的两个场景。
taocarts的解决方案在这几个方面做了处理：使用互斥锁机制保证当某个热门商品缓存过期时只有一个线程去查数据库并重建缓存，其他线程等待锁释放后直接读取新缓存，避免大量请求同时打到数据库。对于预计会是大热门的商品，可以在缓存TTL到期之前主动触发一次预热刷新，确保缓存一直处于有效状态。Redis集群本身也做了高可用配置和自动故障转移，防止单个Redis节点宕机导致整个缓存层失效。
四、1688自动代采场景下的缓存策略
代采模块对缓存的要求更高。1688API调用频率有限制，不能短时间内频繁请求。taocarts的做法是在本地缓存一次会话的Token信息，避免每次调用都要重新登录1688；下单结果短时间内会缓存一个幂等校验，防止同一个订单被重复提交到1688；1688返回的运费模板和活动价格信息也会存入缓存并设置合理的TTL，减少API的调用量。