Methods, apparatus, computer equipment, and storage media for identifying abnormal transaction events

Abstract

This application relates to a method, apparatus, computer device, storage medium, and computer program product for identifying abnormal transaction events, and pertains to the field of artificial intelligence technology. The method includes: in response to a target transaction event, determining the event category of the target transaction event; if the event category of the target transaction event is a submission event, searching in an identifier cache based on the event identifier of the target transaction event; if no submission event identifier corresponding to the event identifier of the target transaction event is found in the identifier cache, then searching in a historical transaction log set based on the event identifier of the target transaction event; if a historical transaction log corresponding to the event identifier of the target transaction event is found in the historical transaction log set, then the target transaction event is identified as an abnormal transaction event. This solution can identify abnormal transaction events.

Description

Technical Field

[0001] This application relates to the field of artificial intelligence technology, and in particular to a method, apparatus, computer device, storage medium, and computer program product for handling abnormal transaction events. Background Technology

[0002] Currently, in resource trading, users typically determine whether to initiate a new transaction based on the outcome of the previous transaction. During the transaction process, situations may arise where later-submitted transactions are processed before earlier-submitted ones (i.e., out-of-order processing). If the outcome of a later-submitted transaction is determined based on the processing status of earlier-submitted transactions, then the later-submitted transaction is considered an abnormal transaction.

[0003] For example, a paired transaction event group includes a submit transaction event and a query transaction event, where the query transaction event is used to check the processing status of the submit transaction event. However, during the transaction processing, if network transmission problems occur, such as network latency or network transmission anomalies, a query transaction event submitted later may be processed before an earlier submit transaction event (i.e., out-of-order processing), leading to incorrect query results for the later-submitted query transaction event.

[0004] However, current trading technology is unable to identify abnormal trading events, making it impossible for trading personnel or trading systems to provide early warnings or control over such events. Therefore, there is an urgent need for a method to identify abnormal trading events. Summary of the Invention

[0005] Therefore, it is necessary to provide a method, apparatus, computer device, computer-readable storage medium, and computer program product for identifying abnormal transaction events, which can identify abnormal transaction events, in order to address the above-mentioned technical problems.

[0006] Firstly, this application provides a method for identifying abnormal transaction events. The method includes:

[0007] In response to a target transaction event, determine the event category of the target transaction event;

[0008] If the event category of the target transaction event is a submission event, the event is retrieved from the identifier cache information based on the event identifier of the target transaction event; the identifier cache information stores submission event identifiers, which are used to characterize the event identifiers of submission events whose query results are submission failures.

[0009] If the submission event identifier corresponding to the event identifier of the target transaction event is not found in the identifier cache information, then a search is performed in the historical transaction log set based on the event identifier of the target transaction event;

[0010] If the historical transaction log corresponding to the event identifier of the target transaction event is found in the historical transaction log set, the target transaction event is identified as an abnormal transaction event.

[0011] In one embodiment, after retrieving the identifier from the identifier cache information based on the event identifier of the target transaction event, the method further includes:

[0012] If the submission event identifier corresponding to the event identifier of the target transaction event is found in the identifier cache information, then the target transaction event is identified as an abnormal transaction event.

[0013] In one embodiment, after determining the event category of the target transaction event, the method further includes:

[0014] If the event category of the target transaction event is a query event, then the target transaction event will be identified as a normal transaction event.

[0015] In one embodiment, after retrieving the target transaction event from the historical transaction log set based on the event identifier, the method further includes:

[0016] If no historical transaction log corresponding to the event identifier of the target transaction event is found in the historical transaction log set, the target transaction event is identified as a normal transaction event.

[0017] In one embodiment, after determining the event category of the target transaction event, the method further includes:

[0018] If the event category of the target transaction event is a query event, then query whether there is a transaction result for the target transaction event;

[0019] If a transaction result exists for the target transaction event, the transaction log of the target transaction event is stored in the historical transaction log set.

[0020] In one embodiment, when the event category of the target transaction event is a query event, the event identifier includes a user identifier, a transaction identifier, and an auxiliary identifier; the auxiliary identifier is the transaction identifier of the submission event queried by the query event; after determining the event category of the target transaction event, the method further includes:

[0021] If the query result of the target transaction event is a submission failure, then the submission event information of the target transaction event is constructed based on the user identifier and the auxiliary identifier of the target transaction event, and the submission event information is stored in the identifier cache information.

[0022] In one embodiment, the method for identifying abnormal transaction events further includes:

[0023] If the submission event identifier corresponding to the event identifier of the target transaction event is found in the identifier cache information, then the processing of the target transaction event is stopped.

