CN112328634A - 一种基于数据库的操作请求处理方法和装置 - Google Patents

Abstract

本申请涉及一种基于数据库的操作请求处理方法和装置，该方法包括：接收数据库操作请求；数据库操作请求包括访问来源标识和业务标识；根据访问来源标识和获取的对应关系表，从多个线程池中确定出目标线程池；基于目标线程池从常用数据分库中获取预设路由规则；其中，预设路由规则包括多个访问来源与多个分库的对应关系；根据访问来源标识和预设路由规则确定目标分库；向目标分库发送数据库操作请求，以从目标分库中获取业务标识对应的数据。如此，可以减少数据库宕机影响范围，可以分散数据库访问压力，从而可以提升系统负载能力。

Description

一种基于数据库的操作请求处理方法和装置

技术领域

本申请涉及数据处理技术领域，特别涉及一种基于数据库的操作请求处理方法和装置。

背景技术

随着银行业务的不断发展，各重要系统的交易量越来越大，涉及到的数据量也越来越多。数据库的种类包括SQL Server、MySql、MS SqlServer和Oracle等；目前银行大多交易系统均采用单套数据库的架构，各交易系统所涉及的全部交易数据均存储于单套数据库中。

对于银行的核心业务来讲，系统的恢复时间目标(RTO)和恢复点目标(RPO)这两项指标有着严格的要求。RTO指故障发生后，信息系统或业务功能从停顿到必须恢复的时间要求，RTO对业务流程恢复优先级的确定有重要作用；RPO指故障发生后，系统和数据必须恢复到的时间点要求，RPO标示了某项业务能容忍的最大数据损失。

对于目前基于单套数据库的银行的交易系统来说，即使是短时间停机也会造成不可估量的经济及声誉损失；且随着业务量的不断增加，业务模型复杂度的不断增高，目前银行交易系统中单套数据库的硬件性能终究会达到瓶颈，纵向扩容也会存在扩无可扩的情况。

发明内容

本申请实施例提供了一种基于数据库的操作请求处理方法和装置，可以减少数据库宕机影响范围，可以分散数据库访问压力，从而可以提升系统负载能力。

一方面，本申请实施例提供了一种基于数据库的操作请求处理方法，包括：

接收数据库操作请求；数据库操作请求包括访问来源标识和业务标识；

根据访问来源标识和获取的对应关系表，从多个线程池中确定出目标线程池；对应关系表包括多个访问来源标识与多个线程池的对应关系；

基于目标线程池从常用数据分库中获取预设路由规则；其中，预设路由规则包括多个访问来源与多个分库的对应关系；多个分库的每个分库用于存储预设时间范围多个访问来源产生的数据；常用数据分库用于根据预设频率从多个分库中获取多个常用数据表；

根据访问来源标识和预设路由规则确定目标分库；

向目标分库发送数据库操作请求，以从目标分库中获取业务标识对应的数据。

可选的，业务标识包括第一业务标识或第二业务标识；目标分库包括两个第一业务库和两个第二业务库；两个第一业务库互为备份；两个第二业务库互为备份；向目标分库发送数据库操作请求，包括：向两个第一业务库中任一个第一业务库发送数据库操作请求；数据库操作请求的业务标识为第一业务标识；或；向两个第二业务库中任一个第二业务库发送数据库操作请求；数据库操作请求的业务标识为第二业务标识。

可选的，多个分库包括常用数据分库配置信息表；从多个线程池中确定出目标线程池之后，还包括：获取常用数据分库配置信息表的状态；若常用数据分库配置信息表的状态为正常状态，则执行步骤：基于目标线程池从常用数据分库中获取预设路由规则。

可选的，若常用数据分库配置信息表的状态为异常状态，则基于目标线程池向第一预设目标分库发送数据库操作请求，以从第一预设目标分库中获取业务标识对应的数据。

