Redis系列——7.sentinel

背景

今年是除夕夜，还在整理文档，偶真是个可爱认真的小仙女。

上篇学习了主从复制，多完美，分散了主服务器的压力，让整个redis拥有更大的吞吐量。（emmmm，虽然这个词好像不太合适）

但是这其中是有问题，比如如果主节点挂了，这咋整呢？

还能咋的啊，当然选择人工干预啦。咱在其他的从节点中再手动选择一个主节点，然后让其他节点变成新的主节点的从节点。

当然有个具体步骤：

1.启动从节点为主节点。命令为slaveof no one

2.旧主节点的其他从节点变成新主节点的从节点。命令为slaveof new master

3.通知应用方redis主节点变成新主节点，修改客户端调用的地址并重启客户端。

4.当已经挂了的主节点重新上线后，旧主节点变成新主节点的从节点。命令为slaveof new master

请原谅偶渣渣的手机画质，是因为穷，没有其他原因啦。

但是这是人工操作的，众所周知，代码狗都懒，能自动的监控的，绝不自己动手。

所以接下来我们要学习redis的哨兵啦，也就是自动切换，无需自己动手。

windows搭建哨兵

上次主从复制因为懒，没写过程，果然这次要一次还清啦，所以哦，不要拖，及时干完把，不然拖到最后还是要自己干。

今天我们先下载windows的redis，再搭建主从复制（一主二从），最后搭建监控redis的哨兵（三个，这里为什么要3个，后面会解释的，所以啊，咱不急，慢慢来，毕竟这是块大骨头）。

1.下载windows的redis

因为redis官方并不支持redis，所以我们先去GitHub下载，https://github.com/MSOpenTech/redis/releases?after=win-2.8.2101

2.搭建主从复制（一主二从）

将redis.windows.conf重命名为redis6379.conf，然后在复制两个分别为redis6380.conf，redis6381.conf。

redis6380的配置文件为:

redis6381的配置文件为：

这简直见名知意啦，如果不懂，可要打人啦。

port为当前redis的端口号

bind为绑定的服务器

slaveof 为该从服务器跟随哪个主服务器及其端口号

我们整好了配置文件，然后就该启动它啦。

如下启动其他两个从服务器，这就交给你们啦。

三个都启动完了，我们来看一下主节点的状态，很明显，6379为主节点，底下有两个从节点，分别是6380和6381。

3.搭建哨兵（3个）

搭好主从复制啦，我们来搭建哨兵啦。

新建三个sentinel配置文件：

那这些配置文件都代表什么意思呢？

port为当前sentinel服务运行的端口。

sentinel monitor mymaster 127.0.0.1 6379 2为sentinel监视一个叫mymaster的主redis实例，这个主实例的IP地址为127.0.0.1，端口号为6379。

sentinel down-after-milliseconds mymaster 5000为自动失效时间。

sentinel parallel-syncs mymaster 1为指定执行故障转移的时候，最多可以有什么个从redis实例在同步新的主实例。

sentinel failover-timeout mymaster 15000为如果在该时间内未完成节点切换，则认为失败。

接下来我们来分别启动三个哨兵：（照猫画虎）

4.测试哨兵

如果我此时再启动6239服务器，他是重新为主节点，还是成为新节点6381的从节点？结论为成为了从节点啦。

哨兵进行故障转移的过程

哨兵sentinel初始化的过程

步骤为：

1.初始化服务器（sentinel也是一个正常的redis服务器）

2.将普通的redis使用的代码替换为哨兵sentinel专用代码

不用RDB/AOF文件（因为不需要加载数据，他为监控节点，而不是数据节点）

端口号不一样（sentinel的端口号为26379，而默认的redis端口为6379）

普通redis命令：set/get/dbsize

哨兵命令：ping/sentinel

3.初始化哨兵状态 sentinel

4.向redis服务器创建连接

一个命令连接：向主服务器发送命令，并接受回复

一个订阅连接：_sentinel_:hello频道

在发送与订阅功能中，被发送的消息不会保存在服务器中。当客户端不在线/断线中，为了不丢失这条消息，redis就用了一个订阅频道来接受这条消息。

sentinel为什么是3个？

哨兵集群必须部署两个以上节点，如果哨兵集群仅仅部署了两个哨兵实例，那么他的大多数为2(2的大多数为2,3的大多数为2,5的大多数为3,4的大多数为2）,如果其中一个哨兵宕机，就无法满足大多数大于等于2，那么在master发生故障的时候就无法进行主从切换。

哨兵如何监控?

检测实例是否下线：

主观下线：sentinel与服务器断开时间超过指定时间

客观下线：客观下线数量超过半数

整个故障转移流程

1.sentinel领导节点的选举

相互发送信息：要求对方设置自己为局部零头sentinel

Raft算法 先到先得 Leader只是故障转移中出现的角色

可参考：http://weizijun.cn/2015/04/30/Raft%E5%8D%8F%E8%AE%AE%E5%AE%9E%E6%88%98%E4%B9%8BRedis%20Sentinel%E7%9A%84%E9%80%89%E4%B8%BELeader%E6%BA%90%E7%A0%81%E8%A7%A3%E6%9E%90/

2.新的主服务器怎么选？

由领导节点将所有的从服务器保存在列表中，然后一项项过滤

A.去除所有处于下线的

B.去除近5s内没有回复的

C.优先级+复制偏移量最大（要求数据为最新的）

D.排序，选择运行ID最小的。