[0024] In one embodiment, the method for identifying abnormal transaction events further includes:

[0025] If the historical transaction log corresponding to the event identifier of the target transaction event is found in the historical transaction log, an alarm will be triggered.

[0026] Secondly, this application also provides a device for identifying abnormal transaction events. The device includes:

[0027] A determination module is used to determine the event category of a target transaction event in response to the target transaction event;

[0028] The first retrieval module is used to retrieve information from the identifier cache based on the event identifier of the target transaction event when the event category of the target transaction event is a submission event; the identifier cache stores submission event identifiers, which are used to characterize the event identifiers of submission events whose query results are submission failures.

[0029] The second retrieval module is used to search in the historical transaction log set according to the event identifier of the target transaction event if the submission event identifier corresponding to the event identifier of the target transaction event is not found in the identifier cache information.

[0030] The third retrieval module is used to identify the target transaction event as an abnormal transaction event if the historical transaction log corresponding to the event identifier of the target transaction event is found in the historical transaction log.

[0031] In one embodiment, the device for identifying abnormal transaction events further includes:

[0032] The first identification module is used to identify the target transaction event as an abnormal transaction event if a submission event identifier corresponding to the event identifier of the target transaction event is found in the identifier cache information.

[0033] In one embodiment, the device for identifying abnormal transaction events further includes:

[0034] The second identification module is used to identify the target transaction event as a normal transaction event if the event category of the target transaction event is a query event.

[0035] In one embodiment, the device for identifying abnormal transaction events further includes:

[0036] The third identification module is used to identify the target transaction event as a normal transaction event if no historical transaction log corresponding to the event identifier of the target transaction event is found in the historical transaction log set.

[0037] In one embodiment, the device for identifying abnormal transaction events further includes:

[0038] The query module is used to query whether there is a transaction result for the target transaction event if the event category of the target transaction event is a query event;

[0039] The first construction module is used to store the transaction log of the target transaction event into the historical transaction log set if a transaction result of the target transaction event exists.

[0040] In one embodiment, when the event category of the target transaction event is a query event, the event identifier includes a user identifier, a transaction identifier, and an auxiliary identifier; the auxiliary identifier is the transaction identifier of the submission event queried by the query event; the abnormal transaction event identification device further includes:

[0041] The second construction module is used to construct the submission event information of the target transaction event based on the user identifier and the auxiliary identifier of the target transaction event if the query result of the target transaction event is submission failure, and to store the submission event information in the identifier cache information.

[0042] In one embodiment, the device for identifying abnormal transaction events further includes:

[0043] The stop module is used to stop processing the target transaction event if the submission event identifier corresponding to the event identifier of the target transaction event is found in the identifier cache information.

[0044] In one embodiment, the device for identifying abnormal transaction events further includes:

[0045] The alarm module is used to trigger an alarm if the historical transaction log corresponding to the event identifier of the target transaction event is found in the historical transaction log.

[0046] Thirdly, this application also provides a computer device. The computer device includes a memory and a processor, the memory storing a computer program, and the processor executing the computer program to implement the steps described in the first aspect.

[0047] Fourthly, this application also provides a computer-readable storage medium. The computer-readable storage medium stores a computer program thereon, which, when executed by a processor, implements the steps described in the first aspect.

[0048] Fifthly, this application also provides a computer program product. The computer program product includes a computer program that, when executed by a processor, performs the steps described in the first aspect.

[0049] The aforementioned methods, devices, computer equipment, storage media, and computer program products for monitoring abnormal transaction events, when the target transaction event's event category is a submission event, search the identifier cache information based on the target transaction event's event identifier. If no corresponding submission event identifier is found, a search is performed in the historical transaction log set. If a corresponding historical transaction log is found, the target transaction event is identified as an abnormal transaction event. It can be understood that since the submission event identifier in the identifier cache information is used to characterize the event identifier of a submission event whose query result is a submission failure, if the target transaction event has a corresponding submission event identifier in the identifier cache information, it means that the identifier cache information contains a query event that was processed earlier, while the target transaction event is a submission event that was processed later. Therefore, the target transaction event in this case is an abnormal transaction event. Similarly, when the target transaction event is a submission event, if the target transaction event has a corresponding historical transaction log, it means that the historical transaction log set contains a query event that was processed earlier. Therefore, the target transaction event in this case is an abnormal transaction event. Therefore, this solution can identify whether a target transaction event is an abnormal transaction event, thereby enabling transaction processing personnel or the transaction system to clearly determine whether the current target transaction event is an abnormal transaction event. Attached Figure Description