可选的，常用数据分库还包括数据维护规则；数据维护规则包括多个分库的数据维护顺序；业务标识还包括第三业务标识；从多个线程池中确定出目标线程池之后，还包括：判断业务标识的种类；若业务标识的种类为第三业务标识，则基于目标线程池向第二预设目标分库发送数据库操作请求；若获取到第二预设目标分库数据维护成功信号，则向第三预设目标分库发送数据库操作请求。

可选的，根据访问来源标识和获取的对应关系表，从多个线程池中确定出目标线程池，包括：根据访问来源标识，从对应关系表中，确定出访问来源标识对应的线程池，将访问来源标识对应的线程池作为目标线程池。

另一方面，本申请实施例提供了一种基于数据库的操作请求处理装置，包括：

接收模块，用于接收数据库操作请求；数据库操作请求包括访问来源标识和业务标识；

第一确定模块，用于根据访问来源标识和获取的对应关系表，从多个线程池中确定出目标线程池；对应关系表包括多个访问来源标识与多个线程池的对应关系；

获取模块，用于基于目标线程池从常用数据分库中获取预设路由规则；其中，预设路由规则包括多个访问来源与多个分库的对应关系；多个分库的每个分库用于存储预设时间范围多个访问来源产生的数据；常用数据分库用于根据预设频率从多个分库中获取多个常用数据表；

第二确定模块，用于根据访问来源标识和预设路由规则确定目标分库；

发送模块，用于向目标分库发送数据库操作请求，以从目标分库中获取业务标识对应的数据。

可选的，业务标识包括第一业务标识或第二业务标识；目标分库包括两个第一业务库和两个第二业务库；两个第一业务库互为备份；两个第二业务库互为备份；

发送模块，用于向两个第一业务库中任一个第一业务库发送数据库操作请求；数据库操作请求的业务标识为第一业务标识；或；向两个第二业务库中任一个第二业务库发送数据库操作请求；数据库操作请求的业务标识为第二业务标识。

可选的，多个分库包括常用数据分库配置信息表；获取模块，还用于获取常用数据分库配置信息表的状态；若常用数据分库配置信息表的状态为正常状态，则执行步骤：基于目标线程池从常用数据分库中获取预设路由规则。

可选的，发送模块，还用于若常用数据分库配置信息表的状态为异常状态，则基于目标线程池向第一预设目标分库发送数据库操作请求，以从第一预设目标分库中获取业务标识对应的数据。

本申请实施例提供的一种基于数据库的操作请求处理方法和装置具有如下有益效果：

通过接收数据库操作请求；数据库操作请求包括访问来源标识和业务标识；根据访问来源标识和获取的对应关系表，从多个线程池中确定出目标线程池；对应关系表包括多个访问来源标识与多个线程池的对应关系；基于目标线程池从常用数据分库中获取预设路由规则；其中，预设路由规则包括多个访问来源与多个分库的对应关系；多个分库的每个分库用于存储预设时间范围多个访问来源产生的数据；常用数据分库用于根据预设频率从多个分库中获取多个常用数据表；根据访问来源标识和预设路由规则确定目标分库；向目标分库发送数据库操作请求，以从目标分库中获取业务标识对应的数据。如此，可以减少数据库宕机影响范围，可以分散数据库访问压力，从而可以提升系统负载能力。

附图说明

为了更清楚地说明本申请实施例中的技术方案，下面将对实施例描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1是本申请实施例提供的一种改进后的数据库的交易类系统架构图的示意图；

图2是本申请实施例提供的一种基于数据库的操作请求处理方法的流程示意图；

图3是本申请实施例提供的一种基于数据库的操作请求处理装置的结构示意图。

具体实施方式

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动的前提下所获得的所有其他实施例，都属于本申请保护的范围。

需要说明的是，本申请的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本申请的实施例能够以除了在这里图示或描述的那些以外的顺序实施。此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、系统、产品或服务器不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。

鉴于目前银行交易类系统由于采用单套数据库的架构，导致数据库宕机影响范围较大的问题，本申请实施例中，对现有的数据库结构进行改进，使其适用于高并发、高时效性的交易类系统，并提供了一种基于改进后的数据库的操作请求处理方法和装置。

