Redis主从复制是什么？
行话：也就是我们所说的主从复制，主机数据更新后根据配置和策略，
自动同步到备机的master/slaver机制，Master以写为主，Slave以读为主
Redis主从复制能干些什么？
（1）读写分离
（2）容灾恢复
Redis配置主从复制（1主2从）
知识注意：
（1）配从(库)不配主(库)
（2）从库配置：slaveof 主库IP 主库端口
（3）info replication查看当前redis节点信息（是主还是从等等）
redis配置1主2从
开始配置：
这里做演示是装在一台机器上，方便学习（生产环境是装在不同机器上的）
我们这里并不安装三个redis，而是已copy三个配置文件来区分。
分别是：redis6379.conf，redis6380.conf，redis6381.conf
修改配置文件内容：（这里的修改都是为了区分不同机器，6379就是端口号）
daemonize yes：开启后台启动
pid /var/run/redis6379.pidpid文件以端口号来区分
P ort 6379指定端口
logfile "redis6379.log"指定log文件名字
dbfilename dump6379.rdb这里使用的是rdb持久化方式，那么就修改rdb快照文件名
（每个配置文件都需要修改）
修改好配置文件后，分别启动三个redis进程：
../bin/redis-server redis6379.conf
../bin/redis-server redis6380.conf
../bin/redis-server redis6381.conf
查看是否启动成功：
可以看到redis三个进程分别在6380,6381,6379三个端口号启动了。
分别连接这三个redis进程，查看当前redis状态：
6379端口：
6380端口：
6381端口：
现在可以看到，三个redis进程状态都是master，都没有slave。
开始主从复制配置：
一个master，两个slave。
定义：6379当master，6380和6381都为slave
可以看到我们只是注意的地方：配从(库)不配主(库)
好的，分别在6380和6381上的redis去关联6379的redis：
slaveof 127.0.0.1 6379
（注意：我们这里是以命令方式去关联主的，当前redis关闭即失效。如果想要重新启动还能关联主，那么需要再配置文件中配置。）
然后我们再查看6380和6381端口redis的状态：
可以看到两台主机都已经改成slave了，而且还标识出master的信息。
如果已经出现以上图片显示，那么代表1主2从配置成功了。
测试redis的1主2从
（1）slave1、slave2是从头开始复制还是从切入点开始复制?当前主机器上已经有了k1 k2 k3了，从机器才关联过来，那么在从机器上能拿到k1 k2 k3吗？
测试：
主服务器先写key
从服务再去关联主服务器，去拿key
答案是可以的！！！分析一下，应该是从机器关联主机器时，会将主机器所有key都copy一份给从机器
（2）从机是否可以写？set可否？主服务器是否可以读呢？get可否
测试：
在从机上写：redis会提示你只是一个从机，是只能读不能写。
在主机上读：可以读，主机可读可写
（3）主机shutdown后情况如何？从机是上位还是原地待命
测试：
主机shutdown：
查看从机状态：
可以看到，从机状态还是没有改变，从机是在原地待命
（4）主机又回来了后，主机新增记录，从机还能否顺利复制？
测试：
从新启动主机，写入一个k5
在从机上获取k5：
从机上获取k5成功。
得出结论：
主机回来后并且新增记录，从机能顺利复制主机上的数据。
（5）其中一台从机down后情况如何？依照原有它能跟上大部队吗？
测试：
关闭从机，重新启动从机。
主机写入k6，从机上获取k6，会发现是不行的。
为什么呢？安装的时候已经说了：
（注意：我们这里是以命令方式去关联主的，当前redis关闭即失效。如果想要重新启动还能关联主，那么需要再配置文件中配置。）
如果不相信可以去看下当前从机的状态，它已经变成master了。
这里就不贴截图了。
薪火相传
什么是薪火相传？
上一个slave可以是下一个slave的master，slave同样可以接收其他
slaves的连接和同步请求，那么该slave作为了链条中下一个的master,
可以有效减轻master的写压力。
注意：
中途变更转向:会清除之前的数据，重新建立拷贝最新的
设置薪火相传
slaveof 新主库IP 新主库端口
我这里还是拿之前配好的6379,6380,6381来做案例。
主机：6379
从机：6380,6381
将6381指向6380,。6380还是指向6379（不变）。
6381端口redis信息：
6380端口redis信息：
可以看到6380端口的redis还是slave，但是它底下有一个slave，正是6381，好的现在我们已经配置成功了。
测试一下：在6379下修改个值，6380上一定是可以取到的，看看6381上能不能取到
ok，6381上也是可以拿到值的，那么薪火相传成功！！！！
反客为主
什么是反客为主？
当主机中宕机了，那么我们可以手动的停止从机与主机的同步，将从机转成主机。再将其他的从机与当前这台主机同步数据，另成一个体系。
命令介绍：
slaveof no one使当前数据库停止与其他数据库的同步，转成主数据库。
反客为主案例：
假如现在主机挂掉了：这里是人为手动关闭，模拟挂掉
查看从机状态：
这里可以发现master的状态是down，那么现在将80端口redis设置为主机，81端口redis做80端口的从机：
slaveof no one使当前数据库停止与其他数据库的同步，转成主数据库。
Info replication查看当前redis的一个信息，可以发现当前已经是master了
再将81关联到80上，再查看当前81上的信息，就可以看到关联的master是80的redis了。
slaveof 127.0.0.1 6380
测试主从复制是否成功：
测试成功！！在80上写数据，在81上可以读取到。
Redis主从复制原理
全量复制：
slave启动成功连接到master后会发送一个sync命令
master接到命令启动后台的存盘进程，同时收集所有接收到的用于修改数据集命令，
在后台进程执行完毕之后，master将传送整个数据文件到slave,以完成一次完全同步
而slave服务在接收到数据库文件数据后，将其存盘并加载到内存中。
增量复制：
master继续将新的所有收集到的修改命令依次传给slave，完成同步。
注意：
（但是只要是重新连接master，回自动执行一次完全同步（全量复制)）
哨兵模式(sentinel)
什么是哨兵模式？
反客为主的自动版，能够后台监控主机是否故障，如果故障了根据投票数自动将从库转换为主库。
实现哨兵模式
我们还是使用6379,6380,6381机器来演示。
（先调回1主2从情况，这里就不演示了。）
主机：6379
从机：6380，6381
（1）在/usr/local/redis/conf下创建一个名为sentinel.conf的文件，并写入内容
sentinel monitor 被监控数据库名字(自己起一个名字) 127.0.0.1 6379 1
上面最后一个数字1，表示主机挂掉后salve投票看让谁接替成为主机，得票数多的redis成为主机
注意：这里要监控的是主机
（2）启动哨兵
这是我的目录：
bin下面就是redis的一些启动脚本。
config下是我copy出来的redis配置文件和刚刚创建的sentinel.conf
到config目录下执行命令启动哨兵：
../bin/redis-sentinel sentinel.conf
（注意：这里的命令根据不同的redis安装目录也是会不相同的。）
好的，如果看到以上打印出得图就是启动成功。可以看到已经在监控6379了，而且还找到了6379的从机器6380和6381。
哨兵测试
（1）原有的master挂了，会怎么样？
好的，我们测试一下，我们手动让6379挂掉，看下哨兵会怎么处理。
模拟6379宕机：（手动让6379宕掉）
稍等一会，看到哨兵日志：
这里已经检测到6379主机宕机，那么就会投票选出一个主机，这里可以看到的是选出的主机是6380。
我们去看下6380和6381的信息
6380：
6381：
以上截图已经可以看到，6380已经成了主机，而且6381已经改变了关联的主机，改成选举出来的6380了。
总结出：如果主机挂掉了，那么会在从机上投票选举出主机，并且修改剩余的从机关联到新的主机中。
（2）如果之前的master重启回来，会不会双master冲突？
测试开始：
重新启动6379端口的redis，查看它的信息，看一看是什么情况：
可以看到6379变成了slave，主机是6380。
而且启动6379时，哨兵打印出了一条日志：
意思：将从机6379关联到6380上。
总结：之前的master重新启动后，并不会冲突，会以从机的身份来关联主机。
注意：一组sentinel能同时监控多个Master
复制的缺点
复制的延迟：
由于所有的写操作都是先在master上操作，然后同步更新到slave上，所以从master同步到slave机器有一定的延迟，当系统很繁忙的时候，延迟问题会更加严重，slave机器数量的增加也会使这个问题更加严重。
好的。到了这里主从复制和哨兵模式完成！！！