一种zedis分布式缓存方法与流程

文档序号:12751746阅读:521来源:国知局
一种zedis分布式缓存方法与流程

本发明涉及数据缓存技术领域,尤其涉及一种分布式缓存方法。



背景技术:

目前的数据缓存方案有redis集群方案及twitter方案。

redis集群方案,由于推出时间比较新,在我们的方案提出时还未成熟和大规模使用,它提供了一种预分配桶的哈希算法,灵活性上不如一致性哈希算法,故障转移需要手动去分配。

twitter方案,它直接在redis协议层做了代理,它能灵活配置并支持例如一致性哈希这样的自动算法,但是它是静态的分布式集群,没有支持redis节点自动故障转移的功能,而且这个代理本身的故障转移也需要开发自己去做。

将redis集群及twitter结合起业,它除了提供缓存服务之外,还提供了一套管理工具去做数据迁移、负载均衡等事情。

目前还提供了一整套完善的平台化工具,支持大规模的集群化部署,但是它的部署比较重,需要部署数据库、WEB系统,对于我们集群规模比较小的应用场景来说,应该起来不够灵活。

以上方案或多或少都提供了分布式缓存的特性,但是他们都不是非常适合我们的应用场景,我们希望分布式缓存满足以下要求:

a)节点的哈希是动态和稳定的,因此我们倾向于一致性哈希或者类似的哈希算法;

b)同时,我们希望故障转移能自动化完成,包括数据迁移等,不需要运维手动介入;方案1、2、3都或多或少不能完全满足自动故障转移的要求。

c)另外,我们希望这套集群方案跟我们现有的支撑运营平台能比较好地兼容。方案4就比较重,集成我们内部的平台难度比较大。

因此,我亟需开发出一种通过最少的配置、实现了集群的高可用、自动化治理,并能实现数据迁移、负载均衡,动态和稳定的zedis分布式缓存方法。



技术实现要素:

本发明要解决的技术问题是提供一种zedis分布式缓存方法,该zedis分布式缓存方法通过最少的配置、实现了集群的高可用、自动化治理,并能实现数据迁移、负载均衡,动态和稳定。

为解决上述技术问题,本发明提供了一种zedis分布式缓存方法,提供zookeeper核心处理器、服务器集群监控模块、节点数据处理模块、数据恢复模块、客户端、服务端及数据存储服务器,所述zookeeper核心处理器包括服务器判断模块及服务器显示模块,所述zedis分布式缓存方法包括以下步骤:

S1:所述服务器判断模块读取所述服务器集群监控模块的redis服务器集群所需的完整信息;

S2:所述服务器判断模块将读取到的信息发送给所述客户端,所述客户端将读取redis服务器集群所需的完整信息,从每一个物理节点的完整信息抽取相对于其他物理节点唯一的信息,其中,所述信息包括ip地址与端口号;

S3:所述客户端通过接收到的信息生成固定的多个key,通过负载均衡核心类ConsistentHash算法生成对应多个hash码,同一个信息生成的哈希码全都映射到同一个物理节点,用哈希码到物理节点的映射填充ConsistentHash的核心变量映射表形成哈希环;

S4:所述哈希环与所述数据存储服务器连接完成数据备份与故障规避的读写过程;

S5:所述故障转移处理模块、服务器集群监控模块及zookeeper核心处理器通过数据备份、规避故障节点和数据恢复实现故障转移;

所述步骤“数据备份与故障规避的读过程”的实现步骤包括:

S401:所述读写代理模块根据key参数,通过哈希环找出主节点,并以此找到备节点;

S402:判断主节点是否可用,如果主节点可用,则执行步骤S403,如果主节点不可用但备节点可用,执行步骤S404,如果主节点及备节点均不可用;

S403:往主节点主数据库写并往备节点的主数据库写入;

S404:往备节点的备用数据库和临时数据库写入;

S405:写入其他可用节点的数据库;

