Redis集群

1.Redis-Cluster:Redis集群(Redis3.0之后的新特性)

1.1.简介

1>.所有的Redis节点彼此互联(PING-PONG机制),内部使用二进制协议优化传输速度和带宽;

2>.节点的fail是通过集群中超过半数的节点检测失效时才生效;

3>.客户端与Redis节点直连,不需要中间proxy层.客户端不需要连接集群所有节点,连接集群中任何一个可用节点即可;

4>.Redis-Cluster把所有的物理节点映射到[0-16383]slot(插槽)上,Redis-Cluster负责维护node<->slot<->value;

5>.Redis-Cluster默认是不支持slave节点读或者写的,跟我们手动基于replication搭建的主从架构不一样的;默认的话就是读和写都到master主节点上去执行的,slave从节点则是某个主节点的复制品;必须slave节点上执行"readonly"命令,这个时候才能在slave节点上进行get读取;

6>.Redis-Cluster的时候,就没有所谓的读写分离的概念了;读写分离,是为了什么,主要是因为要建立一主多从的架构,才能横向任意扩展slave node去支撑更大的读吞吐量;而Redis-Cluster的架构下,实际上本身master就是可以任意扩展的,你如果要支撑更大的读吞吐量,或者写吞吐量,或者数据量,都可以直接对master进行横向扩展就可以了,也可以实现支撑更高的读吞吐的效果;

Redis-Cluster = 主从复制(多主多从) + 哨兵机制 + hash slot;

1.2.Redis-Cluster故障转移

1>.当集群中的某个master节点宕机了,那么该master节点就会失效,并与slave节点断开连接,而他对应的slave节点就会自动变成master继续服务,而原来master上的数据也会一起转移到对应的slave(即新起来的这个主数据库)中[slave对master数据做一次全量复制(清空旧的数据,加载内存中新的数据),然后重写AOF日志文件],所以他的数据并不会丢失!!!

2>.原来的master重启之后他就变成了新增的这个master(由从库变成的主库)的slave;

1.3.Redis-Cluster自动化的slave迁移

1>.比如现在有10个master,每个master有1个slave,然后新增了3个slave作为冗余,有的master就有多个slave了,此时master出现了salve冗余;

2>.如果某个master的slave挂了,那么redis cluster会自动迁移一个冗余的slave给那个master,这就是slave的自动迁移;

3>.只要多加一些冗余的slave就可以了,其他交给redis-cluster去处理;

4>.如果某个master的slave挂了,那么Redis-Cluster就会自动迁移一个冗余的slave给那个master,实现slave自动迁移,如果挂掉的slave又重启了,那么还是挂载到原来的master上,跟原来的master做数据同步,然后重写AOF文件;

2.Redis-Cluster核心原理分析

2.1.Redis集群节点之间的内部通信机制

2.1.1.基础通信原理

维护集群中元数据的方式: 集中式,分布式

分布式跟集中式不同,不是将集群元数据(节点信息,故障,等等)集中存储在某个节点上,而是节点互相之间不断通信,保持整个集群所有节点的数据是完整的;

①.集中式: 如zookeeper

优点: 元数据的更新和读取,时效性非常好,一旦元数据出现了变更,立即就更新到集中式的存储中,其他节点读取的时候立即就可以感知到;

缺点: 所有的元数据的跟新压力全部集中在一个地方,可能会导致元数据的存储有压力;

②.分布式: 如gossip

优点: 元数据的更新比较分散,不是集中在一个地方,每个节点都有一份元数据信息,当某个节点上的元数据信息发生变更时,更新请求会陆陆续续发送到其他所有节点上去更新其他所有节点上的元数据信息,有一定的延时,降低了压力;

缺点: 元数据更新有延时,可能导致集群的一些操作会有一些滞后;

1>.Redis集群节点间采取gossip协议进行通信;

2>.10000端口

每个节点都有一个专门用于和其他节点间通信的端口,就是自己提供服务的端口号+10000,比如7001,那么用于节点间通信的就是17001端口;

每个节点每隔一段时间都会往另外其他节点发送ping消息,同时其他几点接收到ping之后返回pong;

3>.交换信息

故障信息,节点的增加和移除,hash slot信息等等;

2.1.2.gossip协议

1>.gossip协议包含多种消息,包括ping,pong,meet,fail等等;

①.meet:
某个节点发送meet给新加入的节点,让新节点加入集群中,然后新节点就会开始与其他节点进行通信

②."Redis-trib.rb add-node"指令
其实内部就是发送了一个gossip meet消息给新加入的节点,通知那个节点去加入我们的集群

③.ping:
每个节点都会频繁给其他节点发送ping消息,其中包含自己的状态还有自己维护的集群元数据,互相通过ping交换元数据,保持每个节点元数据一致性

