CN117609294A - 数据查询方法、装置及设备 - Google Patents

Abstract

本发明涉及大数据技术领域，尤其涉及一种数据查询方法、装置及设备，该方法包括：在检测到当前主节点进行主从切换时，从预设数据库中提取数据信息；将数据信息恢复至目标从节点中；基于恢复后的目标从节点对接收到的查询指令进行数据查询。由于本发明可在当前主节点内待同步对象进行数据变更时，基于变更后待同步对象的数据信息构建预设数据库，并在当前主节点进行主从切换时，从预设数据库中提取数据信息并恢复至目标从节点中，再基于恢复后的目标从节点对接收到的查询指令进行数据查询。相比于现有的需依赖主节点将数据信息同步至从节点，本发明仅需通过预设数据库将数据信息恢复至从节点中，进而避免了主从同步异常情况的发生，提升用户体验。

Description

数据查询方法、装置及设备

技术领域

本发明涉及大数据技术领域，尤其涉及一种数据查询方法、装置及设备。

背景技术

目前，Redis集群常用于高并发、低延迟以及存在数据热点的业务场景中，而往往这些业务都是需要高保障的，对于Redis集群的可用性有着很高的要求。

现有的对于Redis集群的高保障方案，通常是集群化部署，即集群内的每个分片部署一个主节点和几个从节点，当主节点异常时，依赖Redis本身的机制来切换到从节点上，但该方式依赖Redis本身的主从节点信息同步，一旦Redis主从节点间同步出现异常，在切换至从节点之后，从节点上的数据就可能丢失，进而导致查询使用时使用到的为错误数据，用户体验较差。

上述内容仅用于辅助理解本发明的技术方案，并不代表承认上述内容是现有技术。

发明内容

本发明的主要目的在于提供了一种数据查询方法、装置及设备，旨在解决现有技术中由于Redis主从节点同步出现异常导致数据丢失时，查询使用到的为错误数据，用户体验较差的技术问题。

为实现上述目的，本发明提供了一种数据查询方法，所述数据查询方法包括以下步骤：

在检测到当前主节点进行主从切换时，从预设数据库中提取数据信息，所述预设数据库在所述当前主节点内的待同步对象进行数据变更时，基于变更后待同步对象的数据信息构建；

将所述数据信息恢复至目标从节点中；

基于恢复后的目标从节点对接收到的查询指令进行数据查询。

可选地，在检测到当前主节点进行主从切换时，从预设数据库中提取数据信息的步骤之前，还包括：

在当前主节点内的待同步对象进行数据变更时，获取各次变更后待同步对象的目标数据信息以及目标版本号；

基于所述目标数据信息和所述目标版本号生成数据变更日志，并将所述数据变更日志存储至预设数据库中；

相应地，所述从预设数据库中提取数据信息的步骤，包括：

基于所述数据变更日志从各所述目标版本号中选取最新目标版本号，并根据所述最新目标版本号从各所述目标数据信息中提取最新目标数据信息。

可选地，所述基于所述目标数据信息和所述目标版本号生成数据变更日志的步骤，包括：

获取各次变更前待同步对象对应的初始数据信息以及初始版本号；

基于所述初始数据信息、所述初始版本号、所述目标数据信息以及所述目标版本号生成数据变更日志；

相应地，所述基于所述目标数据信息和所述目标版本号生成数据变更日志的步骤之后，还包括：

将当前变更对应的初始数据信息与前一次变更对应的目标数据信息进行比较，并将当前变更对应的初始版本号与前一次变更对应的目标版本号进行比较；

根据比较结果对所述数据变更日志进行校验。

可选地，所述获取各次变更后待同步对象的目标数据信息以及目标版本号的步骤之前，还包括：

从管理端获取第一数据变更结果以及第二数据变更结果，所述第一数据变更结果为所述管理端从Kafka消息队列中获得的数据变更结果，所述第二数据变更结果为所述管理端从上级应用中获得的数据变更结果；

对所述第一数据变更结果以及所述第二数据变更结果进行整合，获得初始数据信息、初始版本号、目标数据信息以及目标版本号。

可选地，所述基于恢复后的目标从节点对接收到的查询指令进行数据查询的步骤之后，还包括：

在检测到目标从节点不可用时，将所述当前主节点切换至同城集群中的主节点；

从所述预设数据库中提取所述数据信息，并将所述数据信息恢复至所述同城集群中的主节点中；

基于恢复后的同城集群中的主节点对接收到的查询指令进行数据查询。

可选地，所述基于恢复后的同城集群中的主节点对接收到的查询指令进行数据查询的步骤之后，还包括：

在检测到所述同城集群中的主节点不可用时，将所述当前主节点切换至异地集群中的主节点；

从所述预设数据库中提取所述数据信息，并将所述数据信息恢复至所述异地集群中的主节点中；

基于恢复后的异地集群中的主节点对接收到的查询指令进行数据查询。

可选地，所述基于恢复后的异地集群中的主节点对接收到的查询指令进行数据查询的步骤之后，还包括：

在检测到所述异地集群中的主节点不可用时，将所述当前主节点切换至所述预设数据库；

基于所述预设数据库对接收到的查询指令进行数据查询。

可选地，所述将所述数据信息恢复至目标从节点中的步骤之前，还包括：

将所述待同步对象的服务标志设置为停止服务标志；

相应地，所述将所述数据信息恢复至目标从节点中的步骤之后，还包括：

在恢复完成时将所述服务标志设置为允许服务标志，并执行所述基于恢复后的目标从节点对接收到的查询指令进行数据查询的步骤。

此外，为实现上述目的，本发明还提出一种数据查询装置，所述装置包括：

