相信通过前面4篇笔记,大家对redis的基本概念及配置已经有了解,本篇笔记重点说明如何通过官方发布的redis sentinel工具来监控redis的运行状态。另外,对sentinel使用过程中的注意事项做些讨论。 1. Redis Sentinel功能 Redis Sentinel是一套用于管理Redis实
相信通过前面4篇笔记,大家对redis的基本概念及配置已经有了解,本篇笔记重点说明如何通过官方发布的redis sentinel工具来监控redis的运行状态。另外,对sentinel使用过程中的注意事项做些讨论。
1. Redis Sentinel功能Redis Sentinel是一套用于管理Redis实例的分布式系统,主要完成3项任务:
1) Monitoring:持续监控Redis master或slave实例的运行情况是否符合预期
2) Notification:若被监控的Redis实例运行异常,sentinel会通过API通知外界(人或程序)
3) Automation failover:若master实例故障,sentinel会重新选主并启动自动故障切换:选择slave-priority最小的那个slave实例并将其提升为master,同时修改其它slave的配置,使其master配置项指向新的master,当old master恢复重启后,会自动降级为new master的slave。最后,根据配置,Redis Sentinel还会将新的master地址通知给当前正在访问Redis的应用程序。
2. Redis Sentinel部署
Sentinel作为一个分布式系统工具,建议多机房多机部署。
每个sentinel实例主要有6个配置项,按Redis集群的实际部署情况进行配置即可,示例如下:
port 26329 sentinel monitor mymaster 127.0.0.1 6379 2 sentinel down-after-milliseconds mymaster 60000 sentinel failover-timeout mymaster 180000 sentinel parallel-syncs mymaster sentinel notification-script <master-name> <script-path>其中:
port: 指定sentinel的侦听端口(即与redis server或client建立tcp连接的端口)
monitor: 指定sentinel要monitor的redis实例,包括一个redis实例的别名(alias)及redis实例的ip+port,该行最后的数字2表示至少2个setinel实例同时检测到redis server异常时,才将redis server的状态判决为real fail。也即,若这里配置为2,但实际部署中sentinel只部署了1套,则即使redis实例已经挂掉,sentinel也不会给出任何警告。这一点需要特别引起注意。
down-after-milliseconds: 指定sentinel监控到redis实例持续异常多长时间后,会判决其状态为down。若实际业务需要sentinel尽快判决出redis实例异常,则该值可适当配小。
failover-timeout: 若sentinel在该配置值内未能完成failover操作(即故障时master/slave自动切换),则认为本次failover失败。该配置有4个用途,具体可参考sentinel.conf中的说明,限于篇幅,此处不再赘述。
parallel-syncs: 指定failover过程中,同时被sentinel reconfigure的最大slave实例数。由于reconfigure过程中,对应的slave会中断响应客户端请求,故为避免所有的slave同时不可用,该值需适当配小。
notification-script: 指定sentinel检测到master-name指向的实例异常时,调用的报警脚本。该配置项可选,但线上系统建议配置。
2.2 启动监控系统
配置文件修改完成后,启动各监控进程即可,例如:
nohup ./bin/redis-sentinel ./conf/sentinel.conf > ./log/redis-sentinel.log 2>&1 &
2.3 sentinel使用场景实测
为调研并掌握sentinel用法,我搭建了redis测试环境并做了一系列实验,下面对实验情况做详细说明。
特别说明:由于下面的内容可能会涉及到公司内网地址,故为避免不必要的麻烦,文字或截图出现ip地址的地方做了涂抹,但不影响说明问题。
实验环境(one master / two slaves / two sentinels):
a. 一个master(slave-priority为100)部署在ip为xx.xx.234.67的机器上;
b. 两个slaves(slave-priority分别为90/100)的均部署在ip为xx.xx.234.49的机器上;
c. 启用两个sentinel进程监控redis集群状态
做了6种case的测试,结果说明如下:
Case1: 依次启动master进程及2个slave进程后,再启动2个sentinel进程,sentinel可以正常识别出主从关系
Case2: 用shutdown命令停掉master,则sentinel自动选slave-priority小的那个slave进程为new master,同时,自动将另一个slave进程的master指向该new master
Case3: 在case2基础上,重启old master,sentinel会将其降级为slave,其master指向case2选出的新主
Case4: 将master和2个slave实例的slave-priority配为互不相同的值,在Case1基础上,shutdown当前的master,在sentinel已选出新主且reconfigure其它实例使它们指向新主后(从old master异常到触发sentinel重新选主的时间由用户通过sentinel.conf的down-after-milliseconds配置项指定),重启old master,系统最终状态与Case3一致,即old master已降级为slave,其master指向sentinel选出的新主。若在sentinel已选出新主但尚未完成其它实例的reconfigure之前,重启old master,则整个系统会出现无法选出new master的异常,详情见下面Case5的描述。
Case5: 将master和2个slave实例的slave-priority均配为相同的值,在Case1基础上,shutdown当前的master,在sentinel已选出新主且reconfigure其它实例使它们指向新主后,重启old master,系统最终状态与Case3一致,即old master已降级为slave,其master指向sentinel选出的新主。在所有slave-priority配置为相同值的情况下,sentinel会将各slave实例中runid最小的slave提升为master(前提是该slave对应的redis.conf中允许其被promote为master)。与Case4出现的异常情况类似,若在sentinel选出新主但尚未完成其它实例的reconfigure之前,重启old master,会发现sentinel的自动故障切换机制已然凌乱了。
详细的异常情况如下所述。
old master部署在ip为xx.xx.234.67的机器上且port默认为6379,sentinel切换异常后,对该old master执行info命令输出如下:

