CN113127102A

CN113127102A - Method, device, equipment, storage medium and program for processing service data

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

When a service request is received, a target routing identifier can be determined according to the service request, connection information of a target database can be determined according to the target routing identifier, a transaction manager can be switched and connected to the target database according to the connection information of the target database, and target service data can be processed in the target database. Therefore, under the condition that the service system is provided with a plurality of databases, the transaction manager can be switched and connected to different databases according to different received service requests, so that the plurality of databases share one transaction manager without respectively configuring the transaction manager for each database, and the configuration complexity is reduced.

Description

Method, device, equipment, storage medium and program for processing service data

Technical Field

The present application relates to the field of data processing technologies, and in particular, to a method, an apparatus, a device, a storage medium, and a program for processing service data.

Background

A database refers to a repository that organizes, stores, and manages data according to a data structure. The data source refers to a data source, one data source corresponds to one database, and information required for connecting the database is recorded in the data source. By configuring the data sources for the business system, the business system can be made aware of which databases are connected and how. Currently, many business systems support the deployment of multiple databases.

In the related art, when a business system is deployed with a plurality of databases, a transaction manager needs to be configured for each database. Each transaction manager is explicitly assigned a data source by adding annotations in the code. For example, taking the case that two databases are deployed, a transaction manager 1 is allocated to the database 1, the transaction manager 1 designates a data source 1, a transaction manager 2 is allocated to the database 2, and the transaction manager 2 designates a data source 2. When a service request of the service type 1 is received, the transaction manager 1 is connected to a database (namely, database 1) corresponding to the data source 1, and performs an intra-transaction service operation in the database 1. When a service request of the service type 2 is received, the service manager 2 is connected to a database (i.e. database 2) corresponding to the data source 2, and performs intra-transaction service operation in the database 2. That is, by assigning different transaction managers to different databases, transaction operations on different databases are implemented using different transaction managers.

However, the above method requires a plurality of transaction managers to be configured, and the configuration complexity is high.

Disclosure of Invention

The application provides a method, a device, equipment, a storage medium and a program for processing service data, which are used for reducing the configuration complexity of a service system.

In a first aspect, the present application provides a method for processing service data, which is applied to a service system, where the service system is deployed with a plurality of databases and a transaction manager for performing transaction operations on the databases, and the method includes:

acquiring a service request, wherein the service request is used for requesting to process target service data;

determining a target routing identifier according to the service request, wherein a route corresponding to the target routing identifier is used for routing to a target database, and the target database is a database corresponding to the target service data in the plurality of databases;

determining the connection information of the target database according to the target routing identification;

and connecting the target database according to the connection information of the target database through the transaction manager, and processing the target service data in the target database.

In a possible implementation manner, determining a target routing identifier according to the service request includes:

acquiring a data source switching strategy corresponding to the service system;

analyzing the service request according to the data source switching strategy to obtain routing indication information;

and determining the target route identification according to the route indication information.

In a possible implementation manner, determining the target routing identifier according to the routing indication information includes:

acquiring the mapping relation between different routing indication information and different routing identifiers;

and mapping the routing indication information according to the mapping relation to obtain the target routing identifier.

In a possible implementation manner, the number of data source switching strategies corresponding to the service system is multiple; according to the data source switching strategy, analyzing the service request to obtain routing indication information, including:

aiming at each data source switching strategy, acquiring an analysis mode corresponding to the data source switching strategy, and analyzing the service request by adopting the analysis mode to obtain route indication information corresponding to the data source switching strategy;

determining the target routing identifier according to the routing indication information, including:

and determining the target route identifier according to the route indication information corresponding to the data source switching strategies.

In a possible implementation manner, determining connection information of the target database according to the target route identifier includes:

acquiring a data source routing information set, wherein the data source routing information set comprises a plurality of routing identifiers and connection information of a database corresponding to each routing identifier;

and determining the connection information of the database corresponding to the target routing identification in the data source routing information set as the connection information of the target database.

In a possible implementation manner, before obtaining the data source routing information set, the method further includes:

when a starting instruction of the service system is received, acquiring a first configuration file, wherein the first configuration file comprises configuration information of a plurality of routes;

acquiring a route identifier of each route and connection information of a database corresponding to each route according to the first configuration file;

and generating the data source routing information set according to the routing identifiers of the plurality of routes and the connection information of the databases corresponding to the plurality of routes.

In a possible implementation manner, obtaining, according to the first configuration file, a route identifier of each route and connection information of a database corresponding to each route includes:

determining that the connection mode of the database corresponding to the route is a first connection mode or a second connection mode;

if the connection mode of the database corresponding to the route is the first connection mode, acquiring the route identifier of the route and the reference name of the database corresponding to the route from the first configuration file, and acquiring the connection information of the database corresponding to the route from the second configuration file according to the reference name; alternatively, the first and second electrodes may be,

and if the connection mode of the database corresponding to the route is the second connection mode, acquiring the route identifier of the route and the connection information of the database corresponding to the route from the first configuration file.

In a second aspect, the present application provides a service data processing apparatus, applied to a service system, where the service system is deployed with a plurality of databases and a transaction manager for performing transaction operations on the plurality of databases, the apparatus includes:

the system comprises an acquisition module, a processing module and a processing module, wherein the acquisition module is used for acquiring a service request which is used for requesting to process target service data;

a first determining module, configured to determine a target routing identifier according to the service request, where a route corresponding to the target routing identifier is used for routing to a target database, and the target database is a database corresponding to the target service data in the multiple databases;

the second determining module is used for determining the connection information of the target database according to the target routing identifier;

and the processing module is used for connecting the target database through the transaction manager according to the connection information of the target database and processing the target service data in the target database.

In a possible implementation manner, the first determining module is specifically configured to:

acquiring a data source switching strategy corresponding to the service system;

In a possible implementation manner, the number of data source switching strategies corresponding to the service system is multiple; the first determining module is specifically configured to:

In a possible implementation manner, the second determining module is specifically configured to:

In a possible implementation manner, the apparatus further includes a generation module, where the generation module is configured to:

In a possible implementation manner, the generating module is specifically configured to:

In a third aspect, the present application provides an electronic device, comprising: a memory for storing a computer program and a processor for executing the computer program to implement the method according to any of the first aspect.

In a fourth aspect, the present application provides a computer-readable storage medium comprising: a computer program implementing the method according to any one of the first aspect when executed by a processor.

In a fifth aspect, the present application provides a computer program product comprising: a computer program implementing the method according to any one of the first aspect when executed by a processor.

According to the business data processing method, device, equipment, storage medium and program, when a business request is received, a target routing identifier can be determined according to the business request, the connection information of a target database can be determined according to the target routing identifier, and a transaction manager can be switched and connected to the target database according to the connection information of the target database and process target business data in the target database. Therefore, under the condition that the service system is provided with a plurality of databases, the transaction manager can be switched and connected to different databases according to different received service requests, so that the plurality of databases share one transaction manager without respectively configuring the transaction manager for each database, and the configuration complexity is reduced.

Drawings

In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the drawings needed to be used in the description of the embodiments or the prior art will be briefly introduced below, and it is obvious that the drawings in the following description are only some embodiments of the present application, and it is obvious for those skilled in the art that other drawings can be obtained according to the drawings without inventive exercise.

Fig. 1 is a schematic system architecture diagram of a business system according to an embodiment of the present application;

fig. 2 is a schematic diagram of a related art multi-data source based service system;

FIG. 3 is a schematic diagram of a data processing process based on the business system shown in FIG. 2;

fig. 4 is a schematic diagram of a service system based on multiple data sources according to an embodiment of the present application;

fig. 5 is a schematic flowchart of a method for processing service data according to an embodiment of the present application;

fig. 6 is a schematic flowchart of a method for generating a data source routing information set according to an embodiment of the present application;

fig. 7 is a schematic diagram of a service data processing process according to an embodiment of the present application;

fig. 8 is a schematic diagram of another service data processing process provided in the embodiment of the present application;

fig. 9 is a schematic diagram of another service data processing process provided in the embodiment of the present application;

fig. 10 is a schematic diagram of another service data processing process provided in the embodiment of the present application;

fig. 11 is a schematic structural diagram of a service data processing apparatus according to an embodiment of the present application;

fig. 12 is a schematic structural diagram of an electronic device according to an embodiment of the present application.

Detailed Description

The technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the drawings in the embodiments of the present application, and it is obvious that the described embodiments are only a part of the embodiments of the present application, and not all of the embodiments. All other embodiments, which can be derived by a person skilled in the art from the embodiments given herein without making any creative effort, shall fall within the protection scope of the present application.

The terms "first," "second," "third," "fourth," and the like in the description and in the claims of the present application and in the above-described drawings (if any) are used for distinguishing between similar elements and not necessarily for describing a particular sequential or chronological order. Furthermore, the terms "comprises," "comprising," and "having," and any variations thereof, are intended to cover a non-exclusive inclusion, such that a process, method, system, article, or apparatus that comprises a list of steps or elements is not necessarily limited to those steps or elements expressly listed, but may include other steps or elements not expressly listed or inherent to such process, method, article, or apparatus.

First, terms or concepts related to the embodiments of the present application are explained.

A data source: refers to a database used by a database application.

Multiple data sources: that is, multiple databases, an application may configure multiple databases, for example, database a is an online library of applications and database B is a batch library of applications.

Dynamic data sources: the set of multiple data sources is an independent data source for the outsiders, and can be dynamically switched to one of the data source sets, but only one data source is in effect at the same time, that is, only one transaction is in effect.

MyBatis: MyBatis is an excellent persistent layer framework that supports custom SQL, stored procedures, and advanced mapping. MyBatis exempts almost all JDBC code from the task of setting parameters and obtaining a result set. MyBatis can configure and map the original type, interface, and Java POJO (Plain Old Java Objects) into records in the database through simple XML or annotations.

MyBatis-Plus: MP is an enhancement tool of MyBatis, only enhancement is carried out on the basis of MyBatis without change, and the enhancement tool is used for simplifying development and improving efficiency.

Sql session factory (SqlSessionFactory): the method is a key object of MyBatis, and is a memory mirror image of a single database mapping relation after compiling. An instance of the SqlSessionsFactory object may be obtained through a SqlSessionsFactoryBuilder object class, and the SqlSessionsFactoryBuilder may construct an instance of the SqlSessionsFactory from an XML Configuration file or a pre-customized instance of Configuration. Each MyBatis application centers on an instance of a SqlSessionFactory object. Meanwhile, SqlSessionsFactory is also thread-safe, and the SqlSessionsFactory should exist during the execution of the application once being created. The creation is not repeated multiple times during the running of the application, suggesting the use of a singleton mode. The SqlSessionFactory is the factory that creates the SqlSessions.

Spring: spring is a lightweight substitute for Java Enterprise Edition (JEE, also known as J2 EE). Spring provides a relatively simple method for enterprise-level Java development without developing heavyweight Enterprise Java Beans (EJB), and realizes the function of EJB by using simple Java objects (Plain Old Java objects, POJO) through dependency Injection (IOC) and oriented tangent plane (AOP) programming.

Aspect Oriented Programming (AOP), which can be said to be a complement and a complement to Object Oriented Programming (OOP). It dissects the inside of the unpacked object using a technique called "crosscut" and encapsulates those common behaviors that affect multiple classes into a reusable module and names it as "Aspect", i.e., the cut plane. The "section" is simply the logic or responsibility which is not related to the service but is called by the service module together, so as to reduce the repeated codes of the system, reduce the coupling degree between the modules and facilitate the future operability and maintainability.

Spring boot: the Spring boot is a complete scheme for realizing automatic configuration of Spring and reducing project building complexity. The Spring boot itself does not provide the core characteristics and the extension functions of the Spring framework, and is only used for quickly and agilely developing a new generation of application programs based on the Spring framework. That is, it is not a solution for replacing Spring, but a tool for enhancing the Spring developer experience in close combination with the Spring framework. The SpringBoot can ensure that a developer does not need to switch thinking between configuration and logic service based on the idea of convention superior to configuration, and the SpringBoot is put into code compiling of the logic service in whole body and mind, thereby greatly improving the development efficiency and shortening the project cycle to a certain extent.

For ease of understanding, the system architecture of the business system related to the embodiment of the present application is described below with reference to fig. 1.

Fig. 1 is a schematic system architecture diagram of a service system according to an embodiment of the present application. As shown in fig. 1, in the service system provided in this embodiment, a server/server cluster and a plurality of databases are deployed. The server/server cluster may process the service data in the plurality of databases. For example, the server/server cluster may add new service data, modify service data, delete service data, and the like to each database.

It should be noted that the service system of the present embodiment can be applied to various application scenarios, including but not limited to: banking scenarios, financial scenarios, e-commerce scenarios, social business scenarios, and the like. For ease of understanding, the following description will be made with reference to a banking scenario as an example.

In some exemplary scenarios, the plurality of databases may be vertically partitioned. The vertical database partitioning refers to that a data table in one database is split into a plurality of databases according to different business attributions by taking a table as a basis, the structure of each split database is different, and the data in different databases are also different. For example, assume that the business system generates the following data table: user data sheet, loan service data sheet, financing service data sheet, etc. In the vertical banking mode, the user data table may be stored in the database 1, the loan transaction data table may be stored in the database 2, and the financing transaction data table may be stored in the database 3.

In other exemplary scenarios, the plurality of databases may be in a horizontal banking manner. The horizontal database partitioning mode is that data in one database is partitioned into a plurality of databases according to a certain strategy by taking a field as a basis, the structure of each partitioned database is the same, and the data in different databases are different.

For example, a bank typically places branches in various regions of the world. The regulatory bodies in different regions have different regulatory requirements for the independence of data. For example, some regions explicitly indicate that business data generated in the region is not allowed to be deployed in the same database as business data generated in other regions. Therefore, when deploying a database, the data isolation requirements of different areas need to be considered. Therefore, the service data generated by the area 1 can be stored in the database 1, the service data generated by the area 2 can be stored in the database 2, and the service data generated by the area 3 can be stored in the database 3 according to different areas in which the service data are generated.

In still other exemplary scenarios, the plurality of databases may be mixed in a vertical banking manner and a horizontal banking manner. For example, database 1 may store the user data table generated by region 1, database 2 may store the loan transaction data table generated by region 1, database 3 may store the financial transaction data table generated by region 1, database 4 may generate the user data table generated by region 2, database 5 may store the loan transaction data table generated by region 2, database 6 may store the financial transaction data table generated by region 2, database 7 may generate the user data table generated by region 3, database 8 may store the loan transaction data table generated by region 3, and database 9 may store the financial transaction data table generated by region 3.

Data source refers to the source of the data. One data source corresponds to one database, and information required for connecting the database is recorded in the data source. By configuring the data sources for the business system, the business system can be made aware of which databases are connected and how. Many business systems currently support the deployment of multiple data sources.

In the related art, when a business system supports the deployment of a plurality of databases, a transaction manager needs to be configured for each database. Fig. 2 is a schematic diagram of a related art multi-data source based service system. The MyBatis-Plus framework based on SpringBoot is illustrated in FIG. 2 by way of example. As shown in fig. 2, a transaction manager and a SqlSessionFactory are respectively configured for each database.

Further, in the business processing code of each transaction manager, it is supported to configure default data sources, and it is also possible to specify a specific data source by the @ DS comment. Illustratively, the @ DS annotation is added to the Service implementation, that is, Mybatis-Plus only supports the operation of a database corresponding to one data source within a single Service method. For example, if an @ DS annotation is not added to a certain service processing method, the database corresponding to the default data source is operated when the service processing method is executed. If a certain business processing method adds annotations: @ DS ("dsName"), where dsName may be a certain data source, then when executing the business processing method, the database corresponding to dsName is operated.

When a business request of a certain business type is received, the business request can be connected to a corresponding database through a transaction manager corresponding to the business type according to a data source specified by the code annotation. Fig. 3 is a schematic diagram of a data processing process based on the service system shown in fig. 2. As shown in fig. 3, if the annotation in the business process code is @ DS ("data source 1"), a database corresponding to data source 1 is selected for connection, if the annotation in the business process code is @ DS ("data source 2"), a database corresponding to data source 2 is selected for connection, and so on. Then, the intra-transaction business operation is performed in the corresponding database. That is, by assigning different transaction managers to different databases, transaction operations on different databases are implemented using different transaction managers.

However, in the process of implementing the present application, the inventors found that the above related art has at least the following technical problems:

(1) the above method needs to configure a transaction manager and a SqlSessionFactory for each database. When a business system is deployed with a plurality of databases, a plurality of transaction managers and a plurality of SqlSessionFactory need to be configured, so that the configuration complexity is high.

(2) The above-mentioned manner defines the binding relationship between the transaction manager and the database at the code level, so that one business processing method only supports to operate one database, and therefore, the above-mentioned related technology can be generally only used in the vertical banking scenario, but not used in the horizontal banking scenario. In the scenario of horizontal sub-databases, the data table structures in different databases are the same, and the service processing logics of different databases are also the same, it is desirable to implement the service processing procedures of multiple databases by using a set of codes, and one service processing method in the above related art only supports operating a designated database, so that the data processing requirements of the horizontal sub-databases cannot be met.

(3) The above approach requires adding annotations to the business process code to specify the data source, resulting in a high degree of invasiveness to the business code. When the service developer implements the service processing logic, the switching function of the data source needs to be considered, so that the coupling between the data source switching function and the service processing logic is high.

In order to solve at least one of the above technical problems, an embodiment of the present application provides a method for processing service data, and the inventive concept of the present application is described below with reference to fig. 4.

