这里是redis系列文章之《redis集群》，上一篇文章链接：【redis基础】哨兵_努力努力再努力mlx的博客-CSDN博客

槽位与分配的概念及两者的优势

通过redis-dir命名为六台机器构建集群关系

链接进入6381作为切入点，查看并检验集群状态

概念

作用

集群算法-分片-槽位slot

槽位与分配的概念及两者的优势

官网介绍分析

槽位

分片

分片是什么

使用Redis集群时我们会将存储的数据分散到多台redis机器上，这称为分片。

简言之，集群中的每个Redis实例都被认为是整个数据的一个分片。

如何找到给定key的分片

为了找到给定key的分片，我们对key进行CRC16(key)算法处理并通过对总分片数量取模。

然后，使用确定性哈希函数，这意味着给定的key 将多次始终映射到同一个分片，

我们可以推断将来读取特定key的位置。

两者的优势

slot槽位映射的三种解决方案

哈希取余分区

2亿条记录就是2亿个k,v，我们单机不行必须要分布式多机，假设有3台机器构成一个集群，

用户每次读写操作都是根据公式：

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

优点：

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

起到负载均衡+分而治之的作用。

缺点：

原来规划好的节点，进行扩容或者缩容就比较麻烦了额，不管扩缩，每次数据变动导致节点有变动，

映射关系需要重新进行计算，在服务器个数固定不变时没有问题，如果需要弹性扩容或故障停机的情况下，

原来的取模公式就会发生变化：Hash(key)/3会变成Hash(key) /?。

此时地址经过取余运算的结果将发生很大变化，根据公式获取的服务器也会变得不可控。

某个redis机器宕机了，由于台数数量变化，会导致hash取余全部数据重新洗牌。

一致性哈希算法分区

三大步骤：
1.算法构建一致性哈希环

一致性哈希环

2.redis服务器ip节点映射

节点映射

3.key落到服务器的落键规则

优点：

容错性

扩展性

缺点：

Hash环的数据倾斜问题

一致性Hash算法在服务节点太少时，容易因为节点分布不均匀而造成数据倾斜（被缓存的对象大部分集中缓存在某一台服务器上）问题，

例如系统中只有两台服务器：

总结：

哈希槽分区

概念：为解决一致性哈希算法的数据倾斜问题，哈希槽实质就是一个数组，数组[0,2^14 -1]形成hash slot空间。

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

槽解决的是粒度问题，相当于把粒度变大了，这样便于数据移动。哈希解决的是映射问题，使用key的哈希值来计算所在的槽，便于数据分配

多少个hash槽：

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

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

哈希槽计算：

经典面试题

为什么redis集群的最大槽数是16384个?

集群环境案例步骤

3主3从redis集群配置

找三台虚拟机，各自新建

新建6个独立的redis服务实例

每个配置文件中的内容均大同小异，自己调节即可，我们给出一个配置文件的配置信息：

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 111111
masterauth 111111
 
cluster-enabled yes
cluster-config-file nodes-6381.conf
cluster-node-timeout 5000

启动六台redis实例：

redis-server/myredis/cluster/redisCluster6381.conf
........
redis-server/myredis/cluster/redisCluster6386.conf

通过redis-dir命名为六台机器构建集群关系

/注意，注意，注意自己的真实IP地址 //注意，注意，注意自己的真实IP地址

redis-cli -a 111111 --cluster create --cluster-replicas 1 192.168.111.175:6381 192.168.111.175:6382 192.168.111.172:6383 192.168.111.172:6384 192.168.111.174:6385 192.168.111.174:6386

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

链接进入6381作为切入点，查看并检验集群状态

3主3从redis集群读写

对6381新增两个key,查看效果：

我们可以发现:我们在加入新的key时可能会报错，我们分析其原因：我们在设置k1这个新键时，在经过crc16算法和取模运算后，这个key被分配到了一个不属于当前的分片，就会报这个错误，我们想要解决这个错误，我们可以使用以下的指令：

使用 -c指令后，当前的键在经过计算之后，会直接分配到对应的分片和槽位

使用cluster keyslot查看key对应的槽位值

主从容错切换前移案例

案例分析：

6381(主)-6384(从)

主从扩容案例

新建6387、6388 两个服务实例配置文件+启动 (又加了个虚拟机或者直接在三个虚拟机里选一个)
启动87/88两个新的节点实例，此时他们自己都是master

以其中一个为例说明配置文件中的配置信息：

bind 0.0.0.0
daemonize yes
protected-mode no
port 6387
logfile "/myredis/cluster/cluster6387.log"
pidfile /myredis/cluster6387.pid
dir /myredis/cluster
dbfilename dump6387.rdb
appendonly yes
appendfilename "appendonly6387.aof"
requirepass 111111
masterauth 111111

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

再次检查集群情况
redis-cli -a 123456 --cluster check 192.168.238.111:6381

为主节点6387分配从节点6388 –cluster-master-id 后跟的是6387的id
redis-cli -a 123456 --cluster add-node 192.168.238.114:6388 192.168.238.114:6387 --cluster-slave --cluster-master-id b861764cbba16a1b21536a3182349748e56f24cc