1. 本文解决什么问题#

商品详情包含多个数据库查询。如果每次请求都回源，热点商品会反复读取同一批数据；若无效 SKU 大量进入，还会形成缓存穿透压力。

当前代码组合了三层机制：

1. Redisson RBloomFilter 前置判断；
2. 自定义 @CsmallCache 与 Redis AOP 缓存；
3. 每次请求创建固定线程池，用 CompletableFuture 编排独立和依赖任务。

本文只解释代码中真实存在的机制，不把它们表述为已压测或生产验证。

2. 主链路#

3. Bloom 初始化#

源码：duolaimall-product/product-service/src/main/java/com/cskaoyan/mall/product/runner/MyBloomFilter.java，MyBloomFilter#init。

1
@PostConstruct
2
public void init() {
3
    RBloomFilter<Long> bloomFilter =
4
            redissonClient.getBloomFilter(RedisConst.SKU_BLOOM_FILTER);
5

6
    long expectedInsertions = 100000;
7
    double falseProbability = 0.01d;
8

9
    bloomFilter.tryInit(expectedInsertions, falseProbability);
10
    List<Long> allOnSale = skuService.getAllOnSale();
11
    allOnSale.forEach(bloomFilter::add);
12
}

getAllOnSale 以 is_sale = 1 为条件，所以初始化集合表示“当时数据库中的已上架 SKU”。

它不是普通 JVM 集合：RBloomFilter 的数据依赖 Redis。

项目中还存在 MyBloomFilterRunner，它对同一个 key 调用 tryInit，但不加载 SKU；两个初始化组件同时存在是当前代码事实。

4. 详情入口怎样使用 Bloom#

源码：duolaimall-product/product-service/src/main/java/com/cskaoyan/mall/product/service/impl/ProductDetailServiceImpl.java，getItemBySkuIdAsync。

1
RBloomFilter<Object> bloomFilter =
2
        redissonClient.getBloomFilter(RedisConst.SKU_BLOOM_FILTER);
3

4
boolean contains;
5
try {
6
    contains = bloomFilter.contains(skuId);
7
} catch (Exception e) {
8
    log.warn("BloomFilter check failed, fallback to query. skuId={}",
9
            skuId, e);
10
    contains = true;
11
}
12

13
if (!contains) {
14
    return productDetailDTO;
15
}

标准 Bloom Filter 有假阳性，没有假阴性这一语义只成立于“数据已正确加载且没有丢失”的前提下。

当前边界：

• 下架没有从 Bloom 中删除 SKU；
• Bloom 返回 true 后数据库仍可能没有 SKU；
• 上架更新、启动加载与 Redis 状态可能短暂不同步；
• Bloom 不是权限和上架状态的最终事实源。

5. 哪些查询进入统一缓存#

getSkuPrice 没有 @CsmallCache，当前实现每次单独查询价格。

这体现出“详情静态信息可缓存、价格保持实时读取”的设计意图，但是否满足业务实时性并未运行验证。

6. 自定义缓存注解#

源码：duolaimall-product/product-service/src/main/java/com/cskaoyan/mall/product/cache/CsmallCache.java，CsmallCache。

1
@Target(ElementType.METHOD)
2
@Retention(RetentionPolicy.RUNTIME)
3
public @interface CsmallCache {
4
    String prefix();
5
}

注解只声明 key 前缀，命中、回源、锁和 TTL 都由切面统一处理。

优点是 Service 不重复缓存模板代码；代价是异常语义、空对象策略和 key 格式也被统一绑定。

7. 缓存 key 与第一次读取#

源码：duolaimall-product/product-service/src/main/java/com/cskaoyan/mall/product/cache/RedisAspect.java，RedisAspect#redisCache。

1
MethodSignature signature =
2
        (MethodSignature) joinPoint.getSignature();
3
Class<?> returnType = signature.getReturnType();
4
Method method = signature.getMethod();
5
Object[] args = joinPoint.getArgs();
6

7
CsmallCache annotation = method.getAnnotation(CsmallCache.class);
8
String prefix = annotation.prefix();
9
String key = prefix + ":" + Arrays.asList(args).toString();
10

11
RBucket<Object> bucket = redissonClient.getBucket(key);
12
Object obj = bucket.get();
13
if (obj != null) {
14
    return obj;
15
}

