CN115994825A

CN115994825A - Abnormal service processing method, device, equipment and storage medium

Info

Publication number: CN115994825A
Application number: CN202211460441.0A
Authority: CN
Inventors: 何佳存; 滕达
Original assignee: Industrial and Commercial Bank of China Ltd ICBC
Current assignee: Industrial and Commercial Bank of China Ltd ICBC
Priority date: 2022-11-21
Filing date: 2022-11-21
Publication date: 2023-04-21

Abstract

The disclosure provides a method, a device, equipment and a storage medium for processing abnormal services, which can be applied to the technical field of information security. The method is applied to a unitized architecture and comprises the following steps: responding to a transaction request received from a user, acquiring a user identifier corresponding to the current transaction, and determining a first unit in a unitized architecture according to the transaction request; executing a first business logic corresponding to the transaction request through a first unit to obtain first execution data, wherein the first business logic comprises operation logic of the current transaction; in response to determining that the first execution data characterizes the current transaction as an abnormal service, determining a second unit in the unitized architecture based on the user identification and the partition rules, the second unit for executing second service logic including operation logic to restore the abnormal service to a normal service; and executing the second business logic through the second unit to obtain second execution data corresponding to the transaction request so as to restore the running state of the current transaction.

Description

Abnormal service processing method, device, equipment and storage medium

Technical Field

The present disclosure relates to the field of information security technologies, and in particular, to an abnormal service processing method, an apparatus, an electronic device, a storage medium, and a program product.

Background

The unitized architecture is an enterprise application deployment architecture that deploys execution units according to users. Specifically, multiple groups of users are deployed inside multiple execution units of the unitized architecture, and each execution unit is deployed with a main business service required by the user.

In the related art, when a transaction is abnormal, the distributed transaction platform initiates anti-transaction to a plurality of execution units executing the service to ensure service consistency. Because the distributed transaction platform initiates anti-transaction to all execution units, the abnormal business processing process occupies more computer resources, and the processing efficiency of the abnormal business is affected.

Disclosure of Invention

In view of the foregoing, the present disclosure provides an abnormal service processing method, apparatus, device, storage medium, and program product.

According to a first aspect of the present disclosure, there is provided an abnormal service processing method applied to a unitized architecture, the method including:

in response to receiving a transaction request from a user, obtaining a user identification corresponding to a current transaction,

determining a first unit for executing transaction business in the unitized architecture according to the transaction request;

executing a first business logic corresponding to the transaction request through a first unit to obtain first execution data, wherein the first business logic comprises operation logic of the current transaction;

In response to determining that the first execution data characterizes the current transaction as an abnormal service, determining a second unit in the unitized architecture based on the user identification and the partition rules, the second unit for executing second service logic including operation logic to restore the abnormal service to a normal service; and

and executing the second business logic through the second unit to obtain second execution data corresponding to the transaction request so as to restore the running state of the current transaction.

According to an embodiment of the present disclosure, in response to receiving a transaction request from a user, acquiring a user identifier corresponding to a current transaction, and determining a first unit for executing a transaction service in a unitized architecture according to the transaction request, including:

before executing a first business logic corresponding to the transaction request through a first unit, acquiring a target method from graph storage data, wherein the target method is used for acquiring a user identifier, and the graph storage data is used for caching the target method;

taking the transaction parameters of the current transaction as parameters of a target method, executing the target method, and obtaining a user identifier; and

storing the user identification and the transaction log to a common unit in the unitized structure for managing the service, the transaction log comprising an execution record for obtaining the user identification.

According to the embodiment of the disclosure, the target method is added to the unitized architecture through the annotation, and the target method is used as an attribute value of a target attribute in the annotation and used for acquiring the user identification of the transaction.

According to an embodiment of the present disclosure, the method further comprises:

after the first unit is started, a target method is obtained from a preset address according to the annotated target attribute of the current transaction;

taking the name of the execution method of the first unit as a main key of the key value pair, taking the target method as the key value of the key value pair, and constructing graph storage data; and

the graph store data is cached to the memory of the common unit.

According to an embodiment of the present disclosure, the user identification comprises a digital combination in a preset form;

in response to determining that the first execution data characterizes the current transaction as an anomalous business, determining a second unit in the unitized architecture based on the user identification and the partition rules, comprising:

calculating an execution unit to which the current transaction belongs according to the digital combination and the partitioning rule, wherein the partitioning rule at least comprises one of the following: random partition rules and sequential partition rules; and

in the case where the execution unit is different from the first unit, the execution unit is determined as the second unit.

According to an embodiment of the present disclosure, wherein calculating an execution unit to which a current transaction belongs according to a digital combination and partitioning rule includes:

obtaining a partition calculation result of the current transaction according to the number of the partition units of the digital combination and unitization framework, wherein each of the partition units is used for executing a transaction request from a user; and

and determining an execution unit to which the current transaction belongs according to the partition calculation result and the partition rule.

According to an embodiment of the present disclosure, executing, by a second unit, second service logic to obtain second execution data corresponding to a transaction request so as to restore an operation state of a current transaction, includes:

determining a second service logic corresponding to the first service logic in response to an execution request initiated by the common unit to the second unit;

executing the second business logic through a processor in the second unit, and recovering the running state of the current transaction to the normal business state to obtain second execution data corresponding to the transaction request.

A second aspect of the present disclosure provides an abnormal service processing apparatus applied to a unitized architecture, including:

the acquisition module is used for responding to a transaction request received from a user, acquiring a user identifier corresponding to the current transaction, and determining a first unit for executing transaction business in the unitized architecture according to the transaction request;

