A highly efficient fund transaction monitoring and analysis system

Abstract

The present invention provides an efficient fund transaction monitoring and analysis system, comprising: multiple management nodes: based on transaction information, a monitoring rule subset is screened out from a cached monitoring rule set; an analysis node is selected from a routing table for each monitoring rule of the monitoring rule subset in an asynchronous parallel manner, and a transaction analysis task is sent to the selected analysis node, and the analysis results returned by the selected multiple analysis nodes are statistically determined to determine the transaction status of the transaction to be analyzed; multiple analysis nodes: an aggregate query SQL statement is constructed using the parameters of the transaction analysis task, an aggregate value is obtained by querying in a database through the aggregate query SQL statement, an analysis result is determined based on the aggregate value, and the analysis result is returned to the management node that issues the transaction analysis task; and a database stores transaction information. Functions are distributed on different nodes, and transaction analysis tasks are sent to analysis nodes in an asynchronous parallel manner for analysis, so that transaction analysis tasks are executed in parallel, thereby improving transaction analysis efficiency.

Description

Technical Field

[0001] The present invention relates to the field of Internet technology, and in particular to a high-efficiency fund transaction monitoring and analysis system. Background Art

[0002] With the rapid development of the economy, the volume and frequency of fund transactions have increased rapidly, and abnormal transactions have become more and more common. Abnormal transactions not only cause huge losses to users themselves, but also seriously undermine the financial order, damage the reputation of financial institutions, and have a very bad impact on society.

[0003] The existing fund transaction monitoring and analysis solutions usually calculate the transaction information according to the pre-built monitoring rules, and obtain the transaction monitoring and analysis results based on the calculation results. However, as the types of fund transaction risk monitoring increase, the number of monitoring rules increases, and the transaction frequency increases, each fund transaction can match multiple monitoring rules, and multiple matching monitoring rules need to be calculated, which is time-consuming and reduces the efficiency of fund transaction monitoring and analysis.

[0004] In addition, the existing fund transaction monitoring and analysis scheme sets the analysis and calculation of multiple monitoring rules and the fusion of multiple calculation results on the same device, which is limited by the hardware such as the computing power and memory of a single device, resulting in low efficiency of transaction monitoring and analysis. For example, the patent with the publication number CN114049215A in the prior art discloses a method and device for identifying abnormal transactions, which first distinguishes the types of risk control rules, and inputs different types of risk control rules into different classifiers to identify keywords, represents the meaning of the risk control rules themselves according to the identified keywords, and adopts corresponding processing methods according to the substantive meaning, and finally obtains the classification results, thereby improving the efficiency of transaction monitoring and analysis. However, all its steps are executed on the same device. When the number of transactions to be analyzed is large, it is limited by the computing resources of the device, and there is a bottleneck in efficiency improvement. It is impossible to quickly obtain the transaction monitoring and analysis results, and the efficiency cannot be greatly improved. Summary of the invention

[0005] The present invention aims to solve the technical problem in the prior art that the efficiency of fund transaction monitoring and analysis is low when facing a large number of fund transactions and a variety of monitoring rules, and to provide a highly efficient fund transaction monitoring and analysis system.

[0006] In order to achieve the above-mentioned purpose of the present invention, the present invention provides a highly efficient fund transaction monitoring and analysis system, comprising: multiple management nodes, each management node, after receiving the transaction information of the transaction to be analyzed, executes: based on the transaction information, filter out a monitoring rule subset from the monitoring rule set cached in the memory; select an analysis node for each monitoring rule of the monitoring rule subset from the routing table of the management node in an asynchronous parallel manner and send a transaction analysis task to the selected analysis node, and count the analysis results returned by multiple selected analysis nodes to determine the transaction status of the transaction to be analyzed, wherein the parameters of the transaction analysis task include transaction information and a monitoring rule in the monitoring rule subset; multiple analysis nodes, each analysis node, after receiving the transaction analysis task, executes: using the parameters of the received transaction analysis task to construct an aggregate query SQL statement, querying the database through the aggregate query SQL statement to obtain an aggregate value, determining the analysis result based on the aggregate value, and returning the analysis result to the management node that issued the transaction analysis task; a database, storing transaction information.

[0007] The transaction analysis system provided by the present invention is divided into a management node and an analysis node, and functions are distributed on different nodes. The transaction analysis tasks are submitted to the analysis nodes for analysis in an asynchronous parallel manner, so that the transaction analysis tasks can be executed in parallel, greatly improving the efficiency of transaction analysis; and the monitoring rules are pre-grouped and cached in the memory of the management node, so that the matching operations are all completed in the memory of the management node, thereby improving the matching efficiency between the monitoring rules and the transaction information. This also reduces the number of interactions with the database, shortens the analysis time, and further improves the efficiency. In addition, multiple management nodes and analysis nodes can be deployed, and various types of nodes can be flexibly expanded, so that the system has high availability and high scalability. BRIEF DESCRIPTION OF THE DRAWINGS

[0008] Figure 1 It is a structural diagram of a fund transaction monitoring and analysis system in a preferred embodiment of the present invention;

[0009] Figure 2 It is a schematic diagram of a transaction analysis process of a fund transaction monitoring and analysis system in a preferred embodiment of the present invention;

[0010] Figure 3 This is an example of analyzing task log table records in a preferred embodiment of the present invention;

[0011] Figure 4 It is a schematic diagram of the distribution of the proportion of each analysis node processing and executing the set monitoring rules in a preferred implementation mode of the present invention. DETAILED DESCRIPTION

[0012] Embodiments of the present invention are described in detail below, examples of which are shown in the accompanying drawings, wherein the same or similar reference numerals throughout represent the same or similar elements or elements having the same or similar functions. The embodiments described below with reference to the accompanying drawings are exemplary and are only used to explain the present invention, and cannot be understood as limiting the present invention.

[0013] In the description of the present invention, it is necessary to understand that the terms "longitudinal", "lateral", "up", "down", "front", "back", "left", "right", "vertical", "horizontal", "top", "bottom", "inside", "outside", etc., indicating the orientation or position relationship, are based on the orientation or position relationship shown in the accompanying drawings, and are only for the convenience of describing the present invention and simplifying the description, rather than indicating or implying that the device or element referred to must have a specific orientation, be constructed and operated in a specific orientation, and therefore cannot be understood as a limitation on the present invention.