信息提取模块，用于在检测到所述当前主节点进行主从切换时，从所述预设数据库中提取所述数据信息，所述预设数据库在当前主节点内的待同步对象进行数据变更时，基于变更后待同步对象的数据信息构建；

信息恢复模块，用于将所述数据信息恢复至目标从节点中；

数据查询模块，用于基于恢复后的目标从节点对接收到的查询指令进行数据查询。

此外，为实现上述目的，本发明还提出一种数据查询设备，所述设备包括：存储器、处理器及存储在所述存储器上并可在所述处理器上运行的数据查询程序，所述数据查询程序配置为实现如上文所述的数据查询方法的步骤。

本发明是在检测到当前主节点进行主从切换时，从预设数据库中提取所述数据信息，所述预设数据库在当前主节点内的待同步对象进行数据变更时，基于变更后待同步对象的数据信息构建；将所述数据信息恢复至目标从节点中；基于恢复后的目标从节点对接收到的查询指令进行数据查询。由于本发明可在当前主节点内待同步对象进行数据变更时，基于变更后待同步对象的数据信息构建预设数据库，并在当前主节点进行主从切换时，从预设数据库中提取数据信息并恢复至目标从节点中，再基于恢复后的目标从节点对接收到的查询指令进行数据查询。相比于现有的需依赖主节点将数据信息同步至从节点，本发明无需依赖主从节点的同步，仅需通过预设数据库将数据信息恢复至从节点中，进而避免了主从同步异常情况的发生，提升用户体验。

附图说明

图1为本发明实施例方案涉及的硬件运行环境的数据查询设备结构示意图；

图2为本发明数据查询方法第一实施例的流程示意图；

图3为本发明数据查询方法中数据变更日志示意图；

图4为本发明数据查询方法第二实施例的流程示意图；

图5为本发明数据查询方法中部署架构图；

图6为本发明数据查询方法中集群部署示意图；

图7为本发明数据查询方法中切换流程示意图；

图8为本发明数据查询方法第三实施例的流程示意图；

图9为本发明数据查询方法中数据信息恢复流程图；

图10为本发明数据查询装置第一实施例的结构框图。

本发明目的的实现、功能特点及优点将结合实施例，参照附图做进一步说明。

具体实施方式

应当理解，此处所描述的具体实施例仅用以解释本发明，并不用于限定本发明。

参照图1，图1为本发明实施例方案涉及的硬件运行环境的数据查询设备结构示意图。

如图1所示，该数据查询设备可以包括：处理器1001，例如中央处理器(CentralProcessing Unit，CPU)，通信总线1002、用户接口1003，网络接口1004，存储器1005。其中，通信总线1002用于实现这些组件之间的连接通信。用户接口1003可以包括显示屏(Display)、输入单元比如键盘(Keyboard)，可选用户接口1003还可以包括标准的有线接口、无线接口。网络接口1004可选的可以包括标准的有线接口、无线接口(如无线保真(Wireless-Fidelity，Wi-Fi)接口)。存储器1005可以是高速的随机存取存储器(RandomAccess Memory，RAM)，也可以是稳定的非易失性存储器(Non-Volatile Memory，NVM)，例如磁盘存储器。存储器1005可选的还可以是独立于前述处理器1001的存储装置。

本领域技术人员可以理解，图1中示出的结构并不构成对数据查询设备的限定，可以包括比图示更多或更少的部件，或者组合某些部件，或者不同的部件布置。

如图1所示，作为一种存储介质的存储器1005中可以包括操作系统、网络通信模块、用户接口模块以及数据查询程序。

在图1所示的数据查询设备中，网络接口1004主要用于与网络服务器进行数据通信；用户接口1003主要用于与用户进行数据交互；本发明数据查询设备中的处理器1001、存储器1005可以设置在数据查询设备中，所述数据查询设备通过处理器1001调用存储器1005中存储的数据查询程序，并执行本发明实施例提供的数据查询方法。

需要说明的是，目前，Redis集群常用于高并发、低延迟以及存在数据热点的业务场景中，而往往这些业务都是需要高保障的，对于Redis集群的可用性有着很高的要求。

现有的对于Redis集群的高保障方案，通常是集群化部署，即Redis集群可设置多个，每个Redis集群中可设置多个分片，每个分片中均可设置一个主节点以及多个从节点，当主节点正常运行时，可基于主节点提供服务，同时主节点也可将自身内的数据信息同步至该分片中所有从节点中，当主节点异常时，依赖Redis本身的机制来切换到从节点上继续提供服务。

但上述方式需依赖Redis本身的主从节点信息同步，一旦Redis主从节点间同步出现异常(例如同步延迟或者网络异常等原因)，在切换至从节点之后，从节点上的数据就可能丢失(即数据恢复点目标(Recovery Point Objective，RPO)>0，其中RPO可主要指业务系统所能容忍的数据丢失量，RPO＝0，可指已提交的数据都不会被丢失，RPO是灾难恢复时需要考虑的关键指标)，从节点中的数据与主节点中的数据不一致，进而导致查询使用时使用到的为错误数据，用户体验较差。

为解决上述缺陷，本实施例提供一种数据查询方法，可在当前主节点内的待同步对象进行数据变更操作时，将变更后待同步对象的数据信息存储至预设数据库中，并在检测到当前主节点进行主从切换时，从预设数据库中提取上述数据信息恢复至目标从节点中，最后可基于恢复后的目标从节点进行数据查询操作。相比于现有的需依赖主节点将数据信息同步至从节点，本实施例无需依赖主节点的同步，可从预设数据库中将数据信息恢复至从节点中，进而避免了主从同步异常情况的发生，提升用户体验。

