redis集群之Sentinel

  目前我们讲的 Redis 还只是主从方案,最终一致性。读者们可思考过,如果主节点凌晨3 点突发宕机怎么办?就坐等运维从床上爬起来,然后手工进行从主切换,再通知所有的程序把地址统统改一遍重新上线么?毫无疑问,这样的人工运维效率太低,事故发生时估计得至少 1 个小时才能缓过来。如果是一个大型公司,这样的事故足以上新闻了。

  所以我们必须有一个高可用方案来抵抗节点故障,当故障发生时可以自动进行从主切换,程序可以不用重启,运维可以继续睡大觉,仿佛什么事也没发生一样。Redis 官方提供了这样一种方案 —— Redis Sentinel(哨兵)。

  我们可以将 Redis Sentinel 集群看成是一个 ZooKeeper 集群,它是集群高可用的心脏,它一般是由 3~5 个节点组成,这样挂了个别节点集群还可以正常运转。

  它负责持续监控主从节点的健康,当主节点挂掉时,自动选择一个最优的从节点切换为主节点。客户端来连接集群时,会首先连接 sentinel,通过 sentinel 来查询主节点的地址,然后再去连接主节点进行数据交互。当主节点发生故障时,客户端会重新向 sentinel 要地址,sentinel 会将最新的主节点地址告诉客户端。如此应用程序将无需重启即可自动完成节点切换。比如上图的主节点挂掉后,集群将可能自动调整为下图所示结构。

  从这张图中我们能看到主节点挂掉了,原先的主从复制也断开了,客户端和损坏的主节点也断开了。从节点被提升为新的主节点,其它从节点开始和新的主节点建立复制关系。客户端通过新的主节点继续进行交互。Sentinel 会持续监控已经挂掉了主节点,待它恢复后,集群会调整为下面这张图。

  此时原先挂掉的主节点现在变成了从节点,从新的主节点那里建立复制关系。

消息丢失

  Redis 主从采用异步复制,意味着当主节点挂掉时,从节点可能没有收到全部的同步消息,这部分未同步的消息就丢失了。如果主从延迟特别大,那么丢失的数据就可能会特别多。Sentinel 无法保证消息完全不丢失,但是也尽可能保证消息少丢失。它有两个选项可以限制主从延迟过大。

min-slaves-to-write 1
min-slaves-max-lag 10
  第一个参数表示主节点必须至少有一个从节点在进行正常复制,否则就停止对外写服
务,丧失可用性。

  何为正常复制,何为异常复制?这个就是由第二个参数控制的,它的单位是秒,表示如果 10s 没有收到从节点的反馈,就意味着从节点同步不正常,要么网络断开了,要么一直没有给反馈。

Sentinel 基本使用
  接下来我们看看客户端如何使用 sentinel,标准的流程应该是客户端可以通过 sentinel 
发现主从节点的地址,然后在通过这些地址建立相应的连接来进行数据存取操作。我们来看看 Python 客户端是如何做的。

>>> from redis.sentinel import Sentinel
>>> sentinel = Sentinel([(‘localhost‘, 26379)], socket_timeout=0.1)
>>> sentinel.discover_master(‘mymaster‘)
(‘127.0.0.1‘, 6379)
>>> sentinel.discover_slaves(‘mymaster‘)
[(‘127.0.0.1‘, 6380)]
  sentinel 的默认端口是 26379,不同于 Redis 的默认端口 6379,通过 sentinel 对象的
discover_xxx 方法可以发现主从地址,主地址只有一个,从地址可以有多个。

>>> master = sentinel.master_for(‘mymaster‘, socket_timeout=0.1)
>>> slave = sentinel.slave_for(‘mymaster‘, socket_timeout=0.1)
>>> master.set(‘foo‘, ‘bar‘)
>>> slave.get(‘foo‘)
‘bar‘
  通过 xxx_for 方法可以从连接池中拿出一个连接来使用,因为从地址有多个,redis 客
户端对从地址采用轮询方案,也就是 RoundRobin 轮着来。有个问题是,但 sentinel 进行主从切换时,客户端如何知道地址变更了 ? 通过分析源码,我发现 redis-py 在建立连接的时候进行了主库地址变更判断。连接池建立新连接时,会去查询主库地址,然后跟内存中的主库地址进行比对,如果变更了,就断开所有连接,重新使用新地址建立新连接。如果是旧的主库挂掉了,那么所有正在使用的连接都会被关闭,然后在重连时就会用上新地址。但是这样还不够,如果是 sentinel 主动进行主从切换,主库并没有挂掉,而之前的主库连接已经建立了在使用了,没有新连接需要建立,那这个连接是不是一致切换不了?继续深入研究源码,我发现 redis-py 在另外一个点也做了控制。那就是在处理命令的时候捕获了一个特殊的异常 ReadOnlyError,在这个异常里将所有的旧连接全部关闭了,后续指令就会进行重连。主从切换后,之前的主库被降级到从库,所有的修改性的指令都会抛出 ReadonlyError。如果没有修改性指令,虽然连接不会得到切换,但是数据不会被破坏,所以即使不切换也没关系。

原文地址:https://www.cnblogs.com/wuwuyong/p/11774464.html

时间: 2024-10-13 06:53:52

redis集群之Sentinel的相关文章

玩转 Redis 集群之 Sentinel

Redis作为内存数据库,需要具备高可用的特点,不然如果服务器宕机,还在内存里的数据就会丢失.我们最常用的高可用方法就是搭建集群,master机器挂了,可以让slave机器顶上,继续提供服务.但是Redis集群是不会自动进行主从切换的,也就是说,如果主节点非常不争气的在凌晨3点挂了,那么运维同学就要马上起床,把从节点改成主节点,这样的操作是非常繁琐低效的.为此,Redis官方提供了一种解决方案:Redis Sentinel 简介 Redis Sentinel集群通常由3到5个节点组成,如果个别节

redis集群(Sentinel)

问题 Redis 主哨兵模式是如何保证高可用的 主要依赖主哨兵的发现故障和故障转移 概述 本文假设读者对redis 的主从复制已经进行了了解 . Redis 主哨兵集群为Redis 提供了高可用,即高可用是猪哨兵模式的主要目的,这是宏观上Sentinel功能的完整列表 Monitoring :监视实例的情况 Notification : 通知 Automatic failover : 当Master异常下线后,自动会通过选举 Configuration provider : 提供配置信息. 注意

Redis集群 之 Sentinel模式Windows篇

1.环境 a.下载Redis:访问 https://github.com/MicrosoftArchive/redis/releases 下载Windows版Redis,并解压 2.哨兵模式配置 a.复制3份Redis作为3个节点,分别命名为8081.8082.8083 b.修改 Redis 各节点中的 redis.windows.conf 配置文件 1)8081节点: #端口号改为8081 port 8081 2)8082节点: #端口号改为8082 port 8082 #设置该slave的m

Redis集群redis主从自动切换Sentinel(哨兵模式)

Redis SentinelSentinel(哨兵)是用于监控redis集群中Master状态的工具,其已经被集成在redis2.4+的版本中 一.Sentinel作用:1):Master状态检测 2):如果Master异常,则会进行Master-Slave切换,将其中一个Slave作为Master,将之前的Master作为Slave3):Master-Slave切换后,master_redis.conf.slave_redis.conf和sentinel.conf的内容都会发生改变,即mast

redis 集群热备自动切换sentinel配置实战

Redis SentinelSentinel(哨兵)是用于监控redis集群中Master状态的工具,其已经被集成在redis2.4+的版本中 一.Sentinel作用:1):Master状态检测 2):如果Master异常,则会进行Master-Slave切换,将其中一个Slave作为Master,将之前的Master作为Slave3):Master-Slave切换后,master_redis.conf.slave_redis.conf和sentinel.conf的内容都会发生改变,即mast

基于Redis Sentinel的Redis集群(主从&Sharding)高可用方案

基于Redis Sentinel的Redis集群(主从&Sharding)高可用方案 http://www.tuicool.com/articles/naeEJbv 基于Redis Sentinel的Redis集群(主从&Sharding)高可用方案 时间 2014-02-21 15:15:17  IT社区推荐资讯 原文  http://itindex.net/detail/48192-redis-sentinel-redis Redis Sentinel是一个分布式系统,可以部署多个Se

基于Redis Sentinel的Redis集群(主从Sharding)高可用方案(转)

本文主要介绍一种通过Jedis&Sentinel实现Redis集群高可用方案,该方案需要使用Jedis2.2.2及以上版本(强制),Redis2.8及以上版本(可选,Sentinel最早出现在Redis2.4中,Redis2.8中Sentinel更加稳定),Redis集群是以分片(Sharding)加主从的方式搭建,满足可扩展性的要求: Redis Sentinel介绍 Redis Sentinel是Redis官方提供的集群管理工具,主要有三大功能: 监控,能持续监控Redis的主从实例是否正常

02.Redis主从集群的Sentinel配置

阅读目录 开始 1.集群环境 2.配置并启动Redis主从集群 3.配置sentinel集群并启动 4.测试sentinel集群 回到顶部 1.集群环境 1.Linux服务器列表 使用4台CentOS Linux服务器搭建环境,其IP地址如下: 192.168.110.100192.168.110.101192.168.110.102192.168.110.103 2.Redis服务部署环境 192.168.110.100    启动多个Redis sentinel服务,构成Redis sent

sentinel搭建redis集群经验总结

一.protected-mode默认情况下,redis node和sentinel的protected-mode都是yes,在搭建集群时,若想从远程连接redis集群,需要将redis node和sentinel的protected-mode修改为no,若只修改redis node,从远程连接sentinel后,依然是无法正常使用的,且sentinel的配置文件中没有protected-mode配置项,需要手工添加.依据redis文档的说明,若protected-mode设置为no后,需要增加密