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槽是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槽的过程：
客户端在server A上执行meet操作，希望将server B加入到集群中：
cluster addslots {slot…slot}
将任意个空闲槽位加入到当前节点中。实现原理：
其实通过上面的原理也能看得出来，为什么在clusterState和clusterNode中都会存放一个指向槽位的指针了。因为判断槽位是否可用以及当前槽位属于哪个节点就直接看clusterState.slot[i]是否指向null还是指向具体的clusterNode；如果看当前节点负责那些槽位，直接可以通过当前节点的clusterNode.slot来查询就可以。以上查询的时间复杂度都为o(1)。
MOVED错误是在当前节点指向set或get等操作时，通过key计算出的hash槽不在当前节点上，服务器会重定向到正确的节点，也就是负责当前槽位的节点上，在执行客户端请求。当然这个客户端自动跳转是以集群方式开启客户端来说的，以单机模式开启客户端，那么客户端就直接返回给用户一个MOVED的error。
下面就是集群模式的客户端重定向的请求：
上图很明确的描述了节点重新分片的流程，即将其他节点的槽位及槽位上的数据移至到另一个节点上。
1、通知源节点，将要把5343槽位导入到目标节点中；
2、通知目标节点，将要把5343槽位移除；
3、告知源节点要从5343槽位获取多少键值对；
4、将从源节点移除指定键值对到源节点；
5、通知集群中的其他节点，5343槽位已移动到目标节点中。
cluster setslot slot importing source_node_id
当客户端向目标节点发送这个命令后，目标节点会将自身的存储结构clusterState.importing_slots_from属性设置为指向目标节点clusterNode的指针。
向目标节点发送cluster setslot slot migrating target_node_id，将告诉目标节点此槽位将要移除，这样目标节点将clusterState.migrating_slots_to属性值置为指向源节点的指针。
当主节点下线后，从节点将对主节点进行故障转移：
写了大半天，累了。如果本文对你有价值，哪怕一点点，请记得关注、点赞，有不足或疑问之处请留言。