本申请实施例中，对现有的单套数据库进行分库操作，结合图1所示，图1是本申请实施例提供的一种应用场景的示意图，即一种改进后的数据库的交易类系统架构图。

图1中通讯服务是用于接收外部的请求的功能模块，将报文解析后转发至路由服务，同时也用于将系统内部功能模块的处理结果转发至外组件，是系统的出入口；路由服务根据外部请求的报文字段，能够将服务请求转发至不同的分库；

在本申请实施例涉及的应用场景中，前台/后台基础服务可以包括：将路由服务转发过来的请求根据业务规则进行处理，同时写入数据库；其中，前台基础服务处理前台人员(主要是对客柜员等)发起的请求，后台基础服务(主要是中后台管理审批人员)发起的请求；

工作流服务具体可以包括：当基础服务解析出具体的业务编码和场景后，工作流服务根据既定的业务规则，将业务操作流程拆分成具体工作项(版面识别、影像拆分、一次录入、二次录入、录入仲裁、数据检核、记账)等等；

自动服务可以包括：对于工作流服务中拆分出的工作项，除去必须人工进行的环节，部分可以通过程序实现的服务，由自动服务来实现，比如版面识别、要素录入、数据检核、重复交易校验等等；

日终服务可以包括：用于系统夜间的日终批量程序，主要包括清理历史数据，当前库数据进入历史库，调整当日未完成任务优先级，外系统供数和数据加载等等；

Redis：内存数据库，具有高并发的特性，用以存放路由参数配置表等，生产排班参数、人员调度信息、任务分配信息、业务特有的审批点机构等访问频率较高的表；

业务库：存放业务流水数据及操作日志等业务逻辑相关的数据；

核心库：存放工作流任务等流程引擎相关的数据；

历史库：存放历史数据，一般只用作查询；

本申请实施例中，上述当前库和历史库是依照时间的维度进行划分的，当前库进行具体的业务处理，历史库进行历史查询；考虑到当前库的重要程度远高于历史库，一方面将业务库和核心库做了彻底的切分，用两套RAC(Real Application Clusters)来实现相关功能；RAC是Oracle数据库的一个群集解决方案，是有着两个或者两个以上的数据库节点协调运作能力的。

另一方面，对系统进行适量改造，按照分行的维度将系统的当前库再一步进行拆分，进一步降低系统数据库的负载；即设置多组当前库，每组当前库可用于服务若干分行；如此，若当前库中任意一套库故障，可以将相关的业务切换至另一套库，使得新接入的业务不受影响，满足业务的连续性；增加路由服务和Redis两个单元。

本申请实施例中，基于原系统现有架构进行改造，通过增加少量的功能模块，将现有全行数据分散到多个库中，分库间的业务量基本保持一致，如此分散了数据库数据，可以减少数据库宕机影响范围，避免某套数据库的不可用造成全行业务不可用；分库后某一套数据库发生故障只短暂影响这个库中的业务处理，不影响其他库中的业务处理，故障分行只影响查询业务和在途业务，新业务不受影响可立即切换到正常库中。

可选的，当前库的种类可以是Oracle。

以下介绍本申请一种基于数据库的操作请求处理方法的具体实施例，图2是本申请实施例提供的一种基于数据库的操作请求处理方法的流程示意图，本说明书提供了如实施例或流程图的方法操作步骤，但基于常规或者无创造性的劳动可以包括更多或者更少的操作步骤。实施例中列举的步骤顺序仅仅为众多步骤执行顺序中的一种方式，不代表唯一的执行顺序。在实际中的系统或服务器产品执行时，可以按照实施例或者附图所示的方法顺序执行或者并行执行(例如并行处理器或者多线程处理的环境)。具体的如图2所示，该方法可以包括：

S201：接收数据库操作请求；数据库操作请求包括访问来源标识和业务标识。

本申请实施例中，该步骤由服务器执行。结合图1的系统架构图，数据库操作请求可以通过通讯服务进行接收，然后转发至路由服务；数据库操作请求包括访问来源标识和业务标识，访问来源标识用于表明数据库操作的发起方，可以是分行代码或者分行号；业务标识指的是发起方所发起的具体业务的标识，例如银行账户余额查询业务的标识、跨行转账业务的标识等。

