Spring Flux使用Reactive Redis Template时后续阶段线程切换相关问题

现象说明 #

当响应式处理链中间使用Reactive Redis Template执行操作后，后续阶段的执行线程会发生变化，对应的示例代码如下：

return Flux.fromArray(new String[]{"1", "2", "3"}).map(s -> s.toUpperCase()).flatMap(s -> {
    System.out.println(Thread.currentThread().getName());
    return redisTemplate.opsForValue().set(s, s);
}).map(aBoolean -> {
    System.out.println(Thread.currentThread().getName());
    return aBoolean.booleanValue();
}).log();

可以观测到第一个map运行在reactor-http-nio-3线程（Web容器的IO线程），第二个map运行在lettuce-nioEventLoop-5-1线程。 #

问题1：是否意味着Reactive Redis Template拥有专属的scheduler，会对后续所有执行阶段产生影响？ #

是的，本质是Reactive Redis Template底层默认依赖的Lettuce Redis客户端，维护了独立的NIO EventLoop线程池，所有Redis异步IO操作的完成信号默认都会在这个专属线程池上发布。
根据Reactor的默认线程传播规则，在没有显式指定publishOn切换线程的前提下，处理链后续的所有算子都会继承上游信号的发布线程运行，所以会出现后续所有执行阶段都切到Lettuce线程的现象。 #

问题2：是否需要在Redis操作完成后切换为自定义的scheduler来执行后续处理逻辑？ #

按需判断即可：

• 如果后续逻辑是无阻塞的轻量操作（比如简单数据转换、字段拼接、逻辑判断），不需要切换，直接使用Lettuce线程运行即可，额外切换反而会带来不必要的线程调度开销。
• 如果后续逻辑包含阻塞操作（比如同步JDBC查询、文件IO、CPU密集型重计算），必须切换到自定义的Scheduler执行，否则会占用Lettuce的IO核心线程，导致整个Redis客户端的所有请求被阻塞，严重降低服务性能。切换方式很简单，在Redis操作的flatMap之后追加publishOn(自定义Scheduler实例)即可。

内容的提问来源于stack exchange，提问作者Mark