Redis主从、哨兵、集群模式介绍

先来收悉下Redis的持久化方式:
RDB快照:默认情况下,Redis将内存数据库快照保存为名为dump.rdb二进制文件,可以设置他的初九话规则为N秒内发生了M次改动时就做一次保存动作 列: “60秒内有至少有1000个键被改动”这一条件时,自动保存一次数据集:配置文件有体现# save 60 1000
此处有个知识点:命令bgsave,就是写时复制机制,在生成快照持久化时任然可以处理写命令,他是由主线程fork出的子线程。也就是前面提到过的Redis并不是单线程。
AOF : RDB有个缺点,当服务宕机后,会确实最近没达到持久化条件一段时间内的数据。所以AOF出现了,他是规定多长时间就持久化一次,推荐每秒同步一次,即使故障也就那一秒的数据没有。这样的话文件就会较大,所以当恢复采用aof文件,碎度就会稍慢。Redis4.0混合持久化,先采用RDB快照恢复,再用AOF补充缺失的部分数据。重启效率大大提高
一、Redis主从架构
Redis主从、哨兵、集群模式介绍_第1张图片
1.为什么需要主从复制?
虽然单台的Redis的并发能达到10万,但是始终有局限性,这时建立主从模式,可以实现读写分离,一个master负责写,多个从节点负责读,从而提升并发能力。
但是与之而来会带出另一个问题,主从复制风暴:当从节点过多,会导致主节点给从节点同步数据时压力过大,解决方式可以让从节点与从节点同步数据。

如果某一个实例master挂掉,我们需要手动把一台从服务器切换为主服务器,还会造成一段时间内服务不可用。为了解决主从模式不能高可用的问题,就发明了哨兵模式
Redis主从、哨兵、集群模式介绍_第2张图片
二、哨兵高可用模式
Redis主从、哨兵、集群模式介绍_第3张图片
哨兵模式很特殊,他不提供读,也不提供写,主要是做监控Redis实例节点。为了挽救不成熟的主从架构而生。为什么这么说,很简单,主从架构中,如果主节点挂了,没有从节点能代替上位成为主节点。
sentinel哨兵是特殊的Redis服务,哨兵模式下,cline端第一次找出Redis的主节点,后续直接访问Redis的主节点,当主节点发生变化,哨兵第一时间感知到,并将新的Redis主节点通知给客户端。为了实现高可用,sentinel必须是需要集群,当Redis的主节点挂了,每一个发现其下线的sentinel都会开始都票选举出自己醒目中的从节点作为主节点对外提供服务。
至此好像Redis的高可用已经很完美,但是他有个致命的缺点,甚至都会被主从架构看不起:哨兵模式中,只有Redis的主节点对外提供服务,从节点不提供读写,只是当做成为主节点上位的备胎使用,这样在高并发的情况下,并发不升反降。
3.高可用集群模式
1.上面提到过哨兵模式中,哨兵集群主要作用可归功于自动选举,但是并发能力上不去,只有Redis的master节点对外提供读写服务,从节点只是备份节点等待上位。说了这么多,那么集群模式下的从节点难道可以对外提供读服务,想多了其实也是一样,只是作为备份。之所以叫集群模式,是因为他有多个master节点,组成集群,这样多个master一起对外提供服务,提升并发能力
Redis主从、哨兵、集群模式介绍_第4张图片
官方描述:redis集群是一个由多个主从节点群组成的分布式服务器群,它具有复制、高可用和分片特性。Redis集群不需要sentinel哨兵∙也能完成节点移除和故障转移的功能。需要将每个节点设置成集群模式,这种集群模式没有中心节点,可水平扩展,据官方文档称可以线性扩展到上万个节点(官方推荐不超过1000个节点)。redis集群的性能和高可用性均优于之前版本的哨兵模式,且集群配置非常简单。
数据分布的实现原理:Redis 集群将所有数据划分为16384个槽位,每个节点(主节点)负责其中的一部分,当我们根据key存放的时候,Redis根据CRC16算法得出一个结果,然后对16384求余数,这样每个key都会落在0-16383之间,然后找到对应的节点区间。

总结下选举机制:集群模式下,各个master之间会互相通信,当通信超时则认为下线了,此时下线的主节点所对应的所有从节点开始抢夺上位成主节点,当半数的集群主节点同意才能选举成功。从节约资源的角度除法考虑集群主节点设置为奇数个。哨兵模式下sentinel选举也是同样的机制。

你可能感兴趣的:(redis,缓存,数据库)