持续创作,加速成长!这是我参与「掘金日新计划 · 10 月更文挑战」的第6天,点击查看活动详情
Redis 主从复制
概述
主机数据更新后根据配置和策略, 自动同步到备机的 master/slaver 机制,Master 以写为主,Slave 以读为主,主从复制节点间数据是全量的(不考虑同步造成的延时,每个节点数据一样)。
发生时机
- Redis全量复制一般发生在Slave首次初始化阶段,这时Slave需要将Master上的所有数据都复制一份。
- 全量复制过后就是增量复制。
作用
- 读写分离,性能扩展
- 容灾快速恢复
复制原理
-
Slave 启动成功连接到 master 后会发送一个 sync 命令;
-
Master 接到命令
- 启动后台的存盘进程。
- 收集所有接收到的用于修改数据集命令。
- 后台进程执行完毕之后。
- master 将传送整个数据文件到 slave。
- 完成一次完全同步。
-
全量复制:
- slave 服务器在接收到数据库文件数据后,将其存盘并加载到内存中。
-
增量复制:
- Master 继续将新的所有收集到的修改命令依次传给 slave,完成同步。
-
只要是重新连接 master,一次完全同步(全量复制) 将被自动执行。
哨兵模式 (sentinel)
反客为主:当一个 master 宕机后,后面的 slave 可以立刻升为 master,其后面的 slave 不用做任何修改。用 slaveof no one 指令将从机变为主机。而哨兵模式是反客为主的自动版,能够后台监控主机是否故障,如果故障了根据投票数自动将从库转换为主库。
当主机挂掉,从机选举产生新的主机
- 哪个从机会被选举为主机呢?投票机制 。
- 原主机重启后会变为从机。
哨兵基本模式
在上图过程中,哨兵主要有两个重要作用:
- 第一:哨兵节点会以每秒一次的频率对每个 Redis 节点发送
PING命令,并通过 Redis 节点的回复来判断其运行状态。 - 第二:当哨兵监测到主服务器发生故障时,会自动在从节点中选择一台将机器,并其提升为主服务器,然后使用 PubSub 发布订阅模式,通知其他的从节点,修改配置文件,跟随新的主服务器。
多哨兵模式
多个哨兵之间也存在互相监控,这就形成了多哨兵模式。
在实际生产情况中,Redis Sentinel 是集群的高可用的保障,为避免 Sentinel 发生意外,它一般是由 3~5 个节点组成,这样就算挂了个别节点,该集群仍然可以正常运转。
主观下线(真实下线)
主观下线,适用于主服务器和从服务器。如果在规定的时间内(配置参数:down-after-milliseconds),Sentinel 节点没有收到目标服务器的有效回复,则判定该服务器为“主观下线”。比如 Sentinel1 向主服务发送了PING命令,在规定时间内没收到主服务器PONG回复,则 Sentinel1 判定主服务器为“主观下线”。
客观下线(在某一台眼里下线)
客观下线,只适用于主服务器。 Sentinel1 发现主服务器出现了故障,它会通过相应的命令,询问其它 Sentinel 节点对主服务器的状态判断。如果超过半数以上的 Sentinel 节点认为主服务器 down 掉,则 Sentinel1 节点判定主服务为“客观下线”。
投票选举
投票选举,所有 Sentinel 节点会通过投票机制,按照谁发现谁去处理的原则,选举 Sentinel1 为领头节点去做 Failover(故障转移)操作。Sentinel1 节点则按照一定的规则在所有从节点中选择一个最优的作为主服务器,然后通过发布订功能通知其余的从节点(slave)更改配置文件,跟随新上任的主服务器(master)。至此就完成了主从切换的操作。
投票机制详解
投票时机
- 在redis启动的时候,进行选举
- 在leader节点宕机之后,进行选举
选举算法
- 先过滤故障节点
- 划分选举周期(raft算法可以随机定义一个时间周期,这个周期就是选举的周期,如果该周期中没有选出leader,则进入下个时间周期)
- 每个follow节点的选举时钟不一样,这样就可以避免所有的follow节点向其它节点同时发送选举指令
- 首先follow节点先投票给自己,然后发送请求给其它节点给自己投票
- 其它节点收到投票请求之后,先比较优先级(slave-priority)
- 如果自己的大,则给自己投票,否则投票给别人。
- 如果 优先级相同,则比较复制偏移量(从主节点同步的数据偏移量)
- 如果自己大,则给自己投票,否则投票给别人
- 如果偏移量相同,则比较runid(redis的标识,随机生成)
- 如果自己小,则投票给自己,否则投票给别人,每个节点只能投票一次,而每个节点有自己的投票箱 6、最后比较投票的数量,数量最多,则成功leader,如果数量相同,则进入下一个选举周期,重新投票。
复制延时
由于所有的写操作都是先在 Master 上操作,然后同步更新到 Slave 上,所以从 Master 同步到 Slave 机器有一定的延迟,当系统很繁忙的时候,延迟问题会更加严重,Slave 机器数量的增加也会使这个问题更加严重。