这个问题是基于意见的，但让我们从中得到一些客观的观点：

TL;博士：

驱动程序的选择取决于多种因素：

• 其他依赖项
• 编程模型
• 可伸缩性
• 对高级功能的实现固执己见
• 项目的前景，您想要发展的方向

解释

其他依赖项

在添加库时，某些项目对其他依赖项和暂时性依赖项持固执己见。

Jedis几乎是无依赖的，它需要Apache Commons Pool 2进行连接池。

Redisson 需要 Netty、JCache API 和 Project Reactor 作为基本依赖项。它是可扩展的，因为它与许多其他库（Tomcat Session store）集成。

编程模型

这就是您与 Redis 客户端交互的方式。它还定义了抽象级别。

Jedis 是一个低级驱动程序，在 Java 方法调用时公开 Redis API：

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 有多个驱动程序可用于 Java，它们具有可能适合您的项目的各种属性。可扩展性也起到了作用。从驱动程序来看，它归结为驱动程序如何，如何使用他们的资源以及他们支持的编程模型。

Jedis 使用阻塞 I/O，方法调用是同步的。您的程序流需要等到套接字处理 I/O。没有异步（，）或反应式支持（RxJava或Reactive Streams）。FutureCompletableFutureObservablePublisher

Jedis 客户端实例不是线程安全的，因此它们需要连接池（每个调用线程的 Jedis 实例）。

Redisson 使用非阻塞 I/O 和事件驱动的通信层与 netty。方法调用是同步的、异步的或反应式的（通过 Project Reactor 2.0 或 3.1）。连接是池化的，但 API 本身是线程安全的，需要的资源更少。我不完全确定，但也许您甚至可以在单个连接上进行操作。这是使用 Redis 时最有效的方式。

关于客户端实现的意见

这些段落涉及如何实现客户端。

这两个客户端都具有出色的功能覆盖范围，您可以使用这两个库满足您的要求。

Jedis 是一个简单的实现，只需将命令写入 a 并解析响应。仅此而已。OutputStream

如果你想要高级功能，那么你需要使用 Redis API 实现这些功能。它使您可以完全控制调用的命令和结果行为。实现您的功能可能需要在此处进行额外的工作。

Redisson 是一个高级客户端，通过其抽象提供功能。虽然您可以使用这些对象而无需知道它们由 Redis （， ， ， ... ） 支持，但每个 API 调用都会转换为一个或多个 Redis 调用，有些会转换为 Lua 脚本执行。MapListSet

您可能喜欢或不喜欢 Redisson 的行为方式以及它实现这些功能的方式，但最终，您对此无能为力。使用 Redisson 的高级功能可能会减少您的实现工作。

展望

该部分完全取决于您要前往的位置。Jedis 支持所有 Redis API 命令，Redis Standalone、Redis Sentinel 和 Redis Cluster。在主从设置中没有从属读取，但我认为这只是一个时间问题，直到jedis提供这些功能。

使用 jedis，您无法进行异步，并且使用 AWS ElastiCache 或从属读取的高级功能需要您自己的实现。

Redisson广泛覆盖了各种设置。它支持 Jedis 支持的所有内容，并为主/从设置提供读取策略，改进了对 AWS ElastiCache 的支持。