为了便于理解，以下结合图2至图9对本申请实施例提供的数据查询方法进行具体介绍。

本发明实施例提供了一种数据查询方法，参考图2，图2为本发明数据查询方法第一实施例的流程示意图。

本实施例中，所述数据查询方法包括以下步骤：

步骤S10：在检测到当前主节点进行主从切换时，从预设数据库中提取数据信息，所述预设数据库在所述当前主节点内的待同步对象进行数据变更时，基于变更后待同步对象的数据信息构建。

需要说明的是，本实施例方法可以是应用在Redis集群中的主从节点进行信息同步的场景中，或者其它需要进行信息同步的场景中。本实施例的执行主体可以是具有数据查询、数据处理、网络通信以及程序运行功能的数据查询设备，例如服务器，或者是其它能够实现如同或相似功能的设备。此处以上述数据查询设备(以下简称设备)对本实施例和下述各实施例进行具体说明。

可理解的是，上述当前主节点可以是当前Redis集群中某一分片内当前提供服务的节点，当前主节点可存储若干待同步对象，每个待同步对象中均携带有该对象的数据信息，上述数据信息可以是该待同步对象的数值对应的信息。

应理解的是，一般可通过管理端应用接收数据变更指令对待同步对象中的数据信息进行数据变更操作，例如某一待同步对象的数据信息中的初始数值为10000，用户需要将该初始数值变更为11000时，管理端应用可接收相关的数据变更指令并进行消费，进而可对待同步对象的数据信息进行修改为11000。

在数据变更后，上述设备可将变更后待同步对象的数据信息进行存储，构建上述预设数据库，示例性的，可将上述11000存储至预设数据库中。其中预设数据库可以是Oracle数据库，当然还可以采用其它数据库，本实施例对此不加以限制。

还需要说明的是，当当前主节点异常时，上述设备会依赖Redis本身的机制来切换到目标从节点上继续提供服务，为了使上述设备能检测到当前发生了主从切换操作，本实施例可在待同步对象的rediskey中存储有预先登记的节点IP端口信息，并定时对节点进行心跳检测，获取的当前所处节点IP端口信息，并将两者进行比较，若不一致则可判定触发了主动切换，其中预先登记的节点IP端口信息可以是待同步对象主从切换前的节点对应的IP端口信息，当前所处节点IP端口信息可以是待同步对象主从切换后节点对应的IP端口信息，由于本实施例引入了节点IP端口信息，进而上述待同步对象中包括的信息有：数据信息+节点IP端口信息。

在具体实现中，上述设备可在检测到待同步对象中的数据信息发生数据变更时，将变更后的数据信息存储至预设数据库中，并通过待同步对象预先登记的节点IP端口信息与当前所处节点IP端口信息判断当前主节点是否发生了主从切换，若是，则可从预设数据库中提取该待同步对象对应的数据信息。

步骤S20：将所述数据信息恢复至目标从节点中。

可理解的是，由于在待同步对象的数据信息在每一次变更时，均可存储至预设数据库中，进而上述设备可从预设数据库中选取最新一次变更后获得的数据信息恢复至目标从节点中，恢复过程可在1秒以内，用户基本无感。

其中选取最新一次变更后数据信息的方式可以是按照版本号进行选取，也可以按照变更时间进行选取。

步骤S30：基于恢复后的目标从节点对接收到的查询指令进行数据查询。

应理解的是，上述查询指令可以是用户在有查询需求时上述设备所接收到的指令，当需要调取该目标从节点中的数据信息时，由于在主动切换时已将数据信息从预设数据库中恢复至目标从节点中，进而可直接基于目标从节点进行数据查询。

在具体实现中，上述设备可在当前主节点进行主从切换时，将预设数据库中待同步对象的数据信息恢复至目标从节点中提供服务。相比于现有的需依赖主节点进行信息同步，本实施例仅需通过预设数据库将数据信息恢复至从节点中，进而避免了主从同步异常情况的发生，实现RPO＝0效果，提升用户体验。

进一步地，若按照变更时间的方式从预设数据库中选取最新一次变更后获得的数据信息，本实施例上述设备可在待同步对象每次进行数据变更时，将变更时间与数据信息一同存储至上述预设数据库中，进而提取时，按照存储的变更时间选取最新的数据信息。

作为另一实现方式，若按照版本号的方式从预设数据库中选取，本实施例则可在上述在检测到所述当前主节点进行主从切换时，从所述预设数据库中提取所述数据信息的步骤之前，还包括：

步骤S01：在当前主节点内的待同步对象进行数据变更时，获取各次变更后待同步对象的目标数据信息以及目标版本号。

需要说明的是，上述目标数据信息可以是各次变更后获得的数据信息，上述目标版本号可以是各次变更后获得的版本号，本实施例可对每一个数据变更操作设置唯一版本号，示例性的，若初始的数据信息为10000，对应的版本号为0，在增加1000后，获得的目标数据信息则为11000，对应的目标版本号为1，若再减少800后，获得的目标数据信息则可为10200，对应的目标版本号则为2。

由于本实施例引入了版本号，进而上述待同步对象中包括的信息有：数据信息+版本号+节点IP端口信息。

步骤S02：基于所述目标数据信息和所述目标版本号生成数据变更日志，并将所述数据变更日志存储至预设数据库中。

可理解的是，上述数据变更日志中可记录每一次的变更记录，例如可记录第一次变更数据信息变为11000，版本号变为1，第二次记录变更数据信息变为10200，版本号变为2；并以日志的形式存储在预设数据库中。

相应地，上述从预设数据库中提取数据信息的步骤，包括：

