Redis复制（Master/Slave）
是什么？
主从复制，主机数据更新后根据配置和策略，自动同步到备机的Master/Slave机制，Master以写为主，Slave以读为主。
能干嘛？
一半多用于读写分离，容灾恢复
怎么玩？
1、配从（库）不配主（库）
2、从库配置：
slaveof 主库IP 主库端口：每次与master断开之后，都需要重新连接，除非你配置进redis.conf文件
3、修改配置文件细节操作：
（1）拷贝多个redis.conf文件
剩下的操作都以redis6380.conf 为例
（2）开启daemonize yes
（3）pid文件名字
（4）指定端口
（5）Log文件名字
（6）Dump.rdb名字
我们可以看到我们已经模拟出三台机器来进行主从复制：
第一个命令 info replication，我们可以看到三台机器都是master
我们将6379作为主机，先输入两个key，剩下两台机器先不动：
然后我们使剩下的两台机器做从机：
然后我们在6379这边再键入一个key，可以看到两台从机都可以获得主机所写入的key：
那么在它们做从机之前主机写入的数据能不能拿得到？答案是能：
由此我们可以知道，在做从机的那一瞬间，它就已经把主机上的所有数据都备份了一遍
这时候我们再看它们的信息：
那么从机能否写入key呢？答案是不能，只有主机能写，从机只能进行读操作：
那主机挂掉了，从机会怎么办？会有一个趁机翻身变成主机还是老老实实的待命？
答案是老老实实待命：
而且就算主机挂掉，你从机也不能进行写操作，只要你的身份是slave，你就不能做读以外的任何操作：
主机恢复了，从机就会跟主机自动建立连接：
如果从机挂掉了又恢复了，那它还是从机吗？答：不是
我们可以看到6380这台机器挂掉了，这时候6379写入了一个key：
然后6380又恢复了，这时它的身份已经不是slave了，而且主机在这期间写入的数据它也拿不到：
这就是之前我们提到的只要从机断开连接，每次重新启动的时候都要重新建立主从关系，除非把它配置到redis.conf文件里面。
那么如果6379由主机突然变成从机了，6380和6381会如何应答？
我们可以看到，三台机器全部都变成slave了。而且没有一台机器能够写入数据。
这时候我们手动把6381从slave切换到master，可以看到6381是主机，6379是6381的从机，而6380又是6379的从机。。。：
上面这种情况就是薪火相传：
上一个Slave可以是下一个slave的Master，Slave同坐可以接受其他salves的连接和同步请求，那么该slave作为了链条中下一个master，可以有效减轻master的压力
中途变更转向：会清除之前的数据，重新建立拷贝最新的
slaveof 新主库IP 新主库端口
手动切换master：slaveof no one
主从复制的原理：
Slave 启动成功连接到master后会发送一个sync命令
Master接到命令启动后台的存盘进程，同时收集所有接收到的用于修改数据集命令，在后台进程执行完毕之后，master将传送整个数据文件到slave，以完成一次完全同步
全量复制：而slave服务在接收到数据库文件数据后，将其存盘并加载到内存中。
增量复制：Master继续将新的所有收集到的修改命令依次传给slave，完成同步，但是只要是重新连接master，一次完全同步（全量复制）将被自动执行。
接下来说一下最重要的主从复制模式：哨兵模式（sentinel）
是什么？能够后台监控主机是否故障，如果故障了根据投票数自动将从库转换为主库
怎么玩？
1、先建立一个一主多仆的主从复制，这里方便举例说明我们就使6379为主，6380，6381为从
2、安装目录下新建sentinel.conf文件，名字绝对不能错（我这里的安装目录就是/myredis）
3、配置哨兵，填写内容：
sentinel monitor 被监控主机名字（自己起名字）127.0.0.1 6379 1
上面最后一个数字1，表示主机挂掉后slave投票看让谁接替成为主机，得票数多少后成为主机
如图：
4、启动哨兵：Redis-sentinel /myredis/sentinel.conf
上述目录依照各自的实际情况配置，可能目录不同
现在我们让6379挂掉，然后看看80，81的状态：
可以看到他俩还是slave，但是别着急，sentinel正在进行投票选择，这需要一定的时间，我们切到哨兵的那个窗口，可以看到现在已经选出来master了：
然后我们再让6379启动，这时候会发现它刚开始还是master，过了一会就被sentinel自动配置成slave了：
然后我们再看6381，就会发现它有两台slave：
最后提一嘴，一组sentinel能够同时监控多个Master
复制的缺点：复制延迟
由于所有的写操作都是在Master上操作，然后同步更新到Slave上，所以从Master同步到Slave机器上有一定的延迟，当系统很繁忙的时候，延迟问题会更加严重，Slave机器数量的增加也会使这个问题更加严重。