【Redis】集群

---

以下是本篇文章正文内容

一、集群是什么？

• 由于数据量过大，单个Master复制集难以承担，因此需要对多个复制集进行集群，形成水平扩展每个复制集只负责存储整个数据集的一部分，这就是Redis的集群，其作用是提供在多个Redis节点间共享数据的程序集。

Redis集群是一个提供在多个Redis节点间共享数据的程序集

• Redis集群可以支持多个Master

• Redis集群支持多个Master，每个Master又可以挂载多个Slave
• 读写分离
• 支持海量数据的高可用
• 支持海量数据的读写存储操作
• 由于Cluster自带Sentinel的故障转移机制，内置了高可用的支持，无需再去使用哨兵功能
• 客户端和Redis的节点连接，不再需要连接集群中所有节点，只需连接集群中的任意一个可用节点即可
• 槽位slot负责分配到各个物理服务节点，由对应的集群来负责维护节点、插槽和数据之间的关系
• redis集群不保证强一致性，这意味着在特定的条件下，Redis集群可能会丢掉一些被系统收到的写入请求命令

二、 Redis集群分布式存储

槽位
集群的密钥空间被分成16384个槽，有效地设置了16384个主节点的集群大小上限(但是，建议的最大节点大小约为1000个节点)。
Redis集群投有使用一致性hash，而是引入了哈希槽的概念.
Redis集群有16384个哈希槽，每个key通过CRC16校验后对16384取模来决定放置哪个槽。
集群的每个节点（master）负责一部分hash槽。

比如，有一个集群有三个节点：

分片
使用Redis集群时我们会将存储的数据分散到多台redis机器上，这称为分片。简言之，集群中的每个Redis实例都被认为是整个数据的一个分片。

如何找到给定key的分片：为了找到给定key的分片，我们对key进行CRC16(key)算法处理并通过对总分片数量取模。然后，使用确定性哈希函数，这意味着给定的key将多次始终映射到同一个分片，我们可以推断将来读取特定key的位置。

Redis集群分布式存储有大概有3种解决方法

哈希取余分区

hash(key) % N个机器台数，计算出哈希值，用来决定数据映射到哪一个节点上。
优点：

• 简单粗暴，直接有效，只需要预估好数据规划节点例如3台、8台、10台，就能保证一段时间的数据支撑。使用Hash算法让固定的一部分请求落到同一台服务器上，这样每台服务器固定处理一部分请求（并维护这些请求的信息），起到负载均衡+分而治之的作用。

缺点：

• 直接规划好节点，进行扩容或者缩容会很麻烦，不管扩还是缩，每次数据变动会导致节点有变动，映射关系都要重新计算，在服务器个数固定不变时没有问题。
• 如果需要弹性扩容或故障停机的情况下，原来的取模公式就会发生变化，Hash(key)/3会变成Hash(key) /?。
• 此时地址经过取余运算的结果将发生很大变化，根据公式获取的服务器也会变得不可控。

一致性哈希算法分区

为了解决分布式缓存数据变动和映射问题，某个机器宕机了，分母数量改变了，自然取余数不行了。
目的是当服务器个数发生变动时，尽量减少影响客户端到服务器的映射关系

算法步骤：

哈希槽分区

• 哈希槽实质就是一个数组，数组[0,2^14 -1]形成hash slot空间。

解决均匀分配的问题，在数据和节点之间又加入了一层，把这层称为哈希槽（slot），用于管理数据和节点之间的关系（即解决映射问题），现在就相当于节点上放的是槽，槽里放的是数据。

一个集群只能有16384个槽，编号0-16383（0-2^14-1）。这些槽会分配给集群中的所有主节点，分配策略没有要求。

接下来就需要对key求哈希值，然后对16384取模，余数是几key就落入对应的槽里。集群会记录节点和槽的对应关系。
HASH_SLOT = CRC16(key) mod 16384。
以槽为单位移动数据，因为槽的数目是固定的，处理起来比较容易，这样数据移动问题就解决了。