key 由注解前缀和参数列表构成。

部分前缀自身已带冒号，切面又拼接冒号，所以不要在文档或运维脚本中凭经验硬编码 key 文本，应以真实运行 key 为准。

8. 分布式锁与 double check#

源码同上：RedisAspect#redisCache。

1
String lockKey = key + RedisConst.SKULOCK_SUFFIX;
2
RLock lock = redissonClient.getLock(lockKey);
3

4
try {
5
    lock.lock();
6

7
    obj = bucket.get();
8
    if (obj != null) {
9
        return obj;
10
    }
11

12
    obj = joinPoint.proceed();
13
    // 后续写入缓存
14
} finally {
15
    lock.unlock();
16
}

热点 key 失效时的顺序：

1
第一次读取未命中
2
  -> 竞争同一 key 的分布式锁
3
  -> 获锁后再次读取
4
  -> 仍未命中才执行真实 Service
5
  -> 写缓存
6
  -> finally 解锁

第二次读取非常关键：其他请求可能在当前请求等待锁时已经完成回源。

当前使用 lock.lock()，调用处没有显式等待上限或固定租期；实际 watchdog 行为由 Redisson 运行配置决定，本文不作推断。

9. 空值与随机 TTL#

源码同上：RedisAspect#redisCache。

1
if (obj == null) {
2
    if (returnType.equals(List.class)) {
3
        obj = new ArrayList<>();
4
    } else if (returnType.equals(Map.class)) {
5
        obj = new HashMap<>();
6
    } else {
7
        try {
8
            Constructor<?> constructor =
9
                    returnType.getDeclaredConstructor();
10
            constructor.setAccessible(true);
11
            obj = constructor.newInstance();
12
        } catch (Exception ex) {
13
            obj = null;
14
        }
15
    }
16
}
17

18
long randomTime = RedisConst.SKUKEY_TIMEOUT
19
        + new Random().nextInt(100);
20
bucket.set(obj, randomTime, TimeUnit.SECONDS);

需要如实说明：

• 空值 TTL 常量存在，但切面没有单独使用；
• 空结果和正常结果使用同一基础 TTL；
• 普通对象的空实例与真实空对象难以区分；
• 无参构造失败后 obj 仍可能是 null；
• 没有看到商品修改时统一删除这些详情缓存。

10. 异步依赖图#

cf1 是依赖根节点；价格与平台属性只依赖 skuId，可以直接启动。

11. 每个请求创建线程池#

源码：duolaimall-product/product-service/src/main/java/com/cskaoyan/mall/product/service/impl/ProductDetailServiceImpl.java，getItemBySkuIdAsync。

1
ExecutorService executorService = Executors.newFixedThreadPool(8);
2

3
try {
4
    // 创建多个 CompletableFuture
5
} finally {
6
    executorService.shutdown();
7
}

这能展示异步编排，但每个 HTTP 请求都创建和销毁 8 线程池。

并发请求增加时，线程创建成本和总线程数量可能被放大；当前没有共享有界线程池、任务超时、取消或隔离配置。

12. 根任务与依赖任务#

源码同上：getItemBySkuIdAsync。

1
CompletableFuture<SkuInfoDTO> cf1 =
2
        CompletableFuture.supplyAsync(() -> {
3
            try {
4
                SkuInfoDTO skuInfo = skuService.getSkuInfo(skuId);
5
                productDetailDTO.setSkuInfo(skuInfo);
6
                return skuInfo;
7
            } catch (Exception e) {
8
                throw new CompletionException(e);
9
            }
10
        }, executorService);

SKU 基础查询异常会继续向 Future 传播，因为多个分支依赖它。

分类任务使用 thenAcceptAsync 消费根结果：

1
CompletableFuture<Void> cf3 = cf1.thenAcceptAsync(skuInfo -> {
2
    if (skuInfo == null) return;
3
    try {
4
        CategoryHierarchyDTO category =
5
                categoryService.getCategoryViewByCategoryId(
6
                        skuInfo.getThirdLevelCategoryId());
7
        productDetailDTO.setCategoryHierarchy(category);
8
    } catch (Exception e) {
9
        log.error("Query category failed. skuId={}", skuId, e);
10
    }
11
}, executorService);

