Redis集群从搭建到设计，总有一些你不曾了解的东西

Redis集群是Redis服务器高可用的设计模型，也是我们线上应用最多的Redis部署架构。本文主要针对Redis集 群入门搭建、Redis集群节点及其底层数据结构、hash槽、重新分片、消息等核心操作及原理进行分享。本文是基于Redis6.0.1版本展开。

集群搭建

在学习底层原理之前我们首先需要集群是如何应用及搭建部署的。本小节主要介绍集群搭建的核心步骤（本文都是在linux环境上进行操作，至于怎么下载Redis安装包及make过程不在本文讲解内容之内，因为它过于基础）。

环境准备

将安装好的Redis包放到任意目录，我这里是放到了/Users/mm/application/redis-cluster中。我这里就以伪集群的方式来进行说明（与集群搭建部署方式基本一致），部署6个集群节点。

• 在redis-cluster/config目录中新建6个目录（我这里分别命名为7001、7002、7003、7004、7005、7006，代表6个节点），将redis.conf配置和redis-server启动文件分别cp到这6个目录中（我这里也将每个节点的redis.conf配置文件也分别命名成redis7001.conf、redis7002.conf … …），并将这6个目录进行授权。

• 修改每个节点中redis.conf的配置（可以先修改一个节点的配置，然后使用例如sed -i ‘’ ‘s/7001/7002/g’ redis7002.conf）:

  bind 192.XXX.XXX.XXX     		#改为实际的外网ip
  port 7001                       #端口（伪集群模式下ip一致、端口不一致）
  cluster-enabled yes            	#开启此配置，启用集群模式
  logfile "/log7001.log"          #集群日志文件配置，因为是伪集群，日志名称通过端口进行区分命名，集群下无所谓
  

• 新建一个redis集群启动脚本（因为节点太多，每个节点都用命令启动太麻烦了），脚本我就放在了redis-cluster根目录下，cluster.sh：

  cd config/7001
  ./redis-server ./redis7001.conf&
  cd ../7002
  ./redis-server ./redis7002.conf&
  cd ../7003
  ./redis-server ./redis7003.conf&
  cd ../7004
  ./redis-server ./redis7004.conf&
  cd ../7005
  ./redis-server ./redis7005.conf&
  cd ../7006
  ./redis-server ./redis7006.conf&
  

启动

现在我们就可以启动集群了。

• 执行上面编写好的cluster.sh脚本。

  mm@mmdeiMac redis-cluster % ./cluster.sh 
  

• 启动之后查看reids进程：
  
  我们看到6个节点都已经启动，并且是以cluster的模式启动。

• 但此时redis集群还没有真正搭建完成，因为此时主从节点还未分配、hash槽也未分配。下面为创建集群及自动分配hash槽：
  

• 经过上述部署，集群基本搭建完成，我们可以用redis-cli来登陆客户端，看下集群效果（以集群方式连接客户端）：
  
  上面通过cluster info查看到了redis集群节点的状态、cluster nodes查看到了集群中的每个节点的主从关系及每个节点负责的hash槽位。可以通过set、get来测试了。

集群节点数据结构

上图描述了集群中的节点的数据结构：

• clusterState：集群中当前节点的描述信息。

  struct clusterState {
  	* myself;
  	currentEpoch;
  	* slots;
  	* nodes;
  	flag;
  	...
  }
  

  myself：指向当前节点本身的指针；
  currentEpoch：当前集群的纪元；
  slots：集群中所有的槽位数组，每个数组索引指向负责该槽位的节点；
  nodes：当前节点已知的集群中的所有节点；
  flag：标记当前节点的角色；
  state：当前节点的状态（在线/下线）。

• clusterNode：描述集群中的节点信息。

  struct clusterNode {
  	ip;
  	port;
  	flag;
  	* sort;
  	...
  }
  

  ip：节点的ip；
  port：节点的端口；
  flag：节点的角色；
  sort：指针数组，记录了所属节点负责的槽位。即是一个长度16384的数组，每一个索引代表一个槽位，索引值为当前索引槽位是否属于当前节点，若值为1即当前槽位是属于这个节点的，否则为0，即当前槽位不属于当前节点。

hash槽

一直在提hash槽，那么hash槽是什么呢？hash槽是redis集群中的一个逻辑值，共有16384个（从0-16383编号），集群中的每个主节点都负责一部分hash槽。即当一个客户端向集群中发起一个set key value请求后，这个键值对会发往哪个节点进行处理，此时就用到了hash槽。hash槽的值=CRC16(key) & 16383，CRC16大家可以理解为是一个算法，最终计算出的值就在0-16383之间，即该请求就会由负责当前槽位的节点处理。

加入新节点

扩展当前集群，向集群中加入新节点：

cluster meet ip port

新建一个节点7007，将7007这个节点加入集群：