S203：根据访问来源标识和获取的对应关系表，从多个线程池中确定出目标线程池；对应关系表包括多个访问来源标识与多个线程池的对应关系；

本申请实施例中，路由服务中创建有多个线程池，对应关系表是预先存储在路由服务中的包括多个访问来源标识与多个线程池的对应关系，不同访问来源标识的数据库操作请求在不同的线程池中进行处理。

本申请实施例中，由于在路由服务中创建了多个线程池，每套数据库有自己单独的线程资源，互相之间没有干扰。假设某一分库出现了故障，至多消耗本线程池的线程资源，不会影响到其他线程池的相关资源，也不会影响奇特数据库的正常运行。相比于现有技术中，某一分库出现了故障，此时所有经过路由服务发往该分库的请求都会被阻塞，由于整个路由服务共用一个线程池，会导致整个路由服务中的线程资源被耗尽。此时，纵使其他分库没有故障，也会因为路由服务没有可用线程而无法接收新的请求，从而导致整个系统的不可用。如此，本申请通过线程池隔离来实现故障隔离，避免一套库故障时，链接该库的服务无法响应，导致整个路由服务线程池资源耗尽，进而影响到全局交易；同时，实现线程池级中，不同请求的不同超时控制并参数化超时参数、实现对不同请求单个AP和全局限流控制。

在一种可选的根据访问来源标识和获取的对应关系表，从多个线程池中确定出目标线程池的实施方式中，包括：根据访问来源标识，从对应关系表中，确定出访问来源标识对应的线程池，将访问来源标识对应的线程池作为目标线程池。

S205：基于目标线程池从常用数据分库中获取预设路由规则；其中，预设路由规则包括多个访问来源与多个分库的对应关系；多个分库的每个分库用于存储预设时间范围多个访问来源产生的数据；常用数据分库用于根据预设频率从多个分库中获取多个常用数据表。

S207：根据访问来源标识和预设路由规则确定目标分库。

本申请实施例中，多个访问来源与多个分库的对应关系中，每个分库用于存储预设时间范围多个访问来源产生的数据，即图1所示的当前库；多个访问来源可以是多个分行；由于一个当前库可以服务于多个分行，也就是说，多个访问来源可以对应于一个分库。业务标识可以是交易类系统所支持的各种服务的标识，包括前台基础服务、自动服务、日终服务、后台基础服务、工作流服务等。

在一种可选的实施方式中，多个分库包括常用数据分库配置信息表；从多个线程池中确定出目标线程池之后，还包括：获取常用数据分库配置信息表的状态；若常用数据分库配置信息表的状态为正常状态，则执行步骤：基于目标线程池从常用数据分库中获取预设路由规则；

若常用数据分库配置信息表的状态为异常状态，则基于目标线程池向第一预设目标分库发送数据库操作请求，以从第一预设目标分库中获取业务标识对应的数据。

具体的，结合图1的架构图，常用数据分库可以是Redis，Redis根据预设频率从分库中定时获取多个常用数据表，例如路由参数配置表；常用数据分库配置信息表可以是Redis配置信息表，当Redis正常工作时，Redis配置信息表为正常状态；当Redis出现故障时，此时，Redis配置信息表为异常状态；当数据库操作请求中的业务标识为第二预设业务标识，即一些常用业务的标识，且Redis配置信息表的状态为正常状态时，目标线程池向Redis发送数据库操作请求；而当Redis配置信息表的状态为异常状态时，目标线程池将绕过Redis，向第一预设目标分库发送数据库操作请求。这样做的好处是，每次路由服务接入数据库操作请求时，不再访问多个分库，而是访问Redis，Redis本身具有响应速度快，支持高并发等优点。如此，可以降低分库的压力，可以提升系统的响应效率，又因为Redis中数据的来源是多个分库，从而可以规避Redis在数据持续化方面的问题。

