Cluster：数据分片

Redis Cluster 通过分片（Sharding） 来进行数据管理，提供 主从复制（Master-Slave Replication）、故障转移（Failover） 等开箱即用的功能，可以非常方便地帮助我们解决 Redis 大数据量缓存以及 Redis 服务高可用的问题。

虽说 Redis Cluster 可以扩展到 1000 个节点，但强烈不推荐这样做，应尽量避免集群中的节点过多。这是因为 Redis Cluster 中的各个节点基于 Gossip 协议 来进行通信共享信息，当节点过多时，Gossip 协议的效率会显著下降，通信成本剧增。

节点建议最多1000个节点

• Redis集群支持多个Master,每个Master.又可以挂载多个Slave
• 由于Cluster自带Sentinel的故障转移机制，内置了高可用的支持，无需再去使用哨兵功能
• 客户端与Redis的节点连接，♪不再需要连接集群中所有的节点，只需要任意连接集群中的一个可用节点即可
• 槽位slot负责分配到各个物理服务节点，由对应的集群来负责维护节点、插槽和数据之间的关系

集群算法

• redis 集群的槽位slot
• redis 集群的分片
• 他两的优势
• slot 槽位映射，一般业界有3种解决方案
• 经典面试题
• 为什么redis集群的最大槽数是16384个？
• Redis 集群不保证强一致性，这意味着在特定的条件下，Redis集群可能会丢掉一些被系统收到的写入请求命令
• 集群的密钥空间被分成16384个槽，有效地设置了16384个主节点
• 的集群大小上限（但是，建议的最大节点大小约为1000个节点）。

哈希槽，CRC16校验对16384取模

这种结构很容易添加或者删除节点。比如如果我想新添加个节点D,我需要从节点A,B,C中得部分槽到D上。如果我想移除节点A，需要将A中的槽移到B和C节点上，然后将没有任何槽的A节点从集群中移除即可。由于从一个节点将哈希槽移动到另一个节点并不会停止服务，所以无论添加删除或者改变某个节点的哈希槽的数量都不会造成集群不可用的状态。

哈希分区算法

哈希取余分区

如果数量变动，就会故障不可用

一致性哈希算法分区

步骤

构建一致性哈希环：0-2^32-1

节点映射：redis服务器ip节点映射

落键规则：当我们需要存储一个kv键值对时，首先计算key的hash值，hash(key),将这个key使用相同的函数Hash计算出哈希值并确定此数据在环上的位置从此位置沿环顺时针“行走”，第一台遇到的服务器就是其应该定位到的服务器，并将该键值对存储在该节点上。

优点

容错性：只影响宕机的这一台的数据，且这些数据将来也会转移到下一台去存储

扩展性：增加节点不需要哈希重新计算

缺点

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

哈希槽分区

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

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

Redis Cluster 通常有 16384 个哈希槽，要计算给定 key 应该分布到哪个哈希槽中，我们只需要先对每个 key 计算 CRC-16（XMODEM） 校验码，然后再对这个校验码对 16384(哈希槽的总数) 取模，得到的值即是 key 对应的哈希槽。

分槽个数

在消息头中最占空间的是 myslots[CLUSTER SLOTS/8]。当槽位为 65536 时，这块的大小是：65536÷8÷1024=8kb

为什么16384

如果槽位为65536，发送心跳信息的消息头达8k,发送的心跳包过于庞大。

在消息头中最占空间的是myslots[CLUSTER SLOTS/8]。当槽位为65536时，这块的大小是：65536÷8÷1024=8kb
在消息头中最占空间的是myslots[CLUSTER SLOTS/8]。当槽位为16384时，这块的大小是：16384÷8÷1024=2kb
因为每秒钟，redis节点需要发送一定数量的ping消息作为心跳包，如果槽位为65536，这个ping消息的消息头太大了，浪费带宽。

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

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

槽位越小，节点少的情况下，压缩比高，容易传输

Redis主节点的配置信息中它所负责的哈希槽是通过一张bitmap的形式来保存的，在传输过程中会对bitmap进行压缩，但是如果bitmap的填充率
slots/N很高的话(N表示节点数)，bitmap的压缩率就很低。如果节点数很少，而哈希槽数量很多的话，bitmap的压缩率就很低。

扩缩容

不保证强一致性

节点挂了会写丢失

通信

Gossip 协议

Redis Cluster 是一个典型的分布式系统，分布式系统中的各个节点需要互相通信。既然要相互通信就要遵循一致的通信协议，Redis Cluster 中的各个节点基于 Gossip 协议 来进行通信共享信息，每个 Redis 节点都维护了一份集群的状态信息。

Redis Cluster 的节点之间会相互发送多种 Gossip 消息：

• MEET ：在 Redis Cluster 中的某个 Redis 节点上执行 CLUSTER MEET ip port 命令，可以向指定的 Redis 节点发送一条 MEET 信息，用于将其添加进 Redis Cluster 成为新的 Redis 节点。
• PING/PONG ：Redis Cluster 中的节点都会定时地向其他节点发送 PING 消息，来交换各个节点状态信息，检查各个节点状态，包括在线状态、疑似下线状态 PFAIL 和已下线状态 FAIL。
• FAIL ：Redis Cluster 中的节点 A 发现 B 节点 PFAIL ，并且在下线报告的有效期限内集群中半数以上的节点将 B 节点标记为 PFAIL，节点 A 就会向集群广播一条 FAIL 消息，通知其他节点将故障节点 B 标记为 FAIL 。