写入的总体流程：当需要在 Redis 集群中放置一个 key-value时，redis先对key使用crc16算法算出一个结果然后用结果对16384求余数[ CRC16(key) % 16384]，这样每个 key 都会对应一个编号在 0-16383 之间的哈希槽，也就是映射到某个节点上。

为什么redis集群的最大槽数是16384（不太懂）

Redis集群并没有使用一致性hash而是引入了哈希槽的概念。Redis 集群有16384个哈希槽，每个key通过CRC16校验后对16384取模来决定放置哪个槽，集群的每个节点负责一部分hash槽。

正常的心跳数据包带有节点的完整配置，可以用幂等方式用旧的节点替换旧节点，以便更新旧的配置。这意味着它们包含原始节点的插槽配置，该节点使用2k的空间和16k的插槽，但是会使用8k的空间（使用65k的插槽）。同时，由于其他设计折衷，Redis集群不太可能扩展到1000个以上的主节点。因此16k处于正确的范围内，以确保每个主机具有足够的插槽，最多可容纳1000个矩阵，但数量足够少，可以轻松地将插槽配置作为原始位图传播。请注意，在小型群集中，位图将难以压缩，因为当N较小时，位图将设置的slot / N位占设置位的很大百分比。

redis的集群主节点数量基本不可能超过1000个

集群节点越多，心跳包的消息体内携带的数据越多。如果节点过1000个，也会导致网络拥堵。因此redis作者不建议redis cluster节点数量超过1000个。 那么，对于节点数在1000以内的redis cluster集群，16384个槽位够用了。没有必要拓展到65536个。

三、 配置集群（三主三从）

Redis集群为什么至少需要三个master节点？
因为新master的选举需要大于半数的集群master节点同意才能选举成功，如果只有两个master节点，当其中一个挂了，是达不到选举新master的条件的。

Redis集群为什么推荐节点数为奇数？
奇数个master节点可以在满足选举该条件的基础上节省一个节点，比如三个master节点和四个master节点的集群相比，大家如果都挂了一个master节点都能选举新master节点，如果都挂了两个master节点都没法选举新master节点了，所以奇数的master节点更多的是从节省机器资源角度出发说的。

3.1 配置config文件

本案例的配置是在一台虚拟机的6个端口分别配置了6个redis服务器

• 端口 6381

vim /myredis/cluster/redisCluster6381.conf

bind 0.0.0.0
daemonize yes
protected-mode no
port 6381
logfile "/myredis/cluster/cluster6381.log"
pidfile /myredis/cluster6381.pid
dir /myredis/cluster
dbfilename dump6381.rdb
appendonly yes
appendfilename "appendonly6381.aof"
requirepass 123456
masterauth 123456
 
cluster-enabled yes
cluster-config-file nodes-6381.conf
cluster-node-timeout 5000

• 端口 6382

vim /myredis/cluster/redisCluster6382.conf

bind 0.0.0.0
daemonize yes
protected-mode no
port 6382
logfile "/myredis/cluster/cluster6382.log"
pidfile /myredis/cluster6382.pid
dir /myredis/cluster
dbfilename dump6382.rdb
appendonly yes
appendfilename "appendonly6382.aof"
requirepass 123456
masterauth 123456
 
cluster-enabled yes
cluster-config-file nodes-6382.conf
cluster-node-timeout 5000

• 端口 6383

vim /myredis/cluster/redisCluster6383.conf

bind 0.0.0.0
daemonize yes
protected-mode no
port 6383
logfile "/myredis/cluster/cluster6383.log"
pidfile /myredis/cluster6383.pid
dir /myredis/cluster
dbfilename dump6383.rdb
appendonly yes
appendfilename "appendonly6383.aof"
requirepass 123456
masterauth 123456