[0014] In the description of the present invention, unless otherwise specified and limited, it should be noted that the terms "installed", "connected" and "connected" should be understood in a broad sense. For example, it can be a mechanical connection or an electrical connection, or it can be the internal connection between two components. It can be a direct connection or an indirect connection through an intermediate medium. For ordinary technicians in this field, the specific meanings of the above terms can be understood according to the specific circumstances.

[0015] The present invention provides a highly efficient fund transaction monitoring and analysis system. In a preferred embodiment, Figure 1 As shown, the system includes multiple management nodes, multiple analysis nodes, and a database (not shown), which stores transaction information of all transactions. A cluster is composed of multiple management nodes and multiple analysis nodes.

[0016] like Figure 1 As shown, each management node and each analysis node communicate with each other through the RPC interface. Each management node provides an analysis node registration RPC interface for receiving registration requests from each analysis node; each analysis node provides a transaction analysis RPC interface for receiving transaction analysis tasks assigned by each management node; each management node is connected to an MQ (message queue) cluster, and cross-host collaboration, such as data synchronization and message notification, is achieved through the MQ (message queue) cluster.

[0017] Each management node provides transaction monitoring and analysis RPC interface, monitoring rule addition RPC interface and monitoring rule deletion RPC interface for external system calls.

[0018] The system is a server-side program that is deployed and runs on the server. The interfaces and functions provided by each node (including management nodes and analysis nodes) support concurrent calls and processing.

[0019] In this implementation, JAVA language coding is used, the database can be Oracle, MySQL, etc., the MQ (message queue) can be RocketMQ, RabbitMQ, etc., and the RPC framework can be Dubbo, Spring-Cloud, etc.

[0020] In this embodiment, the management node is responsible for the management of transaction information and analysis nodes and the allocation of transaction analysis tasks, and the analysis node is responsible for analyzing transactions according to monitoring rules. The database stores transaction information, monitoring rule sets and analysis task logs. The database can be set in a separate server, integrated in the storage device of a management node, or distributed and integrated in the storage devices of multiple management nodes. The management node and the analysis node access the same database. The management node has new addition and update operations on the data, and the analysis node only has query operations on the data. The system provides transaction monitoring and analysis RPC interfaces for external system calls by each management node. RPC interface call: refers to the process on computer A, which calls the service provided by the process on computer B through the network in the form of an interface. The caller can transmit information to the called party through parameters, and then transmit the results of the processing by the called party through the network to obtain the return data of the interface. This process is transparent to developers.

[0021] In this embodiment, the transaction information includes transaction ID, transaction type, business code, application ID, creation time, currency, transaction amount (cents), terminal type, terminal ID, terminal IP, transaction remarks, identity authentication method (such as payment password, electronic certificate, mobile phone text message, face, etc., which can be multiple), transaction status, payee account ID, payee account level, payee ID type, payee name (or name), payee ID number, payee bank code, payee bank account name, payee bank account number, payee bank account type, payee account ID, payee account level, payee ID type, payee name (or name), payee ID number, payee bank code, payee bank account name, payee bank account number, payee bank account type and other attributes. Among them, the transaction status includes legal transaction and illegal transaction. When the transaction information is saved in the database, the initial default transaction status is legal transaction, and the final transaction status is confirmed after transaction analysis.

[0022] In this embodiment, the monitoring rules set in the database are in the first form. Preferably, each monitoring rule in the database includes the following attributes:

[0023] Monitoring rule ID: unique identifier of the monitoring rule;

[0024] Matching rules: Expressed (or represented) in JAVA code. When the management node is started, this attribute is used to build a complete JAVA class and compile and instantiate it. The compiled and instantiated object is used as the derived attribute of this monitoring rule. The monitoring rule and transaction information are matched by executing the matching method of this object (or derived attribute). The matching rules of the monitoring rules are expressed (or represented) in JAVA code. The matching rules are highly flexible. When the staff who are not familiar with JAVA code configure the monitoring rules, they can use the code tool to generate JAVA code.

[0025] Aggregation period: can be any of permanent, year, season, month, week, day, single transaction; can also be a dynamically expressed time interval;

[0026] Aggregation method: can be any of the following: total number of transactions, total transaction amount, average transaction amount, median transaction amount, or transaction amount variance. In particular, when the "Aggregation period" attribute is "single transaction", the aggregation method must be "total transaction amount";

[0027] Aggregation condition: SQL statement fragment template, consisting of SQL statements and EL expressions. The content of this attribute is related to the name and field name of the transaction information table in the database and the attribute name of the transaction information to be analyzed; for example:

[0028] PAYER_FINANCE_ACCOUNT_NUMBER = '${payerFinanceAccountNumber}' AND PAY_TYPE IN ('INNERTRANS', 'REFUND', 'OUTERTRANS'), where 'PAYER_FINANCE_ACCOUNT_NUMBER' is the 'payer bank account number' field of the transaction information table, and 'PAY_TYPE' is the 'transaction type' field of the transaction information table;

[0029] Illegal interval: a closed interval consisting of a starting value and an ending value. For example, if the starting value is 201 and the ending value is 500, it means that the aggregate value is greater than or equal to 201 and less than or equal to 500, which is an illegal transaction. If the ending value is empty, it means infinity. For example, if the starting value is 201 and the ending value is empty, it means that the aggregate value is greater than or equal to 201, which is an illegal transaction.

[0030] Associated transaction type: used to cache monitoring rule groups in memory; can be multiple values, that is, one monitoring rule can monitor and analyze multiple types of transactions, and one monitoring rule in the cache corresponds to multiple groups.

[0031] In this embodiment, in order to improve the efficiency of transaction analysis, preferably, each management node performs the following steps to cache the monitoring rule set in memory when it starts:

