作者：京东科技 王晨

Redis异步客户端选型及落地实际

可视化服务编排零碎是可能通过线上可视化拖拽、配置的形式实现对接口的编排，可在线实现服务的调试、测试，实现业务需要的交付，具体内容可参考：https://mp.weixin.qq.com/s/5oN9JqWN7n-4Zv6B9K8kWQ。

为了反对更加宽泛的业务场景，可视化编排零碎近期须要反对对缓存的操作性能，为保障编排零碎的性能，服务的执行过程采纳了异步的形式，因而咱们思考应用Redis的异步客户端来实现对缓存的操作。

Redis客户端

Jedis/Lettuce

Redis官网举荐的Redis客户端有Jedis、Lettuce等等，其中Jedis 是老牌的 Redis 的 Java 实现客户端，提供了比拟全面的 Redis 命令的反对，在spring-boot 1.x 默认应用Jedis。

然而Jedis应用阻塞的 IO，且其办法调用都是同步的，程序流须要等到 sockets 解决完 IO 能力执行，不反对异步，在并发场景下，应用Jedis客户端会消耗较多的资源。

此外，Jedis 客户端实例不是线程平安的，要想保障线程平安，必须要应用连接池，每个线程须要时从连接池取出连贯实例，实现操作后或者遇到异样偿还实例。当连接数随着业务一直上升时，对物理连贯的耗费也会成为性能和稳定性的潜在危险点。因而在spring-boot 2.x中，redis客户端默认改用了Lettuce。

咱们能够看下 Spring Data Redis 帮忙文档给出的比照表格，外面具体地记录了两个支流Redis客户端之间的差别。

异步客户端Lettuce

Spring Boot自2.0版本开始默认应用Lettuce作为Redis的客户端。Lettuce客户端基于Netty的NIO框架实现，对于大多数的Redis操作，只须要维持繁多的连贯即可高效反对业务端的并发申请 —— 这点与Jedis的连接池模式有很大不同。同时，Lettuce反对的个性更加全面，且其性能体现并不逊于，甚至优于Jedis。

Netty是由JBOSS提供的一个java开源框架，现为 Github上的独立我的项目。Netty提供异步的、事件驱动的网络应用程序框架和工具，用以疾速开发高性能、高可靠性的网络服务器和客户端程序。

也就是说，Netty 是一个基于NIO的客户、服务器端的编程框架，应用Netty 能够确保你疾速和简略的开发出一个网络应用，例如实现了某种协定的客户、服务端利用。Netty相当于简化和流线化了网络应用的编程开发过程，例如：基于TCP和UDP的socket服务开发。

上图展现了Netty NIO的外围逻辑。NIO通常被了解为non-blocking I/O的缩写，示意非阻塞I/O操作。图中Channel示意一个连贯通道，用于承载连贯治理及读写操作；EventLoop则是事件处理的外围形象。一个EventLoop能够服务于多个Channel，但它只会与繁多线程绑定。EventLoop中所有I/O事件和用户工作的解决都在该线程上进行；其中除了选择器Selector的事件监听动作外，对连贯通道的读写操作均以非阻塞的形式进行 —— 这是NIO与BIO（blocking I/O，即阻塞式I/O）的重要区别，也是NIO模式性能优异的起因。

Lettuce凭借繁多连贯就能够反对业务端的大部分并发需要，这依赖于以下几个因素的独特作用：

1.Netty的单个EventLoop仅与繁多线程绑定，业务端的并发申请均会被放入EventLoop的工作队列中，最终被该线程程序解决。同时，Lettuce本身也会保护一个队列，当其通过EventLoop向Redis发送指令时，胜利发送的指令会被放入该队列；当收到服务端的响应时，Lettuce又会以FIFO的形式从队列的头部取出对应的指令，进行后续解决。

2.Redis服务端自身也是基于NIO模型，应用繁多线程解决客户端申请。尽管Redis能同时维持成千盈百个客户端连贯，然而在某一时刻，某个客户端连贯的申请均是被程序解决及响应的。

3.Redis客户端与服务端通过TCP协定连贯，而TCP协定自身会保障数据传输的程序性。

如此，Lettuce在保障申请解决程序的根底上，人造地应用了管道模式（pipelining）与Redis交互 —— 在多个业务线程并发申请的状况下，客户端不用期待服务端对以后申请的响应，即可在同一个连贯上收回下一个申请。这在减速了Redis申请解决的同时，也高效地利用了TCP连贯的全双工个性（full-duplex）。而与之绝对的，在没有显式指定应用管道模式的状况下，Jedis只能在解决完某个Redis连贯上以后申请的响应后，能力持续应用该连贯发动下一个申请。

在并发场景下，业务零碎短时间内可能会收回大量申请，在管道模式中，这些申请被对立发送至Redis服务端，待处理实现后对立返回，可能大大晋升业务零碎的运行效率，突破性能瓶颈。R2M采纳了Redis Cluster模式，在通过Lettuce连贯R2M之前，应该先对Redis Cluster模式有肯定的理解。

