深入学习 Redis(5):集群体育彩票

原标题:深入学习 Redis(5):集群

在 Redis 集群中,借助槽实现数据分区,具体原理后文会介绍。集群有 16384 个槽,槽是数据管理和迁移的基本单位。

cluster-require-full-coverage 参数可以改变这一设定:如果设置为 no,则当槽没有完全分配时,集群仍可以上线。

指定主从关系

③搭建集群

注意:ip 使用的是局域网 ip,而不是 localhost 或 127.0.0.1,是为了其他机器上的节点或客户端也可以访问。

cluster-require-full-coverage

cluster-enabledyes:Redis 实例可以分为单机模式(standalone)和集群模式(cluster);cluster-enabledyes 可以启动集群模式。

nodes. add(newHostAndPort( "192.168.72.128", 7002));

节点握手使用 cluster meet {ip} {port} 命令实现,例如在 7000 节点中执行 clustermeet 192.168.72.128 7001,可以完成 7000 节点和 7001 节点的握手。

客户端收到 ASK 错误后,从中读取目标节点的地址信息,并向目标节点重新发送请求,就像收到 MOVED 错误时一样。

Redis 每次启动 runId 都会重新创建,但是节点 id 只在集群初始化时创建一次,然后保存到集群配置文件中,以后节点重新启动时会直接在集群配置文件中读取。

Gossip 协议

我们将搭建一个简单的集群:共 6 个节点,3 主 3 从。方便起见,所有节点在同一台服务器上,以端口号进行区分,配置从简。

通过 cluster nodes 获得几个主节点的节点 id 后,执行下面的命令为每个从节点指定主节点:

clustermeet192.168.72.1287002

Hash Tag 原理是:当一个 key 包含 {} 的时候,不对整个 key 做 hash,而仅对 {} 包括的字符串做 hash。

实际上,前三步完成后集群便可以对外提供服务;但指定从节点后,集群才能够提供真正高可用的服务。

故障转移

为此,集群中的每个节点,都提供了两个 TCP 端口:

daemonize yes

Gossip 协议的优点有负载(比广播)低、去中心化、容错性高(因为通信有冗余)等;缺点主要是集群的收敛速度慢。

这里不再详细介绍故障转移的细节,只对重要事项进行说明:

哈希取余分区

②启动节点

此时再使用 cluster nodes 查看:

这一部分将以 cluster meet(节点握手)、cluster addslots(槽分配)为例,说明节点是如何利用上述数据结构和通信机制实现集群命令的。

责任编辑:

一致性哈希分区

下面是使用 Hash Tag 的一个例子:通过对 product 加 Hash Tag,可以将所有产品信息放到同一个槽中,便于操作。

集群的基本原理

①JedisCluster 初始化时,在内部维护 slot->node 的缓存,方法是连接任一节点,执行 cluster slots 命令,该命令返回如下所示:

不过 Hash Tag 可能会带来数据分配不均的问题,这时需要:

如果有则使用文件中的配置启动;如果没有,则初始化配置并将配置保存到文件中。集群配置文件由 Redis 节点维护,不需要人工修改。

高可用

cluster info 命令可以查看集群状态,分配槽之前状态为 fail:

例如,如果单机内存太大,bgsave 和 bgrewriteaof 的 fork 操作可能导致主进程阻塞,主从环境下主机切换时可能导致从节点长时间无法提供服务,全量复制阶段主节点的复制缓冲区可能溢出。

使用 Ruby 脚本搭建集群

故障转移时间:从主节点故障发生到完成转移,所需要的时间主要消耗在主观下线识别、主观下线传播、选举延迟等几个环节。

clustermeet192.168.72.1288001

执行创建命令后,脚本会给出创建集群的计划,如下图所示;计划包括哪些是主节点,哪些是从节点,以及如何分配槽。

数据结构

实践须知

