redis集群客户端JedisCluster优化 - 管道(pipeline)模式支持

文章探讨了Redis集群不支持管道模式的原因,主要在于节点变动可能导致命令发送错误。作者分析了JedisCluster的工作原理,并提出一种简单思路:在遇到'MOVED'或'ASK'错误时重试。鉴于业务特点(定期全量导入,可重试,集群稳定,不影响在线业务),作者提供了自己实现的JedisCluster pipeline源码,供有类似需求的读者参考。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

Redis在3.0版正式引入了集群这个特性,扩展变得非常简单。然而当你开心的升级到3.0后,却发现有些很好用的功能现在工作不了了, 比如我们今天要聊的pipeline功能。

我们知道,普通的情况下,redis client与server之间采用的是请求应答的模式,即:

Client: command1
Server: response1
Client: command2
Server: response2

在这种情况下,如果要完成10个命令,则需要20次交互才能完成。因此,即使redis处理能力很强,仍然会受到网络传输影响,导致吞吐上不去。而在管道模式下,多个请求变成这样:

Client: command1,command2…
Server: response1,response2…

在这种情况下,完成命令只需要2次交互。这样网络传输上能够更加高效,加上redis本身强劲的处理能力,是不是有一种飞一样的感觉。听到这里有没有去优化应用的冲动? 然而到了cluster模式下,这样的功能并不支持。 下面我们先来分析下,是什么原因导致redis cluter没办法支持管道模式。首先需要了解集群下的几个特性:

  • 1、集群将空间分拆为16384个槽位(slot),每一个节点负责其中一些槽位。迁移时对整个slot迁移
  • 2、节点添加,或宕机或不可达的情况下可以正常使用
  • 3、不存在中心或者代理节点, 每个节点中都包含集群所有的节点信息
  • 4、集群中的节点不会代理请求:即如果client将命令发送到错误的节点上,操作会失败,但会返回”-MOVED”或”-ASK”,供client进行永久或临时的节点切换

以上信息中第3、4点信息比较重要。

我们先来看第3点,由于每个节点都包含所有的节点信息,因此client连接任一节点都可以获取整个集群的信息,这样我们在配置JedisCluster时只需要配置其中一部分节点的信息就可以(配置多个是为了高可用)。对应的获取集群命令为:cluster nodes

127.0.0.1:9380> cluster nodes
b6d0cfe64dbae9590e6fc4c5a8e309debcbe0529 127.0.0.1:9380 myself,master - 0 0 2 connected 5461-10922
b9e5592558aae0f28c79c3750b264d5b2530f6a4 127.0.0.1:9381 master - 0 1466758609932 3 connected 10923-16383
b40095eb2023653eaea5b7b4e242a77a7817889a 127.0.0.1:9379 master - 0 1466758608932 1 connected 0-5460

每一行代表一个节点的信息,这里共三个节点(测试用,没有建slave节点),依次的信息为:

{id} {ip:port} {flags如master/slave} {master id} {ping-sent} {pong-recv} {config-epoch} {link-state} {slot} {slot} … {slot}
参考: http://redis.io/commands/cluster-nodes

可以看到每个节点对应的slot信息都在这里,{slot}格式一般是{begin}-{end}(如0-5460),表示从{begin}到{end}的所有slot都在当前节点中。因此我们可以通过slot找到对应机器的ip:port。 注意,新版client中使用cluster slots获取对应数据 , 参考: http://redis.io/commands/cluster-slots

再来看第4点,由第3点可以知道client可以通过获取所有节点信息,根据key计算得到对应的slot后可以找到对应的节点。所以说在节点稳定(没有增减)的情况下,客户端可以一直用缓存的集群信息来发起各种命令。然而,如果节点发生变更客户端是否能够立即感知? 目前的client JedisCluster是无法感知的,他是通过执行命令后, 服务端返回的“-MOVED”信息感知节点的变化,并以此来刷新缓存信息。

了解以上信息以后,JedisCluster为什么不支持pipeline就比较清晰了。 因为pipeline模式下命令将被缓存到对应的连接(OutputStream)上,而在真正向服务端发送数据时,节点可能发生了改变,数据就可能发向了错误的节点,这导致批量操作失败,而要处理这种失败是非常复杂的。至少目前JedisCluster并未提供这样的机制。(对于单key来说,在发生这种情况的时候,进行简单的节点数据刷新+重新发送当前命令来重试)。

看到这里,你可能会感到沮丧(我猿类如此不易,且行且珍惜)。这里提供一个简单的思路,你可以根据单key的逻辑,如果某些key遇到”-MOVE”或”-ASK”则重试。 根据这个思路,你需要按顺序记录所有的命令,每次执行完成后找出异常的数据,刷新节点信息后重试,最终将重试(可能有多次)获取到的结果根据顺序信息插入返回列表。对于重试多次依然失败的数据,交由业务处理。思路很简单,然而redis命令太多了,要对PipelineBase的每个方法都这样改造,我不想(因为我懒呀),而且估计坑也很多,所以这个只能靠你自己去搞了。

下面我说下针对我们的业务做的一个JedisCluster pipeline实现。对应的业务有以下特点:
- 数据为每隔一段时间全量导入redis集群,数据量约xx万(xx较大)
- 导入任务为后台执行,可重试,最终如果有部分失败可接受
- 集群相对较稳定,不会频繁的加减机器
- 在线业务不使用该api

下面是该类的源码(jdk1.7),如在以上这几个条件下有问题,可以一起交流:
(github地址: https://github.com/youaremoon/jedis-ext)


package com.yam.common.redis;

import java.io.Closeable;
import java.io.IOException;
import java.lang.reflect.Field;
import java.util.ArrayList;
import java.util.HashMap;
import
评论 13
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值