Fig. 4 is a schematic diagram of a service system based on multiple data sources according to an embodiment of the present application. As shown in fig. 4, a plurality of databases are deployed in the service system, and share one transaction manager and one SqlSessionFactory. When a service request is received, a target routing identifier can be determined according to the service request, connection information of a target database is determined according to the target routing identifier, the transaction manager is connected to the target database according to the connection information of the target database, and target service data are processed in the target database.

Therefore, in the application, the transaction manager can be dynamically switched and connected to different databases according to the current service request, so that only one transaction manager needs to be configured for the service system, and the configuration complexity is reduced. Correspondingly, notes do not need to be added in the business processing codes to designate data sources, and the intrusiveness of the business codes is reduced, so that business developers do not need to consider the switching function of the data sources when realizing business processing logic, and the data source switching function is decoupled from the business processing logic. Furthermore, the scheme of the application can be applied to a vertical warehouse-splitting scene, a horizontal warehouse-splitting scene and a scene in which the vertical warehouse-splitting and the horizontal warehouse-splitting are used together, and the flexibility of the application scene is improved.

The technical solution of the present application will be described in detail below with specific examples. The following several specific embodiments may be combined with each other, and details of the same or similar concepts or processes may not be repeated in some embodiments.

Fig. 5 is a schematic flowchart of a method for processing service data according to an embodiment of the present application. This embodiment may be performed by the server/server cluster in fig. 4.

As shown in fig. 5, the method of this embodiment includes:

s501: and acquiring a service request, wherein the service request is used for requesting to process target service data.

Specifically, when the terminal device needs to process the target service data, a service request is sent to the server/server cluster to request the server/server cluster to process the target service data.

The target business data can be data in any database in the business system. That is, the service request may be a request for processing the target service data in any one of the databases of the service system.

Illustratively, the service request may be used to request addition of target service data, deletion of target service data, or modification of target service data.

S502: and determining a target routing identifier according to the service request, wherein a route corresponding to the target routing identifier is used for routing to a target database, and the target database is a database corresponding to the target service data in the plurality of databases.

In this embodiment, it may be determined which database needs to be processed according to the service request. In this embodiment, a database that needs to process target service data is referred to as a target database. The target database may be any one of a plurality of databases.

Optionally, the service request may include a target route identifier. Illustratively, the service request may include a first field, and a value of the first field is the target route identifier. Thus, the target route identifier can be determined according to the value of the first field in the service request. For example, in a banking scenario, the first field may be a branch identification field, a business type field, a channel type field, an area identification field, and the like.

Optionally, the service request may include route indication information. Different route indication information and different route identifications have a certain mapping relation. Thus, the target route identifier can be determined by mapping the route indication information in the service request.

The service system of this embodiment is deployed with multiple data sources, and can switch to different data sources according to different received service requests. In practical application, one or more data source switching strategies can be adopted according to the requirements of practical application scenarios. Taking the banking scenario as an example, the data source switching policies that can be adopted include, but are not limited to: and switching the data source according to the branch identification, switching the data source according to the area identification, switching the data source according to the service type and switching the data source according to the channel type.

In one possible implementation manner, the following feasible manner may be adopted to determine the target routing identifier according to the service request: the method comprises the steps of obtaining a data source switching strategy corresponding to a service system, analyzing a service request according to the data source switching strategy to obtain routing indication information, and determining a target routing identifier according to the routing indication information.

Optionally, a mapping relationship between different routing indication information and different routing identifiers may be obtained, and the routing indication information is mapped according to the mapping relationship to determine the target routing identifier.

When different data source switching strategies are adopted, the routing indication information carried in the service request may be different, and correspondingly, the analysis modes of the service request may also be different. The following is exemplified in connection with several specific examples.

In one example, it is assumed that the data source switching strategy is adopted to switch the data source according to the branch identification, that is, the service data of different branches are stored in different databases. In this example, the service request may carry a branch identifier, and the branch identifier is used as the routing indication information. Then, the branch identifier may be obtained by parsing from the service request, and then, the branch identifier may be mapped according to a mapping relationship between the branch and the database, so as to obtain the target routing identifier.

In another example, it is assumed that the data source switching strategy is adopted to switch the data source according to the area identification, that is, the service data of different areas are stored in different databases. In this example, the service request may carry an area identifier, and the area identifier is used as the routing indication information. Then, the area identifier may be obtained by parsing from the request, and then, the area identifier may be mapped according to a mapping relationship between the area and the database, so as to obtain the target routing identifier.

In yet another example, it is assumed that the data source switching strategy is adopted to switch data sources according to service types, that is, service data of different service types are stored in different databases. In this example, the service request may carry a service type, and the service type is used as the routing indication information. Then, the service type can be obtained by parsing from the service request, and then the service type is mapped according to the mapping relationship between the service type and the database, so that the target route identifier can be obtained.

In another example, it is assumed that the data source switching policy is to switch data sources according to channel types, that is, service data of different channel types are stored in different databases. In this example, the service request may carry a channel type, and the channel type is used as the routing indication information. Then, the channel type can be obtained by analyzing from the service request, and then the channel type is mapped according to the mapping relationship between the channel type and the database, so that the target route identifier can be obtained.

In some possible scenarios, the number of data source switching policies corresponding to the service system may be various. For example, the data source switching strategy adopted by the service system is to switch the data source according to the branch identifier + the service type, and in this case, the service request may simultaneously carry the branch identifier and the service type.

Optionally, when the number of the data source switching policies corresponding to the service system is multiple, an analysis manner corresponding to each data source switching policy may be obtained, and the analysis manner is adopted to analyze the service request, so as to obtain the routing indication information corresponding to the data source switching policy. Further, a target route identifier is determined according to the route indication information corresponding to each of the plurality of data source switching strategies.

Optionally, the routing indication information corresponding to each of the multiple data source switching policies may be spliced to obtain the target routing identifier.

For example, assume that the data source switching policy adopted by the service system is to switch the data source according to the branch identifier + the service type. If one piece of route indication information (branch identifier) obtained by parsing the service request is "HK" and the other piece of route indication information (service type) obtained by parsing the service request is service type a, it can be determined that the target route identifier is "HK _ a". The splicing mode of the multiple routing indication information is only an illustration, and in practical application, the multiple routing indication information can be spliced according to the naming rule of the routing identifier.