③迁移槽:推荐使用 redis-trib.rb 的 reshard 工具实现。reshard 自动化程度很高,只需要输入 redis-trib.rb reshard ip:port (ip 和 port 可以是集群中的任一节点)。

其中的 cluster-enabled 和 cluster-config-file 是与集群相关的配置。

前面介绍了集群正常运行和访问的方法和原理,下面是一些重要的补充内容。

每当集群信息发生变化时(如增减节点),集群内所有节点会将最新信息更新到该配置文件。

节点间发送的消息主要分为 5 种:

Smart 客户端(以 Java 的 JedisCluster 为例)的基本原理如下:

redis-trib.rb 脚本提供了众多命令,其中 create 用于搭建集群,使用方法如下:

clustermeet192.168.72.1288002

也就是说,当 Redis 节点以集群模式启动时,会首先寻找是否有集群配置文件。

集群的限制及应对方法

节点握手

一致性哈希分区的主要问题在于,当节点数量较少时,增加或删减节点,对单个节点的影响可能很大,造成数据的严重不平衡。

#redis-7000.conf

实践中常常需要对集群进行伸缩,如访问量增大时的扩容操作。Redis 集群可以在不影响对外服务的情况下实现伸缩;伸缩的核心是槽迁移:修改槽与节点的对应关系,实现槽(即数据)在节点之间的移动。

由于集群中的数据分布在不同节点中,导致一些功能受限,包括:

槽的数量一般远小于 2^32,远大于实际节点的数量;在 Redis 集群中,槽的数量为 16384。

输入 yes 确认执行计划,脚本便开始按照计划执行,如下图所示:

启动节点

charname[REDIS_CLUSTER_NAMELEN];

前面提到,只有当 16384 个槽全部分配完毕时,集群才能上线。这样做是为了保证集群的完整性。

客户端访问集群

但同时也带来了新的问题:当主节点发生故障而故障转移尚未完成,原主节点中的槽不在任何节点中,此时集群会处于下线状态,无法响应客户端的请求。

nodes. add(newHostAndPort( "192.168.72.128", 8001));

其他节点使用相同办法启动,不再赘述。需要特别注意,在启动节点阶段,节点是没有主从关系的,因此从节点不需要加 slaveof 配置。

intport;

通过上述过程可以发现,集群中两个节点的握手过程与 TCP 类似,都是三次握手:A 向 B 发送 MEET;B 向 A 发送 PONG;A 向 B 发送 PING。

nodes. add(newHostAndPort( "192.168.72.128", 7001));

④指定主从关系:方法参见集群搭建。

同理,在 7000 节点中使用 cluster meet 命令,可以将所有节点加入到集群,完成节点握手:

此时查看集群状态,显示所有槽分配完毕,集群进入上线状态:

unsignedcharslots[ 16384/ 8];

集群提供的 cluster keyslot 命令也是使用上述公式实现,如:

因此为了能够在故障发生时顺利选出从节点,集群中至少需要 3 个主节点(且部署在不同的物理机上)。

cluster meet

带虚拟节点的一致性哈希分区

redis-serverredis-7000.conf

System. out.println(cluster. get( "key1"));

以上图为例,如果在 node1 和 node2 之间增加 node5,则只有 node2 中的一部分数据会迁移到 node5;如果去掉 node2,则原 node2 中的数据只会迁移到 node4 中,只有 node4 会受影响。

集群节点的启动仍然是使用 redis-server 命令,但需要使用集群模式启动。

由于哈希的随机性,哈希分区基本可以保证数据分布均匀;因此在比较哈希分区方案时,重点要看增减节点对数据分布的影响。

编辑好配置文件后,使用 redis-server 命令启动该节点:

分配槽

该方案最大的问题是,当新增或删减节点时,节点数量发生变化,系统中所有的数据都需要重新计算映射关系,引发大规模数据迁移。

如果 clusterState.slots[i]==clusterState.myself,说明槽在当前节点,可以直接在当前节点执行命令。

