Anti-retriggering method for operation task click behavior in multiple scenes

Abstract

The invention discloses an anti-retriggering method for operation task clicking behaviors in multiple scenes. The anti-retriggering method comprises the steps that Redis distributed locking is adopted; recording a database task table process; an unlocking task process; and a task cleaning process. A set of complete multi-scheme integrated general scheme is given by using a Redis distributed lock and a task record table.

Description

Technical Field

[0001] This invention relates to the field of financial business systems, and in particular to a method for preventing repeated triggering of click behavior in operation tasks under multiple scenarios. Background Technology

[0002] In financial systems, the accuracy and security of click operations are paramount, making the prevention of duplicate clicks crucial for protecting user funds. In multi-user collaborative or distributed systems, multiple users may simultaneously click on the same resource, necessitating effective mechanisms to prevent duplicate triggering and ensure system consistency and stability. Sometimes, in different network environments, especially under weak network conditions, click response may be delayed. Users may click again due to delayed feedback, resulting in duplicate requests being sent to the server. This not only increases server load but can also lead to data inconsistencies, impacting normal business operations. For example, in critical business scenarios like order submission and payment, duplicate requests could result in multiple deductions or duplicate order generation. For devices with limited performance or complex software systems, click event processing may be slow. Without effective anti-triggering mechanisms, excessive clicks can overload the system, further degrading performance and even causing crashes. Furthermore, users may click the same button or area multiple times during rapid operations or when impatient, triggering the same task repeatedly—unintentionally—which can negatively impact the system and business operations.

[0003] Existing "anti-repeated triggering mechanisms for click behavior in multi-scenario operations" either only involve front-end processing or only involve back-end processing. This approach has the following problems: 1) When only front-end processing is done, it can often only prevent repeated clicks by individuals and there are some problems such as front-end page refresh failure, failure of multiple pages or multiple tabs, and difficulty in accurately setting time intervals. 2) When only backend processing is performed, there are often problems such as limited concurrency performance, unfriendly error messages, and lack of integration of multiple solutions; 3) There is no complete front-end and back-end integration solution or a complete solution integrating multiple solutions. Summary of the Invention

[0004] In view of the above problems, the present invention is proposed to provide a method for preventing repeated triggering of click behavior in operation tasks under multiple scenarios, so as to overcome or at least partially solve the above problems.

[0005] According to one aspect of the present invention, a method for preventing repeated triggering of operation task click behavior in multiple scenarios is provided, the method comprising: Redis distributed locking is used; Record the process of the database task table; Unlocking the mission process; Cleanup process.

[0006] Optionally, the use of Redis distributed locking specifically includes: When a user triggers an operation task, an attempt is made to acquire a Redis-based distributed lock using the task ID. If the task lock is not acquired, a new task lock is created using the Redis SETNX command, and an expiration time is set. If a task lock is acquired, check if the value of the task lock belongs to the current operator. If it does, reset the expiration time and delay the task lock; otherwise, return the message "An operator is currently processing" directly.

[0007] Optionally, the task lock specifically includes: a key for the task ID and a value for the operator.

[0008] Optionally, the process of recording the database task table specifically includes: After successfully locking, check the task table for the person based on the task number ID. If the person does not exist, add a new task record. The system checks whether the current operator is involved. Instead of directly returning the message "An operator is currently processing," it allows the execution of the specific business logic to proceed. The task table is a table in the database, usually with the task ID set as the primary key, used to store detailed information about the operation task.

[0009] Optionally, the newly added task record specifically includes: recording the task ID, operator, start time, and processing identifier as pending.

[0010] Optionally, the details include: task ID, operator, processing identifier, start time and end time.

[0011] Optionally, the unlocking process specifically includes: Once the operation task is completed, release the Redis task lock and update the task table record.

[0012] Optionally, the task table records specifically include: end time and processing identifier.