The first execution module is used for executing first business logic corresponding to the transaction request through the first unit to obtain first execution data, wherein the first business logic comprises operation logic of the current transaction;

a determining module, configured to characterize the current transaction as an abnormal service in response to the first execution data, and determine a second unit in the unitized architecture based on the user identifier and the partition rule, where the second unit is used for second service logic, and the second service logic includes operation logic for restoring the abnormal service to a normal service; and

and the second execution module is used for executing the second business logic through the second unit to obtain second execution data corresponding to the transaction request so as to restore the running state of the current transaction.

A third aspect of the present disclosure provides an electronic device, comprising: one or more processors; and a memory for storing one or more programs, wherein the one or more programs, when executed by the one or more processors, cause the one or more processors to perform the above-described abnormal traffic processing method.

A fourth aspect of the present disclosure also provides a computer-readable storage medium having stored thereon executable instructions that, when executed by a processor, cause the processor to perform the above-described abnormal traffic handling method.

The fifth aspect of the present disclosure also provides a computer program product comprising a computer program which, when executed by a processor, implements the above-described abnormal service handling method.

According to an embodiment of the disclosure, a first unit for executing a transaction service in a unitized architecture is determined from a transaction request by responding to a transaction request received from a user; executing a first business logic corresponding to the transaction request through a first unit to obtain first execution data; in response to determining that the first execution data characterizes the current transaction as an abnormal service, determining a second unit in the unitized architecture based on a user identification corresponding to the current transaction obtained according to the transaction request and the partitioning rule; and executing the second business logic through the second unit to obtain second execution data corresponding to the transaction request. Therefore, the point-to-point routing of the anti-transaction under the abnormal service scene is realized, the anti-transaction is not required to be routed to all execution units, the downstream route receiver is reduced, the computer space for storing a plurality of route operations is released, and the abnormal service processing efficiency is improved.

In addition, under the condition that the partition rule or the execution unit is changed, the point-to-point routing of the anti-transaction under the abnormal service scene can still be realized through the scheme, and the situation that the anti-transaction point-to-point routing cannot be conducted to the correct unit, so that abnormal service cannot be processed is avoided.

Drawings

The foregoing and other objects, features and advantages of the disclosure will be more apparent from the following description of embodiments of the disclosure with reference to the accompanying drawings, in which:

fig. 1 schematically illustrates an application scenario of an abnormal service processing method according to an embodiment of the present disclosure;

FIG. 2 schematically illustrates a flow chart of an abnormal traffic handling method according to an embodiment of the present disclosure;

FIG. 3 schematically illustrates a flow chart of a method of obtaining user identification according to an embodiment of the disclosure;

FIG. 4 schematically illustrates a caching method flow diagram of a target method according to an embodiment of the disclosure;

FIG. 5 schematically illustrates a flow chart of a method of determining a second unit according to an embodiment of the disclosure;

FIG. 6 schematically illustrates a unitized architecture schematic according to an embodiment of the present disclosure;

FIG. 7 schematically illustrates a block diagram of an abnormal traffic handling apparatus according to an embodiment of the present disclosure; and

fig. 8 schematically illustrates a block diagram of an electronic device adapted for an abnormal traffic handling method according to an embodiment of the present disclosure.

Detailed Description

Hereinafter, embodiments of the present disclosure will be described with reference to the accompanying drawings. It should be understood that the description is only exemplary and is not intended to limit the scope of the present disclosure. In the following detailed description, for purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of the embodiments of the present disclosure. It may be evident, however, that one or more embodiments may be practiced without these specific details. In addition, in the following description, descriptions of well-known structures and techniques are omitted so as not to unnecessarily obscure the concepts of the present disclosure.

The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of the disclosure. The terms "comprises," "comprising," and/or the like, as used herein, specify the presence of stated features, steps, operations, and/or components, but do not preclude the presence or addition of one or more other features, steps, operations, or components.

All terms (including technical and scientific terms) used herein have the same meaning as commonly understood by one of ordinary skill in the art unless otherwise defined. It should be noted that the terms used herein should be construed to have meanings consistent with the context of the present specification and should not be construed in an idealized or overly formal manner.

Where expressions like at least one of "A, B and C, etc. are used, the expressions should generally be interpreted in accordance with the meaning as commonly understood by those skilled in the art (e.g.," a system having at least one of A, B and C "shall include, but not be limited to, a system having a alone, B alone, C alone, a and B together, a and C together, B and C together, and/or A, B, C together, etc.).

In the technical scheme of the disclosure, the related data (such as including but not limited to personal information of a user) are collected, stored, used, processed, transmitted, provided, disclosed, applied and the like, all conform to the regulations of related laws and regulations, necessary security measures are adopted, and the public welcome is not violated.

The embodiment of the disclosure provides an abnormal service processing method, which is applied to a unitized architecture, and comprises the following steps: responding to a transaction request received from a user, acquiring a user identifier corresponding to the current transaction, and determining a first unit for executing transaction business in a unitized architecture according to the transaction request; executing a first business logic corresponding to the transaction request through a first unit to obtain first execution data, wherein the first business logic comprises operation logic of the current transaction; in response to determining that the first execution data characterizes the current transaction as an abnormal service, determining a second unit in the unitized architecture based on the user identification and the partition rules, the second unit for executing second service logic including operation logic to restore the abnormal service to a normal service; and executing the second business logic through the second unit to obtain second execution data corresponding to the transaction request so as to restore the running state of the current transaction.

