共计 6765 个字符，预计需要花费 17 分钟才能阅读完成。
作者：京东科技 王晨
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 作为热门的异步客户端，对于集群中产生的一些突发状况是具备解决能力的，只不过在应用的时候须要进行设置。本文目标在于将在开发缓存操作性能时遇到的问题，以及将一些波及到的底层常识做一下总结，也心愿能给大家一些帮忙。
