哨兵简介

一定要有一个概念:哨兵实例也是特殊的Redis实例,也就是哨兵实例是独立的进程,多个哨兵实例可以搭建主从(Master-Slave),它们承担的职责和普通的Redis实例不一样。下面是官方文档中对哨兵的介绍:

Redis哨兵为Redis提供了高可用性,意味着可以使用哨兵创建Redis服务部署,该部署可以在无需人工干预的情况下抵御某些类型的故障。Redis哨兵还提供其他功能,如监视、通知,并且为客户端提供配置入口(acts as a configuration provider for clients)。下面是Redis哨兵提供的完整功能列表:

  • 监控(Monitoring):Sentinel会不断检查Master实例和Slave实例是否按预期工作。
  • 通知(Notification):Sentinel可以通过API进行通知受监控的Redis实例出现问题。
  • 自动故障转移(Automatic Failover):如果Master实例未按预期工作,则Sentinel可以启动故障转移程序,在该过程中,会将一个Slave实例提升为Master实例,将其他Slave实例重新配置为使用新的Master实例,并且会通知使用Redis实例的应用程序获取新的地址、连接信息。
  • 提供配置入口(Configuration provider):Sentinel充当客户端服务发现的授权来源(a source of authority):客户端连接到Sentinel,可以询问Redis服务群中的Master实例的地址。如果发生故障转移,Sentinel将通知客户端新的Master实例的地址。

Sentinel的分布式性质

Redis Sentinel是一个分布式系统,Sentinel采用同一份配置多个Sentinel进程共同协作运行的设计,多Sentinel进程协作的优势如下:

  • 多个Sentinel实例就给定的主机不再可用这一事实达成共识时,将执行故障检测,从而降低了误报的可能性。
  • Sentinel群中即使不是所有Sentinel处于可用状态,Sentinel群仍然能够正常工作,进行故障转移。

哨兵搭建

当前的Redis哨兵版本称为哨兵2,哨兵版本1是Redis 2.6的时候引入,现在已经过期,不推荐使用。官方文档中部署哨兵的示例中指出:一个健壮的部署至少需要三个Sentinel实例。再加上一般情况下,普通的Redis服务实例为了保证健壮性需要搭建树状主从,至少建议部署三个实例。这里的部署拓扑图如下:

 

环境配置

按照部署拓扑图,一共部署6个Redis实例,3个普通的Redis实例组成Master-Slave,并且是树状主从,3个Redis哨兵实例。为了简单起见,6个Redis实例部署在同一个虚拟机中,注意在生产或者测试环境要分散机器部署,避免所有鸡蛋放在同一个篮子出现机器单点故障。具体信息如下:

实例标识

角色

主机IP

端口

备注

Sentinel-1

-

192.168.56.200

26379

-

Sentinel-2

-

192.168.56.200

26380

-

Sentinel-3

-

192.168.56.200

26381

-

Redis-1

Master

192.168.56.200

6380

-

Redis-11

Slave

192.168.56.200

6381

Redis-1的从节点

Redis-111

Slave

192.168.56.200

6382

Redis-11的从节点

Sentinel配置和配置文件创建

先看样板配置文件sentinel.conf的内容:

port 26379
daemonize no
pidfile /var/run/redis-sentinel.pid
logfile ""
dir /tmp
sentinel monitor mymaster 127.0.0.1 6379 2
sentinel down-after-milliseconds mymaster 30000
sentinel parallel-syncs mymaster 1
sentinel failover-timeout mymaster 180000
sentinel deny-scripts-reconfig yes
# sentinel auth-pass mymaster 123456
# bind 127.0.0.1
# ......

完整的配置属性列表比较少,而portdaemonizepidfilelogfiledirbind等属性上一篇文章已经分析过,这里不再复述。

sentinel monitor <master-group-name> <ip> <port> <quorum>

  • master-group-name:被监控的目标Master实例的名称,这个值可以自定义。
  • ip:被监控的目标Master实例的服务器地址。
  • port:被监控的目标Master实例的端口。
  • quorum:仲裁参数,设置需要多少个Sentinel实例同意才能判断一个被监控的Redis实例失效。换言之,一个 Sentinel群需要获得系统中多数Sentinel的支持, 才能发起一次自动故障迁移。如果我们使用3个Sentinel实例,那么这个值可以定义为2。

