之前讲了redis的持久化，持久化保证了即使 redis 服务重启也不会丢失数据，因为 redis 服务重启后会将硬盘上持久化的数据恢复到内存中，但是当 redis 服务器的硬盘损坏了可能会导致数据丢失，如果通过 redis 的主从复制机制就可以避免这种’单点故障’。
Redis主从复制
主从复制：主节点负责写数据，从节点负责读数据，主节点定期把数据同步到从节点保证数据的一致性
Redis主从拓扑：
1.一主一从：用于主节点故障转移从节点，当主节点的“写”命令并发高且需要持久化，可以只在从节点开启AOF（主节点不需要），这样即保证了数据的安全性，也避免持久化对主节点的影响
2.一主多从：针对“读”较多的场景，“读”由多个从节点来分担，但节点越多，主节点同步到多节点的次数也越多，影响带宽，也加重主节点的稳定
3.树状主从：一主多从的缺点（主节点推送次数多压力大）可用些方案解决，主节点只推送一次数据到从节点B，再由从节点B推送到C，减轻主节点推送的压力。
主 redis 中的数据有多个个副本（replication）即从 redisB和从 redisC等，即使一台 redis 服务器宕机其它多台 redis 服务也可以继续提供服务。
主从复制不会阻塞 master，在同步数据时，master 可以继续处理 client 请求。
一个 redis 可以即是主又是从。
主从复制原理
数据同步
主从复制过程:
redis 2.8版本以上使用psync命令完成同步，过程分“全量”与“部分”复制
全量复制（完整复制）：一般用于初次复制场景（第一次建立SLAVE后全量）
复制过程说明：
slave 服务启动，slave 会建立和 master 的连接，发送 sync 命令。
master 启动一个后台进程将数据库快照保存到 RDB 文件中
注意：此时如果生成 RDB 文件过程中存在写数据操作会导致 RDB 文件和当前主 redis 数据不一致，所以此时 master 主进程会开始收集写命令并缓存起来。
master 就发送 RDB 文件给 slave
slave 将文件保存到磁盘上，然后加载到内存恢复
master 把缓存的命令转发给 slave
注意：后续 master 收到的写命令都会通过开始建立的连接发送给 slave。
当 master 和 slave 的连接断开时 slave 可以自动重新建立连接。如果 master 同时收到多个 slave 发来的同步连接命令，只会启动一个进程来写数据库镜像，然后发送给所有 slave。
完整复制的问题：
在 redis2.8 之前从 redis 每次同步都会从主 redis 中复制全部的数据，如果从 redis 是新创建的从主 redis 中复制全部的数据这是没有问题的，但是，如果当从 redis 停止运行，再启动时可能只有少部分数据和主 redis 不同步，此时启动 redis 仍然会从主 redis 复制全部数据，这样的性能肯定没有只复制那一小部分不同步的数据高。
部分复制：网络出现问题，从节点再次连接主节点时，主节点补发缺少的数据，每次数据增量同步
部分复制说明：
从机连接主机后，会主动发起 PSYNC 命令，从机会提供 master 的 runid(机器标识，随机生成的一个串) 和 offset（数据偏移量，如果offset主从不一致则说明数据不同步），主机验证 runid 和 offset 是否有效，runid 相当于主机身份验证码，用来验证从机上一次连接的主机，如果 runid 验证未通过则，则进行全同步，如果验证通过则说明曾经同步过，根据 offset 同步部分数据。
心跳：主从有长连接心跳，主节点默认每10S向从节点发ping命令，repl-ping-slave-period控制发送频率.
主从的缺点
1)主从复制，若主节点出现问题，则不能提供服务，需要人工修改配置将从变主
2)主从复制主节点的写能力单机，能力有限
3)单机节点的存储能力也有限
主从故障如何故障转移
1)主节点(master)故障，从节点slave-1端执行 slaveof no one后变成新主节点；
2)其它的节点成为新主节点的从节点，并从新节点复制数据；
3)需要人工干预，无法实现高可用。
因为主从复制的缺陷无法实现高可用性，所以接下来会讲到高可用的哨兵机制。
Redis哨兵机制（Sentinel）
哨兵机制的出现是为了解决主从复制的缺点的
哨兵机制(sentinel)的高可用
原理：当主节点出现故障时，由Redis Sentinel自动完成故障发现和转移，并通知应用方，实现高可用性。
其实整个过程只需要一个哨兵节点来完成，首先使用Raft算法（选举算法）实现选举机制，选出一个哨兵节点(来当主人master)完成转移和通知。
哨兵的定时监控任务
任务1：每个哨兵节点每10秒会向主节点和从节点发送info命令获取最拓扑结构图，哨兵配置时只要配置对主节点的监控即可，通过向主节点发送info，获取从节点的信息，并当有新的从节点加入时可以马上感知到
任务2：每个哨兵节点每隔2秒会向redis数据节点的指定频道上发送该哨兵节点对于主节点的判断以及当前哨兵节点的信息，同时每个哨兵节点也会订阅该频道，来了解其它哨兵节点的信息及对主节点的判断，其实就是通过消息publish和subscribe来完成的
任务3：每隔1秒每个哨兵会向主节点、从节点及其余哨兵节点发送一次ping命令做一次心跳检测，这个也是哨兵用来判断节点是否正常的重要依据
客观下线：当主观下线的节点是主节点时，此时该哨兵3节点会通过指令sentinel is-masterdown-by-addr寻求其它哨兵节点对主节点的判断，当超过quorum（选举）个数，此时哨兵节点则认为该主节点确实有问题，这样就客观下线了，大部分哨兵节点都同意下线操作，也就说是客观下线
领导者哨兵选举流程
1)每个在线的哨兵节点都可以成为领导者，当它确认（比如哨兵3）主节点下线时，会向其它哨兵发is-master-down-by-addr命令，征求判断并要求将自己设置为领导者，由领导者处理故障转移；
2)当其它哨兵收到此命令时，可以同意或者拒绝它成为领导者；
3)如果哨兵3发现自己在选举的票数大于等于num(sentinels)/2+1时，将成为领导者，如果没有超过，继续选举…………
故障转移机制
1)由Sentinel节点定期监控发现主节点是否出现了故障
sentinel会向master发送心跳PING来确认master是否存活，如果master在“一定时间范围”内不回应PONG 或者是回复了一个错误消息，那么这个sentinel会主观地(单方面地)认为这个master已经不可用了
2)当主节点出现故障，此时3个Sentinel节点共同选举了Sentinel3节点为领导，负载处理主节点的故障转移
3) 由Sentinel3领导者节点执行故障转移，过程和主从复制一样，但是自动执行
流程：
1. 将slave-1脱离原从节点，升级主节点，
2. 将从节点slave-2指向新的主节点
3. 通知客户端主节点已更换
4. 将原主节点（oldMaster）变成从节点，指向新的主节点
4)故障转移后的redis sentinel的拓扑结构图
哨兵机制－故障转移详细流程-确认主节点
-
过滤掉不健康的（下线或断线），没有回复过哨兵ping响应的从节点
-
选择salve-priority从节点优先级最高（redis.conf）的
-
选择复制偏移量最大，指复制最完整的从节点
希望这些理论知识能给大家带来一些帮助。接下来的博客会将到怎么样具体实现redis的主从复制（读写分离）和哨兵机制。
redis----实现数据库服务器的高可用
nginx----实现应用服务器(tomcat)的高可用