redis cluster和hash slot

redis cluster介绍

从redis3.0.0开始，官方支持了redis cluster的集群模式，结束了redis没有集群的时代。

redis cluster 支撑 N 个 redis master node，每个 master node 都可以挂载多个 slave node。这样整个 redis 就可以横向扩容了。如果你要支撑更大数据量的缓存，那就横向扩容更多的 master 节点，每个 master 节点就能存放更多的数据了。

redis cluster实现（hash slot算法）

Redis 集群没有并使用传统的一致性哈希来分配数据，而是采用另外一种叫做哈希槽 (hash slot)的方式来分配的。redis cluster 默认分配了 16384 个slot，当我们set一个key 时，会用CRC16算法来取模得到所属的slot，然后将这个key 分到哈希槽区间的节点上，具体算法就是：CRC16(key) % 16384。

（为什么是16384，选取了16384是因为crc16会输出16bit的结果，可以看作是一个分布在0-2^16-1之间的数，redis的作者测试发现这个数对2^14求模的会将key在0-2^14-1之间分布得很均匀，因此选了这个值。）

在构建redis cluster集群时，master必须大于等于3，否则会创建失败。并且，当集群中存活的master节点数小于总节点数的一半的话，集群就无法提供服务了。

例：我们有三个master节点A、B、C，采用哈希槽 (hash slot)的方式来分配16384个slot 的话，它们三个节点分别承担的slot 区间是：

节点A：0 ~ 5460
节点B：5461 ~ 10922
节点C：10923 ~ 16383

节点在收到读写请求时，会根据CRC16(key) % 16384算出的槽号去查是否指向自己，如果是则进行处理，如果不是，则返回moved错误，moved错误携带正确的节点IP和端口号返回客户端并指引其转向执行，而后客户端每次关于该key都会去moved返回的节点执行。

当节点的key正在迁移的时候，收到关于该key的请求，那么节点会返回ask错误，并但会正确的节点ip和端口号给客户端去执行。但是这个转向只对本次请求有效，后面关于该key的请求还是会发送到目前正在处理key迁移的节点，直到key迁移完毕并发送广播通知。

 

当有新节点D加入时，redis cluster的这种做法是从各个节点的前面各拿取一部分slot到D上。会变成下面这样：

节点A：1364 ~ 5460
节点B：6826 ~ 10922
节点C：12287 ~ 16383
节点D：0 ~ 1364, 5461 ~ 6826, 10923 ~ 12287

删除节点也是类似，数据会均匀的迁移到剩余节点上，迁移完成后就可以删除这个节点了。

cluster节点通信

redis cluster的构造类似下图所示

 

在 redis cluster 架构下，每个 redis 要放开两个端口号，比如一个是 6379，另外一个就是 加1w 的端口号，比如 16379。

16379 端口号是用来进行节点间通信的，也就是 cluster bus 的东西，cluster bus 的通信，用来进行故障检测、配置更新、故障转移授权。cluster bus 用了另外一种二进制的协议，gossip 协议，用于节点间进行高效的数据交换，占用更少的网络带宽和处理时间。

主从模式

 redis cluster 为了保证数据的高可用性，加入了主从模式，一个主节点对应一个或多个从节点，主节点提供数据存取，从节点则是从主节点拉取数据备份，当这个主节点挂掉后，就会有这个从节点选取一个来充当主节点，从而保证集群不会挂掉。

不过redis的cluster模式不支持主从的树状结构。

主从模式最经典的是哨兵（Sentinel）模式，而Sentinel模式需要至少三台机器（一主二从三哨兵），而cluster模式建议每个master最好部署在不同的物理机上，所以，算一算搭建一个高可用的redis cluster至少需要九台物理机……