1. Redis主从复制
1.1 Redis主从复制
Redis主从复制主要有两个角色,主机(master)对外提供读写功能,从机(slave)对外只提供读功能,主机定期把数据同步到从机上保证数据一致性。
Redis主机数据同步到从机上有两种方式,一种是全量同步,另一种是增量同步。
主从复制不会阻塞master,在数据同步时,master还可以继续处理客户端请求,因为redis会产生一个新的进程来解决同步问题。
一个redis也可以是从也可以是主(树状主从),可以减轻主机压力。
1.2 Redis主从配置
只需要修改从服务器上的redis.conf文件:
# slaveof 《masterip》 《masterport》
# 表示当前【从服务器】对应的【主服务器】的IP是192.168.10.135,端口是6379。
slaveof 192.168.10.135 6379
启动主服务器 redis-server redis.conf
进入从服务器文件夹,启动从服务器
查看主服务器信息:redis-cli -p 6379 info Replication,可以看到有几个从服务器
1.3 实现原理
redis的主从同步分为两种,分为全量同步和增量同步。
只有从机第一次连接上主机是全量同步。
断线重连很有可能触发全量同步也有可能是增量同步(master判断runid`是否一致)。
runid
每个redis服务器,不论主服务器还是从服务,都会有自己的运行id。PSYNC runid 这个命令,runid是指上一次复制主服务器的运行id,如果没有保存这个id,PSYNC的命令会使用”PSYNC ? -1” 这种形式发送给Master,请求主服务器进行全量复制。
offset(复制偏移量)
主服务器和从服务器会分别维护一个复制偏移量,主服务器每次向从服务器传播N个字节的数据时,就将自己的复制偏移量的值加上N,从服务器每次收到主服务器传播来的N个字节的数据时,就将自己的复制偏移量值加上N。
复制积压缓冲区
复制积压缓冲区是由主服务器维护一个固定长度(fixed-size)先进先出(FIFO)队列,默认大小是1MB。它主要的作用就是当主服务器进行命令传播时,不仅将命令发送给所有从服务器,还会将命令入队到复制积压缓冲区。如果主服务器向从服务器传播数据时发生断线,主服务器会将复制积压缓冲区偏移量的所有数据都发送给从服务器(发送的是断线之后的的数据)。
PSYNC执行过程
1.Slave接受从客户端发送过来的SLAVEOF命令。
当前服务器判断自己是否保存Master runid是否是第一次复制。
如果是第一次复制那么当前服务器向Master发送PSYNC ? -1命令,主动请求Master进行全量同步。
如果已经父之过Master,那么当前从服务器向Master发送PSYNC runid offset命令。
Master接收到PSYNC 命令后首先判断runid是否和本机的id一致,如果runid和本机id不一致则返回+FULLRESYNC runid offset命令执行全量同步操作,当前服务器会将runid保存起来,在下次发送PSUNC时使用。
如果判断runid和本机id一致,Master则会再次判断offset偏移量和本机的偏移量相差有没有超过复制积压缓冲区大小,如果没有那么就给Slave发送CONTINUE,此时Slave只需要等待Master传回失去连接期间丢失的命令;
全量同步
Redis的全量同步主要分为三个阶段:
同步快照阶段:Master创建并发送快照给Slave,Slave再入快照并解析。Master同时将此阶段产生的新的命令写入到积压缓冲区中。
同步写缓冲阶段:Master向Slave同步存储在缓冲区的写操作命令。
同步增量阶段:Master向SLave同步写操作命令。
增量同步
Redis增量同步主要是指Slave完成初始化开始正常工作时,Master发生的写操作同步到Slave的过程。
通常情况下,Master没执行一个写命令就会想Slave发送相同的写命令,然后Slave接受并执行。
2. 哨兵(sentinel)机制
2.1 哨兵机制介绍
sentinel进程是用于监控Redis集群中Master主服务器工作的状态。
在Master主服务器发生故障的时候,可以实现Master和Slave服务器的切换,保证系统的高可用。
2.2 为什么要有哨兵机制?
Redis主从复制的缺点:没有办法对master进行动态选举,需要使用Sentinel机制完成动态选举。
2.3 哨兵的作用
监控(Monitoring):sentinel会不断检查Master和Slave是否运行正常。
提醒(Notification):当被监控的某个Redis节点出现问题时, sentinel 可以通过 API向管理员或者其他应用程序发送通知。
自动故障转移(Automatic failover):当Master不能正常操作时哨兵会开始一次故障转移。 它会将失效的Master的其中一个Slave升级为新的Master,并让其他Slave改为复制新的Master。 当客户端试图连接失效的Master时,集群会向客户端显示新的Master的地址。 Master和Slave切换后,Master的redis.conf、Slave的reids.conf和senisentinel的sentinel.conf配置文件的内容都会相应的改变,即,Master主服务器的redis.conf配置文件中会多一行slaveof的配置,sentinel.conf的监控目标会随之调换。
2.4 故障判断原理分析
每个sentinel进程每秒钟一次的频率向整个集群中Master、Slave以及其它Sentinel进程发送一个PING命令。
如果一个实例(instance)距离最后一次有效回复PING命令超过down-after-milliseconds选项所指定的值,这个实例会被sentinel进程标记为主观下线(SDOWN)。
如果一个Master主服务器被标记为主观下线(SDOWN),则正在监视这个Master主服务器的所有 Sentinel进程要以每秒一次的频率确认Master主服务器的确进入了主观下线状态。
当有足够数量的 Sentinel进程(大于等于配置文件指定的值)在指定的时间范围内确认Master主服务器进入了主观下线状态(SDOWN), 则Master主服务器会被标记为客观下线(ODOWN)。
在一般情况下, 每个 Sentinel进程会以每 10 秒一次的频率向集群中的所有Master主服务器、Slave从服务器发送 INFO 命令。
当Master主服务器被 Sentinel进程标记为客观下线(ODOWN)时,Sentinel进程向下线的 Master主服务器的所有 Slave从服务器发送 INFO 命令的频率会从 10 秒一次改为每秒一次。
若没有足够数量的 Sentinel进程同意 Master主服务器下线, Master主服务器的客观下线状态就会被移除。若 Master主服务器重新向 Sentinel进程发送 PING 命令返回有效回复,Master主服务器的主观下线状态就会被移除。
-
服务器
+关注
关注
12文章
9129浏览量
85344 -
Redis
+关注
关注
0文章
374浏览量
10871
发布评论请先 登录
相关推荐
评论