[0032] Step 1: The management node loads the monitoring rule set from the database, and executes for each monitoring rule in the monitoring rule set: Use the matching rule attribute of the monitoring rule to build a complete JAVA class and compile and instantiate it, and use the compiled instantiated object as the derived attribute of the monitoring rule; wherein the matching rule attribute of the monitoring rule is represented in the form of JAVA code. Specifically, load all available monitoring rules from the database, use the matching rule attribute (JAVA code) of the monitoring rule to build a complete JAVA class (implementing the TransMatcher interface), use the JDK compiler (obtained using the ToolProvider.getSystemJavaCompiler() method) to compile and instantiate the constructed complete JAVA class, use the compiled instantiated object as a derived attribute of the TransMatcher type of the monitoring rule, and match the monitoring rule with the transaction information by executing the matching method of the object (the method name is "matches", which executes the logic represented by the matching rule attribute of the monitoring rule).

[0033] For example, the matching rule attributes of a monitoring rule are:

[0034] return "III".equals(trans.getPayerAccountLevel())&&Utils.include(trans.getPayType(),"INNERTRANS","OUTERTRANS","REFUND");

[0035] Among them, trans is the transaction information object. The meaning of this code is: this rule applies to transactions where the payer's account level is "III" and the transaction type is "INNERTRANS" (internal transfer) or "OUTERTRANS" (external transfer) or "REFUND" (refund).

[0036] The code for constructing a complete JAVA class (class name TransMatcherPSIIITRANSYEAR20W, format TransMatcher+monitoring rule ID) in the above example is as follows:

[0037]

[0038] Use the JDK compiler (obtained using the ToolProvider.getSystemJavaCompiler() method) to compile the above code into a class file, instantiate this class file using reflection (call the newInstance() method of this class to create an instance object), and use the instantiated object as a derived attribute of the TransMatcher type of the monitoring rule.

[0039] Step 2: The management node groups all monitoring rules in the monitoring rule set according to the "associated transaction type" attribute of the monitoring rule. Each transaction type corresponds to a group, each group contains multiple monitoring rules, and each monitoring rule corresponds to more than one group. Specifically, the compiled monitoring rules are grouped according to the "associated transaction type" attribute of the monitoring rules. One transaction type corresponds to one (multiple) monitoring rules, and one monitoring rule can be associated with multiple transaction types. Finally, the grouped monitoring rules are cached in memory.

[0040] For example, the "associated transaction type" attribute of a monitoring rule is "INNERTRANS, OUTERTRANS, REFUND", which means that this monitoring rule is applicable to three transaction types, namely, transactions of the types INNERTRANS (internal transfer), OUTERTRANS (external transfer), and REFUND (refund), that is, the groups corresponding to the above three transaction types all include this monitoring rule.

[0041] In this embodiment, the form of monitoring rules in which the management node compiles the instantiated matching rule attributes according to the above steps and groups and caches them into the memory according to the "associated transaction type" attribute is called the second form of monitoring rules.

[0042] In this embodiment, preferably, in order to facilitate each management node to perceive the operating status of each analysis node, an analysis node daemon thread is created when the analysis node is started, and the analysis node daemon thread executes: the analysis node periodically initiates an analysis node registration request to each management node at a first time interval, and the parameters of the analysis node registration request include the service IP and port of the analysis node, the current system time of the analysis node, the number of CPUs of the analysis node host server, the CPU idle rate and the free memory size.

[0043] In this embodiment, specifically, the first time interval is preferably but not limited to 10 to 20 seconds, such as 15 seconds. The first time interval is configured in each analysis node. The service IP and port of the registration RPC interface provided by each management node to the analysis node for calling are pre-configured in each analysis node. Each analysis node initiates an analysis node registration request to each management node by calling the registration RPC interface of each management node point-to-point according to the first time interval. The parameters of the analysis node registration request include the service IP and port of the analysis node, the current system time of the analysis node (accurate to milliseconds), and the resource information of the host server of the analysis node (specifically obtainable through commands or oshi components) such as the number of CPUs included, CPU idle rate, and idle memory size.

[0044] In this embodiment, in order to facilitate the management of analysis nodes and grasp the status of analysis nodes, preferably, each management node has a routing table, which stores the service IP and port of each analysis node, the creation time, the most recent registration time, the network delay between the management node and the analysis node, the number of CPUs of the analysis node host server, the CPU idle rate and the free memory size.

[0045] In this embodiment, the network delay between the management node and the analysis node is the current system time of the management node minus the system time of the analysis node when the analysis node initiates a registration request to the management node, that is, the difference between the system time of the management node when the management node receives the registration request of the analysis node and the system time of the analysis node when the analysis node initiates a registration request to the management node, wherein the system time of the analysis node when the analysis node initiates a registration request to the management node is the parameter of the registration request initiated by the analysis node to the management node ("current system time of the analysis node"). The resource information of the host server of the analysis node includes the number of CPUs, the CPU idle rate, and the size of the idle memory, which are all parameters corresponding to the registration request initiated by the analysis node to the management node, and these parameters are stored in the routing table.

[0046] In this embodiment, when the analysis node initiates a registration request to the management node, the management node checks whether the analysis node exists in the routing table (using the service IP+port of the analysis node as a unique identifier). If not, a new analysis node is created. For the newly created analysis node, the creation time is the current system time of the management node, the most recent registration time is also the current system time of the management node, and the service IP and port of the analysis node are the parameters corresponding to the registration request initiated by the analysis node to the management node. If the analysis node exists in the routing table, the most recent registration time of the analysis node is updated to the current system time, and the network delay attributes of the management node and the analysis node and the resource information of the host server of the analysis node, including the number of CPUs, CPU idle rate, and idle memory size, are obtained and updated in the same manner as above.

[0047] In this embodiment, in order to ensure the reliability of the analysis nodes in the routing table of the management node and enable the transaction analysis task to be smoothly executed by the analysis node, preferably, each management node creates a routing table daemon thread when it is started, and the routing table daemon thread executes: the management node regularly traverses the associated routing table according to the second time interval to remove abnormal analysis nodes, and the abnormal analysis nodes are analysis nodes that meet the most recent registration time plus the timeout time less than or equal to the current system time of the management node. The second time interval is preferably, but not limited to, 5 seconds to 15 seconds, preferably 10 seconds.

