Redis集群

前言

如果你想快速搭建集群，百度中有大量的新手资料。本博客主要介绍集群的底层实现细节，比较枯燥，还请读者细品、仔细品。

RedisCluster

集群是Redis分布式数据库的解决方案，具备高可用、高性能的特点，在生产中得到了广泛的应用。

1.搭建集群

一个Redis集群通常由多个节点(node)组成，所以我们首先要启动节点并将多个节点连接起来组成一个集群。

1.1 启动节点

Redis服务器会在启动时检查配置文件(redis.conf)中的cluster-enable配置项值来决定是否开启集群模式，流程如下：

集群模式：集群模式会继续使用单机模式下的一些组件

• 节点继续使用文件事件处理器来处理和返回命令
• 节点继续使用时间处理器，在时间处理器中调用集群特有的函数(向其他节点发送gossip协议、检查节点是否下线等）
• 继续使用数据库来保存键值对
• 继续使用RDB和AOF来持久化
• 继续使用复制模块来进行复制工作

1.2 连接节点

我们可以通过cluster meet 命令，让服务器节点与指定节点握手，握手成功后，就会将ip和port指定的节点加入到当前集群中，如下图：

cluster meet <ip> <port>

1.2.1 cluster meet命令的实现

客户端 ->cluster meet B ->A -->hadle ->B
①：节点A为节点B创建一个ClusterNode结构，并添加到ClusterState. nodes中。
②：节点A根据指定的Ip和端口向节点B发送一条meet消息
③：节点B收到后，会为节点A创建一个ClusterNode结构，并添加到自己ClusterStates.nodes中
④： 节点B向节点A发送一条Pong消息
⑤： 节点A收到后，就确定B已经收到meet消息
⑥： 节点A向节点B发送一条Ping消息
⑦： 节点B收到A的Ping消息，就确定A已经收到了自己Pong消息，握手完成。

1.3 槽指派

集群的整个数据库被分为16384个槽，每个节点都可以处理0个或者最多16384个槽。我们可以通过cluster addslots 命令，将一个或者多个槽指派给指定节点负责。

  cluster addslots <slot> [slot ...]

1.3.1 记录节点的槽指派信息

节点负责的槽位信息该如何去保存呢？二进制位数组，每一位记录一个槽的指派信息，如果对应位为1，则代表当前节点负责该槽位。

public class ClusterNode {
    //..........
    /**
     * 二进制位数组，保存该节点负责的槽位信息
     * 如果二进制为1,则代表该节点负责该槽位
     */
    char[] slots;
    /**
     *  节点负责处理槽的数量
     */
    int numslots;
}

• slots：二进制位数组，包含16384个二进制位
  
• numslots: 记录节点负责的槽的数量

1.3.2 传播节点的槽指派信息

如何将自己负责的槽位信息告诉其它节点呢？将二进制位数组（slots)发送给其他节点。
节点A通过消息从节点B那接收到节点B的slots数组时，节点A在自己的ClusterState.nodes字典中找到节点B对应的ClusterNode结构，并对结构中的slots数组进行保存或者更新。

1.3.3 记录集群所有槽的指派信息

ClusterNode.slots只记录自己负责槽位的信息，那么如何保存整个集群的槽信息呢？ClusterNode数组
ClusterNodes.slots: 自己负责的槽位信息
ClusterState.slots:整个集群的槽位信息

	class ClusterState {
	    /**
	     * 记录槽的指派信息，大小16384
	     */
	    ClusterNode[] slots;
	}

1.3.4 addSlots的实现

清楚如何保存槽位信息，那么addslots命令的实现呢？更新ClusterNodes.slots和ClusterState.slots，然后将更新结果通知给其他节点。

2.集群

集群启动后，当我们发生一条命令时，集群是怎样执行的呢？先根据key找到对应的槽位，再找到负责槽位的机器

2.1 集群命令

2.1.1 计算槽位

Redis采用CRC16算法来计算key对应的槽位，我们可以通过cluster keyslot key 命令来查看key对应的槽位信息。

	cluster keysolt key

2.1.2 判断槽位是否由当前节点负责

