Redis专题(七)——Redis高可用(哨兵篇)

Redis专题(七) ——Redis高可用(哨兵篇)

(原创内容,转载请注明来源,谢谢)

redis2.8开始,提供稳定的哨兵,对redis的主从数据库进行自动化的系统监控和状态恢复。

1、概念

哨兵用于监控redis运行情况,监控主从数据库是否正常运行,并且在主库故障时将从库转换为主库。可以设置单个哨兵,也可以设置多个哨兵。

单个哨兵:

多个哨兵:

2、哨兵使用方式

现假设有一主二从数据库。哨兵建立方式如下:

1)建立配置文件,文件名可以任意,如sentinel.conf,里面的内容为:

sentinelmonitor 主库名字(任意,只能是字母、数字、-、.、_)主库ip 主库端口主库投票数。

由于同一个主从系统可以多个哨兵检查,则投票数的目的在于当该哨兵认为主库主观下线,至少还要有投票数-1 (因为包括当前哨兵)的哨兵认为是客观下线,才会换主库。

其中只需要配置主库,哨兵会自动获取从库。该文件可以有多行,每一行表示一个主库。设置多行表示检测多个主从系统。

除了monitor,还可以配置其他监控内容,通过主库名字区分监控的是哪个主从系统。

2)执行 sentinel进程,将配置文件传给哨兵:

redis-sentinel /sentinel.conf的路径/sentinel.conf

3)启动哨兵,可以看到哨兵的run id,输出+monitor表示监测到主库,+slave表示检测到从库。

哨兵执行过程如下:

1)主库关闭

如果将主库关闭(可以手动关闭或杀死进程),等待时间(默认30秒,可配置),会输出+sdown 主库ip 主库端口,表示哨兵主观认为主库停止服务。接着是+odown,表示哨兵客观认为主库停止服务。

当输出+odown后,哨兵会自动开始故障恢复,+try-failover开始修复,+failover-end表示修复完毕。修复完毕后,会重新设置一个主库,+switch-master 原主库名原主库ip 原主库端口新主库ip 新主库端口。接着,又会有+slave输出,表示检测到新主库的从库,原主库恢复连接后,也会被设置成新主库的从库。

2)从库关闭

从库如果被关闭,也会检测到+sdown,当从库再次开启,会检测到-sdown,并且会输出+convert-to-slave将重启后的从库再次设置为从库。

从库只有主观下线,没有客观下线。因为客观下线后需要重新选出新主库,这对于从库来说没有必要。

3、哨兵原理

1)哨兵进程启动时,通过读取上述提到的配置哨兵配置文件,确定主库的信息。当配置文件中有多行数据,表示是多个主从系统,哨兵也可以同时检测。

2)哨兵启动后,与要检测的主库建立两个连接,一个订阅来自主数据__sentine1__:hello频道,以获取其他监控该主库的哨兵信息;另一个用来给主库建立连接定期发送INFO等命令(这是因为考虑到主库可能会进入订阅模式,而无法执行其他命令,所有才用连接)。

3)连接建立后,进行如下操作:

a.每10秒向主库发送INFO命令。

目的是获取当前主从系统的相关信息,如从库信息,比较上次发送的信息与当前的信息,确认主从库是否有故障。

b.每2秒向主库与从库的__sentine1__:hello发送哨兵自身的信息。

目的是为了使各哨兵之间互相确认当前的检测范围,形成监测网。发送的内容包括哨兵地址、端口、运行id、配置版本,主库名字、地址、端口、配置版本。

当发现主库配置版本比较落后,还会更新主库的信息。

c.每1秒向主从数据库以及其他哨兵发送ping命令。

目的是确认各库、各哨兵是否正常服务。1秒这个时间可以通过配置文件的字段进行配置,down-after-milliseconds,单位是毫秒。如果大于1秒则采用1秒,小于1秒则采用配置的数据。因此开启哨兵后,最少每秒会查看一次各库的情况。

4)判断各库是否下线

a.当超过down-after-milliseconds时间,库没有回复,则认为其主观下线,即上述的检测到+sdown。

当下线的是主库,哨兵还会给其他哨兵发送命令,确认其他哨兵是否也认为主库主观下线,当达到指定数量(哨兵配置文件中主库的投票数,投票数含自身),则认为其客户下线(检测到+odown),此时重新选主库。

5)选举领头哨兵

多个哨兵确认主库客观下线,会选举出一个领头哨兵进行故障恢复,避免多个哨兵重复恢复。

选举领头哨兵,采用Raft算法,如下:

