Transaction processing method and device, equipment and storage medium

Abstract

The invention relates to the field of financial transactions, and discloses a transaction processing method, device and equipment and a storage medium, which can be applied to the financial field, and the method comprises the steps: obtaining a bank card transaction request, and taking a transaction request which does not accord with a concurrency judgment rule as an overrun request according to the preset concurrency judgment rule; acquiring affiliation information of the overrun request, wherein the affiliation information comprises card dimension information and bank dimension information; acquiring a corresponding concurrency control strategy according to the attribution information of the overrun request; and processing the overrun request according to the concurrency control strategy. The problems of easy transaction blockage and low efficiency in the prior art are solved.

Description

Technical Field

[0001] The present invention relates to the field of financial transactions, and in particular to a transaction processing method, apparatus, device and storage medium. Background Art

[0002] In financial transaction systems, different banks have different restrictions on concurrent processing of the same bank card. If ordinary concurrent scheduling methods are used, they may trigger the bank's concurrency restrictions, resulting in transaction failure or rejection.

[0003] Configuring concurrency by bank may easily cause other card transactions to be blocked: If concurrency resources are configured by bank, other card transactions of the same bank may be blocked, affecting overall transaction efficiency. Summary of the Invention

[0004] The present invention provides a transaction processing method, device, equipment and storage medium to solve the problems of easy transaction congestion and low efficiency in the prior art.

[0005] In a first aspect, a transaction processing method is provided, comprising: Obtain bank card transaction requests, and according to preset concurrency judgment rules, treat transaction requests that do not meet the concurrency judgment rules as over-limit requests; Obtaining attribution information of the over-limit request, the attribution information including card dimension information and bank dimension information; Obtaining a corresponding concurrency control strategy according to the attribution information of the excess request; Process the exceeding request according to the concurrency control strategy.

[0006] In a second aspect, a transaction processing device is provided, comprising: A request acquisition module is used to acquire bank card transaction requests and, based on preset concurrency judgment rules, classify transaction requests that do not meet the concurrency judgment rules as over-limit requests; An information acquisition module, configured to acquire attribution information of the over-limit request, wherein the attribution information includes card dimension information and bank dimension information; A policy acquisition module, configured to acquire a corresponding concurrency control policy according to the attribution information of the excess request; A processing module is used to process the excessive request according to the concurrency control strategy.

[0007] In a third aspect, a computer device is provided, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor implements the steps of the above-mentioned transaction processing method when executing the computer program.

[0008] In a fourth aspect, a computer-readable storage medium is provided, wherein the computer-readable storage medium stores a computer program, and when the computer program is executed by a processor, the steps of the above-mentioned transaction processing method are implemented.

[0009] The solution implemented by the above-mentioned transaction processing method, device, equipment and storage medium can be applied to the financial field, obtain bank card transaction requests, and according to the preset concurrency judgment rules, treat transaction requests that do not comply with the concurrency judgment rules as over-limit requests; obtain the attribution information of the over-limit request, the attribution information includes card dimension information and bank dimension information; obtain the corresponding concurrency control strategy according to the attribution information of the over-limit request; and process the over-limit request according to the concurrency control strategy. In the present invention, over-limit requests are accurately identified through the dual dimensions of "card + bank" to avoid indiscriminate congestion, and over-limit requests are processed based on differentiated concurrency control strategies to avoid resource waste and inefficient queuing, thus solving the problems of easy transaction congestion and low efficiency in the prior art. BRIEF DESCRIPTION OF THE DRAWINGS

[0010] In order to more clearly illustrate the technical solutions of the embodiments of the present invention, the following briefly introduces the drawings required for use in the description of the embodiments of the present invention. Obviously, the drawings described below are only one embodiment of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without creative work.

[0011] Figure 1 This is a schematic diagram of an application environment of a transaction processing method according to an embodiment of the present invention; Figure 2 This is a flow chart of a transaction processing method according to an embodiment of the present invention; Figure 3 is a structural diagram of a transaction processing device in one embodiment of the present invention; Figure 4 is a structural diagram of a computer device in one embodiment of the present invention; Figure 5 FIG. 2 is another structural diagram of a computer device according to an embodiment of the present invention. DETAILED DESCRIPTION

[0012] The following will clearly and completely describe the technical solutions in the embodiments of the present invention in conjunction with the accompanying drawings. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of them. All other embodiments obtained by ordinary technicians in this field based on the embodiments of the present invention without making any creative efforts shall fall within the scope of protection of the present invention.