海报、销售属性、规格映射与分类具有同样的“依赖 SKU、内部捕获异常”结构。

13. 独立任务与局部降级#

价格任务：

1
CompletableFuture<Void> cf2 = CompletableFuture.runAsync(() -> {
2
    try {
3
        BigDecimal price = skuService.getSkuPrice(skuId);
4
        productDetailDTO.setPrice(price);
5
    } catch (Exception e) {
6
        log.error("Query price failed. skuId={}", skuId, e);
7
    }
8
}, executorService);

异常被捕获后不再抛出，因此详情可能以 price = null 返回。

平台属性也独立查询，并过滤无有效值的属性：

1
String valueName = Optional.ofNullable(info.getAttrValueList())
2
        .orElse(Collections.emptyList())
3
        .stream()
4
        .filter(Objects::nonNull)
5
        .map(PlatformAttributeValueDTO::getValueName)
6
        .filter(StringUtils::isNotBlank)
7
        .findFirst()
8
        .orElse(null);
9

10
if (valueName == null) {
11
    return null;
12
}

这说明当前详情采用“SKU 根数据失败则整体失败，部分附属字段失败则返回不完整 DTO”的倾向。

但接口没有显式声明哪些字段允许为空，因此这只是从代码得出的行为判断。

14. 等待点与热度上报#

源码同上：getItemBySkuIdAsync。

1
CompletableFuture<Void> all = CompletableFuture.allOf(
2
        cf2, cf3, cf4, cf5, cf6, cf7);
3

4
all.whenComplete((v, ex) -> {
5
    if (ex != null) {
6
        log.error("Assembled ProductDetailDTO with exceptions. skuId={}",
7
                skuId, ex);
8
    }
9
}).join();
10

11
try {
12
    searchApiClient.incrHotScore(skuId);
13
} catch (Exception e) {
14
    log.warn("incrHotScore failed. skuId={}", skuId, e);
15
}

join 是返回前同步点。多个线程写同一 DTO 的不同字段，代码依赖“字段互不重叠且全部完成后再返回”。

热度 Feign 失败不会阻断详情响应。

15. 热度的 Redis 与 ES 双层状态#

源码：duolaimall-search/search-service/src/main/java/com/cskaoyan/mall/search/service/impl/SearchServiceImpl.java，incrHotScore。

1
RScoredSortedSet<Object> scores =
2
        redissonClient.getScoredSortedSet(RedisConst.HOT_SCORE);
3

4
scores.addScore(skuId, 1);
5
Double score = scores.getScore(skuId);
6

7
if (score != null && score % 2 == 0) {
8
    goodsRepository.findById(skuId).ifPresent(goods -> {
9
        goods.setHotScore(score.longValue());
10
        goodsRepository.save(goods);
11
    });
12
}

每次详情访问先增加 Redis ZSet 分数；分数为 2 的倍数时再写 ES 文档。

因此 Redis 与 ES 热度允许短暂不一致，而且跨 Redis 与 ES 的流程不是原子事务。

16. 失败与并发边界#

17. 已确认限制与候选风险#

18. 如果重做（非当前实现）#

1. 使用 Spring 托管、可复用、有界且可观测的线程池；
2. 为每个依赖任务定义超时、降级和必需字段；
3. 区分正常值 TTL 与空值 TTL；
4. 用商品变更事件统一删除或重建详情缓存；
5. 明确 Bloom 重建、增量更新和下架后的业务语义；
6. 将热度同步改为可重试、可观测的批处理或消息链路。

以上是演进方向，不是当前实现。

19. 关键源码导航#

20. 短复习点#

1. Bloom 的 false 才表示明确不在集合，true 仍要查事实数据。
2. 缓存切面用锁、double check、空对象和随机 TTL 分别处理常见缓存问题。
3. 当前异步依赖根是 SKU，价格与平台属性是独立分支。
4. 每请求创建线程池和缺少任务超时是必须说明的实现边界。
5. 热度先写 Redis、偶数分数再写 ES，不是跨存储原子更新。

21. 一句话总结#

当前商品详情用 Bloom 减少无效回源、用 Redis 切面保护热点查询、再用 CompletableFuture 并行聚合；思路完整，但线程池生命周期、缓存失效、空值语义和跨存储热度一致性尚未经过运行验证。