[0048] In this embodiment, the specific execution process of the routing table daemon thread is: traverse the routing table once every second time interval. If the last registration time of the analysis node in the routing table plus the timeout time is less than or equal to the current system time of the management node, it is considered that the corresponding analysis node is abnormal in operation and is an abnormal analysis node. The abnormal analysis node is removed from the routing table so that the management node no longer assigns analysis tasks to the analysis node. The removal condition of the analysis node in the routing table must satisfy the following inequality:

[0049] Where c is the current system time of the management node (in milliseconds), r is the last registration time initiated by the analysis node (in milliseconds), It is the value of the timeout function (if the calculation result is a decimal, it will be rounded to an integer in milliseconds).

[0050] Timeout The calculation formula of the function is:

[0051] Wherein, t is the time period during which the analysis node initiates a registration request to the management node, which is a first time interval; is the average value of the network delay between the management node and each analysis node is the error function value of the network delay between the management node and each analysis node, d i represents the network delay from the i-th analysis node in the routing table to the management node, and n represents the number of analysis nodes in the routing table of the management node. Through the timeout function, when the analysis node fails to initiate a registration request to the management node for two consecutive registration request cycles, the management node regards the operation status of the corresponding analysis node as abnormal, that is, an abnormal analysis node, and removes the abnormal analysis node from the routing table to ensure the availability of the analysis node in the routing table.

[0052] In this embodiment, the host server where each management node and each analysis node are deployed should perform clock synchronization regularly through the NTP service.

[0053] In this embodiment, each management node provides a transaction monitoring and analysis RPC interface for an external system to call. When the external system calls the transaction monitoring and analysis RPC interface provided by the management node, the fund transaction analysis method of the fund transaction monitoring and analysis system provided by the present invention includes the following steps:

[0054] Step A, after receiving the transaction information of the transaction to be analyzed, each management node saves the transaction information of the transaction to be analyzed to the database (at this time, the transaction status defaults to "legal transaction"), and executes: based on the transaction information, a monitoring rule subset is filtered out from the monitoring rule set cached in the memory; an analysis node is selected from the routing table of the management node for each monitoring rule of the monitoring rule subset in an asynchronous parallel manner and a transaction analysis task is sent to the selected analysis node, so that the transaction analysis task is executed asynchronously and in parallel, thereby improving the efficiency of transaction monitoring and analysis. In particular, if the number of analysis nodes in the routing table of the management node is 0, the management node throws an exception when selecting an analysis node for the monitoring rule in the monitoring rule subset and prompts "no available analysis node"; wherein the parameters of the transaction analysis task include transaction information and a monitoring rule in the monitoring rule subset, and the state of the monitoring rule in the transaction analysis task sent by the management node to the selected analysis node is defined as the third state, and the monitoring rule in the third state includes the monitoring rule's unique ID attribute, aggregation period attribute, aggregation method attribute, aggregation rule template attribute, and illegal interval attribute, and the third state does not include the matching rule attribute and the derived attribute of constructing a JAVA class and compiling the instantiation by the matching rule attribute. The transaction information in the transaction analysis task sent to the analysis node contains all the attributes of the transaction information.

[0055] Step B, after receiving the transaction analysis task sent by the management node, each analysis node executes: using the parameters of the received transaction analysis task to build an aggregate query SQL statement, querying the database to obtain the aggregate value through the aggregate query SQL statement, determining the analysis result based on the aggregate value and the illegal interval attribute of the monitoring rule, and returning the analysis result to the management node that issued the transaction analysis task.

[0056] In this embodiment, specifically, step B includes:

[0057] Step B.1, generate aggregation rules (SQL statements) according to the aggregation rule template attributes of the monitoring rules and transaction information. Take the transaction information as a parameter, and generate aggregation rule SQL statement fragments according to the aggregation rule template attributes of the monitoring rules as a template; calculate the aggregation time range according to the aggregation period attribute of the monitoring rules and generate the aggregation time range SQL statement fragment; generate the aggregation method SQL statement fragment according to the aggregation method attribute of the monitoring rules; finally, splice the above SQL statement fragments into a complete aggregation query SQL statement.

[0058] The aggregate rule template attributes of the monitoring rule are in the format of "SQL statement fragment + EL expression". For example, the aggregate rule template attributes of the monitoring rule are:

[0059] PAYER_FINANCE_ACCOUNT_NUMBER='${payerFinanceAccountNumber}'AND PAY_TYPE IN('INNERTRANS', 'REFUND', 'OUTERTRANS').

[0060] Among them, ${payerFinanceAccountNumber} of the aggregation rule template attribute of the monitoring rule is an EL expression. When generating the aggregation rule SQL statement fragment, this parameter will be replaced with the value of the corresponding attribute in the transaction information. For example, the payerFinanceAccountNumber (payer bank account number) attribute of the transaction information is "15987646541235254556", and the generated aggregation rule SQL statement fragment is:

[0061] PAYER_FINANCE_ACCOUNT_NUMBER='15987646541235254556' AND PAY_TYPE IN ('INNERTRANS', 'REFUND', 'OUTERTRANS').

[0062] The aggregated time start and end range is calculated based on the creation time attribute of the transaction information and the aggregation period of the monitoring rule, and the aggregated time range SQL statement fragment is generated. For example, the aggregation period attribute of the monitoring rule is "DAY (daily limit)", and the creation time attribute of the transaction information is "2024-01-11 14:53:54". The start and end time of the time range is calculated to be "2024-01-11 00:00:00.000~2024-01-11 23:59:59.999" (accurate to milliseconds), and the generated aggregated time range SQL statement fragment is: CREATE_TIME>='2024-01-11 00:00:00.000'AND CREATE_TIME<='2024-01-11 23:59:59.999'.

[0063] Generate an aggregation SQL statement fragment based on the aggregation mode attribute of the monitoring rule. For example, if the value of this attribute is "SUM (total transaction amount)", the generated aggregation SQL statement fragment is: SELECT SUM (AMOUNT) FROM TRANSWHERE STATE = 'LEGAL' (here only transactions with a status of "legal transaction" are aggregated).