sentinel monitor配置项比较特殊,主要用来指定Master角色Redis服务的链接信息。其他5个配置项采用下面的格式:

sentinel <option_name> <master-group-name> <option_value>
  • down-after-milliseconds:定了Sentinel认为被监控的Redis服务已经断线的总毫秒数。如果在指定的毫秒数之内,被监控的Redis服务没有向Sentinel回复PING信息或者回复了Error信息,那么Sentinel会开始认为被监控的Redis服务下线(其实这里是主观下线(subjectively down,简称SDOWN)。
  • parallel-syncs:指定了在执行故障转移时,最多可以有多少Slave实例同时对新的Master实例进行同步,这个数字越小,完成故障转移所需的时间就越长。这里建议参考样板配置中的值,设置为1。
  • failover-timeout:故障转移超时时间,单位为毫秒。
  • deny-scripts-reconfig:是否禁用SENTINEL SET命令运行时修改notification-scriptclient-reconfig-script,默认值为yes
  • auth-pass:配置连接Master实例的认证密码,如果Master实例没有设置密码,可以不配置此项属性。

创建3份Sentinel配置文件26379.conf26380.conf26381.conf,它们的内容十分相似,这里只列出26379.conf的内容(192.168.56.200是笔者虚拟机的主机地址):

port 26379
daemonize yes
bind 0.0.0.0
protected-mode no
pidfile /var/run/sentinel-26379.pid
logfile "/data/redis/sentinel-26379.log"
dir /data/redis
sentinel monitor doge-master 192.168.56.200 6380 2
sentinel down-after-milliseconds doge-master 30000
sentinel parallel-syncs doge-master 1
sentinel failover-timeout doge-master 180000

另外,创建3份Redis服务的配置文件6380.conf6381.conf6382.conf,它们的内容十分相似,这里只列出6380.conf(主节点)的内容:

port 6380
daemonize yes
bind 0.0.0.0
protected-mode no
pidfile /var/run/redis-6380.pid
logfile "/data/redis/redis-6380.log"
dir /data/redis
dbfilename "dump-6380.rdb"

6381.conf(从节点)尾部添加额外配置:

slaveof 192.168.56.200 6380

6382.conf(从节点)尾部添加额外配置:

slaveof 192.168.56.200 6381

每份配置记得替换好对应的端口号,都准备好了之后,依次启动主节点、两个从节点和3个Sentinel(可以把命令写成一个start.sh,调用sh start.sh):

/data/redis/redis-5.0.5/src/redis-server /data/redis/6380.conf
/data/redis/redis-5.0.5/src/redis-server /data/redis/6381.conf
/data/redis/redis-5.0.5/src/redis-server /data/redis/6382.conf /data/redis/redis-5.0.5/src/redis-sentinel /data/redis/26379.conf
/data/redis/redis-5.0.5/src/redis-sentinel /data/redis/26380.conf
/data/redis/redis-5.0.5/src/redis-sentinel /data/redis/26381.conf
 

此时查看哨兵的配置,发现被Redis修改,新增了发现的主从信息和哨兵实例信息:

 

查看一下哨兵实例的日志:

 

目前哨兵和Redis服务都正常运作。

模拟故障转移

官方文档中建议使用测试命令让Redis实例Sleep一个时间,从而触发故障转移:

redis-cli -p [port] DEBUG sleep 30

先查看当前的Master实例:

[root@localhost ~]# redis-cli -p 26379
127.0.0.1:26379> SENTINEL get-master-addr-by-name doge-master
1) "127.0.0.1"
2) "6380"

再对Master实例执行Sleep命令:

redis-cli -p 6380 DEBUG sleep 40

该命令会阻塞直到40秒后,控制台释放后,再查看当前的Master实例:

127.0.0.1:26379> SENTINEL get-master-addr-by-name doge-master
1) "127.0.0.1"
2) "6381"
127.0.0.1:26379>