[0013] The transaction processing method provided by the embodiment of the present invention can be applied in Figure 1In an application environment, a client communicates with a server via a network. The server can obtain bank card transaction requests from the client and, based on preset concurrency judgment rules, classify transaction requests that do not comply with the concurrency judgment rules as over-limit requests; obtain attribution information for the over-limit requests, which includes card and bank dimension information; obtain a corresponding concurrency control policy based on the attribution information for the over-limit requests; process the over-limit requests based on the concurrency control policy, and feedback the processing results to the client. In the present invention, over-limit requests are accurately identified through the dual dimensions of "card + bank" to avoid indiscriminate congestion, and over-limit requests are processed based on differentiated concurrency control policies to avoid resource waste and inefficient queuing, thereby solving the problems of transaction congestion and low efficiency in the prior art. The client can include, but is not limited to, various personal computers, laptops, smartphones, tablets, and portable wearable devices. The server can be implemented as a standalone server or a server cluster consisting of multiple servers. The present invention is described in detail below through specific embodiments.

[0014] The transaction processing method provided by the embodiment of the present invention is applicable to the financial field.

[0015] See also Figure 2 As shown, Figure 2 A flowchart of a transaction processing method provided by an embodiment of the present invention includes the following steps: S21: Obtain bank card transaction requests, and according to preset concurrency judgment rules, treat transaction requests that do not comply with the concurrency judgment rules as over-limit requests.

[0016] The obtaining of bank card transaction request refers to receiving a bank card transaction request from a user or a downstream channel. The request contains the core information required to complete concurrent judgment, such as bank card number, bank, transaction amount, transaction timestamp, transaction type, etc.

[0017] The pre-set concurrency judgment rules are formulated based on the differentiated requirements of each bank for bank card concurrent processing. The concurrency judgment rules need to be regularly maintained and updated. The current transaction request information is then compared with the concurrency judgment rules to determine whether it meets the concurrency judgment rules.

[0018] For example, Bank A stipulates that "the number of concurrent processing for the same bank card can only be 1" (that is, only one transaction can be processed at the same time, and the next transaction can only be processed after the previous transaction is completed). The concurrency judgment rule is: for the same bank card number, if there is an unfinished transaction, the newly received transaction request is judged as an over-limit request; Bank B stipulates that "the same bank card can only process one transaction of the same amount within 1 second". The concurrency judgment rule is: for the same bank card number and the same transaction amount, if the time interval between the timestamp of the previous transaction request and the timestamp of the current transaction request is less than 1 second, the current request is judged as an over-limit request.

[0019] S22: Acquire attribution information of the over-limit request, where the attribution information includes card dimension information and bank dimension information.

[0020] This step is crucial for accurately locating over-limit requests after identifying them. Its core purpose is to obtain both card and bank information from over-limit requests, providing a basis for subsequent matching of corresponding concurrency control strategies. This step is the foundation for implementing "bank + card" dual-dimensional scheduling, resolving resource mismatches and congestion issues caused by traditional single-dimensional (bank or card) processing of transaction requests.

[0021] Card-level information refers to information that can uniquely identify a bank card. It is used to distinguish different bank card entities and ensure precise control of individual bank cards. Common information includes: bank card number, card identifier (a unique code assigned to each card within the system, such as card ID), etc. Its core function is to identify the specific bank card corresponding to the over-limit request. Generally, this information can be obtained through the bank card-related data carried in the over-limit request.

[0022] Bank-level information refers to information that uniquely identifies the bank to which the bank card belongs. It is used to determine the bank-level concurrency rules corresponding to the bank card. Common information includes: bank code (such as the institution code uniformly assigned by the central bank or the industry), bank name, institution identifier, etc. Its core function is to clearly identify the bank entity corresponding to the over-limit request. Generally, bank-level information can be obtained by parsing the bank card number in the over-limit request, or by directly including bank-level information (such as bank code, bank abbreviation, etc.) in the over-limit request.

[0023] S23: Acquire a corresponding concurrency control strategy according to the ownership information of the excess request.

