CN115293908A - Abnormal transaction event identification method and device, computer equipment and storage medium - Google Patents

Abnormal transaction event identification method and device, computer equipment and storage medium Download PDF

Info

Publication number
CN115293908A
CN115293908A CN202211010270.1A CN202211010270A CN115293908A CN 115293908 A CN115293908 A CN 115293908A CN 202211010270 A CN202211010270 A CN 202211010270A CN 115293908 A CN115293908 A CN 115293908A
Authority
CN
China
Prior art keywords
event
transaction
identifier
target transaction
target
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
Application number
CN202211010270.1A
Other languages
Chinese (zh)
Inventor
沈聪
杨旭
嵇海锋
胡天皓
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Industrial and Commercial Bank of China Ltd ICBC
Original Assignee
Industrial and Commercial Bank of China Ltd ICBC
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Industrial and Commercial Bank of China Ltd ICBC filed Critical Industrial and Commercial Bank of China Ltd ICBC
Priority to CN202211010270.1A priority Critical patent/CN115293908A/en
Publication of CN115293908A publication Critical patent/CN115293908A/en
Pending legal-status Critical Current

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

Abstract

The application relates to a method and a device for identifying abnormal transaction events, computer equipment, a storage medium and a computer program product, and relates to the technical field of artificial intelligence. The method comprises the following steps: in response to the target transaction event, determining an event category of the target transaction event; under the condition that the event category of the target transaction event is a submission event, retrieving in the identification cache information according to the event identification of the target transaction event; if the submitted event identifier corresponding to the event identifier of the target transaction event is not retrieved in the identifier cache information, retrieving in a historical transaction log set according to the event identifier of the target transaction event; and if the historical transaction log corresponding to the event identifier of the target transaction event is retrieved from the historical transaction log set, identifying the target transaction event as an abnormal transaction event. The scheme can identify abnormal transaction events.

Description