每个节点每秒都会频繁发送ping给其他的节点,通过ping消息频繁的互相之间交换数据,互相进行元数据的更新

④.pong:
返回ping和meet,包含自己的状态和其他信息,也可以用于信息广播和更新

⑤.fail:
某个节点判断另一个节点fail之后,就发送fail消息给其他节点,通知其他节点,指定的节点宕机了

2.1.3.ping消息

①.ping很频繁,而且要携带一些元数据(当前节点的元数据),所以可能会加重网络负担;

②.每个节点每秒会执行10次ping,每次会选择5个最久没有通信的其他节点;如果发现某个节点通信延时达到了cluster_node_timeout / 2,那么立即发送ping,避免节点之间数据交换延时过长,落后的时间太长了;

比如说,两个节点之间10分钟没有交换数据了,那么整个集群处于严重的元数据不一致的情况,就会有问题,所以cluster_node_timeout可以调节,如果调节比较大,那么会降低发送的频率;

③.每次ping,一个是带上自己节点的元数据,还有就是带上1/10其他节点的元数据,发送出去,跟其他所有的节点进行数据交换;每次ping至少包含3个其他节点的信息,最多包含(总节点-2)个其他节点的信息;

2.2.基于重定向的客户端

2.2.1.请求重定向

①.客户端可能会挑选任意一个Redis实例去发送(读写)命令,每个Redis实例接收到命令,都会计算key对应的hash slot;如果hash slot在本地就在当前节点上处理,否则返回"moved…"信息给客户端,让客户端进行重定向;

②.“cluster keyslot mykey”;可以查看一个key对应的hash slot是什么;

③.用"Redis-cli"的时候,可以加入"-c"参数,支持自动的请求重定向,Redis-cli接收到"moved…"消息之后,会自动重定向到对应的节点执行命令;

2.2.2.计算Hash Slot

①.计算hash slot的算法,就是根据key(有效部分)计算CRC16值,然后对16384取模,拿到对应的(0~16383)hash slot;

②.用hash tag可以手动指定key对应的hash slot,同一个hash tag下的key,都会在一个hash slot中,比如set key1:{100}和set key2:{100},他们指定了相同的hash tag,那么这两个kv会落在同一个节点的同一个hash slot中;

扩展:数据分布算法

①.Redis-Cluster有固定的16384个hash slot(哈希槽),对每个key的有效部分计算CRC16值,然后对16384取模,可以获取key对应的hash slot(0~16383);

②.Redis-Cluster中每个master都会持有部分hash slot(哈希槽),比如有3个master,那么可能每个master持有5000多个hash slot(哈希槽);

③.hash slot(哈希槽)让node的增加和移除很简单,增加一个master,就将其他master的hash slot(哈希槽)移动部分过去,减少一个master,就将它的hash slot(哈希槽)移动到其他master上去;

④.Redis底层机制保证移动hash slot(哈希槽)的成本是非常低的,任何一台机器宕机,他上面的数据(hash slot)会重新分布到其他的机器上,保证始终有16384个hash slot存在,数据是不会受影响的,因为key计算hash slot(哈希槽)跟机器数没有任何关系(找的也不是机器而是hash slot);客户端请求发现该节点宕机/不可用,然后再去其他的机器上找这个的hash slot(哈希槽);

⑤.客户端的api,可以对指定的数据,让他们走同一个hash slot(哈希槽),通过hash tag来实现;

扩展:Hash算法与Hash一致性算法

①.Hash算法:
a.计算key的hash值,然后对应节点数量取模(%),取模之后的结果一定是在节点数量之内,例如一个hash值对3取模,得到的结果一定是0,1,2;然后将(读写)请求转发到对应的节点上;

b.Hash算法弊端:

假如某个master节点宕机了,那个这个节点数据就失效了,那么之后所有的请求会基于其他的节点去取数据,此时在使用hash算法得到的结果就不一样了,即找不到原来存放数据的节点,那么也就找不到缓存数据了,整个缓存都会失效,又要从数据库从查询数据,那么数据库的压力的大了;

②.一致性hash算法

a.计算key的hash值,然后会用hash值去匹配圆环上的各个点(master)(每个点都有一个hash值),看hash值应该落在圆环上的哪个部位,key落在圆环上之后,就会顺时针旋转去寻找距离自己最近一个点(master),最后将数据存放在这个部位/从这个部位取数据

b.一致性hash算法弊端:

假如某个点不可用了,那么就顺时针旋转去寻找距离自己最近另一个点(master)继续存放/查询数据,一致性hash算法可以保证任何一个(master)节点宕机,只有宕机的这个节点的数据受到影响,其他的节点上数据还是可以正常使用的,只有这一部分数据会去查询数据库,整个缓存受到的影响远比hash算法低/小,圆环上的点越多,受到的影响越小;