步骤S03：基于所述数据变更日志从各所述目标版本号中选取最新目标版本号，并根据所述最新目标版本号从各所述目标数据信息中提取最新目标数据信息。

应理解的是，在提取时，可从所有目标版本号中选取最新目标版本号，并根据最新版本号选取对应的最新目标数据信息，基于上述举例，则可从各目标版本号中选取版本号2对应的10200作为上述最新目标数据信息进行提取，再恢复至目标从节点中。

在具体实现中，上述设备可在待同步对象进行数据变更时，获取各次变更后的目标数据信息以及目标版本号，基于目标数据信息以及目标版本号生成数据变更日志存储至预设数据库中，进而在提取时，可根据目标版本号确定最新目标版本号，并通过最新版本号对应的最新目标数据信息进行恢复，进而无需将所有的数据信息均恢复至目标从节点中，节约资源的同时还可快速恢复数据以提供服务，提升用户体验。

进一步地，为了对数据变更日志中记录的信息进行校验，以提升记录的准确性，本实施例可采用对版本号以及数据信息分别进行校验的方式，这是由于Redis采用的是单线程模型，保证了每个操作的原子性，基于这一点，在正确的情况下，数据变更日志中的版本号都是逐一递增的，数据信息也都是连续的。具体在本实施例中，上述基于所述目标数据信息和所述目标版本号生成数据变更日志的步骤，包括：

步骤S021：获取各次变更前待同步对象对应的初始数据信息以及初始版本号。

需要说明的是，上述初始数据信息可以是各次数据变更前对应的数据信息，上述初始版本号可以是各次数据变更前对应的版本号；

其中上述初始数据信息、初始版本号、目标数据信息以及目标版本号均可从Kafka消息队列中获得，具体过程为上述设备通过管理端从Kafka消息队列中获得第一数据变更结果，并根据第一数据变更结果获得初始数据信息、初始版本号、目标数据信息以及目标版本号。即在进行联机业务时，在业务处理完成后，可将需要发送的数据变更结果组装成包含数据信息以及版本号的消息对象，异步发送到Kafka消息队列中，管理端再对Kafka消息队列中的消息进行消费，获得上述初始数据信息、初始版本号、目标数据信息以及目标版本号。

但考虑到通过上述方式可能会出现消息丢失的情况，进而为了提升获取的准确度，本实施例还可从上级应用中获得上述初始数据信息、初始版本号、目标数据信息以及目标版本号，具体过程为上述设备通过管理端从上级应用中获得第二数据变更结果，并根据第二数据变更结果获得初始数据信息、初始版本号、目标数据信息以及目标版本号。即在业务处理完成后，会将数据变更结果返回至调用方应用(即上述上级应用)，调用方应用在接收到后可进行落地操作，存储到合适的数据库中，后续再通过接口调用的方式定时同步给管理端，管理端再进行消费，获得上述初始数据信息、初始版本号、目标数据信息以及目标版本号。

作为另一实现方式，本实施例还可同时结合上述两种方式获得初始数据信息、初始版本号、目标数据信息以及目标版本号，即可分别获得第一数据变更结果以及第二数据变更结果，再对两者进行整合，将丢失的进行补齐，将重复的进行去除，获得初始数据信息、初始版本号、目标数据信息以及目标版本号，进而减少数据丢失，保障了后续生成的数据变更日志的准确性。

步骤S022：基于所述初始数据信息、所述初始版本号、所述目标数据信息以及所述目标版本号生成数据变更日志。

可理解的是，上述设备可对各次变更的初始数据信息、初始版本号、目标数据信息以及目标版本号生成数据变更日志，参照图3，图3为本发明数据查询方法中数据变更日志示意图，如图3所示，基于上述举例，可将各次变更对应的具体操作(图3中变更操作)、初始数据信息(图3中前值)、目标数据信息(图3中后值)、初始版本号(图3中前版本号)以及目标版本号(图3中后版本号)生成数据变更日志。

示例性的，若初始的数据信息为10000，版本号为0，数据变更操作依次为增加1000、减少800、返还1500，进而数据变更日志中存储的第一次变更对应的变更操作为：增加1000，前值为10000，后值为11000，前版本号为0，后版本号为1；第二次变更对应的变更操作为：减少800，前值为11000，后值为10200，前版本号为1，后版本号为2；第三次变更对应的变更操作为：返还1500，前值为10200，后值为11700，前版本号为2，后版本号为3。

相应地，上述基于所述目标数据信息和所述目标版本号生成数据变更日志的步骤之后，还包括：

步骤S023：将当前变更对应的初始数据信息与前一次变更对应的目标数据信息进行比较，并将当前变更对应的初始版本号与前一次变更对应的目标版本号进行比较；

步骤S024：根据比较结果对所述数据变更日志进行校验。

应理解的是，在每一次变更后，上述设备均可根据数据变更日志中存储的当前变更对应的前值与前一次变更对应的后值进行比较，并同时将当前变更对应的前版本号与前一次变更对应的后版本号进行比较，若出现不一致的情况，则可判定出现异常，上述设备可发出异常通知，及时提醒用户进行定位，保证数据变更日志的完整性以及准确性。

在具体实现中，上述设备在各次变更时，可获取当前变更对应的初始数据信息以及初始版本号，并获取前一次变更对应的目标数据信息以及目标版本号，通过初始数据信息与目标数据信息之间的比较结果以及初始版本号与目标版本号之间的比较结果对数据变更日志进行校验，提升了数据变更日志的准确性。