[0050] Figure 1 This is an application environment diagram of an abnormal transaction event identification method in one embodiment;

[0051] Figure 2 This is a flowchart illustrating a method for identifying abnormal transaction events in one embodiment;

[0052] Figure 3 This is a flowchart illustrating a method for constructing a historical transaction log set in one embodiment;

[0053] Figure 4This is a structural block diagram of an abnormal transaction event identification device in one embodiment;

[0054] Figure 5 This is an internal structural diagram of a computer device in one embodiment. Detailed Implementation

[0055] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0056] The abnormal transaction event identification method provided in this application embodiment can be applied to, for example, Figure 1 The application environment shown is illustrated. Terminal 102 communicates with server 104 via a network. A data storage system stores the data that server 104 needs to process. The data storage system can be integrated onto server 104 or deployed on the cloud or other network servers. Server 104 includes a transaction business analysis system and an abnormal transaction event identification system, which are connected via communication. In one embodiment, the data storage system includes a message queue. The message queue can be Kafka, RocketMQ, or RabbitMQ. The transaction business analysis system is connected to the message queue, and the message queue is connected to the abnormal transaction event identification system. The abnormal transaction event identification system includes identifier cache information and a collection of historical transaction logs. Terminal 102 can be, but is not limited to, various personal computers, laptops, smartphones, tablets, IoT devices, and portable wearable devices. IoT devices can be smart speakers, smart TVs, smart air conditioners, smart in-vehicle devices, etc. Portable wearable devices can be smartwatches, smart bracelets, head-mounted devices, etc. Server 104 can be implemented using a standalone server or a server cluster consisting of multiple servers. The transaction analysis system and the abnormal transaction event identification system can be located on the same independent server or on different independent servers. The server may also include a transaction processing system; the transaction processing system is used to process target transaction events and generate transaction results for the target transaction events.

[0057] Terminal 102 initiates a transaction request for the target transaction event, which is sent to server 104 via the network. The transaction business analysis system receives and analyzes the transaction request for the target transaction event, obtaining the event data of the target transaction event. The event data includes the event category and the event identifier. If the event category of the target transaction event is a submission event, the transaction business analysis system sends the event data of the target transaction event to the abnormal transaction event identification system. The abnormal transaction event identification system uses the event identifier of the target transaction event as a keyword and searches the identifier cache information based on this keyword. If the abnormal transaction event identification system does not find the submission event identifier corresponding to the event identifier of the target transaction event in the identifier cache information, it then searches the historical transaction log set based on the keyword. If the abnormal transaction event identification system finds the historical transaction log corresponding to the event identifier of the target transaction event in the historical transaction log set, it identifies the target transaction event as an abnormal transaction event. The abnormal transaction event identification system sends the identification result of the target transaction event as an abnormal transaction event to the transaction business analysis system. Upon receiving a result indicating that a target transaction event is an abnormal transaction event, the transaction analysis system initiates an alarm. In one embodiment, the alarm can be triggered by the transaction analysis system sending a notification message to terminal 102. This notification message indicates that the target transaction event has been processed.

[0058] In one embodiment, such as Figure 2 As shown, a method for identifying abnormal transaction events is provided, and this method is applied to... Figure 1 Taking server 104 as an example, the following steps are included:

[0059] Step 202: In response to the target transaction event, determine the event category of the target transaction event.

[0060] In this embodiment, server 104 receives and analyzes the transaction request for the target transaction event sent by terminal 102 to obtain event data for the target transaction event. The event data includes the event category and the event identifier. The event categories for the target transaction event include submission events and query events. Submission events are transaction events involving changes in user funds. Query events are transaction events used to query the processing status of submission events. Server 104 determines the event category of the target transaction event based on the event data.

[0061] Step 204: If the event category of the target transaction event is a submission event, retrieve the information from the identifier cache based on the event identifier of the target transaction event.

[0062] The event identifier is used to distinguish different target transaction events. The event identifier for a submission event includes the user identifier and the transaction identifier; the event identifier for a query event includes the user identifier, the transaction identifier, and an auxiliary identifier; the identifier cache information stores the submission event identifier, which is used to characterize the submission event where the query result is a submission failure.