常见的哈希分区包括:哈希取余分区、一致性哈希分区、带虚拟节点的一致性哈希分区等。

节点数量:在故障转移阶段,需要由主节点投票选出哪个从节点成为新的主节点;从节点选举胜出需要的票数为 N/2+1;其中 N 为主节点数量(包括故障主节点),但故障主节点实际上不能投票。

} clusterNode;

②此外,JedisCluster 为每个节点创建连接池(即 JedisPool)。

nodes. add(newHostAndPort( "192.168.72.128", 8002));

与第一种方法中的“启动节点”完全相同。

在 7001 节点下也可以类似查看:

①启动节点:方法参见集群搭建。

至此,集群搭建完毕。

redis-trib.rb del-node 192.168.72.128:7001{节点7000的id}

参数优化

上面这张图很好的总结了 Redis 集群将数据映射到实际节点的过程:

redis-trib.rb 提供了众多实用工具:创建集群、增减节点、槽迁移、检查完整性、数据重新平衡等;通过 help 命令可以查看详细信息。

redis-trib.rb del-node 192.168.72.128:7001{节点8000的id}

ASK 错误

假设要下线 7000/8000 节点,可以分为两步:

假设要增加 7003 和 8003 节点,其中 8003 是 7003 的从节点,步骤如下:

二者的区别在于:前者存储的是该节点中分配了哪些槽,后者存储的是集群中所有槽分别分布在哪个节点。

但是二者有很大区别:ASK 错误说明数据正在迁移,不知道何时迁移完成,因此重定向是临时的,SMART 客户端不会刷新 slots 缓存;MOVED 错误重定向则是(相对)永久的,SMART 客户端会刷新 slots 缓存。

节点间通信,按照通信协议可以分为几种类型:单对单、广播、Gossip 协议等。重点是广播和 Gossip 的对比。

不同的消息类型,通信协议、发送的频率和时机、接收节点的选择等是不同的:

redis-trib.rbadd-node192.168.72.128:8003192.168.72.1287000

集群最核心的功能是数据分区,因此:

redis-cli -p 8000 cluster replicate be816eba968bc16c884b963d768c945e86ac51ae

redis-cli -p 8002 cluster replicate a26f1624a3da3e5197dde267de683d61bb2dcbf1

Redis 单机内存大小受限问题,在介绍持久化和主从复制时都有提及。

消息类型

uint64_tconfigEpoch;

此时执行 cluster nodes 查看各个节点的状态,可以看到主从关系已经建立:

一致性哈希算法将整个哈希值空间组织成一个虚拟的圆环,如下图所示,范围为 0-2^32-1。

redis-cli -p 7002 cluster addslots {10923..16383}

下面列举了 clusterNode 的部分字段,并说明了字段的含义和作用:

数据分区(或称数据分片)是集群最核心的功能。集群将数据分散到多个节点:

当节点重启后,会重新读取该配置文件,获取集群信息,可以方便的重新加入到集群中。

因此,使用集群时,应谨慎使用读写分离技术,因为从节点故障会导致读服务不可用,可用性变差。

②节点握手:可以使用 cluster meet 命令,但在生产环境中建议使用 redis-trib.rb 的 add-node 工具,其原理也是 cluster meet,但它会先检查新节点是否已加入其他集群或者存在数据,避免加入到集群后带来混乱。

至此,集群搭建完毕。

www.cnblogs.com/kismetv/p/9853040.html

具体时间与参数 cluster-node-timeout 有关,一般来说:

数据分区

在使用了槽的一致性哈希分区中,槽是数据管理和迁移的基本单位。槽解耦了数据和实际节点之间的关系,增加或删除节点对系统的影响很小。

Hash Tag 可以让不同的 key 拥有相同的 hash 值,从而分配在同一个槽里;这样针对不同 key 的批量操作(mget/mset 等),以及事务、Lua 脚本等都可以支持。

集群的作用,可以归纳为两点:

redis-cli