[0013] Optionally, the cleanup task process specifically includes: For tasks whose Redis task locks have expired, the records in the task table are periodically cleaned up using the Redis lock expiration monitoring mechanism; A function to manually clear tasks is provided. If a task has been occupied by operator A for a long time without being processed, and operator B is in a hurry to process the task, the manual task clearing function can release the Redis distributed lock held by operator A and delete operator A's task record, thus freeing the task for other operators to operate.

[0014] This invention provides a method for preventing repeated triggering of operation task click behavior in multiple scenarios. The method includes: using Redis distributed locking; recording the process in the database task table; unlocking the task process; and cleaning up the task process. A complete and universal solution integrating multiple methods is provided by utilizing Redis distributed locking and a task record table.

[0015] The above description is merely an overview of the technical solution of the present invention. In order to better understand the technical means of the present invention and to implement it in accordance with the contents of the specification, and in order to make the above and other objects, features and advantages of the present invention more apparent and understandable, specific embodiments of the present invention are described below. Attached Figure Description

[0016] To more clearly illustrate the technical solutions of the embodiments of the present invention, the drawings used in the following description of the embodiments will be briefly introduced. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0017] Figure 1 A flowchart of a method for preventing repeated triggering of click behavior in operation tasks under multiple scenarios provided by an embodiment of the present invention; Figure 2 A flowchart of Redis distributed locking provided in an embodiment of the present invention; Figure 3 A flowchart illustrating the process of recording database task tables provided in an embodiment of the present invention; Figure 4 A flowchart of the unlocking task process provided in an embodiment of the present invention; Figure 5 A flowchart of the cleanup task process provided in an embodiment of the present invention. Detailed Implementation

[0018] Exemplary embodiments of the present disclosure will now be described in more detail with reference to the accompanying drawings. While exemplary embodiments of the present disclosure are shown in the drawings, it should be understood that the present disclosure may be implemented in various forms and should not be limited to the embodiments set forth herein. Rather, these embodiments are provided so that this disclosure will be thorough and complete, and will fully convey the scope of the disclosure to those skilled in the art.

[0019] The terms "comprising" and "having," and any variations thereof, in the specification, embodiments, claims, and drawings of this invention are intended to cover non-exclusive inclusion, such as including a series of steps or units.

[0020] The technical solution of the present invention will be further described in detail below with reference to the accompanying drawings and embodiments.

[0021] The "anti-duplicate triggering mechanism for click behavior in multiple scenarios" mainly utilizes a "Redis distributed lock + task record table" to prevent continuous repeated clicks of the same task and simultaneous clicks by multiple people, thereby ensuring that each operation task is executed safely and reliably only once. The overall solution flowchart is as follows... Figure 1 As shown.

[0022] The "anti-duplicate triggering mechanism for operation task click behavior in multiple scenarios" implemented based on "Redis distributed lock + task record table" works mainly in the following ways: 1. Redis distributed locking process When a user triggers an operation task, the system first attempts to acquire a Redis-based distributed lock using the task ID. If the task lock is not acquired, a new task lock (with the task ID as the key and the operator as the value) can be added using the Redis SETNX command, and an expiration time can be set. If the task lock is acquired, it checks if the value of the task lock belongs to the current operator. If it does, the expiration time is reset and the task lock is delayed; otherwise, the system directly returns the message "An operator is currently processing the task." The specific flowchart is as follows... Figure 2 As shown.

[0023] 2. Record the database task table process After successful locking, the task table is queried based on the task ID to see if the person already exists. If not, a new task record is added (recording the task ID, operator, start time, and processing identifier, set to pending). If it exists, it is checked whether the current operator is present. Instead of directly returning the message "An operator is currently processing," the specific business logic is allowed to proceed. The task table is a table in the database, typically with the task ID set as the primary key, used to store detailed information about the operation task, such as task ID, operator, processing identifier, start time, and end time, for subsequent querying and management. The specific process is as follows... Figure 3 As shown.