In the related art, when the service application software initiates a distributed transaction, a main transaction and all sub-transactions initiate registration to a distributed transaction platform and store transaction data corresponding to the transaction. Under the condition that two sub-transactions exist under one main transaction, the main transaction registers one piece of main transaction information with a transaction platform before the main transaction initiates a transaction, and the transaction platform receives the registered transaction information through a transaction receiver and persists to a transaction processor. Then, the transaction platform realizes normal call of transaction business by sequentially calling the business 1 and the sub-business 2. The sub-transaction also annotates booklet transaction information to the transaction platform and associates the booklet transaction information with corresponding main transaction information before executing the actual transaction service. When the orthogonality of the main transaction or the sub-transaction is easy to be abnormal, the transaction processor can inform all the sub-transactions to execute anti-transaction so as to ensure the consistency of the whole transaction.

Wherein, orthogonal easiness refers to normal transaction business, including deposit, withdrawal and the like; a transaction in which the opposite transaction is in the opposite direction to the orthogonal direction is also referred to as a punch-forward transaction. The anti-transaction is used to correct abnormal positive transactions due to system failures and the like.

Under the unitized architecture, the distributed transaction platform is planned to a common unit, and the main transaction business is concentrated in a partition unit, and the partition unit is divided into a plurality of sub-units. Different transactions are accessed to corresponding subunits according to the user ID to conduct positive transactions or negative transactions. While conducting the positive transaction, the business application may be directed to initiate a request to the transaction platform because the transaction platform is in a common unit. However, when the transaction platform initiates an anti-transaction to the business application, the anti-transaction cannot be normally routed to the partition unit where the current transaction is located because the partition rules of the partition unit may change. Although the related art can inform all partition units to execute anti-transaction, under the condition that a plurality of orthogonalities are easy to be abnormal, the number of instructions for initiating the call of the anti-transaction is huge, the occupied space of resources is large, and the execution efficiency is affected.

Fig. 1 schematically illustrates an application scenario of an abnormal service processing method according to an embodiment of the present disclosure.

As shown in fig. 1, an application scenario 100 according to this embodiment may include a first terminal device 101, a second terminal device 102, a third terminal device 103, a network 104, and a server 105. The network 104 is a medium used to provide a communication link between the first terminal device 101, the second terminal device 102, the third terminal device 103, and the server 105. The network 104 may include various connection types, such as wired, wireless communication links, or fiber optic cables, among others.

The user may interact with the server 105 through the network 104 using at least one of the first terminal device 101, the second terminal device 102, the third terminal device 103, to receive or send messages, etc. Various client applications, such as a payment type application, a banking client, a web browser application, etc., may be installed on the first terminal device 101, the second terminal device 102, the third terminal device 103 so that a user performs a transaction operation through the client applications.

The first terminal device 101, the second terminal device 102, the third terminal device 103 may be various electronic devices having a display screen and supporting web browsing, including but not limited to smartphones, tablets, laptop and desktop computers, and the like.

The server 105 may be a server providing various services, such as a background management server (by way of example only) providing support for websites browsed by the user using the first terminal device 101, the second terminal device 102, and the third terminal device 103. The background management server may analyze and process the received data such as the user transaction request, and feed back the processing result (e.g., a web page, information, or data obtained or generated according to the user transaction request) to the terminal device.

It should be noted that, the method for processing abnormal services provided in the embodiment of the present disclosure may be generally performed by the server 105. Accordingly, the abnormal service processing apparatus provided by the embodiments of the present disclosure may be generally disposed in the server 105. The abnormal service processing method provided by the embodiment of the present disclosure may also be performed by a server or a server cluster that is different from the server 105 and is capable of communicating with the first terminal device 101, the second terminal device 102, the third terminal device 103, and/or the server 105. Accordingly, the abnormal service processing apparatus provided by the embodiments of the present disclosure may also be provided in a server or a server cluster that is different from the server 105 and is capable of communicating with the first terminal device 101, the second terminal device 102, the third terminal device 103, and/or the server 105.

It should be understood that the number of terminal devices, networks and servers in fig. 1 is merely illustrative. There may be any number of terminal devices, networks, and servers, as desired for implementation.

Fig. 2 schematically illustrates a flowchart of an abnormal traffic handling method according to an embodiment of the present disclosure.

As shown in fig. 2, the method includes operations S210 to S240.

In operation S210, in response to receiving a transaction request from a user, a user identification corresponding to a current transaction is acquired, and a first unit for executing a transaction service in a unitized architecture is determined according to the transaction request.

According to the embodiment of the disclosure, after a user performs a login operation on a web page end or a certain bank client, a transaction request can be initiated through the web page end or the certain bank client. Since the user has completed the login operation, the user's transaction request includes the user's identification information.

In response to receiving a transaction request from a user, a user identification of the current transaction may be obtained by invoking a preset method, where the user identification may be a user ID.

Under the unitized architecture, in response to receiving a transaction request from a user, a web page end or a certain bank client can directly route the main transaction service of the user to a first unit executing the current transaction service; a request is then initiated by the first unit to the distributed transaction platform and transaction information is registered.

According to an embodiment of the present disclosure, the transaction request may include historical execution unit information of the current user, and the first unit in the unitized structure corresponding to the current user may be determined according to the historical execution unit information. The first unit may also be determined directly from the user identification in the transaction request.

In operation S220, first execution data is obtained by the first unit executing the first business logic corresponding to the transaction request.

According to an embodiment of the present disclosure, the first business logic includes operational logic of the current transaction. In particular, the current transaction includes various types of transaction transactions, such as deposit transactions, withdrawal transactions, transfer transactions, and the like. The multiple types of transaction services correspond to multiple types of service logic.