slave-00实例在ip为xx.xx.234.49的机器上且port配为6378,sentinel切换异常后,info输出如下:

slave-01实例在ip为xx.xx.234.49的机器上(与slave-00同机部署)且port配为6377,info输出如下:

从上面3个redis实例的输出情况看,3个均认为自己是slave,整个系统无主!其中,位于xx.xx.234.67的old master(注意上面第1图的master_host字段)和位于xx.xx.234.49的salve-00(注意上面第2图的master_host字段)均认为slave-01为new master,而位于xx.xx.234.49的slave-01则认为自己仍然为slave,认为old master目前还是master(注意上面第3图的master_host字段)。
从sentinel进程日志看,其无法选出新主,即sentinel无法确认两个master candidates到底哪个是new master,在两个实例间频繁切换:

这种情况务在实际运维时务必要引起注意!
Case 6: 在系统已进入Case5所示的异常状态后,shutdown两个master candidates中的一个实例,sentinel仍然无法正常选主,直至3个实例全部shutdown,整个系统仍然无主。基本可以确定监控系统内部逻辑状态已经混乱了。
2.4 结论
若master实例故障,则最好等sentinel选出new master且稳定后(选新主并完成切换的时间与配置有关,典型值在1分钟之内),再重启old master,避免引发sentinel的误判,导致整个系统无法选出new master。
【参考资料】
1. Redis Sentinel Documentation

Redis是现在最热门的key-value数据库,Redis的最大特点是key-value存储所带来的简单和高性能;相较于MongoDB和Redis,晚一年发布的ES可能知名度要低一些,ES的特点是搜索,ES是围绕搜索设计的。

本篇文章给大家带来了关于redis的相关知识,其中主要介绍了关于redis的一些优势和特点,Redis 是一个开源的使用ANSI C语言编写、遵守 BSD 协议、支持网络、可基于内存、分布式存储数据库,下面一起来看一下,希望对大家有帮助。

本篇文章给大家带来了关于redis的相关知识,其中主要介绍了Redis Cluster集群收缩主从节点的相关问题,包括了Cluster集群收缩概念、将6390主节点从集群中收缩、验证数据迁移过程是否导致数据异常等,希望对大家有帮助。

本篇文章给大家带来了关于redis的相关知识,其中主要介绍了Redis实现排行榜及相同积分按时间排序,本文通过实例代码给大家介绍的非常详细,对大家的学习或工作具有一定的参考借鉴价值,希望对大家有帮助。

本篇文章给大家带来了关于redis的相关知识,其中主要介绍了关于原子操作中命令原子性的相关问题,包括了处理并发的方案、编程模型、多IO线程以及单命令的相关内容,下面一起看一下,希望对大家有帮助。

本篇文章给大家带来了关于redis的相关知识,其中主要介绍了bitmap问题,Redis 为我们提供了位图这一数据结构,位图数据结构其实并不是一个全新的玩意,我们可以简单的认为就是个数组,只是里面的内容只能为0或1而已,希望对大家有帮助。

本篇文章给大家带来了关于redis的相关知识,其中主要介绍了Redis实现排行榜及相同积分按时间排序,本文通过实例代码给大家介绍的非常详细,下面一起来看一下,希望对大家有帮助。

本篇文章给大家带来了关于redis的相关知识,其中主要介绍了关于实现秒杀的相关内容,包括了秒杀逻辑、存在的链接超时、超卖和库存遗留的问题,下面一起来看一下,希望对大家有帮助。


ホットAIツール

Undresser.AI Undress
リアルなヌード写真を作成する AI 搭載アプリ

AI Clothes Remover
写真から衣服を削除するオンライン AI ツール。

Undress AI Tool
脱衣画像を無料で

Clothoff.io
AI衣類リムーバー

AI Hentai Generator
AIヘンタイを無料で生成します。

人気の記事

ホットツール

WebStorm Mac版
便利なJavaScript開発ツール

SublimeText3 Linux 新バージョン
SublimeText3 Linux 最新バージョン

ZendStudio 13.5.1 Mac
強力な PHP 統合開発環境

SublimeText3 Mac版
神レベルのコード編集ソフト(SublimeText3)

SublimeText3 英語版
推奨: Win バージョン、コードプロンプトをサポート!