[0024] 3. Unlocking the mission process Once the operation task is completed, the Redis task lock is released and the task table record (end time, processing flag) is updated. The specific process is as follows: Figure 4 As shown.

[0025] 4. Task cleanup process For tasks whose Redis task locks have expired, the Redis lock expiration monitoring mechanism can periodically clean up the records in the task table. A manual task cleanup function can also be provided. If a task has been held by operator A for a long time without being processed, and operator B urgently needs to process the task, the manual task cleanup function can release the Redis distributed lock held by operator A and delete operator A's task record, thus freeing up the task for other operators to operate. The specific process is as follows: Figure 5 As shown.

[0026] Beneficial effects: This is an integrated solution process for an anti-duplicate triggering mechanism for operation task click behavior in multiple scenarios, implemented based on "Redis distributed lock + task record table".

[0027] This paper proposes a solution that combines Redis distributed locks with a task log table to address some of the existing problems and provides a comprehensive general solution integrating multiple approaches.

[0028] The above specific embodiments further illustrate the purpose, technical solution, and beneficial effects of the present invention. It should be understood that the above are merely specific embodiments of the present invention and are not intended to limit the scope of protection of the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the scope of protection of the present invention.

Claims

1. A method for preventing repeated triggering of click behavior in multi-scenario operation tasks, characterized in that, The method for preventing repeated triggering includes: Redis distributed locking is used; Record the process of the database task table; Unlocking the mission process; Cleanup process.

2. The method for preventing repeated triggering of click behavior in multi-scenario operation tasks according to claim 1, characterized in that, The specific implementation of Redis distributed locking includes: When a user triggers an operation task, an attempt is made to acquire a Redis-based distributed lock using the task ID. If the task lock is not acquired, a new task lock is created using the Redis SETNX command, and an expiration time is set. If a task lock is acquired, check if the value of the task lock belongs to the current operator. If it does, reset the expiration time delay task lock; otherwise, directly return the message "An operator is currently processing".

3. The method for preventing repeated triggering of click behavior in multi-scenario operation tasks according to claim 1, characterized in that, The task lock specifically includes: a key for the task ID and a value for the operator.

4. The method for preventing repeated triggering of click behavior in multi-scenario operation tasks according to claim 1, characterized in that, The process of recording the database task table specifically includes: After successfully locking, check the task table for the person based on the task number ID. If the person does not exist, add a new task record. The system checks whether the current operator is involved. Instead of directly returning the message "An operator is currently processing," it allows the execution of the specific business logic to proceed. The task table is a table in the database, usually with the task ID set as the primary key, used to store detailed information about the operation task.

5. The method for preventing repeated triggering of click behavior in multi-scenario operation tasks according to claim 4, characterized in that, The newly added task record specifically includes: recording the task ID, operator, start time, and setting the processing identifier to pending processing.

6. The method for preventing repeated triggering of click behavior in multi-scenario operation tasks according to claim 4, characterized in that, The detailed information includes: task ID, operator, processing identifier, start time, and end time.

7. The method for preventing repeated triggering of click behavior in multi-scenario operation tasks according to claim 1, characterized in that, The unlocking process specifically includes: Once the operation task is completed, release the Redis task lock and update the task table record.

8. The method for preventing repeated triggering of click behavior in multi-scenario operation tasks according to claim 7, characterized in that, The task table records specifically include: end time and processing identifier.

9. The method for preventing repeated triggering of click behavior in multi-scenario operation tasks according to claim 1, characterized in that, The cleanup task process specifically includes: For tasks whose Redis task locks have expired, the records in the task table are periodically cleaned up using the Redis lock expiration monitoring mechanism; A function to manually clear tasks is provided. If a task has been occupied by operator A for a long time without being processed, and operator B is in a hurry to process the task, the manual task clearing function can release the Redis distributed lock held by operator A and delete operator A's task record, thus freeing the task for other operators to operate.

Images