Redis高性能的核心在于服务端单线程+I/O多路复用模型，Linux下默认使用epoll，一个主线程监听成千上万个socket连接，仅在fd就绪时触发读写处理，全程无锁、无上下文切换；Java客户端如Lettuce或JedisPool需配合连接复用与合理配置，共同保障高并发能力。
Java 应用本身不直接实现 Redis 的 I/O 多路复用，而是通过客户端（如 Jedis、Lettuce）与 Redis 服务端通信；真正支撑高并发连接的是 Redis 服务端自身的单线程 + I/O 多路复用模型。Java 端只需合理使用客户端，就能高效复用这一底层能力。
Redis 服务端才是多路复用的执行主体
Redis 服务端在 Linux 上默认使用 epoll，在 macOS/BSD 上使用 kqueue，在其他系统上回退到 select/poll。它用一个主线程监听成千上万个 socket 连接，只在有实际读写事件（比如客户端发来命令、响应可发送）时才触发处理，避免轮询空转或线程阻塞。
- 每个客户端连接对应一个文件描述符（fd），Redis 把它们统一注册进 epoll 实例
- 当某个 fd 可读，epoll_wait() 立即返回该 fd，Redis 就解析 RESP 协议并执行命令
- 当响应数据准备好，Redis 把响应写入 socket 缓冲区，由内核异步完成网络发送
- 整个过程无锁、无上下文切换，单线程串行处理逻辑，天然避免并发竞争
Java 客户端要配合非阻塞与连接池
Java 程序不能破坏 Redis 的高效模型，因此应选用支持异步/连接复用的客户端，并避免创建过多短连接。
- Lettuce 基于 Netty，原生支持异步、响应式和连接共享（多个命令可复用同一 socket）
- Jedis 是同步阻塞客户端，推荐使用连接池（JedisPool），控制最大空闲/最大总连接数，防止耗尽 Redis 的 fd 资源
- 避免每请求新建 Jedis 实例——这会频繁建连、断连，加重 Redis 的 accept 和 close 开销
- 合理设置超时（connectTimeout、socketTimeout），防止因网络抖动导致线程长时间挂起
关键配置影响并发承载效果
Redis 服务端和 Java 客户端的配置共同决定实际并发能力。
立即学习“Java免费学习笔记（深入）”；
- Redis 需调大
maxclients（默认 10000），并确保系统级限制足够：ulimit -n至少设为 65536 - Linux 内核参数优化：增大
net.core.somaxconn（监听队列长度）、启用tcp_tw_reuse - Lettuce 连接池建议启用
PoolingConnectionProvider，设置合理的max pool size和min idle - JedisPool 配置示例：
maxTotal=200, maxIdle=50, blockWhenExhausted=true, testOnBorrow=true
为什么不用 Java 多线程模拟“多路”？
有人想在 Java 层用 NIO + Selector 自己做多路复用对接 Redis，这既没必要也不推荐。
- Redis 已经把 epoll/kqueue 封装得足够健壮，重复造轮子易出错且难维护
- Java NIO 的 Selector 在高负载下存在 wakeup 开销、空轮询等问题，稳定性不如 Redis 内核级实现
- 业务逻辑复杂度远高于网络调度，Java 线程更适合处理领域计算、事务编排等，而非争抢 I/O 调度权
- 让 Redis 专注 I/O，Java 专注业务，分工清晰，整体吞吐更高、故障面更小
