一、集群模式概述
Redis 中哨兵模式虽然提高了系统的可用性，但是真正存储数据的还是主节点和从节点，并且每个节点都存储了全量的数据，此时，如果数据量过大，接近或超出了 主节点 / 从节点机器的物理内存，就会出现严重的问题；
集群模式就是为了解决这个问题的，它通过引入更多的主节点和从节点，每一组主节点及其所对应的从节点存储了数据全集的一部分，多组这个的结构构成了一个更大的整体，这就是集群；
如下图所示，假定引入了三组主从节点来存储全量数据，那么每组机器只需要存储全集的 1/3 即可，其中每组机器中的每个节点保存的数据内容是一样的，这样的一组机器（包含一个主节点和多个从节点）也称为一个分片；
此时，如果全量数据继续增加，就只需引入更多的分片即可；
二、数据分片算法
1. 哈希求余
设有 N 个分片，使用 [0，N-1] 来编号；
哈希求余就是针对给定的 key，先根据一个 hash 函数计算出 hash 值（例如使用 MD5 算法计算 hash 值），再把得到的结果进行 % N，得到的结果就是其所对应的分片编号；
优点：简单高效，数据分配均匀；
缺点：一旦需要进行扩容，N 就会改变，导致原有的映射规则被破坏（hash(key) % N），就需要让节点之间的数据相互传输，重新排列，以满足新的映射规则，此时需要搬运的数据量非常多，开销很大；
2. 一致性哈希算法
首先，把 [0，2^32-1] 这个数据空间，映射到一个圆环上，数据按照顺时针方向增长；
假设存在三个分片，如下图所示
假设有一个 key，通过 hash 函数计算得到 hash 值 H，那么这个 key 对应的分片就是从 H 所在位置，顺时针往下找，找到的第一个分片；
这就相当于，N 个分片的位置，把整个圆环分成了 N 个区间，key 的 hash 值落在某个区间内，就归对应区间管理；
当需要扩容时，原有分片在环上的位置不动，只需要在环上新安排一个分片位置即可；
优点：大大降低了扩容时数据搬运的规模，提高了扩容操作的效率；
缺点：数据分配不均匀(有的分片数据多，有的少，数据倾斜)；
3. 哈希槽分区算法（Redis 采用）
为了解决上述搬运成本高 和 数据分配不均匀的问题，Redis cluster 引入了哈希槽 (hash slots) 算法；
hash_slot = crc16(key) % 1638416384 = 16 * 1024 = 2 ^ 14，这就相当于把整个 hash 值，映射到 16384 个槽位上，即[0，16383]然后再把这些槽位比较均匀的分配给每个分片，同时每个分片的节点都要记录自己持有哪些分片；
比如有三个分片，则槽位的分配方式可能为：
- 0 号分片：[0，5461]，共 5462 个槽位
- 1 号分片：[5462，10923]，共 5462 个槽位
- 2 号分片：[10924，16383]，共 5460 个槽位
每个分片的节点使用 位图 来表示自己持有哪些槽位，对于 16384 个槽位来说，需要 2048 个字节即 2 KB 大小的内存空间来表示；
当需要进行扩容时，比如新加一个 3 号分片，就可以针对原有的槽位进行重新分配，分配的结果可能为：
- 0 号分片：[0，4095]，共 4096 个槽位
- 1 号分片：[5462，9557]，共 4096 个槽位
- 2 号分片：[10924，15019]，共 4096 个槽位
- 3 号分片：[4096，5461]，[9558，10923]，[15020，16383]，共 4096 个槽位
在实际使用 Redis 集群分片的时候，不需要手动指定哪些槽位分配给某个分片，只需要告诉某个分片应该持有多少个槽位即可，Redis 会自动完成后续的槽位分配，以及对应的 key 搬运的工作；
为什么是 16384 个槽位呢？
Redis 官方的解释是：节点之间通过心跳包通信，心跳包中包含了该节点持有哪些 slots，这个是使用位图这样的数据结构表示的，表示 16384 (16k) 个 slots，需要的位图大小是 2KB，如果给定的 slots 数更多了，比如 65536 个了，此时就需要消耗更多的空间，8 KB 位图表示了，8 KB，对于内存来说不算什么，但是在频繁的网络心跳包中，还是⼀个不小的开销的；
另一方面，Redis 集群一般不建议超过 1000 个分片，所以 16k 对于最大 1000 个分片来说是足够用的，同时也会使对应的槽位配置位图体积不至于很大；
三、集群故障处理
1. 故障判定
集群中的所有节点，都会周期性的使用心跳包进行通信；
- 当节点 A 给节点 B 发送 ping 包，B 就会给 A 返回一个 pang 包；每个节点，每秒钟，都会给一些随机的节点发起 ping 包，这样设定是为了避免在节点很多的时候，心跳包也非常多；
- 若节点 A 给节点 B 发起 ping 包，B 不能如期回应时，此时 A 就会尝试重置和 B 的 tcp 连接，看能否连接成功，如果仍然连接失败，A 就会把 B 设为 PFAIL 状态(相当于主观下线)；
- 当A 判定 B 为 PFAIL 之后，会通过 redis 内置的 Gossip 协议，和其他节点进行沟通，向其他节点确认 B 的状态，(每个节点都会维护一个自己的 "下线列表"，由于视角不同，每个节点的下线列表也不⼀定相同)；
- 此时 A 发现其他很多节点，也认为 B 为 PFAIL，并且数目超过总集群个数的一半，那么 A 就会把 B 标记成 FAIL (相当于客观下线)，并且把这个消息同步给其他节点 (其他节点收到之后，也会把 B 标记成 FAIL)
至此 B 就被彻底判定为故障节点了；
若某部分节点宕机，有可能会引起整个集群宕机 (整个集群处于 fail 状态)，主要有以下三种情况：
- 某个分片上的主节点和所有从节点都挂了
- 某个分片上的主节点挂了，并且没有从节点（可归纳为第一种）
- 超过半数的主节点挂了（此时就无法完成投票选举主节点的工作了）
2. 故障迁移
在上述故障判定中，若 B 是从节点，则不需要进行故障迁移，若 B 是主节点，并假设 B 有两个从节点 C 和 D，此时就会由 从节点 C D 触发故障迁移（把从节点提拔为主节点）；
故障迁移的具体步骤为：
- 从节点判定自己是否具有参选资格： 如果从节点和主节点已经太久没通信(此时认为从节点的数据和主节点差异太大了)， 时间超过阈值， 就失去竞选资格；
- 具有资格的节点，比如 C 和 D，会先休眠一定时间，休眠时间 = 500ms 基础时间 + [0， 500ms] 随机时间 + 排名 * 1000ms，offset 的值越大，则排名会越靠前(越小)；
- 比如 C 的休眠时间到了，C 就会给其他所有集群中的节点，进行拉票操作，但是只有主节点才有投票资格；
- 主节点就会把自己的票投给 C (每个主节点只有 1 票)； 当 C 收到的票数超过主节点数目的一半， C 就会晋升成主节点； (C 自己负责执行 slaveof no one， 并且让 D 执行 slaveof C)；
- 同时，C 还会把自己成为主节点的消息，同步给其他集群的节点；大家也都会更新自己保存的集群结构信息；
四、集群扩容
1. 把新的主节点加入到集群
redis-cli --cluster add-node (新的主节点的ip地址和端口号) (集群中任意节点的ip地址和端口号)2. 重新分配 slots
redis-cli --cluster reshard (集群中任意节点的ip地址和端口号)3. 给新的主节点添加从节点
redis-cli --cluster add-node (新的从节点的ip地址和端口号) (集群中任意节点的ip地址和端口号) --cluster-slave --cluster-master-id (新的主节点的 nodeId)