Abnormal transaction event identification method and device, computer equipment and storage medium
Technical Field
The present application relates to the field of artificial intelligence technology, and in particular, to an abnormal transaction event method, apparatus, computer device, storage medium, and computer program product.
Background
Currently, in a resource transaction service, a user usually determines whether to perform a next transaction event again based on a transaction result of a last transaction event. In the course of a user transacting a transaction, it may occur that a subsequently submitted transaction event is processed before a previously submitted transaction event (i.e., out of order). If the transaction outcome of a subsequently submitted transaction event that occurs out of order is determined based on the processing of a previously submitted transaction event, then the subsequently submitted transaction event is an anomalous transaction event.
For example, a set of paired transaction event groups includes a submit transaction event and a query transaction event, where the query transaction event is a processing case for a query submit transaction event. However, in the transaction process of the transaction service, if a problem occurs in the network transmission, such as network delay or network transmission abnormality, a situation may occur in which a subsequently submitted query transaction event is processed before a previously submitted query transaction event (i.e., disorder), and thus the query result of the subsequently submitted query transaction event is incorrect.
However, the current transaction service technology cannot identify an abnormal transaction event, so that the transaction service processing personnel or the transaction service system cannot perform early warning or control on the abnormal transaction event, and therefore, an identification method for the abnormal transaction event is needed.
Disclosure of Invention
In view of the above, it is necessary to provide an abnormal transaction event identification method, an abnormal transaction event identification device, a computer readable storage medium and a computer program product, which can identify an abnormal transaction event.
In a first aspect, the present application provides a method for identifying an abnormal transaction event. The method comprises the following steps:
in response to a target transaction event, determining an event category of the target transaction event;
under the condition that the event category of the target transaction event is a submission event, retrieving in identification cache information according to the event identification of the target transaction event; a submission event identifier is stored in the identifier cache information and is used for representing an event identifier of a submission event with a query result of submission failure;
if the submitted event identifier corresponding to the event identifier of the target transaction event is not retrieved in the identifier cache information, retrieving in a historical transaction log set according to the event identifier of the target transaction event;
and if the historical transaction log corresponding to the event identifier of the target transaction event is retrieved from the historical transaction log set, identifying the target transaction event as an abnormal transaction event.
In one embodiment, after the retrieving in the identification cache information according to the event identification of the target transaction event, the method further includes:
and if a submission event identifier corresponding to the event identifier of the target transaction event is retrieved from the identifier cache information, identifying the target transaction event as an abnormal transaction event.
In one embodiment, after determining the event category of the target transaction event, the method further includes:
if the event type of the target transaction event is a query event, identifying the target transaction event as a normal transaction event.
In one embodiment, after the retrieving in the historical transaction log set according to the event identifier of the target transaction event, the method further includes:
and if the historical transaction log corresponding to the event identifier of the target transaction event is not retrieved in the historical transaction log set, identifying the target transaction event as a normal transaction event.
In one embodiment, after determining the event category of the target transaction event, the method further includes:
if the event type of the target transaction event is an inquiry event, inquiring whether a transaction result of the target transaction event exists or not;
and if the transaction result of the target transaction event exists, storing the transaction log of the target transaction event into the historical transaction log set.
In one embodiment, in the case that 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 a transaction identifier of a submission event queried by the query event; after the determining the event category of the target transaction event, the method further includes:
if the query result of the target transaction event is submission failure, the submission event information of the target transaction event is constructed according to the user identifier and the auxiliary identifier of the target transaction event, and the submission event information is stored in the identifier cache information.
In one embodiment, the method for identifying an abnormal transaction event further includes:
and if the submitting event identifier corresponding to the event identifier of the target transaction event is retrieved from the identifier cache information, stopping the processing of the target transaction event.
In one embodiment, the method for identifying an abnormal transaction event further comprises:
and if the historical transaction log corresponding to the event identifier of the target transaction event is retrieved from the historical transaction log, performing alarm processing.
In a second aspect, the application further provides a device for identifying an abnormal transaction event. The device comprises:
a determining module, configured to determine an event category of a target transaction event in response to the target transaction event;
the first retrieval module is used for retrieving in the identification cache information according to the event identification of the target transaction event under the condition that the event category of the target transaction event is a submission event; a submission event identifier is stored in the identifier cache information, and the submission event identifier is used for representing the query result as an event identifier of a submission event which fails to submit;
the second retrieval module is used for retrieving in a historical transaction log set according to the event identifier of the target transaction event if the submitted event identifier corresponding to the event identifier of the target transaction event is not retrieved in the identifier cache information;
and the third retrieval module is used for identifying 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 retrieved from the historical transaction log.
In one embodiment, the device for identifying an abnormal transaction event further comprises:
and the first identification module is used for identifying 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 retrieved from the identifier cache information.
In one embodiment, the device for identifying an abnormal transaction event further comprises:
and the second identification module is used for identifying the target transaction event as a normal transaction event if the event type of the target transaction event is the query event.
In one embodiment, the device for identifying an abnormal transaction event further comprises:
and the third identification module is used for identifying the target transaction event as a normal transaction event if the historical transaction log corresponding to the event identifier of the target transaction event is not retrieved in the historical transaction log set.
In one embodiment, the device for identifying an abnormal transaction event further comprises:
the query module is used for querying whether a transaction result of the target transaction event exists or not if the event type of the target transaction event is the query event;
and the first construction module is used for storing the transaction log of the target transaction event into the historical transaction log set if the transaction result of the target transaction event exists.
In one embodiment, in the case that 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 a transaction identifier of a submission event queried by the query event; the device for identifying the abnormal transaction event further comprises:
and the second construction module is used for constructing submission event information of the target transaction event according to the user identifier and the auxiliary identifier of the target transaction event and storing the submission event information to the identifier cache information if the query result of the target transaction event is submission failure.
In one embodiment, the device for identifying an abnormal transaction event further comprises:
and the stopping module is used for stopping processing the target transaction event if the submitting event identifier corresponding to the event identifier of the target transaction event is retrieved from the identifier cache information.
In one embodiment, the device for identifying an abnormal transaction event further comprises:
and the alarm module is used for carrying out alarm processing if the historical transaction log corresponding to the event identifier of the target transaction event is retrieved from the historical transaction log.
In a third aspect, the present application also provides a computer device. The computer device comprises a memory storing a computer program and a processor implementing the steps of the first aspect when executing the computer program.
In a fourth aspect, the present application further provides a computer-readable storage medium. The computer readable storage medium having stored thereon a computer program which, when executed by a processor, performs the steps recited in the first aspect.
In a fifth aspect, the present application further provides a computer program product. The computer program product comprising a computer program that when executed by a processor performs the steps of the first aspect.
According to the abnormal transaction event monitoring method, the abnormal transaction event monitoring device, the computer equipment, the storage medium and the computer program product, under the condition that the event type of the target transaction event is a submission event, retrieval is carried out in the identification cache information based on the event identification of the target transaction event, if the corresponding submission event identification is not retrieved, retrieval is carried out in the historical transaction log set, and if the corresponding historical transaction log is retrieved, the target transaction event is identified as the abnormal transaction event. It can be understood that, since the submission event identifier in the identification cache information is used to represent the submission event whose query result is failed to submit, if the target transaction event has a corresponding submission event identifier in the identification cache information, it indicates that there is a query event processed before in the identification cache information, and the target transaction event is a submission event processed after, so that the target transaction event at this time is an abnormal transaction event. Similarly, when the target transaction event is a commit event, if the target transaction event has a corresponding historical transaction log, it indicates that the previously processed query event is stored in the historical transaction log set, so the target transaction event at this time is an abnormal transaction event. Therefore, the scheme can identify whether the target transaction event is an abnormal transaction event, and further can enable a transaction service processing personnel or a transaction service system to determine whether the current target transaction event is the abnormal transaction event.
Drawings
FIG. 1 is a diagram of an exemplary implementation of a method for identifying anomalous transaction events;
FIG. 2 is a flow diagram illustrating a method for identifying anomalous transaction events in one embodiment;
FIG. 3 is a flow diagram that illustrates a methodology for building a historical transaction log collection, under an embodiment;
FIG. 4 is a block diagram of an abnormal transaction event recognition apparatus according to an embodiment;
FIG. 5 is a diagram illustrating an internal structure of a computer device according to an embodiment.
Detailed Description
In order to make the objects, technical solutions and advantages of the present application more clearly understood, the present application is further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative of the present application and are not intended to limit the present application.
The method for identifying the abnormal transaction event provided by the embodiment of the application can be applied to the application environment shown in fig. 1. Wherein the terminal 102 communicates with the server 104 via a network. The data storage system may store data that the server 104 needs to process. The data storage system may be integrated on the server 104, or may be deployed on a cloud or other network server. The server 104 includes a transaction analysis system and an abnormal transaction event recognition system, and the transaction analysis system and the abnormal transaction event recognition system are connected through communication. In one embodiment, a message queue is included in a data storage system. The message queue may be kafka, or may be a rocktmq, or may be a rabbitMQ. The transaction service analysis system is in communication connection with the message queue, and the message queue is in communication connection with the abnormal transaction event identification system. The anomalous transaction event recognition system includes identification cache information, and a set of historical transaction logs. The terminal 102 may be, but not limited to, various personal computers, notebook computers, smart phones, tablet computers, internet of things devices and portable wearable devices, and the internet of things devices may be smart speakers, smart televisions, smart air conditioners, smart car-mounted devices, and the like. The portable wearable device can be a smart watch, a smart bracelet, a head-mounted device, and the like. The server 104 may be implemented as a stand-alone server or as a server cluster comprised of multiple servers. The transaction service analysis system and the abnormal transaction event recognition system can be arranged in the same independent server or respectively arranged in different independent servers. The server may also include a transaction processing system; the transaction service processing system is used for processing the target transaction event and generating a transaction result of the target transaction event.
The terminal 102 initiates a transaction request for a target transaction event, which is sent to the server 104 over the network. The transaction service analysis system receives and analyzes the transaction request of the target transaction event to obtain event data of the target transaction event. The event data comprises an event category and an event identifier. And under the condition that the event category of the target transaction event is the submission event, the transaction service analysis system sends the event data of the target transaction event to the abnormal transaction event identification system. And the abnormal transaction event recognition system takes the event identifier of the target transaction event as a keyword, and searches in the identifier cache information according to the keyword. And if the abnormal transaction event identification system does not retrieve the submitted event identifier corresponding to the event identifier of the target transaction event in the identifier cache information, retrieving in the historical transaction log set according to the keyword. And if the abnormal transaction event identification system searches the historical transaction log corresponding to the event identifier of the target transaction event in the historical transaction log set, identifying the target transaction event as the abnormal transaction event. And the abnormal transaction event identification system sends the identification result that the target transaction event is the abnormal transaction event to the transaction service analysis system. And when the transaction service analysis system receives the identification result that the target transaction event is the abnormal transaction event, the transaction service analysis system carries out alarm processing. In one embodiment, the alarm may be processed by the transaction service analysis system sending an alert message to the terminal 102. Wherein the reminder message is used to characterize that the target transaction event has been processed.
In one embodiment, as shown in fig. 2, a method for identifying an abnormal transaction event is provided, which is described by taking the method as an example applied to the server 104 in fig. 1, and includes the following steps:
in response to the target transaction event, an event category of the target transaction event is determined, step 202.
In the embodiment of the present application, the server 104 receives and analyzes the transaction request of the target transaction event sent by the terminal 102, so as to obtain event data of the target transaction event. The event data comprises an event category and an event identifier. The event categories of the target transaction event include a submission event, and a query event. A commit event is a transaction event involving a change in funds of a user. A query event is a transaction event that queries for the handling of a submission event. The server 104 determines the event type of the target transaction event according to the event data of the target transaction event.
And step 204, under the condition that the event category of the target transaction event is a submission event, retrieving in the identification cache information according to the event identification of the target transaction event.
Wherein the event identification is used to distinguish between different target transaction events. The event identification of the submitted event comprises a user identification and a transaction identification; the event identification of the query event comprises a user identification, a transaction identification and an auxiliary identification; the mark cache information stores a submission event mark which is used for representing the submission event that the query result is failed to submit.
In this embodiment of the application, when the server 104 determines that the event category of the target transaction event is a commit event, the server 104 searches the identifier cache information by using the event identifier as a key. Wherein the submission event is a transaction event involving a change in funds of the user. Alternatively, the commit event may be a transaction event that commits a transfer, or a transaction event that commits a purchase financing. It will be appreciated that a user corresponds to a user identifier and a transaction event corresponds to a transaction identifier. The transaction identifications for different target transaction events are not the same for the same user. The group of transaction event groups comprise query events and submission events, wherein the query events are used for querying the processing conditions of the submission events in the group of transaction event groups; the processing of the commit event includes the transaction result, as well as the transaction data. In particular, a commit event is a transaction event involving a change in funds of a user. A query event is a transaction event that queries for the processing of a submission event. In the same transaction event group, if the transaction result of the submitted event is processed when the query event is processed, the query result of the query event is successful in submission; in the same group of transaction event groups, if the transaction result of the submitting event is unprocessed while the query event is processed, the query result of the query event is a submission failure. The submitting event identification is obtained for the event identification of the query event with failed submission based on the query result. Specifically, the submission event identifier includes a user identifier and an auxiliary identifier of the query event of which the query result is that submission fails. In the same transaction event group, the user identifier of the query event is the same as the user identifier of the submitted event, and the auxiliary identifier of the query event is the same as the transaction identifier of the submitted event, so the submitted event identifier of the query event is equal to the event identifier of the submitted event in the same transaction event group with the query event.
And step 206, if the submitted event identifier corresponding to the event identifier of the target transaction event is not retrieved from the identifier cache information, retrieving in the historical transaction log set according to the event identifier of the target transaction event.
In this embodiment of the application, if the server 104 does not retrieve the submitted event identifier corresponding to the event identifier of the target transaction event in the identifier cache information, the server 104 retrieves from the historical transaction log set according to the keyword obtained in step 204. Wherein the historical transaction log collection includes historical transaction logs of historical transaction events. The historical transaction events are historical transaction events that have been processed by the server 104 and have a processing result. In one embodiment, the historical transaction events are historical query events. In another embodiment, the event types of historical transaction events include historical query events, and historical commit events. The historical transaction log includes event data for historical transaction events. The event data includes an event category, and an event identification.
And step 208, if a historical transaction log corresponding to the event identifier of the target transaction event is retrieved from the historical transaction log set, identifying the target transaction event as an abnormal transaction event.
In this embodiment of the application, if the server 104 retrieves the historical transaction log corresponding to the event identifier of the target transaction event from the historical transaction log set, the server 104 identifies the target transaction event as an abnormal transaction event. Wherein an exception transaction event is a commit event that was committed first but was processed later in a set of transaction event groups. In the same group of transaction event groups, the user identification of the query event is the same as the user identification of the submitted event, and the auxiliary identification of the query event is the same as the transaction identification of the submitted event. Specifically, if the target transaction event is a commit event and the transaction logs of the query events in the same transaction event group as the target transaction event exist in the historical transaction log set, the server 104 may retrieve the historical transaction log corresponding to the event identifier (i.e., the user identifier + the transaction identifier) of the target transaction event, where the retrieved historical transaction log is the transaction log of the query events in the same transaction event group as the target transaction event. For example, submission event 1 is a transfer from user a to user B, and query event 1 in the same transaction event group as submission event 1 is a transfer from user a to user B for 1 ten thousand dollars. Assuming that the user identifier submitting the event 1 is a and the transaction identifier submitting the event 1 is 00, the user identifier querying the event 1 is a and the auxiliary identifier querying the event 1 is 00. Since the transaction id of different transaction events are different for the same user, the transaction id of query event 1 is not necessarily 00, and it is assumed that the transaction id of query event 1 is 01. Assuming that the transaction log of the query event 1 is stored in the historical transaction log set (i.e. the query event 1 is a historical query event), the submission event 1 is a target transaction event, and the format of the keyword is [ user identifier, transaction identifier ], the server 104 performs retrieval in the historical transaction log set according to the keyword [ a,00] corresponding to the submission event 1 to obtain the historical transaction log of the query event 1 corresponding to [ a,00 ]. Server 104 identifies the bid event 1 as an anomalous transaction event.
In the above method for identifying an abnormal transaction event, in the above scheme, when the event type of the target transaction event is a commit event, the retrieval is performed in the identifier cache information based on the event identifier of the target transaction event, if the corresponding commit event identifier is not retrieved, the retrieval is performed in the historical transaction log set, and if the corresponding historical transaction log is retrieved, the target transaction event is identified as an abnormal transaction event. Because the submission event identifier in the identification cache information is used for representing the submission event of which the query result is failed to submit, if the target transaction event has a corresponding submission event identifier in the identification cache information, it indicates that the identification cache information contains a query event which is processed first, and the target transaction event is a submission event which is processed later, so that the target transaction event at this time is an abnormal transaction event. Similarly, when the target transaction event is a commit event, if the target transaction event has a corresponding historical transaction log, it indicates that the previously processed query event is stored in the historical transaction log set, so the target transaction event at this time is an abnormal transaction event. Therefore, the scheme can identify whether the target transaction event is an abnormal transaction event or not, and further can process the abnormal transaction event, so that the transaction result error caused by the abnormal transaction event is avoided.
In one embodiment, after retrieving in the identification cache information according to the event identification of the target transaction event, the method further comprises:
and if the submitting event identifier corresponding to the event identifier of the target transaction event is retrieved from the identifier cache information, identifying the target transaction event as an abnormal transaction event.
In this embodiment of the application, if the server 104 retrieves the submitted event identifier corresponding to the time identifier of the target transaction event from the identifier cache information, the server 104 identifies the target transaction event as an abnormal transaction event.
In this embodiment, the retrieval is performed in the identifier cache information based on the event identifier of the target transaction event, and if the retrieval obtains the corresponding submitted event identifier, the target transaction event is identified as an abnormal transaction event. Therefore, the scheme can identify the abnormal transaction event.
In one embodiment, after determining the event category of the target transaction event, the method further comprises:
and if the event type of the target transaction event is the query event, identifying the target transaction event as a normal transaction event.
In this embodiment of the application, if the server 104 identifies that the event type of the target transaction event is the query event, the server 104 identifies the target transaction event as a normal transaction event. A normal transaction event is a commit event that is submitted first and processed first, or a query event that is submitted later and processed later, in a set of transaction event groups.
In this embodiment, it is determined that the target transaction event is not an abnormal transaction event (i.e., the target transaction event is a normal transaction event) by that the event category of the target transaction event is the query event. Therefore, the scheme can identify the abnormal transaction event.
In one embodiment, after the retrieving in the historical transaction log set according to the event identifier of the target transaction event, the method further includes:
and if the historical transaction log corresponding to the event identifier of the target transaction event is not retrieved in the historical transaction log set, identifying the target transaction event as a normal transaction event.
In this embodiment of the application, if the server 104 does not retrieve the historical transaction log corresponding to the event identifier of the target transaction event in the historical transaction log set, the server 104 identifies the target transaction event as a normal transaction event.
In this embodiment, the event identifier based on the target transaction event is retrieved from the historical transaction log set, and if the corresponding historical transaction log is obtained through retrieval, the target transaction event is identified as an abnormal transaction event. Therefore, the scheme can identify the abnormal transaction event.
In one embodiment, as shown in fig. 3, after determining the event category of the target transaction event, the method further includes:
step 302, if the event type of the target transaction event is the query event, whether a transaction result of the target transaction event exists is queried.
In this embodiment, if the server 104 identifies that the event type of the target transaction event is the query event, the server 104 queries whether a transaction result exists in the target transaction event. Specifically, if the server 104 identifies that the event type of the target transaction event is the query event, the server searches the result transaction log of the target transaction event according to the event identifier of the target transaction event. Wherein the result transaction log comprises transaction results.
Step 304, if the transaction result of the target transaction event exists, the transaction log of the target transaction event is stored in the historical transaction log set.
In the embodiment of the application, if the server queries to obtain the transaction result of the target transaction event (namely, the transaction result of the target transaction event exists), the server stores the transaction log of the target transaction event into the historical transaction log set. The category of the transaction log comprises a starting transaction log and a result transaction log. The start transaction log is a transaction log derived based on transaction requests for the target transaction event. The result transaction log is a transaction log derived based on transaction results for the target transaction event. Optionally, the server may store the start transaction log of the target transaction event into the historical transaction log set, may also store the result transaction log of the target transaction event into the historical transaction log set, and may also store the start transaction log and the result transaction log of the target transaction event into the historical transaction log set. In one embodiment, the transaction log includes an event category, an event identification, and an event timestamp. Optionally, the event timestamp may be a commit timestamp of the target transaction event, and 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. The server 104 determines the event duration and the preset first expiration duration, and if the event duration is greater than the preset first expiration duration, the server 104 deletes the historical transaction log of the target transaction event corresponding to the event duration. Optionally, the preset first failure time period may be 2 hours or 3 hours, and the preset first failure time period is not limited in this application. In this way, the data volume of the historical transaction log collection can be prevented from being too large.
In another embodiment, if the server 104 identifies the event category of the target transaction event as a query event, the server 104 stores a start transaction log of the query event into a set of historical transaction logs. Then, in the case that the server 104 does not query the transaction result of the query event, the server 104 deletes the initial transaction log of the query event in the historical transaction log set. In the case that the server 104 inquires the transaction result of the query event, optionally, the server 104 may store the result transaction log of the query event into the historical transaction log set, the server 104 may not store the result transaction log of the query event into the historical transaction log set, and the server 104 may also store the result transaction log of the query event into the historical transaction log set and delete the start transaction log of the query event in the historical transaction log set.
In this embodiment, the transaction log of the target transaction event with the transaction result is stored in the historical transaction log set, so as to provide a search precondition for identifying the abnormal transaction event.
In one embodiment, in the case that the event category of the target transaction event is a query event, the event identification includes a user identification, a transaction identification, and an auxiliary identification; the auxiliary identification is a transaction identification of a submitted event queried by the query event; after the event category of the target transaction event is determined, the method further comprises the following steps:
if the query result of the target transaction event is submission failure, the submission event information of the target transaction event is constructed according to the user identifier and the auxiliary identifier of the target transaction event, and the submission event information is stored in the identifier cache information.
In this embodiment of the application, the server 104 obtains the event type of the target transaction event, and if the server 104 identifies the event type of the target transaction event as the query event, the server 104 obtains the query result of the target transaction event. Specifically, under the condition that the server 104 identifies the event type of the target transaction event as the query event, the server 104 obtains a result code of the target transaction event, and analyzes the result code according to a preset corresponding relationship between the result code and the query result to obtain the query result. In one embodiment, the result code is A0012, A0012 represents that the query result is a submission failure, and the reason for the submission failure is that the transaction result for the queried submission event was not found. If the server 104 recognizes that the query result of the target transaction event is a failure to submit, the server 104 obtains an event identifier of the target transaction event. Then, the server 104 takes the user identifier and the auxiliary identifier in the event identifier as the submitted event information, and stores the submitted event information in the identifier cache information. In one embodiment, in the event that the server 104 identifies the query result of the target transaction event as a failure to submit, the server 104 obtains an event identification of the target transaction event, and a submission timestamp. For each target transaction event with the query result of failed submission, the server 104 calculates the difference between the current time and the submission timestamp to obtain the event duration corresponding to the target transaction event. The server 104 determines the event duration and the preset second expiration duration, and when the event duration is greater than the preset second expiration duration, the server 104 deletes the submitted event information of the target transaction event corresponding to the event duration. Optionally, the preset second failure duration may be 30 minutes or 40 minutes, the preset second failure duration may be equal to the preset first failure duration, or may not be equal to the preset first failure duration, and the preset second failure duration is not limited in the present application. In this way, the data amount in the identification cache information can be prevented from being excessively large.
In this embodiment, the submission event information of the target transaction event of which the submission result is failed is stored in the identification cache information, so that a retrieval premise is provided for identifying the abnormal transaction event.
In one embodiment, the method for identifying an abnormal transaction event further comprises:
and if the submitting event identifier corresponding to the event identifier of the target transaction event is retrieved from the identifier cache information, stopping processing the target transaction event.
In this embodiment, if the server 104 retrieves the submitted event identifier corresponding to the event identifier of the target transaction event from the identifier cache information, the server stops performing subsequent processing on the target transaction event. In one embodiment, if the server 104 retrieves the submission event identifier corresponding to the event identifier of the target transaction event from the identifier cache information, the server identifies the target transaction event as an abnormal transaction event and stops subsequent processing of the target transaction event.
In this embodiment, the processing of the target transaction event having the corresponding submitting event identifier is stopped, and it can be understood that, since the query event (for convenience of distinction, referred to as a previously processed query event) for querying the transaction result of the target transaction event is processed first, the query result of the previously processed query event is a submission failure, and the processing of the target transaction event is stopped now, so that the accuracy of the query result of the previously processed query event can be ensured.
In one embodiment, the method for identifying an abnormal transaction event further comprises:
and if the historical transaction log corresponding to the event identifier of the target transaction event is searched in the historical transaction log, performing alarm processing.
In this embodiment, if the server 104 retrieves the historical transaction log corresponding to the event identifier of the target transaction event from the historical transaction log, the server 104 performs an alarm process. In one embodiment, if the server 104 retrieves the historical transaction log corresponding to the event identifier of the target transaction event from the historical transaction log, the server 104 identifies the target transaction event as an abnormal transaction event and performs alarm processing. In one embodiment, the alarm may be handled by the server 104 sending an alert message to the terminal 102. Wherein the reminder message is used to characterize that the target transaction event has been processed.
In this embodiment, if the event identifier of the target transaction event has a corresponding historical transaction log, the server performs alarm processing. Since the target transaction event entered in step 206 is actually processed, the transaction result of the target transaction event is actually a successful submission, but the query result of the query event processed previously is a failed submission, so that the user can be reminded of the error query result of the query event processed previously through alarm processing, thereby ensuring that the user knows the correct transaction result of the target transaction event.
It should be understood that, although the steps in the flowcharts related to the embodiments as described above are sequentially displayed as indicated by arrows, the steps are not necessarily performed sequentially as indicated by the arrows. The steps are not performed in the exact order shown and described, and may be performed in other orders, unless explicitly stated otherwise. Moreover, at least a part of the steps in the flowcharts related to the embodiments described above may include multiple steps or multiple stages, which are not necessarily performed at the same time, but may be performed at different times, and the execution order of the steps or stages is not necessarily sequential, but may be rotated or alternated with other steps or at least a part of the steps or stages in other steps.
Based on the same inventive concept, the embodiment of the present application further provides an abnormal transaction event identification device for implementing the above-mentioned abnormal transaction event identification method. The implementation scheme for solving the problem provided by the device is similar to the implementation scheme recorded in the method, so that specific limitations in the embodiment of the device for identifying one or more abnormal transaction events provided below can be referred to the limitations on the method for identifying abnormal transaction events, and details are not described herein again.
In one embodiment, as shown in fig. 4, there is provided an abnormal transaction event recognition apparatus, including:
a determining module 402 for determining an event category of a target transaction event in response to the target transaction event;
a first retrieving module 404, configured to, when the event category of the target transaction event is a commit event, retrieve from the identifier cache information according to the event identifier of the target transaction event; the identification cache information stores a submission event identification which is used for representing the query result as the event identification of the submission event which fails to submit;
a second retrieving module 406, configured to, if a submitted event identifier corresponding to the event identifier of the target transaction event is not retrieved from the identifier cache information, retrieve in the historical transaction log set according to the event identifier of the target transaction event;
the third retrieving module 408 is configured to, if a historical transaction log corresponding to the event identifier of the target transaction event is retrieved from the historical transaction log, identify the target transaction event as an abnormal transaction event.
In one embodiment, the apparatus for identifying an abnormal transaction event further comprises:
and the first identification module is used for identifying 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 retrieved from the identifier cache information.
In one embodiment, the apparatus for identifying an abnormal transaction event further comprises:
and the second identification module is used for identifying the target transaction event as a normal transaction event if the event type of the target transaction event is the query event.
In one embodiment, the apparatus for identifying an abnormal transaction event further comprises:
and the third identification module is used for identifying the target transaction event as a normal transaction event if the historical transaction log corresponding to the event identifier of the target transaction event is not retrieved from the historical transaction log set.
In one embodiment, the apparatus for identifying an abnormal transaction event further comprises:
the query module is used for querying whether a transaction result of the target transaction event exists or not if the event type of the target transaction event is a query event;
and the first construction module is used for storing the transaction log of the target transaction event into a historical transaction log set if the transaction result of the target transaction event exists.
In one embodiment, in the case that the event category of the target transaction event is a query event, the event identification includes a user identification, a transaction identification, and an auxiliary identification; the auxiliary identification is a transaction identification of a submitted event queried by the query event; the device for identifying the abnormal transaction event further comprises:
and the second construction module is used for constructing the submission event information of the target transaction event according to the user identifier and the auxiliary identifier of the target transaction event and storing the submission event information to the identifier cache information if the query result of the target transaction event is that the submission fails.
In one embodiment, the apparatus for identifying an abnormal transaction event further comprises:
and the stopping module is used for stopping the processing of the target transaction event if the submitting event identifier corresponding to the event identifier of the target transaction event is retrieved from the identifier cache information.
In one embodiment, the apparatus for identifying an abnormal transaction event further comprises:
and the alarm module is used for carrying out alarm processing if the historical transaction log corresponding to the event identifier of the target transaction event is retrieved from the historical transaction log.
The modules in the above-mentioned abnormal transaction event identification device can be implemented wholly or partially by software, hardware and their combination. The modules can be embedded in a hardware form or independent of a processor in the computer device, and can also be stored in a memory in the computer device in a software form, so that the processor can call and execute operations corresponding to the modules.
In one embodiment, a computer device is provided, which may be a server, the internal structure of which may be as shown in fig. 5. The computer device includes a processor, a memory, and a network interface connected by a system bus. Wherein the processor of the computer device is configured to provide computing and control capabilities. The memory of the computer device includes a non-volatile storage medium and an internal memory. The non-volatile storage medium stores an operating system, a computer program, and a database. The internal memory provides an environment for the operating system and the computer program to run on the non-volatile storage medium. The database of the computer device is used to store target transaction event data. The network interface of the computer device is used for communicating with an external terminal through a network connection. The computer program is executed by a processor to implement a method of identifying an anomalous transaction event.
Those skilled in the art will appreciate that the architecture shown in fig. 5 is merely a block diagram of some of the structures associated with the disclosed aspects and is not intended to limit the computing devices to which the disclosed aspects apply, as particular computing devices may include more or less components than those shown, or may combine certain components, or have a different arrangement of components.
In one embodiment, there is further provided a computer device including a memory and a processor, the memory having a computer program stored therein, the processor implementing the steps of the above method embodiments when executing the computer program.
In an embodiment, a computer-readable storage medium is provided, on which a computer program is stored which, when being executed by a processor, carries out the steps of the above-mentioned method embodiments.
In an embodiment, a computer program product is provided, comprising a computer program which, when being executed by a processor, carries out the steps of the above-mentioned method embodiments.
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 for analysis, stored data, displayed data, etc.) referred to in the present application are information and data authorized by the user or sufficiently authorized by each party.
It will be understood by those skilled in the art that all or part of the processes of the methods of the embodiments described above may be implemented by hardware instructions of a computer program, which may be stored in a non-volatile computer-readable storage medium, and when executed, may include the processes of the embodiments of the methods described above. Any reference to memory, databases, or other media used in the embodiments provided herein can include at least one of non-volatile and volatile memory. The nonvolatile Memory may include Read-Only Memory (ROM), magnetic tape, floppy disk, flash Memory, optical Memory, high-density embedded nonvolatile Memory, resistive Random Access Memory (ReRAM), magnetic Random Access Memory (MRAM), ferroelectric Random Access Memory (FRAM), phase Change Memory (PCM), graphene Memory, and the like. Volatile Memory can include Random Access Memory (RAM), external cache Memory, and the like. 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), among others. The databases involved in the embodiments provided herein may include at least one of relational and non-relational databases. The non-relational database may include, but is not limited to, a block chain based distributed database, and the like. The processors referred to in the embodiments provided herein may be general purpose processors, central processing units, graphics processors, digital signal processors, programmable logic devices, quantum computing based data processing logic devices, etc., without limitation.
The technical features of the above embodiments can be arbitrarily combined, and for the sake of brevity, all possible combinations of the technical features in the above embodiments are not described, but should be considered as the scope of the present specification as long as there is no contradiction between the combinations of the technical features.
The above-mentioned embodiments only express several embodiments of the present application, and the description thereof is more specific and detailed, but not construed as limiting the scope of the present application. It should be noted that, for a person skilled in the art, several variations and modifications can be made without departing from the concept of the present application, and these are all within the scope of protection of the present application. Therefore, the protection scope of the present application should be subject to the appended claims.

