redis——集群

柔光的暖阳◎ 2022-02-16 16:20 287阅读 0赞

### 本文转自 [https://www.jianshu.com/p/b35d778fa529][https_www.jianshu.com_p_b35d778fa529] 和[https://www.cnblogs.com/lykxqhh/p/5690923.html][https_www.cnblogs.com_lykxqhh_p_5690923.html] ###

# 一.  虚拟槽哈希分布 #

### **1.1  槽（slot）概念** ###

Redis Cluster中有一个16384长度的槽的概念，他们的编号为0、1、2、3……16382、16383。这个槽是一个虚拟的槽，并不是真正存在的。正常工作的时候，Redis Cluster中的每个Master节点都会负责一部分的槽，当有某个key被映射到某个Master负责的槽，那么这个Master负责为这个key提供服务，至于哪个Master节点负责哪个槽，这是可以由用户指定的，也可以在初始化的时候自动生成（redis-trib.rb脚本）。这里值得一提的是，在Redis Cluster中，只有Master才拥有槽的所有权，如果是某个Master的slave，这个slave只负责槽的使用，但是没有所有权。

## ##

### 1.2  数据分片 ###

在Redis Cluster中，拥有16384个slot，这个数是固定的，存储在Redis Cluster中的所有的键都会被映射到这些slot中。数据库中的每个键都属于这16384个哈希槽的其中一个，集群使用公式CRC16(key) % 16384来计算键key属于哪个槽，其中CRC16(key)语句用于计算键key的CRC16校验。集群中的每个节点负责处理一部分哈希槽。

## ##

### 1.3  节点的槽指派信息 ###

clusterNode结构的slots属性和numslot属性记录了节点负责处理那些槽：  
struct clusterNode \{  
//…  
unsignedchar slots\[16384/8\];  
\};  
Slots属性是一个二进制位数组(bit  
array)，这个数组的长度为16384/8=2048个字节，共包含16384个二进制位。  
Master节点用bit来标识对于某个槽自己是否拥有。比如对于编号为1的槽，Master只要判断序列的第二位（索引从0开始）是不是为1即可。时间复杂度为O（1）。

![Image 1][]

## ##

### 1.4  集群所有槽的指派信息 ###

通过将所有槽的指派信息保存在clusterState.slots数组里面，程序要检查槽i是否已经被指派，又或者取得负责处理槽i的节点，只需要访问clusterState.slots\[i\]的值即可，复杂度仅为O（1）。

![Image 1][]

## ##

### 1.5  请求重定向  ###

由于每个节点只负责部分slot，以及slot可能从一个节点迁移到另一节点，造成客户端有可能会向错误的节点发起请求。因此需要有一种机制来对其进行发现和修正，这就是请求重定向。有两种不同的重定向场景：  
a)MOVED错误  
1.请求的key对应的槽不在该节点上，节点将查看自身内部所保存的哈希槽到节点ID的映射记录， 节点回复一个MOVED错误。  
2.需要客户端进行再次重试。

![Image 1][]

b)ASK错误  
1.请求的key对应的槽目前的状态属于MIGRATING状态，并且当前节点找不到这个key了，节点回 复ASK错误。ASK会把对应槽的IMPORTING节点返回给你，告诉你去IMPORTING的节点尝试找找。  
2.客户端进行重试首先发送ASKING命令，节点将为客户端设置一个一次性的标志（flag），使得 客户端可以执行一次针对IMPORTING状态的槽的命令请求，然后再发送真正的命令请求。  
3.不必更新客户端所记录的槽至节点的映射。

# 二  基本架构 #

Redis集群搭建的方式有多种，例如使用zookeeper等，但从redis 3.0之后版本支持redis-cluster集群，Redis-Cluster采用无中心结构，每个节点保存数据和整个集群状态,每个节点都和其他所有 节点连接。其redis-cluster架构图如下：

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM2NTgyNjA0_size_16_color_FFFFFF_t_70][]

其结构特点：

1.  所有的redis节点彼此互联(PING-PONG机制),内部使用二进制协议优化传输速度和带宽。
2.  节点的fail是通过集群中超过半数的节点检测失效时才生效
3.  客户端与redis节点直连,不需要中间proxy层.客户端不需要连接集群所有节点,连接集群中任何一个可用节点即可。
4.  redis-cluster把所有的物理节点映射到\[0-16383\]slot上（不一定是平均分配）,cluster 负责维护node<->slot<->value。       
5.  Redis集群预分好16384个桶，当需要在 Redis 集群中放置一个 key-value 时，根据 CRC16(key) mod 16384的值，决定将一个key放到哪个桶中。

## ##

### redis cluster节点分配 ###

现在我们是三个主节点分别是：A, B, C 三个节点，它们可以是一台机器上的三个端口，也可以是三台不同的服务器。那么，采用哈希槽 (hash slot)的方式来分配16384个slot 的话，它们三个节点分别承担的slot 区间是：  
  
       节点A覆盖0－5460;  
       节点B覆盖5461－10922;  
       节点C覆盖10923－16383.

获取数据：

如果存入一个值，按照redis cluster哈希槽的算法： CRC16('key')%16384 = 6782。 那么就会把这个key 的存储分配到 B 上了。同样，当我连接(A,B,C)任何一个节点想获取'key'这个key时，也会这样的算法，然后内部跳转到B节点上获取数据

新增一个主节点：

新增一个节点D，redis cluster的这种做法是从各个节点的前面各拿取一部分slot到D上，我会在接下来的实践中实验。大致就会变成这样：

节点A覆盖1365-5460  
       节点B覆盖6827-10922  
       节点C覆盖12288-16383  
       节点D覆盖0-1364,5461-6826,10923-12287

同样删除一个节点也是类似，移动完成后就可以删除这个节点了。

# 三  安装 #

集群的安装分为两种，一种是原生命令的安装，还有一种是官方工具的安装

原生命令的安装分为下面几步：

1.  配置开启节点
2.  meet
3.  指派槽
4.  设置主从

但是原生命令安装在生产环境中是不使用的，因为麻烦，容易犯错。一般都是使用官方工具来进行安装，这样更高效，准确。

我们先准备Ruby环境准备，一共有如下三步骤：

1.  下载、编译、安装Ruby
2.  安装rubygem redis
3.  安装redis-trib.rb

具体命令如下：

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM2NTgyNjA0_size_16_color_FFFFFF_t_70 1][]

然后我们再搭建集群

具体步骤就不写了，大家可以去看：

[https://www.cnblogs.com/lykxqhh/p/5690923.html][https_www.cnblogs.com_lykxqhh_p_5690923.html]

[https_www.jianshu.com_p_b35d778fa529]: https://www.jianshu.com/p/b35d778fa529
[https_www.cnblogs.com_lykxqhh_p_5690923.html]: https://www.cnblogs.com/lykxqhh/p/5690923.html
[Image 1]: 
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM2NTgyNjA0_size_16_color_FFFFFF_t_70]: /images/20220216/bb2b9d26d8ee459998e613ca95aa9e15.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM2NTgyNjA0_size_16_color_FFFFFF_t_70 1]: /images/20220216/cf9895fcec8f4d5bbc679dd6a5ffd142.png