所述步骤“数据备份与故障规避的写过程”的实现步骤包括:

S406:所述读写代理模块根据key参数获取主节点及备份节点;

S407:判断主节点是否可用,如果主节点可用,执行步骤S408,如果主节点不可用但备节点可用,执行步骤S409,如果主节点及备节点均不可用,执行步骤S410;

S408:从主节点读取;

S409:从备节点读取;

S410:从其他节点读取;

其中,所述数据存储服务器的数据存储方式如下表所示:

其中,所述主节点为通过负载均衡核心类ConsistentHash算法找到的最近的物理节点,备节点是主节点的下一个节点。

优选地,所述客户端包括负载均衡处理模块,所述步骤S3中的“负载均衡核心类ConsistentHash算法”包括:

所述负载均衡处理模块通过MurMurHash2算法接收参数key,生成并返回哈希码;

所述负载均衡处理模块通过void_addNode算法接收节点S和一个原始参数key,用参数key生成多个哈希码,并将所有的哈希码全部映射到所述节点S,将映射存入TreeMap;

所述负载均衡处理模块通过S_getClosestNode算法接收参数key,根据key生成hashCode,用TreeMap的tailMap算法,找到最近的节点并返回。

优选地,所述服务器集群监控模块包括连接redis服务器所需的信息、表明节点可用性状态的表量及检测redis服务器是否可用的策略。

优选地,所述检测redis服务器是否可用的策略包括:初始化所述服务器集群监控模块并根据信息与redis服务器建立连接;

通过客户端的ping方法检测节点是否存活,再通过客户端的set方法,检查是否能正常存入数据,如果检查均通过则返回服务器可用,否则返回服务器不可用;

连续N次调用pingOnce(),记录调用成功或失败比率并返回;

所述服务器集群监控模块先调用一次pingOnce(),若返回结果与所述服务器集群监控模块一致,则redis服务器可用性状态无变化,并返回检测结果,若首次检测结果与所述服务器集群监控模块不一致,则调用checkStateRatio进行判断,以checkStateRatio返回结果为准,返回检测结果。

优选地,所述哈希环包括Redis节点,Redis节点标号到Redis节点本身的映射表、集群的最大标号和最小标号。

优选地,还包括步骤:所述服务器集群监控模块对集群服务器进行监控,并将监控得出的结果发送给zookeeper核心处理器,该步骤的实现步骤包括:

读取zedis集群配置,建立物理节点对应的检测任务,把检测出的可用性变化情况通过发送给客户端;

初始化集群,构造服务器集群监控模块传入客户端的集群信息,所述服务器集群监控模块根据固定的配置规范读取所述集群信息并初始化;

所述服务器集群监控模块对每个读取到的不同的物理节点构造一个线程内部类RedisPing任务,调用所述“检测redis服务器是否可用”的策略的ping方法,检测物理节点的可用性;

根据监控结果,判断物理节点是否出现可用性变化,若物理节点出现可用性变化,从可用变为不可用,修改所述zookeeper核心处理器配置并通知客户端;若物理节点出现不可用性变化,从不可用变为可用,先数据恢复,然后再修改zookeeper核心处理器配置并通知所述客户端。

优选地,所述步骤S5的实现步骤包括:

所述故障转移处理模块根据key参数生成哈希码并找到主节点,然后找到主节点的备节点,对主备节点进行相同的写操作,主节点=n,则备节点=n+1,写操作在主节点主数据库空间和备节点的备数据库空间一起进行。

优选地,所述步骤S5的“规避故障节点步骤”的实现步骤包括:

所述故障转移处理模块根据java代理拦截接口调用的数据,并通过key参数找到主节点,判断主节点是否可用,如果可用则在主节点上与数据存储服务器进行数据交换的工作;如果主节点不可用,则在备节点与数据存储服务器进行数据交换的工作;如果主节点和备节点均不可用,则在剩余的物理节点中,寻找可用的节点与数据存储服务器进行数据交换的工作。