[0024] The core function of this step is to match and call the concurrency control policy corresponding to the specific "bank + card" combination based on the dual attribution information of "card dimension + bank dimension" obtained in the previous step. Specifically, the system pre-stores the concurrency control policies of each bank for different bank cards, and these policies correspond one-to-one to the attribution information of "bank + card". Through the precise matching of attribution information, it can be ensured that each over-limit request can be processed in accordance with the specific requirements of the bank to which it belongs, which not only complies with the bank's restrictions but also avoids affecting the transactions of other cards. For example, the card dimension information of the over-limit request is the bank card number, and the bank dimension information is Bank A. The concurrency control policy corresponding to "Bank A + Bank Card Number" is queried.

[0025] A concurrency control policy is a set of pre-defined rules for regulating the processing pace and resource allocation of requests exceeding the limit, tailored to the varying concurrent processing limits of different banks and bank cards. Its core purpose is to ensure that requests exceeding the limit comply with the bank's limits on concurrent bank card transactions (e.g., the number of transactions per transaction, time interval, etc.), while also avoiding transaction congestion and improving system efficiency.

[0026] S24: Processing the excess request according to the concurrency control strategy.

[0027] This step executes the over-limit request processing flow. Its core is to handle over-limit requests in a targeted manner according to the concurrency control strategy matched in the previous step. Its goal is to efficiently handle over-limit requests while meeting the bank's concurrency limits, avoiding transaction failures and wasted system resources, while ensuring that normal transactions of other cards are not affected.

[0028] Specifically, according to the concurrency control strategy corresponding to the "bank + card" dimension, through dynamic thread management, queue scheduling, time control and other mechanisms, over-limit requests are processed in an orderly manner. For example, for requests that require serialization, they wait for the previous transaction to be completed in order. For requests that require time intervals, they are triggered and executed at the specified intervals, ultimately achieving the goal of complying with bank regulations and efficiently utilizing resources.

[0029] The solution implemented by the transaction processing method, device, equipment, and storage medium described above can be applied to the financial sector. It obtains bank card transaction requests and, based on preset concurrency judgment rules, classifies transaction requests that do not comply with the concurrency judgment rules as over-limit requests. It also obtains attribution information for the over-limit requests, which includes card and bank dimension information. It obtains a corresponding concurrency control strategy based on the attribution information for the over-limit requests. The present invention accurately identifies over-limit requests through the dual dimensions of "card + bank," avoiding indiscriminate congestion. It also processes over-limit requests based on differentiated concurrency control strategies, avoiding resource waste and inefficient queuing, thereby resolving the issues of transaction congestion and low efficiency in the prior art.

[0030] In one embodiment of the present invention, the processing of the over-limit request according to the concurrency control strategy includes: a serial execution strategy, storing the over-limit request in the card dimension queue of the corresponding bank card, and processing the over-limit requests in the card dimension queue in sequence after the previous transaction of the bank card is completed; a time window limitation strategy, recording the characteristic information of the over-limit request, and processing the over-limit request when the interval between the previous transaction with the same characteristic information as the over-limit request reaches a preset threshold.

[0031] The serial execution strategy is a rule designed to address the concurrency restriction of "only one transaction can be processed at a time for the same bank card." Its core principle is to achieve orderly queuing of transactions through card-level queues, ensuring that the previous transaction is completed before the next one is processed, thus preventing parallel execution from triggering bank restrictions. The key to this strategy lies in card-level queues and sequential execution: a separate card-level queue is established for each bank card. Exceeding-limit requests are stored in the corresponding card-level queue. Only after the current transaction for that card is completed will the next exceeding-limit request be removed from the queue for execution, thus achieving serialization of single-card transactions.

[0032] In one example, Bank A stipulates that "only one transaction can be processed at a time for the same card, and the next transaction can only be initiated after the previous transaction is completed." At 10:00:00, a Bank A card with card number xxxx initiated transaction A (processing in progress). At 10:00:01, the system received transaction B (an over-limit request) for the same card, and at 10:00:02, it received transaction C (an over-limit request). After transactions B and C were identified as over-limit requests, they were matched to the "serial execution strategy" based on their attribution information and stored sequentially in the card-level queue for "Bank A-xxxx" (queue order: transaction B → transaction C). When transaction A completed at 10:00:05, the first over-limit request (transaction B) was removed from the card-level queue and executed immediately. After transaction B completed, the system continued to remove transaction C from the card-level queue for execution until the queue was cleared.

