12.【Redis系列】集群方案1- Sentinel

原文:12.【Redis系列】集群方案1- Sentinel

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

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

image.png

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

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

image.png

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

image.png

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

消息丢失

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/lonelyxmas/p/12515054.html

时间: 2024-08-09 22:01:13

12.【Redis系列】集群方案1- Sentinel的相关文章

Redis缓存集群方案

由于单台Redis服务器的内存管理能力有限,使用过大内存的Redis又会使得服务器的性能急剧下降,一旦服务器发生故障将会影响更大范围业务,而Redis 3.0 beta1支持的集群功能还不适合生产环境的使用.于是为了获取更好的Redis缓存性能及可用性,很多公司都研发了Redis缓存集群方案.现对NetFlix.Twitter.国内的豌豆荚在缓存集群方面的解决方案进行一个汇总,以供读者参考,具体内容如下: 1.NetFlix对Dynamo的开源通用实现Dynomite Dynomite是NetF

Redis学习笔记(11)——Redis缓存集群方案

由于单台Redis服务器的内存管理能力有限,使用过大内存的Redis又会使得服务器的性能急剧下降,一旦服务器发生故障将会影响更大范围业务,而Redis 3.0 beta1支持的集群功能还不适合生产环境的使用.于是为了获取更好的Redis缓存性能及可用性,很多公司都研发了Redis缓存集群方案.现对NetFlix.Twitter.国内的豌豆荚在缓存集群方面的解决方案进行一个汇总,以供读者参考,具体内容如下: 1.NetFlix对Dynamo的开源通用实现Dynomite Dynomite是NetF

170103、Redis官方集群方案 Redis Cluster

前面我们谈了Redis Sharding多服务器集群技术,Redis Sharding是客户端Sharding技术,对于服务端来说,各个Redis服务器彼此是相互独立的,这对于服务端根据需要灵活部署Redis非常轻便,Redis Sharding具有很好的灵活性.可伸缩性,是一种轻量级集群技术. 本篇,介绍另外一种多Redis服务器集群技术,即Redis Cluster.Redis Cluster是一种服务器Sharding技术,3.0版本开始正式提供. Redis Cluster中,Shard

Redis集群方案及实现 - yfk的专栏 - 博客频道 - CSDN.NET

[公告]博客系统优化升级        Unity3D学习,离VR开发还有一步        博乐招募开始啦        虚拟现实,一探究竟 Redis集群方案及实现 2014-08-30 17:20     43035人阅读     评论(15)     收藏     举报 本文章已收录于: .embody{ padding:10px 10px 10px; margin:0 -20px; border-bottom:solid 1px #ededed; } .embody_b{ margin

Redis集群方案,Codis安装测试

1,关于豌豆荚开源的Codis Codis是豌豆荚使用Go和C语言开发.以代理的方式实现的一个Redis分布式集群解决方案,且完全兼容Twemproxy.Twemproxy对于上一层的应用来说, 连接Codis Proxy(Redis代理服务)和连接原生的Redis服务器没有明显的区别,上一层应用能够像使用单机的 Redis一样对待.Codis底层会处理请求的转发.不停机的数据迁移等工作, 所有底层的一切处理, 对于客户端来说是透明的.总之,可以简单的认为后台连接的是一个内存无限大的Redis服

架构设计:系统存储(18)——Redis集群方案:高性能

1.概述 通过上一篇文章(<架构设计:系统存储(17)--Redis集群方案:高可用>)的内容,Redis主从复制的基本功能和进行Redis高可用集群监控的Sentinel基本功能基本呈现给了读者.虽然本人并不清楚上一篇根据笔者实际工作经验所撰写的文章有什么重大问题,导致那么多朋友集体点踩而且截止目前又没有任何人愿意为笔者指出这些问题,但是这不会影响笔者继续学习.总结技术知识的热情.从这篇文章开始我们一起来讨论Redis中两种高性能集群方案,并且在讨论过程中将上一篇文章介绍的高可用集群方案结合

关于redis集群方案

最近在研究redis集群方案,看到知乎上有个朋友写的观点很好,就先收过来了.原文见:http://www.zhihu.com/question/21419897 为什么集群? 通常,为了提高网站响应速度,总是把热点数据保存在内存中而不是直接从后端数据库中读取.Redis是一个很好的Cache工具.大型网站应用,热点数据量往往巨大,几十G上百G是很正常的事儿,在这种情况下,如何正确架构Redis呢? 首先,无论我们是使用自己的物理主机,还是使用云服务主机,内存资源往往是有限制的,scale up不

Redis集群方案应该怎么做

方案1:Redis官方集群方案 Redis Cluster Redis Cluster是一种服务器sharding分片技术. Redis3.0版本开始正式提供,解决了多Redis实例协同服务问题,时间较晚,目前能证明在大规模生产环境下成功的案例还不是很多,需要时间检验. Redis Cluster中,Sharding采用slot(槽)的概念,一共分成16384个槽.对于每个进入Redis的键值对,根据key进行散列,分配到这16384个slot中的某一个中.使用的hash算法也比较简单,CRC1

Redis集群方案及实现

之前做了一个Redis的集群方案,跑了小半年,线上运行的很稳定差不多可以跟大家分享下经验,前面写了一篇文章数据在线服务的一些探索经验,可以做为背景阅读 应用 我们的Redis集群主要承担了以下服务:1. 实时推荐2. 用户画像3. 诚信分值服务 集群状况 集群峰值QPS 1W左右,RW响应时间999线在1ms左右整个集群:1. Redis节点: 8台物理机;每台128G内存;每台机器上8个instance2. Sentienl:3台虚拟机 集群方案 Redis Node由一组Redis Inst

Redis集群方案(来自网络)

参考: https://www.zhihu.com/question/21419897 http://www.cnblogs.com/haoxinyue/p/redis.html 为什么集群? 通常,为了提高网站响应速度,总是把热点数据保存在内存中而不是直接从后端数据库中读取.Redis是一个很好的Cache工具.大型网站应用,热点数据量往往巨大,几十G上百G是很正常的事儿,在这种情况下,如何正确架构Redis呢? 首先,无论我们是使用自己的物理主机,还是使用云服务主机,内存资源往往是有限制的,