CN113127102A

CN113127102A - 业务数据的处理方法、装置、设备、存储介质及程序

Info

Publication number: CN113127102A
Application number: CN202110542242.3A
Authority: CN
Inventors: 陈金康; 姚沛津; 严沛权; 余剑斌
Original assignee: Agricultural Bank of China
Current assignee: Agricultural Bank of China
Priority date: 2021-05-18
Filing date: 2021-05-18
Publication date: 2021-07-16

Abstract

本申请提供一种业务数据的处理方法、装置、设备、存储介质及程序，当接收到业务请求时，可以根据业务请求确定出目标路由标识，并根据目标路由标识确定出目标数据库的连接信息，事务管理器可以根据目标数据库的连接信息切换连接至该目标数据库，并在目标数据库中对目标业务数据进行处理。由此可见，在业务***部署有多个数据库的场景下，可以根据接收到的不同业务请求，将事务管理器切换连接至不同的数据库，从而实现多个数据库共用一个事务管理器，而无需为每个数据库分别配置事务管理器，降低配置复杂度。

Description

业务数据的处理方法、装置、设备、存储介质及程序

技术领域

本申请涉及数据处理技术领域，尤其涉及一种业务数据的处理方法、装置、设备、存储介质及程序。

背景技术

数据库是指按照数据结构来组织、存储和管理数据的仓库。数据源是指数据的来源，一个数据源对应一个数据库，数据源中记录了连接该数据库所需的信息。通过为业务***配置数据源，可以使业务***知道连接哪个数据库以及如何连接。目前，很多业务***支持部署多个数据库。

相关技术中，当业务***部署有多个数据库时，需要为每个数据库配置一个事务管理器。通过在代码中添加注解的方式为每个事务管理器显式指定数据源。举例而言，以部署有两个数据库为例，为数据库1分配事务管理器1，事务管理器1指定数据源1，为数据库2分配事务管理器2，事务管理器2指定数据源2。当接收到业务类型1的业务请求时，通过事务管理器1连接至数据源1对应的数据库(即数据库1)，并在数据库1中进行事务内业务操作。当接收到业务类型2的业务请求时，通过事务管理器2连接至数据源2对应的数据库(即数据库2)，并在数据库2中进行事务内业务操作。也就是说，通过为不同的数据库分配不同的事务管理器，利用不同的事务管理器实现对不同数据库的事务操作。

然而，上述方式需要配置多个事务管理器，配置复杂度较高。

发明内容

本申请提供一种业务数据的处理方法、装置、设备、存储介质及程序，用以降低业务***的配置复杂度。

第一方面，本申请提供一种业务数据的处理方法，应用于业务***，所述业务***部署有多个数据库以及用于对所述多个数据库进行事务操作的事务管理器，所述方法包括：

获取业务请求，所述业务请求用于请求对目标业务数据进行处理；

根据所述业务请求，确定出目标路由标识，所述目标路由标识对应的路由用于路由至目标数据库，所述目标数据库为所述多个数据库中与所述目标业务数据对应的数据库；

根据所述目标路由标识，确定所述目标数据库的连接信息；

通过所述事务管理器根据所述目标数据库的连接信息连接所述目标数据库，并在所述目标数据库中对所述目标业务数据进行处理。

一种可能的实现方式中，根据所述业务请求，确定出目标路由标识，包括：

获取所述业务***对应的数据源切换策略；

根据所述数据源切换策略，对所述业务请求进行解析处理，得到路由指示信息；

根据所述路由指示信息，确定出所述目标路由标识。

一种可能的实现方式中，根据所述路由指示信息，确定出所述目标路由标识，包括：

获取不同路由指示信息与不同路由标识之间的映射关系；

根据所述映射关系对所述路由指示信息进行映射处理，得到所述目标路由标识。

一种可能的实现方式中，所述业务***对应的数据源切换策略的数量有多个；根据所述数据源切换策略，对所述业务请求进行解析处理，得到路由指示信息，包括：

针对每个数据源切换策略，获取该数据源切换策略对应的解析方式，并采用所述解析方式对所述业务请求进行解析处理，得到该数据源切换策略对应的路由指示信息；

根据所述路由指示信息，确定出所述目标路由标识，包括：

根据所述多个数据源切换策略各自对应的路由指示信息，确定出所述目标路由标识。

一种可能的实现方式中，根据所述目标路由标识，确定所述目标数据库的连接信息，包括：

获取数据源路由信息集合，所述数据源路由信息集合包括多个路由标识和每个路由标识对应的数据库的连接信息；

将所述数据源路由信息集合中与所述目标路由标识对应的数据库的连接信息，确定为所述目标数据库的连接信息。

一种可能的实现方式中，获取数据源路由信息集合之前，所述方法还包括：

在接收到所述业务***的启动指令时，获取第一配置文件，所述第一配置文件中包括多个路由的配置信息；

根据所述第一配置文件，获取每个路由的路由标识和每个路由对应的数据库的连接信息；

根据所述多个路由的路由标识和所述多个路由各自对应的数据库的连接信息，生成所述数据源路由信息集合。

一种可能的实现方式中，根据所述第一配置文件，获取每个路由的路由标识和每个路由对应的数据库的连接信息，包括：

确定该路由对应的数据库的连接方式为第一连接方式或者第二连接方式；

若该路由对应的数据库的连接方式为第一连接方式，则从所述第一配置文件中获取该路由的路由标识以及该路由对应的数据库的引用名称，并根据所述引用名称从第二配置文件中获取该路由对应的数据库的连接信息；或者，

若该路由对应的数据库的连接方式为第二连接方式，则从所述第一配置文件中获取该路由的路由标识以及该路由对应的数据库的连接信息。

第二方面，本申请提供一种业务数据的处理装置，应用于业务***，所述业务***部署有多个数据库以及用于对所述多个数据库进行事务操作的事务管理器，所述装置包括：

获取模块，用于获取业务请求，所述业务请求用于请求对目标业务数据进行处理；

第一确定模块，用于根据所述业务请求，确定出目标路由标识，所述目标路由标识对应的路由用于路由至目标数据库，所述目标数据库为所述多个数据库中与所述目标业务数据对应的数据库；