本申请实施例中，将参数维护操作转发给每个分库对应的AP服务，同时维护到每个分库中，相较于现有技术中OGG同步，可以降低操作的复杂性。所有的参数维护请求都先固定发到一个分库。如果失败，则请求不再发送到后续分库；如果成功了则发送到后续分库，后续分库如果请求失败，则记为失败。直到所有分库都成功才将参数生效，避免了全局参数不一致的问题。

在一种可选的实施方式中，常用数据分库还包括数据维护规则；数据维护规则包括多个分库的数据维护顺序；业务标识还包括第三业务标识；从多个线程池中确定出目标线程池之后，还包括：判断业务标识的种类；若业务标识的种类为第三业务标识，则基于目标线程池向第二预设目标分库发送数据库操作请求；若获取到第二预设目标分库数据维护成功信号，则向第三预设目标分库发送数据库操作请求。

具体的，对于数据维护业务来说，其要维护的数据包括大量需要在全体分行同时生效的参数信息，因此当业务标识为数据维护业务标识时，将对应的数据库操作请求先转发到第二预设目标分库中，当获取到第二预设目标分库数据维护成功信号时，则向第三预设目标分库发送数据库操作请求，直至所有分库维护成功，参数才生效；其中第二预设目标分库和第三预设目标分库的维护顺序可以预先进行设定。

S209：向目标分库发送数据库操作请求，以从目标分库中获取业务标识对应的数据。

本申请实施例中，第一预设业务标识包括第一业务标识或第二业务标识，第一业务标识指的是核心业务的标识，核心业务可以包括上述的前台基础服务、自动服务、日终服务、后台基础服务；第二业务标识可以指其他非核心业务的标识，例如上述的工作流服务。对应的，目标分库即每个分库包括两个第一业务库和两个第二业务库，是由两套RAC来实现相关功能的，因此两个第一业务库互为备份，两个第二业务库互为备份。

在一种可选的向目标分库发送数据库操作请求的实施方式中，包括：向两个第一业务库中任一个第一业务库发送数据库操作请求；数据库操作请求的业务标识为第一业务标识；或；向两个第二业务库中任一个第二业务库发送数据库操作请求；数据库操作请求的业务标识为第二业务标识。

下面通过一个具体的客户端请求为例进行说明。假设银行柜员在前台办理一笔信用卡申请的业务，柜员通过扫描仪将客户填写的申请单从员工渠道进行上传，此时，员工渠道会将影像及报文(包含数据库操作请求)通过通讯服务送至系统，系统架构可以参阅图1；首先，通讯服务对数据库操作请求进行解析，并通过路由服务进行转发；其次，路由服务接收到数据库操作请求之后，根据数据库操作请求中所带的访问来源标识(银行分号或者其他机构号信息等)，访问Redis中的路由参数表(即预设路由规则)，将数据库操作请求转发到对应分行所在的前台基础服务中；

前台基础服务根据数据库操作请求进行解析，并将流水记录到对应的目标分库(业务库)中；

同时，工作流引擎根据基础服务解析的结果，将该任务生成若干个工作项(版面识别、影响拆分、OCR识别、一次录入、二次录入、录入仲裁、网点审批、二级分行审批、一级分行审批、外呼记账等等)；

自动服务开始对工作项中机器处理的部分进行处理；

同时，中后台人员登录后台web，web仍然将请求转发至路由服务，路由服务根据登录人员的银行分号，结合路由参数表将服务发往对应的后台基础服务，中后台人员进行任务的处理，在任务处理过程中，会对路由服务中的生产排班参数、人员调度信息、任务分配信息、业务特有的审批点机构等表进行若干次访问，以确认该人员是否有本任务的处理权限，直到该业务所有工作项全部完成，最终成功记账。

综上，本申请提供的一种基于数据库的操作请求处理方法，根据数据库操作请求中的访问来源标识，在对应的目标线程池中进行处理，并根据业务标识将数据库操作请求转发至对应的目标分库中，以从目标分库中获取业务标识对应的数据。如此，可以分散数据库访问压力，从而可以提升系统负载能力。