本实施例上述设备可在待同步对象进行数据变更时，获取各次变更后的目标数据信息以及目标版本号，基于目标数据信息以及目标版本号生成数据变更日志存储至预设数据库中；自动识别主从切换的发生，在当前主节点进行主从切换时，根据预设数据库中的目标版本号确定最新目标版本号，并通过最新版本号对应的最新目标数据信息恢复至目标从节点中提供服务。相比于现有的需依赖主节点进行信息同步，本实施例不受Redis本身的主从同步机制影响，仅需通过预设数据库将数据信息恢复至从节点中，进而避免了主从同步异常情况的发生，保障了恢复数据的准确性，提升用户体验。

参考图4，图4为本发明数据查询方法第二实施例的流程示意图。

考虑到在当前集群内的主节点以及所有从节点全部宕机时，需进行灾备切换，即切换到灾备Redis集群，但现有的将当前集群内的数据信息落入至灾备Redis集群时，需要通过双写或者Redis集群间信息同步的方式实现，且启用异地灾备时需要重启应用实例。进而现有的切换方式会带来以下缺陷，1：正常情况下也要不间断的消耗存储和计算资源进行信息同步；2、需要重启实例导致业务不连续。因此为了解决上述缺陷，如图4所示，在本实施例中，上述步骤S30之后，还包括：

步骤S40：在检测到目标从节点不可用时，将所述当前主节点切换至同城集群中的主节点。

需要说明的是，上述第一实施例中的主从切换可以是在一个集群内进行，本实施例可在一个城市或区域内设置多个集群，即可包括当前集群以及同城集群，同城集群内的部署可与当前集群一致，均按多个分片，一主多从的形式部署，为了便于理解主从切换以及集群切换，可参照图5至7进行说明，图5为本发明数据查询方法中部署架构图，图6为本发明数据查询方法中集群部署示意图，图7为本发明数据查询方法中切换流程示意图，如图5所示，可设置有多个redis集群(即图5中的REDIS数据库A、REDIS数据库B以及REDIS数据库C)，可通过联机交易应用为redis集群提供联机服务，且可在一个城市或区域设置redis集群A以及redis集群B，若上述当前主节点存在于redis集群A中，则上述当前集群为redis集群A，同城集群则可为redis集群B。

redis集群A以及同城redis集群B中均可设置多个分片，各分片中均可设置一个主节点以及若干从节点(即图6中备节点)，当redis集群A中的当前主节点不可用时，可优先切换至该分片内的从节点中(即图6中1、主节点不可用时，切换到备节点)，在切换至从节点中，即可按照第一实施例中的切换方式，从数据变更日志中提取对应的数据信息进行恢复(即图7中Redis节点心跳节点，判断是否发生主从切换，若是则启动主从切换服务，基于redis日志(数据变更日志)对从节点做数据恢复)。

当redis集群A中的所有节点均不可用时，则可优先检测同城集群中的主节点是否可用，若是则进行切换，将数据信息恢复至该节点，若否则检测同城集群中的从节点是否可用，若是则进行切换(即图6中2、主备节点不可用，优先切换同城，也即图7中当前Redis集群是否可用，若否，检查同城Redis集群是否可用，可用，切换到同城Redis集群)。

进一步地，考虑到当存在多个同城集群时，与同城集群之间的距离以及同城集群内存活的节点均会对后续的数据查询性能造成影响，进而为了从中选取合适的同城集群，本实施例可根据各同城集群的距离以及其中的节点数量进行权衡后选取，具体为对距离设置距离权重值，对节点数量设置数量权重值，根据距离的倒数确定距离得分，根据节点数量的倒数确定节点数量得分，再基于距离权重值、距离得分、数量权重值以及节点数量得分选取合适的同城集群。示例性的，若距离权重值为0.6，数量权重值为0.4，集群N距离用户的平均距离为10km，存活节点数量为5，集群M距离用户的平均距离为15km，存活节点数量为8，进而集群N的距离得分为1/10＝0.1，节点数量得分1/5＝0.2，集群M的距离得分为1/15≈0.067，节点数量得分为1/8≈0.125，从而集群N的总得分为0.6*0.1+0.4*0.2＝0.12，集群M的总得分为0.6*0.067+0.4*0.125≈0.083，根据总得分可选取集群N作为切换的集群。

在此需要强调的是，上述距离权重值以及数量权重值均可根据业务需求设置，即若接收到的查询指令对应的业务对延迟和可用性的要求较高，可将距离权重值设置较大，数量权重值设置较小，若对可用节点数量要求较高，则可将距离权重值设置较小，数量权重值设置较大。

在具体实现中，在目标从节点不可用时，上述设备则可自动检测同城集群中的主节点或从节点是否可用，若主节点可用，则可优先切换至同城集群中的主节点，并在检测到发生集群切换时，将预设数据库中的数据信息恢复至该节点中继续提供服务，集群切换的具体过程可与上述主从切换的过程类似，本实施例在此不加以赘述。

步骤S50：从所述预设数据库中提取所述数据信息，并将所述数据信息恢复至所述同城集群中的主节点中。

可理解的是，在确定好同城集群中的主节点后，可从预设数据库中提取最新的数据信息恢复至该节点中，继续提供服务(即图7中基于redis日志恢复对象信息到最新地域)，具体的提取方式可与第一实施例中一致，本实施例对此不加以赘述。

步骤S60：基于恢复后的同城集群中的主节点对接收到的查询指令进行数据查询。

可理解的是，当同城集群中的主节点不可用时，依赖Redis本身的机制可从同城集群中的主节点切换至该集群中的从节点继续提供服务，则上述设备依旧可检测同城集群中是否触发了主从切换，并在切换时依旧将数据信息恢复至该目标从节点中，其中检测不可用、切换集群、切换节点以及恢复数据信息均可由图5中的管理服务以及redis监控与恢复服务实现，管理服务以及redis监控与恢复服务可由管理端应用提供，具体检测以及恢复过程均与第一实施例中一致，本实施例对此不加以赘述。