Hash Tag

cluster_node_timeout

clusterNode 结构保存了一个节点的当前状态,包括创建时间、节点 id、ip 和端口号等。

3个主节点端口号:7000/7001/7002;对应的从节点端口号:8000/8001/8002。

dbfilename "dump-7000.rdb"

与哈希取余分区相比,一致性哈希分区将增减节点的影响限制在相邻节点。

Smart 客户端

上例中,redis-cli 通过 -c 指定了集群模式,如果没有指定,redis-cli 无法处理 MOVED 错误:

}

在 {REDIS_HOME}/src 目录下可以看到 redis-trib.rb 文件,这是一个 Ruby 脚本,可以实现自动化的集群搭建。

集群的搭建可以分为四步:

在哨兵系统中,节点分为数据节点和哨兵节点:前者存储数据,后者实现额外的控制功能。

下面的例子展示了 redis-cli 和集群的互动过程:在 7000 节点中操作 key1,但 key1 所在的槽 9189 在节点 7001 中。

分配槽使用 cluster addslots 命令,执行下面的命令将槽(编号 0-16383)全部分配完毕:

cluster.close();

集群伸缩的核心是槽迁移。在槽迁移过程中,如果客户端向源节点发送命令,源节点执行流程如下:

下面代码演示了如何使用 JedisCluster 访问集群(未考虑资源释放、异常处理等):

本文将详细介绍集群,主要内容包括:

JedisClustercluster = newJedisCluster(nodes);

集群的搭建

redis-cli -p 7000 cluster addslots {0..5461}

集群命令的实现

下面是 7000 节点的配置文件(只列出了节点正常工作关键配置,其他配置,如开启 AOF,可以参照单机节点进行):

cluster_node_timeout 参数在前面已经初步介绍;它的默认值是 15s,影响包括:

衡量数据分区方法好坏的标准有很多,其中比较重要的两个因素是:

nodes. add(newHostAndPort( "192.168.72.128", 8000));

…………

cluster addslots

redis-trib.rbadd-node192.168.72.128:7003192.168.72.1287000

仍以上图为例,系统中有 4 个实际节点,假设为其分配 16 个槽(0-15);槽 0-3 位于 node1,4-7 位于 node2,以此类推。

假设要向 A 节点发送 cluster meet 命令,将 B 节点加入到 A 所在的集群,则 A 节点收到命令后,执行的操作如下:

执行 Redis 命令搭建集群

注意事项如下:

来源:编程迷思

intnumslots;

还是以上图为例,如果去掉 node2,node4 中的数据由总数据的 1/4 左右变为 1/2 左右,与其他节点相比负载过高。

两者搭建的原理是一样的,只是 Ruby 脚本将 Redis 命令进行了打包封装;在实际应用中推荐使用脚本方式,简单快捷不容易出错。下面分别介绍这两种方式。

集群中的节点采用固定频率(每秒 10 次)的定时任务进行通信相关的工作:判断是否需要发送消息及消息类型、确定接收节点、发送消息等。

mstime_tctime;

引入槽以后,数据的映射关系由数据 hash->实际节点,变成了数据 hash->槽->实际节点。

①计算 key 属于哪个槽:CRC16(key) &16383。

集群的作用

节点启动以后,通过 cluster nodes 命令可以查看节点的情况,如下图所示:

redis-cli -p 8001 cluster replicate 788b361563acb175ce8232569347812a12f1fdb4

cluster addslots 命令接收一个槽或多个槽作为参数,例如在 A 节点上执行 cluster addslots {0..10} 命令,是将编号为 0-10 的槽分配给 A 节点。

cluster-enabled yes

Set<HostAndPort>nodes = newHashSet<>();

增加节点

redis-cli -p 7001 cluster addslots {5462..10922}

该方案在一致性哈希分区的基础上,引入了虚拟节点的概念。Redis 集群使用的便是该方案,其中的虚拟节点称为槽(slot)。

