上篇文章给大家介绍了Redis的主从复制，但是并没有介绍完整，本文继续主从复制的介绍
主从复制
上篇文章搭建的主从结构图
本文我们换种结构
具体实现
实现方式也很简单，我们只需要在6381上执行如下命令即可
127.0.0.1:6381> slaveof 127.0.0.1 6380 OK
查看6379节点信息
在6380上查看
在6381上查看
如此6380是一个从机，而6380还有一个slave是6381.至此实现了我们上面的结构图
测试
复制数据没有问题
哨兵模式
结合上篇文章我们给大家介绍了两种主从复制的模式，但是我们发现不论是哪种模式，一旦master宕机了，那么整合服务就不可以使用了，此时我们希望系统能在还运行的slave中从新选举新的节点作为mater这样我们就不用重启服务了。能够显著的提高我们系统的稳定性，这里就需要用到我们将要介绍的哨兵模式。
主从复制环境
我们还是一主两从，按照上篇文章的结构来实现。
哨兵模式配置
修改和redis.conf同级目录下的sentinel.conf文件
sentinel monitor mymaster 127.0.0.1 6379 1
mymaster 是要监控的主机名 可以随意的取
最后的1 表示的是哨兵投票通过的最低票数，我们开启一个哨兵进程的话投票就给1。
启动哨兵模式
先关闭主从服务，然后开启哨兵模式
src/redis-sentinel sentinel.conf
再分别启动主从服务器
[root@hadoop-node01 redis-5.0.3]# src/redis-server redis6379.conf [root@hadoop-node01 redis-5.0.3]# src/redis-cli -p 6379 [root@hadoop-node01 redis-5.0.3]# src/redis-server redis6380.conf [root@hadoop-node01 redis-5.0.3]# src/redis-cli -p 6380 127.0.0.1:6380> slaveof 127.0.0.1 6379 [root@hadoop-node01 redis-5.0.3]# src/redis-server redis6381.conf [root@hadoop-node01 redis-5.0.3]# src/redis-cli -p 6381 127.0.0.1:6381> slaveof 127.0.0.1 6379
关闭6379master测试
查看6379状态
关闭6379等待一会查看哨兵进程界面
当看到如上图的信息后，我们再查看6380的时候，发现该节点已经变成了master了。
再启动6379我们发现该实例依然是slave并不会改变
注意在主从复制中所有的写入操作都是在master实例上进行的，然后再将信息同步到slave上，这就存在一定的信息延迟，在系统非常繁忙的时候延迟会更加的严重，增加slave也会存在这个问题，因此在实际开发中我们需要通过集群(cluster)来进一步提升redis的性能，下篇文章将给大家介绍redis的集群操作。
~本文介绍到此