本申请实施例还提供了一种基于数据库的操作请求处理装置，图3是本申请实施例提供的一种基于数据库的操作请求处理装置的结构示意图，如图3所示，该装置包括：

接收模块301，用于接收数据库操作请求；数据库操作请求包括访问来源标识和业务标识；

第一确定模块302，用于根据访问来源标识和获取的对应关系表，从多个线程池中确定出目标线程池；对应关系表包括多个访问来源标识与多个线程池的对应关系；

获取模块303，用于基于目标线程池从常用数据分库中获取预设路由规则；其中，预设路由规则包括多个访问来源与多个分库的对应关系；多个分库的每个分库用于存储预设时间范围多个访问来源产生的数据；常用数据分库用于根据预设频率从多个分库中获取多个常用数据表；

第二确定模块304，用于根据访问来源标识和预设路由规则确定目标分库；

发送模块305，用于向目标分库发送数据库操作请求，以从目标分库中获取业务标识对应的数据。

在一种可选的实施方式中，业务标识包括第一业务标识或第二业务标识；目标分库包括两个第一业务库和两个第二业务库；两个第一业务库互为备份；两个第二业务库互为备份；发送模块305，具体用于：

向两个第一业务库中任一个第一业务库发送数据库操作请求；数据库操作请求的业务标识为第一业务标识；或；向两个第二业务库中任一个第二业务库发送数据库操作请求；数据库操作请求的业务标识为第二业务标识。

在一种可选的实施方式中，多个分库包括常用数据分库配置信息表；获取模块303具体用于：

获取常用数据分库配置信息表的状态；若常用数据分库配置信息表的状态为正常状态，则执行步骤：基于目标线程池从常用数据分库中获取预设路由规则。

在一种可选的实施方式中，发送模块305具体用于：

若常用数据分库配置信息表的状态为异常状态，则基于目标线程池向第一预设目标分库发送数据库操作请求，以从第一预设目标分库中获取业务标识对应的数据。

本申请实施例中的装置与方法实施例基于同样地申请构思。

需要说明的是：上述本申请实施例先后顺序仅仅为了描述，不代表实施例的优劣。且上述对本说明书特定实施例进行了描述。其它实施例在所附权利要求书的范围内。在一些情况下，在权利要求书中记载的动作或步骤可以按照不同于实施例中的顺序来执行并且仍然可以实现期望的结果。另外，在附图中描绘的过程不一定要求示出的特定顺序或者连续顺序才能实现期望的结果。在某些实施方式中，多任务处理和并行处理也是可以的或者可能是有利的。

本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于设备实施例而言，由于其基本相似于方法实施例，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。

本领域普通技术人员可以理解实现上述实施例的全部或部分步骤可以通过硬件来完成，也可以通过程序来指令相关的硬件完成，所述的程序可以存储于一种计算机可读存储介质中，上述提到的存储介质可以是只读存储器，磁盘或光盘等。

以上所述仅为本申请的较佳实施例，并不用以限制本申请，凡在本申请的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本申请的保护范围之内。

Claims (10)

1.一种基于数据库的操作请求处理方法，其特征在于，包括：

接收数据库操作请求；所述数据库操作请求包括访问来源标识和业务标识；

根据所述访问来源标识和获取的对应关系表，从多个线程池中确定出目标线程池；所述对应关系表包括多个访问来源标识与多个线程池的对应关系；

基于所述目标线程池从常用数据分库中获取预设路由规则；其中，所述预设路由规则包括多个访问来源与多个分库的对应关系；所述多个分库的每个分库用于存储预设时间范围所述多个访问来源产生的数据；所述常用数据分库用于根据预设频率从所述多个分库中获取多个常用数据表；

根据所述访问来源标识和所述预设路由规则确定目标分库；

向所述目标分库发送所述数据库操作请求，以从所述目标分库中获取所述业务标识对应的数据。

2.根据权利要求1所述的方法，其特征在于，所述业务标识包括第一业务标识或第二业务标识；所述目标分库包括两个第一业务库和两个第二业务库；所述两个第一业务库互为备份；所述两个第二业务库互为备份；