节点需要专门的数据结构来存储集群的状态。所谓集群的状态,是一个比较大的概念,包括:集群是否处于上线状态、集群中有哪些节点、节点是否可达、节点的主从状态、槽的分布……

③当执行命令时,JedisCluster 根据 key->slot->node 选择需要连接的节点,发送命令。

在单机模式下启动的 Redis 实例,如果执行 info server 命令,可以发现 redis_mode 一项为 standalone,如下图所示:

intflags;

集群方案设计

在实践中如果能使用 redis-trib.rb 工具则尽量使用,不但方便快捷,还可以大大降低出错概率。

其中返回值第一项表示节点 id,由 40 个 16 进制字符串组成,节点 id 与主从复制一文中提到的 runId 不同。

例如,如果槽均匀分布在集群的 3 个节点中,此时增加一个节点,则需要从 3 个节点中分别拿出一部分槽给新节点,从而实现槽在 4 个节点中的均匀分布。

哈希分区的基本思路是:对数据的特征值(如 key)进行哈希,然后根据哈希值决定数据落在哪个节点。

与哨兵一样,集群只实现了主节点的故障转移;从节点故障时只会被下线,不会进行故障转移。

集群支持主从复制和主节点的自动故障转移(与哨兵类似),当任一节点发生故障时,集群仍然可以对外提供服务。本文内容基于 Redis 3.0.6。

节点启动以后是相互独立的,并不知道其他节点存在;需要进行节点握手,将独立的节点组成一个网络。

如果成功,则命令执行完毕;如果执行失败,则会随机选择其他节点进行重试,并在出现 MOVED 错误时,使用 cluster slots 重新同步 slot->node 的映射关系。

设计集群方案时,至少要考虑以下因素:

redis-cli 这一类客户端称为 Dummy 客户端,因为它们在执行命令前不知道数据在哪个节点,需要借助 MOVED 错误重新定向。与 Dummy 客户端相对应的是 Smart 客户端。

在哨兵一文中,介绍了哨兵实现故障发现和故障转移的原理。

集群中槽的分配信息,存储在 clusterNode 的 slots 数组和 clusterState 的 slots 数组中,两个数组的结构前面已做介绍。

减少节点