[0033] The time window limit strategy is a processing rule designed to address the concurrency restriction requirement that transactions with the same characteristics on the same bank card must meet a minimum time interval. Its core approach is to trigger transactions on a timed basis by "recording transaction characteristics and monitoring time intervals," ensuring that the interval between two transactions with the same characteristics is no less than the bank's specified threshold (e.g., 1 second). The key to this strategy lies in "feature identification" and "interval control": First, the characteristic information of the over-limit request (such as the transaction amount and type, as determined by bank regulations) is recorded. The completion time of the previous transaction with the same characteristic is then compared. Only when the interval between the two reaches a preset threshold (e.g., 1 second) will the current over-limit request be processed.

[0034] In one example, Bank B stipulates that "only one transaction of the same amount using the same bank card can be processed within one second" (characteristic information is "bank card number + transaction amount"). At 10:00:00.0, a Bank B card with card number yyyy initiated transaction D for 1,000 yuan (processing in progress). At 10:00:00.5, a transaction E for 1,000 yuan (an over-limit request) was received from the same card. At 10:00:00.6, a transaction F for 2,000 yuan was received from the same card (not an over-limit request, as the amount was different). After transaction E is identified as an over-limit request, it is matched to the "time window limit policy" based on the attribution information. Its characteristic information, "yyyy + 1,000 yuan," is recorded, and the previous transaction D with the same characteristics is found to have a start time of 10:00:00. To calculate the required waiting time, the preset threshold is 1 second, so the interval between transactions E and D must be ≥ 1 second. Assuming transaction D is completed at 10:00:01, transaction E cannot be triggered until 10:00:02 (one second after transaction D). Because transaction F has a different amount (different feature information from transaction D), it can enter the normal processing flow without waiting (not occupying time window limit resources).

[0035] In one embodiment, processing the over-limit request according to the concurrency control strategy includes: distributing the over-limit request to multiple nodes of the distributed cluster according to bank dimension information, each node maintaining a card dimension queue for each bank card of the corresponding bank, and executing the serial execution strategy or time window limitation strategy to process the over-limit request.

[0036] This step describes the specific logic of how to perform distributed processing for "excessive requests" in a concurrency control scenario. The core is to achieve orderly management and control through three levels: "bank dimension allocation", "node maintenance card dimension queue", and "execution serial or time window strategy".

[0037] The card-dimensional queue is further split by "bank card number" for each node according to the bank assigned to it, maintaining an independent queue for each card, and further refining the "bank-level" requests to the "single-card level" to ensure that all over-limit requests for the same card are queued in sequence to avoid concurrency conflicts (if there are two over-limit transactions on the same card at the same time, the first one must be processed before the second one), and then the "serial execution strategy" or "time window limit strategy" is executed to process the over-limit requests in the queue.

[0038] In one example, a payment platform needs to handle over-limit requests from multiple banks nationwide, alleging "single-card transactions exceeding five per day." The distributed cluster has three nodes (nodes A, B, and C), involving banks X, Y, and Z. The over-limit rule is that any request exceeding five transactions per day from a single card is considered an over-limit request. Over-limit requests are assigned to nodes based on bank information: Bank X's over-limit requests are assigned to node A; Bank Y's over-limit requests are assigned to node B; and Bank Z's over-limit requests are assigned to node C. All over-limit requests from Bank X go only to node A, not to B or C. After receiving over-limit requests from Bank X, node A splits the queues by bank card number: requests for card number aaaa are assigned to card-specific queue Q1; requests for card number bbbb are assigned to card-specific queue Q2; and so on for other card numbers. Each card has a separate card-specific queue. Over-limit requests for the same card are aggregated into the same queue, while over-limit requests for different cards are queued concurrently within node A. Card number aaaa generates five consecutive over-limit requests within 10 minutes, and node A processes the queue in sequence.

[0039] In another example, for all card queues of Bank X, a limit of 100 requests per minute is set. If the number of requests exceeding the limit in each queue reaches 100 within a minute, subsequent requests exceeding the limit are temporarily stored in the queue and processed after the next minute window opens.

[0040] In one embodiment, before processing the over-limit request, it includes: adding a concurrent lock to the transaction primary key of each over-limit request, and the transaction primary key is the unique identifier of each over-limit request; if the concurrent lock is added successfully, the over-limit request is processed normally, and the concurrent lock is released after the processing is completed; if the concurrent lock is added fails, the over-limit request is determined to be a duplicate request, and the over-limit request is refused to be processed.

