三、Redis主从复制和哨兵模式(windows版)

三、Redis主从复制和哨兵模式(windows版)。

1、背景

主从复制是什么？

是指将一台Redis服务器的数据,复制到其他的Redis服务器。前者称为主节点(masterleader) ,后者称为从节点(slavelfllower) ;数据的复制是单向的,只能由主节点到从节点。Master以写为主, Slave以读为主（默认是只读，可以设置成可写，但是不建议）。默认情况下,每台Redis服务器都是主节点 ，可以通过命令设置成别的主节点的从节点;且一个主节点可以有多个从节点(或没有从节点),但一个从节点只能有一个主节点。

主从复制的优点

1、解决单点故障的风险: 主从复制实现了数据的热备份,万一主机报废了，也不怕。当主节点出现问题时,可以由从节点提供服务,实现快速的故障恢复。    

2、负载均衡:在主从复制的基础上,配合读写分离,可以由主节点提供写服务,由从节点提供读服务(即写Redis数据时应用连接主节点,读Redis数据时应用连接从节点) ,分担服务器负载;尤其是在写少读多的场景下,通过多个从节点分担读负载,可以大大提高Redis服务器的并发量。

3、高可用基石:除了上述作用以外,主从复制 + 哨兵, 让Redis的高可用的更可靠。

缺点

复制的延迟：由于所有的写操作都是先在master上操作，然后同步更新到slave上，所以从master同步到slave机器有一定的延迟，当系统很繁忙的时候，延迟问题会更加严重，slave机器数量的增加也会使这个问题更加严重。

Redis主从复制能干些什么？

（1）读写分离

（2）容灾恢复

2、主从复制

1、弄3个Linux虚拟机，并且下载安装Docker，下载安装Redis，

启动各自的redis-cli。

2、查看角色，默认都是master。

（1）配从(库)不配主(库)，因为Redis默认就是主库，所以主库不用配置，只需配置从库。
（2）info replication   查看当前redis节点信息（是主还是从等等）

3、设置6380、6381为6379的从库。

注意：我们这里是以命令方式去关联主的，当前redis关闭即失效。如果想要重新启动还能关联主，那么需要再配置文件中配置。

slaveof 主库IP 主库端口
slaveof 主库IP 6379

4、测试。

测试redis的1主（79）2从（80、81）

（1）slave1、slave2是从头开始复制还是从切入点开始复制? 当前主机器上已经有了k1 k2 k3了，从机器才关联过来，那么在从机器上能拿到k1 k2 k3吗？

测试：

主服务器先写key，从服务再去关联主服务器，去拿key。

答案是可以的！！！从机器关联主机器时，会将主机器所有key都copy一份给从机器。

（2）从机是否可以写？set可否？主服务器是否可以读呢？get可否

测试：

在从机上写：redis会提示你只是一个从机，是只能读不能写。

在主机上读：可以读，主机可读可写

（3）主机shutdown后情况如何？从机是上位还是原地待命

测试：通过客户端输入命令关闭主机（或者直接在服务端关闭ctrl+c）

查看从机状态：

可以看到，从机状态还是没有改变，从机是在原地待命。同时，从机还在正常工作，还能查询。

（4）主机又回来了后，主机新增记录，从机还能否顺利复制？

测试：从新启动主机，写入一个k5。

在从机上获取k5：

得出结论：主机回来后并且新增记录，从机能顺利复制主机上的数据。说明，主从关系还在。

（5）其中一台从机down后情况如何？依照原有它能跟上大部队吗？

测试：关闭从机，重新启动从机。

主机写入k6，从机上获取k6，会发现是不行的。

为什么呢？安装的时候已经说了：

（注意：我们这里是以命令方式去关联主的，当前redis关闭即失效。如果想要重新启动还能关联主，那么需要再配置文件中配置，或者手动关联。

建议手动关联，自己会对系统有更深的了解。）

3、薪火相传

slaveof 新主库IP 新主库端口

我这里还是拿之前配好的6379,6380,6381来做案例。

主机：6379

从机：6380,6381

将6381指向6379改成执行6380,。6380还是指向6379（不变）。

此时，6381的主从信息：

此时，6380的主从信息：

可以看到6380端口的redis还是slave，但是它底下有一个slave，正是6381，好的现在我们已经配置成功了。

测试一下：在6379下修改个值，6380上一定是可以取到的，看看6381上能不能取到

ok，6381上也是可以拿到值的，那么薪火相传成功！！！！

意义：一旦主机挂掉，设置下面的第一层slave为master，第二层的slave会自动关联到第一层的slave，减少主从配置。

4、反客为主

什么是反客为主？

当主机宕机了，那么我们可以手动的停止从机与主机的同步，将从机转成主机。再将其他的从机与当前这台主机同步数据，另成一个体系。

命令介绍：

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上可以读取到。

并且，之间从主机79拷贝过来的数据，还保留着。

5、哨兵模式(sentinel)

什么是哨兵模式？

反客为主的自动版，能够后台监控主机是否故障，如果故障了根据投票数自动将从库转换为主库。

实现哨兵模式

我们还是使用6379,6380,6381机器来演示。

（先调回1主2从情况，这里就不演示了。）

主机：6379

从机：6380，6381

弄第四台Linux虚拟机，安装docker、下载redis镜像

（1）在/目录创建一个名为sentinel.conf的文件，并写入内容

 sentinel monitor 被监控主库名字(自设) 主库ip 6379 1
 sentinel monitor 132-6379 主库ip 6379 1
sentinel monitor 132-6379 192.168.204.132 6379 1

上面最后一个数字1，表示主机挂掉后salve投票看让谁接替成为主机，得票数多的redis成为主机。

（2）启动redis（redis容器中已经包含了哨兵）

docker run -itd --name redis -p 6379:6379 -p 26379:26379 redis

哨兵的通讯端口是26379.

（3）启动哨兵

先把centos7 根目录下的sentinel.conf文件拷贝到容器

redis-sentinel sentinel.conf

哨兵测试

（1）原有的master挂了，会怎么样？

好的，我们测试一下，我们手动让6379挂掉，看下哨兵会怎么处理。

模拟6379宕机：（手动让6379宕掉）

稍等一会（1分钟），看到哨兵日志：

这里已经检测到6379主机宕机，那么就会投票选出一个主机，这里可以看到的是选出的主机是6380。

我们去看下6380和6381的信息

6380：

6381：

以上截图已经可以看到，6380已经成了主机，而且6381已经改变了关联的主机，改成选举出来的6380了。

（2）如果之前的master重启回来，会不会双master冲突？

测试开始： 重新启动6379端口的redis，查看它的信息，看一看是什么情况。

可以看到6379变成了slave，主机是6380。

总结：之前的master重新启动后，并不会冲突，会以从机的身份来关联主机。