检查ClusterState.slots[i]是否等于ClusterState.myself,如果等于，则说明槽i由当前节点负责，执行命令；如果不等于，Redis会返货MOVED错误。

2.1.3 Moved错误

当节点发现键所在的槽位不由自己负责时，就会给客户端返回一个MOVED错误。在集群模式下，MOVED错误会被隐藏。

redis-cli -h -p  //单机模式
redis-cli -c -h -p //集群模式

2.2 节点数据库

集群模式下，节点只能使用0号数据库，而单机模式下没有这一限制。

2.2.1 槽&键

Redis节点会用跳跃表来保存槽和键之间的关系，跳跃表中每个节点的分值代表槽号，key对应数据库键。通过跳跃链表，我们可以很方便的返回某个槽对应的数据库键，这就是cluster getkeyinslot 命令实现的原理。

cluster getkeyinslot <slot> <count> //返回最多count个属于槽slot的数据库键

2.3 重新分片

有时候我们需要进行数据重分片，将已经指派给某个节点的槽改为指派给另一个节点。

2.3.1 重分片原理

Redis集群重分片是由redis-trib负责管理执行的，其执行过如下：
①：向目标节点发送Cluster setslot importing <source_id>命令，让目标节点准备从源节点导入属于槽slot的键值对
②：向源节点发送Cluster setslot migrate <target_id>命令，让源节点准备将属于槽slot的数据迁移之目标节点
③：向源节点发送Cluster getkeyinslot 命令，获取属于槽slot的键值对
④： 对于步骤3获得的每个键，redis-trib向源节点发送一个migrate <target_ip> <target_port> <key_name> 0 <time_out>命令，将键原子的从源节点迁移至目标节点
⑤：重复执行步骤3和步骤4，直到源节点保存的所有属于槽slot的键值对都被迁移至目标节点
⑥：将槽迁移的信息通知给集群中任意一节点，最后整个集群都会知道。

2.3.2 setslot importing

如何记录槽的迁移信息呢？每个节点提供一个迁移节点数组和一个导入节点数组。发送setslot importing的作用就是将目标节点的ClusterState.importingSlotFrom[slot]设置为源节点的ClusterNode;

 class ClusterState {
       /**
        * 当前节点正从其他节点导入的槽,大小16384
        * importingSlotFrom[slot] !=null:当前正从importingSlotFrom[slot]                          导入槽slot的数据
        */
      ClusterNode[] importingSlotFrom;
}

2.3.3 setslot migrating

Redis的migratingSlotTo记录了当前节点迁移到其他节点的信息。

 class ClusterState {
  /**
   * 当前节点正迁至其他节点的槽，大小16384
   *  migratingSlotTo[slot] !=null:当前节点正将槽[slot]迁移至 importingSlotFrom[slot]对应的节点
   */
   ClusterNode[] migratingSlotTo;
}

2.3.4 重分片过程

2.4 ASK错误

在槽迁移过程中，一部分键保存在源节点中、一部分键保存在目标节点中。此时可能客户端请求处理的key正在迁移中,如果该key已经被迁移，那么服务器将会向客户端返回一个ASK错误。如果key还未被迁移，则直接执行命令。

2.4.1 Asking命令

当客户端请求的key正在被迁移且已经迁移至目标节点时，已经通过ASK错误，获取到目标节点的信息，为什么不直接执行命令而是先执行一个ASK命令？ 因为这个槽还不归目标节点负责，此时直接请求，会返回Moved异常。
ASKING命令的作用：打开客户端REDIS_ASKING标识
REDIS_ASKING标识作用：通常情况下如果该节点不负责该槽位，会直接返回Moved异常；但是如果该节点的migratingSlotTo显示该槽正在迁移且客户端打开了REDIS_ASKING标识，则会破例执行一,这个标识会在执行命令后移除。

2.4.2 ASK VS Moved

• Moved代表该槽的负责权不在当前节点，客户端在接收到关于槽的Moved错误之后，客户端之后遇到关于该槽的命令请求时，都可以将命令请求发送至Moved错误指向的节点。
• ASK错误只是两个节点在迁移槽时的临时措施，客户端在收到某个槽的ASK错误后，只会将下次该槽的请求转发到对应的节点，而不会对该槽之后的请求造成影响。