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最小的。

  • 发表于:
  • 原文链接https://kuaibao.qq.com/s/20190205G05LLB00?refer=cp_1026
  • 腾讯「云+社区」是腾讯内容开放平台帐号(企鹅号)传播渠道之一,根据《腾讯内容开放平台服务协议》转载发布内容。
  • 如有侵权,请联系 yunjia_community@tencent.com 删除。

扫码关注云+社区

领取腾讯云代金券