第二确定模块，用于根据所述目标路由标识，确定所述目标数据库的连接信息；

处理模块，用于通过所述事务管理器根据所述目标数据库的连接信息连接所述目标数据库，并在所述目标数据库中对所述目标业务数据进行处理。

一种可能的实现方式中，所述第一确定模块具体用于：

获取所述业务***对应的数据源切换策略；

根据所述路由指示信息，确定出所述目标路由标识。

一种可能的实现方式中，所述第一确定模块具体用于：

获取不同路由指示信息与不同路由标识之间的映射关系；

一种可能的实现方式中，所述业务***对应的数据源切换策略的数量有多个；所述第一确定模块具体用于：

一种可能的实现方式中，所述第二确定模块具体用于：

一种可能的实现方式中，所述装置还包括生成模块，所述生成模块用于：

一种可能的实现方式中，所述生成模块具体用于：

第三方面，本申请提供一种电子设备，包括：存储器和处理器，所述存储器用于存储计算机程序，所述处理器运行所述计算机程序实现如第一方面任一项所述的方法。

第四方面，本申请提供一种计算机可读存储介质，包括：计算机程序，所述计算机程序被处理器执行时实现如第一方面任一项所述的方法。

第五方面，本申请提供一种计算机程序产品，包括：计算机程序，所述计算机程序被处理器执行时实现如第一方面任一项所述的方法。

本申请提供的业务数据的处理方法、装置、设备、存储介质及程序，当接收到业务请求时，可以根据业务请求确定出目标路由标识，并根据目标路由标识确定出目标数据库的连接信息，事务管理器可以根据目标数据库的连接信息切换连接至该目标数据库，并在目标数据库中对目标业务数据进行处理。由此可见，在业务***部署有多个数据库的场景下，可以根据接收到的不同业务请求，将事务管理器切换连接至不同的数据库，从而实现多个数据库共用一个事务管理器，而无需为每个数据库分别配置事务管理器，降低配置复杂度。

附图说明

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

图1为本申请实施例所涉及的业务***的***架构示意图；

图2为相关技术中的基于多数据源的业务***的示意图；

图3为基于图2所示的业务***的数据处理过程示意图；

图4为本申请实施例提供的基于多数据源的业务***的示意图；

图5为本申请实施例提供的一种业务数据的处理方法的流程示意图；

图6为本申请实施例提供的一种数据源路由信息集合的生成方法的流程示意图；

图7为本申请实施例提供的一种业务数据处理过程的示意图；

图8为本申请实施例提供的另一种业务数据处理过程的示意图；

图9为本申请实施例提供的又一种业务数据处理过程的示意图；

图10为本申请实施例提供的又一种业务数据处理过程的示意图；

图11为本申请实施例提供的一种业务数据的处理装置的结构示意图；

图12为本申请实施例提供的一种电子设备的结构示意图。

具体实施方式

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

本申请的说明书和权利要求书及上述附图中的术语“第一”、“第二”、“第三”“第四”等(如果存在)是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、***、产品或设备不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。

首先，对本申请实施例中涉及的专业术语或者概念进行解释说明。

数据源：指数据库应用程序所使用的数据库。

多数据源：就是多个数据库，一个应用可配置多个数据库，比如数据库A是应用的联机库，数据库B是应用的批量库。

动态数据源：多个数据源的集合，对外看来就是一个独立的数据源，可以动态地切换至数据源集合的其中一个，但同一时刻只有一个数据源生效，也就是事务只能有一个生效。

MyBatis：MyBatis是一款优秀的持久层框架，它支持自定义SQL、存储过程以及高级映射。MyBatis免除了几乎所有的JDBC代码以及设置参数和获取结果集的工作。MyBatis可以通过简单的XML或注解来配置和映射原始类型、接口和Java POJO(Plain Old JavaObjects，普通老式Java对象)为数据库中的记录。

MyBatis-Plus：简称MP，是一个MyBatis的增强工具，在MyBatis的基础上只做增强不做改变，为简化开发、提高效率而生。

Sql会话工厂(SqlSessionFactory)：是MyBatis的关键对象，它是个单个数据库映射关系经过编译后的内存镜像。SqlSessionFactory对象的实例可以通过SqlSessionFactoryBuilder对象类获得，而SqlSessionFactoryBuilder则可以从XML配置文件或一个预先定制的Configuration的实例构建出SqlSessionFactory的实例。每一个MyBatis的应用程序都以一个SqlSessionFactory对象的实例为核心。同时SqlSessionFactory也是线程安全的，SqlSessionFactory一旦被创建，应该在应用执行期间都存在。在应用运行期间不要重复创建多次，建议使用单例模式。SqlSessionFactory是创建SqlSession的工厂。

Spring：Spring是Java企业版(Java Enterprise Edition，JEE，也称J2EE)的轻量级代替品。无需开发重量级的EnterpriseJavaBean(EJB)，Spring为企业级Java开发提供了一种相对简单的方法，通过依赖注入(IOC)和面向切面(AOP)编程，用简单的Java对象(Plain Old Java Object，POJO)实现了EJB的功能。

面向切面编程(Aspect Oriented Programming，AOP)，可以说是面向对象编程(Object Oriented Programming，OOP)的补充和完善。它利用一种称为"横切"的技术，剖解开封装的对象内部，并将那些影响了多个类的公共行为封装到一个可重用模块，并将其命名为"Aspect"，即切面。所谓"切面"，简单说就是那些与业务无关，却为业务模块所共同调用的逻辑或责任封装起来，便于减少***的重复代码，降低模块之间的耦合度，并有利于未来的可操作性和可维护性。

SpringBoot：SpringBoot是Spring实现自动配置，降低项目搭建复杂度的一套完整的方案。SpringBoot本身并不提供Spring框架的核心特性以及扩展功能，只是用于快速、敏捷地开发新一代基于Spring框架的应用程序。也就是说，它并不是用来替代Spring的解决方案，而是和Spring框架紧密结合用于提升Spring开发者体验的工具。SpringBoot基于约定优于配置的思想，可以让开发人员不必在配置与逻辑业务之间进行思维的切换，全身心的投入到逻辑业务的代码编写中，从而大大提高了开发的效率，一定程度上缩短了项目周期。