可见,已经成功切换Master实例为6381。那么,当前的Master-Slave的拓扑关系到底是怎么样的?这个时候先看一下Sentinel的日志:

 

这里可以看出了,恢复后的6380实例重新成为了Slave角色,感觉有点翻车了,原来的树状主从部署变回了一主多从,笔者开始不相信,于是从当前的Master实例查看了一下主从信息:

 

确实如此,再检查了一下旧的主节点6380的配置:

port 6380
daemonize yes
bind 0.0.0.0
protected-mode no
pidfile "/var/run/redis-6380.pid"
logfile "/data/redis/redis-6380.log"
dir "/data/redis"
dbfilename "dump-6380.rdb"
# Generated by CONFIG REWRITE
replicaof 192.168.56.200 6381

发现,最后一行被新增了内容,它成为了从节点。这一点如果不实践,恐怕不知道会衍生出这种结果。画了个图表明一下整个过程:

 

这个问题暂时不深入探究,目前知道结果如此即可。

客户端代码测试

既然哨兵搭建完了,可以用Java客户端连接进行一些简单的操作。使用的是Lettuce驱动:

<dependency>
<groupId>io.lettuce</groupId>
<artifactId>lettuce-core</artifactId>
<version>5.1.8.RELEASE</version>
</dependency>

测试代码:

@Test
public void testSentinel() throws Exception {
RedisURI uri = RedisURI.builder()
.withSentinelMasterId("doge-master")
.withSentinel("192.168.56.200", 26379)
.build();
RedisClient redisClient = RedisClient.create(uri);
StatefulRedisMasterSlaveConnection<String, String> connection = MasterSlave.connect(redisClient, new Utf8StringCodec(), uri);
connection.setReadFrom(ReadFrom.SLAVE_PREFERRED);
RedisCommands<String, String> commands = connection.sync();
String result = commands.ping();
log.info("PING:{}", result);
commands.setex("name", 5, "throwable");
result = commands.get("name");
log.info("Get value:{}", result);
connection.close();
redisClient.shutdown();
}

输出结果:

PING:PONG
Get value:throwable

小结

Redis哨兵搭建相对简单,但是需要注意Redis主从配置和Sentinel配置,一些命令可以直接写成shell脚本方便一键shutdown或者重启。在测试故障转移的时候发现了树状主从会变成一主多从,这个问题后面会分析

参考文档: Redis5.x哨兵搭建手记 - 码农教程 (manongjc.com)

liunx下redis的哨兵环境搭建的更多相关文章

  1. 【redis】 linux 下redis 集群环境搭建

    Redis集群 (要让集群正常工作至少需要3个主节点,在这里我们要创建6个redis节点,其中三个为主节点,三个为从节点,对应的redis节点的ip和端口对应关系如下) 127.0.0.1:63791 ...

  2. linux环境(CentOS-6.7)下redis集群的搭建全过程

    linux环境下redis集群的搭建全过程: 使用mount命令将光盘挂载到/mnt/cdrom目录下: [root@hadoop03 ~]# mount -t iso9660 -o ro /dev/ ...

  3. Windows下Lua+Redis 断点调试环境搭建==Linux下类似

    Lua+Redis 断点调试环境搭建 windows环境,使用Redis,写lua脚本头疼的问题之一不能对脚本断点调试,google加上自己的摸索,终于搞定. 1.下载ZeroBraneStudio, ...

  4. Sublime Text 3下C/C++开发环境搭建

    Sublime Text 3下C/C++开发环境搭建 之前在Linux Mint 17一周使用体验中简单介绍过Sublime Text. 1.Sublime Text 3安装 Ubuntu.Linux ...

  5. Redis集群环境搭建

    Redis集群cluster环境搭建 描述:本章节主要单服务器搭建集群,在一个服务器上启动多个不同端口的redis服务,非真实环境. 真实环境下redis集群会搭建在多个物理服务器上,并非单一的服务器 ...

  6. Windows下ELK-5.4.3环境搭建

    Windows下ELK-5.4.3环境搭建 一.概述 ELK官网 https://www.elastic.co ELK由Elasticsearch.Logstash和Kibana三部分组件组成: El ...

  7. Redis进阶:Redis的哨兵模式搭建

    Redis进阶:Redis的哨兵模式搭建 哨兵机制介绍 单机版的Redis存在性能瓶颈,Redis通过提高主从复制实现读写分离,提高了了Redis的可用性,另一方便也能实现数据在多个Redis直接的备 ...

  8. Redis集群环境搭建实践

    0 Redis集群简介 Redis集群(Redis Cluster)是Redis提供的分布式数据库方案,通过分片(sharding)来进行数据共享,并提供复制和故障转移功能.相比于主从复制.哨兵模式, ...

  9. [转]MonkeyRunner在Windows下的Eclipse开发环境搭建步骤(兼解决网上Jython配置出错的问题)

    MonkeyRunner在Windows下的Eclipse开发环境搭建步骤(兼解决网上Jython配置出错的问题)   网上有一篇shangdong_chu网友写的文章介绍如何在Eclipse上配置M ...

  10. 转:Windows下的PHP开发环境搭建——PHP线程安全与非线程安全、Apache版本选择,及详解五种运行模式。

    原文来自于:http://www.ituring.com.cn/article/128439 Windows下的PHP开发环境搭建——PHP线程安全与非线程安全.Apache版本选择,及详解五种运行模 ...

