一、Redis主从复制介绍:
主从复制，master主机以写为主，slave从机以读为主，当主机数据变化的时候自动将新的数据异步同步到其他从机数据库；能够实现读写分离， 容灾恢复、 数据备份以及水平扩容支撑高并发
二、实现方法:配从不配主
主机如果配置了requirepass参数，需要密码登录，那么从机就要配置masterauth来设置校验密码，否则主机会拒绝从机的访问请求
(1)info replication:可以查看复制节点的主从关系和配置信息
(2)replicaof 主机IP 主库端口:一般写入redis.conf配置文件内
(3)slaveof 主库IP 主库端口:每次与master断开后都需要重新连接，除非配置进redis.conf文件；在运行期间修改slave节点的信息，如果该数据库已经是某个主数据库的从数据库，那么会停止和原主数据库的同步关系转而和新的主数据库同步
(4).slaveof no one:使当前数据库停止与其他数据库的同步，转成主数据库
三、三种主从类型:
(1)一主二从:
固定的配置文件:从机只能读取数据，不能执行写命令；主机shutdown后从机不变，从机数据可以正常使用，等待主机重启；主机shutdown重新启动后主从关系依旧存在，从机能够顺利复制；某台从机down后主机和另外一台从机继续执行，从机重启后能够继续从断点执行
如果使用命令的话主从关系只是当次生效，主机或从机重启后原先的状态便会改变
(2).薪火相传:
上一个slave可以是下一个slave的master，slave同样可以接收其他slaves的连接和同步请求，该slave作为链条中下一个的master可以有效减轻主master的写压力;会清除之前的数据，重新建立拷贝最新的;此时新的主机(原先的从机)依旧无法执行写命令
(3).反客为主:slaveof no one
四、主从复制的复制原理和工作流程:
1.slave启动，同步初请:slave启动成功连接到master后会发送一个sync命令，slave首次全新连接到master，一次完全同步将被自动执行，slave自身原有的数据会被master数据覆盖清除
2.首次连接，全量复制:master节点收到sync命令后会开始在后台保存快照，同时收集所有接收到的用于修改数据集命令缓存起来，master节点执行RDB持久化完后将rdb快照文件和所有缓存命令发送到slave，以完成一次完全同步；而slave服务在接收到数据库文件数据后将其存盘并加载到内存中，从而完成复制初始化
3.保持通信:repl-ping-replica-period 10
4.进入平稳，增量复制:master继续将新的所有收集到的修改命令自动依次传给slave，完成同步
5.从机下线，重连续传:master会检查backlog里面的offset，master和slave都会保存一个复制的offset还有一个masterID,offset是保存在backlog中的，master只会把已经复制的offset后面的数据复制给slave，类似断点续传
五、主从复制的缺点:
1.复制延时，信号衰减:所有的写操作都是先在Master上操作，然后同步更新到Slave上，所以从Master同步到Slave机器有一定的延迟，当系统很繁忙的时候延迟问题会更加严重，Slave机器数量的增加也会使这个问题更加严重。
2.主机挂掉后默认情况下不会在slave节点中自动重新选择一个master，需要人工干预
六、哨兵(sentinel)
1.哨兵介绍:
巡查监控后台master主机是否故障，如果故障了根据投票数自动将某一个从库转换为新主库，继续对外服务；作用是能够监控redis运行状态，包括master和slave，当master宕机后能够自动将slave切换成新的master
2.哨兵能够干什么?
(1).主从监控:监控主从redis库运行是否正常
(2).消息通知:哨兵可以将故障转移的结果发送给客户端
(3).故障转移:如果master异常，则会进行主从切换，将其中一个slave作为新的master
(4).配置中心:客户端通过连接哨兵获得当前redis服务的主节点地址
3.Redis Sentinel架构:共计六台机器
3个哨兵:自动监控和维护集群，不存放数据，只是吹哨人
1主2从:用于数据读取和存放
4.哨兵运行流程和选举原理:
当一个主从配置中的master失效之后，sentinel可以选举出一个新的master用于自动接替原master的工作，主从配置中的其他redis服务器自动指向新的master同步数据;一般建议sentinel采取奇数台，防止某一台sentinel无法连接到master导致误切换
(1).三个哨兵监控一主二从，正常运行
(2).SDown主观下线(Subjectively Down):SDOWN是单个sentinel自己主观上检测到的关于master的状态，从sentinel的角度来看，如果发送了PING后，在一定时间内没有收到合法的回复，就达到了SDOWN的条件；sentinel配置文件中的down-after-milliseconds设置了判断主观下线的时间长度
(3).ODown客观下线(Objectively Down):ODown需要一定数量的sentinel，多个哨兵达成一致意见才能认为一个master客观上已经宕机；quorum这个参数是进行客观下线的一个依据，法定人数/法定票数意思是至少有quorum个sentinel认为这个master有故才会对这个master进行下线以及故障转移。因为有的时候某个sentinel节点可能因为自身网络原因导致无法连接master，而此时master并没有出现故障，所以这就需要多个sentine都一致认为该master有问题，才可以进行下一步操作，这就保证了公平性和高可用。
(4).选举出领导者哨兵(哨兵中选出兵王):当主节点被判断客观下线后，各个哨兵节点会进行协商，先选举出一个领导者哨兵节点，并由该领导者节点进行故障迁移；采用Raft算法
(5).由领导者哨兵推动故障切换流程并选举出一个新的master：
a.某个slave被选中成为新的master:在剩余slave节点健康的前提下，redis.conf文件中优先级slave-priority或者replica-priority最高的从节点；复制偏移位置offset最大的从节点，最小Run ID的从节点
b.执行slaveof no one命令让选出来的从节点成为新的主节点，并通过slaveof命令让其他节点成为其从节点；sentinel leader会对选举出的新master执行slaveof no one操作，将其提升为master节点；sentinel leader向其他slave发送命令，让剩余的slave成为新的master节点的slave
c.将之前已下线的老master设置为新选出的新master的从节点，当老master重新上线后会成为新的master的slave，sentinel leader会让原来的master降级为slave并恢复正常工作
5.哨兵使用建议:
a.哨兵节点的数量应该为多个，哨兵本身应该集群，保证高可用
b.哨兵节点的数量应该是基数
c.各个哨兵节点的配置应该一致
d.如果哨兵节点部署在docker容器里面，注意端口的正确映射
e.哨兵集群和主从复制并不能够保证数据的零丢失