**
Redis 主从复制
**
主从复制:主节点负责写数据,从节点负责读数据,主节点定期把数据同步到从节点保证数据的一致性
模拟虚拟机操作
– 配置文件(搭配一主二从)
1.主从配置方式
方式一、新增redis6380.conf/redis6380.conf, 加入 slaveof 127.0.0.1 6379, 在6379启动完后再启6380,完成配置;
方式二、redis-server --slaveof 127.0.0.1 6379 临时生效
2.info replication 查看状态
3.slaveof no one 使当前数据库 停止与其他数据库的同步,转成主数据库
4.
Redis主从拓扑
a)一主一从:用于主节点故障转移从节点,当主节点的“写”命令并发高且需要持久化,可以只在从节点开启AOF(主节点不需要),这样即保证了数据的安全性,也避免持久化对主节点的影响
b)一主多从:针对“读”较多的场景,“读”由多个从节点来分担,但节点越多,主节点同步到多节点的次数也越多,影响带宽,也加重主节点的稳定
c)树状主从:一主多从的缺点(主节点推送次数多压力大)可用些方案解决,主节点只推送一次数据到从节点B,再由从节点B推送到C,减轻主节点推送的压力。
数据同步
a) 全量复制:一般用于初次复制场景(第一次建立SLAVE后全量)
b)部分复制:网络出现问题,从节点再次连接主节点时,主节点补发缺少的数据,每次数据增量同步
心跳:主从有长连接心跳,主节点默认每10S向从节点发ping命令,repl-ping-slave-period控制发送频率
主从复制缺点
a)主从复制,若主节点出现问题,则不能提供服务,需要人工修改配置将从变主
b)主从复制主节点的写能力单机,能力有限
c)单机节点的存储能力也有限
Redis哨兵机制(Sentinel)
1.哨兵机制(sentinel)的高可用
原理:当主节点出现故障时,由Redis Sentinel自动完成故障发现和转移,并通知应用方,实现高可用性。
整个过程只需要一个哨兵节点来完成,首先使用Raft算法(选举算法)实现选举机制,选出一个哨兵节点来完成转移和通知
2.哨兵的定时监控任务
a)每个哨兵节点每10秒会向主节点和从节点发送info命令获取最拓扑结构图,哨兵配置时只要配置对主节点的监控即可,通过向主节点发送info,获取从节点的信息,并当有新的从节点加入时可以马上感知到
b)每个哨兵节点每隔2秒会向redis数据节点的指定频道上发送该哨兵节点对于主节点的判断以及当前哨兵节点的信息,同时每个哨兵节点也会订阅该频道,来了解其它哨兵节点的信息及对主节点的判断,其实就是通过消息publish和subscribe来完成的
c)每隔1秒每个哨兵会向主节点、从节点及其余哨兵节点发送一次ping命令做一次心跳检测,这个也是哨兵用来判断节点是否正常的重要依据
d)客观下线:当主观下线的节点是主节点时,此时该哨兵3节点会通过指令sentinel is-masterdown-by-addr寻求其它哨兵节点对主节点的判断,当超过quorum(选举)个数,此时哨兵节点则认为该主节点确实有问题,这样就客观下线了,大部分哨兵节点都同意下线操作,也就说是客观下线
3.故障转移机制
a)由Sentinel节点定期监控发现主节点是否出现了故障
sentinel会向master发送心跳PING来确认master是否存活,如果master在“一定时间范围”内不回应PONG 或者是回复了一个错误消息,那么这个sentinel会主观地(单方面地)认为这个master已经不可用了
b) 当主节点出现故障,此时Sentinel节点共同选举了某个节点为领导,负载处理主节点的故障转移
c) 由选举出的领导者节点执行故障转移,过程和主从复制一样,但是自动执行
流程:
(1). 将slave-1脱离原从节点,升级主节点,
(2). 将从节点slave-2指向新的主节点
(3). 通知客户端主节点已更换
(4). 将原主节点(oldMaster)变成从节点,指向新的主节点