[0041] This step describes the core logic for resolving duplicate requests through the "concurrency lock + transaction primary key" mechanism before processing over-limit requests. This aims to prevent the same over-limit request from being processed repeatedly (such as repeated submissions due to network retries, system delays, etc.), ensuring the uniqueness and consistency of transactions.

[0042] In a distributed system, over-limit requests may be submitted repeatedly for the following reasons: network fluctuations: clients sending requests don't receive a response, mistakenly believing the request failed and submitting again; system retries: upstream services automatically retry due to timeouts, causing the same request to reach the processing node multiple times; concurrent submissions: users rapidly clicking the submit button, triggering multiple identical requests. If these duplicate requests are processed simultaneously, they can cause serious problems (e.g., the same over-limit request on the same card may result in repeated deductions and transaction records). Therefore, it is necessary to identify and intercept duplicate requests before processing.

[0043] The transaction key uniquely identifies each over-limit request. It's typically automatically generated by the system and consists of a combination of the request's unique ID, request timestamp, bank card number, and other information. The transaction key uniquely distinguishes different requests; multiple submissions of the same request will carry the same transaction key.

[0044] Concurrency locks are a distributed locking mechanism (such as those implemented with Redis or ZooKeeper) that controls concurrent access to the same transaction key. When a node attempts to process an excessive request, it first locks the transaction key associated with the request and then releases the lock after processing. This ensures that excessive requests for the same transaction key can only be processed by one node at a time.

[0045] When an over-limit request arrives at the processing node, the node first extracts the transaction primary key in the over-limit request, and then initiates a "lock request" to the distributed lock service (such as Redis) to try to lock a unique processing permission for the transaction primary key. A successful lock indicates that the current over-limit request is being processed for the first time (or the previous processing has been completed and the lock has been released), and no other node is processing the over-limit request corresponding to the transaction primary key, so it can proceed normally to the subsequent processing flow (such as executing a serial strategy or a time window strategy). A failed lock indicates that another node is already processing the over-limit request corresponding to the transaction primary key (that is, there is a duplicate request), in which case it is directly judged as a "duplicate request" and rejected. When the successfully locked request is processed, the processing node must actively release the concurrent lock of the transaction primary key.

[0046] In one embodiment, adding a concurrent lock to the transaction primary key of each over-limit request includes: A preset timeout period is set for the concurrent lock. If the concurrent lock is added successfully but the concurrent lock is not released after the duration exceeds the preset timeout period, the concurrent lock is forcibly released.

[0047] This step describes a supplementary mechanism for preventing long-term lock occupancy and deadlocks by setting a "preset timeout" when adding a concurrent lock to the transaction primary key for an over-limit request. The core logic is: If a timeout is set for a concurrent lock, and the corresponding over-limit request processing fails to release the lock due to an exception (such as a system crash or network interruption), the system will automatically force the lock to be released when the concurrent lock lasts longer than the timeout, preventing other over-limit requests from being permanently blocked.

[0048] In a distributed system, even if the locking and releasing logic is working correctly, concurrent locks may still fail to be released due to the following issues: A processing node crash: The server holding the concurrent lock suddenly crashes, preventing the release operation from executing; A network interruption: The connection between the processing node and the lock service (such as Redis or ZooKeeper) is lost, preventing the release request from being delivered; A program exception: An uncaught error occurs in the processing flow, preventing the code for releasing the concurrent lock from being executed. Without a timeout, the concurrent lock in these situations will be held permanently. Subsequent requests for the same transaction primary key will be permanently rejected due to lock failures, resulting in a "deadlock" and ultimately blocking business operations.

[0049] For example, when the system receives an over-limit request and adds a concurrent lock for it, the preset timeout period is 30 seconds. 0 seconds: Node A successfully adds a concurrent lock to the transaction primary key of the over-limit request, and the expiration time of the concurrent lock is set to 30 seconds later; 20 seconds: Node A suddenly crashes during processing (such as a server power outage), and is unable to perform the operation of releasing the concurrent lock, so the concurrent lock is continuously held. 30 seconds: The duration of the concurrent lock reaches the preset timeout period. Since it is detected that the concurrent lock has not been released, the concurrent lock is automatically forced to be released. 35 seconds: The user submits the same over-limit request again because he did not receive a result. At this time, node B attempts to add a concurrent lock to the transaction primary key of the over-limit request. Since the previous concurrent lock has been forcibly released, it can now successfully add a concurrent lock to the transaction primary key of the over-limit request, and node B can continue to process the over-limit request.