a.发现主库客观下线的哨兵A,向其他哨兵发送命令,要求选举自己为领头哨兵。

b.如果接到命令的哨兵,没有选过其他人,则选A。

c.当A的票数超过哨兵的半数,且超过哨兵配置文件对该主库的投票数,则A称为领头哨兵。

由于要超过半数才能当领头哨兵,因此确保每次选举都只会选出一个领头哨兵。

d.当多个节点参选领头哨兵,如果出现没有任何哨兵当选的情况,则每个哨兵随机等待一个时间,再重新发起请求。

6)故障恢复

领头哨兵挑选一个从库作为新的主库,挑选依据如下:

a.所有在线从库,选择优先级最高的从库,优先级通过配置文件的slave-priority来设置。

b.当多个从库优先级都一样且最高,则复制的偏移量越大,即增量复制时保存的数据相对约完整的,越优先。

c.以上条件都一样,则选择运行id最小的从库作为新的主库。

7)后续步骤

a.选出新主库,领头哨兵会向其发送slave of no one,让其成为主库,再向其他从库发送slave of命令,让其他从库称为该新主库的从库。

b.将旧主库设置成为新主库的从库,使其重启后可以直接投入工作。

4、哨兵部署

哨兵以独立进程的方式进行监控,如果系统哨兵较少,可靠度则较低。因为哨兵本身也可能发生故障。因此,相对稳妥的方案:

1)为每个数据库(无论主从)都配置一个哨兵。

2)使每个哨兵与其对应节点网络环境相似。

但是,redis不支持连接复用,配置过多哨兵会有太多的冗余连接;另外redis负载高时会影响其对哨兵的回复以及哨兵和其他哨兵的通信。

因此要根据实际情况设置哨兵。

——written by linhxx 2017.08.12

原文发布于微信公众号 - 决胜机器学习(phpthinker)

原文发表时间:2017-08-12

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏喵了个咪的博客空间

原 EMQ百万级MQTT消息服务(分布式集群)

在强大的单机也比不上集群,EMQ的集群模式很粗暴,只需要把EMQ服务关联在一起然后负载均衡就可以达到集群的效果,这样就算面对1000CK问题也迎刃而解 附上: ...

3828
来自专栏北京马哥教育

LVS原理知多少?

LVS简介   Internet的快速增长使多媒体网络服务器面对的访问数量快速增加,服务器需要具备提供大量并发访问服务的能力,因此对于大负载的服务器来讲, CP...

3566
来自专栏后端技术探索

大众点评新开源项目-Camel(干货)

Camel 是大众点评开发的软负载一体解决方案,承担了F5四层硬负载后的软负载工作。Camel已成为大众点评网络流量中必不可缺的一层。

893
来自专栏圣杰的专栏

ABP入门系列(13)——Redis缓存用起来

源码路径:Github-LearningMpaAbp 1. 引言 创建任务时我们需要指定分配给谁,Demo中我们使用一个下拉列表用来显示当前系统的所有用户,以...

2339
来自专栏大魏分享(微信公众号:david-share)

容器超融合的实现&持久存储的动态分配 : Openshift3.9学习系列第六终结篇

干货巨献:Openshift3.9的网络管理大全.加长篇---Openshift3.9学习系列第二篇

1303
来自专栏北京马哥教育

万字长文带你从 0 学习 Keepalived

负载均衡器(Load Balancer, LB )是一组能够将IP数据流以负载均衡形式转发到多台物理服务器的集成软件。有硬件负载均衡器和软件负载均衡器之分,硬件...

900
来自专栏技术分享

RabbitMQ 可靠投递

标签: RabbitMQ shovel-plugin ConfirmCallback RabbitMQ消息投递

1020
来自专栏BeJavaGod

RabbitMQ 整合Spring 实现多客户端发送消息队列

好久没更新了。。实在太忙,对不起大家,今天更一下最近使用到的一些东西,比较实用!看官们亲拍~~ 以前在单项目中用过RabbitMQ,没有问题 不过这次在分布式项...

2805
来自专栏喵了个咪的博客空间

原 荐 EMQ百万级MQTT消息服务(小技巧)

附上: 喵了个咪的博客:w-blog.cn EMQ官方地址:http://emqtt.com/ EMQ中文文档:http://emqtt.com/docs/v2...

3364
来自专栏散尽浮华

Docker管理工具-Swarm部署记录

介绍另一个管理工具Swarm的用法,Swarm是Docker原生的集群管理软件,与Kubernetes比起来比较简单。

4476

扫码关注云+社区