Redis高可用VIP漂移方法、终端及存储介质与制作流程
- 格式:pdf
- 大小:107.51 KB
- 文档页数:11
redis6种策略Redis是一种流行的开源内存数据库,它提供了多种策略来处理数据。
本文将介绍Redis的六种策略,包括数据持久化、主从复制、高可用性、分布式缓存、事务处理和发布订阅。
一、数据持久化数据持久化是Redis的核心特性之一,它允许将内存中的数据保存到硬盘中,以防止数据丢失。
Redis提供了两种数据持久化策略:RDB和AOF。
1. RDB(Redis DataBase)是一种快照式的持久化策略,它会将数据保存为二进制文件。
RDB的优点是文件体积小、加载速度快,适合用于备份和恢复数据。
缺点是在发生故障时可能会有数据丢失。
2. AOF(Append Only File)是一种追加式的持久化策略,它会将每个写操作追加到文件末尾。
AOF的优点是可以提供更好的数据安全性,因为每个操作都会被记录下来。
缺点是文件体积相对较大,加载速度相对较慢。
二、主从复制主从复制是一种将数据从一个Redis服务器复制到多个Redis服务器的策略,用于提高系统的读写性能和可用性。
主从复制的过程分为三个步骤:复制初始化、全量复制和增量复制。
1. 复制初始化:从服务器连接主服务器,并通过发送SYNC命令来进行复制初始化。
2. 全量复制:主服务器将自己的数据发送给从服务器,从服务器接收并加载数据。
3. 增量复制:主服务器将自己的写操作发送给从服务器,从服务器接收并执行写操作,从而保持数据的一致性。
主从复制可以提高系统的读写性能,同时还可以提供故障切换和负载均衡的功能。
三、高可用性高可用性是指系统在发生故障时能够保持正常运行的能力。
Redis 提供了多种策略来实现高可用性,包括哨兵模式和集群模式。
1. 哨兵模式:哨兵模式是通过监控主服务器的状态来实现高可用性。
当主服务器发生故障时,哨兵会自动将一个从服务器升级为主服务器,从而保证系统的可用性。
2. 集群模式:集群模式是通过将数据分布在多个节点上来实现高可用性。
当某个节点发生故障时,其他节点会自动接管该节点的工作,从而保证系统的可用性。
Redis原理和⾼可⽤场景实践总结⽬录1.Redis基础原理和知识1.1 redis和memcached有啥区别1)Redis⽀持服务器端的数据操作:Redis相⽐Memcached来说,拥有更多的数据结构和并⽀持更丰富的数据操作,通常在Memcached⾥,你需要将数据拿到客户端来进⾏类似的修改再set回去。
这⼤⼤增加了⽹络IO的次数和数据体积。
在Redis中,这些复杂的操作通常和⼀般的GET/SET⼀样⾼效。
所以,如果需要缓存能够⽀持更复杂的结构和操作,那么Redis会是不错的选择。
2)集群模式:memcached没有原⽣的集群模式,需要依靠客户端来实现往集群中分⽚写⼊数据;但是redis⽬前是原⽣⽀持cluster模式的,redis官⽅就是⽀持redis cluster集群模式的,⽐memcached来说要更好1.2 redis的线程模型redis单线程模型1.2.1基础概念铺垫redis基于reactor模式开发了⽹络事件处理器,这个处理器叫做⽂件事件处理器⽂件事件处理器是单线程模式运⾏的,但是通过IO多路复⽤机制监听多个socket,可以实现⾼性能的⽹络通信模型,⼜可以跟内部其他单线程的模块进⾏对接,保证了redis内部的线程模型的简单性。
⽂件事件处理器的结构包含4个部分:多个socket,IO多路复⽤程序,⽂件事件分派器,事件处理器(命令请求处理器、命令回复处理器、连接应答处理器,等等)⽂件事件处理器的结构多个socket可能并发的产⽣不同的操作,每个操作对应不同的⽂件事件,但是IO多路复⽤程序会监听多个socket,但是会将socket放⼊⼀个队列中排队,每次从队列中取出⼀个socket给事件分派器,事件分派器把socket给对应的事件处理器。
当socket变得可读时,socket就会产⽣⼀个AE_READABLE事件。
当socket变得可写的时候,socket会产⽣⼀个AE_WRITABLE事件。
redis culster的工作原理Redis Cluster是Redis分布式的解决方案,通过将数据分布在多个节点上,实现了数据的高可用性和扩展性。
Redis Cluster的工作原理可以概括为以下几个方面。
Redis Cluster采用了一种无中心节点的结构,所有的节点都是对等的。
每个节点都可以接收客户端的请求,并参与数据的读写操作。
在集群内部,节点之间通过gossip协议进行通信,实现数据的同步和故障检测。
每个节点都会定期向集群中的其他节点发送信息,包括自己的状态、数据槽分配情况等。
通过这种方式,集群中的节点可以动态地感知到其他节点的状态变化。
Redis Cluster使用了一种哈希槽的方式来管理数据的分布。
集群中的每个节点都负责管理一部分哈希槽,每个槽对应数据中的一个键。
当客户端发送一个命令请求时,Redis Cluster会根据键的哈希值确定其所属的槽,并将命令转发给负责该槽的节点。
这样,每个节点只需要管理部分数据,大大提高了集群的存储能力和性能。
Redis Cluster还实现了数据的冗余备份,提高了数据的可靠性。
每个槽都会有一个主节点和若干个从节点。
主节点负责处理客户端的请求,并将数据同步给从节点。
当主节点发生故障时,从节点会自动选举出一个新的主节点来接替其工作。
这样,即使集群中的某个节点发生故障,仍然能够保证数据的正常访问。
Redis Cluster还提供了一种自动迁移的机制,可以在节点的增删或者故障恢复时进行数据的重新分配。
当新增一个节点时,集群会将一部分槽从其他节点迁移到新的节点上。
当某个节点发生故障后恢复时,集群会将该节点负责的槽重新分配给它。
通过这种方式,Redis Cluster实现了数据的动态平衡和自动恢复,提高了集群的可用性和健壮性。
总结起来,Redis Cluster通过节点的无中心化结构、哈希槽的数据分布、数据的冗余备份和自动迁移等机制,实现了数据的高可用性和扩展性。
Redis 备份、容灾及高可用方案一,Redis简单介绍Redis是一个高性能的key-value非关系型数据库,由于其具有高性能的特性,支持高可用、持久化、多种数据结构、集群等,使其脱颖而出,成为常用的非关系型数据库。
此外,Redis的使用场景也比较多。
我们常通过Reids的队列功能做购买限制。
比如到节假日或者推广期间,进行一些活动,对用户购买行为进行限制,限制今天只能购买几次商品或者一段时间内只能购买一次。
也比较适合适用。
4.排名Redis在内存中对数字进行递增或递减的操作实现得非常好。
所以我们在很多排名的场景中会应用Redis来进行,比如小说网站对小说进行排名,根据排名,将排名靠前的小说推荐给用户。
5.发布/订阅Redis提供发布和订阅功能,发布和订阅的场景很多,比如我们可以基于发布和订阅的脚本触发器,实现用Redis的发布和订阅功能建立起来的聊天系统。
此外还有很多其它场景,Redis都表现的不错。
二,Redis使用中单点故障问题正是由于Redis具备多种优良特新,且应用场景非常丰富,以至于Redis在各个公司都有它存在的身影。
那么随之而来的问题和风险也就来了。
Redis虽然应用场景丰富,但部分公司在实践Redis应用的时候还是相对保守使用单节点部署,那为日后的维护带来了安全风险。
在2015年的时候,曾处理过一个因为单点故障原因导致的业务中断问题。
当时的Redis都未采用分布式部署,采用单实例部署,并未考虑容灾方面的问题。
当时我们通过Redis服务器做用户购买优惠商品的行为控制,但后来由于未知原因Redis节点的服务器宕机了,导致我们无法对用户购买行为进行控制,造成了用户能够在一段时间内多次购买优惠商品的行为。
这种宕机事故可以说已经对公司造成了不可挽回的损失了,安全风险问题非常严重,作为当时运维这个系统的我来说有必要对这个问题进行修复和在架构上的改进。
于是我开始了解决非分布式应用下Redis单点故障方面的研究学习。
redis使用流程(原创版)目录1.Redis 简介2.Redis 的使用流程2.1 安装 Redis2.2 启动 Redis 服务2.3 客户端连接 Redis 服务器2.4 创建和操作 Redis 数据库2.5 关闭 Redis 服务正文【Redis 简介】Redis 是一个基于内存的开源数据库系统,它支持多种数据结构,如字符串、哈希表、列表、集合和有序集合等。
Redis 以其高性能、可扩展性和灵活性而广受欢迎,被广泛应用于缓存、消息队列、排行榜和实时计数器等场景。
【Redis 的使用流程】2.1 安装 Redis在使用 Redis 之前,首先需要在计算机上安装 Redis。
可以访问Redis 官方网站 (https://redis.io/download) 下载适用于不同操作系统的 Redis 版本。
下载完成后,按照官方文档的指引进行安装。
2.2 启动 Redis 服务安装完成后,需要启动 Redis 服务。
在命令行中输入“redis-server”命令,回车后即可启动 Redis 服务。
如果需要设置 Redis 的配置文件,可以使用“redis-server /path/to/redis.conf”命令启动。
2.3 客户端连接 Redis 服务器要与 Redis 服务器进行交互,需要使用 Redis 客户端。
可以使用Redis 官方提供的客户端,也可以使用第三方客户端。
在命令行中输入“redis-cli”命令,回车后即可启动 Redis 客户端。
在客户端中,使用“connect”命令连接 Redis 服务器,如“connect 127.0.0.1:6379”。
2.4 创建和操作 Redis 数据库连接到 Redis 服务器后,可以创建和操作 Redis 数据库。
Redis 中的数据库是以数字命名的,使用“db”命令切换数据库,如“db 0”。
在数据库中,可以使用多种命令来操作数据,如“set”命令设置键值对,“get”命令获取键的值,“del”命令删除键等。
最近整理一下Redis高可用架构的文档,也准备分享出来,虽然这些架构也不是很复杂。
Redis的高可用方案目前主要尝试过5种方式,其中2种方式已经在线上使用。
1)Redis Master-Slave + Keepalive + VIP。
这是很经典的db架构,也可以用与mysql的主从切换。
基本原理是:Keepalive通过脚本检测master的存活,然后通过漂移VIP(Virtual IP)完成主从切换。
2)Redis Master-Slave + DNS Service + Sentinel。
基本原理是Sentinel集群进行Redis的存活检测和Redis M-S状态切换。
完成切换之后,sentinel调用notification-script参数制定的配置文件,通知DNS Server更改DNS配置,master dns解析执行新的master。
3)Redis Master-Slave + Configure Center(Zookeeper)+ Sentinel.基本原理和第三种方案相似,只是notification-script通知的是配置中心完成redis连接配置的修改,比如Zookeeper实现的配置中心。
4)Redis Master-Slave + Sentinel + Twemproxy + Lvs.这种方案层次比较多,sentinel通知twemproxy进行redis m-s的配置更改。
5)Redis Cluster,目前redis3.0接近发布stable版本了。
1、基本架构图2、基本构建与原理1)Keepalive + VIP : 在redis master-slave上部署keepalived、redis instance存活检测脚本、以及告警通知脚本。
2)当redis master失效的时候,VIP从master上漂移到slave上,完成m-s角色和配置更改。
3)客户端连接redis的参数中host设置的是VIP,整个切换过程对客户端透明。
高可用Redis 服务架构设计基于内存的Redis应该是目前各种web开发业务中最为常用的key-value数据库了,我们经常在业务中用其存储用户登陆态(Session存储),加速一些热数据的查询(相比较mysql而言,速度有数量级的提升),做简单的消息队列(LPUSH和BRPOP)、订阅发布(PUB/SUB)系统等等。
规模比较大的互联网公司,一般都会有专门的团队,将Redis存储以基础服务的形式提供给各个业务调用。
不过任何一个基础服务的提供方,都会被调用方问起的一个问题是:你的服务是否具有高可用性?最好不要因为你的服务经常出问题,导致我这边的业务跟着遭殃。
最近我所在的项目中也自己搭了一套小型的“高可用”Redis服务,在此做一下自己的总结和思考。
首先我们要定义一下对于Redis服务来说怎样才算是高可用,即在各种出现异常的情况下,依然可以正常提供服务。
或者宽松一些,出现异常的情况下,只经过很短暂的时间即可恢复正常服务。
所谓异常,应该至少包含了以下几种可能性:【异常1】某个节点服务器的某个进程突然down掉(例如某开发手残,把一台服务器的redis-server进程kill了)【异常2】某台节点服务器down掉,相当于这个节点上所有进程都停了(例如某运维手残,把一个服务器的电源拔了;例如一些老旧机器出现硬件故障)【异常3】任意两个节点服务器之间的通信中断了(例如某临时工手残,把用于两个机房通信的光缆挖断了)其实以上任意一种异常都是小概率事件,而做到高可用性的基本指导思想就是:多个小概率事件同时发生的概率可以忽略不计。
只要我们设计的系统可以容忍短时间内的单点故障,即可实现高可用性。
对于搭建高可用Redis服务,网上已有了很多方案,例如Keepalived,Codis,Twemproxy,Redis Sentinel。
其中Codis和Twemproxy主要是用于大规模的Redis集群中,也是在Redis 官方发布Redis Sentinel之前twitter和豌豆荚提供的开源解决方案。
Redis缓存系统使用教程1. 引言Redis(REmote DIctionary Server)是一个开源的高性能key-value存储系统,广泛应用于缓存、消息队列、分布式锁等场景。
本文将介绍Redis缓存系统的使用教程,包括安装、配置、数据操作等内容。
2. 安装Redis2.1 下载Redis源码或安装包2.2 解压源码或执行安装包2.3 编译并安装Redis2.4 配置环境变量3. 配置Redis3.1 编辑Redis配置文件3.2 配置监听端口3.3 配置数据持久化3.4 配置内存淘汰策略3.5 配置缓存过期策略4. 连接Redis4.1 使用命令行工具连接4.2 使用编程语言连接4.3 配置连接池5. 数据操作5.1 设置缓存数据5.2 获取缓存数据5.3 更新缓存数据5.4 删除缓存数据5.5 批量操作6. 缓存策略6.1 缓存穿透的解决方案6.2 缓存击穿的解决方案6.3 缓存雪崩的解决方案6.4 缓存更新策略6.5 缓存预热7. 高级功能7.1 发布与订阅7.2 主从复制7.3 数据分片7.4 Lua脚本执行7.5 事务处理8. 性能优化8.1 使用Pipeline批量操作8.2 使用Hash数据结构8.3 使用Bitmaps数据结构8.4 使用HyperLogLog数据结构8.5 使用SortedSet数据结构9. 安全性保障9.1 设置密码进行认证9.2 配置网络访问权限9.3 数据持久化与备份9.4 监控与日志10. 总结Redis缓存系统是一款强大且灵活的缓存工具,具备高性能、易部署和丰富的功能特性。
本文从安装配置、连接使用、数据操作、缓存策略、高级功能、性能优化和安全性保障等方面进行了详细介绍,希望读者可以通过本文快速掌握Redis的使用技巧,并在实际开发中灵活应用。
需要注意的是,Redis的使用需要根据实际场景进行合理配置和策略制定,以达到最佳性能和安全性。
怎么实现Redis 的高可用?实现Redis的高可用性通常涉及以下几个方面的考虑:1. 主从复制(Master-Slave Replication):Redis通过主从复制来提供数据的冗余备份和读取负载均衡。
一个Redis主节点(Master)可以有多个从节点(Slave),主节点负责写操作,而从节点负责复制主节点的数据,并可以处理读请求。
2. 哨兵模式(Sentinel):哨兵是一个用于监控Redis主从节点状态的特殊进程。
多个哨兵可以组成一个哨兵集群,用于自动发现故障并进行主节点切换。
当主节点不可用时,哨兵可以选举一个新的主节点,并更新所有的从节点指向新的主节点,实现高可用性。
3. 持久化(Persistence):通过将数据持久化到磁盘,可以在Redis重新启动时保持数据的一致性。
Redis支持两种持久化方式:RDB快照(snapshotting)和AOF日志(Append-Only File)。
RDB快照是定期对数据进行快照备份,而AOF日志则记录每次写操作,可以用于恢复数据。
4. 自动分片(Sharding):当数据量较大时,可以通过对数据进行分片来提高性能和可用性。
Redis Cluster是Redis官方提供的分布式解决方案,它支持自动分片和高可用。
Redis Cluster将数据分散存储在多个节点上,并提供了故障检测和自动故障转移的功能。
5. 网络分区容忍性:在一个分布式系统中,可能会发生网络分区(Network Partition)的情况,即部分节点无法与其他节点通信。
为了提高系统的容忍性,需要在网络分区发生时能够保持系统的可用性。
Redis Cluster和Sentinel都考虑了这一点,并在设计中充分考虑了网络分区容忍性。
综合使用上述策略,可以构建一个具有高可用性的Redis架构。
不同的应用场景可能选择不同的组合方式,以满足特定的需求。
例如,可以使用主从复制和哨兵模式提供基本的高可用性,对于大规模的数据,还可以考虑使用Redis Cluster进行分片。
Redis缓存的原理和工作流程Redis是一种开源的内存数据存储系统,常用于缓存、消息队列和数据存储等场景。
本文将介绍Redis缓存的原理和工作流程。
一、Redis缓存原理Redis缓存的原理基于键值对存储结构,使用内存作为数据存储介质,因此具有高速读写的特性。
下面将详细介绍Redis缓存的原理。
1. 缓存架构Redis缓存采用了经典的客户端-服务器架构模式。
客户端通过网络连接方式与Redis服务器通信,将需要缓存的数据发送给服务器,服务器将这些数据存储在内存中。
当客户端需要获取数据时,通过网络请求将数据从服务器取回。
这种架构使得Redis缓存能够支持高并发的读写操作。
2. 缓存策略Redis缓存常用的缓存策略包括FIFO(先进先出)、LRU(最近最少使用)、LFU(最不常使用)等。
其中,LRU是最常用的策略之一,根据数据的访问时间进行淘汰,保留最近使用频率较高的数据。
采用合适的缓存策略可以提高缓存的效率和命中率。
3. 缓存更新为了保证缓存数据的一致性,当原始数据发生更新时,需要及时更新缓存中的数据。
Redis提供了多种缓存更新方式,包括主动更新和被动更新。
主动更新是指在数据更新时,通过更新缓存的操作保持缓存与数据库的一致性;被动更新是指在缓存数据过期后,再次请求数据时更新缓存。
二、Redis缓存的工作流程Redis缓存的工作流程包括数据写入、数据读取和缓存失效三个步骤。
下面将详细介绍Redis缓存的工作流程。
1. 数据写入当客户端需要将数据写入到Redis缓存中时,首先将数据发送给Redis服务器。
服务器接收到数据后,将数据按照键值对的方式存储在内存中,并设置对应的缓存策略和过期时间。
数据写入完成后,服务器返回写入成功的消息给客户端。
2. 数据读取当客户端需要读取缓存中的数据时,首先向Redis服务器发送数据请求。
服务器接收到读取请求后,检查缓存中是否存在对应的数据。
如果存在,则将数据返回给客户端;如果不存在,则继续从数据库中读取数据,并将读取到的数据存入缓存,然后返回给客户端。
本技术公开了一种Redis高可用VIP漂移方法、终端及存储介质,属于云数据库,要解决的技术问题为如何在确保Redis节点密钥的安全性、且主从节点身份切换时不会导致服务状态混乱的前提下,实现VIP漂移的问题。
方法包括:通过哨兵监测每个Redis节点的运行状态;通过节点监控器监测对应Redis节点的身份;通过哨兵切换两个Redis节点的主从身份,通过部署于原主节点中的节点监控器将原节点与VIP解绑,通过部署于切换后主节点中的节点监控器将切换后主节点与VIP绑定。
终端中处理器被配置用于调用程序指令执行上述方法。
存储介质存储有计算机程序,计算机程序中程序指令当被处理器执行时处理器执行上述方法。
权利要求书1.一种Redis高可用VIP漂移方法,其特征在于用于实现两个Redis节点之间主从身份的切换以及VIP漂移,所述两个Redis节点中一个节点的身份为主节点并绑定VIP,另一个节点的身份为从节点不绑定VIP,主节点和从节点数据同步,所述方法包括:通过哨兵监测每个Redis节点的运行状态;每个Redis节点均部署有节点监控器,通过节点监控器监测对应Redis节点的身份;当哨兵监测到节点异常时,通过哨兵切换两个Redis节点的主从身份,每个节点监控器监测到对应的Redis节点的身份变化后,通过部署于原主节点中的节点监控器将原节点与VIP解绑,通过部署于切换后主节点中的节点监控器将切换后主节点与VIP绑定。
2.根据权利要求1所述的一种Redis高可用VIP漂移方法,其特征在于当哨兵监测到节点异常时,通过哨兵切换两个Redis节点的主从身份,并将切换后每个Redis节点的身份存储于哨兵。
3.根据权利要求2所述的一种Redis高可用VIP漂移方法,其特征在于每个Redis节点本地保存其身份,包括更新并保存切换后的身份。
4.根据权利要求3所述的一种Redis高可用VIP漂移方法,其特征在于所述节点监控器的工作包括:监测对应Redis节点的身份;如果所述Redis节点当前身份为主节点,判断所述Redis节点是否已绑定VIP,如果所述Redis 节点已绑定VIP,则监测对应Redis节点的身份,如果所述Redis节点未绑定VIP,则将所述Redis节点绑定VIP;如果所述Redis节点当前身份为从节点,判断所述Redis节点是否已解绑VIP,如果所述Redis 节点已解绑VIP,则继续监测对应Redis节点的身份,如果所述Redis节点未解绑VIP,则将所述Redis节点解绑VIP。
5.根据权利要求4所述的一种Redis高可用VIP漂移方法,其特征在于节点监控器监测对应Redis节点的身份,包括如下步骤:获取本地保存的身份;判断哨兵中是否存储有所述Redis节点的身份;如果哨兵中存储有所述Redis节点的身份,判断本地保存的身份与哨兵中存储的所述Redis节点的身份是否一致,如果一致,输出本地保存的身份,如果不一致,修改本地保存的身份以与哨兵中存储的所述Redis节点的身份一致,并输出本地保存的修改后的身份;如果哨兵中未存储所述Redis节点的身份,输出本地保存的身份。
6.根据权利要求1、2、3、4或5所述的一种Redis高可用VIP漂移方法,其特征在于所述节点监控器为监控脚本。
7.一种终端,其特征在于包括处理器、输入设备、输出设备和存储器,处理器、输入设备、输出设备和存储器相互连接,存储器用于存储计算机程序,所述计算机程序包括程序指令,所述处理器被配置用于调用所述程序指令执行如权利要求1-6任一项所述一种Redis高可用VIP漂移方法。
8.一种计算机可读存储介质,其特征在于所述存储介质为计算机可读存储介质,所述计算机可读存储介质存储有计算机程序,所述计算机程序包括程序指令,程序指令当被处理器执行时所述处理器执行如权利要求1-6任一项所述的一种Redis高可用VIP漂移方法。
技术说明书一种Redis高可用VIP漂移方法、终端及存储介质技术领域本技术涉及云数据库领域,具体地说是一种Redis高可用VIP漂移方法、终端及存储介质。
背景技术作为一种内存型数据库,Redis具有性能高、结构简单、相关工具完备等特点,被越来越多地应用在各种互联网工程中,成为各大门户网站和移动互联网App的必备组件。
近年来随着云计算概念的兴起,大量Redis数据库从本地被迁移到了云计算平台,成为了云数据库。
然而由于云计算平台特殊的技术架构,云数据库Redis主从切换时的VIP(Virtual IPAddress,虚拟IP地址)漂移环节成为了新的技术难点。
云数据库Redis正常运行时的系统拓扑如图1所示:主节点将VIP绑定,从节点不绑定,业务负载通过VIP访问主节点,从节点与主节点保持数据同步,哨兵(监控器)监控主从节点的运行情况。
Redis主从切换时的VIP漂移方法如附图2所示:哨兵检测到主节点宕机时,会进行以下几步操作:1、切换主从节点互换身份;2、操作宕机节点解绑VIP;3、操作正常节点绑定VIP。
具体流程如图3所示。
上述传统的方法虽然可以实现VIP漂移的功能但是有以下缺陷:1、VIP切换的过程依赖哨兵登录主、从节点进行操作,需要授予哨兵登录Redis云节点的密钥,不利于密钥的管理和系统安全;2、哨兵作为VIP切换的主动方,也存在异常的可能,若哨兵切换主从身份后宕机,会导致身份切换但VIP没有漂移,可能导致云数据库Redis服务状态混乱;3、哨兵作为VIP切换的主动方,仅进行一次VIP切换操作,若VIP切换不成功,没有重试机制,可能导致云数据库Redis服务状态混乱。
针对上述分析,如何在确保Redis节点密钥的安全性、且主从节点身份切换时不会导致服务状态混乱的前提下,实现VIP漂移,是需要解决的技术问题。
技术内容本技术的技术任务是针对以上不足,提供一种Redis高可用VIP漂移方法、终端及存储介质,来解决如何在确保Redis节点密钥的安全性、且主从节点身份切换时不会导致服务状态混乱的前提下,实现VIP漂移的问题。
第一方面,本技术提供一种Redis高可用VIP漂移方法,用于实现两个Redis节点之间主从身份的切换以及VIP漂移,所述两个Redis节点中一个节点的身份为主节点并绑定VIP,另一个节点的身份为从节点不绑定VIP,主节点和从节点数据同步,所述方法包括:通过哨兵监测每个Redis节点的运行状态;每个Redis节点均部署有节点监控器,通过节点监控器监测对应Redis节点的身份;当哨兵监测到节点异常时,通过哨兵切换两个Redis节点的主从身份,每个节点监控器监测到对应的Redis节点的身份变化后,通过部署于原主节点中的节点监控器将原节点与VIP解绑,通过部署于切换后主节点中的节点监控器将切换后主节点与VIP绑定。
使用上述实施方式时,云数据库Redis正常运行时,两个Redis节点分别为第一节点和第二节点,第一节点的的身份为主节点将VIP绑定,第二节点的身份为从节点不绑定VIP,业务负载通过VIP访问主节点,从节点和主节点保持数据同步,哨兵监控主节点和从节点的运行状态,每个Redis节点自带的节点监控器监测对应Redis节点的身份,当哨兵监测到主节点宕机时,切换第一节点和第二节点的主从身份,第一节点的监控器将其与VIP解绑,第二节点的监控器将其与VIP绑定,从而实现主从身份的切换以及VIP漂移。
作为优选,通过哨兵切换两个Redis节点的主从身份,并将切换后每个Redis节点的身份存储于哨兵。
作为优选,当哨兵监测到节点异常时,通过哨兵切换两个Redis节点的主从身份,并将切换后每个Redis节点的身份存储于哨兵。
作为优选,每个Redis节点本地保存其身份,包括更新并保存切换后的身份作为优选,所述节点监控器的工作包括:监测对应Redis节点的身份;如果所述Redis节点当前身份为主节点,判断所述Redis节点是否已绑定VIP,如果所述Redis 节点已绑定VIP,则监测对应Redis节点的身份,如果所述Redis节点未绑定VIP,则将所述Redis节点绑定VIP;如果所述Redis节点当前身份为从节点,判断所述Redis节点是否已解绑VIP,如果所述Redis 节点已解绑VIP,则继续监测对应Redis节点的身份,如果所述Redis节点未解绑VIP,则将所述Redis节点解绑VIP。
作为优选,节点监控器监测对应Redis节点的身份,包括如下步骤:获取本地保存的身份;判断哨兵中是否存储有所述Redis节点的身份;如果哨兵中存储有所述Redis节点的身份,判断本地保存的身份与哨兵中存储的所述Redis节点的身份是否一致,如果一致,输出本地保存的身份,如果不一致,修改本地保存的身份以与哨兵中存储的所述Redis节点的身份一致,并输出本地保存的修改后的身份;如果哨兵中未存储所述Redis节点的身份,输出本地保存的身份。
作为优选,所述节点监控器为监控脚本。
第二方方面,本技术提供一种终端,包括处理器、输入设备、输出设备和存储器,处理器、输入设备、输出设备和存储器相互连接,存储器用于存储计算机程序,所述计算机程序包括程序指令,所述处理器被配置用于调用所述程序指令执行如第一方面任一项所述一种Redis 高可用VIP漂移方法。
第三方面,本技术提供一种存储介质,所述存储介质为计算机可读存储介质,所述计算机可读存储介质存储有计算机程序,所述计算机程序包括程序指令,程序指令当被处理器执行时所述处理器执行如第一方面任一项所述的一种Redis高可用VIP漂移方法。
本技术的一种Redis高可用VIP漂移方法、终端及存储介质具有以下优点:1、VIP切换过程中哨兵不需要登录主节点和从节点,可以保护Redis节点密钥,维护系统的高安全性;2、通过哨兵进行主从身份切换后,Redis节点作为VIP切换的主动方,不会导致数据库Redis 服务状态混乱;3、Redis节点作为VIP切换的主动方具有漂移重试机制,漂移不成功后会在动重试,不会导致数据库Redis服务状态混乱。
附图说明为了更清楚地说明本技术实施例中的技术方案,下面将对实施例中描述中所需要使用的附图作简要介绍,显而易见地,下面描述中的附图仅仅是本技术的一些实施例,对于本领域的普通技术人员来讲,在不付出创造性劳动的前提下,还可以根据这些附图获得其他的附图。
下面结合附图对本技术进一步说明。
附图1为云数据库Redis正常运行系统拓扑结构示意图;附图2为传统VIP漂移方法拓扑示意图;附图3为传统VIP漂移流程框图;附图4为实施例1一种Redis高可用VIP漂移方法中正常运行系统拓扑结构示意图;附图5为1一种Redis高可用VIP漂移方法中VIP漂移拓扑示意图;附图6为1一种Redis高可用VIP漂移方法中哨兵工作流程框图;附图7为1一种Redis高可用VIP漂移方法中节点监控器的工作流程框图;附图8为1一种Redis高可用VIP漂移方法中检测身份流程框图。