[0050] In one embodiment, distributing the over-limit request to multiple nodes of a distributed cluster according to bank dimension information includes: real-time monitoring of the load index of each node; calculating the load weight of each node based on the load index; and dynamically distributing the over-limit request to multiple nodes based on the load weight.

[0051] This step describes how to optimize load balancing between nodes by allocating excess requests to distributed cluster nodes based on bank metrics. This logic involves real-time load monitoring, load weight calculation, and dynamic request allocation. The key goal is to avoid the problem of overly rigid request allocation (e.g., based solely on fixed rules) that can lead to some nodes being overloaded and others being idle.

[0052] Load indicators are key data that reflect the current processing capacity of a node. Common indicators include: hardware indicators: CPU usage, memory usage, disk I / O, and network bandwidth usage; software indicators: the busyness of the thread pool running on the node (such as the ratio of active threads to total threads), request queue length, and response time.

[0053] The load weight is a quantitative score for each node's load status, which serves as the basis for dynamic allocation of excess requests. For example, if Node A has a CPU utilization of 20% (weight +1), a thread pool busyness of 20% (weight +2), and a response time of 50ms (weight +2), the total load weight is 5 (light load). If Node B has a CPU utilization of 90% (weight -3), a thread pool busyness of 90% (weight -3), and a response time of 500ms (weight -2), the total load weight is -8 (heavy load).

[0054] In one example, a distributed cluster consists of three nodes (Node 1, Node 2, and Node 3), responsible for handling excess requests from Banks A and B. By default, Bank A's requests are assigned to Node 1, while Bank B's requests are assigned to Node 2. Node 3 serves as a backup node. Due to a surge in user spending, Bank A's excess requests suddenly increase fivefold. Node 1's load surges: CPU utilization reaches 90%, thread pool usage is 100%, response time increases from 50ms to 800ms, and the load weight drops to -5 (high load). Nodes 2 and 3 remain lightly loaded (weights of 6 and 7, respectively). Instead of assigning all of Bank A's excess requests to Node 1, 70% of them remain on Node 1, while 30% are temporarily assigned to Node 3. Node 3 receives and processes Bank A's requests, alleviating pressure on Node 1 and preventing it from shutting down due to overload.

[0055] In one embodiment, processing the over-limit request according to the concurrency control strategy includes: allocating the over-limit request to the corresponding shards according to bank dimension information, each shard is associated with a specific node in the distributed cluster; the node associated with the shard obtains the over-limit request in the shard, and executes the serial execution strategy or the time window limit strategy to process the over-limit request.

[0056] The core of this step is to split the over-limit requests into different shards according to the bank dimension. Each shard is bound to a fixed node, and then the node processes it according to a serial or time window strategy. This not only ensures the isolation of over-limit requests from each bank, but also utilizes the parallel capabilities of the distributed cluster to improve efficiency.

[0057] For example, if the system has two shards, Shard 1 is bound to Node 1 and is responsible for handling over-limit requests from Banks X and Y; Shard 2 is bound to Node 2 and is responsible for handling over-limit requests from Bank Z. When an over-limit request from Bank X arrives at the system, it is assigned to Shard 1 according to the bank-specific rules; Bank Y's over-limit request is assigned to Shard 1; and Bank Z's over-limit request is assigned to Shard 2. After receiving the over-limit requests from Banks X and Y from Shard 1, Node 1 processes the requests according to the respective concurrency control policies of the two banks. If Bank X requires "serial processing of the same card" (serial execution policy), a separate card-specific queue is maintained for the bank cards corresponding to the over-limit requests, and over-limit requests are processed one by one in the order in which they appear in the queue to avoid concurrency conflicts. If Bank Y requires "a maximum of three requests from the same card within 10 seconds" (time window policy), a 10-second window is set for the bank card corresponding to the over-limit request. If three requests have already been processed, subsequent over-limit requests are temporarily queued and processed after the window expires. After node 2 obtains the over-limit request from bank Z from shard 2, it also processes the over-limit request according to the concurrency control policy corresponding to bank Z.

[0058] In one embodiment, a transaction processing device is provided. Figure 3 As shown, the transaction processing device includes a request acquisition module 31, an information acquisition module 32, a strategy acquisition module 33 and a processing module 34. The functional modules are described in detail as follows: The request acquisition module 31 is used to acquire bank card transaction requests and, based on preset concurrency judgment rules, classify transaction requests that do not meet the concurrency judgment rules as over-limit requests; An information acquisition module 32 is configured to acquire attribution information of the over-limit request, wherein the attribution information includes card dimension information and bank dimension information; A policy acquisition module 33 is configured to acquire a corresponding concurrency control policy according to the attribution information of the over-limit request; The processing module 34 is configured to process the exceeding request according to the concurrency control strategy.