Redis Cluster模式

在redis3.0之前，如果想搭建一个集群架构还是挺简单的，就算是基于一些第三方的中间件搭建的集群总感觉有那么点差强人意，或者基于sentinel哨兵搭建的主从架构在高可用上体现又不是很好，尤其是当数据量越来越大，单纯主从构造无奈满足对性能的需要时，矛盾便产生了。

随着redis cluster的推出，这种海量数据+高并发+高可用的场景真正从根本上失去了无效的反对。

cluster 模式是redis官网提供的集群模式，应用了Sharding 技术，不仅实现了高可用、读写拆散、也实现了真正的分布式存储。

集群外部通信

在redis cluster集群外部通过gossip协定进行通信，集群元数据扩散的存在于各个节点，通过gossip进行元数据的替换。

不同于zookeeper分布式协调中间件，采纳集中式的集群元数据存储。redis cluster采纳分布式的元数据管理，优缺点还是比拟显著的。在redis中集中式的元数据管理相似sentinel主从架构模式。集中式有点在于元数据更新实效性更高，但容错性不如分布式治理。gossip协定长处在于大大加强集群容错性。

redis cluster集群中单节点个别配置两个端口，一个端口如6379对外提供api，另一个个别是加1w，比方16379进行节点间的元数据交换即用于gossip协定通信。

gossip协定蕴含多种音讯，如ping pong，meet，fail等。

1.meet：集群中节点通过向新退出节点发送meet音讯，将新节点退出集群中。

2.ping：节点间通过ping命令替换元数据。

3.pong：响应ping。

4.fail：某个节点主观认为某个节点宕机，会向其余节点发送fail音讯，进行主观宕机断定。

分片和寻址算法

hash slot即hash槽。redis cluster采纳的正式这种hash槽算法实现的寻址。在redis cluster中固定的存在16384个hash slot。

如上图所示，如果咱们有三个节点，每个节点都是一主一从的主从构造。redis cluster初始化时会主动均分给每个节点16384个slot。当减少一个节点4，只须要将原来node1~node3节点局部slot上的数据迁徙到节点4即可。在redis cluster中数据迁徙并不会阻塞主过程。对性能影响是非常无限的。总结一句话就是hash slot算法无效的缩小了当节点发生变化导致的数据漂移带来的性能开销。

集群高可用和主备切换

主观宕机和主观宕机：

某个节点会周期性的向其余节点发送ping音讯，当在肯定工夫内未收到pong音讯会主观认为该节点宕机，即主观宕机。而后该节点向其余节点发送fail音讯，其余超过半数节点也确认该节点宕机，即主观宕机。非常相似sentinel的sdown和odown。

主观宕机确认后进入主备切换阶段及从节点选举。

节点选举：

查看每个 slave node 与 master node 断开连接的工夫，如果超过了 cluster-node-timeout * cluster-slave-validity-factor，那么就没有资格切换成 master。

每个从节点，都依据本人对 master 复制数据的 offset，来设置一个选举工夫，offset 越大（复制数据越多）的从节点，选举工夫越靠前，优先进行选举。

所有的 master node 开始 slave 选举投票，给要进行选举的 slave 进行投票，如果大部分 master node（N/2 + 1）都投票给了某个从节点，那么选举通过，那个从节点能够切换成 master。

从节点执行主备切换，从节点切换为主节点。

Lettuce的应用

建设连贯

应用Lettuce大抵分为以下三步：

1.基于Redis连贯信息创立RedisClient

2.基于RedisClient创立StatefulRedisConnection

3.从Connection中获取Command，基于Command执行Redis命令操作。

因为Lettuce客户端提供了响应式、同步和异步三种命令，从Connection中获取Command时能够指定命令类型进行获取。

在本地创立Redis Cluster集群，设置主从关系如下：

7003(M) --> 7001(S)

7004(M) --> 7002(S)

7005(M) --> 7000(S)

List<RedisURI> servers = new ArrayList<>();servers.add(RedisURI.create("127.0.0.1", 7000));servers.add(RedisURI.create("127.0.0.1", 7001));servers.add(RedisURI.create("127.0.0.1", 7002));servers.add(RedisURI.create("127.0.0.1", 7003));servers.add(RedisURI.create("127.0.0.1", 7004));servers.add(RedisURI.create("127.0.0.1", 7005));//创立客户端RedisClusterClient client = RedisClusterClient.create(servers);//创立连贯StatefulRedisClusterConnection<String, String> connection = client.connect();//获取异步命令RedisAdvancedClusterAsyncCommands<String, String> commands = connection.async();//执行GET命令RedisFuture<String> future = commands.get("test-lettuce-key");try {    String result = future.get();    log.info("Get命令返回:{}", result);} catch (Exception e) {    log.error("Get命令执行异样", e);}

能够看到胜利地获取到了值，由日志能够看出该申请发送到了7004所在的节点上，顺利拿到了对应的值并进行返回。