优选地,所述步骤S5的“数据恢复”的实现步骤包括:

判断故障节点规避是否已经完成,如果已经完成,则进行数据恢复,否则续费进行故障节点规避;

找出恢复正常的节点相对的主节点和备节点,假设主数据库=n,恢复节点=n+2,恢复节点为目标节点,主节点=n+1,备节点=n+3;从备节点临时数据库空间恢复数据到目标节点主数据库空间,然后清空备节点临时数据库空间,从主节点主数据库空间恢复数据到目标节点备用数据库空间。

采用了上述方法之后,所述服务器判断模块读取所述服务器集群监控模块的redis服务器集群所需的完整信息;所述服务器判断模块将读取到的信息发送给所述客户端,所述客户端将读取redis服务器集群所需的完整信息,从每一个物理节点的完整信息抽取相对于其他物理节点唯一的信息,其中,所述信息包括ip地址与端口号;所述客户端通过接收到的信息生成固定的多个key,通过负载均衡核心类ConsistentHash算法生成对应多个hash码,同一个信息生成的哈希码全都映射到同一个物理节点,用哈希码到物理节点的映射填充ConsistentHash的核心变量映射表形成哈希环;所述哈希环与所述数据存储服务器连接完成数据备份与故障规避的读写过程;所述故障转移处理模块、服务器集群监控模块及zookeeper核心处理器通过数据备份、规避故障节点和数据恢复实现故障转移;该zedis分布式缓存方法通过最少的配置、实现了集群的高可用、自动化治理,并能实现数据迁移、负载均衡,动态和稳定,基于监控的自动故障转移机制,利用zookeeper核心处理器的分布式协调机制,对集群进行监控,从而实现自动实时故障转移和数据恢复,,服务器集群监控模块的监控使用基于概率的故障检测算法,既能抗抖动,又保障了实时性,对一致性哈希算法进行扩展优化,实现数据自动备份,还有故障节点的自动恢复。

附图说明

图1是本发明的一种zedis分布式缓存方法的整体模型示意图;

图2是一种zedis分布式缓存方法的实现流程图;

图3是一种zedis分布式缓存方法中的故障场景日记的示意图;

图4是一种zedis分布式缓存方法中的服务器集群监控场景日记的示意图;

图5是一种zedis分布式缓存方法中的客户端运用场景日记的示意图。

具体实施方式

为了使本发明的目的、技术方案及优点更加清楚明白,以下结合附图及实施例,对本发明进行进一步详细说明。应当理解,此处所描述的具体实施例仅用于解释本发明,并不用于限定本发明。

实施例1

请参阅图1至图2,图1是本发明的一种zedis分布式缓存方法的整体模型示意图;图2是与图1的一种zedis分布式缓存方法的实现流程图。

本发明公开了一种zedis分布式缓存方法,提供zookeeper核心处理器、服务器集群监控模块、节点数据处理模块、数据恢复模块、客户端、服务端及数据存储服务器,所述zookeeper核心处理器包括服务器判断模块及服务器显示模块,所述zedis分布式缓存方法包括以下步骤:

S1:所述服务器判断模块读取所述服务器集群监控模块的redis服务器集群所需的完整信息;

S2:所述服务器判断模块将读取到的信息发送给所述客户端,所述客户端将读取redis服务器集群所需的完整信息,从每一个物理节点的完整信息抽取相对于其他物理节点唯一的信息,其中,所述信息包括ip地址与端口号;

S3:所述客户端通过接收到的信息生成固定的多个key,通过负载均衡核心类ConsistentHash算法生成对应多个hash码,同一个信息生成的哈希码全都映射到同一个物理节点,用哈希码到物理节点的映射填充ConsistentHash的核心变量映射表形成哈希环;

S4:所述哈希环与所述数据存储服务器连接完成数据备份与故障规避的读写过程;

