redis mysql 集群_Redis多机数据库之集群

本文详细介绍了Redis集群的工作原理,包括节点间的通信、数据分片、槽指派、命令执行、复制与故障转移机制。Redis集群通过16384个槽实现数据分布,节点间通过消息传递保持同步。在故障发生时,从节点能够进行故障转移,接管主节点的槽处理。此外,还讨论了ASK和MOVED错误的处理,以及集群中的消息类型如MEET、PING、PONG和FAIL等。
摘要由CSDN通过智能技术生成

集群

Redis集群是Redis提供的分布式数据库方案,集群通过分片sharding 来进行数据共享,并提供复制和故障转移功能,结合Redis多机数据库的其他功能实现的。

1、节点

一个Redis集群由多个节点构成,节点可以看成是数据库的抽象,一个节点就是一个运行在集群模式下的Redis服务器,连接各个节点命令是:

CLUSTER MEET

向一个节点node发送CLUSTER MEET命令,可以让node节点与ip和port所指定的节点进行握手(handshake),当握手成功时,node节点就会将ip和port所指定的节点添加到node节点当前所在的集群中

CLUSTER MEET命令连接节点进行握手建立连接时,类似与TCP的三次握手。

当节点建立连接后,节点A会将节点B的信息通过Gossip协议传播给集群中的其他节点,让其他节点也与节点B进行握手,最终,经过一段时间之后,节点B会被集群中的所有节点认识。

Redis服务器在启动时会根据cluster-enabled配置选项是否为yes来决定是否开启服务器的集群模式

节点(运行在集群模式下的Redis服务器)会继续使用所有在单机模式中使用的服务器组件,也有在集群模式下特有的数据结构和组件。

2、集群数据结构

cluster.h/clusterNode结构、cluster.h/clusterLink结构,以及cluster.h/clusterState结构。

clusterNode结构:每个节点会用此结构来记录自己的状态,并为集群中所有其他节点包括主从节点,都创建一个响应的此结构,来记录其他节点的状态:

struct clusterNode {

// 创建节点的时间

mstime_t ctime;

// 节点的名字,由40个十六进制字符组成

// 例如68eef66df23420a5862208ef5b1a7005b806f2ff

char name[REDIS_CLUSTER_NAMELEN];

// 节点标识

// 使用各种不同的标识值记录节点的角色(比如主节点或者从节点),

// 以及节点目前所处的状态(比如在线或者下线)。

int flags;

// 节点当前的配置纪元,用于实现故障转移

uint64_t configEpoch;

// 节点的IP地址

char ip[REDIS_IP_STR_LEN];

// 节点的端口号

int port;

// 保存连接节点所需的有关信息

clusterLink *link;  // ...

};

typedef struct clusterLink {

// 连接的创建时间

mstime_t ctime;

// TCP 套接字描述符

int fd;

// 输出缓冲区,保存着等待发送给其他节点的消息(message)。

sds sndbuf;

// 输入缓冲区,保存着从其他节点接收到的消息。

sds rcvbuf;

// 与这个连接相关联的节点,如果没有的话就为NULL

struct clusterNode *node;

} clusterLink;

redisClient结构和clusterLink结构都有自己的套接字描述符和输入、输出缓冲区,这两个结构的区别在于,redisClient结构中的套接字和缓冲区是用于连接客户端的,而clusterLink结构中的套接字和缓冲区则是用于连接节点的。

clusterState结构:每个节点都保存着一个clusterState结构,这个结构记录了在当前节点的视角下,集群目前所处的状态,例如集群是在线还是下线,集群包含多少个节点,集群当前的配置纪元

typedef struct clusterState {

// 指向当前节点的指针

clusterNode *myself;

// 集群当前的配置纪元,用于实现故障转移

uint64_t currentEpoch;

// 集群当前的状态:是在线还是下线

int state;

// 集群中至少处理着一个槽的节点的数量

int size;

// 集群节点名单(包括myself节点)

// 字典的键为节点的名字,字典的值为节点对应的clusterNode结构

dict *nodes;

// ...

} clusterState;

3、槽指派

Redis集群通过分片的方式来保存数据库中的键值对:集群的整个数据库被分为16384个槽(slot),数据库中的每个键都属于这16384个槽的其中一个,集群中的每个节点可以处理0个或最多16384个槽。

当数据库中的16384个槽都有节点在处理时,集群处于上线状态(ok);相反地,如果数据库中有任何一个槽没有得到处理,那么集群处于下线状态(fail)。

通过向节点发送CLUSTER ADDSLOTS命令,我们可以将一个或多个槽指派(assign)给节点负责。这个步骤其实是将整个数据库进行分布式处理

clusterNode结构的slots属性和numslot属性记录了节点负责处理哪些槽:

slots属性是一个二进制位数组(bit array),这个数组的长度为16384/8=2048个字节,共包含16384个二进制位

Redis以0为起始索引,16383为终止索引,对slots数组中的16384个二进制位进行编号,并根据索引i上的二进制位的值来判断节点是否负责处理槽i,类似于位图的方式,验证时间复杂度很快:

