Lettuce 高性能关键在于让 Netty 事件驱动模型真正运行：全局单例 RedisClient 复用 EventLoopGroup，线程安全的 StatefulRedisConnection 支持多线程并发调用 async/Reactive 接口，禁用 sync() 阻塞调用，配合 TCP 参数优化、超时重试配置及 Cluster/Sentinel 原生路由能力，实现单线程高并发、低延迟、无锁吞吐。
Java 中集成 Lettuce 并发挥其高吞吐能力，关键不在于“怎么连上 Redis”，而在于**如何让 Netty 的事件驱动模型真正跑起来、不被阻塞、不浪费线程资源**。Lettuce 本身不是靠“多开线程”提性能，而是用极少的线程（甚至单线程）处理成千上万个连接和命令——这需要从连接创建、调用方式到错误处理都按异步非阻塞逻辑来组织。
用对 RedisClient 和 StatefulRedisConnection
Lettuce 的高性能起点是连接对象的设计：
- 一个 RedisClient 可复用，且应全局单例：它内部管理 EventLoopGroup（如 NioEventLoopGroup），启动时就分配好线程池，频繁创建/关闭 client 会反复初始化 Netty 资源，拖慢吞吐。
-
StatefulRedisConnection 是线程安全的共享连接：不用像 Jedis 那样配连接池；多个业务线程可并发调用它的
async()或reactive()方法，所有命令自动排队进同一个 EventLoop，无锁、无竞争。 - 避免调用
sync()接口：虽然存在，但它是基于 Future.get() 封装的阻塞等待，会卡住当前线程，破坏 Netty 的非阻塞流水线——高并发下极易引发线程堆积甚至雪崩。
必须走异步或响应式 API 调用路径
只有 async/Reactive 接口才能把 Netty 的能力释放出来：
-
异步模式用 RedisFuture：例如
connection.async().set("k", "v")返回RedisFuture<string></string>（继承自 CompletableFuture），可链式调用thenApply、exceptionally，所有回调仍在 EventLoop 线程内执行，零线程切换开销。 -
响应式模式用 Mono/Flux：适合流式场景，比如批量查 10 万 key：
Flux.fromIterable(keys).concatMap(k -> connection.reactive().get(k))，内存恒定、背压可控、支持取消传播，比 for-loop + Future.get() 快数倍且不 OOM。 - 别在异步回调里做耗时操作（如 DB 查询、HTTP 调用）：若必须，用
publishOn(Schedulers.boundedElastic())切出 EventLoop 线程，防止阻塞 Netty 主循环。
Netty 层关键配置不能默认
Netty 的默认参数偏保守，生产环境需针对性调优：
立即学习“Java免费学习笔记（深入）”；
- 调整 EventLoopGroup 线程数：workerGroup 建议设为 CPU 核数（如 8），不建议盲目加大；过多线程反而增加调度开销，且 Netty 本就是单线程管多连接。
-
启用 TCP 参数优化：如
client.setOptions(ClientOptions.builder().pingBeforeActivateConnection(true).build())，配合tcpNoDelay(true)、soKeepAlive(true)减少小包延迟与连接僵死。 - 设置合理的超时与重试：全局命令超时（5.1+ 支持）比每个 Future 自己 setTimeout 更轻量；自动重连开启但要限制重试次数，避免雪崩式重连冲击服务端。
集群与哨兵模式天然适配，无需额外负载均衡
Lettuce 对高级部署模式的支持本身就是性能放大器：
- Redis Cluster 智能路由：启动时自动拉取 slot-node 映射表，后续所有命令根据 key 的 CRC16 直连目标节点，绕过代理层跳转，减少一次网络 RTT。
- 哨兵自动故障转移感知：当主节点宕机，Lettuce 在下一次命令失败后快速发现新主，并刷新连接，整个过程对上层业务透明，不中断请求流。
- 这些能力都不依赖外部组件（如 Twemproxy 或 Redis Proxy），没有中间转发损耗，吞吐更接近单机直连水平。