typedefstructclusterNode{

每个节点都会用一个 clusterNode 结构记录自己的状态,并为集群内所有其他节点都创建一个 clusterNode 结构来记录节点状态。

③redis-cli 收到 MOVED 错误后,根据返回的 ip 和 port 重新发送请求。

①安装 Ruby 环境

上面介绍了集群的搭建方法和设计方案,下面将进一步深入,介绍集群的原理。

集群模式下的节点,其 redis_mode 为 cluster,如下图所示:

否则,说明槽不在当前节点,则查询槽所在节点的地址(clusterState.slots[i].ip/port),并将其包装到 MOVED 错误中返回给 redis-cli。

在前面的文章中已经介绍了 Redis 的几种高可用技术:、和,但这些方案仍有不足,其中最主要的问题是存储能力受单机限制,以及无法实现写操作的负载均衡。

clustermeet192.168.72.1288000

如果集群状态发生了变化,如增减节点、槽状态变更,通过节点间的通信,所有节点会很快得知整个集群的状态,使集群收敛。

节点通信机制

哈希取余分区思路非常简单:计算 key 的 hash 值,然后对节点数量进行取余,从而决定数据映射到哪个节点上。

charip[REDIS_IP_STR_LEN];

参考文献:

②判断 key 所在的槽是否在当前节点:假设 key 位于第 i 个槽,clusterState.slots[i] 则指向了槽所在的节点。

集群中指定主从关系不再使用 slaveof 命令,而是使用 cluster replicate 命令;参数使用节点 id。

槽是介于数据和实际节点之间的虚拟概念;每个实际节点包含一定数量的槽,每个槽包含哈希值在一定范围内的数据。

然后按照提示输入以下信息,槽迁移会自动完成:

集群的搭建有两种方式:

集群中的节点分为主节点和从节点:只有主节点负责读写请求和集群信息的维护;从节点只进行主节点数据和状态信息的复制。

参数默认值为 yes,如果应用对可用性要求较高,可以修改为 no,但需要自己保证槽全部分配。

集群伸缩

cluster-config-file:该参数指定了集群配置文件的位置。每个节点在运行过程中,会维护一份集群配置文件。

集群,即 Redis Cluster,是 Redis 3.0 开始引入的分布式存储方案。集群由多个节点(Node)组成,Redis 的数据分布在这些节点中。

执行完上述命令后,可以看到 7000 节点已经感知到了所有其他节点:

以 Ubuntu 为例,如下操作即可安装 Ruby 环境:

具体执行过程如下:

redis-trib.rb

./redis-trib.rb create--replicas 1 192.168.72.128:7000192.168.72.128:7001 192.168.72.128:7002 192.168.72.128:8000 192.168.72.128:8001192.168.72.128:8002

节点为了存储集群状态而提供的数据结构中,最关键的是 clusterNode 和 clusterState 结构:前者记录了一个节点的状态,后者记录了集群作为一个整体的状态。

在集群中,没有数据节点与非数据节点之分:所有的节点都存储数据,也都参与集群状态的维护。

logfile "log-7000.log"

clusterNode

集群要作为一个整体工作,离不开节点之间的通信。

虽然细节上有很大不同,但集群的实现与哨兵思路类似:通过定时任务发送 PING 消息检测其他节点状态;节点下线分为主观下线和客观下线;客观下线后选取从节点进行故障转移。

数据分区方案

如果此时删除 node2,只需要将槽 4-7 重新分配即可,例如槽 4-5 分配给 node1,槽 6 分配给 node3,槽 7 分配给 node4;可以看出删除 node2 后,数据在其他节点的分布仍然较为均衡。

Gossip 协议的特点是:在节点数量有限的网络中,每个节点都“随机”的与部分节点通信(并不是真正的随机,而是根据特定的规则选择通信的节点),经过一番杂乱无章的通信,每个节点的状态很快会达到一致。

其中:--replicas=1 表示每个主节点有 1 个从节点;后面的多个 {ip:port} 表示节点地址,前面的做主节点,后面的做从节点。使用 redis-trib.rb 搭建集群时,要求节点不能包含任何槽和数据。

通过节点之间的通信,每个节点都可以感知到所有其他节点,以 8000 节点为例:

当节点收到 redis-cli 发来的命令(如 set/get)时,过程如下:

nodes. add(newHostAndPort( "192.168.72.128", 7000));

除此之外,clusterState 还包括故障转移、槽迁移等需要的信息。

cluster-config-file "node-7000.conf"

对于每个数据,根据 key 计算 hash 值,确定数据在环上的位置,然后从此位置沿环顺时针行走,找到的第一台服务器就是其应该映射到的服务器。

两个端口

广播是指向集群内所有节点发送消息;优点是集群的收敛速度快(集群收敛是指集群内所有节点获得的集群信息是一致的),缺点是每条消息都要发送给所有节点,CPU、带宽等消耗较大。

数据分区有顺序分区、哈希分区等,其中哈希分区由于其天然的随机性,使用广泛;集群的分区方案便是哈希分区的一种。

当数据库中的 16384 个槽都分配了节点时,集群处于上线状态(ok);如果有任意一个槽没有分配节点,则集群处于下线状态(fail)。

因此节点返回 MOVED 错误(包含 7001 节点的 ip 和 port)给 redis-cli,redis-cli 重新向 7001 发起请求。

在集群中,数据分布在不同的节点中,客户端通过某节点访问数据时,数据可能不在该节点中;下面介绍集群是如何处理这个问题的。

本文地址:http://ktw8.com/post/170.html 转载请注明出处!

标签: 设计 开发 客户端