为什么网上都说Lettuce性能相对Jedis性能更好?

如果你搜过"Jedis vs Lettuce"。大概率会看到清一色的结论:Lettuce 更快、更现代,基于 Netty 的异步模型,一条连接就能扛住高并发;Jedis 是老旧的 BIO 模型,不用连接池的话性能堪忧。Spring Boot .x 把 Redis 的默认客户端从 Jedis 换成了 Lettuce,这条新闻又给"Lettuce 更好"这个结论加了一层官方背书。

我一开始也是信的。怎么说呢，但信了之后总觉得少点什么——这些文章大多数只给了一个"更快"的定性结论。很少有人把"多快""在什么条件下更快"讲清楚。压测参数、并发量、连接池怎么配的,往往语焉不详。既然 Jedis 是阻塞模型、Lettuce 是异步模型。这两者的性能曲线大概率不是一条直线的"谁全程碾压谁",而是会因为并发量变化交叉的。

使用者痛点: 开发者普遍依赖网络上的经验分享。但现有比较内容缺乏具体场景数据支持，导致选型决策存在风险。

直接说结果的观点是。分场景怎么选

如果你赶时间,直接看下面的场景对照表;完整的证据链、还有"Jedis 反超 Lettuce"这个反直觉结果是怎么测出来的,在后面几节里。

• 并发 ≤ :选 Lettuce 单连接。网上说的完全成立,而且代码更简单,不用管连接池怎么配。按理说，
• 并发 ~:单连接开始退化。该切连接池了,这时候用哪个客户端问题不大。
• 并发 ≥ 且必须用连接池:优先裸 Jedis。而不是想当然地继续用 Lettuce 连接池——这条是网上几乎不会告诉你的,因为很少有人测这个场景。说起来，
• 如果你在用 Spring Data Redis:上面这条要打个折扣。说起来，Spring 封装的 Jedis 在 线程下自己就掉了小一半性能。裸 Jedis 的优势被削弱了不少;而 Spring 封装的 Lettuce 几乎没有额外开销。真要在极高并发场景死磕性能,可能得考虑绕开 RedisTemplate 直接用裸客户端。

为什么选择困难?

使用者痛点:

1. 缺乏明确教程: 大多数文章只提供笼统建议而非具体场景推荐
2. 架构限制: 高并发环境下需要考虑连接池管理复杂度与性能权衡
3. 框架影响: Spring Data Redis封装带来额外开销影响最终选择

怎么测的的观点是。并发数 × 连接策略

只跑一轮"QPS 对比"就下结论太单薄,我想看的是一条曲线,而不是一个点——所以把参数拉成了两个维度:并发线程数 × 连接策略

为什么需要复杂测试方案?

4. 不确定因素多:

• 生产环境无法随意压测
• 测试成本与资源限制
• 必须平衡准确性与可行性

覆盖更多：从100到8000线程，涵盖绝大多数使用场景需求范围 公平对比：保证两种客户端配置参数完全对等可比

排除干扰：本地部署避免网络波动影响结果 验证机制：JMH微基准双重验证保障数据可靠性

⚡️关键点：通过程序化方法论消除主观判断，确保结论科学可靠⚡️

网上说的。先验证一遍