[0059] The present invention provides a transaction processing device applicable to the financial field, wherein a request acquisition module is used to acquire bank card transaction requests, and according to a preset concurrency judgment rule, a transaction request that does not comply with the concurrency judgment rule is regarded as an over-limit request; an information acquisition module is used to acquire the attribution information of the over-limit request, and the attribution information includes card dimension information and bank dimension information; a strategy acquisition module is used to acquire the corresponding concurrency control strategy according to the attribution information of the over-limit request; and a processing module is used to process the over-limit request according to the concurrency control strategy. In the present invention, over-limit requests are accurately identified through the dual dimensions of "card + bank" to avoid indiscriminate congestion, and over-limit requests are processed based on differentiated concurrency control strategies to avoid resource waste and inefficient queuing, thereby solving the problems of easy transaction congestion and low efficiency in the prior art.

[0060] The specific definition of the transaction processing device can be found in the definition of the transaction processing method above and will not be repeated here. Each module in the aforementioned transaction processing device may be implemented in whole or in part through software, hardware, or a combination thereof. Each of the aforementioned modules may be embedded in or independent of a processor in a computer device in hardware form, or may be stored in a computer device memory in software form, so that the processor can call and execute the corresponding operations of each module.

[0061] In one embodiment, a computer device is provided. The computer device may be a server, and its internal structure diagram may be as follows: Figure 4 As shown. The computer device includes a processor, memory, a network interface, and a database connected via a system bus. The processor of the computer device is used to provide computing and control capabilities. The memory of the computer device includes non-volatile and / or volatile storage media and internal memory. The non-volatile storage medium stores an operating system, a computer program, and a database. The internal memory provides an environment for the operation of the operating system and computer program in the non-volatile storage medium. The network interface of the computer device is used to communicate with an external client via a network connection. When executed by the processor, the computer program implements functions or steps on the server side of a transaction processing method.

[0062] In one embodiment, a computer device is provided. The computer device may be a client, and its internal structure diagram may be as follows: Figure 5 As shown. The computer device includes a processor, memory, a network interface, a display screen, and an input device connected via a system bus. The processor of the computer device is used to provide computing and control capabilities. The memory of the computer device includes a non-volatile storage medium and internal memory. The non-volatile storage medium stores an operating system and a computer program. The internal memory provides an environment for the operation of the operating system and computer program in the non-volatile storage medium. The network interface of the computer device is used to communicate with an external server via a network connection. When executed by the processor, the computer program implements client-side functions or steps of a transaction processing method.

[0063] In one embodiment, a computer device is provided, which can be applied to the financial field, including a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, the following steps are performed: Obtain bank card transaction requests, and according to preset concurrency judgment rules, treat transaction requests that do not meet the concurrency judgment rules as over-limit requests; Obtaining attribution information of the over-limit request, the attribution information including card dimension information and bank dimension information; Obtaining a corresponding concurrency control strategy according to the attribution information of the excess request; Process the exceeding request according to the concurrency control strategy.

[0064] In one embodiment, a computer-readable storage medium is provided, which can be applied to the financial field and stores a computer program. When the computer program is executed by a processor, the following steps are performed: Obtain bank card transaction requests, and according to preset concurrency judgment rules, treat transaction requests that do not meet the concurrency judgment rules as over-limit requests; Obtaining attribution information of the over-limit request, the attribution information including card dimension information and bank dimension information; Obtaining a corresponding concurrency control strategy according to the attribution information of the excess request; Process the exceeding request according to the concurrency control strategy.

[0065] It should be noted that the functions or steps that can be implemented by the computer-readable storage medium or computer device can be found in the corresponding descriptions of the computer device and the external computer device in the aforementioned method embodiment. To avoid repetition, they will not be described one by one here.

