Redis集群之主从复制，读写分离（下）（六）

上一次呢我们讲到了redis的集群，还有redis的主从复制，读写分离的一些配置，那么接下来就接着上次还未完结的内容

上一次呢讲的是在正常的情况下redis服务在各个主机上的运行情况，那么接下来就是要介绍不正常的情况了。

假如说我们的redis的主库挂了或者是运行redis服务的服务器挂了，那么其余的redis从库是否会趁机上位还是忠于职守在slave的角色？那么接下来就为大家揭晓

首先启动redis服务，包括主库与从库

各个服务器上的redis服务均启动正常，那么接下来就是模拟redis主库宕机了

shutdown表示关闭redis服务
exit表示退出redis连接

那么接下来就是查看各个redis从库的角色以及连接状态了

我们可以看到，在从库中还是可以拿到数据的，说明redis主库挂了并不会影响redis从库的运行。但是看到master_line_status为down的时候，就知道这个时候的主库是挂了的，因为一开始的状态是up

那么如果redis主库的服务有重新启动了呢？redis从库会不会再次连接上主库？

首先启动redis主库，然后写入数据，这个时候发现从库的master_line_status的连接状态都是up了，并且可以取到在redis主库中写入的数据

那么这样子是不是很不好啊，假如是电商网站，然后突然间redis主库挂了，那么这个时候就只有redis从库服务在运行了。但是redis从库是只读的是不是就无法写入数据了，那么客户就无法下订单了。那么有没有什么方法，就是在redis主服务挂了之后我再从redis从库服务中挑选出一个比较优秀的来接替主库的位置

方案一：使用命令的方式

那么接下来呢我们就学习一个新的命令

slaveof no one

可以看到，命令执行之后，就立刻趁机上位了，那么另外一台从库是不是也要换一个新的老大啊

但是这个时候原来的redis主库有杀回来了呢？这个时候是不是另外两个就是有两个redis主库的服务了，但是原来的从库并不会回到这个主库上去，而是后面那两台自立规则。那么这个时候是不是很不好啊，我们想要的是只有一个redis主库服务，那么有没有什么解决方法呢？

那么接下来就是终极的解决方案

方案二：哨兵模式

哨兵模式是反客为主的自动版，能够jiankong 后台主机是否故障，如果故障了根据投票数自动将从库转换为主库

首先恢复原来的一主N从的环境

接下来就是配置了

在redis安装目录下新建sentinel.conf文件，名字绝不能错

编辑sentinel.conf文件， sentinel monitor 被监控数据库名字(自己起名字) 127.0.0.1 6379 1【上面最后一个数字1，表示主机挂掉后salve投票看让谁接替成为主机，得票数多少后成为主机】

接下来就是启动哨兵进行监控了，命令

redis-sentinel sentinel.conf

那么这个时候就是哨兵开始监控了

首先模拟主库宕机，关闭主库，并且观察哨兵输出的日志并且两个从库角色的变化

（这里需要等待片刻才可看到结果）大家可以看到，端口号为6381的redis从库立马变成了主库，而且端口号为6380的redis从库就跟着端口号为6381混了。

那么问题来了，如果原来的老大回来了呢，6381会不会让位呢？

（这里也许等待片刻）那么结果是原来的redis服务就变成从库了，连接着现在的端口号为6381的主库了。

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

OK，到这里就是我们redis主从复制，读写分离的全部介绍了

如果大家觉得有哪些地方看不懂或者我的描述有问题的话请留言提醒我，谢谢