ps:若主宕机了，从会一直等待（后面会用 哨兵解决这个问题）
首先启动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从的环境
接下来就是配置了
编辑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机器数量的增加也会使这个问题更加严重。
ps：java 该如何实现呢？后面继续