S503: and determining the connection information of the target database according to the target routing identification.

The connection information of one database refers to information required by the transaction manager to connect the database. For example, the connection information of a database may include information such as an Internet Protocol Address (IP) Address, a port number, a connection account number, and a connection password corresponding to the database.

The routing identification and the connection information of the database have a corresponding relation, so that the connection information of the target database can be determined according to the target routing identification.

In one possible implementation, the connection information of the target database may be determined as follows: acquiring a data source routing information set, wherein the data source routing information set comprises a plurality of routing identifiers and connection information of a database corresponding to each routing identifier; and determining the connection information of the database corresponding to the target routing identification in the data source routing information set as the connection information of the target database.

S504: and connecting the target database according to the connection information of the target database through the transaction manager, and processing the target service data in the target database.

In this embodiment, after the connection information of the target database is determined, the transaction manager may connect the target database according to the connection information of the target database, and process the target service data in the target database.

For example, taking a banking system as an example, assume that a bank includes 3 branches, and the business data of branch 1 is stored in database 1, the business data of branch 2 is stored in database 2, and the business data of branch 3 is stored in database 3.

In an example, assuming that a service system receives a service request 1, the scheme of this embodiment is adopted to perform parsing processing on the service request 1 to obtain a branch identifier 1, so as to determine that a target route is a route 1. Then, by querying the data source routing information set, the connection information of the database 1 corresponding to the route 1 can be obtained. Further, the transaction manager connects to the database 1 according to the connection information of the database 1, and processes the target service data in the database 1.

In another example, assuming that the service system receives the service request 2, the scheme of this embodiment is adopted to perform parsing processing on the service request 2 to obtain the branch identifier 2, so as to determine that the target route is the route 2. Then, by querying the data source routing information set, the connection information of the database 2 corresponding to the route 2 can be obtained. Further, the transaction manager connects to the database 2 according to the connection information of the database 2, and processes the target service data in the database 2.

In another example, assuming that the service system receives the service request 3, the scheme of this embodiment is adopted to perform parsing processing on the service request 3 to obtain the branch identifier 3, so as to determine that the target route is the route 3. Then, by querying the data source routing information set, the connection information of the database 3 corresponding to the route 3 can be obtained. Further, the transaction manager connects to the database 3 according to the connection information of the database 3, and processes the target service data in the database 3.

In the method for processing service data provided in this embodiment, when a service request is received, a target routing identifier may be determined according to the service request, and connection information of a target database may be determined according to the target routing identifier, and the transaction manager may switch to be connected to the target database according to the connection information of the target database, and process target service data in the target database. Therefore, under the condition that the service system is provided with a plurality of databases, the transaction manager can be switched and connected to different databases according to different received service requests, so that the plurality of databases share one transaction manager without respectively configuring the transaction manager for each database, and the configuration complexity is reduced.

Furthermore, as a plurality of databases can share one transaction manager, the condition that a data source is appointed by adding annotation in a business processing code is avoided, and the intrusiveness on the business code is reduced, so that a business developer does not need to consider the switching function of the data source when realizing the business processing logic, and the data source switching function is decoupled from the business processing logic.

Furthermore, because the transaction manager can be switched and connected to different databases according to different received service requests, flexible switching of the transaction manager among a plurality of databases is realized, and data sources are prevented from being designated in service processing codes, the embodiment can be applied to a vertical database partitioning scene, a horizontal database partitioning scene, a mixed vertical database partitioning scene and a mixed horizontal database partitioning scene, and the application flexibility is improved.

In the above embodiment, when the target routing identifier is determined, the connection information of the target database may be determined according to the data source routing information set. The following describes a process for generating a set of data source routing information in conjunction with a specific embodiment.

Fig. 6 is a schematic flowchart of a method for generating a data source routing information set according to an embodiment of the present application. As shown in fig. 6, the method of this embodiment includes:

s601: and when a starting instruction of the service system is received, acquiring a first configuration file, wherein the first configuration file comprises configuration information of a plurality of routes.

S602: and acquiring the route identification of each route and the connection information of the database corresponding to each route according to the first configuration file.

S603: and generating the data source routing information set according to the routing identifiers of the plurality of routes and the connection information of the databases corresponding to the plurality of routes.

In this embodiment, the first configuration file is used to record configuration information of each route. One route corresponds to a connection path of one database. When the first configuration file is changed, for example, when a data source is added, modified or deleted, the data source routing information set needs to be updated, so that the service system can be restarted. And in the process of starting and initializing the service system, acquiring the route identification of each route and the connection information of the database corresponding to each route according to the first data configuration file. And generating the data source route information set according to the route identifications of the plurality of routes and the connection information of the databases corresponding to the plurality of routes.

In a possible implementation manner, for each route configured in the first configuration file, it may be determined that a connection manner of the database corresponding to the route is the first connection manner or the second connection manner. For example, using Java as an example, the first connection mode may be a Java Naming and Directory Interface (JNDI) connection mode, and the second connection mode may be a managed connection mode. When a certain database adopts a JNDI connection mode, only the reference name of the database needs to be recorded in the first configuration file, and the connection information of the database is recorded in the second configuration file. When the connection information of the database needs to be acquired, the second configuration file can be accessed according to the reference name in the first configuration file for acquisition. When a certain database adopts a drive connection mode, the connection information of the database can be recorded in the first configuration file.

Therefore, the route identifier of each route and the connection information of the database corresponding to the route can be obtained in the following feasible manner.

Optionally, if the connection mode of the database corresponding to the route is a JNDI connection mode, the route identifier of the route and the reference name of the database corresponding to the route are obtained from the first configuration file, and the connection information of the database corresponding to the route is obtained from the second configuration file according to the reference name.

Optionally, if the connection mode of the database corresponding to the route is a route connection mode, the route identifier of the route and the connection information of the database corresponding to the route are obtained from the first configuration file.

In this embodiment, the multiple databases deployed in the service system support the same type of database, and may also be different types of databases, such as mysql, oracle, sybase, and the like. Since Druid supports mysql, oracle, sybase, etc., JNDI also supports mysql, oracle, sybase, etc.

On the basis of the above embodiment, the following takes Spring as an example to exemplify the implementation process of the technical solution of the present application.

Fig. 7 is a schematic diagram of a service data processing process according to an embodiment of the present application. As shown in fig. 7, the business system is deployed with a data source routing information set generator, a route identifier resolver, a route identifier holder, a transaction manager, and a data source routing information set.

The data source routing information set generator may obtain the first configuration file in the service system starting process, and generate the data source routing information set according to the first configuration file. The data source routing information set comprises a plurality of routing identifications and connection information of the database corresponding to each routing identification.

The first configuration file records configuration information of a plurality of routes. Each route is for routing to a database in the business system. The configuration information of each route includes a route identifier corresponding to the route and related information of a database corresponding to the route.

When generating the data source routing information set, the data source routing information set generator judges whether the connection mode of the database corresponding to the route is a JNDI connection mode or a Druid connection mode according to whether a JNDI field exists in a configuration item of the route in the first configuration file.

And if the JNDI field exists in the configuration item of the route, the database corresponding to the route is represented as a JNDI connection mode, and the value of the JNDI field is the reference name of the database corresponding to the route. In this case, the data source routing information set generator may obtain the routing identifier of the route from the first configuration file, and search the connection information of the corresponding database from the second configuration file according to the value of the jndi field (i.e., the reference name of the database corresponding to the route). Thus, a data source is generated according to the route identifier corresponding to the route and the connection information of the database corresponding to the route.

And if the jndi field does not exist in the configuration item of the route, indicating that the database corresponding to the route is in a drive connection mode. In this case, the data source route information set generator may obtain, from the first configuration file, the route identifier of the route and the connection information of the database corresponding to the route. Thus, a data source is generated according to the route identifier corresponding to the route and the connection information of the database corresponding to the route.

In one example, when a database corresponding to a route adopts a route connection manner, configuration items of the route in the first configuration file are as follows:

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

when a database corresponding to a route adopts a JNDI connection mode, configuration items of the route in the first configuration file are as follows:

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

wherein default is a route identifier.

When a route is configured with both the JNDI connection mode and the route connection mode, the data source route information set generator may preferentially select the JNDI connection mode.

Through the design, the scheme of the application not only supports the drive connection mode, but also supports the JNDI connection mode, and also supports the mixed configuration of the drive connection mode and the JNDI connection mode.

Optionally, an alias (alias) field may be included in the configuration entry of each route in the first configuration file. For example, taking a banking scenario as an example, assume that the business system is deployed according to regions, and different regions use different databases. Assuming that region a includes 3 branches, branch 1, branch 2, and branch 3, respectively, the 3 branches in region a use the same database. In this case, only the route corresponding to the branch 1 in the area a may be configured in the first configuration file, and the identifiers of the branch 2 and the branch 3 may be configured in the alias field of the route. In this way, when generating the data source routing information set, the data source routing information set generator may generate the data source corresponding to the branch 1 according to the configuration item of the branch 1, and may also generate the data source corresponding to the branch 2 and the branch 3 according to the alias field of the branch 1.

In this way, the number of configuration information in the first configuration file is reduced by setting the alias field in the first configuration file, so that the configuration process of the first configuration file is more elegant and simple, and the data source grouping management can be well realized.

With continued reference to fig. 7, when receiving the service request, the route identifier parser may parse the service request to obtain route indication information, and determine the target route identifier according to the route indication information. The route identity resolver may set the target route identity into the route identity holder.

With continued reference to fig. 7, the route identifier holder is configured to store a route identifier k. The route identifier holder can be said to be a global operator and manager for data source switching, and realizes dynamic data source switching by setting different route identifiers.

With continued reference to FIG. 7, the transaction manager triggers the dynamic data source before opening the transaction. In this embodiment, the customized dynamic data source inherits the abstract routing data source of Spring, and rewrites the deteremirrenthookupkey method, which obtains the target routing identifier from the routing identifier holder and returns the target routing identifier. In the process of service operation of the system, when getConnection is performed each time, connection information of a database corresponding to the target route identifier is inquired from the data source route information set according to the target route identifier, and the database is connected to the corresponding database according to the connection information. Further, the transaction manager opens the transaction and performs business operations within the transaction.

Through the process of the service data shown in fig. 7, dynamic switching of the data source is realized.

On the basis of any of the above embodiments, the following takes a banking scenario as an example, and illustrates the technical solution of the present application by combining several specific examples.

Fig. 8 is a schematic diagram of another service data processing process provided in the embodiment of the present application. The embodiment takes a transaction-based business system as an example for illustration. In this embodiment, the service data of different branches are stored in different databases, and the branch identifier may be used as the routing identifier.

The transaction service system adopts a Client-Server (C/S) architecture. As shown in fig. 8, the server receives a service request sent by the client, and analyzes the service request to obtain a branch identifier (i.e., a routing identifier). The following description will be given by taking the column mark 1 as an example. Assuming that the branch identifier is 1, storing the branch identifier 1 in the target routing identifier holder, and obtaining connection information of the database corresponding to the branch identifier 1, and further switching and connecting to the database corresponding to the branch identifier according to the connection information, and starting a transaction. And then, continuing to execute the responsibility chain nodes until all the nodes are executed, and clearing the current data source according to whether the execution of the business logic layer is successful or not to submit or rollback the data source transaction, thereby finally forming a dynamic data source routing switching period, wherein the cycle is repeated, independent, non-interfering and non-influencing.

In this embodiment, in the whole service logic processing process, developers only need to pay attention to specific service processing logic, and do not need to pay attention to data source switching, that is, data source switching is transparent to services. However, it should be noted that the service logic processing layer cannot switch the data source again in the process of processing a specific service, or in a database transaction, and even if the data source is switched, the data source cannot be switched again, because the database connection acquired at the beginning is used in the transaction.