为了便于理解，下面结合图1对本申请实施例涉及的业务***的***架构进行介绍。

图1为本申请实施例所涉及的业务***的***架构示意图。如图1所示，本实施例提供的业务***中，部署有服务器/服务器集群、以及多个数据库。服务器/服务器集群可以对上述多个数据库中的业务数据进行处理。例如，服务器/服务器集群可以向各数据库中新增业务数据、修改业务数据、删除业务数据等。

需要说明的是，本实施例的业务***可应用于多种应用场景中，包括但不限于：银行业务场景、金融业务场景、电商业务场景、社交业务场景等。为了便于理解，后续涉及举例时，以银行业务场景为例进行描述。

一些示例性的场景中，上述多个数据库可以采用垂直分库的方式。垂直分库是指以表为依据，按照业务归属不同，将一个数据库中的数据表拆分到多个数据库中，拆分后的每个数据库的结构不同，并且不同数据库中的数据也不同。举例而言，假设业务***产生了如下数据表：用户数据表、贷款业务数据表、理财业务数据表等。在垂直分库方式中，可以将用户数据表存储到数据库1中，将贷款业务数据表存储到数据库2中，将理财业务数据表存储到数据库3中。

另一些示例性的场景中，上述多个数据库可以采用水平分库的方式。水平分库方式是指以字段为依据，按照一定策略将一个数据库中的数据拆分到多个数据库中，拆分后的每个数据库的结构相同，不同数据库中的数据不同。

举例而言，一家银行通常在全球各个区域设置分行。不同区域的监管部门对于数据的独立性有不同的监管要求。例如，有些区域明确指出，在本区域产生的业务数据与其他区域产生的业务数据不允许部署在相同的数据库中。因此，在数据库部署时，需要考虑不同区域的数据隔离要求。因此，可以按照业务数据产生的区域不同，将区域1产生的业务数据存储到数据库1中，将区域2产生的业务数据存储到数据库2中，将区域3产生的业务数据存储到数据库3中。

又一些示例性的场景中，上述多个数据库可以混合采用垂直分库和水平分库方式。举例而言，数据库1可以存储区域1产生的用户数据表，数据库2可以存储区域1产生的贷款业务数据表，数据库3可以存储区域1产生的理财业务数据表，数据库4可以产生区域2产生的用户数据表，数据库5可以存储区域2产生的贷款业务数据表，数据库6可以存储区域2产生的理财业务数据表，数据库7可以产生区域3产生的用户数据表，数据库8可以存储区域3产生的贷款业务数据表，数据库9可以存储区域3产生的理财业务数据表。

数据源是指数据的来源。一个数据源即对应一个数据库，数据源中记录了连接该数据库所需的信息。通过为业务***配置数据源，可以使业务***知道连接哪个数据库以及如何连接。目前，很多业务***可支持配置多个数据源。

相关技术中，当业务***支持部署多个数据库时，需要为每个数据库配置一个事务管理器。图2为相关技术中的基于多数据源的业务***的示意图。图2中以基于SpringBoot的MyBatis-Plus框架为例进行举例说明。如图2所示，针对每个数据库分别配置一个事务管理器以及SqlSessionFactory。

进一步的，在每个事务管理器的业务处理代码中，支持配置默认数据源，也可以通过@DS注解指定特定数据源。示例性的，将@DS注解添加在service实现上，也就是说，Mybatis-Plus只支持在单Service方法内操作一个数据源对应的数据库。举例而言，若某个业务处理方法没有添加@DS注解，则执行该业务处理方法时操作默认数据源对应的数据库。若某个业务处理方法添加了注解：@DS("dsName")，其中dsName可以为某个数据源，则执行该业务处理方法时操作dsName对应的数据库。

当接收到某个业务类型的业务请求时，可以通过该业务类型对应的事务管理器根据代码注解所指定的数据源，连接至相应的数据库。图3为基于图2所示的业务***的数据处理过程示意图。如图3所示，若业务处理代码中的注解为@DS(“数据源1”)，则选择连接至数据源1对应的数据库，若业务处理代码中的注解为@DS(“数据源2”)，则选择连接至数据源2对应的数据库，以此类推。然后，在相应的数据库中进行事务内业务操作。也就是说，通过为不同的数据库分配不同的事务管理器，利用不同的事务管理器实现对不同数据库的事务操作。

然而，发明人在实现本申请的过程中，发现上述相关技术至少存在如下技术问题：

(1)上述方式需要为每个数据库分别配置事务管理器以及SqlSessionFactory。当业务***部署有多个数据库时，需要配置多个事务管理器以及多个SqlSessionFactory，使得配置复杂度较高。

(2)上述方式在代码层面限定了事务管理器与数据库之间的绑定关系，使得一个业务处理方法仅支持操作一个数据库，因此，上述相关技术通常只能用于垂直分库的场景中，而无法用于水平分库的场景中。因为在水平分库的场景中，不同数据库中的数据表结构是相同的，不同数据库的业务处理逻辑也是相同的，希望采用一套代码实现多个数据库的业务处理过程，而上述相关技术中一个业务处理方法仅支持操作指定的数据库，因此，无法满足水平分库的数据处理需求。

(3)上述方式需要在业务处理代码中添加注解以指定数据源，导致对业务代码的侵入性较高。业务开发人员在实现业务处理逻辑时，还需要考虑数据源的切换功能，导致数据源切换功能与业务处理逻辑的耦合性较高。

为了解决上述技术问题中的至少一个，本申请实施例提供一种业务数据的处理方法，下面结合图4对本申请的发明构思进行介绍。

图4为本申请实施例提供的基于多数据源的业务***的示意图。如图4所示，业务***中部署有多个数据库，多个数据库共用一个事务管理器和一个SqlSessionFactory。在接收到业务请求时，可以根据业务请求确定出目标路由标识，并根据目标路由标识确定出目标数据库的连接信息，事务管理器根据目标数据库的连接信息连接至目标数据库，并在目标数据库中对目标业务数据进行处理。