[0063] In this embodiment, when server 104 determines that the target transaction event is a submission event, server 104 uses the event identifier as a keyword to search in the identifier cache information. A submission event is a transaction event involving changes in user funds. Optionally, a submission event can be a transaction event submitting a transfer or a transaction event submitting a purchase of financial products. It can be understood that one user corresponds to one user identifier, and one transaction event corresponds to one transaction identifier. For the same user, different target transaction events will have different transaction identifiers. A group of transaction events includes query events and submission events. Query events are used to query the processing status of submission events in the group of transaction events; the processing status of submission events includes transaction results and transaction data. Specifically, a submission event is a transaction event involving changes in user funds. A query event is a transaction event used to query the processing status of submission events. Within the same transaction event group, if the transaction result of the submit event has been processed when the query event is processed, then the query result for the query event is "submission successful." Conversely, if the transaction result of the submit event has not been processed when the query event is processed, then the query result for the query event is "submission failed." The submit event identifier is derived from the event identifier of the query event whose result is "submission failed." Specifically, the submit event identifier includes the user identifier and an auxiliary identifier of the query event whose result is "submission failed." Since the user identifier of the query event is the same as the user identifier of the submit event, and the auxiliary identifier of the query event is the same as the transaction identifier of the submit event, the submit event identifier of the query event is equal to the event identifier of the submit event in the same transaction event group as the query event.

[0064] Step 206: If the submission event identifier corresponding to the event identifier of the target transaction event is not found in the identifier cache information, then the historical transaction log set is searched according to the event identifier of the target transaction event.

[0065] In this embodiment, if the server 104 does not find the submission event identifier corresponding to the event identifier of the target transaction event in the identifier cache information, the server 104 then searches in the historical transaction log set according to the keyword obtained in step 204. The historical transaction log set contains historical transaction logs of historical transaction events. Historical transaction events are those that have been processed by the server 104 and have processing results. In one embodiment, a historical transaction event is a historical query event. In another embodiment, the event type of a historical transaction event includes historical query events and historical submission events. The historical transaction log includes event data of historical transaction events. The event data includes event category and event identifier.

[0066] Step 208: If the historical transaction log corresponding to the event identifier of the target transaction event is found in the historical transaction log set, the target transaction event is identified as an abnormal transaction event.

[0067] In this embodiment, if server 104 retrieves the historical transaction log corresponding to the event identifier of the target transaction event from the historical transaction log set, server 104 identifies the target transaction event as an abnormal transaction event. An abnormal transaction event is a submission event that was submitted earlier but processed later in a group of transaction events. Within the same group of transaction events, the user identifier of the query event is the same as the user identifier of the submission event, and the auxiliary identifier of the query event is the same as the transaction identifier of the submission event. Specifically, if the target transaction event is a submission event, and the transaction logs of query events in the same group of transaction events as the target transaction event exist in the historical transaction log set, then server 104 can retrieve the historical transaction log corresponding to the event identifier (i.e., user identifier + transaction identifier) ​​of the target transaction event. The retrieved historical transaction logs are the transaction logs of query events in the same group of transaction events as the target transaction event. For example, submission event 1 is a transfer from user A to user B, then query event 1 in the same group of transaction events as submission event 1 is a query about the transfer of 10,000 yuan from user A to user B. Assuming the user identifier for submitting event 1 is A and the transaction identifier for submitting event 1 is 00, then the user identifier for querying event 1 is A, and the auxiliary identifier for querying event 1 is 00. Since the transaction identifiers for different transaction events are not the same for the same user, the transaction identifier for querying event 1 must not be 00; let's assume the transaction identifier for querying event 1 is 01. Assuming the transaction log for querying event 1 is stored in the historical transaction log set (i.e., querying event 1 is a historical query event), submitting event 1 is the target transaction event, and the keyword format is [user identifier, transaction identifier], then server 104 searches the historical transaction log set based on the keyword [A, 00] corresponding to submitting event 1, obtaining the historical transaction log for querying event 1 corresponding to [A, 00]. Server 104 identifies price increase event 1 as an abnormal transaction event.

[0068] In the above-described method for identifying abnormal transaction events, when the target transaction event is a submission event, the system searches the identifier cache based on the event identifier of the target transaction event. If no corresponding submission event identifier is found, the system searches the historical transaction log set. If a corresponding historical transaction log is found, the target transaction event is identified as an abnormal transaction event. Since the submission event identifier in the identifier cache is used to represent the event identifier of a submission event whose query result is a submission failure, if the target transaction event has a corresponding submission event identifier in the identifier cache, it means that the identifier cache contains a query event that was processed earlier, while the target transaction event is a submission event that was processed later. Therefore, the target transaction event is an abnormal transaction event. Similarly, if the target transaction event is a submission event and there is a corresponding historical transaction log, it means that the historical transaction log set contains a query event that was processed earlier. Therefore, the target transaction event is also an abnormal transaction event. Therefore, this solution can identify whether a target transaction event is an abnormal transaction event, and thus process abnormal transaction events, thereby avoiding transaction result errors caused by abnormal transaction events.

