6.哨兵模式的简单配置和使用

1. 哨兵模式简介

哨兵主要的功能是对主机进行监控和提醒，如果主机发生故障，哨兵能够自动对其进行故障转移。（三个关键词：监控，提醒，故障转移）

哨兵模式的启动有两种方式：

1. redis-sentinel本身就可一个程序，所以可以直接启动redis-sentinel这个程序。
2. 可以去启动redis-server程序，后边带上一个参数 --sentinel （本文以这种方式为例分析）

2. 演示

1. 首先，linux上已经布署了多台redis，且使它们保持关闭状态。
2. 在前几节的基础之上，我们在test目录下再新建三个配置文件，分别作为redis哨兵的配置文件。详细内容如下所示：

[root@localhost test]# ll
总用量 336
-rw-r--r--. 1 root root    642 12月 29 21:07 26379.conf
-rw-r--r--. 1 root root    642 12月 29 21:07 26380.conf
-rw-r--r--. 1 root root    642 12月 29 21:07 26381.conf
-rw-r--r--. 1 root root 106787 12月 29 21:12 6379.conf
-rw-r--r--. 1 root root 106786 12月 29 21:07 6380.conf
-rw-r--r--. 1 root root 106760 12月 29 21:07 6381.conf

26379.conf中编辑输入以下内容：

port 26379
sentinel monitor mymaster 127.0.0.1 6379 2

26380.conf中编辑输入以下内容：

port 26380
sentinel monitor mymaster 127.0.0.1 6379 2

26381.conf中编辑输入以下内容：

port 26381
sentinel monitor mymaster 127.0.0.1 6379 2

3. 以上配置解释
   test文件中除了redis本身的三个配置文件以外，剩下的三个是哨兵的配置文件。哨兵的配置文件主要有两个配置项：

port：指定当前哨兵的端口
sentinel monitor mymaster 127.0.0.1 6379 2：当前哨兵监控的主机IP和端口，
最后的2代表监控的这台主机挂掉以后，需要几个哨兵的投票形成“势力范围”从而实现故障转移。
mymaster代表一个逻辑名称，一套哨兵可以监控多套主从复制集群，起个唯一名字就可以了。

以上三个配置文件也就代表着三个哨兵将要一起去监视主机。如果主机挂掉了，两个哨兵识别到，并给出“确实挂掉了”的结论，无论剩下的一个主机给出什么结果，最终都是按照“少数服从多数”的原则来的。

4. 开启三个redis-server主机，并建立主从关系（6379是主，其他两个是从）。
   示例命令如下：

[root@localhost test] server-redis 6379.conf 
[root@localhost test]# server-redis 6380.conf --replicaof 127.0.0.1 6379
[root@localhost test]# server-redis 6381.conf --replicaof 127.0.0.1 6379

5. 开启三个哨兵
   这里选择的是以redis-server带sentinel参数的方式来开启的。
   redis-server本来是存数据的，如果想要让它跑成哨兵，必须得追加上--sentinel参数。--sentinel是为了告诉server，不再是存数据了，而是一个哨兵，是用来监控别人的，而且是根据配置文件去监控的。

redis-server 26379.conf --sentinel
redis-server 26379.conf --sentinel
redis-server 26379.conf --sentinel

此时三个哨兵已经开始对6379这个主机进行监控了。
这时可以看6379服务端输出的日志，发现日志提示监控主机有两个slave，能够确定一点是6379不仅知道自己被建立主从关系了，还会知道监控自己的哨兵有哪些。这些在日志中都有详细体现。

6. 模拟主机挂掉的场景。
   将6379的服务端ctrl+c退出。这时再去看6380和6381的服务端，发现会不停的自动访问6379，而且一直失败。所以可以清楚，主挂掉了，从也会发现主挂掉了。
   但是在短时间之内，哨兵的日志没有任何输出，可以看出不会立即切换指定主，主要是所有技术基于冯诺伊曼互联网网络，网络有可能出现延迟，所以内部配了一个时间，避免短时间的网络波动或短时间内的重启问题。
   过了可能是几十秒的时间，哨兵会自动把新的主机选出来，并且把所有的其他从机（包括挂掉的）关联到新的主身上。
7. 故障转移的大致流程
   自动切换成功后，观察三个哨兵的日志，会发现三个的日志不一样，第一个的较长，其他两个日志较短。
   其实哨兵的内部选出了一个leader，leader操控实现故障转移。
   leader先是判断主观挂掉了，然后投票选主。（过程可以分析第一个哨兵的日志）
   主挂掉以后，开启剩下的两个客户端判断是否能够同步。
   即使原来的主机上线了，它也是从的角色，除非新的主挂掉了，它才有可能被选为主机。
   此时检查配置文件，发现哨兵已经将自己的配置文件修改了。本来监控的主机是6379，结果6379挂了，并且选出了新的主比如6380，它就会把配置文件中的监控目标自己改成6380。
8. 一个哨兵是怎么知道其他的哨兵的？
   过程：哨兵先去监控目标主机，然后由于主机知道谁是从，所以哨兵也知道谁是从。同时在当前主身上开启发布订阅。
   可以把主当成订阅方，psubscribe(如果不写p，就需要加监控的通道。加了p，后边可以写正则，监控符合正则的所有通道信息。比如写*)
9. 哨兵这种方式是集群的一种，只解决了单点故障的问题。访问上的压力可以有一点分担。
   但是这种x轴方向上的方案没有解决容量有限的问题。
   要么在客户端实现不同的业务访问不同的redis实例。如果业务特别多，肯定是要使用分片集群的方式等等。下节讲cluster模式。
   ps：以上详细的步骤会在后续进行完善和更新。如果有建议或问题，欢迎大家留言讨论。