如果slots数组在索引i上的二进制位的值为1,那么表示节点负责处理槽i;

如果slots数组在索引i上的二进制位的值为0,那么表示节点不负责处理槽i;

numslot表示当前节点中处理槽的总数

取出和设置slots数组中的任意一个二进制位的值的复杂度仅为O(1),所以对于一个给定节点的slots数组来说,程序检查节点是否负责处理某个槽,又或者将某个槽指派给节点负责,这两个动作的复杂度都是O(1)

一个节点除了会将自己负责处理的槽记录在clusterNode结构的slots属性和numslots属性之外,它还会将自己的slots数组通过消息发送给集群中的其他节点,以此来告知其他节点自己目前负责处理哪些槽;集群中的每个节点都会将自己的slots数组通过消息发送给集群中的其他节点,并且每个接收到slots数组的节点都会将数组保存到相应节点的clusterNode结构里面,因此,集群中的每个节点都会知道数据库中的16384个槽分别被指派给了集群中的哪些节点。

clusterState结构中的slots数组记录了集群中所有16384个槽的指派信息。slots数组包含16384个项,每个数组项都是一个指向clusterNode结构的指针。

clusterState.slots数组记录了集群中所有槽的指派信息,而clusterNode.slots数组只记录了clusterNode结构所代表的节点的槽指派信息,这是两个slots数组的关键区别所在。

CLUSTER ADDSLOTS命令接受一个或多个槽作为参数,并将所有输入的槽指派给接收该命令的节点负责,如果输入的槽参数中,有一个槽已经被某个节点所指派,那么命令失败,返回客户端执行错误信息。在CLUSTER ADDSLOTS命令执行完毕之后,节点会通过发送消息告知集群中的其他节点,自己目前正在负责处理哪些槽。

4、在集群中执行命令

当集群进入上线状态,即16384个槽全部被指派时,客户端就可以向集群中的节点发布命令了。发布命令的判断如下:

d62b19443b3b6ba2408e45030c93d3ff.png

计算键key属于哪个槽的算法:CRC16(key) & 16384 ;CLUSTER KEYSLOT命令可以查看一个给定键属于哪个槽

判断槽是否由当前节点处理:

如果clusterState.slots[i]等于clusterState.myself,那么说明槽i由当前节点负责,节点可以执行客户端发送的命令

如果clusterState.slots[i]不等于clusterState.myself,那么说明槽i并非由当前节点负责,节点会根据clusterState.slots[i]指向的clusterNode结构所记录的节点IP和端口号,向客户端返回MOVED错误,指引客户端转向至正在处理槽i的节点。

MOVED错误的格式为:MOVED :;集群模式下,是不是打印出该错误,而是自动进行节点转向,在单机stand Alone模式会被客户端打印出来

当客户端接收到节点返回的MOVED错误时,客户端会根据MOVED错误中提供的IP地址和端口号,转向至负责处理槽slot的节点,并向该节点重新发送之前想要执行的命令,实质上就是换一个套接字发送命令,如果没由创建套接字连接,则会根据IP和端口号来连接节点,再进行转向。

5、节点中数据库实现和槽重新分片

集群中保留键值对和键值对过期时间的方式同单机Redis服务器的方式完全相同,只是集群中节点只能使用0号数据库,而单机数据库没有这个限制。

另外,节点还会用clusterState结构中的slots_to_keys跳跃表存放键和槽位的关系,将槽作为跳跃表的分值,键作为跳跃表的成员。

通过在slots_to_keys跳跃表中记录各个数据库键所属的槽,节点可以很方便地对属于某个或某些槽的所有数据库键进行批量操作,例如命令CLUSTER GETKEYSINSLOT命令可以返回最多count个属于槽slot的数据库键,而这个命令就是通过遍历slots_to_keys跳跃表来实现的。

Redis集群的重新分片操作可以将任意数量已经指派给某个节点(源节点)的槽改为指派给另一个节点(目标节点),并且相关槽所属的键值对也会从源节点被移动到目标节点,重新分片操作可以在线(online)进行,在重新分片的过程中,集群不需要下线,并且源节点和目标节点都可以继续处理命令请求。

Redis集群的重新分片操作是由Redis的集群管理软件redis-trib负责执行的,Redis提供了进行重新分片所需的所有命令,而redis-trib则通过向源节点和目标节点发送命令来进行重新分片操作。

6、ASK错误

在进行重新分片期间,源节点向目标节点迁移一个槽的过程中,可能会出现这样一种情况:属于被迁移槽的一部分键值对保存在源节点里面,而另一部分键值对则保存在目标节点里面。

当客户端向源节点发送一个与数据库键有关的命令,并且命令要处理的数据库键恰好就属于正在被迁移的槽时:

源节点会先在自己的数据库里面查找指定的键,如果找到的话,就直接执行客户端发送的命令。

相反地,如果源节点没能在自己的数据库里面找到指定的键,那么这个键有可能已经被迁移到了目标节点,源节点将向客户端返回一个ASK错误,指引客户端转向正在导入槽的目标节点,并再次发送之前想要执行的命令。

与MOVED错误的区别:

MOVED错误代表槽的负责权已经从一个节点转移到了另一个节点:在客户端收到关于槽i的MOVED错误之后,客户端每次遇到关于槽i的命令请求时,都可以直接将命令请求发送至MOVED错误所指向的节点,因为该节点就是目前负责槽i的节点。

ASK错误只是两个节点在迁移槽的过程中使用的一种临时措施:在客户端收到关于槽i的ASK错误之后,客户端只会在接下来的一次命令请求中将关于槽i的命令请求发送至ASK错误所指示的节点,但这种转向不会对客户端今后发送关于槽i的命令请求产生任何影响,客户端仍然会将关于槽i的命令请求发送至目前负责处理槽i的节点,除非ASK错误再次出现。

7、复制与故障转移

Redis集群中的节点分为主节点和从节点,其中主节点负责处理槽,从节点用于复制某个主节点,并在被复制的主节点下线时,代替下线主节点继续处理命令请求

集群中的复制节点的命令: CLUSTER REPLICATE

一个节点成为从节点,并开始复制某个主节点这一信息会通过消息发送给集群中的其他节点,最终集群中的所有节点都会知道某个从节点正在复制某个主节点。集群中的所有节点都会在代表主节点的clusterNode结构的slaves属性和numslaves属性中记录正在复制这个主节点的从节点名单。

集群中的每个节点都会定期地向集群中的其他节点发送PING消息,以此来检测对方是否在线,如果接收PING消息的节点没有在规定的时间内,向发送PING消息的节点返回PONG消息,那么发送PING消息的节点就会将接收PING消息的节点标记为疑似下线 probable fail,PFAIL

集群中的各个节点会通过互相发送消息的方式来交换集群中各个节点的状态信息。

当一个主节点A通过消息得知主节点B认为主节点C进入了疑似下线状态时,主节点A会在自己的clusterState.nodes字典中找到主节点C所对应的clusterNode结构,并将主节点B的下线报告(failure report)添加到clusterNode结构的fail_reports链表里面。

如果在一个集群里面,半数以上负责处理槽的主节点都将某个主节点x报告为疑似下线,那么这个主节点x将被标记为已下线(FAIL),将主节点x标记为已下线的节点会向集群广播一条关于主节点x的FAIL消息,所有收到这条FAIL消息的节点都会立即将主节点x标记为已下线。

当一个从节点发现自己正在复制的主节点进入了已下线状态时,从节点将开始对下线主节点进行故障转移,以下是故障转移的执行步骤:

复制下线主节点的所有从节点里面,会有一个从节点被选中;

被选中的从节点会执行SLAVEOF no one命令,成为新的主节点;

新的主节点会撤销所有对已下线主节点的槽指派,并将这些槽全部指派给自己;

新的主节点向集群广播一条PONG消息,这条PONG消息可以让集群中的其他节点立即知道这个节点已经由从节点变成了主节点,并且这个主节点已经接管了原本由已下线节点负责处理的槽。

新的主节点开始接收和自己负责处理的槽有关的命令请求,故障转移完成。

新的主节点是通过选举产生,产生方法与选举Sentinel哨兵的方法一致。因为两者都是基于Raft算法的领头选举(leader election)方法来实现的。

8、消息

集群中的各个节点通过发送和接收消息(message)来进行通信,我们称发送消息的节点为发送者(sender),接收消息的节点为接收者(receiver);一条消息由消息头(header)和消息正文(data)组成

常见消息主要有以下五种:

MEET消息:当发送者接到客户端发送的CLUSTER MEET命令时,发送者会向接收者发送MEET消息,请求接收者加入到发送者当前所处的集群里面

PING消息:集群里的每个节点默认每隔一秒钟就会从已知节点列表中随机选出五个节点,然后对这五个节点中最长时间没有发送过PING消息的节点发送PING消息,以此来检测被选中的节点是否在线。除此之外,如果节点A最后一次收到节点B发送的PONG消息的时间,距离当前时间已经超过了节点A的cluster-node-timeout选项设置时长的一半,那么节点A也会向节点B发送PING消息,这可以防止节点A因为长时间没有随机选中节点B作为PING消息的发送对象而导致对节点B的信息更新滞后

PONG消息:当接收者收到发送者发来的MEET消息或者PING消息时,为了向发送者确认这条MEET消息或者PING消息已到达,接收者会向发送者返回一条PONG消息。另外,一个节点也可以通过向集群广播自己的PONG消息来让集群中的其他节点立即刷新关于这个节点的认识,例如当一次故障转移操作成功执行之后,新的主节点会向集群广播一条PONG消息,以此来让集群中的其他节点立即知道这个节点已经变成了主节点,并且接管了已下线节点负责的槽

FAIL消息:当一个主节点A判断另一个主节点B已经进入FAIL状态时,节点A会向集群广播一条关于节点B的FAIL消息,所有收到这条消息的节点都会立即将节点B标记为已下线

PUBLISH消息:当节点接收到一个PUBLISH命令时,节点会执行这个命令,并向集群广播一条PUBLISH消息,所有接收到这条PUBLISH消息的节点都会执行相同的PUBLISH命令

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值