[0069] In one embodiment, after retrieving the identifier from the identifier cache information based on the event identifier of the target transaction event, the method further includes:

[0070] If the submission event identifier corresponding to the event identifier of the target transaction event is found in the identifier cache information, the target transaction event will be identified as an abnormal transaction event.

[0071] In this embodiment of the application, if the server 104 retrieves the submission event identifier corresponding to the time identifier of the target transaction event in the identifier cache information, the server 104 will identify the target transaction event as an abnormal transaction event.

[0072] In this embodiment, the target transaction event is identified as an abnormal transaction event by searching the identifier cache information based on the event identifier of the target transaction event. If the corresponding submission event identifier is found, the target transaction event can be identified as an abnormal transaction event. Therefore, this solution can identify abnormal transaction events.

[0073] In one embodiment, after determining the event category of the target transaction event, the method further includes:

[0074] If the event category of the target transaction event is a query event, then the target transaction event will be identified as a normal transaction event.

[0075] In this embodiment of the application, if the server 104 identifies the event category of the target transaction event as a query event, then the server 104 identifies the target transaction event as a normal transaction event. A normal transaction event is either a submission event that is submitted and processed earlier or a query event that is submitted and processed later in a group of transaction events.

[0076] In this embodiment, the target transaction event is determined to be a normal transaction event (i.e., it is not an abnormal transaction event) by identifying the event category as a query event. Therefore, this solution can identify abnormal transaction events.

[0077] In one embodiment, after retrieving data from the historical transaction log set based on the event identifier of the target transaction event, the method further includes:

[0078] If no historical transaction log corresponding to the event identifier of the target transaction event is found in the historical transaction log set, the target transaction event will be identified as a normal transaction event.

[0079] In this embodiment of the application, if the server 104 does not find the historical transaction log corresponding to the event identifier of the target transaction event in the historical transaction log set, the server 104 will identify the target transaction event as a normal transaction event.

[0080] In this embodiment, the target transaction event is retrieved from the historical transaction log set based on its event identifier. If a corresponding historical transaction log is found, the target transaction event is identified as an abnormal transaction event. Therefore, this solution can identify abnormal transaction events.

[0081] In one embodiment, such as Figure 3 As shown, after determining the event category of the target transaction event, the following is also included:

[0082] Step 302: If the event category of the target transaction event is a query event, then query whether there is a transaction result for the target transaction event.

[0083] In this embodiment, if server 104 identifies the event category of the target transaction event as a query event, then server 104 queries whether the target transaction event has a transaction result. Specifically, if server 104 identifies the event category of the target transaction event as a query event, then the server searches the result transaction log of the target transaction event based on the event identifier of the target transaction event. The result transaction log contains the transaction result.

[0084] Step 304: If there is a transaction result for the target transaction event, then store the transaction log of the target transaction event into the historical transaction log set.

[0085] In this embodiment, if the server retrieves the transaction result of the target transaction event (i.e., the transaction result of the target transaction event exists), the server stores the transaction log of the target transaction event into a historical transaction log set. The transaction log categories include start transaction logs and result transaction logs. Start transaction logs are obtained based on the transaction request of the target transaction event. Result transaction logs are obtained based on the transaction result of the target transaction event. Optionally, the server can store the start transaction log of the target transaction event, the result transaction log of the target transaction event, or both the start and result transaction logs of the target transaction event into the historical transaction log set. In one embodiment, the transaction log includes an event category, an event identifier, and an event timestamp. Optionally, the event timestamp can be the submission timestamp of the target transaction event, or it can be the submission timestamp of the target transaction event combined with an end timestamp. For each historical transaction log in the historical transaction log set, the server 104 obtains the current time and the submission timestamp of the historical transaction log, and calculates the difference between the current time and the submission timestamp to obtain the event duration corresponding to the target transaction event. Server 104 determines the event duration and its relation to a preset first expiration duration. If the event duration exceeds the preset first expiration duration, server 104 deletes the historical transaction logs of the target transaction event corresponding to that event duration. Optionally, the preset first expiration duration can be 2 hours or 3 hours; this application does not limit the preset first expiration duration. This prevents the historical transaction log set from becoming too large.