Claims (10)

1. A method for identifying anomalous transaction events, said method comprising:
in response to a target transaction event, determining an event category of the target transaction event;
under the condition that the event category of the target transaction event is a submission event, retrieving in identification cache information according to the event identification of the target transaction event; a submission event identifier is stored in the identifier cache information, and the submission event identifier is used for representing the query result as an event identifier of a submission event which fails to submit;
if the submitted event identifier corresponding to the event identifier of the target transaction event is not retrieved from the identifier cache information, retrieving in a historical transaction log set according to the event identifier of the target transaction event;
and if the historical transaction log corresponding to the event identifier of the target transaction event is retrieved from the historical transaction log set, identifying the target transaction event as an abnormal transaction event.
2. The method of claim 1, wherein after retrieving in identification cache information according to the event identification of the target transaction event, further comprising:
and if a submission event identifier corresponding to the event identifier of the target transaction event is retrieved from the identifier cache information, identifying the target transaction event as an abnormal transaction event.
3. The method of claim 1, wherein after determining the event category of the target transaction event, further comprising:
if the event type of the target transaction event is a query event, identifying the target transaction event as a normal transaction event.
4. The method of claim 1, wherein after retrieving from a set of historical transaction logs according to the event identification of the target transaction event, further comprising:
and if the historical transaction log corresponding to the event identifier of the target transaction event is not retrieved in the historical transaction log set, identifying the target transaction event as a normal transaction event.
5. The method of any one of claims 1 to 4, wherein after determining the event category of the target transaction event, further comprising:
if the event type of the target transaction event is a query event, querying whether a transaction result of the target transaction event exists or not;
and if the transaction result of the target transaction event exists, storing the transaction log of the target transaction event into the historical transaction log set.
6. The method according to any one of claims 1 to 4, wherein in the case that the event category of the target transaction event is a query event, the event identifier comprises a user identifier, a transaction identifier, and an auxiliary identifier; the auxiliary identifier is a transaction identifier of a submission event queried by the query event; after the determining the event category of the target transaction event, the method further includes:
if the query result of the target transaction event is submission failure, establishing submission event information of the target transaction event according to the user identifier and the auxiliary identifier of the target transaction event, and storing the submission event information to the identifier cache information.
7. The method of claim 2, further comprising:
and if the submitting event identifier corresponding to the event identifier of the target transaction event is retrieved from the identifier cache information, stopping the processing of the target transaction event.
8. The method of claim 1, further comprising:
and if the historical transaction log corresponding to the event identifier of the target transaction event is retrieved from the historical transaction log, performing alarm processing.
9. An apparatus for identifying anomalous transaction events, said apparatus comprising:
a determining module, configured to determine an event category of a target transaction event in response to the target transaction event;
the first retrieval module is used for retrieving in the identification cache information according to the event identification of the target transaction event under the condition that the event category of the target transaction event is a submission event; a submission event identifier is stored in the identifier cache information, and the submission event identifier is used for representing the query result as an event identifier of a submission event which fails to submit;
a second retrieval module, configured to, if a submitted event identifier corresponding to the event identifier of the target transaction event is not retrieved from the identifier cache information, retrieve the submitted event identifier from a historical transaction log set according to the event identifier of the target transaction event;
and the third retrieval module is used for identifying 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 retrieved from the historical transaction log.
10. A computer device comprising a memory and a processor, the memory storing a computer program, characterized in that the processor, when executing the computer program, implements the steps of the method of any of claims 1 to 8.
CN202211010270.1A 2022-08-23 2022-08-23 Abnormal transaction event identification method and device, computer equipment and storage medium Pending CN115293908A (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202211010270.1A CN115293908A (en) 2022-08-23 2022-08-23 Abnormal transaction event identification method and device, computer equipment and storage medium

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202211010270.1A CN115293908A (en) 2022-08-23 2022-08-23 Abnormal transaction event identification method and device, computer equipment and storage medium

Publications (1)

Publication Number Publication Date
CN115293908A true CN115293908A (en) 2022-11-04

Family

ID=83831046

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202211010270.1A Pending CN115293908A (en) 2022-08-23 2022-08-23 Abnormal transaction event identification method and device, computer equipment and storage medium

Country Status (1)

Country Link
CN (1) CN115293908A (en)

Similar Documents

Publication Publication Date Title
US20230125566A1 (en) Long string pattern matching of aggregated account data
CN107038182B (en) Method and device for checking completeness of sub-table data
JP4848128B2 (en) Database system, computer-executable method for database system, program and method for updating index table in database system
CN109785867B (en) Double-recording flow configuration method and device, computer equipment and storage medium
US20170286440A1 (en) Method, business processing server and data processing server for storing and searching transaction history data
CN115293908A (en) Abnormal transaction event identification method and device, computer equipment and storage medium
US20230298016A1 (en) Systems and methods for validating asset destinations in blockchain networks
CN113902415A (en) Financial data checking method and device, computer equipment and storage medium
CN115186164A (en) Search request control method and device, equipment, medium and product thereof
WO2021207831A1 (en) Method and systems for indexing databases on a contextual basis
CN114490415A (en) Service testing method, computer device, storage medium, and computer program product
CN113806504B (en) Multi-dimensional report data calculation method and device and computer equipment
CN115599968A (en) Transaction data processing method and device, computer equipment and storage medium
CN116248481A (en) Message processing method, device, computer equipment and storage medium
US20240078225A1 (en) Transaction management method and transaction management apparatus
CN117194499A (en) Real estate service processing method, apparatus, device, storage medium and program product
CN117593125A (en) Service data processing method, device, computer equipment and storage medium
CN117314603A (en) Resource acquisition method, device, equipment and storage medium based on block chain system
CN114185949A (en) Information registration method, information registration apparatus, computer device, storage medium, and program product
CN114237977A (en) Transaction rollback method, device, computer equipment and storage medium
CN115190015A (en) Soft load system configuration method and device, computer equipment and storage medium
CN114756589A (en) Document number generation method and device and computer equipment
CN117785900A (en) Data updating method, device, computer equipment and storage medium
CN113987322A (en) Index data query method and device, computer equipment and computer program product
CN117454025A (en) Method, device, equipment and medium for determining paging display data of server

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