[0064] The complete aggregate query SQL statement obtained by splicing the above SQL statement fragments is:

[0065] SELECT SUM(AMOUNT)FROM TRANS WHERE STATE=′LEGAL′AND CREATE_TIME>=′2024-01-11 00:00:00.000′AND CREATE_TIME<=′2024-01-11 23:59:59.999′AND PAYER_FINANCE_ACCOUNT_NUMBER=′15987646541235254556′AND PAY_TYPE IN(′INNERTRANS′,′REFUND′,′OUTERTRANS′)

[0066] Step B.2, query the above SQL statement in the database (the analysis node and the management node use the same database) to obtain an aggregated value, that is, the aggregated value.

[0067] Step B.3, compare the above-obtained aggregate value with the illegal interval represented by the illegal interval attribute of the monitoring rule. If it belongs to the illegal interval of the monitoring rule, the transaction is judged as an "illegal transaction", otherwise it is judged as a "legal transaction".

[0068] Step B.4, returning the above analysis results to the management node that issues the transaction analysis task.

[0069] In this embodiment, "SQL statement fragment + EL expression" is used as the aggregation rule template of the monitoring rule, and the aggregation query SQL statement fragment is generated according to the attributes of the transaction information and this template. The aggregation rule is highly flexible, and the process of generating the aggregation query SQL statement fragment is simple and efficient.

[0070] In this embodiment, the two attributes of the monitoring rule, "aggregation period" and "aggregation method", are used to generate analysis nodes to generate aggregate query SQL statement fragments. In the above step B.1, in particular, when the "aggregation period" attribute is "SINGLTEN (single transaction)", the "aggregation method" attribute can only be "SUM (total transaction amount)", and there is no need to generate an aggregate query SQL statement at this time, but directly use the value of the transaction amount attribute of the current transaction to compare with the illegal interval represented by the illegal interval attribute of the monitoring rule. If it belongs to the illegal interval of the monitoring rule, the transaction is judged as an "illegal transaction", otherwise it is judged as a "compliant transaction". In particular, when the "aggregation period" attribute is "PERM (permanent)", the aggregation time range SQL statement fragment is not generated, that is, the time range of the aggregate query is not restricted. When the "aggregation period" attribute is "YEAR", the aggregation time range SQL statement fragment is generated according to the start and end time of the natural year where the creation time attribute of the transaction information is located. For example, when the creation time attribute of the transaction information is "2024-01-11 14:53:54" and the aggregation period attribute is "YEAR", the generated aggregation time range SQL statement fragment is: CREATE_TIME>='2024-01-01 00:00:00.000'AND CREATE_TIME<='2024-12-31 23:59:59.999'; when the "aggregation period" attribute is "MONTH", the aggregation time range SQL statement fragment is generated according to the start and end time of the natural month where the creation time attribute of the transaction information is located. For example, when the creation time attribute of the transaction information is "2024-01-11 14:53:54", when the aggregation period attribute is "MONTH", the generated aggregation time range SQL statement fragment is: CREATE_TIME>='2024-01-01 00:00:00.000'AND CREATE_TIME<='2024-01-31 23:59:59.999'; and so on.

[0071] When the "aggregation method" attribute of the monitoring rule is "COUNT (total number of transactions)", the resulting aggregation method SQL statement fragment is: SELECT COUNT (AMOUNT) FROM TRANS WHERE STATE = 'LEGAL'; when the "aggregation method" attribute is "AVG (average transaction amount)", the resulting aggregation method SQL statement fragment is: SELECT AVG (AMOUNT) FROM TRANS WHERE STATE = 'LEGAL'; and so on.

[0072] Step C: Count the analysis results returned by multiple selected analysis nodes and determine the final transaction status of the transaction to be analyzed.

[0073] Step C specifically includes: the management node waits for and receives the analysis results returned by the analysis node (the analysis results returned by the analysis node will be saved in the created CompletionService object, and the take method of the CompletionService object will be called (this method will block until the analysis results of multiple selected analysis nodes are all returned) to obtain), and the number of analysis results is equal to the number of monitoring rules in the above-mentioned monitoring rule subset B. If the number of "illegal transactions" returned by the analysis node is greater than 0, the final transaction status of the transaction corresponding to the transaction information of the transaction to be analyzed is judged as "illegal transaction", and the status of the corresponding transaction information record in the database is updated to the "illegal transaction" status; otherwise, the final transaction status of the transaction corresponding to the transaction information is judged as "legal transaction".

[0074] In this embodiment, the step of the management node returning the determined final transaction status of the transaction to be analyzed to the external calling system is also included.

[0075] In a preferred embodiment, in order to improve the efficiency of transaction analysis, in the above step A, refer to Figure 2 The process of the management node filtering out a subset of monitoring rules from the monitoring rule set cached in memory based on transaction information includes:

[0076] Step A-1, obtaining a monitoring rule group that is adapted to the transaction type attribute of the transaction information from the monitoring rule set cached in the memory, and the adapted monitoring rule group constitutes a monitoring rule set A;

[0077] Step A-2, traverse the monitoring rule set A, match the monitoring rules and the transaction information by executing the matching method of the derived attributes of the monitoring rules, extract the monitoring rules matching the transaction information, and form the extracted monitoring rules into the monitoring rule subset B.

[0078] Specifically, the matching action is completed by executing the matching method (the method name is "matches", and the input parameter of this method is all the information of a transaction) of the object instantiated by constructing JAVA code and compiling the matching rule attribute of the monitoring rule (this object is a derived attribute of the TransMatcher type of the monitoring rule to which this matching rule attribute belongs).

[0079] In this embodiment, dynamic compilation and caching technology is adopted, that is, when the system is started (or newly added), the matching rule attributes (JAVA code) of the monitoring rules are used to construct a complete JAVA class and compile and instantiate it, and the instance object is used as the derived attribute of the monitoring rule. The monitoring rules are then grouped and cached into the memory according to their associated transaction types. The management node narrows the scope of matching monitoring rules through the transaction type attributes of the transaction information, and the matching actions are all completed in the memory, thereby improving the matching efficiency of monitoring rules and transaction information.