According to an embodiment of the present disclosure, the first business logic corresponds to a normal business logic for executing a current transaction. The second business logic comprises operation logic for restoring the abnormal business to the normal business, wherein the second business logic corresponds to the anti-transaction and is used for executing the business logic with the opposite direction to the first business logic.

According to the embodiment of the disclosure, the first execution data is obtained by the first unit executing the first business logic corresponding to the transaction request. The first execution data includes an execution result and an operation state of the current transaction, wherein the execution result includes account information of the user after executing the first business logic, such as account balance, transfer amount, transfer person and the like, and prompt information after executing the first business logic, such as "transfer success" and "transfer time" and the like.

According to an embodiment of the present disclosure, the running status is used to indicate whether the current transaction is an abnormal transaction, including a normal transaction and an abnormal transaction.

For example, the current operation performed by user A is 500 yuan of withdrawal. The first unit executes first business logic of a withdrawal type, and after the first business logic is executed, the execution result is: updated account balance for user a, such as "current balance: 500 yuan ", prompting information" transfer failure ". The running state is "abnormal business".

In response to determining that the first execution data characterizes the current transaction as an anomalous business, a second unit in the unitized architecture is determined based on the user identification and the partition rules, the second unit for executing a second business logic in operation S230.

According to an embodiment of the present disclosure, in response to determining that the first execution data characterizes the current transaction as an abnormal service, the operational state of the current transaction is restored to a normal service by routing an execution request of the anti-transaction to an execution unit of the current transaction. Since the anti-transaction is initiated by the distributed transaction platform in the unitized architecture, the point-to-point correct routing of the anti-transaction is ensured by determining the execution unit of the current transaction before the execution request of the anti-transaction will be routed.

According to an embodiment of the present disclosure, after determining that the current transaction is an abnormal transaction, a second unit performing the current transaction is determined based on the user identification and the partition rules. Specifically, calculating information represented by a user identifier to obtain a partition calculation result; and determining an execution unit pointed by the partition calculation result based on the partition rule to obtain a second unit.

After the current transaction is determined to be the abnormal service, the partition rule and the execution unit can be changed according to the system upgrading operation or the system maintenance operation, so that the correct execution unit can be determined based on the user identification and the partition rule, and the running state of the current transaction cannot be corrected due to the change of the partition rule or the execution unit.

According to an embodiment of the present disclosure, partitioning rules are used to determine execution units for multiple groups of users.

In operation S240, the second business logic is executed by the second unit to obtain second execution data corresponding to the transaction request so as to restore the operation state of the current transaction.

According to an embodiment of the disclosure, after the second unit is determined, the second business logic is executed by the second unit, and second execution data corresponding to the transaction request is obtained. The second execution data is similar to the first execution data and comprises an execution result and an operation state, wherein the execution result comprises account information, prompt information and the like of a user, and the operation state comprises normal service and abnormal service.

According to an embodiment of the present disclosure, a first unit for executing a transaction service in a unitized architecture is determined from a transaction request by responding to a transaction request received from a user; executing a first business logic corresponding to the transaction request through a first unit to obtain first execution data; in response to determining that the first execution data characterizes the current transaction as an abnormal service, determining a second unit in the unitized architecture based on a user identification corresponding to the current transaction obtained according to the transaction request and the partitioning rule; and executing the second business logic through the second unit to obtain second execution data corresponding to the transaction request. Therefore, the point-to-point routing of the anti-transaction under the abnormal service scene is realized, the anti-transaction is not required to be routed to all execution units, the downstream route receiver is reduced, the computer space for storing a plurality of route operations is released, and the abnormal service processing efficiency is improved.

Fig. 3 schematically illustrates a flowchart of a method of obtaining a user identification according to an embodiment of the present disclosure.

As shown in fig. 3, the method for acquiring a user identifier of this embodiment includes operations S311 to S313, which may be a specific embodiment of operation S210.

In operation S311, a target method is acquired from the graph store data, the target method being used to acquire the user identification, before the first business logic corresponding to the transaction request is executed by the first unit.

According to an embodiment of the present disclosure, after a transaction request is received from a user, and before a first business logic corresponding to the transaction request is executed by a first unit, a target method is obtained from graph storage data, wherein the target method user obtains a user identification. That is, the target method for acquiring the user identification is acquired before the orthogonal cover of the current transaction is performed, so that the identification information of the user is recorded before the orthogonal cover is performed, so that the connection relationship between the user identification and the current transaction is established.

Wherein the graph stores data for caching the target method.

Specifically, the method name of the target method may be a getcustomerId method, and the calling operation in the target method may be custom developed by a service application or may be a standard format predefined by a developer.

According to an embodiment of the disclosure, a target method is added to the unitized framework through an annotation, and the target method is used as an attribute value of a target attribute in the annotation for acquiring a user identification of a transaction.

For example, by presetting the value of the attribute cidGetter on the transaction annotation @ Dtx to getCustomerId, the acquisition of the user ID of the current transaction is effected before executing the first business logic.

In operation S312, the target method is executed with the transaction parameters of the current transaction as parameters of the target method, and the user identification is obtained.

For example, the method of the current transaction is doMainTx, and the return result of the current transaction may be "success". When a transaction is initiated, a corresponding cidGetter method is obtained from the graph storage data according to the current method in the pre-enhancement of the main transaction section, the parameters of the original method are used as the parameters of the cidGetter method, and the cidGetter method is executed to obtain the user ID of the current transaction.

In operation S313, the user identification and the transaction log including the execution record for obtaining the user identification are stored to a common unit for managing services in the unitized structure.

According to embodiments of the present disclosure, after the user identification is obtained, the user identification and the transaction log are together persisted to a common gateway unit in a unitized structure for managing traffic, e.g., a distributed transaction platform.