[0086] In another embodiment, if server 104 identifies the target transaction event as a query event, then server 104 stores the start transaction log of the query event in the historical transaction log set. Then, if server 104 does not find a transaction result for the query event, server 104 deletes the start transaction log of the query event from the historical transaction log set. If server 104 finds a transaction result for the query event, optionally, server 104 may store the result transaction log of the query event in the historical transaction log set; alternatively, server 104 may not store the result transaction log of the query event in the historical transaction log set, or server 104 may store the result transaction log of the query event in the historical transaction log set and delete the start transaction log of the query event from the historical transaction log set.

[0087] In this embodiment, the transaction logs of target transaction events with transaction results are stored in the historical transaction log set, providing a retrieval prerequisite for the identification of abnormal transaction events.

[0088] In one embodiment, when the event category of the target transaction event is a query event, the event identifier includes a user identifier, a transaction identifier, and an auxiliary identifier; the auxiliary identifier is the transaction identifier of the submission event queried by the query event; after determining the event category of the target transaction event, it also includes:

[0089] If the query result for the target transaction event is a submission failure, then the submission event information for the target transaction event is constructed based on the user identifier and auxiliary identifier of the target transaction event, and the submission event information is stored in the identifier cache information.

[0090] In this embodiment, server 104 obtains the event category of the target transaction event. If server 104 identifies the event category of the target transaction event as a query event, then server 104 obtains the query result of the target transaction event. Specifically, when server 104 identifies the event category of the target transaction event as a query event, server 104 obtains the result code of the target transaction event and parses the result code according to the preset correspondence between the result code and the query result to obtain the query result. In one embodiment, the result code is A0012, which represents that the query result is a submission failure, and the reason for the submission failure is that no transaction result for the queried submission event was found. If server 104 identifies the query result of the target transaction event as a submission failure, then server 104 obtains the event identifier of the target transaction event. Then, server 104 uses the user identifier and auxiliary identifier in the event identifier as submission event information and stores the submission event information in the identifier cache information. In one embodiment, when server 104 identifies the query result of the target transaction event as a submission failure, server 104 obtains the event identifier and the submission timestamp of the target transaction event. For each target transaction event whose query result is a submission failure, server 104 calculates the difference between the current time and the submission timestamp to obtain the event duration corresponding to the target transaction event. Server 104 compares the event duration with a preset second expiration duration. If the event duration is greater than the preset second expiration duration, server 104 deletes the submission event information of the target transaction event corresponding to that event duration. Optionally, the preset second expiration duration can be 30 minutes or 40 minutes, and it can be equal to or different from the preset first expiration duration. This application does not limit the preset second expiration duration. This prevents the amount of data in the identifier cache information from becoming too large.

[0091] In this embodiment, the submission event information of the target transaction event whose query result is submission failure is stored in the identifier cache information, which provides a retrieval prerequisite for the identification of abnormal transaction events.

[0092] In one embodiment, the method for identifying abnormal transaction events further includes:

[0093] If the submission event identifier corresponding to the event identifier of the target transaction event is found in the identifier cache information, then the processing of the target transaction event is stopped.

[0094] In this embodiment, if the server 104 finds a submission event identifier corresponding to the event identifier of the target transaction event in the identifier cache information, the server stops further processing of the target transaction event. In one embodiment, if the server 104 finds a submission event identifier corresponding to the event identifier of the target transaction event in the identifier cache information, the server identifies the target transaction event as an abnormal transaction event and stops further processing of the target transaction event.

[0095] In this embodiment, stopping the processing of the target transaction event with the corresponding submission event identifier can be understood as follows: the query event used to query the transaction result of the target transaction event (for ease of distinction, it is called the query event processed earlier) was processed earlier, so the query result of the query event processed earlier is submission failure. Now stopping the processing of the target transaction event can ensure the correctness of the query result of the query event processed earlier.

[0096] In one embodiment, the method for identifying abnormal transaction events further includes:

[0097] If the historical transaction log corresponding to the event identifier of the target transaction event is found in the historical transaction log, an alarm will be triggered.

[0098] In this embodiment, if server 104 retrieves the historical transaction log corresponding to the event identifier of the target transaction event in the historical transaction log, server 104 performs an alarm process. In one embodiment, if server 104 retrieves the historical transaction log corresponding to the event identifier of the target transaction event in the historical transaction log, server 104 identifies the target transaction event as an abnormal transaction event and performs an alarm process. In one embodiment, the alarm process can be implemented by server 104 sending a reminder message to terminal 102. The reminder message indicates that the target transaction event has been processed.

[0099] In this embodiment, if the event identifier of the target transaction event has a corresponding historical transaction log, the server will issue an alarm. Since the target transaction event that proceeds to step 206 is actually processed, the transaction result of the target transaction event is indeed a successful submission. However, the query result of the previously processed query event is a submission failure. Therefore, an alarm can be used to remind the user that the query result of the previously processed query event is incorrect, thereby ensuring that the user receives the correct transaction result of the target transaction event.