[0080] In a preferred embodiment, in order to take into account the network delay, idleness, load and processing capacity of the analysis node, the management node reasonably selects an analysis node for each monitoring rule from the routing table to improve the analysis efficiency. Preferably, in the above step A, an analysis node is selected from the routing table of the management node for each monitoring rule of the monitoring rule subset (refer to Figure 2 In step A-3), for monitoring rule b in monitoring rule subset B, b∈B, it includes:

[0081] Step A-3-1, obtaining first information of each analysis node in the routing table of the management node, the first information including the network delay between the analysis node and the management node, the number of CPUs of the host server of the analysis node, the CPU idle rate and the free memory size;

[0082] Step A-3-2, calculating the evaluation score of each analysis node according to a preset first evaluation function based on the first information of each analysis node;

[0083] Step A-3-3, select the analysis node with the highest evaluation score as the analysis node for monitoring rule b.

[0084] In this implementation, further preferably, the first evaluation function is:

[0085]

[0086] Among them, d represents the network delay between the analysis node and the management node, in milliseconds. In actual applications, the management node and the analysis node are deployed in the same local area network, and the network delay is within 2 milliseconds; l represents the CPU idle rate of the host server of the analysis node (percentage, which needs to be converted to a decimal between (0, 1)); n′ represents the number of CPUs of the host server of the analysis node; e is the base of the natural logarithm. g(m) represents the normalized value of the free memory size m (in MB) of the host server of the analysis node. The value of the free memory size m in the set dimension MB is substituted into the following normalization function (inverse tangent function) and normalized to the interval (0, 1), π is the ratio of a circle to its circumference.

[0087] In a preferred embodiment, in order to take into account the network delay, idleness, load and processing capacity of the analysis node, as well as the distribution of the transaction analysis tasks corresponding to each monitoring rule processed by the analysis node in the system, while selecting analysis nodes with strong processing capabilities, the transaction analysis tasks corresponding to each monitoring rule are evenly distributed on each analysis node, so as to enhance the robustness, security and processing capacity of the system and avoid the concentration of transaction analysis tasks of certain monitoring rules on some analysis nodes. Preferably, in the above step A, the step of selecting an analysis node for each monitoring rule of the monitoring rule subset from the routing table of the management node (refer to Figure 2 In step A-3), respectively select an analysis node for each monitoring rule in the monitoring rule subset B. For monitoring rule b, b∈B, the process of selecting an analysis node is:

[0088] Step A-3-1′, retrieve the analysis task log table from the database, use the data in the analysis task log table to calculate the proportion distribution of the analysis nodes processing the transaction analysis tasks containing monitoring rule b, and obtain the proportion p of each analysis node processing the transaction analysis tasks containing monitoring rule b according to the proportion distribution; wherein, the analysis task log table includes three fields: analysis node ID, monitoring rule ID and transaction ID, and a record is added to this table when the management node sends a transaction analysis task to the selected analysis node. In the above proportion distribution, the proportion p∈[0,1] of each analysis node processing the transaction analysis tasks containing monitoring rule b, and the sum of the proportions of all analysis nodes processing the transaction analysis tasks containing monitoring rule b is equal to 1.

[0089] Step A-3-2′, calculate the evaluation score of each analysis node according to the preset second evaluation function based on the network delay between each analysis node and the management node in the routing table of the management node, the number of CPUs, CPU idle rate and free memory size of the host server of the analysis node, and the proportion p of transaction analysis tasks containing monitoring rule b processed by the analysis node.

[0090] The second evaluation function is expressed as:

[0091]

[0092] Step A-3-3′, select the analysis node with the largest evaluation score as the analysis node for monitoring rule b.

[0093] In an application scenario of this embodiment, the detailed process of the management node executing step A is as follows:

[0094] Step 4.1, use the thread pool to construct a CompletionService object for asynchronous parallel scheduling execution: select analysis nodes for monitoring rule b and send transaction analysis tasks to the selected analysis nodes, so that the appropriate analysis nodes can asynchronously and parallelly process transaction analysis tasks.

[0095] Step 4.2, traverse the monitoring rules in the monitoring rule subset B and create an asynchronous transaction analysis task object using the monitoring rules and transaction information and submit it to the CompletionService object for scheduling and execution, so that the created asynchronous transaction analysis task object is executed asynchronously and in parallel. The execution logic of the asynchronous transaction analysis task object is as follows:

[0096] Step 4.2.1, count and calculate the distribution of transaction analysis tasks processed by each analysis node for this monitoring rule (proportion p, p∈[0,1]) from the analysis task log table of the database (containing three fields: analysis node ID, monitoring rule ID, transaction ID) according to the specified monitoring rule ID. For example, count and calculate the distribution of transaction analysis tasks processed by each analysis node for the monitoring rule (monitoring rule ID is "INNERTRANSDAY5CT"). The distribution of transaction analysis tasks processed by each analysis node for this monitoring rule is as follows: Figure 4 As shown, Figure 4 In the ANALYZE_NODE_ID field, the ID of the analysis phase is used, and the PROPORTION field is the percentage of transaction analysis tasks that process the specified monitoring rule, that is, p. Figure 4 If the analysis node does not exist in the result, the value of p is 0.

[0097] Step 4.2.2, select an analysis node from the routing table of the management node to send the current transaction analysis task to the node: based on the network delay between the analysis node and the management node, the resource information of the host server of the analysis node including the number of CPUs, CPU idle rate, free memory size and the distribution of the analysis nodes processing transaction analysis tasks of the specified monitoring rules obtained in step 4.2.1, a comprehensive evaluation (using the second evaluation function) is performed to calculate the score and select an analysis node with the highest score.

[0098] The second evaluation function is negatively correlated with the network delay between the analysis node and the management node, positively correlated with the resource information of the host server of the analysis node, including the number of CPUs, CPU idle rate, and idle memory size, and negatively correlated with the proportion of transaction analysis tasks that the analysis node processes with specified monitoring rules. In this way, when selecting an analysis node to submit a transaction analysis task, the network delay of the analysis node, the idle degree of the analysis node, and the distribution of transaction analysis tasks based on monitoring rules are taken into account; the transaction analysis tasks are evenly distributed on each analysis node, while taking into account the load and processing capacity of the analysis node.