可见，本申请中，事务管理器可以根据当前业务请求动态切换连接至不同数据库，从而只需要为业务***配置一个事务管理器即可，降低配置复杂度。相应的，不需要在业务处理代码中添加注解来指定数据源，降低对业务代码的侵入性，从而业务开发人员在实现业务处理逻辑时，不需要考虑数据源的切换功能，使得数据源切换功能与业务处理逻辑解耦。进一步的，本申请方案既可应用于垂直分库场景，也可应用于水平分库场景，还可应用于垂直分库和水平分库混用的场景，提高了应用场景的灵活性。

下面以具体地实施例对本申请的技术方案进行详细说明。下面这几个具体的实施例可以相互结合，对于相同或相似的概念或过程可能在某些实施例不再赘述。

图5为本申请实施例提供的一种业务数据的处理方法的流程示意图。本实施例可由图4中的服务器/服务器集群执行。

如图5所示，本实施例的方法，包括：

S501：获取业务请求，所述业务请求用于请求对目标业务数据进行处理。

具体的，终端设备需要对目标业务数据进行处理时，向服务器/服务器集群发送业务请求，以请求服务器/服务器集群对目标业务数据进行处理。

其中，目标业务数据可以是业务***中的任意一个数据库中的数据。也就是说，业务请求可以是请求在业务***的任意一个数据库中对目标业务数据进行处理。

示例性的，业务请求可用于请求增加目标业务数据、删除目标业务数据、或者修改目标业务数据。

S502：根据所述业务请求，确定出目标路由标识，所述目标路由标识对应的路由用于路由至目标数据库，所述目标数据库为所述多个数据库中与所述目标业务数据对应的数据库。

本实施例中，根据业务请求可以确定出需要对哪个数据库中的目标业务数据进行处理。本实施例中，将需要对目标业务数据进行处理的数据库称为目标数据库。目标数据库可以是多个数据库中的任意一个。

可选的，业务请求中可以包括目标路由标识。示例性的，业务请求中可以包括第一字段，第一字段的取值即为目标路由标识。这样，根据业务请求中的第一字段的取值即可确定出目标路由标识。例如，在银行业务场景中，第一字段可以为分行标识字段、业务类型字段、渠道类型字段、区域标识字段等。

可选的，业务请求中可以包括路由指示信息。不同路由指示信息与不同路由标识之间具有某种映射关系。这样，通过对业务请求中的路由指示信息进行映射处理，即可确定出目标路由标识。

本实施例的业务***中部署有多个数据源，可以根据接收到的不同业务请求，切换至不同的数据源。实际应用中，可以根据实际应用场景的需求，采用一种或者多种数据源切换策略。以银行业务场景为例，可采用的数据源切换策略包括但不限于：根据分行标识切换数据源、根据区域标识切换数据源、根据业务类型切换数据源、根据渠道类型切换数据源。

一种可能的实现方式中，可以采用如下可行的方式根据业务请求确定出目标路由标识：获取业务***对应的数据源切换策略，根据所述数据源切换策略，对业务请求进行解析处理，得到路由指示信息，并根据路由指示信息，确定出目标路由标识。

可选的，可以获取不同路由指示信息与不同路由标识之间的映射关系，根据所述映射关系对路由指示信息进行映射处理，确定出目标路由标识。

当采用不同的数据源切换策略时，业务请求中携带的路由指示信息可以不同，相应的，对业务请求的解析方式也可能不同。下面结合几个具体的示例进行举例说明。

一个示例中，假设采用的数据源切换策略为根据分行标识切换数据源，即，不同分行的业务数据存储在不同的数据库中。该示例中，业务请求中可以携带分行标识，分行标识作为路由指示信息。那么，可以从业务请求中解析得到分行标识，进而，根据分行与数据库之间的映射关系，对分行标识进行映射处理，可以得到目标路由标识。

另一个示例中，假设采用的数据源切换策略为根据区域标识切换数据源，即，不同区域的业务数据存储在不同的数据库中。该示例中，业务请求中可以携带区域标识，区域标识作为路由指示信息。那么，可以从业请求中解析得到区域标识，进而，根据区域与数据库之间的映射关系，对区域标识进行映射处理，可以得到目标路由标识。

又一个示例中，假设采用的数据源切换策略为根据业务类型切换数据源，即，不同业务类型的业务数据存储在不同的数据库中。该示例中，业务请求中可以携带业务类型，业务类型作为路由指示信息。那么，可以从业务请求中解析得到业务类型，进而根据业务类型与数据库之间的映射关系，对业务类型进行映射处理，可以得到目标路由标识。

再一个示例中，假设采用的数据源切换策略为根据渠道类型切换数据源，即，不同渠道类型的业务数据存储在不同的数据库中。该示例中，业务请求中可以携带渠道类型，渠道类型作为路由指示信息。那么，可以从业务请求中解析得到渠道类型，进而根据渠道类型与数据库之间的映射关系，对渠道类型进行映射处理，可以得到目标路由标识。

一些可能的场景中，业务***对应的数据源切换策略的数量可能有多种。例如，业务***采用的数据源切换策略为根据分行标识+业务类型切换数据源，该情况下，业务请求中可以同时携带分行标识和业务类型。

可选的，当业务***对应的数据源切换策略的数量有多个时，可以针对每个数据源切换策略，获取该数据源切换策略对应的解析方式，并采用该解析方式对业务请求进行解析处理，得到该数据源切换策略对应的路由指示信息。进一步的，根据所述多个数据源切换策略各自对应的路由指示信息，确定出目标路由标识。

可选的，可以对所述多个数据源切换策略各自对应的路由指示信息进行拼接处理，得到目标路由标识。

举例而言，假设业务***采用的数据源切换策略为根据分行标识+业务类型切换数据源。从业务请求中解析得到的一个路由指示信息(分行标识)为“HK”，从业务请求中解析得到的另一个路由指示信息(业务类型)为业务类型A，则可以确定出目标路由标识为“HK_A”。对多个路由指示信息的拼接方式仅为示意，实际应用中，可以根据路由标识的命名规则，对多个路由指示信息进行拼接处理。

S503：根据所述目标路由标识，确定所述目标数据库的连接信息。

