1.概念
集群，从广义来讲：只要是多个机器，构成了分布式系统，都可以称为一个集群
狭义的集群：redis提供的集群模式，这个集群模式之下，主要是要解决存储空间不足的问题（拓展存储空间）
哨兵模式提高了系统的可用性，哨兵模式中，本质上还是redis主从节点存储数据，其中就要求一个主节点/从节点，就得存储整个数据的"全集"
引入多台机器，每台机器分担一部分：存储一部分数据，每台存储数据的机器还需要搭配多个从节点
2.分片
上述红框标注的就是分片~ 三种主流的分片方式
2.1 hash求余
借助hash函数，把一个key映射到整数，再针对数组长度求余，就可以得到一个数组下标
比如有三个分片：0，1，2
此时可以针对要插入的数据的key（redis都是键值对结构的数据）计算hash值（比如md5：将string经过数据计算得到一个整数），再把这个hash值余上分片的个数，就得到了一个下标，此时就可以把这个数据放到该下标对应的分片中了。
hash(key) % length(分片的个数，上述就是3)
但如果分片添加了，也就是扩容发生的时候，分片结果就会发生变化（需要重新进行分配）。
2.2 一致性hash算法
上述方式，如果数据很大，且发生数据搬运，开销极大，只能在非生产环境下，通过替换的方式进行扩容，依赖机器更多了，成本也高，因此一致性hash算法解决上述问题
在hash求余这种操作，当前key属于哪个分片是交替的：例如102 -》0 ，103-》1，104-》2 ...0,1,2.....，在一致性hash下，把交替出现，改成连续出现。
具体分为几步：
把0->2^32-1这个数据空间,映射到⼀个圆环上.数据按照顺时针⽅向增⻓.
假设有三个分区，在圆环上进行划分
假定一个key，计算得到hash值，该key值划分就是顺时针往下找，找到的第一个分区就是key所属分片
这就相当于,N个分⽚的位置,把整个圆环分成了N个管辖区间.Key的hash值落在某个区间内,就对应区间管理.
扩容场景
此时,只需要把0号分⽚上的部分数据 ,搬运给3号分⽚即可 .1号分⽚和2号分⽚ 管理的区间都是不变 的.
优点:⼤⼤降低了扩容时数据搬运的规模,提⾼了扩容操作的效率.
缺点:数据分配不均匀(有的多有的少,数据倾斜).
2.3 hash槽分区算法（redis使用）
就比如说：
此处，每个分区都会使用位图的数据结构表示当前有多少槽位号，16384个bit位，用每一个0/1来区分自己这个分片当前是否持有该槽位号
总结一下：key值先通过hash算法计算一下得到一个hash值，hash值再取模16384得到槽位，根据槽位数再划分到不同的分片。
分片增加场景：
注意事项
Redis集群是最多有16384个分⽚吗?
key是先映射到槽位 ，再映射到分片的。
如果每个分片包含的槽位比较多，如果槽位个数相当，就可以认为是包含的key数量相当。
如果每个分片包含的槽位比较少，槽位个数并不能直观的反应到key的数目。
因此造成：有的槽位有key，有的槽位没有key
如果每个分片只有一个槽位：很难保证数据在各个分片的均衡性
为什么是16384
1.节点之间通过心跳包进行通信，心跳包包含每个节点持有什么slots （槽位），槽位使用位图这样的数据结构表示的，16384 （16k）是2kb字节的空间，redis留出2kb的空间来保存槽位，如果slots更多了，就需要更大的空间去保存槽位。因为是周期性通信*（非常频繁，占用带宽）
2.另⼀⽅⾯,Redis集群⼀般不建议超过1000个分⽚.所以16k对于最⼤1000个分⽚来说是⾜够⽤
的,同时也会使对应的槽位配置位图体积不⾄于很⼤.
3.集群搭建
需求:
3.1 实现
在sh文件添加：
实现批量创建redis配置文件
执行脚本：
bash
sh xxx.sh创建redis容器：
在yml文件中进行编辑：
其他redis节点配置:
启动容器：
bash
docker -compose up -d几个redis节点构建成集群：
3.2 使用集群
使用集群存储数据:
-c：选型添加之后，redis客户端就会根据当前key实际算出来的槽位号，自动找到匹配的分片主机
4.故障处理
如果某个节点挂了，处理分几个情况
从节点挂了，挂就挂了不管，但如果是主节点挂了 ？
如果主节点挂了，就会自动把该主节点旗下的某个从节点选拨为主节点
4.1具体流程
1、先判断故障：
1.节点A给节点B发送ping包，B节点返回pong包，二个包除了message type属性不同之外，其他部分是一样的。
2.每个节点每秒钟都会给一些随机的节点发送ping包
3.A节点向B节点发送ping，不能正常返回pong，A就会尝试重置和B的TCP连接，如果还是失败，A就会把B标记为PEAIL(主观下线)
4.A判定BPEAIL之后，A会通过内置的Gossip协议，和其他节点进行沟通。让其他节点确认B状态
5.A发现其他节点也是认为B节点PFAIL，超过一半，那么A标记B为FAIL（客观下线），并且将消息同步给其他节点。
2、故障迁移
如果挂了的B节点是从节点无所谓
如果是主节点：需要从B节点的从节点挑选一个作为主节点
1.从节点首先需要判定是否有资格，从节点与主节点之间太久没同步了，此时差异太大，（超过了一定的阈值），就会失去资格
2.具有资格的节点会先进行休眠：休眠时间的大小因素主要为排名大小（offset值越大，排名越小）
3.有资格从节点的休眠时间到了，该节点就会给其他主节点进行拉票操作
4.主节点收到拉票请求就会投给那个参加竞选的从节点，当票数超过主节点数目的一半，该晋升成功的从节点自己负责 slaveof no one，并且让同为从节点的另一个从节点归属自己
5.同时，该节点晋升为主节点的消息也要发送给其他节点，以供其他节点更新自己的集群结构
集群宕机
出现以下几种情况会发生集群宕机：
1.某个分片，所有的主节点和从节点全挂了 ：分片存储了部分的数据，如果该分片全挂了，就会宕机
2.主节点挂了，但该主节点没有从节点：和上述一个情况
3.超过半数的主节点挂了
5.集群扩容
场景:101-109 9个主机，构成了3主6从结构的集群，当前110和111也想加入到集群中：以110为主节点，111为从节点 == 分片从三个到四个
1.新的主节点添加到集群中
左ip为被新增的节点，右ip为集群上任意的一个节点:表明节点增添到哪个集群中
2.重新分配slots
然后需要输入分配多少槽位（通常16384 / 分片数）
紧接着，会询问让哪个节点来接收，粘贴110主机id即可
3.把从节点添加到集群中
5.1 问题
如果搬运key/slots时，此时的客户端能否访问咱们redis集群吗？
搬运key，大部分的key不是用来搬运的，针对这些未搬运的key：此时是可以访问的，针对这些正在搬运中的key，是有可能出现不能访问的情况
