如果单机情况下，机器重启，内存数据丢失，如何保证数据的高可用呢？持久化方案如果机器硬盘坏掉，如何保证数据的高可用呢？主从复制Redis的主从机制：主负责读写，从一般只读不能写（客户端）。
持久化保证了即使 Redis 服务重启也不会丢失数据，因为 Redis 服务重启后会将硬盘上持久化的数据恢复到内存中，但是当 Redis 服务器的硬盘损坏了可能会导致数据丢失，不过通过 Redis 的主从复制机制就可以避免这种单点故障，如下图：
说明：
主 Redis 中的数据有两个副本（ replication ）即从 redis1 和从 redis2 ，即使一台 Redis 服务器宕机其它两台 Redis 服务也可以继续提供服务。主 Redis 中的数据和从 Redis 上的数据保持实时同步，当主 Redis 写入数据时通过主从复制机制会复制到两个从 Redis 服务上。只有一个主 Redis ，可以有多个从 Redis 。主从复制不会阻塞 master ，在同步数据时， master 可以继续处理 client 请求。一个 Redis 可以即是主又是从，如下图：
主从配置 主Redis配置无需特殊配置
从Redis配置修改从服务器上的 redis.conf 文件：
实现原理 Redis 的主从同步，分为全量同步和增量同步。只有从机第一次连接上主机是全量同步。断线重连有可能触发全量同步也有可能是增量同步（ master 判断 runid 是否一致）。除此之外的情况都是增量同步。全量同步
Redis 的全量同步过程主要分三个阶段：
同步快照阶段： Master 创建并发送快照给 Slave ， Slave 载入并解析快照。 Master 同时将此阶段所产生的新的写命令存储到缓冲区。同步写缓冲阶段： Master 向 Slave 同步存储在缓冲区的写操作命令。同步增量阶段： Master 向 Slave 同步写操作命令。增量同步
Redis 增量同步主要指 Slave 完成初始化后开始正常工作时， Master 发生的写操作同步到 Slave 的过程。通常情况下， Master 每执行一个写命令就会向 Slave 发送相同的写命令，然后 Slave 接收并执行。 Redis 哨兵机制Redis 主从复制的缺点：没有办法对 master 进行动态选举，需要使用 Sentinel 机制完成动态选举。
简介 Sentinel (哨兵)进程是用于监控 Redis 集群中 Master 主服务器工作的状态在 Master 主服务器发生故障的时候，可以实现 Master 和 Slave 服务器的切换，保证系统的高可用（ HA ）其已经被集成在 redis2.6+ 的版本中， Redis 的哨兵模式到了 2.8 版本之后就稳定了下来。 哨兵进程的作用 监控( Monitoring ): 哨兵( sentinel ) 会不断地检查你的 Master 和 Slave 是否运作正常。提醒( Notification )： 当被监控的某个 Redis 节点出现问题时, 哨兵( sentinel ) 可以通过API 向管理员或者其他应用程序发送通知。自动故障迁移( Automatic failover )：当一个 Master 不能正常工作时，哨兵( sentinel )会开始一次自动故障迁移操作 故障判定原理分析 每个 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 主服务器的主观下线状态就会被移除。 自动故障迁移 它会将失效 Master 的其中一个 Slave 升级为新的 Master , 并让失效 Master 的其他 Slave 改为复制新的 Master ；当客户端试图连接失效的 Master 时，集群也会向客户端返回新 Master 的地址，使得集群可以使用现在的 Master 替换失效 Master 。Master 和 Slave 服务器切换后， Master 的 redis.conf 、 Slave 的 redis.conf 和 sentinel.conf 的配置文件的内容都会发生相应的改变，即， Master 主服务器的 redis.conf配置文件中会多一行 slaveof 的配置， sentinel.conf 的监控目标会随之调换。 案例演示修改从机的 sentinel.conf ：
其他配置项说明sentinel.conf
通过 redis-sentinel 启动哨兵服务
到此这篇关于Redis6 主从复制及哨兵机制的实现的文章就介绍到这了,更多相关Redis6 主从复制及哨兵机制内容请搜索七叶笔记以前的文章或继续浏览下面的相关文章希望大家以后多多支持七叶笔记！