[0099] Step 4.2.3, use the analysis node object obtained in step 4.2.2 (including the service IP and port of the analysis node) to create a proxy object for the transaction analysis RPC interface. The created proxy object is cached here according to the node IP, port and interface name to avoid creating the proxy object multiple times and affecting efficiency.

[0100] Step 4.2.4 converts the monitoring rule parameters required by the analysis node (there is no need to pass all the attributes of the monitoring rule to the analysis node): monitoring rule ID, aggregation cycle, aggregation method, aggregation condition template, and illegal interval.

[0101] Step 4.2.5, record the analysis task log, and save the ID of the analysis node object obtained in step 4.2.2 (in the format of "analysis node service IP: port"), monitoring rule ID, and transaction ID as an analysis task log record to the analysis task log table of the database, so that step 4.2.1 can count and calculate the distribution of transaction analysis tasks processed by each analysis node for this monitoring rule. The record example of the analysis task log table is as follows: Figure 3 shown.

[0102] Figure 3 In the ANALYZE_NODE_ID field, the ID of the analysis phase is displayed, the METAPHASE_ID field is the monitoring rule ID, and the TRANS_ID field is the transaction ID.

[0103] Step 4.2.6, send the transaction analysis task to the corresponding analysis node through the transaction analysis RPC interface proxy object created in step 4.2.3 by using the parameters and transaction information converted in step 4.2.4.

[0104] In a preferred embodiment, multiple management nodes synchronize monitoring rules according to the following steps:

[0105] Let the management node set be J, j and j′ are both management node indexes, and j≠j′, j∈J, j′∈J;

[0106] When a new monitoring rule is added: each management node provides an RPC interface for a new monitoring rule to the external system, and the external system calls the new monitoring rule interface provided by the management node j; the management node j saves the monitoring rule to be added to the database, and the management node j caches the new monitoring rule (constructs a complete JAVA class with its matching rule attributes and compiles and instantiates it, and uses the compiled and instantiated object as a derived attribute of the TransMatcher type of the new monitoring rule, and caches it in memory in groups according to its "associated transaction type" attribute), and synchronizes the basic information of the new monitoring rule to the management node j′ through the MQ (message queue) cluster in a broadcast manner; after receiving the message of the new monitoring rule synchronized by the MQ (message queue) cluster, the management node j′ caches the new monitoring rule (constructs a complete JAVA class with its matching rule attributes and compiles and instantiates it, and uses the compiled and instantiated object as a derived attribute of the TransMatcher type of the new monitoring rule, and caches it in memory in groups according to its "associated transaction type" attribute).

[0107] When deleting monitoring rules: each management node provides an RPC interface for deleting monitoring rules to the external system, and the external system calls the interface for deleting monitoring rules provided by management node j; management node j deletes the monitoring rules to be deleted from the database, and deletes the monitoring rules to be deleted from the monitoring rule set cached in the memory (removes the monitoring rules to be deleted from the monitoring rule cache grouped by "transaction type" according to the obtained "associated transaction type"), and synchronizes the basic information of the monitoring rules to be deleted to the management node j' through the MQ (message queue) cluster by broadcasting; management node j' deletes the monitoring rules to be deleted from the monitoring rule set cached in the memory (removes the monitoring rules to be deleted from the monitoring rule cache grouped by "transaction type" according to the received "associated transaction type").

[0108] In this embodiment, the system of the present invention provides a monitoring rule addition / deletion RPC interface for external system calls by the management node, so as to manage the monitoring rules. After the management node completes the addition / deletion operation of the monitoring rule record in the database and the addition / deletion operation of the monitoring rule in the cache of the management node, it constructs the addition / deletion message of the monitoring rule and notifies other management nodes through the MQ (message queue) cluster. After receiving the addition / deletion message of the monitoring rule, other management nodes perform the addition / deletion operation on the monitoring rule cached in the memory, ensuring that the data cached in the memory of the database and each management node are consistent.

[0109] In the description of this specification, the description with reference to the terms "one embodiment", "some embodiments", "examples", "specific examples", or "some examples" means that the specific features, structures, materials or characteristics described in conjunction with the embodiment or example are included in at least one embodiment or example of the present invention. In this specification, the schematic representation of the above terms does not necessarily refer to the same embodiment or example. Moreover, the specific features, structures, materials or characteristics described may be combined in any one or more embodiments or examples in a suitable manner.

[0110] Although the embodiments of the present invention have been shown and described, it will be appreciated by those skilled in the art that various changes, modifications, substitutions and variations may be made to the embodiments without departing from the principles and spirit of the present invention, and that the scope of the present invention is defined by the claims and their equivalents.

Claims

