redis持久化、高可用主从架构以及哨兵模式、集群模式详解
2021-08-08 14:52:19 0 举报redis持久化、高可用主从架构以及哨兵模式、集群模式详解
作者其他创作
大纲/内容
dump.rdb文件
一：连接断开
.................
主线程
Redis集群方案
最终文件为appendonly.aof
客户端本地
三：将主节点rdb快照数据发送给从节点（一个rdb快照数据发给多个从节点）
slave2
Redis主从复制工作原理
slave
2：广播FAILOVER_AUTH_REQUEST申请主节点请求
master
引出高可用集群模式
客户端缓存每个节点的槽位信息
slave2检测到master故障时，也会向slave1一样向集群中的每个节点进行申请主节点申请请求
bgsave子进程
内存数据A20条
在默认情况下， Redis 将内存数据库快照保存在名字为 dump.rdb 的二进制文件中
Redis Cluster将内存数据分为16384个槽位slots来存储数据每个redis节点会存储一部分槽位信息
副本
修改
.......
Redis集群
FAILOVER_AUTH_ACK
redis集群是一个由多个主从节点群组成的分布式服务器群，具有高可用、复制、分片的特性不需要哨兵也可以实现故障转移、节点清除功能每个节点配置成集群模式，没有中心节点，可以水平扩展，官方网站说支持上万个节点，但推荐不超过1000个节点
生成新的rdb文件B21条数据
0~5461
16384
新master
对ping和meet消息的返回，包含自己的状态和其他信息，也可以用于信息广播和更新
有三个选项：1appendfsync always：每次有新命令追加到 AOF 文件时就执行一次 fsync ，非常慢，也非常安全。2appendfsync everysec：每秒 fsync 一次，足够快，并且在故障时只会丢失 1 秒钟的数据。3appendfsync no：从不 fsync ，将数据交给操作系统来处理。更快，也更不安全的选择。推荐（并且也是默认）的措施为每秒 fsync 一次， 这种 fsync 策略可以兼顾速度和安全性。
选举的规则是：超过半数票选获得者才会被选上
...........16384
redis集群原理分析
ping
四：slave的offset如果在repl baklog buffe缓存队列中，那么master将会将offset之后的数据一次性发送给从节点，如果master进程id找不到
3G
某个节点发送meet给新加入的节点，让新节点加入集群中，然后新节点就会开始与其他节点进行通信
思考：如何解决这一问题呢
覆盖
两种方式生成rdb文件
覆盖之前的rdb文件
slave3
将修改的每一条指令记录进文件appendonly.aof中
维护集群的元数据、主从关系、节点数量等
fail
0
client
如何将内存数据快照保存在rdb文件中呢？内存数据又是如何同步到rdb文件中呢？或者说如何生成rdb文件？
JedisCluster
RDB快照
配置文件打开 appendonly yes
Hash slot（槽位定位算法）
当客户端向一个错误的节点发出了指令，该节点发现指令的key不在自己管理的槽位上，那么该节点则通过节点之间的通信查找出key对应的槽位信息，然后向客户端返回一个携带目标地址的特殊跳转指令，然后客户端收到该命令后，会直接访问正确的节点地址，而且会同步更新客户端缓存在本地的槽位映射表，后续key会使用新的槽位映射表
五：将rdb快照数据加载到内存中
集群脑裂丢失数据问题
思考：客户端通过槽位信息如何找到对应的节点呢
老master
save命令执行过程
save
rdb文件A20条数据
思考：这种集群架构模式有什么缺点？
否
两种生成rdb文件各自的特点是什么？优缺点是什么？
meet
Redis集群选举原理分析
网络一会不能访问，一会又恢复了
此时如果老master因为网络原因重新由故障变为正常状态了，则会出现两个master，这两个主节点都可以对外提供读写服务
当redis重启时，则可以先加载rdb快照内容，然后执行增量的aof命令
一：从节点通过socket长连接连接到主节点发送psync复制数据命令
某个节点判断另一个节点fail之后，就发送fail给其他节点，通知其他节点，指定的节点宕机了
bgsave子进程可以读取内存所有数据
原理：哨兵sentinel是一种特殊的redis服务，不提供读写服务，负责监控redis节点实例的状态，重点是监控master节点的状态client第一次通过哨兵找到master主节点，然后后续会直接访问master主节点，当哨兵监控到master主节点状态发生变化时，会通过在从节点中进行选举来进行主从切换，然后第一时间通知client，client订阅了哨兵sentinel发布的节点变动信息
gossip协议通信
以配置 Redis 多久才将数据 fsync 到磁盘一次
复制修改前的内存数据为副本，主线程继续操作内存数据
Redis主从架构
三：从节点发送psync命令请求复制数据
高可用集群模式
redis如何进行持久化呢?
DELAY = 500ms + random(0 ~ 500ms) + SLAVE_RANK * 1000ms
集群默认会对key使用crc16算法，hash得到一个整数值，然后对16384取模得到具体的槽位
AOF
先开启aof
面试题：为什么redis集群至少需要三个master主节点呢
面试题：为什么redis集群必须至少三个master节点呢
同步数据
每个节点都会频繁给其他节点发送ping，其中包含自己的状态还有自己维护的集群元数据，互相通过ping交换元数据(类似自己感知到的集群节点增加和移除，hash slot信息等)；
二：主节点收到psync命令后执行bgsave命令，将内存数据生成为rdb快照，写入到rdb文件中
一：aof重写前将内存数据进行快照处理，然后将rdb快照内容写入aof文件中二：如果内存有新的缓存数据，则将新的缓存数据命令追加到aof文件中rdb快照后面
HASH_SLOT = CRC16(key) mod 16384
slave1
继续读取内存数据，写入rdb文件
包含多种消息类型
1：主节点访问不通了，故障
七：从节点执行主节点发送的缓存中的命令到内存中
部分复制断点续传
广播FAILOVER_AUTH_REQUEST申请主节点请求
内存
思考：每执行一次修改命令，就要将该命令写入拽驾到aof文件末尾，长此以往，aof文件中的命令会越积越多，导致变得非常大，恢复数据时，需要执行很多命令，则会变得很慢，那么怎样解决这个问题呢？
跳转重定位
二：主从复制（部分复制，断点续传）工作原理
网络抖动
5461
思考：如果客户端缓存的槽位信息和实际上集群节点的槽位信息不匹配了该怎么办？
Redis主线程fork一个bgsave子进程
5：选举主节点成功后，则通过pong广播所有节点
执行save命令
六：主节点通过长连接将缓存中的新数据发送给从节点
四：从节点先清理老数据，然后将主节点的rdb快照数据写入rdb文件
4G
子进程将副本写入rdb文件
思考：RDB快照持久化主要是通过执行save或者bgsave命令读取内存数据写入rdb文件，那么一旦redis出现故障，那些刚刚写入内存没有写入rdb文件的数据岂不丢失了？这个问题如何解决呢
一：主从复制（全量复制）工作原理
内存数据（10G）
半数写机制
bgsave命令执行过程
将副本数据写入rdb文件中
AOF重写redis会fork出一个子进程去做(与bgsave命令类似)，不会对redis正常命令处理有太多影响
执行set操作内存添加一条新数据内存数据A变为内存数据B20条->21条
redis集群中的节点都是可以相互通信的
读取
什么叫做脑裂？
八：主节点通过socket长连接持续的将写命令发送给从节点
master和所有从节点都维护了复制的数据下标offset以及master进程id
bgsave
复制修改前的那块内存数据为副本
AOF重写
互不影响
通过设置cluster-node-timeout，标识某世界店持续timeout失联时，才被认定为故障，然后重新选举进行主从切换
是
试想：如果redis集群主节点少于3个只有2个，那么一个主节点故障，另外一个节点则不具备选举条件
底层采用写时复制技术copy on write(cow)
5461~........
二：从节点重新发送socket长连接连接主节点
min‐replicas‐to‐write 1
从现在开始， 每当 Redis 执行一个改变数据集的命令时（比如 SET）， 这个命令就会被追加到 AOF 文件的末尾当redis重新启动时，则重新读取aof文件中的命令，重新恢复数据
全量复制
集中式管理，比如zookeeper管理节点信息
思考：开启了混合持久化时，持久化操作是什么样的呢
3：其他节点收到信息，只有master节点响应，如果判断出申请成为主节点的从节点合法，则会给第一个发送成为主节点的从节点(比如slave1是第一个发送的从节点)一个failover-auth-ack
将内存数据写入rdb文件中
pong
开启aof‐use‐rdb‐preamble yes
引发的问题：脑裂
阻塞其他客户端命令
主节点开始做rdb后的新数据缓存
比如一个redis节点挂了，槽位信息也发生了变化，原先和客户端匹配的槽位信息挪到另外一个节点上了
混合持久化
客户端直接通过槽位信息访问对应的节点读写数据
执行bgsave命令
RDB和AOF一起使用
一：哨兵集群配置比较繁琐，性能和高可用效率低下（哨兵集群只要挂掉，监控不到master状态）二：master节点出现故障时，需要重新在从节点中选举出一个新的master主节点，实现主从切换，然而在主从切换期间，client读写数据，则会查不到master节点，导致访问瞬断三：哨兵模式只有一个主节点master对外提供读写服务，并发能力不好font color=\"#000000\
redis主节点突然访问不了了，从节点检测到主节点故障，开始进行重新选举，待选举好了一个新的主节点后，原来的故障主节点又好了，于是出现了一个机器上有两个主节点，原来的主节点则会变成从节点重新加入集群，作为新的主节点的从节点，进行主从复制，于是乎原来主节点的数据全部丢失
执行bgsave时，主线程是读取内存操作？
repl buffer
Redis主线程执行
0 条评论
下一页