The method and the system provide an entrance for acquiring the user identification when executing the transaction by acquiring the target method before executing the transaction and executing the target method to acquire the user identification, so that a user of the current transaction can be quickly positioned when an abnormality occurs, and point-to-point routing of the anti-transaction is realized.

Fig. 4 schematically illustrates a caching method flow diagram of a target method according to an embodiment of the disclosure.

As shown in fig. 4, the caching method of the target method of this embodiment includes operations S410 to S430. Operations S410 to S430 may be disposed before operation S230, or may be disposed before operation S210, for pre-caching the target method when the unitized architecture is started.

In operation S410, after the first unit is started, a target method is acquired from a preset address according to a target attribute of the annotation of the current transaction.

According to an embodiment of the present disclosure, the first unit is pre-fetched from the preset address after the first start-up or after the start-up of the unitized architecture. Specifically, a target method corresponding to the target attribute value is obtained from the preset address.

For example, the preset address is a method database, a character string including "cidGetter" is determined from the preset address of the method database, and then a method corresponding to the character string is taken as a target method.

In operation S420, the graph storage data is constructed with the execution method name of the first unit as the primary key of the key value pair and the target method as the key value of the key value pair.

According to the embodiment of the disclosure, after the target method is acquired, a map is constructed by taking a method name of an execution method of the first unit as a primary key of a key value pair and a method corresponding to the cidGetter as a key value. Still taking the doMainTx method as an example, the main key of the map constructed at this time is the name of the doMainTx method, and the key value is getCustomerId.

In operation S430, the graph store data is cached to the memory of the common unit.

According to an embodiment of the present disclosure, after constructing the graph store data including the acquisition of the user identification, the graph store data is cached to the memory of the common unit. In particular, the graph store data can be stored to a distributed transaction platform in a common unit to invoke the graph store data at the distributed transaction platform to determine a second unit and route the reconciliation of the anti-transaction to the second unit.

The graph store data can also be stored to other common units in addition to the distributed transaction platform for distributed transaction platform calls.

According to the method, the access method provided by the cache application when the project is started, the execution speed of the transaction is increased, and the processing efficiency of the transaction service is improved.

Fig. 5 schematically illustrates a flow chart of a method of determining a second unit according to an embodiment of the disclosure.

As shown in fig. 5, the second unit method of determining this embodiment includes operations S531 to S532, which may be a specific embodiment of operation S230.

In operation S531, an execution unit to which the current transaction belongs is calculated according to the digital combination and the partitioning rule, wherein the partitioning rule at least includes one of the following: random partitioning rules, sequential partitioning rules.

According to an embodiment of the present disclosure, the user identification comprises a combination of digits in a preset form, such as a user ID. For example, the user ID of the user "Zhang San", is 1001, and the user ID of the user "Lifour", is 1103.

The partition rule is used for determining execution units of multiple groups of users, wherein the partition rule at least comprises one of the following: random partitioning rules, sequential partitioning rules.

For example, taking a random partitioning rule as an example, users with tail numbers of singular numbers in the user ID are divided into the unit 1, and users with tail numbers of double numbers are divided into the unit 2. Taking the sequential partitioning rule as an example, users may be partitioned into units 1-9, respectively, in order of tail numbers from 0-9. Specifically, the partitioning rule and the number of partition units to be partitioned may be determined according to actual situations.

According to an embodiment of the present disclosure, calculating an execution unit to which a current transaction belongs according to a digital combination and partitioning rule includes: the partition calculation result of the current transaction is obtained according to the number of the partition units of the digital combination and unitization framework, and each of the partition units is used for executing the transaction request from the user. And determining an execution unit to which the current transaction belongs according to the partition calculation result and the partition rule.

For example, taking a standard form of digital combination as a user ID as an example, dividing the user ID by the number of partition units gives a partition calculation result. Wherein the partition calculation result includes a remainder obtained after the division operation.

The partition rule is defined according to the number of partition units, for example, the number of partition units is 4, corresponding to units 1 to 4. The partitioning rules include: the user with a remainder of 0 is divided into cell 1, the user with a remainder of 1 is divided into cell 2, the user with a remainder of 2 is divided into cell 3, and the user with a remainder of 3 is divided into cell 4. It is also possible to divide the user with a remainder of 0 into cell 4, the user with a remainder of 1 into cell 3, the user with a remainder of 2 into cell 2, and the user with a remainder of 3 into cell 1. It should be noted that the specific partitioning rule may be determined according to the actual situation.

After the calculation is performed according to the number of the partition units and the number combination of the user IDs, the execution unit of the current transaction can be determined according to the partition rule after the partition calculation result is obtained.

In operation S532, in the case where the execution unit is different from the first unit, the execution unit is determined as the second unit.

According to embodiments of the present disclosure, the partitioning rules may change as the user is conducting a positive transaction. At this point, the execution unit executing the first business logic is still orthogonal, since the user is conducting a transaction. However, in the case where the first execution data characterizes the current transaction as an abnormal transaction, the anti-transaction request needs to be routed to the execution unit after the partition change.

According to an embodiment of the present disclosure, after determining an execution unit that executes the second business logic, the execution unit is determined to be the same as the first unit, which is still taken as the execution unit that executes the second business logic.

In the event that the first execution data is determined to characterize the current transaction as an abnormal transaction, and the first unit is different from the execution unit, the execution unit for the second business logic is determined to be the second unit to which the anti-transaction request is to be routed.

According to the method and the device, under the condition that the transaction is abnormal, the execution unit where the current transaction is located is recalculated, so that the situation that the anti-transaction cannot be executed due to the change of the partition rule, and abnormal business cannot be processed is avoided.

