文章目录
在前面的文章中,我们介绍了redis的主从和哨兵两种集群方案,redis从3.0版本开始引入了redis-cluster(集群)。
从
主从-哨兵-集群
可以看到redis的不断完善;
主从复制
是最简单的节点同步方案,但无法自动故障转移。
哨兵
可以同时管理多个主从同步方案同时也可以处理主从自动故障转移,通过配置多个哨兵节点可以解决单点网络故障问题,但是单个节点的性能压力问题无法解决。
集群解决了前面两个方案的所有问题,下面我们就学习redis cluster。
一、redis集群之redis cluster
对于Redis集群方案有好多种,基本常用的就是twemproxy
,codis
,redis cluster
这三种解决方案。Redis Cluster是Redis官方提供的Redis集群功能
1.1为什么要用Redis Cluster
除了主从复制
无法自动故障转移和哨兵
无法解决单个节点的性能压力问题外,还有数据量的增加,当现有服务器内存不能满足业务数据的需要时,单纯向服务器添加内存不能达到要求,此时就需要考虑分布式需求,把数据分布到不同服务器上,还有就是网络流量需求,当业务的流量已经超过服务器的网卡的上限值,就需要使用分布式来进行分流。
1.2数据分布
1、 数据分布的目的
全量数据,单机Redis节点无法满足要求,按照分区规则把数据分到若干个子集当中。
2、 常用数据分布方式之顺序分布
顺序分布常用在关系型数据库
的设计.
比如:1到100个数字,要保存在3个节点上,按照顺序
分区,把数据平均分配
三个节点上,1号到33号数据保存到节点1上,34号到66号数据保存到节点2上,67号到100号数据保存到节点3上
3、 常用数据分布方式之哈希分布(虚拟槽分区是Redis Cluster采用的分区方式)
例如1到100个数字,对每个数字进行哈希运算
,然后对每个数的哈希结果除以节点数进行取余
,余数为1则保存在第1个节点上,余数为2则保存在第2个节点上,余数为0则保存在第3个节点,这样可以保证数据被打散,同时保证数据分布的比较均匀
哈希分布方式分为三个分区方式:
- 节点取余分区:比如有100个数据,对每个数据进行hash运算之后,与节点数进行取余运算,根据余数不同保存在不同的节点上
优点:客户端分片,配置简单:对数据进行哈希,然后取余
缺点:数据节点伸缩时,导致数据迁移,迁移数量和添加节点数据有关,建议翻倍扩容
节点取余分区方式有一个问题:即当增加或减少节点时,原来节点中的80%的数据会进行迁移操作,对所有数据重新进行分布,节点取余分区方式建议使用多倍扩容的方式,例如以前用3个节点保存数据,扩容为比以前多一倍的节点即6个节点来保存数据,这样只需要适移50%的数据。数据迁移之后,第一次无法从缓存中读取数据,必须先从数据库中读取数据,然后回写到缓存中,然后才能从缓存中读取迁移之后的数据 - 一致性哈希分区: 原理: 将所有的数据当做一个token环,token环中的数据范围是0到2的32次方,然后为每一个数据节点分配一个token范围值,这个节点就负责保存这个范围内的数据。
对每一个key进行hash运算,被哈希后的结果在哪个token的范围内,则按顺时针去找最近的节点,这个key将会被保存在这个节点上。
在下面的图中,有4个key被hash之后的值在在n1节点和n2节点之间,按照顺时针
规则,这4个key都会被保存在n2节点上,
如果在n1节点和n2节点之间添加n5节点,当下次有key被hash之后的值在n1节点和n5节点之间,这些key就会被保存在n5节点上。
在此例子里,添加n5节点之后,数据迁移会在n1节点和n2节点之间进行,n3节点和n4节点不受影响,数据迁移范围被缩小很多,同理,如果有1000个节点,此时添加一个节点,受影响的节点范围最多只有千分之2。
一致性哈希一般用在节点比较多的时候
优点:采用客户端分片方式:哈希 + 顺时针(优化取余);节点伸缩时,只影响邻近节点,但是还是有数据迁移
缺点:翻倍伸缩
- 虚拟槽分区:预设
虚拟槽
,每个槽就相当于一个数字,有一定范围。每个槽映射一个数据子集,一般比节点数大。Redis Cluster中预设虚拟槽的范围为0到16383
步骤:
1.把16384槽按照节点数量进行平均分配,由节点进行管理
2.对每个key按照CRC16规则进行hash运算
3.把hash结果对16383进行取余
4.把余数发送给Redis节点
5.节点接收到数据,验证是否在自己管理的槽编号的范围
如果在自己管理的槽编号范围内,则把数据保存到数据槽中,然后返回执行结果
如果在自己管理的槽编号范围外,则会把数据发送给正确的节点,由正确的节点来把数据保存在对应的槽中
需要注意的是:Redis Cluster的节点之间会共享消息,每个节点都会知道是哪个节点负责哪个范围内的数据槽
虚拟槽分布方式中,由于每个节点管理一部分数据槽,数据保存到数据槽中。当节点扩容或者缩容时,对数据槽进行重新分配迁移即可,数据不会丢失
。
虚拟槽分区特点: 使用服务端管理节点,槽,数据:例如Redis Cluster;可以对数据打散,又可以保证数据分布均匀
二、Redis Cluster基本架构
Redis-Cluster采用无中心结构,每个节点保存数据和整个集群状态,每个节点都和其他所有 节点连接。其redis-cluster架构图如下:
图中描述的是六个redis实例构成的集群
- 6379端口为客户端通讯端口
- 16379端口为集群总线端口
集群内部划分为16384个数据分槽,分布在三个主redis中。
从redis中没有分槽,不会参与集群投票,也不会帮忙加快读取数据,仅仅作为主机的备份。
三个主节点中平均分布着16384数据分槽的三分之一,每个节点中不会存有有重复数据,仅仅有自己的从机帮忙冗余。
2.1 结构特点
1、所有的redis节点彼此互联(PING-PONG机制),内部使用二进制协议优化传输速度和带宽。
2、节点的fail是通过集群中超过半数的节点检测失效时才生效,只有当集群中的过半节点同时fail整个集群才fail。
3、客户端与redis节点直连,不需要中间proxy层。客户端不需要连接集群所有节点,连接集群中任何一个可用节点即可。
4、redis-cluster把所有的物理节点映射到[0-16383]slot上,cluster 负责维护node<->slot<->value。
5、Redis集群预分好16384个桶,当需要在 Redis 集群中放置一个 key-value 时,根据 CRC16(key) mod16384的值,决定将一个key放到哪个桶中。
2.2 节点分配
假设我们现在有三个主节点,分别是:A, B, C 三个节点,它们可以是一台机器上的三个端口,也可以是三台不同的服务器。那么,采用哈希槽
(hash slot)的方式来分配16384个slot 的话,它们三个节点分别承担的slot 区间是:
节点A覆盖0-5460;
节点B覆盖5461-10922;
节点C覆盖10923-16383
获取数据:
如果存入一个值,按照redis cluster哈希槽的算法: CRC16(‘key’)%16384 = 6782。
那么就会把这个key 的存储分配到 B
上了。同样,当我连接(A,B,C)任何一个节点想获取’key’这个key时,也会这样的算法,然后内部跳转到B节点上获取数据。
新增一个主节点:
新增一个节点D,redis
cluster的这种做法是从各个节点的前面各拿取一部分slot到D上,我会在接下来的