所述向所述目标分库发送所述数据库操作请求，包括：

向所述两个第一业务库中任一个第一业务库发送所述数据库操作请求；所述数据库操作请求的业务标识为所述第一业务标识；或；向所述两个第二业务库中任一个第二业务库发送所述数据库操作请求；所述数据库操作请求的业务标识为所述第二业务标识。

3.根据权利要求1所述的方法，其特征在于，所述多个分库包括常用数据分库配置信息表；

所述从多个线程池中确定出目标线程池之后，还包括：

获取所述常用数据分库配置信息表的状态；

若所述常用数据分库配置信息表的状态为正常状态，则执行步骤：基于所述目标线程池从常用数据分库中获取预设路由规则。

4.根据权利要求3所述的方法，其特征在于，

若所述常用数据分库配置信息表的状态为异常状态，则基于所述目标线程池向第一预设目标分库发送所述数据库操作请求，以从所述第一预设目标分库中获取所述业务标识对应的数据。

5.根据权利要求2所述的方法，其特征在于，所述常用数据分库还包括数据维护规则；所述数据维护规则包括所述多个分库的数据维护顺序；所述业务标识还包括第三业务标识；

所述从多个线程池中确定出目标线程池之后，还包括：

判断所述业务标识的种类；

若所述业务标识的种类为所述第三业务标识，则基于所述目标线程池向第二预设目标分库发送所述数据库操作请求；

若获取到所述第二预设目标分库数据维护成功信号，则向第三预设目标分库发送所述数据库操作请求。

6.根据权利要求1所述的方法，其特征在于，所述根据所述访问来源标识和获取的对应关系表，从多个线程池中确定出目标线程池，包括：

根据所述访问来源标识，从所述对应关系表中，确定出所述访问来源标识对应的线程池，将所述访问来源标识对应的线程池作为所述目标线程池。

7.一种基于数据库的操作请求处理装置，其特征在于，包括：

接收模块，用于接收数据库操作请求；所述数据库操作请求包括访问来源标识和业务标识；

第一确定模块，用于根据所述访问来源标识和获取的对应关系表，从多个线程池中确定出目标线程池；所述对应关系表包括多个访问来源标识与多个线程池的对应关系；

获取模块，用于基于所述目标线程池从常用数据分库中获取预设路由规则；其中，所述预设路由规则包括多个访问来源与多个分库的对应关系；所述多个分库的每个分库用于存储预设时间范围所述多个访问来源产生的数据；所述常用数据分库用于根据预设频率从所述多个分库中获取多个常用数据表；

第二确定模块，用于根据所述访问来源标识和所述预设路由规则确定目标分库；

发送模块，用于向所述目标分库发送所述数据库操作请求，以从所述目标分库中获取所述业务标识对应的数据。

8.根据权利要求7所述的装置，其特征在于，所述业务标识包括第一业务标识或第二业务标识；所述目标分库包括两个第一业务库和两个第二业务库；所述两个第一业务库互为备份；所述两个第二业务库互为备份；

所述发送模块，用于向所述两个第一业务库中任一个第一业务库发送所述数据库操作请求；所述数据库操作请求的业务标识为所述第一业务标识；或；向所述两个第二业务库中任一个第二业务库发送所述数据库操作请求；所述数据库操作请求的业务标识为所述第二业务标识。

9.根据权利要求7所述的装置，其特征在于，所述多个分库包括常用数据分库配置信息表；

所述获取模块，还用于获取所述常用数据分库配置信息表的状态；若所述常用数据分库配置信息表的状态为正常状态，则执行步骤：基于所述目标线程池从常用数据分库中获取预设路由规则。

10.根据权利要求7所述的装置，其特征在于，所述发送模块，还用于若所述常用数据分库配置信息表的状态为异常状态，则基于所述目标线程池向第一预设目标分库发送所述数据库操作请求，以从所述第一预设目标分库中获取所述业务标识对应的数据。

Images