According to an embodiment of the present disclosure, the second unit performs information interaction with a distributed transaction platform within the common unit. After the distributed transaction platform determines that the second unit is an execution unit, an execution request to invoke an anti-transaction is initiated to the second unit. The second unit determines a second business logic corresponding to the first business logic in response to an execution request from the distributed transaction platform within the common unit. The first business logic may be business logic corresponding to deposit, withdrawal or transfer, and the second business logic may be business logic opposite to deposit execution direction, business logic opposite to withdrawal execution direction, or business logic opposite to transfer execution direction. Specifically, the type of the second business logic has an association relationship with the first business logic executed by the current transaction.

According to an embodiment of the disclosure, the second unit includes a processor configured to execute second service logic, so as to restore the running state of the current transaction to the normal service state, and obtain second execution data corresponding to the transaction request.

Fig. 6 schematically illustrates a unitized architecture schematic according to an embodiment of the present disclosure.

As shown in FIG. 6, the unitized architecture 600 includes a partition unit including a plurality of execution units for executing business logic, such as "RZ 01-Unit 1"601, "RZ 02-Unit 2"602, "RZ 03-Unit 3"603, and "RZ 04-Unit 4"604, and a common unit including a distributed transaction platform 605 for managing traffic. Wherein the execution units within the partition unit include unit identifiers RZ01-RZ04 for distinguishing among the plurality of execution units.

According to an embodiment of the present disclosure, "RZ 01-Unit 1"601, "RZ 02-Unit 2"602, "RZ 03-Unit 3"603, and "RZ 04-Unit 4"604 are used to perform a first business logic and a second business logic corresponding to the first business logic, i.e., a forward transaction and an inverse transaction.

The distributed transaction platform 605 is used to interact with "RZ 01-Unit 1"601, "RZ 02-Unit 2"602, "RZ 03-Unit 3"603, and "RZ 04-Unit 4"604, so that the execution units execute both forward and reverse transactions upon request of the distributed transaction platform.

Fig. 7 schematically illustrates a block diagram of an abnormal service processing apparatus according to an embodiment of the present disclosure.

As shown in fig. 7, the abnormal service processing apparatus 700 of this embodiment includes an acquisition module 710, a first execution module 720, a determination module 730, and a second execution module 740.

And the acquiring module 710 is configured to acquire, in response to receiving a transaction request from a user, a user identifier corresponding to a current transaction, and determine a first unit for executing a transaction service in the unitized architecture according to the transaction request. In an embodiment, the obtaining module 710 may be configured to perform the operation S210 described above, which is not described herein.

The first execution module 720 is configured to execute, by using a first unit, a first service logic corresponding to the transaction request, to obtain first execution data, where the first service logic includes an operation logic of the current transaction. In an embodiment, the first execution module 720 may be configured to execute the operation S220 described above, which is not described herein.

A determining module 730, configured to characterize the current transaction as an abnormal service in response to the first execution data, and determine, based on the user identifier and the partition rule, a second unit in the unitized architecture, where the second unit is used for second service logic, and the second service logic includes operation logic for restoring the abnormal service to a normal service. In an embodiment, the determining module 730 may be configured to perform the operation S230 described above, which is not described herein.

And a second execution module 740, configured to execute the second service logic through the second unit, and obtain second execution data corresponding to the transaction request, so as to restore the running state of the current transaction. In an embodiment, the second execution module 740 may be configured to execute the operation S240 described above, which is not described herein.

According to an embodiment of the present disclosure, the acquisition module 710 includes a first acquisition unit, a second acquisition unit, and a third acquisition unit.

The first obtaining unit is used for obtaining a target method from the graph storage data before the first business logic corresponding to the transaction request is executed through the first unit, wherein the target method is used for obtaining the user identifier, and the graph storage data is used for caching the target method. In an embodiment, the first obtaining unit may be configured to perform the operation S311 described above, which is not described herein.

And the second acquisition unit is used for taking the transaction parameters of the current transaction as the parameters of the target method, executing the target method and obtaining the user identification. In an embodiment, the second obtaining unit may be configured to perform the operation S312 described above, which is not described herein.

And the third acquisition unit is used for storing the user identifier and the transaction log into a common unit used for managing the service in the unitized structure, and the transaction log comprises an execution record for obtaining the user identifier. In an embodiment, the second obtaining unit may be configured to perform the operation S313 described above, which is not described herein.

According to an embodiment of the present disclosure, the abnormal service processing apparatus 700 further includes a buffer module, where the buffer module includes a first buffer unit, a second buffer unit, and a third buffer unit.

The first caching unit is used for acquiring the target method from a preset address according to the target attribute of the annotation of the current transaction after the first unit is started. In an embodiment, the first buffer unit may be used to perform the operation S410 described above, which is not described herein.

The second cache unit is used for taking the name of the execution method of the first unit as a main key of a key value pair, taking the target method as a key value of the key value pair, and constructing the graph storage data. In an embodiment, the second buffer unit may be used to perform the operation S420 described above, which is not described herein.

The third buffer unit is used for buffering the graph storage data to the storage of the common unit. In an embodiment, the second buffer unit may be used to perform the operation S430 described above, which is not described herein.

According to an embodiment of the present disclosure, the determining module 730 includes a first determining unit and a second determining unit.

The first determining unit is configured to calculate, according to the number combination and the partitioning rule, an executing unit to which the current transaction belongs, where the partitioning rule at least includes one of the following: random partitioning rules, sequential partitioning rules. In an embodiment, the first determining unit may be configured to perform the operation S531 described above, which is not described herein.