其中，一个数据库的连接信息是指事物管理器连接该数据库所需要的信息。例如，一个数据库的连接信息可以包括该数据库对应的互联网协议地址(Internet ProtocolAddress，IP)地址、端口号、连接账号、连接密码等信息。

路由标识和数据库的连接信息之间具有对应关系，因此，根据目标路由标识，可以确定出目标数据库的连接信息。

一种可能的实现方式中，可以采用如下方式确定出目标数据库的连接信息：获取数据源路由信息集合，所述数据源路由信息集合包括多个路由标识和每个路由标识对应的数据库的连接信息；将所述数据源路由信息集合中与所述目标路由标识对应的数据库的连接信息，确定为所述目标数据库的连接信息。

S504：通过所述事务管理器根据所述目标数据库的连接信息连接所述目标数据库，并在所述目标数据库中对所述目标业务数据进行处理。

本实施例中，确定出目标数据库的连接信息之后，可以通过事务管理器根据目标数据库的连接信息连接目标数据库，并在目标数据库中对目标业务数据进行处理。

举例而言，以银行业务***为例，假设银行包括3个分行，分行1的业务数据存储在数据库1中，分行2的业务数据存储在数据库2中，分行3的业务数据存储在数据库3中。

一个示例中，假设业务***接收到业务请求1，采用本实施例的方案，通过对业务请求1进行解析处理，得到分行标识1，从而确定出目标路由为路由1。然后，通过查询数据源路由信息集合，可以得到路由1对应的数据库1的连接信息。进而，事务管理器根据数据库1的连接信息连接至数据库1，并对数据库1中的目标业务数据进行处理。

另一个示例中，假设业务***接收到业务请求2，采用本实施例的方案，通过对业务请求2进行解析处理，得到分行标识2，从而确定出目标路由为路由2。然后，通过查询数据源路由信息集合，可以得到路由2对应的数据库2的连接信息。进而，事务管理器根据数据库2的连接信息连接至数据库2，并对数据库2中的目标业务数据进行处理。

又一个示例中，假设业务***接收到业务请求3，采用本实施例的方案，通过对业务请求3进行解析处理，得到分行标识3，从而确定出目标路由为路由3。然后，通过查询数据源路由信息集合，可以得到路由3对应的数据库3的连接信息。进而，事务管理器根据数据库3的连接信息连接至数据库3，并对数据库3中的目标业务数据进行处理。

本实施例提供的业务数据的处理方法中，当接收到业务请求时，可以根据业务请求确定出目标路由标识，并根据目标路由标识确定出目标数据库的连接信息，事务管理器可以根据目标数据库的连接信息切换连接至该目标数据库，并在目标数据库中对目标业务数据进行处理。由此可见，在业务***部署有多个数据库的场景下，可以根据接收到的不同业务请求，将事务管理器切换连接至不同的数据库，从而实现多个数据库共用一个事务管理器，而无需为每个数据库分别配置事务管理器，降低配置复杂度。

进一步的，由于多个数据库可以共用一个事务管理器，避免了在业务处理代码中添加注解来指定数据源，降低对业务代码的侵入性，从而业务开发人员在实现业务处理逻辑时，不需要考虑数据源的切换功能，使得数据源切换功能与业务处理逻辑解耦。

更进一步的，由于本实施例可以根据接收到的不同业务请求，将事务管理器切换连接至不同的数据库，实现了事务管理器在多个数据库之间的灵活切换，避免了在业务处理代码中指定数据源，因此，本实施例既可应用于垂直分库场景，也可应用于水平分库场景，还可应用于垂直分库和水平分库混用的场景，提高了应用灵活性。

上述实施例中，在确定出目标路由标识的情况下，可以根据数据源路由信息集合确定出目标数据库的连接信息。下面结合一个具体的实施例描述数据源路由信息集合的生成过程。

图6为本申请实施例提供的一种数据源路由信息集合的生成方法的流程示意图。如图6所示，本实施例的方法，包括：

S601：在接收到所述业务***的启动指令时，获取第一配置文件，所述第一配置文件中包括多个路由的配置信息。

S602：根据所述第一配置文件，获取每个路由的路由标识和每个路由对应的数据库的连接信息。

S603：根据所述多个路由的路由标识和所述多个路由各自对应的数据库的连接信息，生成所述数据源路由信息集合。

本实施例中，第一配置文件用于记录各个路由的配置信息。一个路由对应一个数据库的连接路径。当第一配置文件发生变更的情况下，例如，新增、修改或者删除数据源的情况下，需要对数据源路由信息集合进行更新，因此可以重新启动业务***。在业务***启动初始化过程中，根据第一数据配置文件获取每个路由的路由标识和每个路由对应的数据库的连接信息。进而，根据所述多个路由的路由标识和所述多个路由各自对应的数据库的连接信息，生成所述数据源路由信息集合。

一种可能的实现方式中，针对第一配置文件中配置的每个路由，可以先确定出该路由对应的数据库的连接方式为第一连接方式或者第二连接方式。示例性的，以Java为例，第一连接方式可以为Java命名与目录接口(Java Naming and Directory Interface，JNDI)连接方式，第二连接方式可以为Druid连接方式。当某个数据库采用JNDI连接方式时，只需要在第一配置文件中记录该数据库的引用名称，而将该数据库的连接信息记录到第二配置文件中。当需要获取该数据库的连接信息时，可以根据第一配置文件中的引用名称访问第二配置文件获取。当某个数据库采用Druid连接方式时，可以在第一配置文件中记录该数据库的连接信息。

因此，可以采用如下可行的方式获取每个路由的路由标识以及该路由对应的数据库的连接信息。

可选的，若该路由对应的数据库的连接方式为JNDI连接方式，则从第一配置文件中获取该路由的路由标识以及该路由对应的数据库的引用名称，并根据所述引用名称从第二配置文件中获取该路由对应的数据库的连接信息。

可选的，若该路由对应的数据库的连接方式为Druid连接方式，则从第一配置文件中获取该路由的路由标识以及该路由对应的数据库的连接信息。

本实施例中，业务***中部署的多个数据库，既支持为同类型的数据库，也可以是不同类型的数据库，比如mysql、oracle、sybase等。因为Druid支持mysql、oracle、sybase等，JNDI也支持mysql、oracle、sybase等。

