RedisCluster

        Redis集群是Redis提供分布式数据库方案，集群通过分片(sharding)来进行数据共享，并提供复制和故障转移功能。

 

节点

        一个Redis集群通常由多个节点(node)组成，在刚开始的时候，每个节点都是互相独立的，他们都处于一个只包含自己的集群当中，要组建一个真正可工作的集群，必须将各个独立的节点连接起来，构成一个包含多个节点的集群。

         连接各个节点的工作可以使用CLUSTER MEET命令来完成：CLUSTER MEET $IP $PORT

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

        下面将三个独立节点组建一个集群，127.0.0.1:7000~7002，在节点7000通过发送CLUSTER NODES命令可以看到只有一个节点，然后添加7001和7002到集群里。

7000>CLUSTER NODES
7000>CLUSTER MEET 127.0.0.1 7001
7000>CLUSTER NODES
7000>CLUSTER MEET 127.0.0.1 7002
7000>CLUSTER NODES

        一个节点就是一个运行在集群模式下的Redis服务器，Redis服务器在启动时会根据cluster-enabled配置选项是否为yes来决定是否开启服务器的集群模式。

        clusterNode结构保存了一个节点的当前状态，比如节点的创建时间，节点的名字，节点当前配置的纪元，节点的IP地址和端口等信息。

         每个节点都会使用一个clusterNode结构来记录自己的状态，并为集群中的所有其他节点（包括主节点和从节点）都创建一个相应的clusterNode结构，以此来记录其他节点状态。

        通过CLUSTER MEET命令，节点握手的过程：

• 将节点A与节点B进行握手(handshake),以此来确认彼此的存在。
• 节点A会为节点B创建一个clusterNode结构，并将该结构添加到自己的clusterState.nodes字典里面。
  
• 节点A根据CLUSTER MEET命令给定的IP地址和端口，向B节点发送一条MEET消息
• 如果一切顺利，节点B将收到A发送的MEET消息，节点B会为节点A创建一个clusterNode结构，并将该结构添加到自己的clusterState.nodes字典里面
• 节点B将向A返回一条PONG消息。
• 节点A将收到节点B返回的PONG消息，通过PONG消息节点A可以知道节点B已经成功的接收到自己发送的MEET消息
• 节点A将向节点B返回一条PING消息
• 节点B将接收到节点A返回的PING消息，通过这条PING消息节点B可以知道节点A已经成功地接收到了自己返回的PONG消息，握手完成
• 节点A会将节点B的信息通过gossip协议传播给集群中的其他节点，让其他节点与B进行握手，最终经过一段时间后，节点B会被集群中所有节点认识

槽指派

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

         当数据库中的16384个槽都有节点处理时，集群处于上线状态，如果任何一个槽没有得到处理，那么集群处于下线状态。通过CLUSTER MEET将7000~7002连接到一个集群中，不过这个集群仍然是下线状态，因为没有处理任何槽。通过CLUSTER ADDSLOTS命令，我们可以将一个或多个槽指派给节点。

 

7000>CLUSTER INFO
7000>CLUSTER ADDSLOTS 0 1 2 3 4 ... 5000
7000>CLUSTER NODES
7001>CLUSTER ADDSLOTS 5001 ... 10000
7002>CLUSTER ADDSLOTS 10000 ... 16383
7000>CLUSTER INFO

       clusterNode结构的slots属性和numslot属性保存槽信息，slots是一个二进制数组，一个节点除了将自己负责处理的槽记录在clusterNode结构中之外，它还会将自己的slots数据通过消息发送给集群中的其他节点，以此来告知其他节点自己目前负责那些槽。

 

命令执行

        在对数据库中的16384个槽都进行了指派之后，集群就会进入上线状态，这时客户端就可以向集群中的节点发送数据命令了。

        当客户端节点发送与数据库键有关的命令时，接收命令的节点会计算出命令要处理的数据键属于哪个槽，并检查这个槽是否指派给了自己：

• 如果键所在的槽正好在当前节点，那么节点直接执行这个命令
• 如果键所在的槽不再当前节点，那么会向客户端返回一个MOVED错误，指引客户端转向(redirect)正确的节点，并再次发送要执行的命令。

       计算key属于哪个槽

CLUSTER KEYSLOT "stevenDing"

       MOVED错误的格式

  

MOVED $slot  $ip:port

     单机的redis-cli会直接将MOVED错误输出，集群模式redis-cli会直接向目标地址请求。

 

重新分片

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

        目前有7000~7002三个节点的集群，增加一个7003节点，将15001-16383槽指派给7003节点。

 

7000>CLUSTER NODES
7003>CLUSTER ADDSLOTS 15001-16383
7000>CLUSTER NODES

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

 

• redis-trib对目标节点发送CLUSTER SETSLOT <slot> IMPORTING <source_id>命令，让目标节点准备好从源节点导入(import)属于槽slot的键值对。
• redis-trib对源节点发送CLUSTER SETLOT <slot> MIGRATING <target_id>命令，让源节点准备好将属于槽slot的键值对迁移(migrate)至目标节点。
• redis-trib向源节点发送CLUSTER GETKEYSINSLOT <slot> <count>命令，获得最多count个属于槽slot的键值对的键名（key name）。
• 对于步骤3获得的每个键名，redis-trib都向源节点发送一个MIGRATE <target_ip> <target_port> <key_name> 0 <timeout>命令，将被选中的键原子的从源节点迁移至目标节点。
• 重复执行步骤3和步骤4，直到源节点保存的所有属于槽slot的键值都被迁移至目标节点为止，迁移过程见下图。
• redis-trib向集群中的任意一个几点发送CLUSTER SETSLOT <slot> NODE <target_id>命令，将槽slot指派给目标节点，这一指派信息会通过消息发送至整个集群，最终集群中所有节点都会知道槽slot已经指派给了目标节点。

 

ASK错误

     在进行充分片期间，源节点向目标节点迁移一个槽的过程中，可能会出现这样一种情况，属于被迁移槽的一部分键值对保存在源节点里面，而另一部分保存在目标节点里面。当客户端向源节点发送一个与数据库键有关的命令，并且命令要处理的数据库敲好就属于正在被迁移的槽时：

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

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

 

ASKING命令

      ASKING命令唯一要做的就是打开发送命令的客户端的REDIS_ASKING标识符，在一般情况下，如果客户端向节点发送一个关于槽i的命令，而槽i有没有指派给这个节点的话，那么将向客户端返回一个MOVED错误，如果节点显示正在导入i槽，并且发送命令的客户端带有REDIS_ASKING标识，那么节点将破例执行一次关于槽i的命令一次。

 

ASK错误和MOVED错误的区别

• MOVED错误代表槽的负责权已经从一个节点转移到了另一个节点：在客户端收到关于槽i的MOVED错误之后，客户端每次遇到关于槽i的命令请求时，都可以直接将命令请求发送至MOVED错误所指向的节点，因为该节点就是目前负责槽i的节点。
• ASK错误是两个节点在迁移槽的过程中使用的一种临时措施：在客户端收到关于槽i的ASK错误之后，客户端只会在接下来的一次命令请求中将关于槽i的命令请求发送至ASK错误所指示的节点，但这种转向不会对客户端今后发送的关于槽i的命令请求产生任何影响，客户端仍然会将关于槽i的命令请求发送至目前负责处理槽i的几点，除非ASK错误再次出现。

 

故障转移

 

 

消息