缓存热点问题,某个区间内的缓存数据特别多;

c.解决方案:

为每个圆环上的每个点都做了均匀分布的虚拟节点,这样的话,在每个区间内大量的数据都会均匀的分布在不同的节点上,而不是按照顺时针的顺序去找距离最近的节点,将数据全部存放/查询同一个节点;

2.2.3.Hash Slot查找

节点间通过gossip协议进行数据交换,就知道每个hash slot在哪个节点上;

2.2.4.Smart Jedis

1>.什么是Smart Jedis?

①.(“Redis-cli -c”)基于重定向的客户端,很消耗网络IO,因为大部分情况下,可能都会出现一次请求重定向,才能找到正确的节点;所以大部分的客户端,比如java Redis客户端,就是Jedis,都是使用smart模式;

②.smart模式会在本地维护一份hash slot -> node的映射表的缓存,通过这个映射表可以直接定位到对应的node节点;大部分情况下,直接通过本地缓存就可以找到hash slot对应的node节点在哪里,不需要通过节点进行moved重定向;

2.3.JedisCluster的工作原理

①.在JedisCluster初始化的时候,就会随机选择一个node,利用node上的(集群)元数据初始化hash slot -> node映射表,同时为每个node节点创建一个JedisPool连接池;

②.每次基于JedisCluster执行操作时,首先JedisCluster都会在本地计算key的hash slot,然后通过本地缓存的hash slot->node映射表找到对应的node节点;

③.如果那个node正好还是持有那个hash slot,那么就ok,直接在那个node节点上进行读写操作;如果说进行了reshard(重新分片)这样的操作,可能hash slot已经不在那个node上了,就会返回"moved…"消息,需要重定向;

④.如果JedisCluter API发现对应的节点返回moved(返回的move的信息中包含了该key对应的hash slot所在的node的信息),那么利用该节点的元数据,更新本地的hashslot -> node映射表缓存;

⑤.重复上面几个步骤,直到找到对应的节点,完成数据操作;如果重试超过5次,那么就报错"JedisClusterMaxRedirectionException";

注意:

jedis老版本可能会出现在集群的某个节点故障还没完成自动切换恢复时,频繁更新hash slot,频繁ping节点检查活跃,导致大量网络IO开销;

jedis最新版本,对于这些过度的hash slot更新和ping,都进行了优化,避免了类似问题;

2.4.Hash Slot迁移和Ask重定向

①.如果jedis要操作的hash slot正在迁移(到其他节点),那么会返回ask重定向信息给jedis,告诉jedis客户端hash slot迁移后的目标节点信息;

②.jedis接收到ask重定向信息之后,会重新定位到目标节点去执行读写操作,但是由于ask发生在hash slot迁移过程中(即迁移还没有完成),所以JedisCluster API收到ask重定向信息之后是不会更新hash slot-> node节点映射表的本地缓存;

③.如果jedis客户端接受到的是"moved …"信息,已经可以确定hash slot已经迁移完了,那么JedisCluster API是会更新本地hash slot->node映射表的本地缓存;

2.5.高可用性与主备切换原理

Redis-Cluster的高可用原理,几乎跟哨兵是类似的;

2.5.1.判断节点宕机

①.如果在cluster-node-timeout内,某个节点一直没有返回pong,那么一个节点认为另外一个节点宕机,那么就是pfail主观宕机;如果一个节点认为某个节点pfail了,那么会在gossip ping消息中把这个pfail节点的(pfail状态)信息ping给其他节点,如果超过半数的节点都认为pfail了,那么(pfail状态的节点)就会变成fail客观宕机;

②.如果多个节点都认为另外一个节点宕机了,那么就是fail客观宕机,跟哨兵的原理(sdown,odown)几乎一样;

2.5.2.从节点过滤

①.对fail客观宕机的master node,从他所有的slave node中,选择一个切换成master node;

②.如果该master有多个slave,那么检查每个slave node与master node断开连接的时间,如果超过了[cluster-node-timeout * cluster-slave-validity-factor],那么该slave 就没有资格切换成master,这个也是跟哨兵是一样的;

2.5.3.从节点选举

哨兵:对所有从节点进行排序(slave priority,offset,run id)

①.每个从节点都根据自己对master复制数据的offset来设置一个选举时间,offset越大(复制数据越多/越完整)的从节点,选举时间越靠前,优先进行选举;

②.所有的master node开始给要进行选举的slave投票,如果大部分master node(N/2 + 1,N为master节点个数)都投票给了某个slave从节点,那么选举通过,那个从节点可以切换成master,然后从节点执行主备切换,从节点切换为主节点;

2.5.4.Redis-Cluster与Sentinel哨兵比较

Redis-Cluster整个流程跟哨兵相比,非常类似,所以说Redis-Cluster功能强大,直接集成了replication和sentinal的功能;