CN112819638A - Transaction weight judging method, device, equipment and computer readable medium - Google Patents
Transaction weight judging method, device, equipment and computer readable medium Download PDFInfo
- Publication number
- CN112819638A CN112819638A CN202110339808.2A CN202110339808A CN112819638A CN 112819638 A CN112819638 A CN 112819638A CN 202110339808 A CN202110339808 A CN 202110339808A CN 112819638 A CN112819638 A CN 112819638A
- Authority
- CN
- China
- Prior art keywords
- access request
- database access
- database
- token
- request
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q40/00—Finance; Insurance; Tax strategies; Processing of corporate or income taxes
- G06Q40/04—Trading; Exchange, e.g. stocks, commodities, derivatives or currency exchange
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
- G06F16/21—Design, administration or maintenance of databases
- G06F16/215—Improving data quality; Data cleansing, e.g. de-duplication, removing invalid entries or correcting typographical errors
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
- G06F16/24—Querying
- G06F16/245—Query processing
- G06F16/2455—Query execution
- G06F16/24552—Database cache management
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/60—Protecting data
- G06F21/602—Providing cryptographic facilities or services
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/60—Protecting data
- G06F21/62—Protecting access to data via a platform, e.g. using keys or access control rules
- G06F21/6218—Protecting access to data via a platform, e.g. using keys or access control rules to a system of files or objects, e.g. local or distributed file system or database
- G06F21/6227—Protecting access to data via a platform, e.g. using keys or access control rules to a system of files or objects, e.g. local or distributed file system or database where protection concerns the structure of data, e.g. records, types, queries
Abstract
The invention discloses a method, a device, equipment and a computer readable medium for transaction weight judgment, and relates to the technical field of big data. One embodiment of the method comprises: after receiving a database access request, acquiring an identifier of the database access request, and setting a distributed lock of the identifier; judging whether the database access request is a repeated request or not according to the token of the database access request and parameters related to the token in the database; and executing the database access request according to the judgment result of the database access request, and releasing the distributed lock if the distributed lock is overdue. This embodiment avoids duplicate submission transactions and can therefore relieve server and database strain.
Description
Technical Field
The invention relates to the technical field of big data, in particular to a method, a device, equipment and a computer readable medium for judging transaction weight.
Background
With the rapid development of the internet, the use of page applications has wide popularity. In reality, the 'submit', 'back', 'refresh' buttons on the page give the page powerful functions, but also bring about the problem of repeated submission.
In a platform system, if some transaction data is repeatedly submitted, dirty data or other significant business problems may result. And if the user frequently clicks or the malicious attack of a malicious user, continuous requests can be caused, and further great pressure is caused on the server.
In the process of implementing the invention, the inventor finds that at least the following problems exist in the prior art: traditionally, it is common practice to limit the database to avoid duplication, but if the number of people requesting the same service is large, the pressure on the server and the database is increased.
Disclosure of Invention
In view of this, embodiments of the present invention provide a method, an apparatus, a device, and a computer-readable medium for transaction weight determination, which avoid repeated submission of transactions, and thus can reduce the pressure on servers and databases.
To achieve the above object, according to an aspect of an embodiment of the present invention, there is provided a method for determining a trade weight, including:
after receiving a database access request, acquiring an identifier of the database access request, and setting a distributed lock of the identifier;
judging whether the database access request is a repeated request or not according to the token of the database access request and parameters related to the token in the database;
and executing the database access request according to the judgment result of the database access request, and releasing the distributed lock if the distributed lock is overdue.
After receiving the database access request, acquiring the identifier of the database access request, including:
after receiving a database access request, according to the database access request, not finding the identifier of the database access request in a redis cache;
and adding an identifier in the database access request to acquire the identifier of the database access request.
The distributed lock is a redis distributed lock.
After receiving a database access request, acquiring an identifier of the database access request, and setting a distributed lock of the identifier, including:
after receiving a database access request, acquiring an identifier of the database access request;
based on the identification of the database access request, a key is generated using the MD5 algorithm to set the distributed lock.
The generating a key to set the distributed lock using the MD5 algorithm based on the identification of the database access request includes:
generating a key using the MD5 algorithm based on the identification of the database access request;
and setting an expiration time corresponding to the key to generate the distributed lock.
The setting an expiration time corresponding to the key to generate the distributed lock includes:
and updating the corresponding expiration time of the key to generate the distributed lock.
The parameters involved in the token in the database include http stress,
the determining whether the database access request is a repeat request according to the token of the database access request and the parameters related to the token in the database includes:
and according to the token of the database access request, if the fact that the corresponding http failure does not exist in the database access request is known, the database access request is judged to be a repeated request.
The parameters referred to by the tokens in the database include the tokens to which the identifications correspond,
the determining whether the database access request is a repeat request according to the token of the database access request and the parameters related to the token in the database includes:
and according to the token of the database access request, if the token corresponding to the identifier is not found in the database, judging that the database access request is a repeated request.
The parameters related to the tokens in the database comprise the tokens corresponding to the identifications in the database,
the determining whether the database access request is a repeat request according to the token of the database access request and the parameters related to the token in the database includes:
and judging whether the database access request is a repeated request according to whether the token of the database access request is consistent with the token corresponding to the identifier in the database.
The determining whether the database access request is a repeat request according to the token of the database access request and the parameters related to the token in the database includes:
generating tokens in a database according to the identifier of the database access request, wherein the generated tokens are stored in the database, and the number of the tokens stored in the database is less than or equal to the maximum token number;
and judging whether the database access request is a repeated request or not based on the token of the database access request and the parameters related to the token in the database.
The determining whether the database access request is a repeat request according to the token of the database access request and the parameters related to the token in the database includes:
generating tokens in a database according to the identifier of the database access request, wherein the generated tokens are stored in the database, and the number of the tokens stored in the database is greater than the maximum token number;
deleting the tokens stored in the database according to the stored token establishing time and the maximum token quantity;
and judging whether the database access request is a repeated request or not based on the token of the database access request and the parameters related to the token in the database.
The executing the database access request according to the judgment result of the database access request comprises:
and if the database access request is a repeated request, rejecting the database access request.
The executing the database access request according to the judgment result of the database access request comprises:
and if the database access request is not a repeated request, executing the database access request.
The method further comprises the following steps:
and according to the identifier of the database access request, if the database access request is not responded to be processed, initiating the processing of the database access request.
Releasing the distributed lock if the distributed lock has expired, including:
and if the distributed lock is expired, deleting the identifier in the database access request to release the distributed lock.
The database access request includes one or more of: submitting the service request, updating the service request and repeatedly submitting the service request.
The method further comprises the following steps:
and if the node for processing the database access request fails, selecting one node from the nodes to continue processing the database access request.
According to a second aspect of the embodiments of the present invention, there is provided a device for determining a trade weight, including:
the setting module is used for acquiring the identifier of the database access request after receiving the database access request and setting the distributed lock of the identifier;
the judging module is used for judging whether the database access request is a repeated request according to the token of the database access request and the parameters related to the token in the database;
and the execution module is used for executing the database access request according to the judgment result of the database access request, and releasing the distribution lock if the distribution lock is overdue.
According to a third aspect of the embodiments of the present invention, there is provided an electronic device for transaction weight determination, including:
one or more processors;
a storage device for storing one or more programs,
when executed by the one or more processors, cause the one or more processors to implement the method as described above.
According to a fourth aspect of embodiments of the present invention, there is provided a computer readable medium, on which a computer program is stored, which when executed by a processor, implements the method as described above.
One embodiment of the above invention has the following advantages or benefits: after receiving a database access request, acquiring an identifier of the database access request, and setting a distributed lock of the identifier; judging whether the database access request is a repeated request or not according to the database access request and parameters related to the token in the database; and executing the database access request according to the judgment result of the database access request, and releasing the distributed lock if the distributed lock is overdue. The token and the distributed lock are combined, so that on one hand, whether the request is a repeated request is judged through the token; on the other hand, the processing time of the database access request is limited in a distributed mode, and further repeated transaction submission is avoided, so that the pressure of the server and the database can be relieved.
Further effects of the above-mentioned non-conventional alternatives will be described below in connection with the embodiments.
Drawings
The drawings are included to provide a better understanding of the invention and are not to be construed as unduly limiting the invention. Wherein:
FIG. 1 is a schematic diagram of the main flow of a method of transaction re-determination according to an embodiment of the invention;
FIG. 2 is a schematic flow chart of obtaining an identification of a database access request according to an embodiment of the present invention;
FIG. 3 is a schematic flow diagram of a distributed lock setting identification according to an embodiment of the invention;
FIG. 4 is a flowchart illustrating a method for determining whether a database access request is a repeat request according to an embodiment of the invention;
FIG. 5 is a schematic flow chart illustrating another method for determining whether a database access request is a repeat request according to an embodiment of the present invention;
fig. 6 is a schematic diagram of the main structure of a transaction re-determination apparatus according to an embodiment of the present invention;
FIG. 7 is an exemplary system architecture diagram in which embodiments of the present invention may be employed;
fig. 8 is a schematic structural diagram of a computer system suitable for implementing a terminal device or a server according to an embodiment of the present invention.
Detailed Description
Exemplary embodiments of the present invention are described below with reference to the accompanying drawings, in which various details of embodiments of the invention are included to assist understanding, and which are to be considered as merely exemplary. Accordingly, those of ordinary skill in the art will recognize that various changes and modifications of the embodiments described herein can be made without departing from the scope and spirit of the invention. Also, descriptions of well-known functions and constructions are omitted in the following description for clarity and conciseness.
In platform business transactions, the problem of pain points to prevent repeated requests is often faced. If the requested response is an operation of modifying data, etc., it will cause a great harm, such as: jitter operation, fast operation, misoperation of the front end, network communication speed or background feedback response speed are slow, and if there is an incomplete response situation, a method of preventing repeated requests is indispensable.
The above problems cause the generation of dirty data or other serious problems in the platform system if repeated submissions are made. However, when the front end triggers the operation, or pops up the confirmation interface, the repeated submission of the transaction cannot be completely limited. These resulting effects are reflected by the following example: suppose that a 9299 yuan mobile phone is bought on the internet by twenty-two, after payment, the number of visitors is too many, which causes card pause, and further needs to repeatedly click a payment button. If the platform system does not add the limit to prevent duplicate transactions, you spend 9299 x 2 prices to purchase a cell phone.
As one example, the platform system is a charitable organization integrated services platform system. Specifically, the charitable organization integrated services platform system comprises a charitable organization administrator, a donor, and a bank financing advisor. The participants of the whole business process have five categories, which are respectively: charity administrators, bank financial consultants, donors, banks, and project beneficiaries. In the web page request process, the donor donations, the project beneficiaries apply for assistance, and the charity administrator is responsible for management. When the transaction request is submitted by clicking the button, the resource is requested from the server. If the network has problems or clicks 'refresh' and the like, under the condition of no anti-replay operation, a plurality of requests can wait after clicking for a plurality of times, or the same data can be generated, and even the system is crashed.
The platform is provided with management modules such as project management (functions of issuing projects, auditing projects and the like) and service management (functions of type management, issuing contents and the like), so that how to effectively prevent a user from repeatedly submitting the same transaction request is the problem which is the first solution faced by the platform.
The general conventional solution includes the following three ways. The first method is as follows: submitting post-ash by using a js control button; the second method comprises the following steps: a token mechanism is used at the server.
However, there may be uncontrollable use of either approach alone. The first mode can not control the user to directly call the request or the check code is cleared, and meanwhile, the repeated submission caused by the buttons such as 'back' and 'refresh' can not be limited. Mode two does not apply to microservice.
Therefore, it is still difficult to avoid double submitting transactions, thereby increasing the pressure on the server and the database.
In order to solve the problem that repeated submission of transactions is difficult to avoid, and further the pressure of a server and a database is increased, the following technical scheme in the embodiment of the invention can be adopted.
Referring to fig. 1, fig. 1 is a schematic diagram of a main flow of a transaction re-determination method according to an embodiment of the present invention, in which a distributed lock is first set, and then a token is used to determine whether the transaction re-determination method is a repeat request. As shown in fig. 1, the method specifically comprises the following steps:
s101, after receiving a database access request, acquiring an identifier of the database access request, and setting a distributed lock of the identifier.
The technical scheme of the embodiment of the invention is suitable for preventing repeated submission of the database access request by adopting the page button and the micro-service. The method and the system realize that the transaction related to the database access request cannot be repeatedly submitted within a certain time, avoid the generation of dirty data and reduce the pressure of the server and the database.
Among them, microservices are a variant of the SOA architecture, which constructs applications as a set of loosely coupled services. In the microservice architecture, services are fine-grained and protocols are lightweight.
In an embodiment of the invention, the data access request comprises one or more of: submitting the service request, updating the service request and repeatedly submitting the service request.
In the specific implementation, the platform system is specifically a charitable organization integrated service platform system.
Scene one: in the event of a delay in the network, the participants submit service requests. The service request is realized by clicking the following buttons for multiple times: "save", "submit audit", and "donate". Multiple clicks will result in repeated submission of the business request.
Scene two: after the service request is submitted, the participant updates the service request, and particularly, the participant repeatedly submits the service request again by clicking a refresh button.
Scene three: after the participants successfully submit the service, jumping to a jump page to repeatedly submit the service request, and specifically clicking a 'back' button to return to the submission page, so that repeated submission is caused again.
Scene four: and the participant obtains the URL through the historical browsing records of the browser so as to repeatedly submit the service request, so that repeated submission is caused.
Referring to fig. 2, fig. 2 is a schematic flowchart of a process of obtaining an identifier of a database access request according to an embodiment of the present invention, which specifically includes:
s201, after receiving the database access request, according to the database access request, the identifier of the database access request is not found in the redis cache.
In an embodiment of the present invention, the distributed lock is a redis distributed lock. And utilizing redis to make a distributed lock, and processing the next database access request to complete only after the current database access request is completed.
The participant initiates a database access request, and the platform system searches whether the identifier of the database access request exists in a redis cache. And according to the database access request, the identifier of the database access request is not found in the redis cache.
S202, adding an identifier in the database access request to acquire the identifier of the database access request.
And if the identifier of the database access request is not found in the redis cache according to the database access request, adding the identifier in the database access request to acquire the identifier of the database access request.
In the embodiment of fig. 2, if the identifier of the database access request is not found in the redis cache, the identifier is added to the database access request.
Referring to fig. 3, fig. 3 is a schematic flowchart of a distributed lock for setting an identifier according to an embodiment of the present invention, which specifically includes the following steps:
s301, after receiving the database access request, acquiring the identifier of the database access request.
After receiving the database access request, the identifier of the database access request can be directly obtained.
S302, based on the identification of the database access request, a key is generated by using an MD5 algorithm to set a distributed lock.
The key is generated using the MD5 algorithm based on the identity of the database access request. If the database access request is submitted repeatedly, the key generated by the database access request is the same.
In one embodiment of the invention, the key is generated using the MD5 algorithm based on the identity of the database access request. Then, the corresponding expiration time of the key is set to generate the distributed lock. As an example, the expiration time of setting key 1 is 12 o' clock, 22 minutes, 10 seconds. Then, for this distributed lock, it is released directly after 12 o' clock, 22 minutes, 10 seconds.
In one embodiment of the invention, the expiration time corresponding to the key may be updated. I.e., the corresponding expiration time of the key is updated to generate the distributed lock. Specifically, the expiration time can be updated after the existing expiration time corresponding to the key is known.
In the embodiment of FIG. 3, a key is generated to enable setting of a distributed lock based on the identification of the database access request.
S102, judging whether the database access request is a repeated request or not according to the token of the database access request and parameters related to the token in the database.
In the embodiment of the invention, a token mechanism is adopted to judge whether the database access request is a repeated request. As an example, a token mechanism based on a FIFO mechanism is employed. The key point of the FIFO mechanism is that a reliable read-write pointer and full/empty state identification effectively judge the read-write state by using an extra bit.
Referring to fig. 4, fig. 4 is a schematic flowchart of a process of determining whether a database access request is a repeat request according to an embodiment of the present invention, which specifically includes the following steps:
s401, generating tokens in the database according to the identifier of the database access request, wherein the tokens are stored in the database, and the number of the tokens stored in the database is less than or equal to the maximum token number.
Specifically, before a java server page (jsp) is requested, a database access request is forwarded to a corresponding Action, and the Action calls a savotoken method to generate a new token.
That is, tokens are generated in the database according to the identifier of the database access request, the tokens are stored in the database, and if the number of the tokens stored in the database is judged to be less than or equal to the maximum token number, it is indicated that the number of the tokens stored in the database does not exceed the limit.
S402, judging whether the database access request is a repeated request or not based on the token of the database access request and the parameters related to the token in the database.
And then judging whether the database access request is a repeated request or not according to the token of the database access request and parameters related to the token in the database.
The following describes the determination of whether a database access request is a repeat request, with reference to three cases.
The first condition is as follows: the parameters involved in the database for the token include http stress,
and according to the token of the database access request, if the database access request does not have the corresponding H ttpSession, judging that the database access request is a repeated request.
Case two: the parameters referred to by the token in the database include the token corresponding to the identification of the database access request.
And according to the token of the database access request, if the token corresponding to the identifier of the database access request is not found in the database, judging that the database access request is a repeated request. This is because the server typically stores the token in the database where the first access to the database was requested, deleting the token for the database access request in the database.
Case three: the parameters referred to by the token in the database include the token corresponding to the identification of the database access request in the database,
and judging whether the database access request is a repeated request according to whether the token of the database access request is consistent with the token corresponding to the identifier of the database access request in the database.
In the embodiment of fig. 4, in the case that the number of tokens stored in the database is less than or equal to the maximum token number, it is determined whether the database access request is a repeat request.
Referring to fig. 5, fig. 5 is another schematic flowchart of determining whether a database access request is a repeat request according to an embodiment of the present invention, which specifically includes the following steps:
s501, generating tokens in the database according to the identifier of the database access request, wherein the tokens are stored in the database, and the number of the tokens stored in the database is larger than the maximum token number.
And generating tokens in the database according to the identifier of the database access request, storing the tokens in the database, and judging that the number of the tokens stored in the database is greater than the maximum token number, which indicates that the tokens stored in the database exceed the limit.
And S502, deleting the tokens stored in the database according to the stored token establishing time and the maximum token quantity.
And deleting the tokens stored in the database according to the stored token establishment time and the maximum token quantity. Specifically, the token with the earliest token establishment time is destroyed until the tokens stored in the database are less than or equal to the maximum token number.
S503, judging whether the database access request is a repeated request or not based on the token of the database access request and the parameters related to the token in the database.
Similar to the scheme in S403, it is determined whether the database access request is a repeat request according to the token of the database access request and the parameter related to the token in the database.
In the embodiment of fig. 5, in the case where the number of tokens stored in the database is greater than the maximum token number, it is determined whether the database access request is a repeat request.
S103, executing the database access request according to the judgment result of the database access request, and releasing the distribution lock if the distribution lock is overdue.
And executing the database access request according to the judgment result of the database access request. It should be noted that while executing a database access request, the presence of a distributed lock ensures that no further database access requests are received while the current database access request is executing until the distributed lock has expired.
The database access request may be executed according to the judgment result of the database access request. And if the database access request is a repeated request, rejecting the database access request. As one example, denying a database access request may show "please try again later".
And executing the database access request if the database access request is not a repeated request.
In one embodiment of the invention, if the distributed lock expires, indicating that the distributed lock can be released, the identifier in the database access request is deleted to release the distributed lock. In this way, the next database access request can be processed.
In one embodiment of the present invention, in order to process the database access request in time, if it is known that the database access request is not responded to be processed according to the identifier of the database access request, the processing of the database access request is initiated.
In one embodiment of the invention, if the node processing the database access request fails, one of the nodes is selected to continue processing the database access request.
The redis deployment scheme adopts a sentinel mode and sets one or more sentinels. As one example, a sentinel may be a slave node. When the master node is failed, a new master node is automatically selected from the slave nodes. The master node continues to process database access requests.
In the embodiment of the present invention, after receiving a database access request, an identifier of the database access request is obtained, and a distributed lock of the identifier is set; judging whether the database access request is a repeated request or not according to the database access request and parameters related to the token in the database; and executing the database access request according to the judgment result of the database access request, and releasing the distributed lock if the distributed lock is overdue. The token and the distributed lock are combined, so that on one hand, whether the request is a repeated request is judged through the token; on the other hand, the processing time of the database access request is limited in a distributed mode, and further repeated transaction submission is avoided, so that the pressure of the server and the database can be relieved.
Specifically, in the platform system, a storage server for storing lock information is built outside the distributed application server by using the token and the distributed lock. The expiration time of the lock information is set, the phenomenon that one thread occupies lock resources for a long time to cause deadlock is avoided, and simultaneously, redis atomicity is utilized to ensure that only one thread can obtain the lock at the same time. In addition, the token mode of the FIFO mechanism is adopted, so that each database access request is available, and the condition that a plurality of database access requests compete for tokens at the same time is prevented.
Referring to fig. 6, fig. 6 is a schematic diagram of a main structure of a transaction repeat determination device according to an embodiment of the present invention, where the transaction repeat determination device may implement a transaction repeat determination method, and as shown in fig. 6, the transaction repeat determination device specifically includes:
the setting module 601 is configured to obtain an identifier of a database access request after receiving the database access request, and set a distributed lock of the identifier;
a determining module 602, configured to determine whether the database access request is a repeated request according to the token of the database access request and parameters related to the token in the database;
an executing module 603, configured to execute the database access request according to a determination result of the database access request, and release the distribution lock if the distribution lock is expired.
In an embodiment of the present invention, the setting module 601 is specifically configured to, after receiving a database access request, find, according to the database access request, an identifier of the database access request in a redis cache;
and adding an identifier in the database access request to acquire the identifier of the database access request.
In one embodiment of the invention, the distributed lock is a redis distributed lock.
In an embodiment of the present invention, the setting module 601 is specifically configured to, after receiving a database access request, obtain an identifier of the database access request;
based on the identification of the database access request, a key is generated using the MD5 algorithm to set the distributed lock.
In an embodiment of the present invention, the setting module 601 is specifically configured to generate a key by using an MD5 algorithm based on the identifier of the database access request;
and setting an expiration time corresponding to the key to generate the distributed lock.
In an embodiment of the present invention, the setting module 601 is specifically configured to update an expiration time corresponding to the key to generate the distributed lock.
In one embodiment of the invention, the parameters related to the token in the database comprise Htt pSession,
the determining module 602 is specifically configured to, according to the token of the database access request, learn that there is no http response to the database access request, and determine that the database access request is a repeat request.
In one embodiment of the invention, the parameters referred to by the tokens in the database comprise tokens corresponding to the identifications,
the determining module 602 is specifically configured to determine, according to the token of the database access request, that the token corresponding to the identifier is not found in the database, and the database access request is a repeat request.
In one embodiment of the invention, the parameters referred to by the tokens in the database comprise tokens corresponding to the identifications in the database,
the determining module 602 is specifically configured to determine whether the database access request is a repeated request according to whether a token of the database access request is consistent with a token corresponding to the identifier in the database.
In an embodiment of the present invention, the determining module 602 is specifically configured to generate a token in a database according to the identifier of the database access request, where the generated token is stored in the database, and the number of tokens stored in the database is less than or equal to the maximum token number;
and judging whether the database access request is a repeated request or not based on the token of the database access request and the parameters related to the token in the database.
In an embodiment of the present invention, the determining module 602 is specifically configured to generate a token in a database according to the identifier of the database access request, where the generated token is stored in the database, and the number of tokens stored in the database is greater than the maximum token number;
deleting the tokens stored in the database according to the stored token establishing time and the maximum token quantity;
and judging whether the database access request is a repeated request or not based on the token of the database access request and the parameters related to the token in the database.
In an embodiment of the present invention, the executing module 603 is specifically configured to reject the database access request if the database access request is a repeat request.
In an embodiment of the present invention, the executing module 603 is specifically configured to execute the database access request if the database access request is not a repeat request.
In an embodiment of the present invention, the executing module 603 is further configured to, according to the identifier of the database access request, acquire that the database access request is not processed in response, and then initiate processing of the database access request.
In an embodiment of the present invention, the executing module 603 is specifically configured to delete the identifier in the database access request to release the distributed lock when the distributed lock has expired.
In one embodiment of the invention, the database access request comprises one or more of: submitting the service request, updating the service request and repeatedly submitting the service request.
In an embodiment of the present invention, the executing module 603 is further configured to, if a node processing the database access request fails, select a node from the nodes to continue processing the database access request.
Fig. 7 illustrates an exemplary system architecture 700 of a method or apparatus for transaction re-determination to which embodiments of the invention may be applied.
As shown in fig. 7, the system architecture 700 may include terminal devices 701, 702, 703, a network 704, and a server 705. The network 704 serves to provide a medium for communication links between the terminal devices 701, 702, 703 and the server 705. Network 704 may include various connection types, such as wired, wireless communication links, or fiber optic cables, to name a few.
A user may use the terminal devices 701, 702, 703 to interact with a server 705 over a network 704, to receive or send messages or the like. The terminal devices 701, 702, 703 may have installed thereon various communication client applications, such as a shopping-like application, a web browser application, a search-like application, an instant messaging tool, a mailbox client, social platform software, etc. (by way of example only).
The terminal devices 701, 702, 703 may be various electronic devices having a display screen and supporting web browsing, including but not limited to smart phones, tablet computers, laptop portable computers, desktop computers, and the like.
The server 705 may be a server providing various services, such as a background management server (for example only) providing support for shopping websites browsed by users using the terminal devices 701, 702, 703. The backend management server may analyze and perform other processing on the received data such as the product information query request, and feed back a processing result (for example, target push information, product information — just an example) to the terminal device.
It should be noted that the method for determining transaction weight provided by the embodiment of the present invention is generally executed by the server 705, and accordingly, the device for determining transaction weight is generally disposed in the server 705.
It should be understood that the number of terminal devices, networks, and servers in fig. 7 is merely illustrative. There may be any number of terminal devices, networks, and servers, as desired for implementation.
Referring now to FIG. 8, shown is a block diagram of a computer system 800 suitable for use with a terminal device implementing an embodiment of the present invention. The terminal device shown in fig. 8 is only an example, and should not bring any limitation to the functions and the scope of use of the embodiments of the present invention.
As shown in fig. 8, the computer system 800 includes a Central Processing Unit (CPU)801 that can perform various appropriate actions and processes in accordance with a program stored in a Read Only Memory (ROM)802 or a program loaded from a storage section 808 into a Random Access Memory (RAM) 803. In the RAM 803, various programs and data necessary for the operation of the system 800 are also stored. The CPU 801, ROM 802, and RAM 803 are connected to each other via a bus 804. An input/output (I/O) interface 805 is also connected to bus 804.
The following components are connected to the I/O interface 805: an input portion 806 including a keyboard, a mouse, and the like; an output section 807 including a signal such as a Cathode Ray Tube (CRT), a Liquid Crystal Display (LCD), and the like, and a speaker; a storage portion 808 including a hard disk and the like; and a communication section 809 including a network interface card such as a LAN card, a modem, or the like. The communication section 809 performs communication processing via a network such as the internet. A drive 810 is also connected to the I/O interface 805 as necessary. A removable medium 811 such as a magnetic disk, an optical disk, a magneto-optical disk, a semiconductor memory, or the like is mounted on the drive 810 as necessary, so that a computer program read out therefrom is mounted on the storage section 808 as necessary.
In particular, according to the embodiments of the present disclosure, the processes described above with reference to the flowcharts may be implemented as computer software programs. For example, embodiments of the present disclosure include a computer program product comprising a computer program embodied on a computer readable medium, the computer program comprising program code for performing the method illustrated in the flow chart. In such an embodiment, the computer program can be downloaded and installed from a network through the communication section 809 and/or installed from the removable medium 811. The computer program performs the above-described functions defined in the system of the present invention when executed by the central processing unit (CP U) 801.
It should be noted that the computer readable medium shown in the present invention can be a computer readable signal medium or a computer readable storage medium or any combination of the two. A computer readable storage medium may be, for example, but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination of the foregoing. More specific examples of the computer readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer diskette, a hard disk, a Random Access Memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing. In the present invention, a computer readable storage medium may be any tangible medium that can contain, or store a program for use by or in connection with an instruction execution system, apparatus, or device. In the present invention, however, a computer readable signal medium may include a propagated data signal with computer readable program code embodied therein, for example, in baseband or as part of a carrier wave. Such a propagated data signal may take many forms, including, but not limited to, electro-magnetic, optical, or any suitable combination thereof. A computer readable signal medium may also be any computer readable medium that is not a computer readable storage medium and that can communicate, propagate, or transport a program for use by or in connection with an instruction execution system, apparatus, or device. Program code embodied on a computer readable medium may be transmitted using any appropriate medium, including but not limited to: wireless, wire, fiber optic cable, RF, etc., or any suitable combination of the foregoing.
The flowchart and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods and computer program products according to various embodiments of the present invention. In this regard, each block in the flowchart or block diagrams may represent a module, segment, or portion of code, which comprises one or more executable instructions for implementing the specified logical function(s). It should also be noted that, in some alternative implementations, the functions noted in the block may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams or flowchart illustration, and combinations of blocks in the block diagrams or flowchart illustration, can be implemented by special purpose hardware-based systems which perform the specified functions or acts, or combinations of special purpose hardware and computer instructions.
The modules described in the embodiments of the present invention may be implemented by software or hardware. The described modules may also be provided in a processor, which may be described as: a processor includes a setting module, a judging module and an executing module. The names of the modules do not form a limitation on the modules themselves in some cases, for example, the setting module may also be described as "a distributed lock for acquiring an identifier of a database access request and setting the identifier after receiving the database access request".
As another aspect, the present invention also provides a computer-readable medium that may be contained in the apparatus described in the above embodiments; or may be separate and not incorporated into the device. The computer readable medium carries one or more programs which, when executed by a device, cause the device to comprise:
after receiving a database access request, acquiring an identifier of the database access request, and setting a distributed lock of the identifier;
judging whether the database access request is a repeated request or not according to the token of the database access request and parameters related to the token in the database;
and executing the database access request according to the judgment result of the database access request, and releasing the distributed lock if the distributed lock is overdue.
According to the technical scheme of the embodiment of the invention, after a database access request is received, an identifier of the database access request is obtained, and a distributed lock of the identifier is set; judging whether the database access request is a repeated request or not according to the database access request and parameters related to the token in the database; and executing the database access request according to the judgment result of the database access request, and releasing the distributed lock if the distributed lock is overdue. The token and the distributed lock are combined, so that on one hand, whether the request is a repeated request is judged through the token; on the other hand, the processing time of the database access request is limited in a distributed mode, and further repeated transaction submission is avoided, so that the pressure of the server and the database can be relieved.
The above-described embodiments should not be construed as limiting the scope of the invention. Those skilled in the art will appreciate that various modifications, combinations, sub-combinations, and substitutions can occur, depending on design requirements and other factors. Any modification, equivalent replacement, and improvement made within the spirit and principle of the present invention should be included in the protection scope of the present invention.
Claims (20)
1. A method for transaction re-determination, comprising:
after receiving a database access request, acquiring an identifier of the database access request, and setting a distributed lock of the identifier;
judging whether the database access request is a repeated request or not according to the token of the database access request and parameters related to the token in the database;
and executing the database access request according to the judgment result of the database access request, and releasing the distributed lock if the distributed lock is overdue.
2. The method for transaction reiteration according to claim 1, wherein said obtaining an identifier of said database access request after receiving said database access request comprises:
after receiving a database access request, according to the database access request, not finding the identifier of the database access request in a redis cache;
and adding an identifier in the database access request to acquire the identifier of the database access request.
3. The method of claim 1, wherein the distributed lock is a redis distributed lock.
4. The method for transaction reiteration according to claim 1, wherein said obtaining an identifier of said database access request and setting a distributed lock of said identifier after receiving said database access request comprises:
after receiving a database access request, acquiring an identifier of the database access request;
based on the identification of the database access request, a key is generated using the MD5 algorithm to set the distributed lock.
5. The method of claim 4, wherein generating a key to set the distributed lock using the MD5 algorithm based on the identification of the database access request comprises:
generating a key using the MD5 algorithm based on the identification of the database access request;
and setting an expiration time corresponding to the key to generate the distributed lock.
6. The method of claim 5, wherein the setting an expiration time corresponding to the key to generate the distributed lock comprises:
and updating the corresponding expiration time of the key to generate the distributed lock.
7. The method of claim 1, wherein the parameters related to the token in the database include http session,
the determining whether the database access request is a repeat request according to the token of the database access request and the parameters related to the token in the database includes:
and according to the token of the database access request, if the fact that the corresponding http failure does not exist in the database access request is known, the database access request is judged to be a repeated request.
8. The method of claim 1, wherein the parameters related to the tokens in the database include the tokens corresponding to the identifications,
the determining whether the database access request is a repeat request according to the token of the database access request and the parameters related to the token in the database includes:
and according to the token of the database access request, if the token corresponding to the identifier is not found in the database, judging that the database access request is a repeated request.
9. The method of claim 1, wherein the parameters related to the tokens in the database include the tokens corresponding to the identifiers in the database,
the determining whether the database access request is a repeat request according to the token of the database access request and the parameters related to the token in the database includes:
and judging whether the database access request is a repeated request according to whether the token of the database access request is consistent with the token corresponding to the identifier in the database.
10. The method for transaction re-judgment according to claim 1, wherein the judging whether the database access request is a repeated request according to the token of the database access request and the parameters related to the token in the database comprises:
generating tokens in a database according to the identifier of the database access request, wherein the generated tokens are stored in the database, and the number of the tokens stored in the database is less than or equal to the maximum token number;
and judging whether the database access request is a repeated request or not based on the token of the database access request and the parameters related to the token in the database.
11. The method for transaction re-judgment according to claim 1, wherein the judging whether the database access request is a repeated request according to the token of the database access request and the parameters related to the token in the database comprises:
generating tokens in a database according to the identifier of the database access request, wherein the generated tokens are stored in the database, and the number of the tokens stored in the database is greater than the maximum token number;
deleting the tokens stored in the database according to the stored token establishing time and the maximum token quantity;
and judging whether the database access request is a repeated request or not based on the token of the database access request and the parameters related to the token in the database.
12. The method for transaction reiteration according to claim 1, wherein said executing the database access request according to the determination result of the database access request comprises:
and if the database access request is a repeated request, rejecting the database access request.
13. The method for transaction reiteration according to claim 1, wherein said executing the database access request according to the determination result of the database access request comprises:
and if the database access request is not a repeated request, executing the database access request.
14. The method of claim 1, wherein the method further comprises:
and according to the identifier of the database access request, if the database access request is not responded to be processed, initiating the processing of the database access request.
15. The method of claim 1, wherein releasing the distributed lock if the distributed lock has expired comprises:
and if the distributed lock is expired, deleting the identifier in the database access request to release the distributed lock.
16. The method of claim 1, wherein the database access request comprises one or more of: submitting the service request, updating the service request and repeatedly submitting the service request.
17. The method of claim 1, wherein the method further comprises:
and if the node for processing the database access request fails, selecting one node from the nodes to continue processing the database access request.
18. An apparatus for transaction re-determination, comprising:
the setting module is used for acquiring the identifier of the database access request after receiving the database access request and setting the distributed lock of the identifier;
the judging module is used for judging whether the database access request is a repeated request according to the token of the database access request and the parameters related to the token in the database;
and the execution module is used for executing the database access request according to the judgment result of the database access request, and releasing the distribution lock if the distribution lock is overdue.
19. An electronic device for transaction re-determination, comprising:
one or more processors;
a storage device for storing one or more programs,
when executed by the one or more processors, cause the one or more processors to implement the method of any one of claims 1-17.
20. A computer-readable medium, on which a computer program is stored, which, when being executed by a processor, carries out the method according to any one of claims 1-17.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202110339808.2A CN112819638A (en) | 2021-03-30 | 2021-03-30 | Transaction weight judging method, device, equipment and computer readable medium |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202110339808.2A CN112819638A (en) | 2021-03-30 | 2021-03-30 | Transaction weight judging method, device, equipment and computer readable medium |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN112819638A true CN112819638A (en) | 2021-05-18 |
Family
ID=75863627
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202110339808.2A Pending CN112819638A (en) | 2021-03-30 | 2021-03-30 | Transaction weight judging method, device, equipment and computer readable medium |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN112819638A (en) |
Cited By (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN113778697A (en) * | 2021-09-14 | 2021-12-10 | 福建天晴数码有限公司 | Method and system for realizing high availability of redis distribution lock |
| CN116824724A (en) * | 2023-08-30 | 2023-09-29 | 深圳市永兴元科技股份有限公司 | Network card punching timing management method, device, equipment and storage medium |
-
2021
- 2021-03-30 CN CN202110339808.2A patent/CN112819638A/en active Pending
Cited By (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN113778697A (en) * | 2021-09-14 | 2021-12-10 | 福建天晴数码有限公司 | Method and system for realizing high availability of redis distribution lock |
| CN116824724A (en) * | 2023-08-30 | 2023-09-29 | 深圳市永兴元科技股份有限公司 | Network card punching timing management method, device, equipment and storage medium |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| KR102510195B1 (en) | Transaction Processing Methods, Devices and Appliances, and Computer Storage Media | |
| CN111277639B (en) | Method and device for maintaining data consistency | |
| CN111260474B (en) | Asset transaction method, device, equipment, system and storage medium of cross-blockchain | |
| CN111198751A (en) | Service processing method and device | |
| CN112819638A (en) | Transaction weight judging method, device, equipment and computer readable medium | |
| CN111857888B (en) | Transaction processing method and device | |
| CN111126948A (en) | Processing method and device for approval process | |
| CN111831461A (en) | Method and device for processing business process | |
| CN114327799A (en) | Distributed transaction processing method and device, electronic equipment and storage medium | |
| CN111324615A (en) | Data processing method, device, medium and electronic equipment | |
| CN112884181A (en) | Quota information processing method and device | |
| CN113760924A (en) | Distributed transaction processing method and device | |
| CN111343239A (en) | Communication request processing method, communication request processing device and transaction system | |
| CN112948138A (en) | Method and device for processing message | |
| CN113553206B (en) | Data event execution method and device, electronic equipment and computer readable medium | |
| US20230093004A1 (en) | System and method for asynchronous backend processing of expensive command line interface commands | |
| CN115421922A (en) | Current limiting method, device, equipment, medium and product of distributed system | |
| CN113726885A (en) | Method and device for adjusting flow quota | |
| CN113114768A (en) | Service request processing method, device and system | |
| CN113760487A (en) | Service processing method and device | |
| CN111681026A (en) | Resource allocation method and device, electronic equipment and computer readable storage medium | |
| CN111771191A (en) | Cross-domain inline event handler | |
| CN109561146A (en) | Document down loading method, device, terminal device | |
| CN113760886B (en) | Method, apparatus, device and computer readable medium for providing data service | |
| CN116167835A (en) | Service processing method, device, electronic equipment and computer readable medium |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination |