Detailed Description
It is found through research that in practical applications, although the services processed by many systems are different, the operations actually involved are similar, for example, in the examples mentioned in the background art, no matter the service systems, such as deposit, financing, balance, red packet, etc., all require functions, such as querying, depositing, taking, freezing, unfreezing, etc., from the perspective of database operations, the processing logic corresponding to the same operation among different services is completely the same, and the difference is only different in the target database corresponding to the operation. Based on the situation, the scheme provided by the application is as follows: a set of general database operation logic is developed for multiplexing of multiple services, and when a specific service is processed, the general operation is only required to be directed to the database corresponding to the service.
In order to make those skilled in the art better understand the technical solutions in the present application, the technical solutions in the embodiments of the present application will be described in detail 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 embodiments. All other embodiments that can be derived from the embodiments given herein by a person of ordinary skill in the art are intended to be within the scope of the present disclosure.
Still taking the accounting system as an example, the service multiplexing scheme provided in the present application is described, and fig. 2 is a schematic diagram of an architecture of a comprehensive accounting system provided in the present application. The system comprises: service interface layer 100, service data routing layer 200, general instruction base 300, and database 400.
Service interface layer 100: the system is responsible for receiving service operation requests sent to the system from the outside of the system. As shown in fig. 1, the integrated financial system can receive operation requests of a plurality of services, such as deposit service, financial service, card and ticket service, and at an interface level, the receiving logic of the operation requests of different services is unified.
Service data routing layer 200: is responsible for routing service operation requests received by the service interface layer 100 to the corresponding database. The main functions include:
calling a corresponding general service operation instruction from the general instruction library 300 according to the operation type;
and determining the actual storage position of the current business operation object data according to the business type, and constructing an actual business operation instruction for processing the current business according to the called general business operation instruction. Depending on the actual usage of the database, the storage location may include two specific information, namely "library location" and "table location", which will be further described in the following embodiments.
The general instruction library 300: a plurality of general service operation instruction codes are stored, such as query operation statements, freezing operation statements, unfreezing operation statements and the like. In these statements, the storage location of the specific operation object in the database does not need to be specified, and the corresponding part in the statement may be left empty or replaced with some sort of identifier. A particular statement may apply to all traffic types. When a general service operation command is called by the service data routing layer 200, it will be reconstructed as an actual service operation command together with the actual storage location of the service operation object data.
The database 400: in the scheme provided by the application, different services can use independent physical databases respectively, and the utilization rate of database resources can be improved by sharing the same physical database. For the latter mode, the data storage locations of different services may be divided in a logical database mode, and the service operation is directed to the corresponding logical database in combination with the routing function of the service data routing layer 200, thereby ensuring data isolation between services.
It can be seen that, in the multi-service multiplexing system provided in the present application, the service data routing layer 200 is a core functional component, and the following will describe the basic functions of the service data routing layer 200 with reference to specific examples:
1) and (3) database configuration:
the scheme provided by the application not only supports different services to use independent physical database resources respectively, but also supports different services to share the same physical database resources. The former way is the same as the database resource using way in the prior art, and is not further described in the application; the latter method can be further divided into the case of storing in a database or a table. Some services have very large access volume, and the databases need to be subjected to database partitioning and table partitioning to support huge service access volume. On the contrary, if the service access amount is not large, resources do not need to be wasted for database division or table division, and only a single database single table or a single database sub table needs to be configured.
Assume that there are M physical databases in the system: db0, db1, … dbM-1, then for any service x:
if x is configured to use a single bank, i.e., the number of sub-banks mx1, any 1 of the M physical databases may be used to store business data;
if x is configured to use sub-banks, i.e. the number of sub-banks is 1<mxM ≦ M, any M of the M physical databases may be usedxStoring the service data;
for the case of a single library, the method can be directly configured as single table storage and can also be configured as sub-table storage; for the case of sub-base, only sub-table storage can be configured. To facilitate uniform computation and expansion, the number n of data tables is typically setxIs set as mxInteger multiples of.
Data tables between different services are distinguished by service identities, for example:
for service x, the data table name it correspondingly uses is: x _000, x _001, x _002, … …
For service y, the data table name used correspondingly is: y _000, y _001, y _002, … …
Of course, the above naming convention is for illustrative purposes only and should not be construed as limiting the scope of the present application.
2) Data routing:
the data routing comprises two parts, namely library routing and table routing, and during actual application, the data routing needs to be accurately routed to a specific sub-library and a specific sub-table according to the service type and certain characteristics of service operation target data.
Suppose that for service x, its user data is stored in m in sequence according to user number accountNoxN of each sub-libraryxIn each sub-table, the library route and table route calculation method is as follows:
library routing:
under the condition of single base, the base position is the service type number% M;
in the case of binning, binning bit ═ (accountNo% nx)/(nx/mx)
Table routing:
in the case of a single table, there is no branch table, and the corresponding table name is "service identifier";
in the case of the sublist, the sublist bit is (accountNo% n)x) The corresponding table name is "service identifier _ sub-table".
In the above formula, "%" represents a remainder operation, and "/" represents an integer division operation.
The following describes the database configuration and data routing scheme of the present application with reference to specific examples:
it is assumed that the system supports deposit, financing and card services simultaneously and has 5 physical databases db0, db1, … db 4. According to the service requirement, the configuration is as follows:
deposit service: using 5 databases and 100 data tables in total, wherein each database comprises 20 data tables;
financing service: using 1 database and 10 data tables in total;
card ticket business: 1 database and 1 data table are used;
specific configuration information is shown in table 1, where "service type code" is used to distinguish different services, "type number" is used to distinguish different sub-libraries, and "type suffix" is used to distinguish sub-tables of different services.
Type of service
|
Service type coding
|
Type numbering
|
Type suffix
|
Whether to divide the warehouse or not
|
Number of sub-banks
|
Whether to divide the table
|
Number of sub-meters
|
Deposit transaction
|
DTTRANS
|
0
|
dt
|
true
|
5
|
true
|
100
|
Financing service
|
FDTRANS
|
1
|
fd
|
false
|
1
|
true
|
10
|
Card ticket business
|
FDTRANS
|
2
|
cp
|
false
|
1
|
false
|
1 |
TABLE 1
Assuming that the user number accountNo is 2015092201234, the database and the data table corresponding to the data in each service data item can be calculated according to the number and the configuration in table 1.
For a deposit transaction:
mx=5,nx=100;
(accountNo% n)x)/(nx/mx) 34/20 ═ 1, corresponding to the physical database db 1;
epitope (accountNo% n)x) The corresponding table name is dt _034, 34.
For financial services:
mx=1,nx=10
the database sharing position is the service type number% M1, and the corresponding physical database is db 1;
epitope (accountNo% n)x) The corresponding table name is fd _004 ═ 4.
For a card transaction:
mx=1,nx=1
the database dividing position is the service type number% M2, and the corresponding physical database is db 2;
the sub-table bit does not exist and the corresponding table name is cp.
It will be appreciated that the above database configuration and data routing scheme is not the only embodiment of the present application. For example, the following steps are carried out: the single-library bit uses a calculation formula: the number of the service type is% M, which aims to distribute different single-base services to each physical database on average, and there are many actual database configuration modes, for example, for the case that there are 5 physical databases, all the single-base services can be distributed to the database db0, and the sub-base services can be distributed to the databases db 1-db 4, so the data routing calculation formula also needs to be adjusted accordingly. In addition, the naming rules of the database and the data table in practical application, the storage allocation rules of each piece of data, and other factors all affect the corresponding data routing calculation formula. In summary, the above detailed description should not be construed as limiting the present application.
On the basis of the above database configuration and data routing scheme, the present application provides a multi-service multiplexing processing method, where an execution subject of the method is a service data routing layer 200 in a system, and in an execution process, basic information of a service operation needs to be obtained from a service operation request forwarded by a service interface layer 100, a general service operation instruction is called from a general instruction library 300, and a database 400 is used as a final operation object, as shown in fig. 3, the method may include the following steps:
s101, receiving a service operation request, and determining a service type to be processed and a corresponding operation type;
still taking the aforementioned accounting system as an example, the types of the pending transactions may include: deposit, financial, card and ticket transactions, etc., and the corresponding types of operations may include: the query, the storage, the extraction, the freezing, the thawing, and the like, which are all obtained by analyzing the service operation request, are not further described in detail in this application.
S102, determining the storage position of the service data in a database according to the type of the service to be processed;
if the independent physical databases are respectively used among different services, determining the storage position of the service data in the database directly according to the corresponding relation between the service data and the physical databases;
if the same physical database is shared among different services, the method provided in the previous embodiment is adopted to determine the logical storage location of the service data in the general physical database. According to the specific service data storage situation, operations such as determining a sub-library bit, a sub-library bit and the like may be included, and the specific process is not described repeatedly in this embodiment.
In a multi-thread operating environment, each type of processing thread with fixed identification features may be assigned, for example, a service type name is encoded in a specific manner, an interceptor is set at the service interface layer 100, a thread variable is set according to a preset rule, from the perspective of a thread, each thread maintains an implicit reference to a copy of a local variable of the thread, and the thread variable is always valid and accessible during a life cycle of a thread, so that when a data routing layer processes, a service code may be directly extracted according to a variable of a current service processing process, and then a corresponding service data storage location is further determined. The method does not need to really know the service type by the data routing layer, only needs to inquire according to the identification characteristics of the threads, and can better meet the resource sharing problem of multiple threads. Of course, this approach should not be construed as limiting the scope of the claimed subject matter.
S103, acquiring a preset general service operation instruction for processing the operation type according to the operation type of the service to be processed;
in the general instruction library, a plurality of general service operation instruction codes are stored in advance, and only basic processing logic is contained in the instruction codes without indicating the storage position of a specific operation object in the database.
Assuming that the operation type of the service to be processed is "query", taking account information query as an example, the general query instruction code form is as follows:
connect to [ library name ]
The/representation is connected to a designated library, here pseudo code, which is implemented differently in different operating environments;
select from table name, where account no user number
// here is the sql statement
The content in the middle brackets is not specifically indicated, and after the specific content is indicated for the variable in the middle brackets in the subsequent steps, the statement can be correspondingly used for processing inquiry operations of various services such as deposit, financial management, card and ticket services and the like.
It should be noted that the execution order of S102 and S103 is not specifically limited in sequence.
S104, constructing an actual service operation instruction by using the determined service data storage position and the obtained general service operation instruction;
assuming that the user number is 2015092201234, the type of the service to be processed is "deposit service", the operation type is "account information inquiry",
according to the calculation of S102, the service data is stored in the data table dt _034 of the database db1, and the unspecified content is replaced according to the general query instruction code obtained in S103, and the actual service operation instruction code is reconstructed as follows:
connect to db1
// pseudo-code, representing a connection to db 1;
select*from dt_034in where account_no=’2015092201234’
a// sql statement;
and S105, executing an actual service operation instruction to respond to the service operation request.
Therefore, the scheme provided by the application completely isolates different service data based on the horizontal expansion of the database of the service channel, establishes and supports various service systems under different service systems, and provides a complete solution for the access of new services in the future; due to the reusability of the operation logic, when a new service is added, the service function can be directly realized only by adding a set of database configuration, and the development and maintenance cost is effectively reduced. In addition, the use mode of the database can be flexibly configured through a data routing algorithm, so that the optimal utilization of database resources is realized.
In addition, although the above embodiments are described only in terms of accounting system applications, the application scenario should not be construed as limiting the application scheme. For example, in a game platform, the management logic of different in-game information is the same, including user registration, login, points, in-purchase, achievement and the like, the corresponding operation logic can be designed as a general operation instruction, and the scheme of the application realizes the unified management of the same game platform on a plurality of games. Similar application scenarios are not illustrated here, and in summary, according to the solution provided in the present application, a person skilled in the art can design a multi-service multiplexing scheme applied to other scenarios without creative effort.
Corresponding to the above method embodiment, the present application further provides a multi-service multiplexing processing apparatus, which is functionally equivalent to the service data routing layer in the foregoing embodiment, and as shown in fig. 4, the apparatus may include:
a request receiving module 110, configured to receive a service operation request, and determine a service type to be processed and a corresponding operation type;
a storage location determining module 120, configured to determine, according to the type of the service to be processed, a storage location of the service data in the database;
a general operation instruction obtaining module 130, configured to obtain a preset general service operation instruction for processing an operation type according to the operation type of a service to be processed, where an actual storage location of operation object data is not specified in the general service operation instruction;
an actual operation instruction constructing module 140, configured to construct an actual service operation instruction by using the determined service data storage location and the obtained general service operation instruction;
and the execution module 150 is configured to execute the actual service operation instruction to respond to the service operation request.
In a specific embodiment of the present application, each type of service corresponds to a processing thread having a fixed identification feature; accordingly, the storage location determining module 120 may be specifically configured to determine the storage location of the service data in the database according to the currently used service processing thread identification feature.
In a specific embodiment of the present application, different types of services share the same physical database; accordingly, the storage location determining module 120 may be specifically configured to determine the logical storage location of the business data in the common physical database.
The implementation process of the functions and actions of each module in the above device is specifically described in the implementation process of the corresponding step in the above method, and is not described herein again.
From the above description of the embodiments, it is clear to those skilled in the art that the present application can be implemented by software plus necessary general hardware platform. Based on such understanding, the technical solutions of the present application may be essentially or partially implemented in the form of a software product, which may be stored in a storage medium, such as a ROM/RAM, a magnetic disk, an optical disk, etc., and includes several instructions for enabling a computer device (which may be a personal computer, a server, or a network device, etc.) to execute the method according to the embodiments or some parts of the embodiments of the present application.
The embodiments in the present specification are described in a progressive manner, and the same and similar parts among the embodiments are referred to each other, and each embodiment focuses on the differences from the other embodiments. In particular, for the apparatus embodiment, since it is substantially similar to the method embodiment, it is relatively simple to describe, and reference may be made to some descriptions of the method embodiment for relevant points. The above-described apparatus embodiments are merely illustrative, and the modules described as separate components may or may not be physically separate, and the functions of the modules may be implemented in one or more software and/or hardware when implementing the solution of the present application. And part or all of the modules can be selected according to actual needs to achieve the purpose of the scheme of the embodiment. One of ordinary skill in the art can understand and implement it without inventive effort.
The foregoing is directed to embodiments of the present application and it is noted that numerous modifications and adaptations may be made by those skilled in the art without departing from the principles of the present application and are intended to be within the scope of the present application.