这个问题是基于个人观点的，但让我们了解一些客观的观点：
简短版：
选择驱动程序取决于多种因素：
- 额外依赖
- 编程模型
- 可扩展性
- 对高级特性实现的看法
- 您的项目前景以及您想要发展的方向
说明
额外依赖
一些项目对添加库时的附加依赖和暂时依赖有自己的看法。
Jedis 几乎没有依赖关系，它需要 Apache Commons Pool 2 来进行连接池化。
Redisson 需要 Netty、JCache API 和 Project Reactor 作为基本依赖。它是可扩展的，因为它与许多其他库（如 Tomcat Session 存储）集成。
编程模型
这是您与 Redis 客户端交互的方式。它还定义了抽象级别。
Jedis 是一个低级驱动程序，将 Redis API 公开为 Java 方法调用：
Jedis jedis = …;
jedis.set("key", "value");
List<String> values = jedis.mget("key", "key2", "key3");
Redisson是一个高级客户端，通过各种API对象来公开其功能：
Redisson redisson = …
RMap map = redisson.getMap("my-map"); // implement java.util.Map
map.put("key", "value");
map.containsKey("key");
map.get("key");
每个调用都会触发一个或多个 Redis 调用，其中一些使用 Lua 实现（Redis“脚本”）。
可扩展性
Java 有多个可用的驱动程序，具有各种属性可能适合您的项目。 可扩展性也会涉及其中。 看驱动程序，它归结于驱动程序如何使用其资源以及它们支持哪些编程模型。
Jedis 使用阻塞 I/O，方法调用是同步的。 程序流程需要等待，直到 socket 处理完 I/O。 没有异步（Future、CompletableFuture）或反应式支持（RxJava Observable 或 Reactive Streams Publisher）。
Jedis 客户端实例不是线程安全的，因此需要连接池（每个调用线程一个 Jedis 实例）。
Redisson 使用非阻塞 I/O 和基于 Netty 的事件驱动通信层。 方法调用是同步的、异步的或反应式的（通过 Project Reactor 2.0 或 3.1）。 连接已汇集，但 API 本身是线程安全的，并且需要较少的资源。 我不是很确定，但您甚至可以在单个连接上操作。 这是与 Redis 一起工作的最有效方式。
客户端实现的观点
这些段落涉及客户端是如何实现的。
两个客户端都具有出色的功能覆盖，您可以使用两个库来满足您的要求。
Jedis 是一个简单的实现，只是将命令写入 OutputStream 并解析响应。 没有更多了。
如果您需要高级功能，则需要使用 Redis API 来实现这些功能。 它使您完全控制您调用的命令和结果行为。 在此处实现自己的功能可能需要额外的努力。
Redisson 是一个高级客户端，通过其抽象提供功能。 虽然可以使用这些对象而不需要知道它们由 Redis 支持（Map、List、Set等），但每个 API 调用都会转换为一个或多个 Redis 调用，其中一些是 Lua 脚本执行。
您可能喜欢或不喜欢 Redisson 的行为方式以及如何实现功能，但最终，您无法做太多关于它。 使用 Redisson 的高级功能可能会减少您的实现工作。
前景
该部分完全取决于您的目标。 Jedis 支持所有 Redis API 命令、Redis 独立版、Redis Sentinel 和 Redis Cluster。 在主-从设置中没有从属读取，但我认为这只是时间问题，直到 jedis 提供这些功能。
使用 jedis，您无法进行异步操作，并且使用 AWS ElastiCache 的高级功能或从属读取需要您自己实现。
Redisson 具有各种设置的广泛覆盖范围。 它支持 Jedis 支持的所有内容，并为主/从设置提供读取策略，在 AWS ElastiCache 方面提供了改进的支持。
5
原文链接