在上述实施例的基础上，下面以Spring为例，对本申请技术方案的实现过程进行举例说明。

图7为本申请实施例提供的一种业务数据处理过程的示意图。如图7所示，业务***部署有数据源路由信息集合生成器、路由标识解析器、路由标识持有器、事务管理器和数据源路由信息集合。

其中，数据源路由信息集合生成器可以在业务***启动过程中，获取第一配置文件，并根据第一配置文件生成数据源路由信息集合。数据源路由信息集合包括多个路由标识以及每个路由标识对应的数据库的连接信息。

第一配置文件中记录有多个路由的配置信息。每个路由用于路由到业务***中的一个数据库。每个路由的配置信息中包括该路由对应的路由标识以及该路由对应的数据库的相关信息。

在生成数据源路由信息集合时，数据源路由信息集合生成器针对每个路由，根据第一配置文件中该路由的配置项中是否存在jndi字段判断该路由对应的数据库的连接方式为JNDI连接方式，还是Druid连接方式。

如果该路由的配置项中存在jndi字段，则表示该路由对应的数据库为JNDI连接方式，并且，jndi字段的取值即为该路由对应的数据库的引用名称。该情况下，数据源路由信息集合生成器可以从第一配置文件中获取该路由的路由标识，并根据jndi字段的取值(即该路由对应的数据库的引用名称)从第二配置文件中查找对应数据库的连接信息。这样，根据该路由对应的路由标识以及该路由对应的数据库的连接信息，生成一个数据源。

如果该路由的配置项中不存在jndi字段，则表示该路由对应的数据库为Druid连接方式。该情况下，数据源路由信息集合生成器可以从第一配置文件中获取到该路由的路由标识以及该路由对应的数据库的连接信息。这样，根据该路由对应的路由标识以及该路由对应的数据库的连接信息，生成一个数据源。

一个示例中，当一个路由对应的数据库采用Druid连接方式时，第一配置文件中该路由的配置项如下所示：

spring.datasource.odf.multidatasource.default.url＝xxx

spring.datasource.odf.multidatasource.default.aliases＝xxx

spring.datasource.odf.multidatasource.default.username＝xxx

spring.datasource.odf.multidatasource.default.password＝xxx

当一个路由对应的数据库采用JNDI连接方式时，第一配置文件中该路由的配置项如下所示：

spring.datasource.odf.multidatasource.default.jndi＝xxx

其中，default为路由标识。

当某个路由既配置了JNDI连接方式，也配置了Druid连接方式，则数据源路由信息集合生成器可以优先选择JNDI连接方式。

通过上述设计，使得本申请方案既支持Druid连接方式，也支持JNDI连接方式，还支持Druid连接方式与JNDI连接方式混合配置。

可选的，第一配置文件中每个路由的配置项中可以包括别名(aliases)字段。举例而言，以银行业务场景为例，假设业务***按照区域部署，不同区域使用不同的数据库。假设区域A包括3家分行，分别为分行1、分行2和分行3，区域A中的3家分行使用相同的数据库。该情况下，在第一配置文件中可以只配置区域A中分行1对应的路由，并在该路由的别名字段中配置分行2和分行3的标识。这样，在生成数据源路由信息集合时，数据源路由信息集合生成器可以根据分行1的配置项生成分行1对应的数据源，并且，还可以根据分行1的别名字段，生成分行2和分行3对应的数据源。

这样，通过在第一配置文件中设置别名字段，减少了第一配置文件中的配置信息的数量，使得第一配置文件的配置过程更为优雅简单，也能很好地实现数据源分组管理。

继续参见图7，在接收到业务请求时，路由标识解析器可以对业务请求进行解析处理，得到路由指示信息，并根据路由指示信息确定出目标路由标识。路由标识解析器可以将目标路由标识设置到路由标识持有器中。

继续参见图7，路由标识持有器用于对路由标识k进行存储。路由标识持有器可以说是数据源切换的全局操控者和管理者，通过设置不同的路由标识，以实现动态的数据源切换。

继续参见图7，事务管理器在开启事务之前，会触发动态数据源。本实施例中自定义的动态数据源继承了Spring的AbstractRoutingDataSource，并重写determineCurrentLookupKey方法，该方法从路由标识持有器获取目标路由标识并返回。在***进行业务操作过程中，每次getConnection时，都会根据目标路由标识从数据源路由信息集合中查询到目标路由标识对应的数据库的连接信息，并根据该连接信息连接至相应数据库。进而，事务管理器开启事务，并进行事务内的业务操作。

通过图7所示的业务数据的处理过程，实现了数据源的动态切换。

在上述任意实施例的基础上，下面以银行业务场景为例，结合几个具体的示例对本申请技术方案进行举例说明。

图8为本申请实施例提供的另一种业务数据处理过程的示意图。本实施例以交易类业务***为例进行举例说明。本实施例中，不同分行的业务数据存储在不同数据库中，可以采用分行标识作为路由标识。

交易类业务***采用客户端-服务器(Client-Server，C/S)架构。如图8所示，服务器端接收客户端发送的业务请求，并对业务请求进行解析处理得到分行标识(即路由标识)。下面以分行标识1为例进行举例说明。假设分行标识为1，则将分行标识1存储到目标路由标识持有器中，并获取分行标识1对应的数据库的连接信息，进而根据该连接信息切换连接至该分行标识对应的数据库，并开启事务。然后，继续执行责任链节点，直至所有节点执行完毕之后，根据业务逻辑层执行成功与否提交或回滚数据源事务，清空当前数据源，最终形成一个动态数据源路由切换周期，循环反复，相互独立，互不干扰，互不影响。

本实施例中，在整个业务逻辑处理过程中，开发人员只需关注具体的业务处理逻辑，无需关注数据源切换，也就是说，数据源切换对业务是透明的。但需要注意的是，业务逻辑处理层在处理具体业务过程中，或者说在一个数据库事务中，不能再次切换数据源，即使切换，也没有效果，因为事务中会使用一开始获取到的数据库连接。

