初探 Redis 客户端 Lettuce：真香

一、Lettuce 是啥？

一次技术讨论会上，大家说起 Redis 的 Java 客户端哪家强，我第一时间毫不犹豫地喊出 "Jedis, YES！"

“Jedis 可是官方客户端，用起来直接省事，公司中间件都用它。除了 Jedis 外难道还有第二个能打的？”我直接扔出王炸。

刚学 Spring 的小张听了不服：“SpringDataRedis 都用 RedisTemplate！Jedis？不存在的。”

“坐下吧秀儿，SpringDataRedis 就是基于 Jedis 封装的。”旁边李哥呷了一口刚开的快乐水，嘴角微微上扬，露出一丝不屑。

“现在很多都是用 Lettuce 了，你们不会不知道吧？”老王推了推眼镜淡淡地说道，随即缓缓打开镜片后那双心灵的窗户，用关怀的眼神俯视着我们几只菜鸡。

Lettuce？生菜？满头雾水的我赶紧打开了 Redis 官网的客户端列表。发现 Java 语言有三个官方推荐的实现： Jedis 、 Lettuce 和 Redission 。

初探 Redis 客户端 Lettuce：真香( 截图来源： https://redis.io/clients#java )

Lettuce 是什么客户端？没听过。但发现它的官方介绍最长：

Advanced Redis client for thread-safe sync, async, and reactive usage. Supports Cluster, Sentinel, Pipelining, and codecs.

赶紧查着字典翻译了下：

高级客户端线程安全支持同步、异步和反应式 API 支持集群、哨兵、管道和编解码老王摆摆手示意我收好字典，不紧不慢介绍起来。

1.1 高级客户端

“师爷，你给翻译翻译，什么（哔——）叫做（哔——）高级客户端？”

“高级客户端嘛，高级嘛，就是 Advanced 啊！new 一下就能用，什么实现细节都不用管，拿起业务逻辑直接突突。”

1.2 线程安全

这是和 Jedis 主要不同之一。

Jedis 的连接实例是线程不安全的，于是需要维护一个连接池，每个线程需要时从连接池取出连接实例，完成操作后或者遇到异常归还实例。当连接数随着业务不断上升时，对物理连接的消耗也会成为性能和稳定性的潜在风险点。

Lettuce 使用 Netty 作为通信层组件，其连接实例是线程安全的，并且在条件具备时可访问操作系统原生调用 epoll, kqueue 等获得性能提升。

我们知道 Redis 服务端实例虽然可以同时连接多个客户端收发命令，但每个实例执行命令时都是单线程的。

这意味着如果应用可以通过多线程+单连接方式操作 Redis，将能够精简 Redis 服务端的总连接数，而多应用共享同一个 Redis 服务端时也能够获得更好的稳定性和性能。对于应用来说也减少了维护多个连接实例的资源消耗。

1.3 支持同步、异步和反应式 API

Lettuce 从一开始就按照非阻塞式 IO 进行设计，是一个纯异步客户端，对异步和反应式 API 的支持都很全面。

即使是同步命令，底层的通信过程仍然是异步模型，只是通过阻塞调用线程来模拟出同步效果而已。

1.4 支持集群、哨兵、管道和编解码

“这些特性都是标配，Lettuce 可是高级客户端！高级，懂吗？”老王说到这里兴奋地用手指点着桌面，但似乎不想多做介绍，我默默地记下打算好好学习一番。

（在项目使用过程中，pipeling 机制用起来和 Jedis 相比稍微抽象已点，下文会给出在使用过程中遇到的小坑和解决办法。）

1.5 在 Spring 中的使用情况

除了 Redis 官方介绍，我们也可以发现 Spring Data Redis 在升级到 2.0 时，将 Lettuce 升级到了 5.0。其实 Lettuce 早就在 SpringDataRedis 1.6 时就被官方集成了；而 SpringSessionDataRedis 则直接将 Lettuce 作为默认 Redis 客户端，足见其成熟和稳定。

Jedis 广为人知甚至是事实上的标准 Java 客户端（de-facto standard driver），和它推出时间早（1.0.0 版本 2010 年 9 月，Lettuce 1.0.0 是 2011 年 3 月）、API 直接易用、对 Redis 新特性支持最快等特点都密不可分。

但 Lettuce 作为后进，其优势和易用性也获得了 Spring 等社区的青睐。下面会分享我们在项目中集成 Lettuce 时的经验总结，供大家参考。

二、Jedis 和 Lettuce 有啥主要区别？

说了这么多，Lettuce 和老牌客户端 Jedis 主要都有哪些区别呢？我们可以看下 Spring Data Redis 帮助文档给出的对比表格：

初探 Redis 客户端 Lettuce：真香（截图来源： https://docs.spring.io ）

注：其中 X 标记的是支持.经过比较我们可以发现：

Jedis 支持的 Lettuce 都支持；Jedis 不支持的 Lettuce 也支持！这么看来 Spring 中越来越多地使用 Lettuce 也就不奇怪了。

三、Lettuce 初体验

光说不练假把式，给大家分享我们尝试 Lettuce 时的收获，尤其是批量命令部分花了比较多的时间踩坑，下文详解。

3.1 快速开始

如果最简单的例子都令人费解，那这个库肯定流行不起来。Lettuce 的快速开始真的够快：

a. 引入 maven 依赖（其他依赖类似，具体可见文末参考资料）

<dependency>

<groupId>io.lettuce</groupId>
<artifactId>lettuce-core</artifactId>
<version>5.3.6.RELEASE</version>

</dependency>b. 填上 Redis 地址，连接、执行、关闭。Perfect！

import io.lettuce.core.*;

// Syntax: redis://[password@]host[:port][/databaseNumber]

// Syntax: redis://[username:password@]host[:port][/databaseNumber]

RedisClient redisClient = RedisClient.create("redis://password@localhost:6379/0");

StatefulRedisConnection<String, String> connection = redisClient.connect();

RedisCommands<String, String> syncCommands = connection.sync();

syncCommands.set("key", "Hello, Redis!");

connection.close();

redisClient.shutdown();3.2 支持集群模式吗？支持！

Redis Cluster 是官方提供的 Redis Sharding 方案，大家应该非常熟悉不再多介绍，官方文档可参考 Redis Cluster 101 。

Lettuce 连接 Redis 集群对上述客户端代码一行换一下即可：

// Syntax: redis://[password@]host[:port]

// Syntax: redis://[username:password@]host[:port]

RedisClusterClient redisClient = RedisClusterClient.create("redis://password@localhost:7379");3.3 支持高可靠吗？支持！

Redis Sentinel 是官方提供的高可靠方案，通过 Sentinel 可以在实例故障时自动切换到从节点继续提供服务，官方文档可参考 Redis Sentinel Documentation 。

仍然是替换客户端的创建方式就可以了：

// Syntax: redis-sentinel://[password@]host[:port][,host2[:port2]][/databaseNumber]#sentinelMasterId

RedisClient redisClient = RedisClient.create("redis-sentinel://localhost:26379,localhost:26380/0#mymaster");3.4 支持集群下的 pipeline 吗？支持！

Jedis 虽然有 pipeline 命令，但不能支持 Redis Cluster。一般都需要自行归并各个 key 所在的 slot 和实例后再批量执行 pipeline。

官网对集群下的 pipeline 支持 PR 截至本文写作时（2021 年 2 月）四年过去了仍然未合入，可见 Cluster pipelining 。

Lettuce 虽然号称支持 pipeling，但并没有直接看到 pipeline 这种 API，这是怎么回事？

3.4.1 实现 pipeline 使用 AsyncCommands 和 flushCommands 实现 pipeline，经过阅读官方文档可以知道，Lettuce 的同步、异步命令其实都共享同一个连接实例，底层使用 pipeline 的形式在发送/接收命令。

区别在于：

connection.sync() 方法获取的同步命令对象，每一个操作都会立刻将命令通过 TCP 连接发送出去；connection.async() 获取的异步命令对象，执行操作后得到的是 RedisFuture<?>，在满足一定条件的情况下才批量发送。由此我们可以通过异步命令+手动批量推送的方式来实现 pipeline，来看 官方示例 ：

StatefulRedisConnection<String, String> connection = client.connect();

RedisAsyncCommands<String, String> commands = connection.async();

// disable auto-flushing

commands.setAutoFlushCommands(false);

// perform a series of independent calls

List<RedisFuture<?>> futures = Lists.newArrayList();

for (int i = 0; i < iterations; i++) {

futures.add(commands.set("key-" + i, "value-" + i));

futures.add(commands.expire("key-" + i, 3600));

}

// write all commands to the transport layer

commands.flushCommands();

// synchronization example: Wait until all futures complete

boolean result = LettuceFutures.awaitAll(5, TimeUnit.SECONDS,

futures.toArray(new RedisFuture[futures.size()]));

// later

connection.close();3.4.2 这么做有没有问题？乍一看很完美，但其实有暗坑：

setAutoFlushCommands(false) 设置后，会发现 sync() 方法调用的同步命令都不返回了！ 这是为什么呢？我们再看看官方文档：

Lettuce is a non-blocking and asynchronous client. It provides a synchronous API to achieve a blocking behavior on a per-Thread basis to create await (synchronize) a command response..... As soon as the first request returns, the first Thread’s program flow continues, while the second request is processed by Redis and comes back at a certain point in time

sync 和 async 在底层实现上都是一样的，只是 sync 通过阻塞调用线程的方式模拟了同步操作。并且 setAutoFlushCommands 通过源码可以发现就是作用在 connection 对象上，于是该操作对 sync 和 async 命令对象都生效。

所以，只要某个线程中设置了 auto flush commands 为 false，就会影响到所有使用该连接实例的其他线程。

/**

• An asynchronous and thread-safe API for a Redis connection.

• @param <K> Key type.

• @param <V> Value type.

• @author Will Glozer

• @author Mark Paluch

*/

public abstract class AbstractRedisAsyncCommands<K, V> implements RedisHashAsyncCommands<K, V>, RedisKeyAsyncCommands<K, V>,

RedisStringAsyncCommands<K, V>, RedisListAsyncCommands<K, V>, RedisSetAsyncCommands<K, V>,

RedisSortedSetAsyncCommands<K, V>, RedisScriptingAsyncCommands<K, V>, RedisServerAsyncCommands<K, V>,

RedisHLLAsyncCommands<K, V>, BaseRedisAsyncCommands<K, V>, RedisTransactionalAsyncCommands<K, V>,

RedisGeoAsyncCommands<K, V>, RedisClusterAsyncCommands<K, V> {

@Override
public void setAutoFlushCommands(boolean autoFlush) {
    connection.setAutoFlushCommands(autoFlush);
}

}对应的，如果多个线程调用 async() 获取异步命令集，并在自身业务逻辑完成后调用 flushCommands() ，那将会强行 flush 其他线程还在追加的异步命令，原本逻辑上属于整批的命令将被打散成多份发送。

虽然对于结果的正确性不影响，但如果因为线程相互影响打散彼此的命令进行发送，则对性能的提升就会很不稳定。

自然我们会想到：每个批命令创建一个 connection，然后……这不和 Jedis 一样也是靠连接池么？

回想起老王镜片后那穿透灵魂的目光，我打算硬着头皮再挖掘一下。果然，再次认真阅读文档后我发现了另外一个好东西： Batch Execution 。

3.4.3 Batch Execution 既然 flushCommands 会对 connection 产生全局影响，那把 flush 限制在线程级别不就行了？我从文档中找到了示例官方示例。

回想起前文 Lettuce 是高级客户端，看了文档后发现确实高级，只需要定义接口就行了（让人想起 MyBatis 的 Mapper 接口），下面是项目中使用的例子：

/**

• 定义会用到的批量命令

*/

@BatchSize(100)

public interface RedisBatchQuery extends Commands, BatchExecutor {

RedisFuture<byte[]> get(byte[] key);
RedisFuture<Set<byte[]>> smembers(byte[] key);
RedisFuture<List<byte[]>> lrange(byte[] key, long start, long end);
RedisFuture<Map<byte[], byte[]>> hgetall(byte[] key);

}调用时这样操作：

// 创建客户端

RedisClusterClient client = RedisClusterClient.create(DefaultClientResources.create(), "redis://" + address);

// service 中持有 factory 实例，只创建一次。第二个参数表示 key 和 value 使用 byte[] 编解码

RedisCommandFactory factory = new RedisCommandFactory(connect, Arrays.asList(ByteArrayCodec.INSTANCE, ByteArrayCodec.INSTANCE));

// 使用的地方，创建一个查询实例代理类调用命令，最后刷入命令

List<RedisFuture<?>> futures = new ArrayList<>();

RedisBatchQuery batchQuery = factory.getCommands(RedisBatchQuery.class);

for (RedisMetaGroup redisMetaGroup : redisMetaGroups) {

// 业务逻辑，循环调用多个 key 并将结果保存到 futures 结果中
appendCommand(redisMetaGroup, futures, batchQuery);

}

// 异步命令调用完成后执行 flush 批量执行，此时命令才会发送给 Redis 服务端

batchQuery.flush();就是这么简单。

此时批量的控制将在线程粒度上进行，并在调用 flush 或达到 @BatchSize 配置的缓存命令数量时执行批量操作。 而对于 connection 实例，不用再设置 auto flush commands，保持默认的 true 即可，对其他线程不造成影响。

ps：优秀、严谨的你肯定会想到：如果单命令执行耗时长或者谁放了个诸如 BLPOP 的命令的话，肯定会造成影响的，这个话题官方文档也有涉及，可以考虑使用连接池来处理。

3.5 还能再给力一点吗？

Lettuce 支持的当然不仅仅是上面所说的简单功能，还有这些也值得一试：

3.5.1 读写分离我们知道 Redis 实例是支持主从部署的，从实例异步地从主实例同步数据，并借助 Redis Sentinel 在主实例故障时进行主从切换。

当应用对数据一致性不敏感、又需要较大吞吐量时，可以考虑主从读写分离方式。Lettuce 可以设置 StatefulRedisClusterConnection 的 readFrom 配置来进行调整：

初探 Redis 客户端 Lettuce：真香 3.5.2 配置自动更新集群拓扑当使用 Redis Cluster 时，服务端发生了扩容怎么办？Lettuce 早就考虑好了——通过 RedisClusterClient#setOptions 方法传入 ClusterClientOptions 对象即可配置相关参数（全部配置见文末参考链接）。

ClusterClientOptions 中的

topologyRefreshOptions 常见配置如下：

初探 Redis 客户端 Lettuce：真香 3.5.3 连接池虽然 Lettuce 基于线程安全的单连接实例已经具有非常好的性能，但也不排除有些大型业务需要通过线程池来提升吞吐量。另外对于事务性操作是有必要独占连接的。

Lettuce 基于 Apache Common-pool2 组件提供了连接池的能力（以下是官方提供的 RedisCluster 对应的客户端线程池使用示例）：

RedisClusterClient clusterClient = RedisClusterClient.create(RedisURI.create(host, port));

GenericObjectPool<StatefulRedisClusterConnection<String, String>> pool = ConnectionPoolSupport

           .createGenericObjectPool(() -> clusterClient.connect(), new GenericObjectPoolConfig());

// execute work

try (StatefulRedisClusterConnection<String, String> connection = pool.borrowObject()) {

connection.sync().set("key", "value");
connection.sync().blpop(10, "list");

}

// terminating

pool.close();

clusterClient.shutdown();这里需要说明的是： createGenericObjectPool 创建连接池默认设置 wrapConnections 参数为 true。 此时借出的对象 close 方法将通过动态代理的方式重载为归还连接；若设置为 false 则 close 方法会关闭连接。

Lettuce 也支持异步的连接池（从连接池获取连接为异步操作），详情可参考文末链接。还有很多特性不能一一列举，都可以在官方文档上找到说明和示例，十分值得一读。

四、使用总结

Lettuce 相较于 Jedis，使用上更加方便快捷，抽象度高。并且通过线程安全的连接降低了系统中的连接数量，提升了系统的稳定性。

对于高级玩家，Lettuce 也提供了很多配置、接口，方便对性能进行优化和实现深度业务定制的场景。

另外不得不说的一点，Lettuce 的官方文档写的非常全面细致，十分难得。社区比较活跃，Commiter 会积极回答各类 issue，这使得很多疑问都可以自助解决。

相比之下，Jedis 的文档、维护更新速度就比较慢了。JedisCluster pipeline 的 PR 至今（2021 年 2 月）四年过去还未合入。

参考资料

其中两个 GitHub 的 issue 含金量很高，强烈推荐一读！1.Lettuce 快速开始： https://lettuce.io

2. Redis Java Clients

3.Lettuce 官网： https://lettuce.io

4.SpringDataRedis 参考文档

5. Question about pipelining

6. Why is Lettuce the default Redis client used in Spring Session Redis

7.Cluster-specific options： https://lettuce.io

8. Lettuce 连接池

9.客户端配置：https://lettuce.io/core/release

10.SSL 配置： https://lettuce.io

原文https://mp.weixin.qq.com/s?__biz=MzI4NjY4MTU5Nw==&mid=2247491453&idx=1&sn=c74628fed0ae2ee5d79ec428c36f13f5