JAVA项目对接redis，客户端是选Redisson、Lettuce还是Jedis？
- 一、客户端简介
- 1. Jedis介绍
- 2. Lettuce介绍
- 3. Redisson介绍
- 二、横向对比
- 三、选型说明
在实际的项目开发中，对于一个需要对接Redis的项目来说，就面临着选择合适的Redis客户端。目前比较常用的Redis客户端有Redisson、Lettuce和Jedis，两者都有各自的优点和适用场景，本文将对三者进行比较，并给出选择的建议。
📕作者简介：战斧，从事金融IT行业，有着多年一线开发、架构经验；爱好广泛，乐于分享，致力于创作更多高质量内容
📗本文收录于 Redis专栏 专栏，有需要者，可直接订阅专栏实时获取更新
📘高质量专栏 云原生、RabbitMQ、Spring全家桶 等仍在更新，欢迎指导
📙Zookeeper Redis kafka docker netty等诸多框架，以及架构与分布式专题即将上线，敬请期待
一、客户端简介
1. Jedis介绍
Jedis代码仓库地址：https://github.com/redis/jedis 。它是Redis对Java语言所推出的官方客户端，可见下图
Jedis的主要特点如下：
-
简洁高效：Jedis的设计简洁高效，性能较好，可以通过直接发送命令字符串与Redis进行通信，适用于对Redis的原生命令操作更为关注的场景。
-
社区活跃：Jedis是最早的Java Redis客户端，拥有庞大的用户社区和完善的文档支持，可以方便地获取到各种使用案例和问题解答。
-
支持大部分特性：Jedis支持Redis的大部分特性，如事务、流水线、发布/订阅等，可以满足绝大多数的需求。
简而言之，作为官方客户端，各种命令及功能的支持自然是齐全的，社区及文档的支持也是最完善的。
2. Lettuce介绍
Lettcue代码仓库地址：https://github.com/redis/lettuce 。自从Lettcue并入Redis官方后（如下新闻），我们可以说Jedis是长子，Lettcue就是次子，也成为了官方推荐的客户端。
Lettuce主打高性能，它的主要特点如下：
-
异步IO：Lettuce使用异步IO和非阻塞IO模型，可以在一个线程中处理多个并发请求，提供了更好的并发能力和响应速度。它使用了Netty作为底层网络通信框架，充分利用了Netty的高性能和可扩展性。
-
响应式编程：Lettuce支持响应式编程模式，使用Reactive Streams来处理异步数据流。通过使用响应式编程，可以简化异步编程的复杂性，提供了更加灵活和可组合的方式来处理Redis的响应。
-
连接池：Lettuce内置了连接池功能，可以管理和复用Redis的连接，提供了更好的连接管理和资源利用。连接池可以有效地减少连接的创建和销毁开销，提高了系统的性能和稳定性。
-
高可用和集群支持：Lettuce支持Redis的高可用和集群模式，提供了自动的节点发现和故障转移功能。它可以自动检测集群的拓扑结构，并在节点故障时进行自动切换，保证数据的可用性和持久性。
-
扩展性和灵活性：Lettuce提供了丰富的功能和API，可以满足各种不同的需求。它支持事务、管道、发布-订阅等特性，还提供了对Redis Sentinel、Redis Cluster和Redis Streams等功能的支持。同时，Lettuce也支持自定义的扩展，可以方便地进行功能扩展和定制开发。
简而言之，相比Jedis，Lettuce提升了性能，丰富了功能，对于开发者来说就减少了自己造轮子。
3. Redisson介绍
Redisson代码仓库地址：https://github.com/redisson/redisson 。虽然并不是官方客户端，但是其热度却超过了上述两个‘亲儿子’
Redisson主打功能丰富，它的主要特点如下：
-
分布式对象：Redisson支持将Java对象存储在Redis中，以及在分布式环境中进行操作和调用。这使得开发人员可以更方便地使用常规的面向对象编程方式来处理分布式数据。
-
分布式集合：Redisson提供了一系列分布式集合数据结构，比如Set、List、Queue、Deque、Map等。这些数据结构可以在分布式环境中进行操作和处理，使得开发人员能够更方便地实现分布式应用。
-
分布式锁：Redisson提供了一种分布式锁的实现，支持公平锁和非公平锁两种模式。这使得开发人员可以更容易地实现分布式环境下的并发控制，避免数据竞争和资源争用。
-
分布式调度器：Redisson提供了一种分布式调度器的实现，可以让开发人员在分布式环境中进行任务调度和定时任务的管理。这使得分布式应用的任务调度更加方便和灵活。
-
集群支持：Redisson支持Redis的集群模式，可以轻松地在Redis集群中进行数据操作和处理。这使得Redisson能够处理大规模的数据量和高并发的请求。
简而言之，相比前两者，Redisson提供了更多贴近业务的功能，在性能上也做了优化 。
二、横向对比
看完三大客户端的特点，其实不难发现针对Redis的基础用法是大家都有的，重点就是是否内置“高级功能”，以及对“连接性能”的追求。Jedis的主要不足在于它不支持异步和响应式API；Lettuce有高性能的异步和响应式API，但在“高级功能”（如分布式功能）方面的支持相对有限，Redisson则有很多高级功能也做了连接优化，但也因此比较复杂臃肿，处理简单的Redis操作时反倒浪费了一些性能。它们的部分特性对比如下：
| 特性 | Redisson | Lettuce | Jedis |
|---|---|---|---|
| 异步IO | 是 | 是 | 否 |
| 非阻塞IO | 是 | 是 | 否 |
| 连接池 | 是 | 是 | 是 |
| 分布式锁 | 是 | 否 | 否 |
| 分布式集合 | 是 | 否 | 否 |
| 哨兵模式 | 是 | 是 | 是 |
| 主从复制 | 是 | 是 | 是 |
| 集群模式 | 是 | 是 | 是 |
| 性能 | 高 | 高 | 一般 |
| 功能丰富性 | 非常丰富 | 较丰富 | 基本 |
| 学习曲线 | 较陡 | 适中 | 简单 |
| 社区支持 | 相对较多 | 相对较多 | 相对较多 |
综合对比来看，Redisson在功能丰富性和性能方面都具有优势，适用于对分布式对象和服务有更高要求的项目。Lettuce在性能方面表现优秀，适合对并发能力和响应速度有较高要求的项目。Jedis虽然简单易用，但在性能和功能方面相对较弱。
三、选型说明
作为架构选型，我们必须清楚，选出一个完美的方案几乎不可能。更多的时候，架构只是排除掉那些不符合要求的方案，然后在剩下的方案中，选一个不那么差的，就成了所谓的“最佳实践”。因此在选型之前，我们必须明确自己当前的需求，按需来选。以我们自己的某个项目来说，引入Redis主要就是两方面的作用：
- 固定-复杂数据的分布式缓存
有一些计算非常复杂，但用的又比较频繁，如果用到了就去算一遍非常耗时，因此把结果缓存至Redis，供各业务获取 - 分布式锁
有些业务运行时，其他相关业务需要锁定为不可操作，需要使用分布式锁
针对项目要对接Redis的场景，我们可以根据以下因素进行选择：
接下来，就是分析支持情况，选择Redis做缓存是一个比较基础的功能，各个客户端都能比较简单的实现这个功能。而对于分布式锁其实场景比较复杂，使用 Jedis 或 Lettuce也都能实现，但需要我们自己写不少代码来完善场景。 而 Redisson 本身就实现了比较完备的分布式锁功能，比如支持RedLock算法，读写锁，上锁后自动续期的 watchDog 功能。所以开发者可以直接使用现成的功能。
所以在我们项目这种场景下，选择 Redisson 几乎成了必然，事实上用Redis做分布式锁，Redisson确实是最强大而省事的，这也正是 Redisson 比官方客户端人气还高的重要因素。当然如果你的项目对接redis，纯为了当缓存用，既没有高并发也没有复杂场景，使用
Lettuce 也是可以的。至于Jedis则太简单了，不支持NIO，性能上也稍弱，一旦后续有些复杂的业务，还需要我们手动去改，新项目的话就不推荐再用了。
)
