Transaction limit limiting method and system, medium and terminal
Patent Information
- Application Number
- CN202411526491.3
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2024-10-30
- Publication Date
- 2025-03-28
AI Technical Summary
In the prior art, since hotspot data is concentrated on certain specific database nodes, the load on these nodes is too high, affecting system performance and reducing system stability. At the same time, the price of distributed transaction databases is high, resulting in increased system costs.
A transaction quota restriction method is adopted to improve online processing capabilities by storing real-time transaction requests and temporary used quota values in an in-memory database; at the same time, transaction requests and target quota rules are stored in a persistent relational database to perform persistent storage of used quota values asynchronously, and the stability and asynchronous storage of the persistent database avoid hot data pressure.
It improves the high-performance processing capability and stability of the system, reduces the pressure of hot spot data, avoids excessive load of local nodes caused by the hot spot data set, and ensures data security and integrity.
Smart Images

Figure CN119722304A_ABST
Abstract
Description
Technical Field
[0001] The present application relates to the field of computer technology, and in particular to a transaction limit method and system, medium, and terminal. Background Art
[0002] Transaction limit management is an indispensable part of finance, e-commerce and other fields, which usually involves a large amount of data reading and writing, numerical calculation and numerical judgment. When the transaction concurrency is high, the system needs to handle a large number of concurrent requests and quickly and accurately calculate and update the limit for each request, which requires the system to have high scalability, high performance and high consistency.
[0003] Since the distributed transaction database can horizontally expand database performance to support higher concurrency and larger data volumes, and can also use the distributed transaction mechanism to ensure the consistency of multiple update operations, in the prior art, the distributed transaction database is usually used to store the results of quota calculation.
[0004] However, since hot data is often concentrated on certain specific database nodes, the load on these nodes is too high, affecting the performance of the entire system and thus reducing the stability of the system. At the same time, the high price of distributed transaction databases leads to increased system costs. Summary of the invention
[0005] In view of this, the present application provides a transaction limit method and system, medium, and terminal. The main purpose is to solve the problem that hot data is often concentrated on certain specific database nodes, which causes the load of these nodes to be too high, affecting the performance of the entire system and thus reducing the stability of the system. At the same time, the high price of distributed transaction databases leads to increased system costs.
[0006] According to the first aspect of the present application, a transaction limit method is provided, which is applied to a limit limit online module, including:
[0007] Receiving a transaction request sent by a target merchant, wherein the transaction request carries a merchant identity identifier and a transaction category identifier of the target merchant;
[0008] According to the transaction category identifier, a credit limit rule matching the transaction category identifier is obtained as a target credit limit rule, and according to the target credit limit rule and the merchant identity identifier, a used credit limit value of the target merchant is obtained from an in-memory database;
[0009] Returning the transaction status of the transaction request according to the amount of the transaction request and the used credit value, and updating the used credit value according to the transaction status and the amount of the transaction request, wherein the transaction status is transaction success or transaction failure;
[0010] The transaction request and the target quota rule are stored in a persistent relational database to asynchronously perform persistent storage of the used quota value.
[0011] Preferably, obtaining the used credit limit value of the target merchant from the in-memory database according to the target credit limit rule and the merchant identity identifier includes:
[0012] Calculate a first hash value of the target quota rule;
[0013] According to the first hash value, searching the in-memory database for a first storage area for storing the quota data required by the target quota rule;
[0014] Searching for the target merchant in the first storage area according to the merchant identity identifier;
[0015] If the target merchant is found, the used credit value of the target merchant is obtained;
[0016] If the target merchant is not found, a second storage area for storing the credit limit data required for the target credit limit rule is searched in the persistent relational database according to the first hash value, and the target merchant is searched in the second storage area according to the merchant identity identifier to obtain the used credit limit value of the target merchant stored in the persistent relational database, and the used credit limit value stored in the persistent relational database and the target merchant are stored in the in-memory database in a mapping relationship.
[0017] Preferably, storing the transaction request and the target limit rule in a persistent relational database to asynchronously perform persistent storage of the used limit value includes:
[0018] Calculate a second Hash value of the transaction request serial number;
[0019] According to the second hash value, a third storage area for storing the transaction request is searched in the persistent relational database, and the transaction request and the target limit rule are added to the third storage area, and the limit update status of the transaction request is marked as a pending update status, so as to asynchronously perform persistent storage of the used limit value, wherein the transaction request includes transaction data.
[0020] According to the second aspect of the present application, another transaction limit method is provided, which is applied to the limit offline module, including:
[0021] Monitoring transaction requests stored in a persistent relational database, and when the limit update status of the transaction request is updated, obtaining a target limit rule corresponding to the transaction request, wherein the transaction request carries a merchant identity of a target merchant;
[0022] Calculate the hash value of the target credit limit rule, search the persistent relational database for a storage area for storing credit limit data required by the target credit limit rule according to the hash value, search the target merchant in the storage area according to the merchant identity, and obtain the used credit limit value of the target merchant;
[0023] The used credit limit value is updated according to the updated credit limit update status.
[0024] Preferably, updating the used credit limit value according to the updated credit limit update status includes:
[0025] If the updated credit limit update status is successful, the amount of the transaction request is added to the used credit limit value to obtain the updated used credit limit value;
[0026] If the updated credit limit update status is update failure, the used credit limit value remains unchanged.
[0027] According to the third aspect of the present application, a transaction limit system is provided, including:
[0028] Online quota limit module, offline quota limit module, in-memory database, and persistent relational database;
[0029] The credit limit online module is used to receive a transaction request sent by a target merchant, the transaction request carries a merchant identity identifier and a transaction category identifier of the target merchant, obtain a credit rule matching the transaction category identifier as a target credit rule according to the transaction category identifier, and obtain the used credit value of the target merchant from an in-memory database according to the target credit rule and the merchant identity identifier, return a transaction status of the transaction request according to the amount of the transaction request and the used credit value, update the used credit value according to the transaction status and the amount of the transaction request, the transaction status is a transaction success or a transaction failure, store the transaction request and the target credit rule in a persistent relational database, and asynchronously perform persistent storage of the used credit value;
[0030] The quota limit offline module is used to calculate the second hash value of the transaction request serial number, search the third storage area for storing the transaction request in the persistent relational database according to the second hash value, add the transaction request and the target quota rule to the third storage area, and mark the quota update state of the transaction request as a pending update state, so as to persistently store the transaction request, wherein the transaction request includes transaction data;
[0031] The in-memory database is used to store the quota data required by each quota rule;
[0032] The persistent relational database is used to store the quota data and transaction requests required by each quota rule.
[0033] Preferably, the credit limit online module is also used to calculate a first hash value of the target credit limit rule, and according to the first hash value, search the in-memory database for a first storage area for storing credit limit data required for the target credit limit rule, and according to the merchant identity identifier, search the target merchant in the first storage area, if the target merchant is found, obtain the used credit limit value of the target merchant, if the target merchant is not found, search the persistent relational database for a second storage area for storing credit limit data required for the target credit limit rule according to the first hash value, and search the target merchant in the second storage area according to the merchant identity identifier to obtain the used credit limit value of the target merchant stored in the persistent relational database, and store the used credit limit value stored in the persistent relational database and the target merchant in the in-memory database in a mapping relationship.
[0034] Preferably, the credit limit online module is also used to calculate a second hash value of the transaction request serial number, and based on the second hash value, search the third storage area for storing the transaction request in the persistent relational database, add the transaction request and the target credit limit rule to the third storage area, and mark the credit limit update status of the transaction request as a pending update status, so as to asynchronously perform persistent storage of the used credit limit value, wherein the transaction request includes transaction data.
[0035] According to a fourth aspect of the present application, a storage medium is provided, in which at least one executable instruction is stored, and the executable instruction enables a processor to perform operations corresponding to the above-mentioned transaction amount limitation method.
[0036] According to a fifth aspect of the present application, a terminal is provided, comprising: a processor, a memory, a communication interface and a communication bus, wherein the processor, the memory and the communication interface communicate with each other through the communication bus;
[0037] The memory is used to store at least one executable instruction, and the executable instruction enables the processor to execute operations corresponding to the above-mentioned transaction amount limitation method.
[0038] By means of the above technical solution, the technical solution provided by the embodiment of the present application has at least the following advantages:
[0039] The present application provides a transaction limit method and system, medium, and terminal, which first receive a transaction request sent by a target merchant, wherein the transaction request carries a merchant identity identifier and a transaction category identifier of the target merchant; secondly, according to the transaction category identifier, obtain a limit rule matching the transaction category identifier as a target limit rule, and according to the target limit rule and the merchant identity identifier, obtain the used limit value of the target merchant from an in-memory database; again, according to the amount of the transaction request and the used limit value, return a transaction status of the transaction request, and according to the transaction status and the amount of the transaction request, update the used limit value, wherein the transaction status is a transaction success or a transaction failure; finally, store the transaction request and the target limit rule in a persistent relational database, so as to asynchronously perform persistent storage of the used limit value. Compared with the prior art, the embodiment of the present application improves the online high-performance processing capability by storing real-time transaction requests and temporary used credit values in an in-memory database, taking advantage of the unlimited scalability and fast computing characteristics of the in-memory database; at the same time, the transaction requests and target credit rules are stored in a persistent relational database, and the used credit value is asynchronously persisted and stored, taking advantage of the high stability of the persistent relational database, and performing persistent storage in an asynchronous manner, thereby avoiding the situation where the local node is overloaded due to the concentration of hot data in the local node, reducing the pressure of the hot data, improving the stability of the system, and ensuring that the data is safe and not lost.
[0040] The above description is only an overview of the technical solution of the present application. In order to more clearly understand the technical means of the present application, it can be implemented in accordance with the contents of the specification. In order to make the above and other purposes, features and advantages of the present application more obvious and easy to understand, the specific implementation methods of the present application are listed below. BRIEF DESCRIPTION OF THE DRAWINGS
[0041] Various other advantages and benefits will become apparent to those of ordinary skill in the art by reading the detailed description of the preferred embodiments below. The accompanying drawings are only for the purpose of illustrating the preferred embodiments and are not to be considered as limiting the present application. Also, the same reference symbols are used throughout the accompanying drawings to represent the same components. In the accompanying drawings:
[0042] Figure 1A flow chart of a transaction limit method applied to a limit online module provided in an embodiment of the present application is shown;
[0043] Figure 2 A schematic diagram of a transaction limit system provided in an embodiment of the present application is shown;
[0044] Figure 3 A flowchart of obtaining the used credit value of a target merchant from an in-memory database provided by an embodiment of the present application is shown;
[0045] Figure 4 A flowchart of storing a transaction request and a target quota rule in a persistent relational database provided by an embodiment of the present application is shown;
[0046] Figure 5 A flow chart of a transaction limit method applied to a limit offline module provided in an embodiment of the present application is shown;
[0047] Figure 6 A block diagram of a transaction limit system provided by an embodiment of the present application is shown;
[0048] Figure 7 A schematic diagram of the structure of a terminal provided in an embodiment of the present application is shown. DETAILED DESCRIPTION
[0049] The exemplary embodiments of the present disclosure will be described in more detail below with reference to the accompanying drawings. Although the exemplary embodiments of the present disclosure are shown in the accompanying drawings, it should be understood that the present disclosure can be implemented in various forms and should not be limited by the embodiments set forth herein. On the contrary, these embodiments are provided to enable a more thorough understanding of the present disclosure and to fully convey the scope of the present disclosure to those skilled in the art.
[0050] At the same time, it should be understood that for the convenience of description, the sizes of the various parts shown in the drawings are not drawn according to the actual proportional relationship.
[0051] The following description of at least one exemplary embodiment is merely illustrative in nature and is in no way intended to limit the present application, its application, or uses.
[0052] Technologies, methods, and equipment known to ordinary technicians in the relevant art may not be discussed in detail, but where appropriate, the technologies, methods, and equipment should be considered as part of the specification.
[0053] It should be noted that like reference numerals and letters refer to similar items in the following figures, and therefore, once an item is defined in one figure, it need not be further discussed in subsequent figures.
[0054] The embodiments of the present application can be applied to computer systems / servers, which can operate with many other general or special computing system environments or configurations. Examples of well-known computing systems, environments and / or configurations suitable for use with computer systems / servers include, but are not limited to: personal computer systems, server computer systems, thin clients, thick clients, handheld or laptop devices, microprocessor-based systems, set-top boxes, programmable consumer electronics, network personal computers, small computer systems, large computer systems, and distributed cloud computing technology environments including any of the above systems, etc.
[0055] Computer systems / servers may be described in the general context of computer system executable instructions (such as program modules) executed by a computer system. In general, program modules may include routines, programs, object programs, components, logic, data structures, etc., which perform specific tasks or implement specific abstract data types. Computer systems / servers may be implemented in a distributed cloud computing environment where tasks are performed by remote processing devices linked through a communication network. In a distributed cloud computing environment, program modules may be located on local or remote computing system storage media including storage devices.
[0056] The present application embodiment provides a transaction limit method, which is applied to a limit limit online module, such as Figure 1 As shown, the method includes:
[0057] 101. Receive a transaction request sent by a target merchant.
[0058] The transaction request carries the merchant identification and transaction category identification of the target merchant; the merchant identification, such as merchant ID, merchant unified credit code, etc., is used to distinguish different merchants; the transaction category identification, such as small and micro merchant barcode transaction, small and micro merchant bank card transaction, etc., is used to filter the limit rules. In the embodiment of the present application, the current execution end can be a limit limit online module in the transaction limit system, which is used to process real-time transaction requests online.
[0059] 102. According to the transaction category identifier, a credit limit rule matching the transaction category identifier is obtained as a target credit limit rule, and according to the target credit limit rule and the merchant identity identifier, a used credit limit value of the target merchant is obtained from an in-memory database.
[0060] It should be noted that, since the in-memory database has the characteristics of unlimited expansion and fast calculation, in the embodiment of the present application, in order to improve the online high-performance processing capability, the real-time transaction request and the temporary used credit limit value are stored in the in-memory database. Specifically, first, the transaction category identifier is found in the transaction category identifier field of the transaction category identifier and credit limit rule mapping table, and the credit limit rule with which the transaction category identifier is mapped is obtained as the target credit limit rule, wherein the transaction category identifier and credit limit rule mapping table is shown in Table 1.
[0061] Table 1 Transaction category identification and quota rule mapping table
[0062] Transaction ID Transaction ID Transaction Description Quota Rules List 1 MicroMerchantBarCode Barcode transactions for small and micro businesses 1,2 2 MicroMerchantCard Small and micro merchant bank card transactions 1,2 3 MicroMerchantBarCode Barcode transactions for small and micro businesses 3,4 … … … …
[0063] Furthermore, according to the target quota rule, it can be determined according to the quota rule correspondence table which quotas need to be restricted. For example, quota rule 1 needs to limit the cumulative daily quota, quota rule 2 needs to limit the cumulative monthly quota, etc., where the quota rule correspondence table is shown in Table 2.
[0064] Table 2 Quota rule correspondence table
[0065] Rule ID Rule Processor Rule Processing Description 1 MerchantSingleLimitProcessor The daily limit of the merchant's current transaction 2 MerchantDayLimitProcessor The monthly cumulative limit of merchant transactions 3 MerchantSingleLimitFailedProcessor Merchant transaction failed and the daily limit was refunded 4 MerchantDayLimitFailedProcessor Merchants are returning monthly quotas due to failed transactions … … …
[0066] Finally, after the amount to be restricted is determined, the used amount value of the amount to be restricted can be obtained from the in-memory database according to the merchant identity identifier.
[0067] 103. Return the transaction status of the transaction request according to the amount of the transaction request and the used credit limit value, and update the used credit limit value according to the transaction status and the amount of the transaction request.
[0068] Among them, the transaction status is transaction success or transaction failure; if the transaction is successful, it means that the used amount after accumulating the amount of the current transaction request does not exceed the preset limit amount, at this time, the transaction is returned to be successful; if the transaction fails, it means that the used amount after accumulating the amount of the current transaction request has exceeded the preset limit amount, at this time, the transaction is returned to be failed. In the embodiment of the present application, by accumulating the amount of the current transaction request on the basis of the used amount value, and then comparing it with the preset limit amount, it can be determined whether the transaction is successful, thereby generating a transaction status. Furthermore, when the transaction is successful, the amount of the current transaction request is added to the current used amount value to obtain an updated used amount value; when the transaction fails, the current used amount value remains unchanged.
[0069] 104. Store the transaction request and the target quota rule in a persistent relational database to asynchronously perform persistent storage of the used quota value.
[0070] It should be noted that, since the persistent relational database has the characteristic of high stability, in order to ensure data security and prevent data loss, in the embodiment of the present application, the transaction request and the target limit rule are stored in the persistent relational database. Furthermore, the used limit value can be asynchronously updated in the persistent relational database according to the transaction request and the target limit rule, and stored persistently, thereby avoiding the situation where the local node is overloaded due to the concentration of hot data in the local node, reducing the pressure of the hot data and improving the stability of the system.
[0071] In specific application scenarios, the transaction limit system, such as Figure 2 As shown, it includes a quota limit online module for online processing of real-time transaction requests; a quota limit offline module for asynchronously updating the used quota value; a memory-level distributed database, that is, an in-memory database, for storing real-time transaction requests and temporary used quota values; a persistent distributed database, that is, a persistent relational database, for persistently storing transaction requests and target quota rules.
[0072] Compared with the prior art, the embodiment of the present application improves the online high-performance processing capability by storing real-time transaction requests and temporary used credit values in an in-memory database, taking advantage of the unlimited scalability and fast computing characteristics of the in-memory database; at the same time, the transaction requests and target credit rules are stored in a persistent relational database, and the used credit value is asynchronously persisted and stored, taking advantage of the high stability of the persistent relational database, and performing persistent storage in an asynchronous manner, thereby avoiding the situation where the local node is overloaded due to the concentration of hot data in the local node, reducing the pressure of the hot data, improving the stability of the system, and ensuring that the data is safe and not lost.
[0073] In an embodiment of the present application, in order to further define and illustrate, Figure 3 As shown, in step 102 of the embodiment, the used credit value of the target merchant is obtained from the in-memory database according to the target credit rule and the merchant identity, which specifically includes:
[0074] 201. Calculate the first hash value of the target quota rule.
[0075] Among them, the first hash value is used to represent the hash value corresponding to the target limit rule. It should be noted that the hash value is a function that maps input data of any length to output data of a fixed length. Therefore, no matter what kind of data is input, the output hash value is a fixed-length value. Based on this, using the hash value as an index to store the limit data can be more standardized and more accurate when searching.
[0076] 202. According to the first hash value, search in the in-memory database for a first storage area for storing the quota data required by the target quota rule.
[0077] Among them, the first storage area is a storage area for storing the quota data required by the target quota rule, that is, the quota data shard. For example, if the target quota rule is the cumulative daily limit of the merchant's current transactions, then the first storage area is the quota data shard that stores the merchant's cumulative daily used quota value. It should be noted that in order to improve the accuracy and efficiency of searching for the used quota value, in the embodiment of the present application, multiple data quota shards can be divided in the in-memory database, such as Figure 2 In the memory-level distributed database, there are quota data shards 1 to quota data shard N. Different categories of quota data are stored in corresponding quota data shards, and the hash value of the quota rule is used as the index. When searching, the corresponding quota data shard can be found in the memory database according to the first hash value of the calculated target quota rule. The quota data required by the target quota rule is stored in the quota data shard.
[0078] 203. Search for a target merchant in the first storage area according to the merchant identity identifier.
[0079] It should be noted that the same credit limit data of different merchants is stored in the first storage area. For example, the cumulative daily credit limit value used in the transactions of merchant A and the cumulative daily credit limit value used in the transactions of merchant B are all stored in the first storage area. At this time, the corresponding merchant can be searched in the first storage area according to the merchant identity identifier.
[0080] 204a. If the target merchant is found, the used credit value of the target merchant is obtained.
[0081] In the embodiment of the present application, when the target merchant exists in the first storage area, the used credit limit value thereof is directly obtained.
[0082] 204b. If the target merchant is not found, search the second storage area for storing the quota data required by the target quota rule in the persistent relational database according to the first hash value, and search the target merchant in the second storage area according to the merchant identity identifier to obtain the used quota value of the target merchant stored in the persistent relational database, and store the used quota value stored in the persistent relational database and the target merchant in the in-memory database in a mapping relationship.
[0083] It should be noted that since the in-memory database is used to store real-time transaction requests and temporary used credit values, there may be a situation where no records can be found. In this case, the persistent relational database is searched. Since the persistent relational database has the characteristics of high stability, the used credit value is persistently stored in it to ensure data security and prevent loss. Specifically, for the purpose of improving the accuracy and efficiency of searching for used credit values, in the embodiment of the present application, multiple data credit shards can also be divided in the persistent relational database, such as Figure 2 In the persistent distributed database, there are quota data shards 1 to quota data shard N. Different categories of quota data are also stored in corresponding quota data shards, and the hash value of the quota rule is also used as the index. When searching, the corresponding quota data shard (i.e., the second storage area) can also be found in the persistent relational database according to the first hash value of the target quota rule. The quota data required by the target quota rule is also stored in the quota data shard. Furthermore, according to the merchant identity, the corresponding merchant is searched in the second storage area, and its used quota value is obtained. Finally, the used quota value and the target merchant are stored in the memory database in a mapping relationship to process real-time transaction requests online.
[0084] In an embodiment of the present application, in order to further define and illustrate, Figure 4 As shown, step 103 of the embodiment stores the transaction request and the target quota rule in a persistent relational database to asynchronously perform persistent storage of the used quota value, specifically including:
[0085] 301. Calculate a second hash value of the transaction request serial number.
[0086] The second hash value is used to represent the hash value corresponding to the transaction request serial number.
[0087] 302. According to the second hash value, search for a third storage area for storing the transaction request in the persistent relational database, add the transaction request and the target limit rule to the third storage area, and mark the limit update status of the transaction request as a pending update status, so as to asynchronously perform persistent storage of the used limit value.
[0088] The transaction request includes transaction data; the third storage area is a storage area for storing transaction requests, that is, a transaction data shard. It should be noted that multiple transaction data shards can be pre-divided in the persistent relational database, such as Figure 2The transaction data shards 1 to N in the persistent distributed database are divided and stored according to the hash value of the transaction request serial number. When searching, the hash value of the transaction request serial number can be used as an index to find the transaction data shard (i.e., the third storage area) used to store the transaction request, and the transaction request and the target limit rule are added thereto, and the limit update status of the transaction request is marked as a pending update status, so as to asynchronously perform persistent storage of the used limit value. The transaction request record table in the transaction data shard is shown in Table 3.
[0089] Table 3 Transaction request record table
[0090] Primary Key ID Transaction serial number Credit update status Quota Rules List 1 20241010000000001 1-To be updated 1,2 2 20241010000000002 2- Success 3,4 3 20241010000000003 3- Failure 1,2
[0091] The present application embodiment provides another transaction limit method, which is applied to the limit offline module, such as Figure 5 As shown, the method includes:
[0092] 401. Monitor the transaction request stored in the persistent relational database, and when the quota update status of the transaction request is updated, obtain the target quota rule corresponding to the transaction request.
[0093] Among them, the transaction request carries the merchant identity of the target merchant; the transaction request's quota update status is updated, including from pending update to successful update and from pending update to failed update. In the embodiment of the present application, the current execution end can be a quota limit offline module in the transaction quota limit system, which is used to asynchronously perform persistent storage of the used quota value. Specifically, the current execution end can be used to subscribe to the change log of the persistent relational database, process each change record in turn, and when it is monitored that the quota update status of the transaction request is updated, the target quota rule corresponding to the transaction request is obtained.
[0094] 402. Calculate the hash value of the target credit limit rule, and according to the hash value, search the persistent relational database for a storage area for storing credit limit data required by the target credit limit rule, and search the target merchant in the storage area according to the merchant identity to obtain the used credit limit value of the target merchant.
[0095] In the embodiment of the present application, based on the method disclosed in step 202 of the embodiment, the corresponding credit limit data shard is found in the persistent relational database according to the hash value of the target credit limit rule, and the credit limit data required by the target credit limit rule is stored in the credit limit data shard. The target merchant is further searched in the storage area according to the merchant identity, and the used credit limit value of the target merchant is obtained.
[0096] 403. Update the used credit limit value according to the updated credit limit update status.
[0097] The updated credit limit update status includes two types: transaction success and transaction failure. In the embodiment of the present application, when the updated credit limit update status is transaction success, the used credit limit value is updated; when the updated credit limit update status is transaction failure, the current used credit limit value remains unchanged.
[0098] Compared with the prior art, the embodiment of the present application improves the online high-performance processing capability by storing real-time transaction requests and temporary used credit values in an in-memory database, taking advantage of the unlimited scalability and fast computing characteristics of the in-memory database; at the same time, the transaction requests and target credit rules are stored in a persistent relational database, and the used credit value is asynchronously persisted and stored, taking advantage of the high stability of the persistent relational database, and performing persistent storage in an asynchronous manner, thereby avoiding the situation where the local node is overloaded due to the concentration of hot data in the local node, reducing the pressure of the hot data, improving the stability of the system, and ensuring that the data is safe and not lost.
[0099] In an embodiment of the present application, for further limitation and explanation, step 403 of the embodiment updates the used credit limit value according to the updated credit limit update status, specifically including: if the updated credit limit update status is update success, the amount of the transaction request is added to the used credit limit value to obtain the updated used credit limit value; if the updated credit limit update status is update failure, the used credit limit value remains unchanged.
[0100] It should be noted that if the updated credit limit update status is update successful, it means that the transaction is successful. At this time, the amount of the transaction request needs to be added to the used credit limit value to obtain the updated used credit limit value; if the updated credit limit update status is update failed, it means that the transaction has failed. At this time, the used credit limit value needs to be kept unchanged.
[0101] The present application provides a transaction limit method, which first receives a transaction request sent by a target merchant, wherein the transaction request carries a merchant identity identifier and a transaction category identifier of the target merchant; secondly, according to the transaction category identifier, a limit rule matching the transaction category identifier is obtained as a target limit rule, and according to the target limit rule and the merchant identity identifier, a used limit value of the target merchant is obtained from an in-memory database; again, according to the amount of the transaction request and the used limit value, a transaction status of the transaction request is returned, and according to the transaction status and the amount of the transaction request, the used limit value is updated, and the transaction status is a transaction success or a transaction failure; finally, the transaction request and the target limit rule are stored in a persistent relational database, so as to asynchronously perform persistent storage of the used limit value. Compared with the prior art, the embodiment of the present application improves the online high-performance processing capability by storing real-time transaction requests and temporary used credit values in an in-memory database, taking advantage of the unlimited scalability and fast computing characteristics of the in-memory database; at the same time, the transaction requests and target credit rules are stored in a persistent relational database, and the used credit value is asynchronously persisted and stored, taking advantage of the high stability of the persistent relational database, and performing persistent storage in an asynchronous manner, thereby avoiding the situation where the local node is overloaded due to the concentration of hot data in the local node, reducing the pressure of the hot data, improving the stability of the system, and ensuring that the data is safe and not lost.
[0102] Furthermore, as a response to the above Figure 1 The implementation of the method shown in the embodiment of the present application provides a transaction limit system, such as Figure 6 As shown, the system includes:
[0103] A quota limit online module 51, a quota limit offline module 52, an in-memory database 53, and a persistent relational database 54;
[0104] The credit limit online module 51 is used to receive a transaction request sent by a target merchant, the transaction request carries the merchant identity identifier and transaction category identifier of the target merchant, obtains a credit rule matching the transaction category identifier as a target credit rule according to the transaction category identifier, and obtains the used credit value of the target merchant from an in-memory database according to the target credit rule and the merchant identity identifier, returns a transaction status of the transaction request according to the amount of the transaction request and the used credit value, updates the used credit value according to the transaction status and the amount of the transaction request, the transaction status is transaction success or transaction failure, stores the transaction request and the target credit rule in a persistent relational database, and asynchronously performs persistent storage of the used credit value;
[0105] The quota limit offline module 52 is used to calculate the second hash value of the transaction request serial number, search the third storage area for storing the transaction request in the persistent relational database according to the second hash value, add the transaction request and the target quota rule to the third storage area, and mark the quota update state of the transaction request as a pending update state, so as to persistently store the transaction request, wherein the transaction request includes transaction data;
[0106] The in-memory database 53 is used to store the quota data required by each quota rule;
[0107] The persistent relational database 54 is used to store the quota data and transaction requests required by each quota rule.
[0108] In a specific application scenario, the credit limit online module 51 is also used to calculate the first hash value of the target credit limit rule, and according to the first hash value, search the first storage area for storing the credit limit data required for the target credit limit rule in the in-memory database, and search the target merchant in the first storage area according to the merchant identity identifier. If the target merchant is found, the used credit limit value of the target merchant is obtained. If the target merchant is not found, search the second storage area for storing the credit limit data required for the target credit limit rule in the persistent relational database according to the first hash value, and search the target merchant in the second storage area according to the merchant identity identifier to obtain the used credit limit value of the target merchant stored in the persistent relational database, and store the used credit limit value stored in the persistent relational database and the target merchant in the in-memory database in a mapping relationship.
[0109] In a specific application scenario, the credit limit online module 51 is also used to calculate the second hash value of the transaction request serial number, and according to the second hash value, search the third storage area for storing the transaction request in the persistent relational database, add the transaction request and the target credit limit rule to the third storage area, and mark the credit limit update status of the transaction request as a pending update status, so as to asynchronously perform persistent storage of the used credit limit value, and the transaction request contains transaction data.
[0110] In a specific application scenario, the credit limit offline module 52 is also used to add the amount of the transaction request to the used credit value if the updated credit update status is a successful update to obtain an updated used credit value; if the updated credit update status is an update failure, keep the used credit value unchanged.
[0111] The present application provides a transaction limit system, which first receives a transaction request sent by a target merchant, wherein the transaction request carries a merchant identity identifier and a transaction category identifier of the target merchant; secondly, according to the transaction category identifier, obtains a limit rule matching the transaction category identifier as a target limit rule, and according to the target limit rule and the merchant identity identifier, obtains the used limit value of the target merchant from an in-memory database; again, according to the amount of the transaction request and the used limit value, returns a transaction status of the transaction request, and according to the transaction status and the amount of the transaction request, updates the used limit value, wherein the transaction status is a transaction success or a transaction failure; finally, stores the transaction request and the target limit rule in a persistent relational database, so as to asynchronously perform persistent storage of the used limit value. Compared with the prior art, the embodiment of the present application improves the online high-performance processing capability by storing real-time transaction requests and temporary used credit values in an in-memory database, taking advantage of the unlimited scalability and fast computing characteristics of the in-memory database; at the same time, the transaction requests and target credit rules are stored in a persistent relational database, and the used credit value is asynchronously persisted and stored, taking advantage of the high stability of the persistent relational database, and performing persistent storage in an asynchronous manner, thereby avoiding the situation where the local node is overloaded due to the concentration of hot data in the local node, reducing the pressure of the hot data, improving the stability of the system, and ensuring that the data is safe and not lost.
[0112] According to one embodiment of the present application, a storage medium is provided, wherein the storage medium stores at least one executable instruction, and the computer executable instruction can execute the transaction amount limitation method in any of the above method embodiments.
[0113] Based on this understanding, the technical solution of the present application can be embodied in the form of a software product, which can be stored in a non-volatile storage medium (which can be a CD-ROM, a USB flash drive, a mobile hard disk, etc.), and includes a number of instructions for enabling a computer device (which can be a personal computer, a server, or a network device, etc.) to execute the methods described in each implementation scenario of the present application.
[0114] Figure 7 A schematic diagram of the structure of a terminal provided according to an embodiment of the present application is shown, and the specific embodiment of the present application does not limit the specific implementation of the terminal.
[0115] like Figure 7 As shown, the terminal may include: a processor (processor) 602 , a communication interface (Communications Interface) 604 , a memory (memory) 606 , and a communication bus 608 .
[0116] The processor 602 , the communication interface 604 , and the memory 606 communicate with each other via a communication bus 608 .
[0117] The communication interface 604 is used to communicate with other devices such as clients or other servers.
[0118] The processor 602 is used to execute the program 610, and specifically can execute the relevant steps in the above-mentioned transaction amount limitation method embodiment.
[0119] Specifically, the program 610 may include program codes, which include computer operation instructions.
[0120] The processor 602 may be a central processing unit (CPU), or an application-specific integrated circuit (ASIC), or one or more integrated circuits configured to implement the embodiments of the present application. The one or more processors included in the computer device may be processors of the same type, such as one or more CPUs; or may be processors of different types, such as one or more CPUs and one or more ASICs.
[0121] The memory 606 is used to store the program 610. The memory 606 may include a high-speed RAM memory, and may also include a non-volatile memory (non-volatile memory), such as at least one disk memory.
[0122] The program 610 may be specifically configured to enable the processor 602 to perform the following operations:
[0123] Receiving a transaction request sent by a target merchant, wherein the transaction request carries a merchant identity identifier and a transaction category identifier of the target merchant;
[0124] According to the transaction category identifier, a credit limit rule matching the transaction category identifier is obtained as a target credit limit rule, and according to the target credit limit rule and the merchant identity identifier, a used credit limit value of the target merchant is obtained from an in-memory database;
[0125] Returning the transaction status of the transaction request according to the amount of the transaction request and the used credit value, and updating the used credit value according to the transaction status and the amount of the transaction request, wherein the transaction status is transaction success or transaction failure;
[0126] The transaction request and the target quota rule are stored in a persistent relational database to asynchronously perform persistent storage of the used quota value.
[0127] The storage medium may also include an operating system and a network communication module. The operating system is a program that manages the hardware and software resources of the physical device of the transaction limit method, and supports the operation of the information processing program and other software and / or programs. The network communication module is used to realize the communication between the components inside the storage medium, and the communication with other hardware and software in the information processing physical device.
[0128] Each embodiment in this specification is described in a progressive manner, and each embodiment focuses on the differences from other embodiments. The same or similar parts between the embodiments can be referred to each other. For the system embodiment, since it basically corresponds to the method embodiment, the description is relatively simple, and the relevant parts can be referred to the partial description of the method embodiment.
[0129] The method and system of the present application may be implemented in many ways. For example, the method and system of the present application may be implemented by software, hardware, firmware, or any combination of software, hardware, and firmware. The above order of steps for the method is for illustration only, and the steps of the method of the present application are not limited to the order specifically described above, unless otherwise specifically stated. In addition, in some embodiments, the present application may also be implemented as a program recorded in a recording medium, which includes machine-readable instructions for implementing the method according to the present application. Therefore, the present application also covers a recording medium storing a program for executing the method according to the present application.
[0130] Obviously, those skilled in the art should understand that the above modules or steps of the present application can be implemented by a general computing device, they can be concentrated on a single computing device, or distributed on a network composed of multiple computing devices, and optionally, they can be implemented by a program code executable by a computing device, so that they can be stored in a storage device and executed by the computing device, and in some cases, the steps shown or described can be executed in a different order from that herein, or they can be made into individual integrated circuit modules, or multiple modules or steps therein can be made into a single integrated circuit module for implementation. Thus, the present application is not limited to any specific combination of hardware and software.
[0131] The above description is only the preferred embodiment of the present application and is not intended to limit the present application. For those skilled in the art, the present application may have various modifications and variations. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the present application shall be included in the protection scope of the present application.
Claims
1. A transaction limit method, applied to a limit online module, characterized in that: include: Receiving a transaction request sent by a target merchant, wherein the transaction request carries a merchant identity identifier and a transaction category identifier of the target merchant; According to the transaction category identifier, a credit limit rule matching the transaction category identifier is obtained as a target credit limit rule, and according to the target credit limit rule and the merchant identity identifier, a used credit limit value of the target merchant is obtained from an in-memory database; Returning the transaction status of the transaction request according to the amount of the transaction request and the used credit value, and updating the used credit value according to the transaction status and the amount of the transaction request, wherein the transaction status is transaction success or transaction failure; The transaction request and the target quota rule are stored in a persistent relational database to asynchronously perform persistent storage of the used quota value.
2. The method according to claim 1, characterized in that: The step of obtaining the used credit limit value of the target merchant from the in-memory database according to the target credit limit rule and the merchant identity identifier includes: Calculate a first hash value of the target quota rule; According to the first hash value, searching the in-memory database for a first storage area for storing the quota data required by the target quota rule; Searching for the target merchant in the first storage area according to the merchant identity identifier; If the target merchant is found, the used credit value of the target merchant is obtained; If the target merchant is not found, a second storage area for storing the credit limit data required for the target credit limit rule is searched in the persistent relational database according to the first hash value, and the target merchant is searched in the second storage area according to the merchant identity identifier to obtain the used credit limit value of the target merchant stored in the persistent relational database, and the used credit limit value stored in the persistent relational database and the target merchant are stored in the in-memory database in a mapping relationship.
3. The method according to claim 1, characterized in that: The storing of the transaction request and the target quota rule in a persistent relational database to asynchronously perform persistent storage of the used quota value includes: Calculate a second Hash value of the transaction request serial number; According to the second hash value, a third storage area for storing the transaction request is searched in the persistent relational database, and the transaction request and the target limit rule are added to the third storage area, and the limit update status of the transaction request is marked as a pending update status, so as to asynchronously perform persistent storage of the used limit value, wherein the transaction request includes transaction data.
4. A transaction limit method, applied to a limit offline module, characterized in that: include: Monitoring transaction requests stored in a persistent relational database, and when the limit update status of the transaction request is updated, obtaining a target limit rule corresponding to the transaction request, wherein the transaction request carries a merchant identity of a target merchant; Calculate the hash value of the target credit limit rule, search the persistent relational database for a storage area for storing credit limit data required by the target credit limit rule according to the hash value, search the target merchant in the storage area according to the merchant identity, and obtain the used credit limit value of the target merchant; The used credit limit value is updated according to the updated credit limit update status.
5. The method according to claim 4, characterized in that The updating of the used credit limit value according to the updated credit limit update status includes: If the updated credit limit update status is successful, the amount of the transaction request is added to the used credit limit value to obtain the updated used credit limit value; If the updated credit limit update status is update failure, the used credit limit value remains unchanged.
6. A transaction limit system, characterized in that: include: Online quota limit module, offline quota limit module, in-memory database, and persistent relational database; The credit limit online module is used to receive a transaction request sent by a target merchant, the transaction request carries a merchant identity identifier and a transaction category identifier of the target merchant, obtain a credit rule matching the transaction category identifier as a target credit rule according to the transaction category identifier, and obtain the used credit value of the target merchant from an in-memory database according to the target credit rule and the merchant identity identifier, return a transaction status of the transaction request according to the amount of the transaction request and the used credit value, update the used credit value according to the transaction status and the amount of the transaction request, the transaction status is a transaction success or a transaction failure, store the transaction request and the target credit rule in a persistent relational database, and asynchronously perform persistent storage of the used credit value; The quota limit offline module is used to calculate the second hash value of the transaction request serial number, search the third storage area for storing the transaction request in the persistent relational database according to the second hash value, add the transaction request and the target quota rule to the third storage area, and mark the quota update state of the transaction request as a pending update state, so as to persistently store the transaction request, wherein the transaction request includes transaction data; The in-memory database is used to store the quota data required by each quota rule; The persistent relational database is used to store the quota data and transaction requests required by each quota rule.
7. The system according to claim 6, characterized in that The credit limit online module is also used to calculate a first hash value of the target credit limit rule, and according to the first hash value, search the first storage area for storing credit limit data required by the target credit limit rule in the in-memory database, and according to the merchant identity identifier, search the target merchant in the first storage area. If the target merchant is found, the used credit limit value of the target merchant is obtained. If the target merchant is not found, search the second storage area for storing credit limit data required by the target credit limit rule in the persistent relational database according to the first hash value, and search the target merchant in the second storage area according to the merchant identity identifier to obtain the used credit limit value of the target merchant stored in the persistent relational database, and store the used credit limit value stored in the persistent relational database and the target merchant in the in-memory database in a mapping relationship.
8. The system according to claim 6, characterized in that The quota limit online module is also used to calculate the second hash value of the transaction request serial number, and according to the second hash value, search the third storage area for storing the transaction request in the persistent relational database, add the transaction request and the target quota rule to the third storage area, and mark the quota update status of the transaction request as a pending update status to asynchronously perform persistent storage of the used quota value, wherein the transaction request includes transaction data.
9. A storage medium, wherein at least one executable instruction is stored in the storage medium, characterized in that: The executable instructions enable the processor to perform operations corresponding to the transaction amount limiting method as described in any one of claims 1-3 and claim 4 or 5.
10. A terminal, comprising: A processor, a memory, a communication interface and a communication bus, wherein the processor, the memory and the communication interface communicate with each other via the communication bus; The memory is used to store at least one executable instruction, characterized in that the executable instruction enables the processor to perform operations corresponding to the transaction amount limitation method as described in any one of claims 1-3 and claim 4 or 5.