redis-Sentinel哨兵原理与实战

男娘i 2022-06-04 08:23 248阅读 0赞

Sentinel(哨岗、哨兵)是redis的高可用性解决方案：由一个或多个Sentinel实例组成的Sntinel系统。  
其主要作用是可以监视任意多个主服务器，以及这些主服务器树下的所有从服务器，并在被监视的主服务器进入下线的状态时，自动将下线主服务器属下的某个从服务器升级为新的主服务器，然后又新的主服务器代替已经下线的主服务器继续处理命令请求。  
其实哨兵模式存在的意义就是使redis高可用，当redis出现问题的时间可以让redis实现热切换  
过程：  
我们现在假定存在

Sentinel系统
    主服务器server1
    从服务器server2、server3、server4

那么可以画出状态图  
![这里写图片描述][SouthEast]

当原来的主服务器server1出现崩溃，此时Sentinel系统将会在从服务器中选出一个服务器来担任主服务器  
![这里写图片描述][SouthEast 1]

![这里写图片描述][SouthEast 2]

当原来的主服务器server1恢复服务后，将把server1定义为当前主服务器server2的从服务器  
![这里写图片描述][SouthEast 3]

## 启动Sentinel与启动redis服务器的区别 ##

1.启动方式不同

redis-sentinel /path/to/your/sentinel.conf

或

redis-server /path/to/your/sentinel.conf --sentinel

在程序内部，当启动Sentinel启动，把redis使用的代码替换成Sentinel专用代码，并会初始化Sentinel状态，初始化监视的主服务器列表，创建连向主服务器的网络链接

2.可用命令不同  
因为Sentinel只是简单的提供监视的服务，所以其内容只能执行一些与监视有关的命令，其中包括发布与订阅命令，文件事件处理器命令，时间事件处理器命令等，并不包括一些如set,get的命令

3.内部代码不同，其配置文件也不同  
在观点1中有讲到哨兵模式是会使用专用的代码，而配置文件是代码一些通用配置的体现，所以配置文件与redis服务的配置文件也不同，其中，值得注意的是：

1.实例的名字，主服务器的名字由用户在配置文件中设置从服务器以及哨兵的名字将会由哨兵自己定义，格式为IP:port
    2.实例无响应多少毫秒之后才会被判断为主观下线（down-after-milliseconds），该值可以在配置文件中找到并修改
    3.判断实例为客观下线所需支持的投票数（quorum）
    4.在执行故障转移操作时，可以同时对新的主服务器进行同步的从服务器数量（parallel_syncs）
    5.刷新故障迁移状态的最大时限制(failover_timeout)

其中主观下线与客观下线是需要在一个哨兵系统中才能体现其作用，即对同一主机监听的哨兵数量>=2

换句话说就是我们可以通过修改sentinel.conf来配置哨兵的相关状态

port 26379 #端口号
    sentinel monitor mymaster 127.0.0.1 6379 2 #监听的主机名，ip，端口，客观下线时投票数
    sentinel down-after-milliseconds mymaster 30000#实例无响应多少毫秒后判断为主观下线
    sentinel parallel-syncs mymaster 1#在执行故障转移操作时，可以同时对新的主服务器进行同步的从服务器数量
    sentinel failover-timeout mymaster 180000#刷新故障迁移状态的最大时限制

## 哨兵模式工作流程内部实现 ##

1.创建链向主服务器器的网络链接  
当初始化哨兵时，将会向主服务器创建两个链接

命令链接：主要用来发送命令
    订阅链接：主要用来监听信息

![这里写图片描述][SouthEast 4]

随后哨兵便能通过info命令获取到主服务与所有从服务器的信息，根据反馈内容哨兵在内部构建监视的服务器对象，并实时更新状态  
![这里写图片描述][SouthEast 5]

![这里写图片描述][SouthEast 6]

不仅如此，如果有多个哨兵监视同一个服务器的话，那么哨兵可以通过与主服务器的交互来了解到当前的哨兵系统集  
![这里写图片描述][SouthEast 7]

![这里写图片描述][SouthEast 8]

最后整个系统会成为一个网的状态  
![这里写图片描述][SouthEast 9]

检测下线的逻辑：

1.当其中一台哨兵发A现主服务器下线时，此时对A来说主服务器是主观下线，他需要把该消息传递给系统中其他哨兵
    2.当其他哨兵B、C接受到A的消息后，会对主服务器进行监测，如果判断为下线，将对A进行反馈，此时如果认为主服务器已经进入下线状态的Sentinel的数量超过配置中设置的quorum值，那么该Sentinel就会认为主服务器已经进入客观下线状态。
    3.当一个主服务器被判断为客观下线时，监视这个下线主服务器的各个Sentinel会进行协商，选举出一个领头，执行故障转移操作

![这里写图片描述][SouthEast 10]

![这里写图片描述][SouthEast 11]

故障转移：