1. A highly efficient fund transaction monitoring and analysis system, characterized in that: include: A plurality of management nodes, each of which, after receiving the transaction information of the transaction to be analyzed, performs: based on the transaction information, filtering out a monitoring rule subset from the monitoring rule set cached in the memory; selecting an analysis node for each monitoring rule of the monitoring rule subset from the routing table of the management node in an asynchronous parallel manner and sending a transaction analysis task to the selected analysis node, and counting the analysis results returned by the plurality of selected analysis nodes to determine the transaction status of the transaction to be analyzed, wherein the parameters of the transaction analysis task include the transaction information and a monitoring rule in the monitoring rule subset; Multiple analysis nodes, each of which, after receiving a transaction analysis task, executes: constructing an aggregate query SQL statement using the parameters of the received transaction analysis task, querying a database to obtain an aggregate value through the aggregate query SQL statement, determining an analysis result based on the aggregate value, and returning the analysis result to the management node that issued the transaction analysis task; Database, storing transaction information; The database also stores a monitoring rule set. When the management node is started, the management node executes the following steps to cache the monitoring rule set in the memory: The management node loads the monitoring rule set from the database, and executes for each monitoring rule in the monitoring rule set: using the matching rule attribute of the monitoring rule to construct a complete JAVA class and compile and instantiate it, and using the compiled instantiated object as a derived attribute of the monitoring rule; wherein the matching rule attribute of the monitoring rule is represented in the form of JAVA code; The management node groups all monitoring rules in the monitoring rule set according to the transaction type attribute of the monitoring rule. Each transaction type corresponds to one group, each group contains multiple monitoring rules, and each monitoring rule corresponds to more than one group. Each monitoring rule in the database includes: monitoring rule ID: unique identifier of the monitoring rule; matching rule: expressed in JAVA code; aggregation period: any one of permanent, year, season, month, week, day, single transaction, or a dynamically expressed time interval; aggregation method: any one of the total number of transactions, total transaction amount, average transaction amount, median transaction amount, and transaction amount variance; aggregation condition: SQL statement fragment template, consisting of SQL statement and EL expression; illegal interval: a closed interval consisting of a starting value and an ending value; and associated transaction type; The management node selects a monitoring rule subset from a monitoring rule set cached in the memory based on the transaction information, including: obtaining a monitoring rule group that is adapted to the transaction type attribute of the transaction information from the cached monitoring rule set, and the adapted monitoring rule group constitutes a monitoring rule set A; traversing the monitoring rule set A, matching the monitoring rules and the transaction information by executing a matching method of the derived attributes of the monitoring rules, extracting the monitoring rules that match the transaction information, and forming the extracted monitoring rules into a monitoring rule subset B; Each management node has a routing table, which stores the service IP and port of each analysis node, the creation time, the last registration time, the network delay between the management node and the analysis node, the number of CPUs of the analysis node host server, the CPU idle rate and the free memory size; The selecting of an analysis node for each monitoring rule of the monitoring rule subset from the routing table of the management node, for monitoring rule b in the monitoring rule subset B, b∈B, comprises: Obtaining first information of each analysis node in the routing table of the management node, the first information including the network delay between the analysis node and the management node, the number of CPUs of the host server of the analysis node, the CPU idle rate and the free memory size; Calculating an evaluation score of each analysis node according to a preset first evaluation function based on the first information of each analysis node; The analysis node with the highest evaluation score is selected as the analysis node of monitoring rule b; the first evaluation function is: Where d represents the network delay between the analysis node and the management node; l represents the CPU idle rate of the host server of the analysis node, n′ represents the number of CPUs of the host server of the analysis node, and g(m) represents the normalized value of the free memory size m of the host server of the analysis node; Alternatively, in the step of selecting an analysis node for each monitoring rule of the monitoring rule subset from the routing table of the management node: selecting an analysis node for each monitoring rule in the monitoring rule subset B respectively, for monitoring rule b, b∈B, the process of selecting an analysis node is: Retrieving an analysis task log table from a database, using the analysis task log table to obtain the proportion distribution of transaction analysis tasks including monitoring rule b processed by the analysis node, and obtaining the proportion p of transaction analysis tasks including monitoring rule b processed by each analysis node according to the proportion distribution; wherein the analysis task log table includes an analysis node ID, a monitoring rule ID, and a transaction ID; The evaluation score is calculated according to the network delay between each analysis node and the management node in the routing table of the management node, the number of CPUs, the CPU idle rate and the free memory size of the host server of the analysis node, and the proportion p of transaction analysis tasks containing monitoring rule b processed by the analysis node, according to the preset second evaluation function; The analysis node with the largest evaluation score is selected as the analysis node for monitoring rule b.

2. The highly efficient fund transaction monitoring and analysis system as claimed in claim 1, characterized in that: When the analysis node is started, an analysis node daemon thread is created, and the analysis node daemon thread executes: The analysis node periodically initiates a node registration request to each management node at a first time interval. The parameters of the analysis node registration request include the service IP and port of the analysis node, the current system time of the analysis node, the number of CPUs of the analysis node host server, the CPU idle rate and the free memory size.

3. A highly efficient fund transaction monitoring and analysis system as claimed in claim 1 or 2, characterized in that: Each management node creates a routing table daemon thread when it starts, and the routing table daemon thread executes: The management node periodically traverses the routing table at a second time interval to remove abnormal analysis nodes, where the abnormal analysis nodes are analysis nodes whose most recent registration time plus a timeout time is less than or equal to the current system time of the management node.

4. The highly efficient fund transaction monitoring and analysis system as claimed in claim 3, characterized in that: The timeout period The calculation formula is: Wherein, t is the first time interval; is the average value of the network delay between the management node and each analysis node; is the error function value of the network delay between the management node and each analysis node, d i represents the network delay from the i-th analysis node in the routing table to the management node, and n represents the number of analysis nodes in the routing table of the management node, wherein, 5. A highly efficient fund transaction monitoring and analysis system as claimed in claim 1, 2 or 4, characterized in that: Multiple management nodes synchronize monitoring rules according to the following steps: Let the management node set be J, j and j′ are both management node indexes, and j≠j′, j∈J, j′∈J; When adding a new monitoring rule: each management node provides an RPC interface for adding a monitoring rule to the external system, and the external system calls the new monitoring rule interface provided by the management node j; the management node j saves the monitoring rule to be added to the database, compiles and instantiates the monitoring rule to be added, caches it in groups to the memory, and synchronizes the monitoring rule to be added to the management node j′ through the MQ cluster in a broadcast manner; After receiving the message of the monitoring rules to be added synchronized by the MQ cluster, the management node j′ compiles and instantiates the monitoring rules to be added and caches them in groups into the memory; When deleting monitoring rules: each management node provides an RPC interface for deleting monitoring rules to the external system, and the external system calls the deleting monitoring rule interface provided by management node j; The management node j deletes the monitoring rules to be deleted from the database, deletes the monitoring rules to be deleted from the monitoring rule set cached in the memory, and synchronizes the monitoring rules to be deleted to the management node j′ through the MQ cluster in a broadcast manner; After receiving the monitoring rule to be deleted message synchronized by the MQ cluster, the management node j′ deletes the monitoring rules to be deleted from the monitoring rule set cached in the memory.

Images