响应式缓存踩坑实录：操作符选错一步，内存直接飙到天花板

响应式缓存踩坑实录：操作符选错一步，内存直接飙到天花板

响应式编程中，缓存不再是简单的 map.get(key)，而是与 Mono/Flux 的生命周期纠缠在一起的精巧设计。你用 Mono.just(cache.get(key)) 试图提速，结果一个缓存穿透就把线程池堵死；你兴奋地启用了 Reactor 的 .cache() 操作符，几天后 OOM 排查才发现它缓存了整个流的历史数据；你贴上 @Cacheable 注解，期待它能像在 MVC 中那样工作，却发现 WebFlux 根本不吃这套。响应式缓存的坑，九成源于操作符选错了地方。

本文将逐一击破 Spring Boot WebFlux 中缓存操作符选择的典型疑难杂症，给出从同步库适配、响应式缓存抽象、缓存穿透/雪崩防护，到 .cache() 安全使用的完整方案，让你的缓存在响应式世界里不再“帮倒忙”。

一、血泪现场：响应式缓存的三种“谋杀”方式

1.1 线程池窒息：一个 Mono.just 引发的血案

public Mono<User> getUser(Long id) {
    User cached = localCache.getIfPresent(id);
    if (cached != null) {
        return Mono.just(cached);
    }
    return userRepository.findById(id)
        .doOnNext(user -> localCache.put(id, user));
}

当缓存未命中时，Mono.just(cached) 不会阻塞。但危险在于 localCache.getIfPresent 本身在某些实现中（如 LoadingCache.get）会同步加载数据，阻塞调用线程。如果这发生在 Netty I/O 线程上，服务瞬间窒息。

1.2 内存泄漏：.cache() 把整个历史记录都吞进肚

Flux<Message> chatStream() {
    return messageRepository.findAll()
        .cache(); // 天真地以为可以加速重放
}

.cache() 会无限缓存这个 Flux 发出的所有数据，任何新订阅都会收到完整历史。随着消息积累，内存占用无上限，最终 OOM。

1.3 缓存注解石沉大海：@Cacheable 在 WebFlux 中静默失效

@Cacheable(value = "users", key = "#id")
public Mono<User> getUser(Long id) {
    return userRepository.findById(id);
}

测试发现每次都查数据库。Spring 的 @Cacheable 默认基于 ThreadLocal 切面，对于返回 Mono 的方法，代理会立即返回 Mono 对象本身，而不是等待其完成后再缓存，导致缓存项永远是 Mono 的引用，而不是实际数据。

这些问题，都需要从操作符和缓存抽象的根本差异去解决。

二、响应式缓存的核心矛盾：同步 API 与异步流的适配

缓存库（Caffeine、Guava Cache、Redis）大多提供同步 API，而 WebFlux 需要非阻塞。适配的关键在于两个操作符：

• Mono.fromCallable(() -> cache.get(key))：将同步获取包装为惰性求值，不会在方法调用时立即执行。
• Mono.defer(() -> ...)：每次订阅都重新执行内部的表达式，保证获取的是最新缓存值。

常见误区：

• Mono.just(cache.get(key))：立即执行 cache.get(key)，即使订阅者尚未消费，且会阻塞调用线程。
• Mono.fromFuture(cache.get(key))：仅当缓存返回 CompletableFuture 时可用，普通同步缓存不行。

正确的非阻塞封装：

Mono<User> getUserFromCache(Long id) {
    return Mono.defer(() -> {
        User cached = localCache.getIfPresent(id);
        return cached != null ? Mono.just(cached) : Mono.empty();
    });
}

如果缓存操作可能阻塞（如 LoadingCache.get），必须额外使用 subscribeOn(Schedulers.boundedElastic())。

三、疑难一：Mono.just 与 Mono.defer 的选择——冷热之辨

3.1 场景：缓存旁路（Cache-Aside）模式

public Mono<User> findUser(Long id) {
    return Mono.defer(() -> {
        User cached = cache.getIfPresent(id);
        if (cached != null) return Mono.just(cached);
        return db.findById(id)
            .doOnNext(user -> cache.put(id, user));
    });
}

为什么必须用 Mono.defer？
Mono.just 是热的，创建时就已经确定值。如果将其写在 if 外部，缓存未命中时也会创建一个 Mono.just(null)，导致下游收到 null 而非空流。Mono.defer 保证每次订阅都重新执行 Supplier，动态判断是否命中。

3.2 对比错误写法

Mono<User> cached = Mono.justOrEmpty(cache.getIfPresent(id)); // 立即求值

若 cache.getIfPresent 是同步阻塞操作（如 Redis 的 opsForValue().get()），当前线程被阻塞。正确做法：

Mono<User> cached = Mono.defer(() -> {
    try {
        return Mono.justOrEmpty(redisTemplate.opsForValue().get(key));
    } catch (Exception e) {
        return Mono.empty();
    }
}).subscribeOn(Schedulers.boundedElastic()); // Redis 客户端同步操作需隔离

如果使用 ReactiveRedisTemplate，则无需隔离，直接使用其返回的 Mono。

四、疑难二：Reactor .cache() 操作符的“甜蜜陷阱”

Reactor 提供了内置的 .cache() 操作符，用于缓存 Flux 或 Mono 的结果，以便多个订阅者共享同一份数据。但用不好会成为内存炸弹。

4.1 问题一：无限缓存导致 OOM

.cache() 默认无限制地存储所有元素，历史数据永不丢弃。
解决方案：

• 使用 cache(Duration, Scheduler) 设置 TTL。
• 使用 cache(int history) 限制历史缓存大小。

Flux<Price> priceStream = marketDataService.stream()
    .cache(100, Duration.ofMinutes(5)); // 保留最近100条，或5分钟过期