The second determining unit is configured to determine the executing unit as a second unit in a case where the executing unit is different from the first unit. In an embodiment, the second determining unit may be configured to perform the operation S532 described above, which is not described herein.

According to an embodiment of the present disclosure, the first determination unit includes a first determination subunit and a second determination subunit.

The first determining subunit is configured to obtain a partition calculation result of the current transaction according to the number of the digital combinations and the partition units of the unitized framework, where each of the partition units is used to execute a transaction request from a user.

The second determining subunit is used for determining the executing unit to which the current transaction belongs according to the partition calculation result and the partition rule.

According to an embodiment of the present disclosure, the second execution module 740 includes a first execution unit and a second execution unit.

The first execution unit is used for responding to an execution request initiated by the public unit to the second unit and determining second business logic corresponding to the first business logic.

The second execution obtaining unit is used for executing the second business logic through a processor in the second unit, and restoring the running state of the current transaction to the normal business state to obtain second execution data corresponding to the transaction request.

According to an embodiment of the present disclosure, any of the acquisition module 710, the first execution module 720, the determination module 730, and the second execution module 740 may be combined in one module to be implemented, or any of the modules may be split into a plurality of modules. Alternatively, at least some of the functionality of one or more of the modules may be combined with at least some of the functionality of other modules and implemented in one module. According to embodiments of the present disclosure, at least one of the acquisition module 710, the first execution module 720, the determination module 730, and the second execution module 740 may be implemented at least in part as hardware circuitry, such as a Field Programmable Gate Array (FPGA), a Programmable Logic Array (PLA), a system on a chip, a system on a substrate, a system on a package, an Application Specific Integrated Circuit (ASIC), or may be implemented in hardware or firmware in any other reasonable way of integrating or packaging circuitry, or in any one of or a suitable combination of three of software, hardware, and firmware. Alternatively, at least one of the acquisition module 710, the first execution module 720, the determination module 730, and the second execution module 740 may be at least partially implemented as a computer program module, which when executed, may perform the corresponding functions.

As shown in fig. 8, an electronic device 800 according to an embodiment of the present disclosure includes a processor 801 that can perform various appropriate actions and processes according to a program stored in a Read Only Memory (ROM) 802 or a program loaded from a storage section 808 into a Random Access Memory (RAM) 803. The processor 801 may include, for example, a general purpose microprocessor (e.g., a CPU), an instruction set processor and/or an associated chipset and/or a special purpose microprocessor (e.g., an Application Specific Integrated Circuit (ASIC)), or the like. The processor 801 may also include on-board memory for caching purposes. The processor 801 may include a single processing unit or multiple processing units for performing the different actions of the method flows according to embodiments of the disclosure.

In the RAM803, various programs and data required for the operation of the electronic device 800 are stored. The processor 801, the ROM 802, and the RAM803 are connected to each other by a bus 804. The processor 801 performs various operations of the method flow according to the embodiments of the present disclosure by executing programs in the ROM 802 and/or the RAM 803. Note that the program may be stored in one or more memories other than the ROM 802 and the RAM 803. The processor 801 may also perform various operations of the method flows according to embodiments of the present disclosure by executing programs stored in the one or more memories.

According to an embodiment of the present disclosure, the electronic device 800 may also include an input/output (I/O) interface 805, the input/output (I/O) interface 805 also being connected to the bus 804. The electronic device 800 may also include one or more of the following components connected to the I/O interface 805: an input portion 806 including a keyboard, mouse, etc.; an output portion 807 including a display such as a Cathode Ray Tube (CRT), a Liquid Crystal Display (LCD), and a speaker; a storage section 808 including a hard disk or the like; and a communication section 809 including a network interface card such as a LAN card, a modem, or the like. The communication section 809 performs communication processing via a network such as the internet. The drive 810 is also connected to the I/O interface 805 as needed. A removable medium 811 such as a magnetic disk, an optical disk, a magneto-optical disk, a semiconductor memory, or the like is mounted on the drive 810 as needed so that a computer program read out therefrom is mounted into the storage section 808 as needed.

The present disclosure also provides a computer-readable storage medium that may be embodied in the apparatus/device/system described in the above embodiments; or may exist alone without being assembled into the apparatus/device/system. The computer-readable storage medium carries one or more programs which, when executed, implement methods in accordance with embodiments of the present disclosure.

According to embodiments of the present disclosure, the computer-readable storage medium may be a non-volatile computer-readable storage medium, which may include, for example, but is not limited to: a portable computer diskette, a hard disk, a Random Access Memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing. In the context of this disclosure, a computer-readable storage medium may be any tangible medium that can contain, or store a program for use by or in connection with an instruction execution system, apparatus, or device. For example, according to embodiments of the present disclosure, the computer-readable storage medium may include ROM 802 and/or RAM 803 and/or one or more memories other than ROM 802 and RAM 803 described above.

Embodiments of the present disclosure also include a computer program product comprising a computer program containing program code for performing the methods shown in the flowcharts. When the computer program product runs in a computer system, the program code is used for enabling the computer system to realize the abnormal business processing method provided by the embodiment of the present disclosure.

The above-described functions defined in the system/apparatus of the embodiments of the present disclosure are performed when the computer program is executed by the processor 801. The systems, apparatus, modules, units, etc. described above may be implemented by computer program modules according to embodiments of the disclosure.

In one embodiment, the computer program may be based on a tangible storage medium such as an optical storage device, a magnetic storage device, or the like. In another embodiment, the computer program may also be transmitted, distributed, and downloaded and installed in the form of a signal on a network medium, and/or from a removable medium 811 via a communication portion 809. The computer program may include program code that may be transmitted using any appropriate network medium, including but not limited to: wireless, wired, etc., or any suitable combination of the foregoing.