cluster-enabled yes
cluster-config-file nodes-6383.conf
cluster-node-timeout 5000

• 端口 6384

vim /myredis/cluster/redisCluster6384.conf

bind 0.0.0.0
daemonize yes
protected-mode no
port 6384
logfile "/myredis/cluster/cluster6384.log"
pidfile /myredis/cluster6384.pid
dir /myredis/cluster
dbfilename dump6384.rdb
appendonly yes
appendfilename "appendonly6384.aof"
requirepass 123456
masterauth 123456
 
cluster-enabled yes
cluster-config-file nodes-6384.conf
cluster-node-timeout 5000

• 端口 6385

vim /myredis/cluster/redisCluster6385.conf

bind 0.0.0.0
daemonize yes
protected-mode no
port 6385
logfile "/myredis/cluster/cluster6385.log"
pidfile /myredis/cluster6385.pid
dir /myredis/cluster
dbfilename dump6385.rdb
appendonly yes
appendfilename "appendonly6385.aof"
requirepass 123456
masterauth 123456
 
cluster-enabled yes
cluster-config-file nodes-6385.conf
cluster-node-timeout 5000

• 端口 6386

vim /myredis/cluster/redisCluster6386.conf

bind 0.0.0.0
daemonize yes
protected-mode no
port 6386
logfile "/myredis/cluster/cluster6386.log"
pidfile /myredis/cluster6386.pid
dir /myredis/cluster
dbfilename dump6386.rdb
appendonly yes
appendfilename "appendonly6386.aof"
requirepass 123456
masterauth 123456
 
cluster-enabled yes
cluster-config-file nodes-6386.conf
cluster-node-timeout 5000

3.2 启动六台redis

redis-server /myredis/cluster/redisCluter6381.conf 
..........
redis-server /myredis/cluster/redisCluter6386.conf 

3.2 通过redis-cli命令为6台机器构建集群关系

redis-cli -a 123456 --cluster create --cluster-replicas 1 192.168.88.130:6381 192.168.88.130:6382 192.168.88.130:6383 192.168.88.130:6384 192.168.88.130:6385 192.168.88.130:6386

• -cluster-replicas 1 表示为每个master创建一个slave节点

3.3 任意连接一个作为切入点（集群只需要连一个），并检验集群状态

• 连接6381端口

redis-cli -a 123456 -p 6381 -c     // -c表示集群 不加的话不是按照集群启动的，对于在别的机器上的key，会报错

不加 -c 启动 ，在存值时，可能会报错，原因是在计算槽位时，可能是在别的master下管理的槽位
下图中的槽位是在6384端口，所以需要在6384端口的redis进行set操作

加上-c之后，会进行自动重定向

• 查看集群主从关系

cluster nodes       // 查看集群的主从关系

• 查看集群信息

 cluster info       // 查看集群信息     

• 查看某个key该属于对应的槽位值

CLUSTER KEYSLOT key  //查询key所在的槽位值

四、 扩展

• 不在同一个slot槽位下的键值无法使用mset.mget等多键操作

可以通过{}来定义同一个组的概念，使key中内相同内容的键值对放到一个slot槽位去，对照下图类似k1k2k3都映射为x，

• 集群是否完整才能对外提供服务

在配置文件中有以下代码

cluster-require-full-coverage

默认YES，现在集群架构是3主3从的redis cluster由3个master平分16384个slot，每个master的小集群负责1/3的slot，对应一部分数据。
cluster-require-full-coverage:默认值 yes，即需要集群完整性，方可对外提供服务通常情况，如果这3个小集群中，任何一个（1主1从）挂了，你这个集群对外可提供的数据只有2/3了，整个集群是不完整的，
redis 默认在这种情况下，是不会对外提供服务的。

如果你的诉求是，集群不完整的话也需要对外提供服务，需要将该参数设置为no ，这样的话你挂了的那个小集群是不行了，但是其他的小集群仍然可以对外提供服务。