Redis主从复制
单机有什么问题
单机故障、容量瓶颈、qps瓶颈。主机数据更新后根据策略和配置，自动同步到备机上。master以写为主，从以读为主。
默认情况下，Redis使用异步复制(低延迟和高性能)。也允许使用同步复制。客户端可以使用WAIT命令请求某些数据的同步复制，但是，WAIT命令仅能确保其他Redis实例中具有指定数量的已确认副本，它不会将一组redis实例转换为具有高度一致的CP系统，在故障转移期间，仍然会丢失已确认的写入，具体取决于关于redis持久性的配置。但是，使用wait在发生故障事件后丢失写操作的可能性会大大降低，从而很难触发某些故障模式。
当然，如果主服务器的持久性关闭时，会造成复制的安全性问题。所以应避免实例的自动重启。
redis主从复制配置
redis.conf
bind 192.168.0.104 ##指定本机ip
port 8000
daemonize yes
pidfile /var/run/redis_8000.pid
dir /myredis/redis8000
requirepass 123456
如果是伪主从，只需要新建多个同级文件放置redis.conf
如：./redis8000/redis.conf ./redis8001/redis.conf ./redis8002/redis.conf
1、批量替换redis.conf文件 %s/8000/8001/g %s/8000/8002/g
2、在redis.conf添加 replicaof 192.168.x.xx 8000
3、在redis.conf添加 masterauth 123456
然后，启动8000、8001、8002
redis-server ./redis8000/redis.conf
redis-server ./redis8001/redis.conf
redis-server ./redis8002/redis.conf
redis复制如何工作
1.slave(从)发送指令 psync master复制ID和到目前已处理的偏移量，这样主机可以只发送所需的增量部分。当然如果命令缓冲区积压不足，将会进行全量复制
2.master 执行bgsave 后台保存生成rdb文件，同时生成命令缓冲区缓存从客户端接收到的所有新写命令
3.在第一个salve连接时，创建命令缓存区
4.生成RDB文件，通过socket发送给slave
5.slave接收RDB，清空数据，执行RDB文件恢复过程 副本将其保存在磁盘，加载到内存
6.发送命令告知RDB恢复已经完成（告知全量复制完成）
7.master发送所有缓冲区信息命令到副本 这是作为命令流完成的
8.slave接收信息，执行重写后恢复数据
当主副本链接断开时，副本能够自动重连。如果主服务器接收到多个并发副本同步请求，将会执行一次后台保存，为所有请求提供服务
在命令传播阶段如果断网：
长时间断网 全量复制
段时间断网 增量
全量复制的要素：
1、主服务器的run_id
2、主服务器的命令缓冲区 是一个先进先出队列
3、主服务器复制偏移量 用于判断是执行增量还是全量复制
全量复制有哪些消耗：
1、bgsave时间
2、rdb文件网络传输时间
3、从节点请求数据时间
4、从节点加载时间
增量复制是从命令缓冲区进行复制
主从复制缺点
1、延迟：所有写操作都是在主服务器上操作，然后再同步到从
2、主机宕机后，需要手动处理
哨兵模式
核心功能是主节点的自动故障转移(解决主从复制的手动处理)
Redis Sentinel为Redis提供了高可用性，可以在无人工干预情况下抵抗某些类型的故障。Redis Sentinel提供的功能：
1、监控。不断检查主服务器和副本是否按预期工作
2、通知。可以通过API通知redis实例出了问题
3、自动故障转移。如果主服务器未按预期工作，则Sentinel启动自动故障转移，将副本升级为主服务器，其他副本重新配置使用新的主服务器，并通知redis的应用程序使用新地址
4、配置提供程序。Sentinel充当客户端服务发现的授权来源，询问主redis地址。如果发生故障转移报告新地址
部署哨兵节点
配置文件主要是端口不同，假设实例端口使用28000、28001、28002。8000运行redis主服务器，8001、8002运行从服务器
sentinel-28000.conf
port 28000
daemonize yes
logfile "28000.log"
sentinel monitor mymaster 127.0.0.1 8000 2
其他两个文件相同，但使用28001、28002端口号
sentinel monitor mymaster表示：该哨兵节点监控192.168.x.x 8000 主节点，该主节点的名称是mymaster。2表示至少需要两个哨兵同意才能判断主节点进行故障转移
启动方式
redis-sentinel sentinel-28000.conf
redis-server sentinel-28000.conf --sentinel
故障转移测试，只需要杀死主节点
jedis访问哨兵系统测试 可以使用JedisSentinelPool
哨兵原理
哨兵的原理，主要是以下几个基本概念
主观下线：在心跳检测的定时任务中，如果主节点超过一定时间没有回复，则当前哨兵节点就认为此节点下线
客观下线：如果一个哨兵节点对主节点进行主观下线后，会通过
sentinel is-master-down-by-addr命令询问其他哨兵节点这个主节点的状态。如果判断主节点下线的哨兵数量达到一定的值，则该主节点进行客观下线。
定时任务：每个哨兵节点维护了三个定时任务
1、每10s通过发送info命令获取最新的主从结构 发现slave节点、确认主从关系
2、每2s通过发布订阅功能获取其他哨兵节点信息 交互节点及自身信息情况
3、每1s通过向其他节点发送ping进行心跳检测，判断是否下线
选举领导者哨兵节点：一般是判断主观下线的节点(Raft算法，先到先得)，对主节点进行故障转移
故障转移步骤：
1、在从节点选择新的主节点。
选取原则：首先过滤掉不健康的从节点、过滤掉响应慢的节点、过滤掉与master断开时间最久的、优先原则(replica-priority指定的优先级、复制偏移量最大、选择runid最小的从节点)
2、更新主从状态：slaveof no one命令让选出来的节点成为主节点，并通过slaveof命令让其他节点成为从节点
3、对下线的主节点，如果重新上线后设置为新主节点的从节点
哨兵模式缺点：
无法对从节点进行故障转移 需要额外监控、切换操作
没有解决写操作的负载均衡
存储能力受单机限制
总结：
主从复制主要是全量复制和增量复制概念区别
主从复制与哨兵模式解决的问题及其缺点
哨兵模式是在主从复制的基础上解决主节点的自动故障转移