[0066] Those skilled in the art will understand that all or part of the processes in the above-mentioned embodiments can be implemented by instructing the relevant hardware through a computer program. The computer program can be stored in a non-volatile computer-readable storage medium. When the computer program is executed, it can include the processes of the embodiments of the above-mentioned methods. Among them, any reference to memory, storage, database or other media used in the embodiments provided in this application may include non-volatile and / or volatile memory. Non-volatile memory may include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM) or flash memory. Volatile memory may include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in many forms such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), double data rate SDRAM (DDRSDRAM), enhanced SDRAM (ESDRAM), Synchronous Link DRAM (SLDRAM), Rambus direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM), etc.

[0067] Those skilled in the art will clearly understand that for the sake of convenience and brevity of description, only the division of the above-mentioned functional units and modules is used as an example. In actual applications, the above-mentioned functions can be distributed and completed by different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above.

[0068] The embodiments described above are only used to illustrate the technical solutions of the present invention, rather than to limit the same. Although the present invention has been described in detail with reference to the aforementioned embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the aforementioned embodiments, or make equivalent replacements for some of the technical features therein. These modifications or replacements do not deviate the essence of the corresponding technical solutions from the spirit and scope of the technical solutions of the various embodiments of the present invention, and should all be included in the scope of protection of the present invention.

Claims

1. A transaction processing method, characterized in that: include: Obtain bank card transaction requests, and according to preset concurrency judgment rules, treat transaction requests that do not meet the concurrency judgment rules as over-limit requests; Obtaining attribution information of the over-limit request, the attribution information including card dimension information and bank dimension information; Obtaining a corresponding concurrency control strategy according to the attribution information of the excess request; Process the exceeding request according to the concurrency control strategy.

2. The transaction processing method according to claim 1, characterized in that: The processing of the excess request according to the concurrency control strategy includes: A serial execution strategy stores the over-limit request in the card-dimension queue of the corresponding bank card, and processes the over-limit requests in the card-dimension queue in sequence after the previous transaction of the bank card is completed; The time window limit strategy records the characteristic information of the over-limit request and processes the over-limit request when the interval between the previous transaction with the same characteristic information as the over-limit request reaches a preset threshold.

3. The transaction processing method according to claim 2, characterized in that: The processing of the excess request according to the concurrency control strategy includes: The over-limit request is distributed to multiple nodes of the distributed cluster according to bank dimension information. Each node maintains a card dimension queue for each bank card of the corresponding bank and executes the serial execution strategy or time window limit strategy to process the over-limit request.

4. The transaction processing method according to claim 1, wherein: Before processing the over-limit request, the method includes: Add a concurrent lock to the transaction primary key of each over-limit request. The transaction primary key is the unique identifier of each over-limit request. If the concurrent lock is added successfully, the over-limit request is processed normally, and the concurrent lock is released after the processing is completed; If adding a concurrent lock fails, the exceeding request is determined to be a repeated request and the exceeding request is rejected.

5. The transaction processing method according to claim 1, wherein: Adding a concurrent lock to the transaction primary key of each over-limit request includes: A preset timeout period is set for the concurrent lock. If the concurrent lock is added successfully but the concurrent lock is not released after the duration exceeds the preset timeout period, the concurrent lock is forcibly released.

6. The transaction processing method according to claim 3, characterized in that: The distributing the over-limit request to multiple nodes of the distributed cluster according to bank dimension information includes: Real-time monitoring of the load indicators of each node; Calculating the load weight of each node according to the load index; The excess requests are dynamically distributed to multiple nodes according to the load weights.

7. The transaction processing method according to claim 3, characterized in that: The processing of the excess request according to the concurrency control strategy includes: Allocate the over-limit request to the corresponding shard according to the bank dimension information, and each shard is associated with a specific node in the distributed cluster; The node associated with the shard obtains the excess request in the shard and executes the serial execution strategy or the time window limit strategy to process the excess request.

8. A transaction processing device, characterized in that: include: A request acquisition module is used to acquire bank card transaction requests and, based on preset concurrency judgment rules, classify transaction requests that do not meet the concurrency judgment rules as over-limit requests; An information acquisition module, configured to acquire attribution information of the over-limit request, wherein the attribution information includes card dimension information and bank dimension information; A policy acquisition module, configured to acquire a corresponding concurrency control policy according to the attribution information of the excess request; A processing module is used to process the excessive request according to the concurrency control strategy.

9. A computer device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein: When the processor executes the computer program, the steps of the transaction processing method according to any one of claims 1 to 7 are implemented.

10. A computer-readable storage medium storing a computer program, characterized in that: When the computer program is executed by a processor, the steps of the transaction processing method according to any one of claims 1 to 7 are implemented.

Images