在具体实现中，上述设备可在当前集群内的主从节点均不可以用时，优先切换至同城集群中的节点，并从预设数据库中提取数据信息进行恢复，从而同城集群无需执行redis操作的双写，仅在切换时进行数据恢复，减少资源消耗，同时无需重启实例，提升了业务的连续性。

进一步地，为了在同城集群不可用之依旧可继续提供服务，本实施例还可在除同城集群所在的城市或者区域外设置异地集群(即图6中异地redis集群C)，以便在同城redis集群B不可用时切换至异地redis集群C，异地redis集群C中部署可与同城集群一致，均按多个分片，一主多从的形式部署，具体的切换过程为：上述步骤S60之后，还包括：

步骤S70：在检测到所述同城集群中的主节点不可用时，将所述当前主节点切换至异地集群中的主节点。

应理解的是，上述设备可在同城集群内的主从节点均不可用时，切换至异地集群中(即图6中的异地redis集群C)的主节点继续提供服务，在切换时，依旧可优先检测异地集群中的主节点是否可用，若主节点可用，则切换至异地集群中的主节点继续提供服务。

需要说明的是，若存在多个异地集群，也可按照上述同城集群的选取方式计算总得分后选取，在此不加以赘述。

步骤S80：从所述预设数据库中提取所述数据信息，并将所述数据信息恢复至所述异地集群中的主节点中。

可理解的是，在确定好异地集群中的主节点后，可从预设数据库中提取最新的数据信息恢复至该节点中，继续提供服务(即图7中基于redis日志恢复对象信息到最新地域)，具体的提取方式可与第一实施例中一致，本实施例对此不加以赘述。

步骤S90：基于恢复后的异地集群中的主节点对接收到的查询指令进行数据查询。

可理解的是，当异地集群中的主节点不可用时，依赖Redis本身的机制可从异地集群中的主节点切换至该集群中的从节点继续提供服务，则上述设备依旧可检测异地集群中是否触发了主从切换，并在切换时依旧将数据信息恢复至该目标从节点中，(即图6中主备节点不可用，同城也不可用，切换到异地，也即图7中检查异地Redis集群是否可用，若可用则切换到异地Redis集群)，具体检测以及恢复过程均与上述一致，本实施例对此不加以赘述。

在具体实现中，上述设备可在同城集群内的主从节点均不可以用时，切换至异地集群中的节点，并从预设数据库中提取数据信息进行恢复，从而异地集群无需执行redis操作的双写，仅在切换时进行数据恢复，减少资源消耗，同时无需重启实例，提升了业务的连续性。

进一步地，考虑到异地集群中的节点也均不可用时，本实施例还设置有兜底策略，即可切换至本实施例中的预设数据库继续提供服务，具体流程为：上述步骤S90之后，还包括：

步骤S100：在检测到所述异地集群中的主节点不可用时，将所述当前主节点切换至所述预设数据库；

步骤S110：基于所述预设数据库对接收到的查询指令进行数据查询。

需要说明的是，本实施例提供的兜底策略对应的服务可由图5所示的降级服务提供，在异地集群不可用时，上述设备可对联机服务进行自动降级，切换至预设数据库(即图5中的关系型数据库，也即图6中的数据库)继续提供服务(即图6中主备节点不可用，同城、异地redis均不可用，切换到数据库，也即图7中异地Redis集群不可用时切换到Oracle数据库)。

在具体实现中，当异地集群中的主从节点均不可用时，可切换至预设数据库，从预设数据库内的数据变更日志中提取对应的数据信息继续提供服务，从而预设数据库无需执行redis操作的双写，减少资源消耗，同时无需重启实例，提升了业务的连续性。

本实施例可在当前集群内的主从节点均不可用时，先切换至同城集群内节点继续提供服务；若同城集群内的节点不可用时，切换至异地集群内的节点继续提供服务；若异地集群内的节点不可同时，切换至上述预设数据库继续提供服务；其中恢复的数据信息均可从预设数据库中获得，因此本实施例可无需执行redis操作的双写，减少资源消耗，同时无需重启实例，提升了业务的连续性。

参考图8，图8为本发明数据查询方法第三实施例的流程示意图。

考虑到在将数据信息从预设数据库恢复至节点上时，为了防止恢复期间节点接收到查询指令而返回错误数据信息，影响用户体验，因此本实施例可对待同步对象配置服务标志，可根据服务标志判断此时该待同步对象的数据信息是否可以提供服务，如图8所示，具体流程如下：上述步骤S20之前，还包括：

步骤S201：将所述待同步对象的服务标志设置为停止服务标志。

需要说明的是，上述服务标识可分为停止服务标志以及允许服务标志，其中若为停止服务标志则可表明此时该数据信息暂停服务，不允许有业务发生；若为运行服务标志则可表明此时该数据信息允许服务，允许发生业务。

进而在不需要进行恢复时，待同步对象的服务标志一般设置为允许服务标志，以便联机交易应用进行交易服务，参照图9，图9为本发明数据查询方法中数据信息恢复流程图，如图9所示，联机交易应用可检查待同步对象当前的服务标志是否为允许服务标志(即图9中检查是否提供服务标志)，若否，则说明为停止服务标志，该待同步对象的数据信息暂停服务(即图9中闭市，报错暂停服务)，若是，则可正常开市进行交易，在此期间可检查当前所处节点IP端口信息与预先登记的节点IP端口信息是否一致(即图9中检查操作redis对象当前节点与节点信息中的IP是否一致)，若一致说明并未发生主从切换，该节点可正常提供服务(即图9中一致，redis对象使用)，若不一致说明此时出触发了主从切换，则需将服务标志设置为停止服务标志，不允许发生业务(即图9中不一致，报错暂停服务)。

