本文主要是介绍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节点
这篇关于Redis主从和哨兵的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