Fig. 9 is a schematic diagram of another service data processing process provided in the embodiment of the present application. This embodiment exemplifies a management-type service system. In this embodiment, the service data of different branches are stored in different databases, and the branch identifier may be used as the routing identifier.

The management business system adopts Browser/Server (B/S) architecture. As shown in fig. 9, the user sends a service request through the terminal browser. The server receives the service request through a Spring AOP surrounding section (the section can intercept all RequestMapping requests), and analyzes the service request through a route identifier analyzer to obtain a branch identifier (namely a route identifier). And storing the resolved branch identification (namely the route identification) into a route identification holder. When the Spring acquires the database connection, the Spring queries the data source routing information set according to the branch identifier (namely the routing identifier) in the routing identifier holder to obtain the connection information of the corresponding database, and then the Spring is connected to the corresponding database according to the connection information to start the database transaction. And continuing to execute the specific control layer (controller), service logical layer (service) and object persistence layer (mapper) steps. After the steps are completed, the Spring AOP surrounding tangent plane can empty the current data source, and finally a dynamic data source routing switching period is formed, wherein the dynamic data source routing switching period is repeated in a circulating mode, is independent of each other, does not interfere with each other, and does not affect each other.

The embodiments shown in fig. 8 and 9 are described primarily with respect to a horizontal banking scenario. The service data processing method provided by the application can be applied to a scene of horizontal database partitioning and can also be applied to a scene of vertical database partitioning. For example, the database division is performed according to the transaction types, and the database division is divided into the scenes of an online database and a batch database, or the database division is performed according to the service types, and the database division is divided into the scenes of a service type A database, a service type B database and a service type C database. This is illustrated below with reference to fig. 10.

Fig. 10 is a schematic diagram of another service data processing process provided in the embodiment of the present application. As shown in fig. 10, the service system receives the service request, and performs parsing processing on the service request by using the route identifier parser, so as to obtain a service type identifier (i.e., a route identifier). A traffic type identifier (i.e., a routing identifier) is set to the routing identifier holder. When the Spring acquires the database connection, according to the service type identifier (namely the routing identifier) in the routing identifier holder, the Spring queries the data source routing information set to obtain the connection information of the corresponding database, connects to the corresponding database according to the connection information, and starts a database transaction. Then, the intra-transaction business logic operation continues to be executed. And after the steps are finished, clearing the current data source, and finally forming a dynamic data source routing switching period which is repeated in a circulating way, independent from each other, non-interfering with each other and non-influencing with each other.

The embodiment of the application has the following technical effects:

(1) by adopting the single-instance multi-tenant database connection pool technology, the data isolation requirements of different service scenes are well met. Based on a set of table structure design, a set of application codes, a SqlSessionsFactory, a transaction manager and a dynamic data source, dynamic data source switching is realized according to different tenants (such as different branch identifiers), only one data source takes effect at the same time, and different tenant service data are stored in different databases, so that the requirement of data isolation is met.

2) The data source switching function is decoupled from the service processing logic, and service developers only need to pay attention to the specific service processing logic without paying attention to the data source switching function, so that the service is transparent and the users are not sensitive.

3) The alias fields are supported in the configuration items of the routes in the first configuration file, the configuration process of the first configuration file can be simplified by multiplexing the configuration information of the routes through the alias fields, and the data source routing information can be subjected to grouping management according to the alias fields.

4) Both the same type of multiple data sources and different types of data sources are supported for use, such as mysql, oracle, sybase, etc., since draid supports mysql, oracle, sybase, etc., and JNDI also supports mysql, oracle, sybase, etc.

5) The data source drive connection configuration and the data source JNDI connection configuration are supported, and the data source drive and JNDI connection mixed configuration is also supported.

6) The method not only supports the horizontal sub-library, but also supports the vertical sub-library, and also supports the mixed use of the horizontal sub-library and the vertical sub-library.

7) The service system may define its own data source switching policy according to actual needs, for example, switching may be performed according to a branch identifier, switching may be performed according to a service type, switching may be performed according to a channel type, switching may be performed according to a region identifier, and the like, or multiple data source switching policies may be used in combination, for example, switching may be performed according to a branch identifier + a service type.

Fig. 11 is a schematic structural diagram of a service data processing apparatus according to an embodiment of the present application. The means may be in the form of software and/or hardware. The device can be applied to a business system, wherein the business system is provided with a plurality of databases and a transaction manager used for performing transaction operation on the databases.

As shown in fig. 11, the apparatus 1100 for processing service data provided in this embodiment may include: an acquisition module 1101, a first determination module 1102, a second determination module 1103 and a processing module 1104.

The acquiring module 1101 is configured to acquire a service request, where the service request is used to request processing of target service data;

a first determining module 1102, configured to determine a target routing identifier according to the service request, where a route corresponding to the target routing identifier is used for routing to a target database, and the target database is a database corresponding to the target service data in the multiple databases;

a second determining module 1103, configured to determine connection information of the target database according to the target route identifier;

and the processing module 1104 is configured to connect the target database through the transaction manager according to the connection information of the target database, and process the target service data in the target database.

In a possible implementation manner, the first determining module 1102 is specifically configured to:

acquiring a data source switching strategy corresponding to the service system;

In a possible implementation manner, the number of data source switching strategies corresponding to the service system is multiple; the first determining module 1102 is specifically configured to:

In a possible implementation manner, the second determining module 1103 is specifically configured to:

In a possible implementation, the apparatus further includes a generating module (not shown) configured to:

The processing apparatus for service data provided in this embodiment may be configured to execute the method for processing service data in any of the above method embodiments, and the implementation principle and the technical effect are similar, which are not described herein again.

Fig. 12 is a schematic structural diagram of an electronic device according to an embodiment of the present application. The electronic device may be an electronic device deployed with a business system. As shown in fig. 12, the electronic device 1200 provided in this embodiment includes: a processor 1201 and a memory 1202.

