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至少需要九台物理机……
Original: https://www.cnblogs.com/zhusihua/p/11328042.html
Author: 拉通对齐端到端
Title: redis cluster和hash slot
原创文章受到原创版权保护。转载请注明出处:https://www.johngo689.com/591748/
转载文章受原作者版权保护。转载请注明原作者出处!