Redis主从和哨兵

目录

开启主从关系（两种）

 数据同步原理

全量同步

增量同步

哨兵的作用和原理

服务状态监控

 故障转移步骤

---

开启主从关系（两种）

修改配置文件（永久生效）：

        在redis.conf中添加一行配置：slaveof  <masterip>  <masterport>

使用redis-cli客户端连接到redis服务，执行slaveof命令（重启后失效）：

        slaveof  <masterip> <masterport>

注意：在5.0后新增命令replicaof，与salveof效果一致。

步骤：

先进入客户端7001：redis-cli -p 7002  

执行 ：SLAVEOF  ip  端口号（SLAVEOF  192.168

150..101  7001）表示 7002的服务是7001的从节点

之后在主节点上可以进行写，从节点也可以拿到值，完成了主从数据同步。但如果在从节点上写，会报错，天然实现读写分离。

 数据同步原理

master判断slave是不是第一次来同步数据，用到两个概念：

Replication id：简称replid，是数据集的标记，id一致则说明是同一数据集。每一个master都有一个唯一的replid，slave则会继承master节点的replid。

offset：偏移量，随着记录在repl_backlog中的数据增多而逐渐增大。slave完成同步时也会记录当前同步的offset。如果slave的offset小于master的offset，说明slave数据落后于master，需要更新。

因此主从第一次同步时全量同步时，需要判断是否是第一次：

在1.1请求数据同步时需要带上replid offset

1.2判断请求replid是否一致

全量同步

1.slave节点请求增量同步

2.master节点判断replid，发现不一致，拒绝增量同步

3.master将完整内存数据生成RDB，发送RDB到slave

4.slave清空本地数据，加载master的RDB

5.master将RDB期间的命令记录在repl——baklog，并持续将log中的命令发送给slave

6.slave执行接收到命令，保持与master之间的同步。

 

增量同步

如果slave重启后同步，则执行增量同步 

由于repl——baklog大小有上限，写满后会覆盖最早的数据。如果slave断开时间过久，导致尚未备份的数据被覆盖，则无法基于log做增量同步，只能再次全量同步。

主同步优化：

• 在master中配置repl-diskless-sync yes 启用无磁盘复制，避免全量同步时的磁盘IO（直接写入网络，前提网络需要很快）；
• Redis节点上的内存占用不要太大，发现slave宕机时尽快实现故障恢复，尽可能避免全量同步。
• 适当提高repl——baklog大小，发现slave宕机时尽快实现故障恢复，尽可能避免全量同步。
• 限制一个master上的slave节点数量，如果实在时太多slave，则可以采用主-从-从链式结构，减少master压力。

全量同步和增量同步的区别：

全量同步：需要一次RDB文件生成和传输，将RDB文件传输给slave。后续命令记录在repl_baklog，逐个发送给slave。

增量同步：slave提交自己的offset到master，master获取repl_baklog中从offset之后的命令给slave。

何时执行全量同步？

slave节点第一次连接master节点时

slave节点断开时间太久，repl_baklog中的offset已经被覆盖时。

什么时候执行增量同步？

slave节点断开又恢复，并在repl_baklog中能找到offset时。

哨兵的作用和原理

 Redis提供了哨兵（Sentinel）机制来实现主从集群的自动故障恢复。

哨兵的作用有如下几个：

监控：Sentinel会不断检查master和slave是否按预期工作。

自动故障恢复：如果master故障，Sentinel会将一个slave提升为master。当故障实例恢复后也以新的master为主

通知：Sentinel充当Redis客户端的服务发现来源，当集群发生故障转移时，会将最新信息推送给redis的客户端。

服务状态监控

Sentinel基于心跳机制检测服务状态，每隔1秒向集群的每个实例发送ping命令：

主观下线：如果某sentinel节点发现某实例未在规定时间相应，则认为该实例主管下线。

客观下线：若超过指定数量的sentinel都认为 该实例主观下线，则该实例客观下线。quorum值最好超过Sentinel实例数量的一半。 

 故障转移步骤

（选举新的master）

当发现master故障，sentinel需要再salve中选择一个作为新的master，选择依据：

首先会判断slave节点与master节点断开时间长短，如果超过指定值（down-after-millisecon*10）则会排除该slave节点

然后判断slave节点的slave-priority值，越小优先级越高，如果是0则永不参与选举

如果slave-prority一样，则判断slave节点的offset值，越大说明数据越新，优先级越高

最后是判断slave节点的，当做故障节点恢复后会自动成为新的master的slave节点