图9为本申请实施例提供的又一种业务数据处理过程的示意图。本实施例以管理类业务***为例进行举例说明。本实施例中，不同分行的业务数据存储在不同数据库中，可以采用分行标识作为路由标识。

管理类业务***采用浏览器/服务器(Browser/Server，B/S)架构。如图9所示，用户通过终端浏览器发送业务请求。服务器端通过Spring AOP环绕切面(该切面会拦截所有的RequestMapping请求)接收业务请求，并通过路由标识解析器对业务请求进行解析处理，得到分行标识(即路由标识)。将解析到的分行标识(即路由标识)存储到路由标识持有器中。Spring在获取数据库连接时，根据路由标识持有器中的分行标识(即路由标识)查询数据源路由信息集合，得到对应的数据库的连接信息，进而根据该连接信息连接至相应数据库，开启数据库事务。继续执行具体的控制层(controller)、业务逻辑层(service)及对象持久化层(mapper)步骤。上述步骤执行完毕之后，Spring AOP环绕切面会清空当前数据源，最终形成一个动态数据源路由切换周期，循环反复，相互独立，互不干扰，互不影响。

图8和图9所示实施例主要是针对水平分库场景进行描述。本申请提供的业务数据的处理方法，除了应用于水平分库的场景，还可以应用于垂直分库的场景。例如，根据交易类型进行分库，分为联机数据库和批量数据库的场景，或者，根据业务类型进行分库，分为业务类型A数据库、业务类型B数据库、业务类型C数据库的场景。下面结合图10进行举例说明。

图10为本申请实施例提供的又一种业务数据处理过程的示意图。如图10所示，业务***接收业务请求，通过路由标识解析器对业务请求进行解析处理，得到业务类型标识(即路由标识)。将业务类型标识(即路由标识)设置到路由标识持有器中。Spring在获取数据库连接时，根据路由标识持有器中的业务类型标识(即路由标识)，查询数据源路由信息集合得到对应的数据库的连接信息，根据连接信息连接至相应数据库，并开启数据库事务。然后，继续执行事务内业务逻辑操作。上述步骤执行完毕之后，清空当前数据源，最终形成一个动态数据源路由切换周期，循环反复，相互独立，互不干扰，互不影响。

本申请实施例中具有如下技术效果：

(1)采用单实例多租户的数据库连接池技术，很好的满足了不同业务场景的数据隔离要求。可以基于一套表结构设计、一套应用代码、一个SqlSessionFactory、一个事务管理器、一个动态数据源，根据不同租户(例如不同分行标识)实现动态的数据源切换，同一时刻只有一个数据源生效，不同租户业务数据存储在不同数据库，从而满足数据隔离要求。

2)数据源切换功能与业务处理逻辑解耦，业务开发人员不需要关注数据源切换功能，只需关注具体的业务处理逻辑，对业务透明，用户无感。

3)第一配置文件中路由的配置项中支持别名字段，可以通过别名字段复用路由的配置信息，简化第一配置文件的配置过程，并且，还可以根据别名字段对数据源路由信息进行分组管理。

4)既支持同类型多数据源，也支持不同类型的数据源混用，比如mysql、oracle、sybase等，因为Druid支持mysql、oracle、sybase等,JNDI也支持mysql、oracle、sybase等。

5)既支持数据源Druid连接配置，也支持数据源JNDI连接配置，还支持数据源Druid与JNDI连接混合配置。

6)既支持水平分库，也支持垂直分库，还支持水平分库和垂直分库混合使用。

7)业务***可根据实际需要定义自己的数据源切换策略，例如，可以根据分行标识切换、根据业务类型切换、根据渠道类型切换、根据区域标识切换等，也可以多种数据源切换策略组合使用，例如根据分行标识+业务类型切换等。

图11为本申请实施例提供的一种业务数据的处理装置的结构示意图。该装置可以为软件和/或硬件的形式。该装置可以应用于业务***，所述业务***部署有多个数据库以及用于对所述多个数据库进行事务操作的事务管理器。

如图11所示，本实施例提供的业务数据的处理装置1100，可以包括：获取模块1101、第一确定模块1102、第二确定模块1103和处理模块1104。

其中，获取模块1101，用于获取业务请求，所述业务请求用于请求对目标业务数据进行处理；

第一确定模块1102，用于根据所述业务请求，确定出目标路由标识，所述目标路由标识对应的路由用于路由至目标数据库，所述目标数据库为所述多个数据库中与所述目标业务数据对应的数据库；

第二确定模块1103，用于根据所述目标路由标识，确定所述目标数据库的连接信息；

处理模块1104，用于通过所述事务管理器根据所述目标数据库的连接信息连接所述目标数据库，并在所述目标数据库中对所述目标业务数据进行处理。

一种可能的实现方式中，所述第一确定模块1102具体用于：

获取所述业务***对应的数据源切换策略；

根据所述路由指示信息，确定出所述目标路由标识。

一种可能的实现方式中，所述第一确定模块1102具体用于：

获取不同路由指示信息与不同路由标识之间的映射关系；

一种可能的实现方式中，所述业务***对应的数据源切换策略的数量有多个；所述第一确定模块1102具体用于：

一种可能的实现方式中，所述第二确定模块1103具体用于：

一种可能的实现方式中，所述装置还包括生成模块(未示出)，所述生成模块用于：

一种可能的实现方式中，所述生成模块具体用于：

本实施例提供的业务数据的处理装置，可用于执行上述任一方法实施例中的业务数据的处理方法，其实现原理和技术效果类似，此处不作赘述。

图12为本申请实施例提供的一种电子设备的结构示意图。该电子设备可以为部署有业务***的电子设备。如图12所示，本实施例提供的电子设备1200，包括：处理器1201以及存储器1202。

其中，存储器1202，用于存储计算机程序；处理器1201，用于执行存储器中存储的计算机程序，以实现上述实施例中业务数据的处理方法中的一个或者多个步骤。具体可以参见前述方法实施例中的相关描述，其实现原理和技术效果类似，本实施例此处不再赘述。

可选地，存储器1202既可以是独立的，也可以跟处理器1201集成在一起。