In such an embodiment, the computer program may be downloaded and installed from a network via the communication section 809, and/or installed from the removable media 811. The above-described functions defined in the system of the embodiments of the present disclosure are performed when the computer program is executed by the processor 801. The systems, devices, apparatus, modules, units, etc. described above may be implemented by computer program modules according to embodiments of the disclosure.

According to embodiments of the present disclosure, program code for performing computer programs provided by embodiments of the present disclosure may be written in any combination of one or more programming languages, and in particular, such computer programs may be implemented in high-level procedural and/or object-oriented programming languages, and/or assembly/machine languages. Programming languages include, but are not limited to, such as Java, c++, python, "C" or similar programming languages. The program code may execute entirely on the user's computing device, partly on the user's device, partly on a remote computing device, or entirely on the remote computing device or server. In the case of remote computing devices, the remote computing device may be connected to the user computing device through any kind of network, including a Local Area Network (LAN) or a Wide Area Network (WAN), or may be connected to an external computing device (e.g., connected via the Internet using an Internet service provider).

The flowcharts and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods and computer program products according to various embodiments of the present disclosure. In this regard, each block in the flowchart or block diagrams may represent a module, segment, or portion of code, which comprises one or more executable instructions for implementing the specified logical function(s). It should also be noted that, in some alternative implementations, the functions noted in the block may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams or flowchart illustration, and combinations of blocks in the block diagrams or flowchart illustration, can be implemented by special purpose hardware-based systems which perform the specified functions or acts, or combinations of special purpose hardware and computer instructions.

Those skilled in the art will appreciate that the features recited in the various embodiments of the disclosure and/or in the claims may be provided in a variety of combinations and/or combinations, even if such combinations or combinations are not explicitly recited in the disclosure. In particular, the features recited in the various embodiments of the present disclosure and/or the claims may be variously combined and/or combined without departing from the spirit and teachings of the present disclosure. All such combinations and/or combinations fall within the scope of the present disclosure.

While the foregoing is directed to embodiments of the present disclosure, other and further details of the invention may be had by the present application, it is to be understood that the foregoing description is merely exemplary of the present disclosure and that no limitations are intended to the scope of the disclosure, except insofar as modifications, equivalents, improvements or modifications may be made without departing from the spirit and principles of the present disclosure.

Claims

1. An abnormal business processing method applied to a unitized architecture, the method comprising:

responding to a transaction request received from a user, acquiring a user identifier corresponding to a current transaction, and determining a first unit for executing transaction business in the unitized architecture according to the transaction request;

Executing a first business logic corresponding to the transaction request through the first unit to obtain first execution data, wherein the first business logic comprises operation logic of the current transaction;

responsive to determining that the first execution data characterizes the current transaction as an abnormal business, determining a second unit in the unitized architecture based on the user identification and partition rules, the second unit for executing second business logic including operation logic to restore the abnormal business to a normal business; and

2. The method of claim 1, wherein the obtaining, in response to receiving a transaction request from a user, a user identification corresponding to a current transaction and determining a first unit in the unitized architecture for performing a transaction service according to the transaction request comprises:

before executing a first business logic corresponding to the transaction request through a first unit, acquiring a target method from graph storage data, wherein the target method is used for acquiring the user identifier, and the graph storage data is used for caching the target method;

Taking the transaction parameters of the current transaction as the parameters of the target method, and executing the target method to obtain the user identification; and

and storing the user identification and a transaction log to a common unit for managing services in the unitized structure, wherein the transaction log comprises an execution record for obtaining the user identification.

3. The method of claim 2, wherein the target method is added to the unitized framework by annotation and the target method is used to obtain a user identification of a transaction as an attribute value of a target attribute in the annotation.

4. A method according to claim 3, further comprising:

after the first unit is started, acquiring the target method from a preset address according to the annotated target attribute of the current transaction;

taking the name of the execution method of the first unit as a primary key of a key value pair, taking the target method as a key value of the key value pair, and constructing the graph storage data; and

the graph store data is cached to the memory of the common unit.

5. The method of claim 1, wherein the user identification comprises a combination of digits in a preset form;

The determining, in response to determining that the first execution data characterizes the current transaction as an anomalous traffic, a second unit in the unitized architecture based on the user identification and a partitioning rule, comprising:

in the case that the execution unit is different from the first unit, the execution unit is determined as a second unit.

6. The method of claim 5, wherein said calculating an execution unit to which a current transaction belongs based on said digital combination and said partitioning rules comprises:

obtaining a partition calculation result of the current transaction according to the number of the digital combination and the partition units of the unitized framework, wherein each of the partition units is used for executing a transaction request from a user; and

7. The method of claim 1, wherein the executing, by the second unit, the second business logic to obtain second execution data corresponding to the transaction request to restore an operational state of a current transaction comprises:

Determining a second business logic corresponding to the first business logic in response to an execution request initiated by the public unit to the second unit;

and executing the second business logic through a processor in the second unit, and recovering the running state of the current transaction to the normal business state to obtain second execution data corresponding to the transaction request.

8. An abnormal service processing device, applied to a unitized architecture, comprising:

9. An electronic device, comprising:

one or more processors;

storage means for storing one or more programs,

wherein the one or more programs, when executed by the one or more processors, cause the one or more processors to perform the method of any of claims 1-7.

10. A computer readable storage medium having stored thereon executable instructions which, when executed by a processor, cause the processor to perform the method according to any of claims 1-7.

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