随机推荐

  1. C# DevExpress下GridControl控件的增删查改

    DevExpress的GridControl控件可以从任何数据源绑定数据并进行增删查改等操作,和VS自带的dataGridView控件对比,GridControl控件可以实现更多自定义的功能,界面UI ...

  2. OS常用功能--持续更新

    import os # 拼接路径 print(os.path.join('a', 'b', 'c')) # 获取当前路径 print(os.getcwd()) # 在当前文件夹创建文件夹a # os. ...

  3. failed to push some refs to xxxx

    ***************ssh  秘钥上传远程仓库 1. 添加远程仓库ssh 命令   git remote add origin  git@github.com:ThreeNut/zou.gi ...

  4. docker 应用篇————具名挂载和匿名挂载[十三]

    前言 简单整理一下具名挂载和匿名挂载. 正文 来看一下匿名挂载. 这里-v指定了容器内部的路径,但是没有指定容器外部的路径,那么挂载到了什么地方. 用inspect 查看一下. 挂载到这个位置了. 然 ...

  5. oracle 数据库连接

    前言 关于oracle 数据库如何连接,我一开始以为和mysql 和 sql server一样,写好连接语句然后调用相应的dll. 知道我遇到了两个错误: 1.64位程序不能去驱动32位客户端 2.O ...

  6. WIN11 安装 SQL Server 2019,SQLSERVER2022, MYSQL 8.0 ,Docker,Mongodb失败故障分析

    最近研究数据库性能调优遇到各种数据库各种装不上,不知道熬了多少根软白沙,熬了多少颗张三疯,问了多少AI,查了多少网页,熬了两天,终于搞明白了一件事:那就是WIN11 ON ARM (因为拿的是MAC ...

  7. 【2021.6.26 NOI模拟】Problem B. 简单题 another solution

    Problem Description Input 从文件 b.in 中读入数据. 一个正整数 n. Output 输出到文件 b.out 中. 一个整数表示答案. Sample Data Input ...

  8. 深度解读 MongoDB 最全面的增强版本 4.4 新特性

    MongoDB 在今年正式发布了新的 4.4 大版本,这次的发布包含众多的增强 Feature,可以称之为是一个维护性的版本,而且是一个用户期待已久的维护性版本,MongoDB 官方也把这次发布称为「 ...

  9. N个技巧,编写更高效 Dockerfile|云效工程师指北

    简介:云原生时代下软件的构建和部署离不开容器技术.提到容器,几乎大家下意识都会联想到 Docker .而 Docker 中有两个非常重要的概念,一个是Image(镜像),一个是Container(容器 ...

  10. 京东:Flink SQL 优化实战

    简介: 本文着重从 shuffle.join 方式的选择.对象重用.UDF 重用等方面介绍了京东在 Flink SQL 任务方面做的优化措施. 本文作者为京东算法服务部的张颖和段学浩,并由 Apach ...