我们可以看到加入集群后的7007节点还没有分配槽位，我们可以通过以下命令分配槽位：

cluster addslots slot … slot

为7007节点分配槽位（0-5400）：

让系统自动重新分配槽位：

redis-cli --cluster reshard ip port

上面重新分配槽位是报错了，可能是由于节点删除了，相应的槽位没有正确的删除，导致槽位分布不正确。
此时可以通过以下操作完成修复：

上述操作是修复集群中节点的问题。

以下是7002节点从7001节点分配hash槽的过程：

cluster meet原理

客户端在server A上执行meet操作，希望将server B加入到集群中：

• 客户端执行meet操作，server A上建立节点B的信息clusterNode，保存到A节点的clusterState.nodes属性中；
• server A根据cluster meet ip port中的ip和port向server B发送meet请求。
• server B接收到A的meet请求后，在server B节点上新建一个A节点的信息clusterNode，保存在B节点的clusterState.nodes属性中。server B向节点A发送一个pong消息。
• server A收到server B的pong消息后，向server A发送一个ping消息。
• server B收到server A发来的ping消息后，知道server A已经确认了自己发送的消息后，完成了整个握手操作。
• 完成后，server A会讲server B加入到集群的消息通过Gossip协议发送给集群中的所有节点，至此集群中的所有节点都知道了server B已加入了集群。

addslots原理

cluster addslots {slot…slot}

将任意个空闲槽位加入到当前节点中。实现原理：

• 根据输入的slot集合，与clusterState.slots中拿出所有槽位进行比较（未用槽位指向null，已用槽位指向负责该槽位的节点），如果输入的slot集合中只要有一个槽位已使用，那么就给客户端一个报错响应；
• 如果输入的槽位都未使用，那么遍历输入的每一个槽位i，将clusterState.slots[i]指向当前节点，然后将当前节点的clusterNode.slot[i]数组中的值设置为1，表示为当前节点负责这个槽位。

其实通过上面的原理也能看得出来，为什么在clusterState和clusterNode中都会存放一个指向槽位的指针了。因为判断槽位是否可用以及当前槽位属于哪个节点就直接看clusterState.slot[i]是否指向null还是指向具体的clusterNode；如果看当前节点负责那些槽位，直接可以通过当前节点的clusterNode.slot来查询就可以。以上查询的时间复杂度都为o(1)。

MOVED错误

MOVED错误是在当前节点指向set或get等操作时，通过key计算出的hash槽不在当前节点上，服务器会重定向到正确的节点，也就是负责当前槽位的节点上，在执行客户端请求。当然这个客户端自动跳转是以集群方式开启客户端来说的，以单机模式开启客户端，那么客户端就直接返回给用户一个MOVED的error。

下面就是集群模式的客户端重定向的请求：

重新分片

上图很明确的描述了节点重新分片的流程，即将其他节点的槽位及槽位上的数据移至到另一个节点上。
1、通知源节点，将要把5343槽位导入到目标节点中；
2、通知目标节点，将要把5343槽位移除；
3、告知源节点要从5343槽位获取多少键值对；
4、将从源节点移除指定键值对到源节点；
5、通知集群中的其他节点，5343槽位已移动到目标节点中。

cluster setslot importing

cluster setslot slot importing source_node_id

当客户端向目标节点发送这个命令后，目标节点会将自身的存储结构clusterState.importing_slots_from属性设置为指向目标节点clusterNode的指针。

cluster setslot migrating

向目标节点发送cluster setslot slot migrating target_node_id，将告诉目标节点此槽位将要移除，这样目标节点将clusterState.migrating_slots_to属性值置为指向源节点的指针。

故障转移及选举流程

故障转移

当主节点下线后，从节点将对主节点进行故障转移：

• 发生故障的主节点里面会有一个从节点被选中；
• 被选中的从节点会成为新的从节点；
• 新的主节点会撤销已下线的主节点负责的槽位，然后将槽位指派给自己；
• 新的主节点会向集群中所有节点发送pong消息，告知所以节点原来的主节点已经下线，并且当前的节点成为新的主节点。
• 主节点开始正常接收客户端的请求。

选举流程

• 当从节点发现自己正复制的主节点下线后，会向集群中的所以节点发送一条广播；
• 接收到广播的有选举资格的主节点，并且该主节点没有投票给其他节点，会投票给这个从节点，即会发送一条消息给这个从节点；
• 该从节点接收到这个消息后，记录收到的消息总和，如果该节点被投票的票数大于节点总数的二分之一，那么就被选举为主节点；
• 因为集群中有纪元的概念，会保证在一个集群纪元中，保证一个主节点只有一次投票的权利。

最后

写了大半天，累了。如果本文对你有价值，哪怕一点点，请记得关注、点赞，有不足或疑问之处请留言。