[0100] It should be understood that although the steps in the flowcharts of the embodiments described above are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowcharts of the embodiments described above may include multiple steps or multiple stages. These steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the steps or stages of other steps.

[0101] Based on the same inventive concept, this application also provides an abnormal transaction event identification device for implementing the abnormal transaction event identification method described above. The solution provided by this device is similar to the implementation described in the above method; therefore, the specific limitations in one or more abnormal transaction event identification device embodiments provided below can be found in the limitations of the abnormal transaction event identification method described above, and will not be repeated here.

[0102] In one embodiment, such as Figure 4 As shown, an abnormal transaction event identification device is provided, comprising:

[0103] The determination module 402 is used to determine the event category of the target transaction event in response to the target transaction event;

[0104] The first retrieval module 404 is used to retrieve information from the identifier cache based on the event identifier of the target transaction event when the event category of the target transaction event is a submission event. The identifier cache stores the submission event identifier, which is used to represent the event identifier of the submission event that the query result is a submission failure.

[0105] The second retrieval module 406 is used to search the historical transaction log set according to the event identifier of the target transaction event if the submission event identifier corresponding to the event identifier of the target transaction event is not found in the identifier cache information.

[0106] The third retrieval module 408 is used to identify the target transaction event as an abnormal transaction event if the historical transaction log corresponding to the event identifier of the target transaction event is found in the historical transaction log.

[0107] In one embodiment, the device for identifying abnormal transaction events further includes:

[0108] The first identification module is used to identify the target transaction event as an abnormal transaction event if the submission event identifier corresponding to the event identifier of the target transaction event is found in the identifier cache information.

[0109] In one embodiment, the device for identifying abnormal transaction events further includes:

[0110] The second identification module is used to identify the target transaction event as a normal transaction event if the event category of the target transaction event is a query event.

[0111] In one embodiment, the device for identifying abnormal transaction events further includes:

[0112] The third identification module is used to identify the target transaction event as a normal transaction event if no historical transaction log corresponding to the event identifier of the target transaction event is found in the historical transaction log set.

[0113] In one embodiment, the device for identifying abnormal transaction events further includes:

[0114] The query module is used to query whether there are any transaction results for the target transaction event if the event category of the target transaction event is a query event.

[0115] The first construction module is used to store the transaction log of the target transaction event into the historical transaction log set if there is a transaction result for the target transaction event.

[0116] In one embodiment, when the event category of the target transaction event is a query event, the event identifier includes a user identifier, a transaction identifier, and an auxiliary identifier; the auxiliary identifier is the transaction identifier of the submission event queried by the query event; the device for identifying abnormal transaction events further includes:

[0117] The second construction module is used to construct the submission event information of the target transaction event based on the user identifier and auxiliary identifier of the target transaction event if the query result of the target transaction event is submission failure, and to store the submission event information in the identifier cache information.

[0118] In one embodiment, the device for identifying abnormal transaction events further includes:

[0119] The stop module is used to stop processing the target transaction event if the submission event identifier corresponding to the event identifier of the target transaction event is found in the identifier cache information.

[0120] In one embodiment, the device for identifying abnormal transaction events further includes:

[0121] The alarm module is used to trigger an alarm if the historical transaction log corresponding to the event identifier of the target transaction event is found in the historical transaction log.

[0122] Each module in the aforementioned abnormal transaction event identification device can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in or independent of the processor in a computer device, or stored in the memory of a computer device as software, so that the processor can call and execute the corresponding operations of each module.

[0123] In one embodiment, a computer device is provided, which may be a server, and its internal structure diagram may be as follows: Figure 5 As shown, the computer device includes a processor, memory, and a network interface connected via a system bus. The processor provides computing and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system, computer programs, and a database. The internal memory provides an environment for the operation of the operating system and computer programs in the non-volatile storage media. The database stores target transaction event data. The network interface communicates with external terminals via a network connection. When executed by the processor, the computer program implements a method for identifying abnormal transaction events.

[0124] Those skilled in the art will understand that Figure 5 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device to which the present application is applied. Specific computer devices may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0125] In one embodiment, a computer device is also provided, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps in the above-described method embodiments.

[0126] In one embodiment, a computer-readable storage medium is provided having a computer program stored thereon that, when executed by a processor, implements the steps in the above method embodiments.

[0127] In one embodiment, a computer program product is provided, including a computer program that, when executed by a processor, implements the steps in the above method embodiments.

