CN106210151A - 一种zedis分布式缓存及服务器集群监控方法 - Google Patents
一种zedis分布式缓存及服务器集群监控方法 Download PDFInfo
- Publication number
- CN106210151A CN106210151A CN201610852752.XA CN201610852752A CN106210151A CN 106210151 A CN106210151 A CN 106210151A CN 201610852752 A CN201610852752 A CN 201610852752A CN 106210151 A CN106210151 A CN 106210151A
- Authority
- CN
- China
- Prior art keywords
- node
- server
- server cluster
- data
- module
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/10—Protocols in which an application is distributed across nodes in the network
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
- G06F16/24—Querying
- G06F16/245—Query processing
- G06F16/2455—Query execution
- G06F16/24552—Database cache management
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/10—Protocols in which an application is distributed across nodes in the network
- H04L67/1001—Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
- H04L67/1004—Server selection for load balancing
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/50—Network services
- H04L67/56—Provisioning of proxy services
- H04L67/568—Storing data temporarily at an intermediate stage, e.g. caching
Abstract
本发明提供了一种zedis分布式缓存及服务器集群监控方法，包括以下步骤：所述服务器判断模块读取所述服务器集群监控模块的redis服务器集群所需的完整信息；所述服务器判断模块将读取到的信息发送给所述客户端，所述客户端将读取redis服务器集群所需的完整信息，从每一个物理节点的完整信息抽取相对于其他物理节点唯一的信息，其中，所述信息包括ip地址与端口号；所述客户端通过接收到的信息生成固定的多个key,通过负载均衡核心类ConsistentHash算法生成对应多个hash码，用哈希码到物理节点的映射填充ConsistentHash的核心变量映射表形成哈希环；该zedis分布式缓存及服务器集群监控方法通过最少的配置、实现了集群的高可用、自动化治理，并能实现数据迁移、负载均衡，动态和稳定。
Description
技术领域
本发明涉及数据缓存技术领域，尤其涉及一种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核心处理器通过数据备份、规避故障节点和数据恢复实现故障转移；
S6:所述服务器集群监控模块对集群服务器进行监控，并将监控得出的结果发送给zookeeper核心处理器，所述步骤S6的实现步骤包括：
S601:读取zedis集群配置，建立物理节点对应的检测任务，把检测出的可用性变化情况发送给客户端；
S602:初始化集群，构造服务器集群监控模块传入客户端的集群信息，所述服务器集群监控模块根据固定的配置规范读取所述集群信息并初始化；
S603:所述服务器集群监控模块对每个读取到的不同的物理节点构造一个线程内部类RedisPing任务，调用所述“检测redis服务器是否可用”的策略的ping方法，检测物理节点的可用性；
S604:根据监控结果，判断物理节点是否出现可用性变化，若物理节点出现可用性变化，从可用变为不可用，修改所述zookeeper核心处理器配置并通知客户端；若物理节点出现不可用性变化，从不可用变为可用，先数据恢复，然后再修改zookeeper核心处理器配置并通知所述客户端；
其中，所述数据存储服务器的数据存储方式如下表所示：
其中，所述主节点为通过负载均衡核心类ConsistentHash算法找到的最近的物理节点，备节点是主节点的下一个节点。
优选地，所述步骤“数据备份与故障规避的读过程”的实现步骤包括：
S401:所述读写代理模块根据key参数，通过哈希环找出主节点，并以此找到备节点；
S402:判断主节点是否可用，如果主节点可用，则执行步骤S403，如果主节点不可用但备节点可用，执行步骤S404，如果主节点及备节点均不可用；
S403:往主节点主数据库写并往备节点的主数据库写入；
S404:往备节点的备用数据库和临时数据库写入；
S405:写入其他可用节点的数据库；
所述步骤“数据备份与故障规避的写过程”的实现步骤包括：
S406:所述读写代理模块根据key参数获取主节点及备份节点；
S407:判断主节点是否可用,如果主节点可用，执行步骤S408，如果主节点不可用但备节点可用，执行步骤S409,如果主节点及备节点均不可用，执行步骤S410；
S408：从主节点读取；
S409:从备节点读取；
S410:从其他节点读取。
优选地，所述客户端包括负载均衡处理模块，所述步骤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核心处理器通过数据备份、规避故障节点和数据恢复实现故障转移；
S6:所述服务器集群监控模块对集群服务器进行监控，并将监控得出的结果发送给zookeeper核心处理器，所述步骤S6的实现步骤包括：
S601:读取zedis集群配置，建立物理节点对应的检测任务，把检测出的可用性变化情况发送给客户端；
S602:初始化集群，构造服务器集群监控模块传入客户端的集群信息，所述服务器集群监控模块根据固定的配置规范读取所述集群信息并初始化；
S603:所述服务器集群监控模块对每个读取到的不同的物理节点构造一个线程内部类RedisPing任务，调用所述“检测redis服务器是否可用”的策略的ping方法，检测物理节点的可用性；
S604:根据监控结果，判断物理节点是否出现可用性变化，若物理节点出现可用性变化，从可用变为不可用，修改所述zookeeper核心处理器配置并通知客户端；若物理节点出现不可用性变化，从不可用变为可用，先数据恢复，然后再修改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节点本身的映射表、集群的最大标号和最小标号。
所述步骤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核心处理器的分布式协调机制，对集群进行监控，从而实现自动实时故障转移和数据恢复，服务器集群监控模块的监控使用基于概率的故障检测算法，既能抗抖动，又保障了实时性，对一致性哈希算法进行扩展优化，实现数据自动备份，还有故障节点的自动恢复。
同时，应当理解的是，以上仅为本发明的优选实施例，不能因此限制本发明的专利范围，凡是利用本发明说明书及附图内容所作的等效结构或等效实现方法，或直接或间接运用在其他相关的技术领域，均同理包括在本发明的专利保护范围内。
Claims (9)
1.一种zedis分布式缓存及服务器集群监控方法，其特征在于：提供zookeeper核心处理器、服务器集群监控模块、节点数据处理模块、数据恢复模块、客户端、服务端及数据存储服务器，所述zookeeper核心处理器包括服务器判断模块及服务器显示模块，所述zedis分布式缓存及服务器集群监控方法包括以下步骤：
S1:所述服务器判断模块读取所述服务器集群监控模块的redis服务器集群所需的完整信息；
S2:所述服务器判断模块将读取到的信息发送给所述客户端，所述客户端将读取redis服务器集群所需的完整信息，从每一个物理节点的完整信息抽取相对于其他物理节点唯一的信息，其中，所述信息包括ip地址与端口号；
S3:所述客户端通过接收到的信息生成固定的多个key,通过负载均衡核心类ConsistentHash算法生成对应多个hash码，同一个信息生成的哈希码全都映射到同一个物理节点，用哈希码到物理节点的映射填充ConsistentHash的核心变量映射表形成哈希环；
S4:所述哈希环与所述数据存储服务器连接完成数据备份与故障规避的读写过程；
S5:所述故障转移处理模块、服务器集群监控模块及zookeeper核心处理器通过数据备份、规避故障节点和数据恢复实现故障转移；
S6:所述服务器集群监控模块对集群服务器进行监控，并将监控得出的结果发送给zookeeper核心处理器；
所述步骤S6的实现步骤包括：
S601：读取zedis集群配置，建立物理节点对应的检测任务，把检测出的可用性变化情况通过发送给客户端；
S602：初始化集群，构造服务器集群监控模块传入客户端的集群信息，所述服务器集群监控模块根据固定的配置规范读取所述集群信息并初始化；
S603：所述服务器集群监控模块对每个读取到的不同的物理节点构造一个线程内部类RedisPing任务，调用所述“检测redis服务器是否可用”的策略的ping方法，检测物理节点的可用性；
S604：根据监控结果，判断物理节点是否出现可用性变化，若物理节点出现可用性变化，从可用变为不可用，修改所述zookeeper核心处理器配置并通知客户端；若物理节点出现不可用性变化，从不可用变为可用，先数据恢复，然后再修改zookeeper核心处理器配置并通知所述客户端；
其中，所述数据存储服务器的数据存储方式如下表所示：
其中，所述主节点为通过负载均衡核心类ConsistentHash算法找到的最近的物理节点，备节点是主节点的下一个节点。
2.根据权利要求1所述的zedis分布式缓存及服务器集群监控方法，其特征在于：所述步骤“数据备份与故障规避的读过程”的实现步骤包括：
S401:所述读写代理模块根据key参数，通过哈希环找出主节点，并以此找到备节点；
S402:判断主节点是否可用，如果主节点可用，则执行步骤S403，如果主节点不可用但备节点可用，执行步骤S404，如果主节点及备节点均不可用；
S403:往主节点主数据库写并往备节点的主数据库写入；
S404:往备节点的备用数据库和临时数据库写入；
S405:写入其他可用节点的数据库；
所述步骤“数据备份与故障规避的写过程”的实现步骤包括：
S406:所述读写代理模块根据key参数获取主节点及备份节点；
S407:判断主节点是否可用,如果主节点可用，执行步骤S408，如果主节点不可用但备节点可用，执行步骤S409,如果主节点及备节点均不可用，执行步骤S410；
S408：从主节点读取；
S409:从备节点读取；
S410:从其他节点读取。
3.根据权利要求1所述的zedis分布式缓存及服务器集群监控方法，其特征在于：所述客户端包括负载均衡处理模块，所述步骤S3中的“负载均衡核心类ConsistentHash算法”包括：
所述负载均衡处理模块通过MurMurHash2算法接收参数key，生成并返回哈希码；
所述负载均衡处理模块通过void_addNode算法接收节点S和一个原始参数key,用参数key生成多个哈希码,并将所有的哈希码全部映射到所述节点S，将映射存入TreeMap；
所述负载均衡处理模块通过S_getClosestNode算法接收参数key,根据key生成hashCode，用TreeMap的tailMap算法，找到最近的节点并返回。
4.根据权利要求1所述的zedis分布式缓存及服务器集群监控方法，其特征在于：所述服务器集群监控模块包括连接redis服务器所需的信息、表明节点可用性状态的表量及检测redis服务器是否可用的策略。
5.根据权利要求4所述的zedis分布式缓存及服务器集群监控方法，其特征在于：所述“检测redis服务器是否可用”的策略包括：初始化所述服务器集群监控模块并根据信息与redis服务器建立连接；
通过客户端的ping方法检测节点是否存活，再通过客户端的set方法，检查是否能正常存入数据，如果检查均通过则返回服务器可用,否则返回服务器不可用；
连续N次调用pingOnce()，记录调用成功或失败比率并返回；
所述服务器集群监控模块先调用一次pingOnce(),若返回结果与所述服务器集群监控模块一致，则redis服务器可用性状态无变化，并返回检测结果，若首次检测结果与所述服务器集群监控模块不一致,则调用checkStateRatio进行判断，以checkStateRatio返回结果为准，返回检测结果。
6.根据权利要求4所述的zedis分布式缓存及服务器集群监控方法，其特征在于：所述哈希环包括Redis节点，Redis节点标号到Redis节点本身的映射表、集群的最大标号和最小标号。
7.根据权利要求1所述的zedis分布式缓存及服务器集群监控方法，其特征在于：所述步骤S5的实现步骤包括：
所述故障转移处理模块根据key参数生成哈希码并找到主节点，然后找到主节点的备节点，对主备节点进行相同的写操作，主节点＝n,则备节点＝n+1,写操作在主节点主数据库空间和备节点的备数据库空间一起进行。
8.根据权利要求1所述的zedis分布式缓存及服务器集群监控方法，其特征在于：所述步骤S5的“规避故障节点步骤”的实现步骤包括：
所述故障转移处理模块根据java代理拦截接口调用的数据，并通过key参数找到主节点,判断主节点是否可用，如果可用则在主节点上与数据存储服务器进行数据交换的工作；如果主节点不可用，则在备节点与数据存储服务器进行数据交换的工作；如果主节点和备节点均不可用，则在剩余的物理节点中,寻找可用的节点与数据存储服务器进行数据交换的工作。
9.根据权利要求1所述的zedis分布式缓存及服务器集群监控方法，其特征在于：所述步骤S5的“数据恢复”的实现步骤包括：
判断故障节点规避是否已经完成，如果已经完成，则进行数据恢复，否则续费进行故障节点规避；
找出恢复正常的节点相对的主节点和备节点，假设主数据库＝n,恢复节点＝n+2，恢复节点为目标节点，主节点＝n+1,备节点＝n+3；从备节点临时数据库空间恢复数据到目标节点主数据库空间，然后清空备节点临时数据库空间,从主节点主数据库空间恢复数据到目标节点备用数据库空间。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201610852752.XA CN106210151A (zh) | 2016-09-27 | 2016-09-27 | 一种zedis分布式缓存及服务器集群监控方法 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201610852752.XA CN106210151A (zh) | 2016-09-27 | 2016-09-27 | 一种zedis分布式缓存及服务器集群监控方法 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN106210151A true CN106210151A (zh) | 2016-12-07 |
Family
ID=57521173
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201610852752.XA Pending CN106210151A (zh) | 2016-09-27 | 2016-09-27 | 一种zedis分布式缓存及服务器集群监控方法 |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN106210151A (zh) |
Cited By (21)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN106951431A (zh) * | 2016-12-16 | 2017-07-14 | 华南理工大学 | 一种集群监控数据采集方法 |
| CN106951456A (zh) * | 2017-02-24 | 2017-07-14 | 广东广信通信服务有限公司 | 一种内存数据库系统及数据处理系统 |
| CN106959996A (zh) * | 2017-01-20 | 2017-07-18 | 华数传媒网络有限公司 | 一种基于互联网电视的后台数据同步方法 |
| CN108519954A (zh) * | 2018-03-23 | 2018-09-11 | 北京焦点新干线信息技术有限公司 | 一种集中管理缓存的方法及装置 |
| CN109151057A (zh) * | 2018-09-27 | 2019-01-04 | 郑州云海信息技术有限公司 | 一种智能分布式存储集群管理的方法 |
| CN109213792A (zh) * | 2018-07-06 | 2019-01-15 | 武汉斗鱼网络科技有限公司 | 数据处理的方法、服务端、客户端、装置及可读存储介质 |
| CN109241048A (zh) * | 2018-06-29 | 2019-01-18 | 深圳市彬讯科技有限公司 | 用于数据统计的数据处理方法、服务器及存储介质 |
| CN109508261A (zh) * | 2018-08-31 | 2019-03-22 | 云南电网有限责任公司信息中心 | 一种基于大数据的电网数据节点备份方法及备份系统 |
| CN109783564A (zh) * | 2019-01-28 | 2019-05-21 | 上海雷腾软件股份有限公司 | 支持多节点的分布式缓存方法及设备 |
| CN109800236A (zh) * | 2019-01-28 | 2019-05-24 | 上海雷腾软件股份有限公司 | 支持多节点的分布式缓存方法及设备 |
| CN109828971A (zh) * | 2019-01-28 | 2019-05-31 | 上海雷腾软件股份有限公司 | 支持多节点的分布式缓存方法及设备 |
| CN110224871A (zh) * | 2019-06-21 | 2019-09-10 | 深圳前海微众银行股份有限公司 | 一种Redis集群的高可用方法及装置 |
| CN111107120A (zh) * | 2018-10-29 | 2020-05-05 | 亿阳信通股份有限公司 | 一种Redis集群的构建方法及系统 |
| CN111338902A (zh) * | 2020-02-28 | 2020-06-26 | 上海商汤智能科技有限公司 | 数据处理方法、装置及系统 |
| CN111541753A (zh) * | 2020-04-16 | 2020-08-14 | 深圳市网心科技有限公司 | 区块链数据的分布式存储系统、方法、计算机设备及介质 |
| CN111628899A (zh) * | 2019-02-27 | 2020-09-04 | 北京京东尚科信息技术有限公司 | 服务器之间网络互联互通情况的绘制方法、装置及其系统 |
| CN112306720A (zh) * | 2020-11-23 | 2021-02-02 | 迈普通信技术股份有限公司 | 业务系统集群管理方法 |
| CN112559248A (zh) * | 2020-12-23 | 2021-03-26 | 深圳市彬讯科技有限公司 | 预处理服务恢复方法、装置、设备及存储介质 |
| CN113259188A (zh) * | 2021-07-15 | 2021-08-13 | 浩鲸云计算科技股份有限公司 | 一种构建大规模redis集群的方法 |
| CN113364839A (zh) * | 2021-05-26 | 2021-09-07 | 武汉虹旭信息技术有限责任公司 | 服务调用方法、服务调用装置及zookeeper集群 |
| WO2022166101A1 (zh) * | 2021-02-05 | 2022-08-11 | 天津市普迅电力信息技术有限公司 | 一种基于socket长连接的均衡负载分片方法 |
Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN103501319A (zh) * | 2013-09-18 | 2014-01-08 | 北京航空航天大学 | 一种低延迟的面向小文件的分布式存储系统 |
| CN104199957A (zh) * | 2014-09-17 | 2014-12-10 | 合一网络技术(北京)有限公司 | 一种Redis通用代理的实现方法 |
-
2016
- 2016-09-27 CN CN201610852752.XA patent/CN106210151A/zh active Pending
Patent Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN103501319A (zh) * | 2013-09-18 | 2014-01-08 | 北京航空航天大学 | 一种低延迟的面向小文件的分布式存储系统 |
| CN104199957A (zh) * | 2014-09-17 | 2014-12-10 | 合一网络技术(北京)有限公司 | 一种Redis通用代理的实现方法 |
Non-Patent Citations (1)
| Title |
|---|
| 曾泉匀等: "一种Redis集群管理的设计方案", 《中国科技论文在线》 * |
Cited By (28)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN106951431A (zh) * | 2016-12-16 | 2017-07-14 | 华南理工大学 | 一种集群监控数据采集方法 |
| CN106959996A (zh) * | 2017-01-20 | 2017-07-18 | 华数传媒网络有限公司 | 一种基于互联网电视的后台数据同步方法 |
| CN106951456A (zh) * | 2017-02-24 | 2017-07-14 | 广东广信通信服务有限公司 | 一种内存数据库系统及数据处理系统 |
| CN108519954A (zh) * | 2018-03-23 | 2018-09-11 | 北京焦点新干线信息技术有限公司 | 一种集中管理缓存的方法及装置 |
| CN109241048A (zh) * | 2018-06-29 | 2019-01-18 | 深圳市彬讯科技有限公司 | 用于数据统计的数据处理方法、服务器及存储介质 |
| CN109213792A (zh) * | 2018-07-06 | 2019-01-15 | 武汉斗鱼网络科技有限公司 | 数据处理的方法、服务端、客户端、装置及可读存储介质 |
| CN109213792B (zh) * | 2018-07-06 | 2021-11-09 | 武汉斗鱼网络科技有限公司 | 数据处理的方法、服务端、客户端、装置及可读存储介质 |
| CN109508261A (zh) * | 2018-08-31 | 2019-03-22 | 云南电网有限责任公司信息中心 | 一种基于大数据的电网数据节点备份方法及备份系统 |
| CN109151057A (zh) * | 2018-09-27 | 2019-01-04 | 郑州云海信息技术有限公司 | 一种智能分布式存储集群管理的方法 |
| CN111107120A (zh) * | 2018-10-29 | 2020-05-05 | 亿阳信通股份有限公司 | 一种Redis集群的构建方法及系统 |
| CN111107120B (zh) * | 2018-10-29 | 2022-09-02 | 亿阳信通股份有限公司 | 一种Redis集群的构建方法及系统 |
| CN109828971A (zh) * | 2019-01-28 | 2019-05-31 | 上海雷腾软件股份有限公司 | 支持多节点的分布式缓存方法及设备 |
| CN109800236A (zh) * | 2019-01-28 | 2019-05-24 | 上海雷腾软件股份有限公司 | 支持多节点的分布式缓存方法及设备 |
| CN109783564A (zh) * | 2019-01-28 | 2019-05-21 | 上海雷腾软件股份有限公司 | 支持多节点的分布式缓存方法及设备 |
| CN111628899A (zh) * | 2019-02-27 | 2020-09-04 | 北京京东尚科信息技术有限公司 | 服务器之间网络互联互通情况的绘制方法、装置及其系统 |
| CN111628899B (zh) * | 2019-02-27 | 2022-07-05 | 北京京东尚科信息技术有限公司 | 服务器之间网络互联互通情况的绘制方法、装置及其系统 |
| CN110224871A (zh) * | 2019-06-21 | 2019-09-10 | 深圳前海微众银行股份有限公司 | 一种Redis集群的高可用方法及装置 |
| CN110224871B (zh) * | 2019-06-21 | 2022-11-08 | 深圳前海微众银行股份有限公司 | 一种Redis集群的高可用方法及装置 |
| CN111338902A (zh) * | 2020-02-28 | 2020-06-26 | 上海商汤智能科技有限公司 | 数据处理方法、装置及系统 |
| CN111338902B (zh) * | 2020-02-28 | 2024-04-12 | 上海商汤智能科技有限公司 | 数据处理方法、装置及系统 |
| CN111541753A (zh) * | 2020-04-16 | 2020-08-14 | 深圳市网心科技有限公司 | 区块链数据的分布式存储系统、方法、计算机设备及介质 |
| CN111541753B (zh) * | 2020-04-16 | 2024-02-27 | 深圳市迅雷网络技术有限公司 | 区块链数据的分布式存储系统、方法、计算机设备及介质 |
| CN112306720B (zh) * | 2020-11-23 | 2022-06-21 | 迈普通信技术股份有限公司 | 业务系统集群管理方法 |
| CN112306720A (zh) * | 2020-11-23 | 2021-02-02 | 迈普通信技术股份有限公司 | 业务系统集群管理方法 |
| CN112559248A (zh) * | 2020-12-23 | 2021-03-26 | 深圳市彬讯科技有限公司 | 预处理服务恢复方法、装置、设备及存储介质 |
| WO2022166101A1 (zh) * | 2021-02-05 | 2022-08-11 | 天津市普迅电力信息技术有限公司 | 一种基于socket长连接的均衡负载分片方法 |
| CN113364839A (zh) * | 2021-05-26 | 2021-09-07 | 武汉虹旭信息技术有限责任公司 | 服务调用方法、服务调用装置及zookeeper集群 |
| CN113259188A (zh) * | 2021-07-15 | 2021-08-13 | 浩鲸云计算科技股份有限公司 | 一种构建大规模redis集群的方法 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN106210151A (zh) | 一种zedis分布式缓存及服务器集群监控方法 | |
| CN106357449A (zh) | 一种zedis分布式缓存方法 | |
| WO2020147331A1 (zh) | 一种微服务监控方法及系统 | |
| CN108513657B (zh) | 数据转换方法及备份服务器 | |
| CN104424287B (zh) | 数据查询方法和装置 | |
| CN108959385B (zh) | 数据库部署方法、装置、计算机设备和存储介质 | |
| CN102088490B (zh) | 数据存储方法、设备和系统 | |
| CN105653425A (zh) | 基于复杂事件处理引擎的监控系统 | |
| CN112667362B (zh) | Kubernetes上部署Kubernetes虚拟机集群的方法与系统 | |
| CN106209943A (zh) | 通讯节点的选择方法及装置 | |
| CN112953982B (zh) | 一种服务处理的方法、服务配置的方法以及相关装置 | |
| CN106209411B (zh) | 分布式网络系统容错方法、装置及容错式分布式网络系统 | |
| US11953997B2 (en) | Systems and methods for cross-regional back up of distributed databases on a cloud service | |
| CN104035836A (zh) | 集群检索平台中的自动容灾恢复方法及系统 | |
| CN112698992B (zh) | 一种云集群的容灾管理方法以及相关装置 | |
| CN109656569A (zh) | 多环境应用部署方法、设备、存储介质及装置 | |
| CN113934539B (zh) | 一种基于微服务架构的地理信息服务系统的构建方法 | |
| CN107066522A (zh) | 数据库的访问方法和装置 | |
| CN108464031A (zh) | 电信网络中的基于数据库的冗余 | |
| CN106790610A (zh) | 一种云系统消息分发方法，装置和系统 | |
| CN104657240B (zh) | 多内核操作系统的失效控制方法及装置 | |
| CN106210101A (zh) | 消息管理系统及消息管理方法 | |
| CN109213883A (zh) | 灾害模型群服务链编排方法及装置、终端、存储介质 | |
| CN113596195A (zh) | 公共ip地址管理方法、装置、主节点及存储介质 | |
| CN115134424B (zh) | 负载均衡方法、装置、计算机设备、存储介质和程序产品 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| C06 | Publication | ||
| PB01 | Publication | ||
| C10 | Entry into substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| WD01 | Invention patent application deemed withdrawn after publication |
Application publication date: 20161207 |
|
| WD01 | Invention patent application deemed withdrawn after publication |