SB3的Redis客户端默认吞吐低是因Lettuce的Netty线程模型未调优：默认仅4个IO线程共享所有连接，高频小包场景下IO线程成瓶颈；需调大ioEventLoopGroup（如CPU×2）、配置computationEventLoopGroup、禁用useDaemonThreads，并同步优化连接池参数。
为什么 SB3 的 Redis 客户端默认吞吐上不去
Spring Boot 3 默认用 Lettuce 作为 Redis 客户端，底层基于 Netty。但开箱即用的配置对高并发写入或小包高频场景并不友好——吞吐卡在 1–2 万 QPS 很常见，不是代码写得有问题，而是 Netty 的线程模型没调优。
根本原因在于：LettuceClientResources 默认只启 4 个 ioEventLoopGroup 线程（Netty 的 IO 线程），且共享给所有连接；当 Redis 命令响应快、网络延迟低时，IO 线程反而成了瓶颈，大量连接争抢有限的 event loop，导致排队和上下文切换开销上升。
怎么改 Netty 线程池参数才有效
不能只改 ioEventLoopGroup 线程数，必须配合连接池与事件循环分离策略。关键是在自定义 ClientResources 时显式指定：
-
ioEventLoopGroup：建议设为 CPU 核数 × 2（如 8 核机器设 16），避免 IO 线程饥饿 -
computationEventLoopGroup：处理命令编解码、超时回调等非阻塞计算任务，设为 CPU 核数即可（如 8） - 禁用
useDaemonThreads（默认 true），否则 JVM 退出时 Netty 线程可能被强杀，导致连接泄漏
示例配置片段：
ClientResources resources = DefaultClientResources.builder()
.ioEventLoopGroup(new NioEventLoopGroup(16))
.computationEventLoopGroup(new DefaultEventLoopGroup(8))
.useDaemonThreads(false)
.build();
连接池配置必须同步调整
光调 Netty 线程池不够，LettucePoolingClientConfiguration 的连接池参数不匹配会放大瓶颈：
-
maxConnections要 ≥ioEventLoopGroup线程数，否则线程空转等连接 -
minConnections建议设为maxConnections的 50%～70%，避免冷启动抖动 - 务必关闭
validateConnectionOnBorrow（默认 false），开启会引入额外同步阻塞调用 - 如果用的是
RedisClusterClient，注意maxRedirects过高会拖慢失败路径，保持默认 5 即可
容易被忽略的兼容性陷阱
SB3.1+ 引入了 ReactiveRedisConnectionFactory 自动装配逻辑，如果你手动 new LettuceClientConfiguration 但没覆盖 RedisAutoConfiguration，Spring 仍会加载默认资源，你的线程池配置实际没生效。
验证是否生效的方法：
- 启动时 grep 日志：
Creating LettuceClientResources with ioEventLoopGroup=NioEventLoopGroup-16 - JVM 运行中执行
jstack -l <pid> | grep NioEventLoop，确认线程数符合预期 - 压测时观察
netstat -an | grep :6379 | wc -l和top -H -p <pid>，看线程负载是否均衡
Netty 线程池不是越大越好，超过物理核数太多反而因调度开销降低吞吐；真正卡点往往在连接复用率和序列化效率，别一上来就堆线程数。
