开发者学堂课程【Redis 入门实战演练： Redis 哨兵及实现（三）】学习笔记，与课程紧密联系，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/653/detail/10840
Redis 哨兵及实现（三）
如何验证三个哨兵？先连接到哨兵端口上去，查验使用 redis-cli -p 26379 默认的端口是26379,输入语句 info
之后查看 sentinel 信息日志，主要看哨兵的应用信息，可以看到地址是172.31.7.101，有两个 slave 以及三个哨兵。最后一行的信息非常重要是决定 master 的地址、端口、哨兵数量以及获取到的 slave，可以看到这个信息就代表哨兵的验证完成。
最好是将每一台的服务器都进行验证日志，输入语句vim/apps/redis/logs/sentinel_26379.log,得到结果如下图。在这哨兵中，一定要看到其他两个结点。在102上面坑定可以看到101和103，只用这种结构，哨兵在 master 后才会进行故障转移
（2）验证哨兵的可用性
停止 master 看能不能发生故障转移，就是把当前的 master172.31.7.101 停掉后，在102和103之间是否可以选举出一个新的 master，并且把剩下的 slave 指向新的 master，新的 master 只能是102或103。到目前为止，由于在之前的演示中设置的有104结点，在这里需要关闭，进入104结点输入语句 redis-cli、AUTH l、redis-cli、SLAVEOF no one，
在最后的语句可以看到 SHUTDOWN 就可以关掉，或是通过交互窗口关掉。再输入语句systemtcl stop redis、ss -tnl这两个命令行停掉。
在这里104本省就是一个测试机器，停掉之后现在的状态就是正常的，输入语句redis-cli、AUTH linux39、info。
测试是否能够实现这个效果现在有两个 slave102和103输入语句systemtcl stop redis，把master停掉。之后查看日志打开101、102、103的哨兵日志，输入语句tail -f /apps/redis/logs/sentinel_26379.log
在执行停止操作后，（注意有间隔时间是15s，会有一定的延迟），可以看到监控的 id 是多少，并且此时已经处于down的状态（如下图鼠标选中内容），并且图中可以看到已经认为是主观宕机门后面还有根据选举产生的 leader
下图鼠标中所选中的内容就是代表是发生故障转移，并且可以观察到7.103成为了新的 master
在日志中可以看到104这个结点也是产生了一定的影响，然后进入102的 redis 命令行查看当前状态语句AUTH linux39、info打印，看结点情况，新的 master 是7.103
进入到7.103的 redis 命令行查看，重复刚刚的操作，查看内容如下图所示。可以看到只有一个 slave，对应的端口、地址，说明103成为了 master。
KEYS
往103上写数据，在102的命令行中输入KEYS *,在103上面写SET key10 value10，看这个数据是否可以同步给102，在102中输入KEYS *，会看到结果会自动成为103的 slave，那么是如何成为103的 slave？输入语句get key10，之前是101的slave，后来变为了103的 slave。看配置文件输入语句vim /apps/redis/etc/redis.conf，哨兵会改配置文件,在 redis.conf 中可以看到之前的slave是指向的101，它会自动加入后面的两条语句使得 slave 发生变化，所以说哨兵会自动改变配置文件，修改配置文件就可以把 master 指向新的 master，此时的故障转移就成功了。
转移成功之后，就可以通过监控知道当前的 redis 已经挂掉，之后赶紧查看服务器是怎么回事，内存问题等并即使修复(修改配置文件)。输入语句redis-cli^C、vim /apps/redis/etc/redis.conf，再上线之后就不能成为 master，而是以 slave的身份连接到当前的环境中去。如何加入？需要把 slave 和 master 的文件配置好，已经成为 mater 后，101就不要在成为 master，打开对应的 REPLACITON，手动的指向172.31.7.103上去。要输入密码，整个密码再 redis 中都是一致的在这时 linux39 如下图。
之后重新启动 redis，语句为 systemctl restart redis，修复好之后去172.31.7.103上查看是否已经连上，结果如下，可以看到此时的 slave 有2个。当103挂掉之后，会在102和101之间再次选出一个从而保证 redis 服务的高可用性。
（3）根据什么选举出的新节点？
在哨兵的接口中，输入语句redis-cli -h 172.31.7.101 -p26379，就是连到任何一个哨兵都是可以的，之后输入info。
在下图所示中发现了有三个 slave，原因需要进行排查。
在103中输入redis-cli、info、AUTH linux39，结果如下，可以看到连接的只有两个。
输入语句redis-cli -h 172.31.7.103 -p 26379，之后输入info。得到结果，哨兵有三个。
打开配置文件，输入语句vim /apps/redis/etc/sentinel.conf,结果如下图，可以看到之前配置的104也在，是之前改的配置，之前的会向101来同步数据，这个在平常用的环境是不用担心的只有不使之前配置的结点同步 master 的数据即可，他现在是还有一个104但并不影响使用。
这里的104是为了测试不同版本的问题，104是3.2的无法和4.0版本的同步数据，这里是做的一个实验，对后续讲课的实验没有影响。原因是在哨兵的日志中，输入语句vim /apps/redis/logs/sentinel_26379.log,在这里是已经把 slave 标记为 down
在103上输入语句/aps/redis/logs/sentinel_26379.log，可以看到104已经是认为被 down 的，对结果是没有影响的。
客户端怎样知道 master？故障转移之后，Java 程序会和哨兵进行连接，比如和哨兵进行通告，通告当前的 master 换成哪一个，Java 的 Jedis 包是可以实现这个功能的，不然角色切换之后怎么使用。104是最早做的连接信息，是一个测试。
在102上输入vim /apps/redis/log/sentinel_26379.log,得到结果如下，结点都会加进去的。
104他不是 master，master 才会用到 ODOWN。ODOWN 是用来仲裁的，一旦整个哨兵认为 master odown 数量超过一半后就会进行选举，master 才会有 odown。104down 之后会出现什么情况，就算有一个 master down，加入这个结果是一主三从，104 down 是没有关系的，无非是在下一次故障转移的时候，这个新的 master 是从101和102上选举，是不包括104。另外还需要保证哨兵开机或会自己动，通常保证的方法是把这个哨兵的启动命令（/apps/redis/etc/redis-sentinel /apps/redis/etc/sentinel.conf）放在 etc 下的 local 文件，并且文件要设置成开机自动运行，语句为 vim /etc/rc.d/rc.local。如下图使得哨兵的脚本在开机后可以自动运行，必须要放上这个语句，否则可能会在某一天的情况下，哨兵没有起来，redis 挂了后没有发生故障转移，就会导致不解，明明存在哨兵却不能够执行故障转移，大部分人是不会告诉需要重启的。
最后再加上一个可执行权限既可，语句为:chmod a+x /etc/rc.d/rc.local。
注意：哨兵还可以用 system 管理书写，这个哨兵就是redis的服务命令，可以直接写，在启动的时候加上配置语句为vim /usr/lib/system/system/redis.service，之后直接在后面加入就可以