[0128] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties.

[0129] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. Any references to memory, databases, or other media used in the embodiments provided in this application can include at least one of non-volatile and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. By way of illustration and not limitation, RAM can take many forms, such as Static Random Access Memory (SRAM) or Dynamic Random Access Memory (DRAM). The databases involved in the embodiments provided in this application may include at least one type of relational database and non-relational database. Non-relational databases may include, but are not limited to, blockchain-based distributed databases. The processors involved in the embodiments provided in this application may be general-purpose processors, central processing units, graphics processing units, digital signal processors, programmable logic devices, quantum computing-based data processing logic devices, etc., and are not limited to these.

[0130] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0131] The embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are specific and detailed, they should not be construed as limiting the scope of this patent application. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this application should be determined by the appended claims.

Claims

1. A method for identifying abnormal transaction events, characterized in that, The method includes: In response to a target transaction event, determine the event category of the target transaction event; If the event category of the target transaction event is a submission event, a search is performed in the identifier cache information based on the event identifier of the target transaction event; the identifier cache information stores submission event identifiers, which are used to characterize the event identifiers of submission events whose query result is a submission failure; if the submission event identifier corresponding to the event identifier of the target transaction event is not found in the identifier cache information, a search is performed in the historical transaction log set based on the event identifier of the target transaction event. If the historical transaction log corresponding to the event identifier of the target transaction event is found in the historical transaction log set, the target transaction event is identified as an abnormal transaction event; the historical transaction log is the transaction log of the query event of the target transaction event in the same group of transaction events; the abnormal transaction event is a submission event that was submitted earlier but processed later in a group of transaction events.

2. The method according to claim 1, characterized in that, After retrieving the identifier from the identifier cache information based on the event identifier of the target transaction event, the method further includes: If the submission event identifier corresponding to the event identifier of the target transaction event is found in the identifier cache information, then the target transaction event is identified as an abnormal transaction event.

3. The method according to claim 1, characterized in that, After determining the event category of the target transaction event, the process also includes: If the event category of the target transaction event is a query event, then the target transaction event will be identified as a normal transaction event.

4. The method according to claim 1, characterized in that, After retrieving the target transaction event from the historical transaction log set based on the event identifier, the process further includes: If no historical transaction log corresponding to the event identifier of the target transaction event is found in the historical transaction log set, the target transaction event is identified as a normal transaction event.

5. The method according to any one of claims 1 to 4, characterized in that, After determining the event category of the target transaction event, the process also includes: If the event category of the target transaction event is a query event, then query whether there is a transaction result for the target transaction event; If a transaction result exists for the target transaction event, the transaction log of the target transaction event is stored in the historical transaction log set.

6. The method according to any one of claims 1 to 4, characterized in that, When the event category of the target transaction event is a query event, the event identifier includes a user identifier, a transaction identifier, and an auxiliary identifier; The auxiliary identifier is the transaction identifier of the submission event queried by the query event; After determining the event category of the target transaction event, the process also includes: If the query result of the target transaction event is a submission failure, then the submission event information of the target transaction event is constructed based on the user identifier and the auxiliary identifier of the target transaction event, and the submission event information is stored in the identifier cache information.

7. The method according to claim 2, characterized in that, The method further includes: If the submission event identifier corresponding to the event identifier of the target transaction event is found in the identifier cache information, then the processing of the target transaction event is stopped.

8. The method according to claim 1, characterized in that, The method further includes: If the historical transaction log corresponding to the event identifier of the target transaction event is found in the historical transaction log, an alarm will be triggered.

9. A device for identifying abnormal transaction events, characterized in that, The device includes: A determination module is used to determine the event category of a target transaction event in response to the target transaction event; The first retrieval module is used to retrieve information from the identifier cache based on the event identifier of the target transaction event when the event category of the target transaction event is a submission event; the identifier cache stores submission event identifiers, which are used to characterize the event identifiers of submission events whose query results are submission failures. The second retrieval module is used to search in the historical transaction log set according to the event identifier of the target transaction event if the submission event identifier corresponding to the event identifier of the target transaction event is not found in the identifier cache information. The third retrieval module is used to identify the target transaction event as an abnormal transaction event if the historical transaction log corresponding to the event identifier of the target transaction event is found in the historical transaction log; the historical transaction log is the transaction log of the query event of the target transaction event in the same group of transaction events; the abnormal transaction event is a submission event that was submitted earlier but processed later in a group of transaction events.

10. A computer device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that, When the processor executes the computer program, it implements the steps of the method according to any one of claims 1 to 8.

Images