4.2 问题二：缓存了整个 Mono 的错误信号

若 Mono 以错误告终，.cache() 也会缓存该错误，后续订阅全部直接收到错误。
解决方案：使用 retry 或 onErrorResume 在缓存之前处理错误，或使用 cacheMono 模式（如 CacheMono 库）。

4.3 替代方案：Mono.replay() 和 AutoConnect

对于需要重放历史的需求，可使用 .replay(int).autoConnect()，它与 .cache() 类似但更灵活，可以控制缓存数量和连接行为。

五、疑难三：Spring Cache 抽象在 WebFlux 中的适配

从 Spring Framework 5.3 开始，@Cacheable 可以在返回 Mono/Flux 的方法上使用，但需要额外注意：

5.1 必须使用响应式缓存提供者

只有响应式缓存库（如 spring-boot-starter-data-redis-reactive）才能真正支持非阻塞缓存。若底层是 Caffeine（同步），@Cacheable 仍会在线程池中执行，但必须确保缓存管理器配置正确。

spring:
  cache:
    type: redis
  redis:
    host: localhost
    port: 6379

5.2 正确包裹返回值

@Cacheable 需要方法返回 Mono 或 Flux，Spring 会自动适配：当 Mono 成功完成时，将发出的值存入缓存；下次调用时，直接返回缓存的 Mono。

@Cacheable(value = "users", key = "#id")
public Mono<User> getUser(Long id) {
    return userRepository.findById(id);
}

注意：若方法内部使用 subscribeOn 切换调度器，可能影响缓存切面的执行顺序，尽量保持简单。

5.3 缓存空值处理

防止缓存穿透，可以配置 @Cacheable(unless = "#result == null") 或使用 CacheErrorHandler 处理异常情况。

六、疑难四：缓存穿透与雪崩的响应式护盾

缓存穿透（大量不存在的 key 直接压到数据库）和缓存雪崩（大量缓存同时失效）在响应式下需要特有的防御手段，操作符的组合是关键。

6.1 缓存空值 + Mono.defer

public Mono<User> findById(Long id) {
    return Mono.defer(() -> cache.get(id))
        .switchIfEmpty(Mono.defer(() -> db.findById(id)
            .flatMap(user -> cache.set(id, user).thenReturn(user))
        ));
}

若数据库返回空，需要缓存空标记（如 Optional.empty()），使用 onErrorResume 兜底。

6.2 响应式请求合并（防穿透）

使用 Mono.cache 配合 groupBy 或 HystrixCollapser 的响应式版本（如 resilience4j 的 Bulkhead），但最简单的单机合并可用 Mono.fromCallable 结合 AtomicReference 实现单键锁定。

更优雅的方式是使用 Reactor 的 Transformers.cacheMono，它内部处理并发请求合并。

6.3 设置随机的 TTL 避免雪崩

在写入缓存时，为每个 key 的 TTL 增加随机抖动：

Duration ttl = Duration.ofSeconds(60).plusMillis(ThreadLocalRandom.current().nextInt(5000));
cache.set(key, value, ttl);

七、疑难五：flatMap 与缓存操作符的阻塞混淆

当缓存的获取方法返回 Mono，开发者常将 flatMap 和缓存逻辑混在一起，造成重复缓存、不必要的请求。

错误：

return Mono.just(id)
    .flatMap(id -> cache.get(id).switchIfEmpty(dbCall(id)))
    .flatMap(user -> cache.set(id, user).thenReturn(user)); // 重复设置

正确：使用 cache.get(id).switchIfEmpty(...) 旁路模式，避免额外设置。

标准模板：

public Mono<User> getUser(Long id) {
    return cache.get(id)
        .switchIfEmpty(
            db.findById(id)
                .flatMap(user -> cache.set(id, user, ttl).thenReturn(user))
        );
}

八、工具推荐与最佳实践

8.1 reactor-extra 的 CacheMono

专门解决响应式缓存的场景：

CacheMono.lookup(key -> cache.get(key).map(Signal::next), key)
    .onCacheMissResume(db.findById(key))
    .andWriteWith((key, signal) -> cache.put(key, signal.get()));

它提供了完整的缓存穿透保护、回源合并（同一 key 同时只有一个请求去数据库）等功能。

8.2 使用 Schedulers.boundedElastic() 隔离同步缓存

对于必须使用的同步缓存库，务必在获取时切换线程：

Mono<User> cached = Mono.fromCallable(() -> cache.get(key))
    .subscribeOn(Schedulers.boundedElastic());

同时设置合理的 boundedElastic 线程池大小，防止阻塞任务耗尽线程。

8.3 监控缓存的响应式行为

• 记录缓存命中率：在 doOnNext 和 switchIfEmpty 中埋点。
• 监控 .cache() 的内存占用：通过 Micrometer Gauge 统计缓存大小。

8.4 避免缓存整个流到内存

对于大容量流，切勿使用 .cache()。若需重放，将数据写入外部存储（如 Redis），再用 Flux.defer 读取，并限制读取速率。

九、常见坑点速查表

十、结语：操作符是刀，缓存是术，合一方能无痛加速

响应式缓存不是简单套用旧模式，而是在 defer、fromCallable、switchIfEmpty、cache() 等操作符的精密组合中，构建出一条既能高效返回数据，又能抵御穿透、雪崩和内存泄漏的安全通道。下次当你写下 Mono.just(cache.get()) 时，问问自己：是在 Netty 线程上阻塞了吗？是不是该用 defer？缓存的生命周期和流信号的生命周期是不是对齐了？把这几个问题答清楚，你的响应式缓存才能真正跑起来，而不是变成一次次线上事故的导火索。