S5:所述故障转移处理模块、服务器集群监控模块及zookeeper核心处理器通过数据备份、规避故障节点和数据恢复实现故障转移;

所述步骤“数据备份与故障规避的读过程”的实现步骤包括:

S401:所述读写代理模块根据key参数,通过哈希环找出主节点,并以此找到备节点;

S402:判断主节点是否可用,如果主节点可用,则执行步骤S403,如果主节点不可用但备节点可用,执行步骤S404,如果主节点及备节点均不可用;

S403:往主节点主数据库写并往备节点的主数据库写入;

S404:往备节点的备用数据库和临时数据库写入;

S405:写入其他可用节点的数据库;

所述步骤“数据备份与故障规避的写过程”的实现步骤包括:

S406:所述读写代理模块根据key参数获取主节点及备份节点;

S407:判断主节点是否可用,如果主节点可用,执行步骤S408,如果主节点不可用但备节点可用,执行步骤S409,如果主节点及备节点均不可用,执行步骤S410;

S408:从主节点读取;

S409:从备节点读取;

S410:从其他节点读取;

其中,所述数据存储服务器的数据存储方式如下表所示:

其中,所述主节点为通过负载均衡核心类ConsistentHash算法找到的最近的物理节点,备节点是主节点的下一个节点。

所述客户端包括负载均衡处理模块,所述步骤S3中的“负载均衡核心类ConsistentHash算法”包括:

所述负载均衡处理模块通过MurMurHash2算法接收参数key,生成并返回哈希码;

所述负载均衡处理模块通过void_addNode算法接收节点S和一个原始参数key,用参数key生成多个哈希码,并将所有的哈希码全部映射到所述节点S,将映射存入TreeMap;

所述负载均衡处理模块通过S_getClosestNode算法接收参数key,根据参数key生成hashCode,用TreeMap的tailMap算法,找到最近的节点并返回。

所述服务器集群监控模块包括连接redsi服务器所需的信息、表明节点可用性状态的表量及检测redis服务器是否可用的策略。

所述检测redis服务器是否可用的策略包括:初始化所述服务器集群监控模块并根据信息与redis服务器建立连接;

通过客户端的ping方法检测节点是否存活,再通过客户端的set方法,检查是否能正常存入数据,如果检查均通过则返回服务器可用,否则返回服务器不可用;

连续N次调用pingOnce(),记录调用成功或失败比率并返回;

所述服务器集群监控模块先调用一次pingOnce(),若返回结果与所述服务器集群监控模块一致,则redis服务器可用性状态无变化,并返回检测结果,若首次检测结果与所述服务器集群监控模块不一致,则调用checkStateRatio进行判断,以checkStateRatio返回结果为准,返回检测结果。

在本实施例中,所述哈希环包括Redis节点、Redis节点标号到Redis节点本身的映射表、集群的最大标号和最小标号。

在本实施例中,所述的zedis分布式缓存方法还包括步骤:所述服务器集群监控模块对集群服务器进行监控,并将监控得出的结果发送给zookeeper核心处理器,该步骤的实现步骤包括:

读取zedis集群配置,建立物理节点对应的检测任务,把检测出的可用性变化情况发送给客户端;

初始化集群,构造服务器集群监控模块传入客户端的集群信息,所述服务器集群监控模块根据固定的配置规范读取所述集群信息并初始化;

所述服务器集群监控模块对每个读取到的不同的物理节点构造一个线程内部类RedisPing任务,调用所述“检测redis服务器是否可用”的策略的ping方法,检测物理节点的可用性;

根据监控结果,判断物理节点是否出现可用性变化,若物理节点出现可用性变化,从可用变为不可用,修改所述zookeeper核心处理器配置并通知客户端;若物理节点出现不可用性变化,从不可用变为可用,先数据恢复,然后再修改zookeeper核心处理器配置并通知所述客户端。

所述步骤S5的实现步骤包括:

所述故障转移处理模块根据key参数生成哈希码并找到主节点,然后找到主节点的备节点,对主备节点进行相同的写操作,主节点=n,则备节点=n+1,写操作在主节点主数据库空间和备节点的备数据库空间一起进行。

所述步骤S5的“规避故障节点步骤”的实现步骤包括:

所述故障转移处理模块根据java代理拦截接口调用的数据,并通过key参数找到主节点,判断主节点是否可用,如果可用则在主节点上与数据存储服务器进行数据交换的工作;如果主节点不可用,则在备节点与数据存储服务器进行数据交换的工作;如果主节点和备节点均不可用,则在剩余的物理节点中,寻找可用的节点与数据存储服务器进行数据交换的工作。

所述步骤S5的“数据恢复”的实现步骤包括:

判断故障节点规避是否已经完成,如果已经完成,则进行数据恢复,否则继续进行故障节点规避;

找出恢复正常的节点相对的主节点和备节点,假设主数据库=n,恢复节点=n+2,恢复节点为目标节点,主节点=n+1,备节点=n+3;从备节点临时数据库空间恢复数据到目标节点主数据库空间,然后清空备节点临时数据库空间,从主节点主数据库空间恢复数据到目标节点备用数据库空间。

本实施例,模拟实验过程及部分实验结果如下文所示。

(1)故障场景

故障测试模拟了一个故障场景,用程序在本地上启动几个redis服务器,并且按照一定配置不间断地终结服务器进程和重启服务器,本场景中同一时间只有一个服务器会被终结,服务器故障场景如下图3程序的打印记录。

(2)服务器集群监控,布置好故障场景后,启动服务器集群监控模块,检测redis服务器可用性,改写zookeeper核心处理器通知客户端,并且负责数据恢复,启动服务器集群监控模块应对服务器上下线的操作如图4的日志记录。

(3)客户端运用场景

如图5的日记所示,在故障场景下,和服务器集群监控模块的协助下,开启程序模拟客户端使用zedis,按照一定比例不断地读写redis集群数据,记录并实时打印出成功读写的百分比,在本故障场景下,写成功率会是100%,这是客户端读写模拟场景简单单一的效果。

采用了上述方法之后,所述服务器判断模块读取所述服务器集群监控模块的redis服务器集群所需的完整信息;所述服务器判断模块将读取到的信息发送给所述客户端,所述客户端将读取redis服务器集群所需的完整信息,从每一个物理节点的完整信息抽取相对于其他物理节点唯一的信息,其中,所述信息包括ip地址与端口号;所述客户端通过接收到的信息生成固定的多个key,通过负载均衡核心类ConsistentHash算法生成对应多个hash码,同一个信息生成的哈希码全都映射到同一个物理节点,用哈希码到物理节点的映射填充ConsistentHash的核心变量映射表形成哈希环;所述哈希环与所述数据存储服务器连接完成数据备份与故障规避的读写过程;所述故障转移处理模块、服务器集群监控模块及zookeeper核心处理器通过数据备份、规避故障节点和数据恢复实现故障转移;该zedis分布式缓存方法通过最少的配置、实现了集群的高可用、自动化治理,并能实现数据迁移、负载均衡,动态和稳定,基于监控的自动故障转移机制,利用zookeeper核心处理器的分布式协调机制,对集群进行监控,从而实现自动实时故障转移和数据恢复,,服务器集群监控模块的监控使用基于概率的故障检测算法,既能抗抖动,又保障了实时性,对一致性哈希算法进行扩展优化,实现数据自动备份,还有故障节点的自动恢复。

同时,应当理解的是,以上仅为本发明的优选实施例,不能因此限制本发明的专利范围,凡是利用本发明说明书及附图内容所作的等效结构或等效实现方法,或直接或间接运用在其他相关的技术领域,均同理包括在本发明的专利保护范围内。

当前第1页1 2 3 
网友询问留言 已有0条留言
  • 还没有人留言评论。精彩留言会获得点赞!
1