当所述存储器1202是独立于处理器1201之外的器件时，所述电子设备1200还可以包括：总线1203，用于连接所述存储器1202和处理器1201。

本申请实施例还提供一种计算机可读存储介质，所述计算机可读存储介质包括计算机程序，所述计算机程序用于实现如上任一方法实施例中的业务数据的处理方法中的一个或者多个步骤，其实现原理和技术效果类似，此处不作赘述。

本申请实施例还提供一种芯片，包括：存储器和处理器，所述存储器中存储有计算机程序，所述处理器运行所述计算机程序执行上述任一方法实施例中的业务数据的处理方法中的一个或者多个步骤，其实现原理和技术效果类似，此处不作赘述。

本申请实施例还提供一种计算机程序产品，包括计算机程序，所述计算机程序被处理器执行时实现上述任一方法实施例中的业务数据的处理中的一个或者多个步骤，其实现原理和技术效果类似，此处不作赘述。

在本申请所提供的几个实施例中，应该理解到，所揭露的设备和方法，可以通过其它的方式实现。例如，以上所描述的设备实施例仅仅是示意性的，例如，所述模块的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个模块可以结合或者可以集成到另一个***，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或模块的间接耦合或通信连接，可以是电性，机械或其它的形式。

所述作为分离部件说明的模块可以是或者也可以不是物理上分开的，作为模块显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。

另外，在本申请各个实施例中的各功能模块可以集成在一个处理单元中，也可以是各个模块单独物理存在，也可以两个或两个以上模块集成在一个单元中。上述模块成的单元既可以采用硬件的形式实现，也可以采用硬件加软件功能单元的形式实现。

上述以软件功能模块的形式实现的集成的模块，可以存储在一个计算机可读取存储介质中。上述软件功能模块存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)或处理器(英文：processor)执行本申请各个实施例所述方法的部分步骤。

应理解，上述处理器可以是中央处理单元(英文：Central Processing Unit，简称：CPU)，还可以是其他通用处理器、数字信号处理器(英文：Digital Signal Processor，简称：DSP)、专用集成电路(英文：Application Specific Integrated Circuit，简称：ASIC)等。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。结合申请所公开的方法的步骤可以直接体现为硬件处理器执行完成，或者用处理器中的硬件及软件模块组合执行完成。

存储器可能包含高速RAM存储器，也可能还包括非易失性存储NVM，例如至少一个磁盘存储器，还可以为U盘、移动硬盘、只读存储器、磁盘或光盘等。

总线可以是工业标准体系结构(Industry Standard Architecture，ISA)总线、外部设备互连(Peripheral Component，PCI)总线或扩展工业标准体系结构(ExtendedIndustry Standard Architecture，EISA)总线等。总线可以分为地址总线、数据总线、控制总线等。为便于表示，本申请附图中的总线并不限定仅有一根总线或一种类型的总线。

上述存储介质可以是由任何类型的易失性或非易失性存储设备或者它们的组合实现，如静态随机存取存储器(SRAM)，电可擦除可编程只读存储器(EEPROM)，可擦除可编程只读存储器(EPROM)，可编程只读存储器(PROM)，只读存储器(ROM)，磁存储器，快闪存储器，磁盘或光盘。存储介质可以是通用或专用计算机能够存取的任何可用介质。

一种示例性的存储介质耦合至处理器，从而使处理器能够从该存储介质读取信息，且可向该存储介质写入信息。当然，存储介质也可以是处理器的组成部分。处理器和存储介质可以位于专用集成电路(Application Specific Integrated Circuits，简称：ASIC)中。当然，处理器和存储介质也可以作为分立组件存在于电子设备或主控设备中。

本领域普通技术人员可以理解：实现上述各方法实施例的全部或部分步骤可以通过程序指令相关的硬件来完成。前述的程序可以存储于一计算机可读取存储介质中。该程序在执行时，执行包括上述各方法实施例的步骤；而前述的存储介质包括：ROM、RAM、磁碟或者光盘等各种可以存储程序代码的介质。

最后应说明的是：以上各实施例仅用以说明本申请的技术方案，而非对其限制；尽管参照前述各实施例对本申请进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分或者全部技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本申请各实施例技术方案的范围。

Claims

1.一种业务数据的处理方法，其特征在于，应用于业务***，所述业务***部署有多个数据库以及用于对所述多个数据库进行事务操作的事务管理器，所述方法包括：

根据所述目标路由标识，确定所述目标数据库的连接信息；

2.根据权利要求1所述的方法，其特征在于，根据所述业务请求，确定出目标路由标识，包括：

获取所述业务***对应的数据源切换策略；

根据所述路由指示信息，确定出所述目标路由标识。

3.根据权利要求2所述的方法，其特征在于，根据所述路由指示信息，确定出所述目标路由标识，包括：

获取不同路由指示信息与不同路由标识之间的映射关系；

4.根据权利要求2所述的方法，其特征在于，所述业务***对应的数据源切换策略的数量有多个；根据所述数据源切换策略，对所述业务请求进行解析处理，得到路由指示信息，包括：

根据所述路由指示信息，确定出所述目标路由标识，包括：

5.根据权利要求1至4任一项所述的方法，其特征在于，根据所述目标路由标识，确定所述目标数据库的连接信息，包括：

6.根据权利要求5所述的方法，其特征在于，获取数据源路由信息集合之前，所述方法还包括：

7.根据权利要求6所述的方法，其特征在于，根据所述第一配置文件，获取每个路由的路由标识和每个路由对应的数据库的连接信息，包括：

8.一种业务数据的处理装置，其特征在于，应用于业务***，所述业务***部署有多个数据库以及用于对所述多个数据库进行事务操作的事务管理器，所述装置包括：

9.一种电子设备，其特征在于，包括：存储器和处理器，所述存储器用于存储计算机程序，所述处理器运行所述计算机程序实现如权利要求1至7任一项所述的方法。

10.一种计算机可读存储介质，其特征在于，包括：计算机程序，所述计算机程序被处理器执行时实现如权利要求1至7任一项所述的方法。

11.一种计算机程序产品，其特征在于，包括：计算机程序，所述计算机程序被处理器执行时实现如权利要求1至7任一项所述的方法。