redis：cluster

朴灿烈づ我的快乐病毒、 2022-09-15 00:07 120阅读 0赞

> redis cluster是redis作者自己提供的集群化方案

与codis有所不同，redis cluster是去中心化的，如下图

*  该集群有三个redis节点组成，每个节点负责整个集群的一部分数据，每个节点负责的数据多少可能不一样。
 *  这三个节点相互连接组成一个对等的集群，它们之间通过一种特殊的二进制协议交互集群信息

![在这里插入图片描述][watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBAT2NlYW4mJlN0YXI_size_18_color_FFFFFF_t_70_g_se_x_16]

*  redis cluster将所有数据划分为16384个槽位，它比codis的1024个槽位划分更加精细，每个节点负责其中一部分槽位。
 *  槽位的信息存储在每个节点中，它不像codis，不需要另外的分布式存储空间来存储节点槽位信息
 *  当redis cluster的客户端来连接集群时，也会得到一份集群的槽位配置信息。这样当客户端需要查找某个key时，可以直接定位到目标节点。
 *  这一点不同于codis，codis需要通过proxy来定位目标节点，redis cluster则直接定位
 *  客户端为了可以直接定位某个具体的key所在的节点，需要**缓存槽位相关信息**，这样才可以准确快速的定位到相应的节点。
 *  同时因为可能会存在客户端与服务端存储槽位的信息不一致的情况，还需要**纠正机制**来实现槽位信息的校验调整

另外，redis cluster的每个节点会将集群的配置信息持久化到配置文件中，所以必须确保配置文件是可写的，而且尽量不要依靠人工修改配置文件

# 槽位定位算法 #

*  redis cluster默认会对key值使用crc16算法来进行hash，得到一个整数值，然后用这个整数值对16384进行取模来得到具体槽位
 *  redis cluster还允许用户强制把某个key挂在特定槽位上。通过在key字符串里面嵌入tag标记，这就可以强制key所挂的槽位等于tag所在的槽位。

![在这里插入图片描述][watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBAT2NlYW4mJlN0YXI_size_12_color_FFFFFF_t_70_g_se_x_16]

# 跳转 #

当客户端向一个错误的节点发出了指令之后，该节点会发现指令的key所在的槽位并不归自己管理，这时它会向客户端发送一个特殊的跳转指令携带目标操作的节点地址，告诉客户端去连接这个节点以获取数据

![在这里插入图片描述][cc76db16f5df4a56be12fd1d14451b55.png]

*  MOVED指令的第一个参数3999是key对应的槽位编号，后面是目标节点地址。MOVED指令前面有一个减号，表示该指令是一个错误信息
 *  客户端在收到MOVED指令之后，要立即纠正本地的槽位映射表。后继所有的key将使用新的槽位映射表。

# 迁移 #

redis cluster提供了工具redis-trib可以让运维人员手动调整槽位的分配情况，它使用ruby语言开发，通过组合各种原生的redis cluster指令来实现。这一点codis做的更加人性化，它不但提供了UI界面可以让我们方便的迁移，还提供了自动化平衡槽位工具，无需人工干预就可以均衡集群负载。不过redis官方向来的策略就是提供最小可用的工具，其他交给社区完成。

接下来我们看看redis cluster的数据迁移过程

*  redis迁移的单位是槽，redis一个槽一个槽的进行迁移，当一个槽正在迁移时，这个槽就处于中间过渡状态。如下图，这个槽在源节点的状态为migrating，在目标节点的状态为importing，表示数据正从源节点流向目标节点

![在这里插入图片描述][watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBAT2NlYW4mJlN0YXI_size_18_color_FFFFFF_t_70_g_se_x_16 1]

*  迁移工具redis-trib首先会在源节点和目标节点设置好中间过渡状态，然后一次性获取源节点槽位的所有key列表（`keysinslot`指令，可以部分获取），再挨个key进行迁移
 *  每个key的迁移过程是以源节点作为目标节点的“客户端”，源节点对当前的key执行`dump`指令获得序列化内容，然后通过“客户端”向目标节点发送restore指令携带序列化的内容作为参数，目标节点再进行反序列化就可以将内容恢复到目标节点的内存中，然后返回“客户端”OK，源节点“客户端”收到后再把当前节点的key删除掉就完成了单个key迁移的全过程

大致流程如下：从源节点获取内容—>存到目标节点—> 从源节点删除内容

注意这里的迁移过程是同步的，在目标节点执行restore指令到源节点删除key之间，源节点的主线程会处于阻塞状态，直到key被成功删除。

如果迁移过程中突然出现了网络故障，整个槽的迁移只进行了一半，这时两个节点依然处于中间过渡状态，待下次迁移工具重新连上时，会提示用户继续进行迁移。

在迁移过程中，如果每个key的内容都很小，migrate指令会执行的很快，它就不会影响客户端的正常访问。如果key的内容很大，因为migrate指令是阻塞指令，会同时导致源节点和目标节点卡顿，影响集群的稳定性。所以在集群环境下，业务立即要尽可能避免产生很大的key。

在迁移过程中，客户端访问的流程会有很大的变化

*  首先新旧两个节点对应的槽位都存在部分key数据
 *  客户端先尝试访问旧节点，如果对应的数据还在旧节点里面，那么旧节点正常处理
 *  如果对应的数据不在旧节点里面，那么有两种可能，要么该数据在新节点里，要么根本不存在
 *  旧节点不知道是哪种情况，所以它会向客户端返回一个`-ASK targetNodeAddr`的重定向指令。
 *  客户端收到这个重定向指令之后，先去目标节点执行一个不带任何参数的`ASKING`指令，然后在目标节点在重新执行原先的操作指令

