一、Jedis源码级学习要点
1. 线程模型与连接管理
- 阻塞式I/O设计：通过Socket直接建立连接，每个命令发送后线程会阻塞等待响应25
- 连接池实现：JedisPool管理物理连接，避免线程安全问题，核心类GenericObjectPool实现连接复用57
- 资源竞争优化：JedisCluster通过哈希槽映射实现集群命令路由，关键类JedisSlotBasedConnectionHandler处理节点定位5
2. 高性能设计
- 二进制协议优化：BinaryJedis类支持原生二进制操作，减少序列化开销5
- 管道批处理：Pipeline类实现批量命令打包发送，减少网络往返次数（10万次操作耗时从4秒降至0.6秒）5
- 序列化扩展：通过JedisCluster.NodeResource支持自定义序列化协议5
3. 核心源码结构
- 命令执行入口：Jedis#sendCommand()方法封装协议组装逻辑
- 响应解析：Protocol#process()方法处理RESP协议解析
- 异常处理：JedisConnectionException捕获网络层异常
个人总结
老生常谈的web应用性能两大重点:多线程&IO;
Jedis使用的是BIO模型,在高并发要求下性能是不会比NIO模型好
虽然是BIO阻塞读写,但Pipeline模式可以一次性发送多条指令,不等待指令执行结果传回后再执行下一条指令;
Pipline模式允许异步等待返回而非指令串行,这可以轻松提升十倍;
Pipeline内部有序存储指令执行顺序,有序读取网络io返回;
但这本身就说redis提供的能力,io-stream同时可以写入多条指令,只要按执行顺序读取就行,相比正常模式下,发送指令后要等待指令返回,pipeline对可以批量执行的指令提升很大, 但多数业务场景下都需要指令实时返回结果;
二、Lettuce源码级学习要点
1. 异步通信架构
- Netty事件驱动：基于EventLoopGroup实现非阻塞I/O，核心类ChannelHandler处理命令编解码
- 连接复用机制：StatefulRedisConnection线程安全，支持多线程共享连接
- 响应式扩展：通过RedisReactiveCommands实现Reactive Streams支持
2. 同步/异步转换机制
- 动态代理设计：RedisAdvancedClusterCommands接口通过ClusterFutureSyncInvocationHandler将异步结果转为同步
- Future处理优化：LettuceFutures.awaitOrCancel() 实现带超时的异步结果等待
3. 集群支持设计
- 拓扑动态更新：ClusterTopologyRefresh定时刷新集群节点状态
- 自适应路由：PartitionSelector根据哈希槽动态选择目标节点
个人总结
使用了Netty做客户端的io管理,没有所谓的pipeline模式: 如果理解pipeline的实现原理可以发现该功能只是开放了异步等待结果;
使用Netty(NIO模型)对比Jedis的BIO模型网络性能更嘉,同时多线程共享连接;
Lettuce 的默认设计每个client(连接)不支持线程安全,如使用RedisAsyncCommands(异步模式),如果多线程调用flushall会影响其他线程的执行节奏;
Lettuce 基于 Apache Common-pool2 组件提供了连接池的能力,没有自带的池化实现;
Lettuce 相较于Jedis，使用上更加方便快捷，抽象度高。并且通过线程安全的连接降低了系统中的连接数量，提升了系统的稳定性。
三、Redisson源码级学习要点
1. 分布式数据结构实现
- 对象代理机制：RMap、RList等通过RedissonObject封装Redis命令，实现Java集合接口
- 锁续期设计：RedissonLock使用看门狗线程（LockWatchdog）自动延长锁有效期
2. 网络通信优化
- 连接池扩展：ConnectionManager支持单连接/连接池混合模式，针对不同操作类型优化
- PubSub高效分发：PubSubConnectionEntry管理订阅通道，实现消息的线程安全分发
3. 分布式锁实现
- Lua脚本原子性：加锁操作通过EVAL命令执行Lua脚本保证原子性
- 红锁算法：RedissonRedLock实现多节点加锁的容错机制
个人理解
同样使用Netty
创建了一个独立线程池实现watch dog等高级功能
Redisson提供的更多高级功能,同时也提供的深度的抽象;
四、对比与选型指导
| 维度 | Jedis | Lettuce | Redisson |
|---|---|---|---|
| 线程模型 | 阻塞I/O+连接池 | 非阻塞I/O（Netty） | 非阻塞I/O+分布式扩展 |
| 性能瓶颈 | 高并发时连接池竞争 | 单连接支持高并发 | 复杂操作有额外开销 |
| 适用场景 | 简单同步操作 | 高吞吐量/响应式编程 | 分布式系统/复杂数据结构 |
五、基准测试
| 客户端 | 基准测试 | 说明 |
|---|---|---|
| Jedis | 3.754 | 单个连接不支持并发,只能串行,对于web应用而已,业务处理线程肯定比连接数量高 |
| Lettuce | 7.892 | 支持并发操作,非阻塞占用单个连接 |
| Redisson | 5.453 | 支持并发操作,高级线程连接池管理 |
如果连接需求>能提供的连接数量,优先选择基于netty的Lettuce和Redisson