作为一个须要长时间放弃的客户端，放弃其与集群之间连贯的稳定性是至关重要的，那么集群在运行过程中会产生哪些非凡状况呢？作为客户端又应该如何应答呢？这就要引出智能客户端（smart client）这个概念了。

智能客户端

在Redis Cluster运行过程中，所有的数据不是永远固定地保留在某一个节点上的，比方遇到cluster扩容、节点宕机、数据迁徙等状况时，都会导致集群的拓扑构造发生变化，此时作为客户端须要对这一类状况作出应答，来保障连贯的稳定性以及服务的可用性。随着以上问题的呈现，smart client这个概念逐步走到了人们的视线中，智能客户端会在外部保护hash槽与节点的映射关系，大家耳熟能详的Jedis和Lettuce都属于smart client。客户端在发送申请时,会先依据CRC16(key)%16384计算key对应的hash槽,通过映射关系,本地就可实现键到节点的查找,从而保障IO效率的最大化。

但如果呈现故障转移或者hash槽迁徙时,这个映射关系是如何保护的呢？

客户端重定向

MOVED

当Redis集群产生数据迁徙时，当对应的hash槽曾经迁徙到变的节点时，服务端会返回一个MOVED重定向谬误，此时并通知客户端这个hash槽迁徙后的节点IP和端口是多少；客户端在接管到MOVED谬误时，会更新本地的映射关系，并从新向新节点发送申请命令。

ASK

Redis集群反对在线迁徙槽（slot）和数据来实现程度伸缩，当slot对应的数据从源节点到指标节点迁徙过程中，客户端须要做到智能辨认，保障键命令可失常执行。例如当一个slot数据从源节点迁徙到指标节点时，期间可能呈现一部分数据在源节点，而另一部分在指标节点，如下图所示

当呈现上述情况时，客户端键命令执行流程将发生变化，如下所示：

1）客户端依据本地slots缓存发送命令到源节点，如果存在键对象则直 接执行并返回后果给客户端

2）如果键对象不存在，则可能存在于指标节点，这时源节点会回复 ASK重定向异样。

3）客户端从ASK重定向异样提取出指标节点信息，发送asking命令到指标节点关上客户端连贯标识，再执行键命令。如果存在则执行，不存在则返回不存在信息。

在客户端收到ASK谬误时，不会更新本地的映射关系

节点宕机触发主备切换

上文提到，如果redis集群在运行过程中，某个主节点因为某种原因宕机了，此时就会触发集群的节点选举机制，选举其中一个从节点作为新的主节点，进入主备切换，在主备切换期间，新的节点没有被选举进去之前，打到该节点上的申请实践上是无奈失去执行的，可能会产生超时谬误。在主备切换实现之后，集群拓扑更新实现，此时客户端应该向集群申请新的拓扑构造，并更新至本地的映射表中，以保障后续命令的正确执行。

有意思的是，Jedis在集群主备切换实现之后，是会被动拉取最新的拓扑构造并进行更新的，然而在应用Lettuce时，发现在集群主备切换实现之后，连贯并没有复原，打到该节点上的命令依旧会执行失败导致超时，必须要重启业务程序能力复原连贯。

在应用Lettuce时，如果不进行设置，默认是不会触发拓扑刷新的，因而在主备切换实现后，Lettuce仍旧应用本地的映射表，将申请打到曾经挂掉的节点上，就会导致继续的命令执行失败的状况。

能够通过以下代码来设置Lettuce的拓扑刷新策略，开启基于事件的自适应拓扑刷新，其中包含了MOVED、 ASK、PERSISTENT_RECONNECTS等触发器，当客户端触发这些事件，并且持续时间超过设定阈值后，触发拓扑刷新，也能够通过enablePeriodicRefresh（）设置定时刷新，不过倡议这个工夫不要太短。

// 设置基于事件的自适应刷新策略ClusterTopologyRefreshOptions topologyRefreshOptions = ClusterTopologyRefreshOptions.builder()        //开启自适应拓扑刷新        .enableAllAdaptiveRefreshTriggers()        //自适应拓扑刷新事件超时工夫，超时后进行刷新        .adaptiveRefreshTriggersTimeout(Duration.ofSeconds(30))        .build();redisClusterClient.setOptions(ClusterClientOptions.builder()        .topologyRefreshOptions(topologyRefreshOptions)        // redis命令超时工夫        .timeoutOptions(TimeoutOptions.enabled(Duration.ofSeconds(30)))        .build());

进行以上设置并进行验证，集群在主备切换实现后，客户端在段时间内复原了连贯，可能失常存取数据了。

总结

对于缓存的操作，客户端与集群之间连贯的稳定性是保证数据不失落的要害，Lettuce作为热门的异步客户端，对于集群中产生的一些突发状况是具备解决能力的，只不过在应用的时候须要进行设置。本文目标在于将在开发缓存操作性能时遇到的问题，以及将一些波及到的底层常识做一下总结，也心愿能给大家一些帮忙。