为什么需要执行一个不带参数的`ASKING`指令呢？

*  因为在迁移没有完成之前，按理来说这个槽位还是不归新节点管理的，如果这个时候向目标节点发送该槽位的指令，节点是不认的，它会向客户端返回一个`-MOVED`重定向指令告诉它去源节点去执行。如此就会形成“重定向循环”
 *  `ASKING`指令的目标就是打开目标节点的选项，告诉它下一条指令不能不理，而要当成自己的槽位来处理

# 容错 #

**redis cluster可以为每个主节点设置若干个从节点，当主节点发生故障时，集群会自动将其中某个从节点提升为主节点**。

如果某个主节点没有从节点，那么当它发生故障时，集群将完全处于不可用状态。

不过redis也提供了一个参数cluster-require-full-coverage可以允许部分节点发生故障，其他节点还可以继续提供对外访问。

# 网络抖动 #

网络抖动：突然之间部分连接变得不可访问，然后很快又恢复正常

*  为解决这个问题，redis cluster提供了一种选项`cluster-node-timeout`，表示当某个节点持续timeout的时间失联时，才可以认定该节点出现故障，需要进行主从切换。如果没有这个选项，网络抖动会导致主从频繁切换（数据的重新复制）
 *  还有另外一个选项`cluster-slave-validity-factor`作为倍乘系数放大这个超时时间来宽松容错的紧急程度。如果这个系统为0，那么主从切换时不会抗拒网络抖动的。如果这个系数大于1，它就成了主从切换的松弛系数。

# 可能下线(PFail)与确定下线(Fail) #

因为redis cluster是去中心化的，一个节点认为某个节点失联了并不代表所有的节点都认为它失联了，所以集群还得经过一次协商的过程，只有当大多数节点都认定某个节点失联了，集群才认为该节点需要进行主从切换来容错

redis集群节点采用`gossip`协议来广播自己的状态以及改变对整个集群的认知。

*  如果一个节点发送某个节点失联了（Possibly Fail），它会将这条信息向整个集群广播，其他节点就可以收到这点的失联信息
 *  如果收到了某个节点失联的节点数量（PFail Count）已经达到了集群的大多数，就可以标记该失联节点为确定下线状态（Fail）
 *  然后向整个集群广播，强迫其他节点也接受该节点已经下线的事实，并立即对该失联节点进行主从切换

# 槽位迁移感知 #

如果cluster中某个槽位正在迁移或者已经迁移完毕，那么客户端如何能感知到槽位的变化呢？**客户端保存了槽位和节点的映射关系表，它需要及时得到更新，才可以正常的将某条消息发到正确的节点中**

cluster有两个特殊的error指令：

*  MOVED指令：用来纠正槽位
    
     *  如果我们将指令发送到来错误的节点，该节点发现对应的指令槽位不归自己管理，就会将目标节点的地址随同`MOVED`指令回复给客户端通过客户端去目标节点访问
     *  这个时候**客户端会刷新自己的槽位关系表，然后重试指令，后继所有打在该槽位的指令都会转移到目标节点**
 *  `ASKING`指令：用来临时纠正槽位
    
     *  如果当前槽位正处于迁移中，指令会被先发送到槽位所在的旧节点
     *  如果旧节点存在数据，就直接返回结果
     *  如果旧节点不存在数据，那么数据可能真的不存在，也可能在迁移目标上
        
         *  所以旧节点会通知客户端去新节点尝试拿数据，看新节点有没有
         *  这时候就会给客户端返回一个asking error携带上目标节点的地址
         *  客户端收到这个asking error之后，就去目标节点尝试。
         *  **客户端不会刷新槽位映射关系表，因为它只是临时纠正该指令的槽位信息，不影响后继指令**

# 集群变更感知 #

当服务器节点变更时，客户端应该立即得到通知以实时刷新自己的节点关系表。那么客户端是如何得到通知的呢？这里分两种情况

*  目标节点挂了
    
     *  客户端会抛出一个`ConnetionError`，紧接着会随机挑一个节点来重试
     *  这时被重试的节点会通过MOVED指令告知目标槽位被分配到新的节点地址
 *  运维手动修改了集群信息，将主节点切换到其他节点，并将旧的主节点移除出集群
    
     *  这时打在旧的主节点上的指令会收到一个ClusterDown的错误，告知当前节点所在集群不可用（当前节点已经被孤立了，它不再属于之前的集群）
     *  这时客户端会关闭所有的连接，清空槽位映射关系表，然后向上层抛错。
     *  待下一条指令过来时，就会尝试初始化节点信息

[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBAT2NlYW4mJlN0YXI_size_18_color_FFFFFF_t_70_g_se_x_16]: /images/20220828/a891a03c2e7b4fc29751d7c86ff702ab.png
[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBAT2NlYW4mJlN0YXI_size_12_color_FFFFFF_t_70_g_se_x_16]: /images/20220828/1be58643192a4f8182d66cd2f1fb5a55.png
[cc76db16f5df4a56be12fd1d14451b55.png]: /images/20220828/63822462bf934384923209d3cbd1cbfa.png
[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBAT2NlYW4mJlN0YXI_size_18_color_FFFFFF_t_70_g_se_x_16 1]: /images/20220828/a4668113c89f463ebb698cd2efe07448.png