同时，对于管理端应用来说，管理端应用同样也可通过定时检测节点IP端口信息是否一致的方式判断主从节点是否开始切换(即图9中定时任务探测主从节点开始切换，检查redis对象实际所处节点IP与对象中登记IP是否一致)，若不一致则可进行登记，并将该待同步对象的服务标志由允许服务标志设置为停止服务标志(即图9中不一致，登记异步处理，设置不提供服务)，接着进行数据恢复，将预设数据库中的数据信息恢复至对应节点上(即图9中刷新redis中对象数值，版本号等信息)。

相应地，上述步骤S20之后，还包括：

步骤S202：在恢复完成时将所述服务标志设置为允许服务标志，并执行所述基于恢复后的目标从节点对接收到的查询指令进行数据查询的步骤。

可理解的是，在恢复完成后，即可将服务标志设置为允许服务标志，继续提供服务(即图9中设置提供服务)。

应理解的是，由于本实施例引入了服务标志，进而上述待同步对象中包括的信息有：数据信息+版本号+节点IP端口信息+服务标志。

本实施例上述设备可在正常情况下将待同步对象的服务标志设置为允许服务标志，当出现主从切换或集群切换时，可将服务标志设置为禁止服务标志，以短暂暂停服务，并在数据信息恢复完成后又重新设置为允许服务标志，进而可防止恢复期间节点接收到查询指令而返回错误数据信息，提升用户体验。

此外，本发明实施例还提出一种存储介质，所述存储介质上存储有数据查询程序，所述数据查询程序被处理器执行时实现如上文所述的数据查询方法的步骤。

此外，参照图10，图10为本发明数据查询装置第一实施例的结构框图，本发明实施例还提出一种数据查询装置，所述数据查询装置包括：

信息提取模块100，用于在检测到当前主节点进行主从切换时，从预设数据库中提取数据信息，所述预设数据库在所述当前主节点内的待同步对象进行数据变更时，基于变更后待同步对象的数据信息构建；

信息恢复模块110，用于将所述数据信息恢复至目标从节点中；

数据查询模块120，用于基于恢复后的目标从节点对接收到的查询指令进行数据查询。

本实施例上述设备可在待同步对象进行数据变更时，获取各次变更后的目标数据信息以及目标版本号，基于目标数据信息以及目标版本号生成数据变更日志存储至预设数据库中；自动识别主从切换的发生，在当前主节点进行主从切换时，根据预设数据库中的目标版本号确定最新目标版本号，并通过最新版本号对应的最新目标数据信息恢复至目标从节点中提供服务。相比于现有的需依赖主节点进行信息同步，本实施例不受Redis本身的主从同步机制影响，仅需通过预设数据库将数据信息恢复至从节点中，进而避免了主从同步异常情况的发生，保障了恢复数据的准确性，提升用户体验。

作为一种实施方式，所述信息提取模块100，还用于在当前主节点内的待同步对象进行数据变更时，获取各次变更后待同步对象的目标数据信息以及目标版本号；基于所述目标数据信息和所述目标版本号生成数据变更日志，并将所述数据变更日志存储至预设数据库中。

所述信息提取模块100，还用于基于所述数据变更日志从各所述目标版本号中选取最新目标版本号，并根据所述最新目标版本号从各所述目标数据信息中提取最新目标数据信息。

作为一种实施方式，所述信息提取模块100，还用于获取各次变更前待同步对象对应的初始数据信息以及初始版本号；基于所述初始数据信息、所述初始版本号、所述目标数据信息以及所述目标版本号生成数据变更日志；

所述信息提取模块100，还用于将当前变更对应的初始数据信息与前一次变更对应的目标数据信息进行比较，并将当前变更对应的初始版本号与前一次变更对应的目标版本号进行比较；根据比较结果对所述数据变更日志进行校验。

作为一种实施方式，所述信息提取模块100，还用于从管理端获取第一数据变更结果以及第二数据变更结果，所述第一数据变更结果为所述管理端从Kafka消息队列中获得的数据变更结果，所述第二数据变更结果为所述管理端从上级应用中获得的数据变更结果；对所述第一数据变更结果以及所述第二数据变更结果进行整合，获得初始数据信息、初始版本号、目标数据信息以及目标版本号。

基于本发明上述数据查询装置第一实施例，提出本发明数据查询装置的第二实施例。

在本实施例中，所述数据查询模块120，还用于在检测到目标从节点不可用时，将所述当前主节点切换至同城集群中的主节点；从所述预设数据库中提取所述数据信息，并将所述数据信息恢复至所述同城集群中的主节点中；基于恢复后的同城集群中的主节点对接收到的查询指令进行数据查询。

作为一种实施方式，所述数据查询模块120，还用于在检测到所述同城集群中的主节点不可用时，将所述当前主节点切换至异地集群中的主节点；从所述预设数据库中提取所述数据信息，并将所述数据信息恢复至所述异地集群中的主节点中；基于恢复后的异地集群中的主节点对接收到的查询指令进行数据查询。

作为一种实施方式，所述数据查询模块120，还用于在检测到所述异地集群中的主节点不可用时，将所述当前主节点切换至所述预设数据库；基于所述预设数据库对接收到的查询指令进行数据查询。

基于本发明上述数据查询装置各实施例，提出本发明数据查询装置的第三实施例。

在本实施例中，所述信息恢复模块110，还用于将所述待同步对象的服务标志设置为停止服务标志；