1.在已下线主服务器树下的所有从服务器里面，挑出一个从服务器，并将其转换为主服务器(根据其活跃的状态与级别，可以在从服务器里面进行设置)
    2.让已下线主服务器树下的所有从服务器改为复制新的主服务器
    3.将已下线主服务器设置为新的主服务器的从服务器，当这个旧的主服务器重新上线

![这里写图片描述][SouthEast 12]

![这里写图片描述][SouthEast 13]

![这里写图片描述][SouthEast 14]

![这里写图片描述][SouthEast 15]

当原来的主服务器重新上线后，让其成为当前主服务器的从服务器  
![这里写图片描述][SouthEast 16]

## 实战 ##

我将在[这片文章][Link 1]搭建 的主从基础上加上一个哨兵，来模拟高可用的过程，其应用包括  
1.主服务器 redis-m  
2.从服务器 redis-s  
3.哨兵 redis-sentinel

在原来的基础上复制一个应用作为哨兵应用

cp -rf  redis-m redis-sentinel

在这里，为了能够做到主从切换，从主切换，一定要更新主从服务器里面的配置，都需要加入这两个项

requirepass Link$2013
    masterauth Link$2013

修改哨兵配置文件

cd redis-sentinel
    vim sentinel.conf

主要修改以下配置

sentinel monitor mymaster 127.0.0.1 10001 1
    sentinel down-after-milliseconds mymaster 5000 #5秒无反应认定为失效
    sentinel parallel-syncs mymaster 1
    daemonize yes
    sentinel auth-pass mymaster Link$2013 #记得配置密码否则无法监听

先启动主从链，在启动哨兵

./redis-sentinel ../sentinel.conf

查看进程状态  
![这里写图片描述][SouthEast 17]

使用cli进入哨兵，输入命令info可以看到以下信息

# Sentinel
    sentinel_masters:1
    sentinel_tilt:0
    sentinel_running_scripts:0
    sentinel_scripts_queue_length:0
    master0:name=mymaster,status=ok,address=127.0.0.1:10001,slaves=1,sentinels=1 #这里可以看到监听的主从链的状态

现在我们先把redis-m给九杀掉 看看变化  
![这里写图片描述][SouthEast 18]

再次进入哨兵结点，输入info命令

进入redis-s，输入info，查看replication信息

# Replication
    role:master
    connected_slaves:0
    master_repl_offset:0
    repl_backlog_active:0
    repl_backlog_size:1048576
    repl_backlog_first_byte_offset:0
    repl_backlog_histlen:0

重启启动redis-m,9杀redis-s,可以看到状态切换回来了，这里需要注意的是，热切换时一定要保证从服务列表存在可替换的服务器，即如果

杀死redis-m
    再杀死redis-s
    启动redis-m
    这时已经无法切换到redis-m了
    这时启动redis-s，已经无法维持redis-m、redis-s的主从关系了

[SouthEast]: /images/20220604/18b113e6b51a491e9b04f4aa77015d44.png
[SouthEast 1]: /images/20220604/f29451b3fa804972b01ced4c7aa2ba69.png
[SouthEast 2]: /images/20220604/75da8f1b54174b629d99ea014de4aa01.png
[SouthEast 3]: /images/20220604/1935871f97c542339bd8bc0b4ab1e971.png
[SouthEast 4]: /images/20220604/e83ba40508d24c549bcd69d17bfb7275.png
[SouthEast 5]: /images/20220604/ae3ca369792c49e095e75c15e0c55a71.png
[SouthEast 6]: /images/20220604/67b757df75c94e9a989b7a61c503d978.png
[SouthEast 7]: /images/20220604/661a4dde0f7147c5a8b4ad92bb1cab27.png
[SouthEast 8]: /images/20220604/c54df2736ead43a88ccf3afd3e3eaf04.png
[SouthEast 9]: /images/20220604/1424616dad5b4316b1bbbdb767203505.png
[SouthEast 10]: /images/20220604/0255803012a2456eaf010af40716d5c5.png
[SouthEast 11]: /images/20220604/be87e6ee5c4c419ba5e1584d6f9fbcde.png
[SouthEast 12]: /images/20220604/b2883b505b2b4dc6a408c2efad20bbcc.png
[SouthEast 13]: /images/20220604/ffb4b21079a34a23886f5e609ac017e9.png
[SouthEast 14]: /images/20220604/10b78fb0b6834123b131b3d34de87a22.png
[SouthEast 15]: /images/20220604/cf8f4348f9db4efe8b09035113c57907.png
[SouthEast 16]: /images/20220604/031912c8cdd5413b97b2a30676865dac.png
[Link 1]: http://blog.csdn.net/hayre/article/details/78744650
[SouthEast 17]: /images/20220604/e94fefad6bcf4bbe95127ef80bc9a5d0.png
[SouthEast 18]: /images/20220604/a700330fa64640f3b706dbbe912c4757.png