A memory 1202 for storing a computer program; the processor 1201 is configured to execute the computer program stored in the memory to implement one or more steps of the service data processing method in the foregoing embodiments. Specifically, reference may be made to the related descriptions in the foregoing method embodiments, which have similar implementation principles and technical effects, and this embodiment is not described herein again.

Alternatively, the memory 1202 may be separate or integrated with the processor 1201.

When the memory 1202 is a separate device from the processor 1201, the electronic device 1200 may further include: a bus 1203 for connecting the memory 1202 and the processor 1201.

An embodiment of the present application further provides a computer-readable storage medium, where the computer-readable storage medium includes a computer program, and the computer program is used to implement one or more steps in the method for processing service data in any method embodiment, and implement principles and technical effects thereof are similar, and are not described herein again.

An embodiment of the present application further provides a chip, including: the processor runs the computer program to execute one or more steps in the method for processing the service data in any one of the above method embodiments, and the implementation principle and the technical effect are similar, which are not described herein again.

An embodiment of the present application further provides a computer program product, which includes a computer program, and when the computer program is executed by a processor, the computer program implements one or more steps in the processing of the service data in any of the method embodiments, and the implementation principle and the technical effect of the computer program are similar, which are not described herein again.

In the several embodiments provided in the present application, it should be understood that the disclosed apparatus and method may be implemented in other ways. For example, the above-described device embodiments are merely illustrative, and for example, the division of the modules is only one logical division, and other divisions may be realized in practice, for example, a plurality of modules may be combined or integrated into another system, or some features may be omitted, or not executed. In addition, the shown or discussed mutual coupling or direct coupling or communication connection may be an indirect coupling or communication connection through some interfaces, devices or modules, and may be in an electrical, mechanical or other form.

The modules described as separate parts may or may not be physically separate, and parts displayed as modules may or may not be physical units, may be located in one place, or may be distributed on a plurality of network units. Some or all of the modules may be selected according to actual needs to achieve the purpose of the solution of the present embodiment.

In addition, functional modules in the embodiments of the present application may be integrated into one processing unit, or each module may exist alone physically, or two or more modules are integrated into one unit. The unit formed by the modules can be realized in a hardware form, and can also be realized in a form of hardware and a software functional unit.

The integrated module implemented in the form of a software functional module may be stored in a computer-readable storage medium. The software functional module is stored in a storage medium and includes several instructions for enabling a computer device (which may be a personal computer, a server, or a network device) or a processor (processor) to execute some steps of the methods according to the embodiments of the present application.

It should be understood that the Processor may be a Central Processing Unit (CPU), other general purpose Processor, a Digital Signal Processor (DSP), an Application Specific Integrated Circuit (ASIC), etc. A general purpose processor may be a microprocessor or the processor may be any conventional processor or the like. The steps of a method disclosed in the incorporated application may be directly implemented by a hardware processor, or may be implemented by a combination of hardware and software modules in the processor.

The memory may comprise a high-speed RAM memory, and may further comprise a non-volatile storage NVM, such as at least one disk memory, and may also be a usb disk, a removable hard disk, a read-only memory, a magnetic or optical disk, etc.

The bus may be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, an Extended ISA (EISA) bus, or the like. The bus may be divided into an address bus, a data bus, a control bus, etc. For ease of illustration, the buses in the figures of the present application are not limited to only one bus or one type of bus.

The storage medium may be implemented by any type or combination of volatile or non-volatile memory devices, such as Static Random Access Memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic memory, flash memory, magnetic or optical disks. A storage media may be any available media that can be accessed by a general purpose or special purpose computer.

An exemplary storage medium is coupled to the processor such the processor can read information from, and write information to, the storage medium. Of course, the storage medium may also be integral to the processor. The processor and the storage medium may reside in an Application Specific Integrated Circuits (ASIC). Of course, the processor and the storage medium may reside as discrete components in an electronic device or host device.

Those of ordinary skill in the art will understand that: all or a portion of the steps of implementing the above-described method embodiments may be performed by hardware associated with program instructions. The program may be stored in a computer-readable storage medium. When executed, the program performs steps comprising the method embodiments described above; and the aforementioned storage medium includes: various media that can store program codes, such as ROM, RAM, magnetic or optical disks.

Finally, it should be noted that: the above embodiments are only used for illustrating the technical solutions of the present application, and not for limiting the same; although the present application has been described in detail with reference to the foregoing embodiments, it should be understood by those of ordinary skill in the art that: the technical solutions described in the foregoing embodiments may still be modified, or some or all of the technical features may be equivalently replaced; and the modifications or the substitutions do not make the essence of the corresponding technical solutions depart from the scope of the technical solutions of the embodiments of the present application.

Claims

1. A method for processing service data is applied to a service system, wherein the service system is deployed with a plurality of databases and a transaction manager for performing transaction operations on the plurality of databases, and the method comprises the following steps:

2. The method of claim 1, wherein determining a target routing identifier according to the service request comprises:

acquiring a data source switching strategy corresponding to the service system;

3. The method of claim 2, wherein determining the target routing identifier according to the routing indication information comprises:

4. The method according to claim 2, wherein the number of data source switching strategies corresponding to the service system is plural; according to the data source switching strategy, analyzing the service request to obtain routing indication information, including:

5. The method according to any one of claims 1 to 4, wherein determining the connection information of the target database according to the target routing identifier comprises:

6. The method of claim 5, wherein prior to obtaining the set of data source routing information, the method further comprises:

7. The method of claim 6, wherein obtaining the route identifier of each route and the connection information of the database corresponding to each route according to the first configuration file comprises:

8. A business data processing apparatus, applied to a business system, where a plurality of databases and a transaction manager are deployed in the business system, and the apparatus is configured to perform a transaction operation on the plurality of databases, and includes:

9. An electronic device, comprising: a memory for storing a computer program and a processor for executing the computer program to implement the method of any one of claims 1 to 7.

10. A computer-readable storage medium, comprising: computer program which, when executed by a processor, implements the method of any one of claims 1 to 7.

11. A computer program product, comprising: computer program which, when executed by a processor, implements the method of any one of claims 1 to 7.