所述信息恢复模块110，还用于在恢复完成时将所述服务标志设置为允许服务标志，并执行所述基于恢复后的目标从节点对接收到的查询指令进行数据查询的操作。

本发明数据查询装置的其他实施例或具体实现方式可参照上述各方法实施例，此处不再赘述。

需要说明的是，在本文中，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者系统不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者系统所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括该要素的过程、方法、物品或者系统中还存在另外的相同要素。

上述本发明实施例序号仅仅为了描述，不代表实施例的优劣。通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到上述实施例方法可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件，但很多情况下前者是更佳的实施方式。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质(如只读存储器/随机存取存储器、磁碟、光盘)中，包括若干指令用以使得一台终端设备(可以是手机，计算机，服务器，或者网络设备等)执行本发明各个实施例所述的方法。

以上仅为本发明的优选实施例，并非因此限制本发明的专利范围，凡是利用本发明说明书及附图内容所作的等效结构或等效流程变换，或直接或间接运用在其他相关的技术领域，均同理包括在本发明的专利保护范围内。

Claims (10)

1.一种数据查询方法，其特征在于，所述数据查询方法包括以下步骤：

在检测到当前主节点进行主从切换时，从预设数据库中提取数据信息，所述预设数据库在所述当前主节点内的待同步对象进行数据变更时，基于变更后待同步对象的数据信息构建；

将所述数据信息恢复至目标从节点中；

基于恢复后的目标从节点对接收到的查询指令进行数据查询。

2.如权利要求1所述的数据查询方法，其特征在于，所述在检测到当前主节点进行主从切换时，从预设数据库中提取数据信息的步骤之前，还包括：

在当前主节点内的待同步对象进行数据变更时，获取各次变更后待同步对象的目标数据信息以及目标版本号；

基于所述目标数据信息和所述目标版本号生成数据变更日志，并将所述数据变更日志存储至预设数据库中；

相应地，所述从预设数据库中提取数据信息的步骤，包括：

基于所述数据变更日志从各所述目标版本号中选取最新目标版本号，并根据所述最新目标版本号从各所述目标数据信息中提取最新目标数据信息。

3.如权利要求2所述的数据查询方法，其特征在于，所述基于所述目标数据信息和所述目标版本号生成数据变更日志的步骤，包括：

获取各次变更前待同步对象对应的初始数据信息以及初始版本号；

基于所述初始数据信息、所述初始版本号、所述目标数据信息以及所述目标版本号生成数据变更日志；

相应地，所述基于所述目标数据信息和所述目标版本号生成数据变更日志的步骤之后，还包括：

将当前变更对应的初始数据信息与前一次变更对应的目标数据信息进行比较，并将当前变更对应的初始版本号与前一次变更对应的目标版本号进行比较；

根据比较结果对所述数据变更日志进行校验。

4.如权利要求3所述的数据查询方法，其特征在于，所述获取各次变更后待同步对象的目标数据信息以及目标版本号的步骤之前，还包括：

从管理端获取第一数据变更结果以及第二数据变更结果，所述第一数据变更结果为所述管理端从Kafka消息队列中获得的数据变更结果，所述第二数据变更结果为所述管理端从上级应用中获得的数据变更结果；

对所述第一数据变更结果以及所述第二数据变更结果进行整合，获得初始数据信息、初始版本号、目标数据信息以及目标版本号。

5.如权利要求1至4中任一项所述的数据查询方法，其特征在于，所述基于恢复后的目标从节点对接收到的查询指令进行数据查询的步骤之后，还包括：

在检测到目标从节点不可用时，将所述当前主节点切换至同城集群中的主节点；

从所述预设数据库中提取所述数据信息，并将所述数据信息恢复至所述同城集群中的主节点中；

基于恢复后的同城集群中的主节点对接收到的查询指令进行数据查询。

6.如权利要求5所述的数据查询方法，其特征在于，所述基于恢复后的同城集群中的主节点对接收到的查询指令进行数据查询的步骤之后，还包括：

在检测到所述同城集群中的主节点不可用时，将所述当前主节点切换至异地集群中的主节点；

从所述预设数据库中提取所述数据信息，并将所述数据信息恢复至所述异地集群中的主节点中；

基于恢复后的异地集群中的主节点对接收到的查询指令进行数据查询。

7.如权利要求6所述的数据查询方法，其特征在于，所述基于恢复后的异地集群中的主节点对接收到的查询指令进行数据查询的步骤之后，还包括：

在检测到所述异地集群中的主节点不可用时，将所述当前主节点切换至所述预设数据库；

基于所述预设数据库对接收到的查询指令进行数据查询。

8.如权利要求1所述的数据查询方法，其特征在于，所述将所述数据信息恢复至目标从节点中的步骤之前，还包括：

将所述待同步对象的服务标志设置为停止服务标志；

相应地，所述将所述数据信息恢复至目标从节点中的步骤之后，还包括：

在恢复完成时将所述服务标志设置为允许服务标志，并执行所述基于恢复后的目标从节点对接收到的查询指令进行数据查询的步骤。

9.一种数据查询装置，其特征在于，所述装置包括：

信息提取模块，用于在检测到当前主节点进行主从切换时，从预设数据库中提取数据信息，所述预设数据库在所述当前主节点内的待同步对象进行数据变更时，基于变更后待同步对象的数据信息构建；

信息恢复模块，用于将所述数据信息恢复至目标从节点中；

数据查询模块，用于基于恢复后的目标从节点对接收到的查询指令进行数据查询。

10.一种数据查询设备，其特征在于，所述设备包括：存储器、处理器及存储在所述存储器上并可在所述处理器上运行的数据查询程序，所述数据查询程序配置为实现如权利要求1至8任一项所述的数据查询方法的步骤。