请教一个问题，为什么 JetCache 用 Lettuce 返回的 RedisCommand 做 callback

[Roiocam]

背景

我们用 JetCache 发现大量 lettuce-ioEventLoop 会执行一些比较重的问题：如反序列化、如 Pub、Sub

分析

翻看 JetCache 源码是因为 JetCache 大量用 lettuce 返回的 RedisCommand 做 future 的 callback，虽然 RedisFuture（RedisCommand） 是一个 Future，但是这里似乎只是用来异步通知 bytebuffer 写进来了

我去翻了 lettuce 的源代码， lettuce-ioEventLoop 会执行 IO 读写操作，如果读到一个命令的返回结果，那么会取出 RedisCommand：

1. 写入到 CommandOutput 里
2. 然后他执行一遍 complete 通知异步回调，请求结束了（由于是 CompletableFuture 这里会去执行一些如 apply、handle 的 callback）

问题在于调用 complete 的是 IO 线程，callback 也会由 IO 线程来跑，如果再跑序列化的话，那么性能是很差的（总共没几个线程能执行）

我看了下 Spring Data Redis 的做法，他们没有在 Future 的 callback 里反序列化，而是返回 Byte[] 序列化是调用线程来做的

不知道我的理解对不对，如果是的话，这里似乎能解释为什么我们做大量 get 操作（没有本地缓存的时候）的时候，jetcache 跑得特别慢

[areyouok]

我没完全看懂你的描述，但你提示了很重要的问题。我理解是这样的：

Cache类提供的是异步接口，对于使用jedis的场景来说它本身没有支持异步，所以是同步转异步的“伪异步”，对于lettuce来说就是真正的异步。

CompletableFuture虽然是用来做异步开发的，但它的回调很容易堵塞本来不该堵塞的IO线程，这很容易搞错。JetCache本身虽然没有在这类回调里面执行IO操作，但编解码操作也是比较耗时的（此外lettuce api的回调里面也不该执行解码）。这些操作包括

• do_GET里面的解码操作。
• CacheMonitor回调，其中就包括发送缓存失效通知时，对CacheMessage的编码操作。
• BroadcastManager接收到CacheMessage，在回调中执行解码操作

可以把这些操作丢到另一个线程池里面去执行。

[Roiocam]

你的理解没错，测试代码如下：

也就是 JetCache 一开始其实是基于 Jedis 开发的，没什么问题，但是在 lettuce 这种真异步下，很多 future().handle() 和 future().apply() 这样的代码会阻塞 IO 线程，导致性能瓶颈

下面代码的输出是：hello: world. current thread: IO-Thread

 final CompletableFuture<String> future = new CompletableFuture<>();
        final CompletableFuture<String> newFuture = future.thenApply(e -> "hello: " + e + ". current thread: " + Thread.currentThread().getName());

        new Thread(() -> {
            try {
                Thread.sleep(700);
            } catch (InterruptedException e) {
                throw new RuntimeException(e);
            }
            future.complete("world");

        }, "IO-Thread").start();

        new Thread(() -> {

            String result = null;
            try {
                result = newFuture.get(1000, TimeUnit.MILLISECONDS);
                System.out.println(result);
            } catch (Exception e) {
                throw new RuntimeException(e);
            }
        }, "User-Thread").start();

[Roiocam]

还有一个

JetCache本身虽然没有在这类回调里面执行IO操作

其实是有的，Pub 就是一个 IO 操作，只不过因为不会在这个线程等 future 的结果，因此不会出现死锁问题。如果在这里等 future 的话是会死锁的（我们自己实现 Pub 的时候遇到过）

jetcache/jetcache-support/jetcache-redis-lettuce/src/main/java/com/alicp/jetcache/redis/lettuce/LettuceBroadcastManager.java

Lines 61 to 63 in 07de031

	byte[] value = config.getValueEncoder().apply(cacheMessage);
	RedisFuture<Long> future = stringAsyncCommands.publish(channel, value);
	return new CacheResult(future.handle((rt, ex) -> {

[Roiocam]

我有个想法是：

publish 似乎是需要序列化的（但是 JetCache 在 Publish 之前又反序列化了），这里其实没有必要。

对 future 的 callback 有两种情况：

• publish 场景：我认为可以直接 apply，并且优先级应该高于反序列化，因为这里也是在做 IO 操作
• 反序列化场景：应该由用户线程调用后触发，我的想法是在 CacheResult 的 waitForResul() 增加一个字段（Bifunction）如果用户希望等结果，那就反序列化给用户，这样总是由用户线程来做序列化/反序列化操作

这样可以 publish 路径中，无效序列化的问题

[Roiocam]

呃，看错了，cacheMessage 的序列化是必须要做的

[areyouok]

调用异步publish就不算了吧，那是不会堵塞的，不过感觉有点不太好，主调方和异步操作可能使用同一个线程池。

[Roiocam]

嗯嗯也是，异步不会 IO，一下子想错了。

但是如果异步的结果同步去拿(future.get())了，且 lettuce 的 dispatch 分给当前的 IO-Thread 了，那就死锁了。

[areyouok]

我看看怎么改一下

[areyouok]

这个问题比较好改，我已经改好了。但是很多单元测试原来是为同步方式开发的，现在就不能通过，还需要一些时间修复。

[Roiocam]

感谢！计划在 2.6.x 做一个 backport 吗？

[areyouok]

2.6不改。为什么不能升2.7啊，按兼容性文档肯定可以升的。而且2.6没有pub/sub本来影响就不大。

[Roiocam]

升级的问题是我们在 2.6.x 做了一版支持过滤部分 Key 的 Pub/Sub，我看 2.7 的官方实现是没有开放这个能力

2.6 的影响是大量 GET 场景下 Kryo 序列化阻塞了 IO 线程。

[areyouok]

我已经改好了，你可以试试。

关于你说的过滤的问题，可以通过注解的syncLocal来决定是否打开缓存失效通知。我知道这可能还不够，但不想堆太多只有部分人使用，并且容易被错误使用的功能。以缓存失效通知为例，2.7之前我一直没有做，现在做了也不知道是好事还是坏事，这功能看起来很好，但滥用就会形成广播风暴。

其实我预留了很多扩展点给你这类需求。自己定义一个SpringConfigProvider bean，覆盖notifyMonitorInstaller() 方法，然后覆盖NotifyMonitorInstaller的createMonitor方法（我刚给你弄的），就可以返回自己的CacheNotifyMonitor，你覆盖afterOperation就能实现过滤了。

有时间的话不如帮我看看github action为什么又挂了吧T_T，docker-compose命令找不到了，可能要固定ubuntu的版本才好。

[Roiocam]

docker-compose命令找不到了，可能要固定ubuntu的版本才好。

应该是 github 升级 docker compose 的语法到 v3 了，我提了个 PR 修复：#912

自己定义一个SpringConfigProvider bean，覆盖notifyMonitorInstaller() 方法，然后覆盖NotifyMonitorInstaller的createMonitor方法（我刚给你弄的），就可以返回自己的CacheNotifyMonitor，你覆盖afterOperation就能实现过滤了。

看起来不复杂，我先尝试看一下升级，谢谢～

[areyouok]

github action ok了，单测也过了，你先用snapshot试试吧，没问题过两天我再发布一个版本