redis 集群
一、概念
分布式网络服务器集群,没有中心节点,在多个节点间共享数据,从3.0版本中开始支持。
二、数据切片
哈希槽
redis集群中共有16384个哈希槽,每个key通过crc16校验后对16384取模来决定放置哪个槽。集群中每个节点负责一部分hash槽,
举个例子,比如当前集群有3个节点,那么:
- 节点 A 包含 0 到 5500号哈希槽.
- 节点 B 包含5501 到 11000 号哈希槽.
- 节点 C 包含11001 到 16384号哈希槽.
这种结构很容易添加或者删除节点. 比如如果我想新添加个节点D, 我需要从节点 A, B, C中得部分槽到D上. 如果我想移除节点A,需要将A中的槽移到B和C节点上,然后将没有任何槽的A节点从集群中移除即可. 由于从一个节点将哈希槽移动到另一个节点并不会停止服务,所以无论添加删除或者改变某个节点的哈希槽的数量都不会造成集群不可用的状态.
1.槽指派:
记录节点处理哪些槽?记录节点一共处理多少槽:clusterNode
struct clusterNode {
unsigned char slots[16384/8];
int numslots;
};
slots 属性是一个二进制数组,这个数组长为16384/8=2048个字节,包含16384个二进制位。
根据二进制数组的索引判断,该节点是否处理该数据槽i:
- 如果slots数组在索引i上的二进制位的值为1,那么表示节点负责处理槽i;
- 如果slots数组在索引i上的二进制位的值为0,那么表示节点不负责处理槽i;
2.槽指派信息的传播
每个槽节点会将自己负责的槽信息发送给其他槽。当节点A通过消息从节点B那里接收到节点B的数组时,节点A会在在即的clusterState.nodes字典查找节点B
对应的clusterNode结构,并对该结构进行更新和保存。
因为集群中的每个节点都会将自己的slots数组通过消息发送给集群中的其他节点,并且每个接收到slots数组的节点都会将数组保存到相应节点的clusterNode结构里面,因此,集群中的每个节点都会知道数据库中的16384个槽分别被指派给了集群中的哪些节点。
三、主从复制
为了实现数据高可用性,redis集群使用了主从复制功能,举例来说:集群中有A、B、C 3个主节点,每个主节点都会配置一个数据切片A1、B1、C1,
这样集群由3个master节点和3个slave节点组成,这样即使主节点B失败,集群会选举出B1为新的主节点继续服务。
数据槽分布在主节点上,从节点没有分槽,仅作为主节点的一个备份。
四、故障转移
(1) Redis-Cluster是无中心的架构,判断节点失败是通过仲裁的方式来进行(gossip和raft),也就是大部分节点认为一个节点挂掉了,就会做fail判定。
(2) 如果某个节点在执行比较重的操作(flushall, slaveof等等)(可能短时间redis客户端连接会阻塞(redis单线程))或者由于网络原因,造成其他节点认为它挂掉了,会做fail判定。
(3) Redis-Cluster提供了cluster-node-timeout这个参数(默认15秒),作为fail依据(如果超过15秒还是没反应,就认为是挂掉了).
五、集群搭建
1.节点数量至少为6个才能保证集群的高可用性。
修改配置文件:新建一个目录,cp redis.conf redis6666.conf
port 6379 //端口 cluster-enabled yes //开启集群模式 cluster-config-file nodes-6379.conf //集群内部的配置文件 cluster-node-timeout 15000 //节点超时时间,单位毫秒
2.启动所有的节点
sudo redis-server conf/redis-6384.conf
sudo redis-server conf/redis-6383.conf
sudo redis-server conf/redis-6382.conf
sudo redis-server conf/redis-6381.conf
sudo redis-server conf/redis-6380.conf
sudo redis-server conf/redis-6379.conf
3.节点握手
节点握手是指一批运行在集群模式的节点通过Gossip
协议彼此通信,达到感知对方的过程。节点握手是集群彼此通信的第一步,由客户端发起命令:cluster meet <ip> <port>
127.0.0.1:6379> CLUSTER MEET 127.0.0.1 6380 OK // 发送CLUSTER NODES可以查看到已经感知到 6380 端口的节点了。 127.0.0.1:6379> CLUSTER NODES 29978c0169ecc0a9054de7f4142155c1ab70258b 127.0.0.1:6379 myself,master - 0 0 1 connected 8f285670923d4f1c599ecc93367c95a30fb8bf34 127.0.0.1:6380 master - 0 1496129041442 0 connected
让所有的节点都互相感知:
127.0.0.1:6379> CLUSTER MEET 127.0.0.1 6381 OK 127.0.0.1:6379> CLUSTER MEET 127.0.0.1 6382 OK 127.0.0.1:6379> CLUSTER MEET 127.0.0.1 6383 OK 127.0.0.1:6379> CLUSTER MEET 127.0.0.1 6384 OK // 已经全部感知到所有的节点 127.0.0.1:6379> CLUSTER NODES e0c7961a1b07ab655bc31d8dfd583da565ec167d 127.0.0.1:6384 master - 0 1496129143703 0 connected 961097d6be64ebd2fd739ff719e97565a8cee7b5 127.0.0.1:6382 master - 0 1496129141678 0 connected 29978c0169ecc0a9054de7f4142155c1ab70258b 127.0.0.1:6379 myself,master - 0 0 1 connected 8f285670923d4f1c599ecc93367c95a30fb8bf34 127.0.0.1:6380 master - 0 1496129142682 3 connected 6fb7dfdb6188a9fe53c48ea32d541724f36434e9 127.0.0.1:6383 master - 0 1496129145699 4 connected 66478bda726ae6ba4e8fb55034d8e5e5804223ff 127.0.0.1:6381 master - 0 1496129147704 2 connected
当前已经使这六个节点组成集群,但是现在还无法工作,因为集群节点还没有分配槽(slot)。
4.分配槽
127.0.0.1:6379> CLUSTER INFO cluster_state:fail cluster_slots_assigned:0 // 被分配槽的个数为0
cluster_slots_ok:0
cluster_slots_pfail:0
cluster_slots_fail:0
cluster_known_nodes:6
cluster_size:0
cluster_current_epoch:5
cluster_my_epoch:1
cluster_stats_messages_sent:479
cluster_stats_messages_received:479
接下来为节点分配槽空间。通过cluster addslots
命令。
redis-cli -h 127.0.0.1 -p 6379 cluster addslots {0..5461} OK redis-cli -h 127.0.0.1 -p 6380 cluster addslots {5462..10922} OK redis-cli -h 127.0.0.1 -p 6381 cluster addslots {10923..16383} OK
我们将16383
个槽平均分配给6379
、6380
、6381
端口的节点。再次执行CLUSTER INFO
查看一下集群的状态:
127.0.0.1:6379> CLUSTER INFO cluster_state:ok // 集群状态OK cluster_slots_assigned:16384 // 已经分配了所有的槽 cluster_slots_ok:16384 cluster_slots_pfail:0 cluster_slots_fail:0 cluster_known_nodes:6 cluster_size:3 cluster_current_epoch:5 cluster_my_epoch:1 cluster_stats_messages_sent:1212 cluster_stats_messages_received:1212
可以通过CLUSTER NODES
来查看分配情况:
127.0.0.1:6379> CLUSTER NODES e0c7961a1b07ab655bc31d8dfd583da565ec167d 127.0.0.1:6384 master - 0 1496129666347 0 connected 961097d6be64ebd2fd739ff719e97565a8cee7b5 127.0.0.1:6382 master - 0 1496129664844 5 connected 29978c0169ecc0a9054de7f4142155c1ab70258b 127.0.0.1:6379 myself,master - 0 0 1 connected 0-5461 8f285670923d4f1c599ecc93367c95a30fb8bf34 127.0.0.1:6380 master - 0 1496129665846 3 connected 5462-10922 6fb7dfdb6188a9fe53c48ea32d541724f36434e9 127.0.0.1:6383 master - 0 1496129661838 4 connected 66478bda726ae6ba4e8fb55034d8e5e5804223ff 127.0.0.1:6381 master - 0 1496129666848 2 connected 10923-16383
目前还有三个节点没有使用,作为一个完整的集群,每个负责处理槽的节点应该具有从节点,保证当主节点出现故障时,可以自动进行故障转移。集群模式下,首次启动的节点和被分配槽的节点都是主节点,从节点负责复制主节点槽的信息和相关数据。
使用cluster replicate <nodeid>
在从节点上执行。
redis-cli -h 127.0.0.1 -p 6382 cluster replicate 29978c0169ecc0a9054de7f4142155c1ab70258b OK redis-cli -h 127.0.0.1 -p 6383 cluster replicate 8f285670923d4f1c599ecc93367c95a30fb8bf34 OK redis-cli -h 127.0.0.1 -p 6384 cluster replicate 66478bda726ae6ba4e8fb55034d8e5e5804223ff OK
通过CLUSTER NODES
可以查看集群节点的状态
127.0.0.1:6379> CLUSTER NODES e0c7961a1b07ab655bc31d8dfd583da565ec167d 127.0.0.1:6384 slave 66478bda726ae6ba4e8fb55034d8e5e5804223ff 0 1496130082754 2 connected 961097d6be64ebd2fd739ff719e97565a8cee7b5 127.0.0.1:6382 slave 29978c0169ecc0a9054de7f4142155c1ab70258b 0 1496130080749 5 connected 29978c0169ecc0a9054de7f4142155c1ab70258b 127.0.0.1:6379 myself,master - 0 0 1 connected 0-5461 8f285670923d4f1c599ecc93367c95a30fb8bf34 127.0.0.1:6380 master - 0 1496130078744 3 connected 5462-10922 6fb7dfdb6188a9fe53c48ea32d541724f36434e9 127.0.0.1:6383 slave 8f285670923d4f1c599ecc93367c95a30fb8bf34 0 1496130079747 4 connected 66478bda726ae6ba4e8fb55034d8e5e5804223ff 127.0.0.1:6381 master - 0 1496130081751 2 connected 10923-16383