Business processing method and device, computer equipment, readable storage medium and program product

Abstract

The invention relates to the technical field of cloud computing, and discloses a business processing method and device, computer equipment, a readable storage medium and a program product, which can improve the business processing efficiency. The method comprises the steps that when it is determined that account detection is passed based on all first detection rules, a first detection result of an account is obtained, multiple threads are called, and the multiple parallel threads obtain detection values of the account under second detection rules according to the corresponding second detection rules; each thread is used for writing the respective detection values of the plurality of accounts obtained by the thread into a database in batches when the accumulated detection account number reaches a threshold value, and generating a detection value query index; according to each detection value query index, obtaining a detection value of the account under each second detection rule from a database, and according to each detection value, determining a second detection result of the account; and when it is determined that account detection is passed according to the first detection result and the second detection result, returning a service processing success message to the account.

Description

Technical Field

[0001] This application relates to the field of cloud computing technology, and in particular to a business processing method, apparatus, computer equipment, computer-readable storage medium, and computer program product. Background Technology

[0002] With the development of computer technology, users can conveniently apply for and process specific financial transactions online. To quickly determine whether a user is eligible for a particular transaction, a pre-set detection model can be used. This model checks the user's information based on pre-obtained rules and processes the transaction if the check is successful.

[0003] In related technologies, the detection model primarily determines whether a user meets each of the detection rules sequentially. If a user fails any rule, their request is rejected. If a user passes all rules, their business request is processed. However, this approach struggles to accurately and effectively identify user risks and anomalies. Business personnel often need to re-identify users who pass the checks, resulting in low processing efficiency. Summary of the Invention

[0004] Therefore, it is necessary to provide a business processing method, apparatus, computer equipment, computer-readable storage medium, and computer program product to address the aforementioned technical problems.

[0005] Firstly, this application provides a business processing method, including:

[0006] In response to a target business processing request from an account, if the account fails the detection based on any of the first detection rules, a business processing failure message is returned to the account.

[0007] When the account passes the detection based on the first detection rules, the first detection result of the account is obtained, and multiple threads are invoked in parallel. The multiple threads obtain the detection value of the account under the second detection rule according to their respective second detection rules. Each thread is used to write the detection values ​​of the multiple accounts obtained by the thread into the database in batches when the cumulative number of detected accounts reaches the threshold, and generate a detection value query index.

[0008] When the detection value query index generated by each thread is obtained, the detection value of the account under each of the second detection rules is obtained from the database according to the detection value query index, and the second detection result of the account is determined according to the detection value.

[0009] When the account passes the test based on the first test result and the second test result, a message indicating successful business processing is returned to the account.

[0010] In one embodiment, the step of batch writing the detection values ​​of the multiple accounts obtained by the thread into the database and generating a detection value query index includes:

[0011] At least one columnar storage file is generated based on the detection values ​​of each of the multiple accounts; each columnar storage file stores multiple detection values ​​in a columnar storage format; for each columnar storage file, an account index is generated based on the account identifier corresponding to each detection value contained in the columnar storage file; the account identifier corresponding to the detection value is the identifier of the account corresponding to the detection value; the columnar storage file is written to the database, and a detection value query index corresponding to the columnar storage file is generated based on the rule identifier of the second detection rule corresponding to the thread and the account index.

[0012] In one embodiment, the identifier order of each account identifier in the account index is determined according to the storage location of each corresponding detection value in the columnar storage file; the step of retrieving the detection value of the account under each of the second detection rules from the database based on the query index of each detection value includes: for each of the second detection rules, determining the target columnar storage file based on the rule identifier of the second detection rule, the account identifier of the account, and the detection value query index, and requesting the database to retrieve the target detection value located at the target storage location in the target columnar storage file; the target storage location is determined according to the identifier order of the account identifiers of the account; and receiving each of the target detection values ​​returned by the database.

[0013] In one embodiment, the step of having the multiple threads in parallel obtain the detection value of the account under the second detection rule according to their respective corresponding second detection rules includes: the multiple threads in parallel determining their respective corresponding first containers and sending a first acquisition request to the corresponding first container; the first acquisition request is used to trigger the acquisition of the first detection value of the account under the second detection rule using a first detection model encapsulated in the first container; the first detection model is a detection model configured for the second detection rule corresponding to the thread; when the request response time of the first container exceeds a preset threshold, the first container is determined to be abnormal and a second acquisition request is sent to the available backup container corresponding to the first container, and the detection value is obtained based on the second detection value; the first acquisition request is used to trigger the acquisition of the second detection value using the same first detection model encapsulated in the available backup container.

[0014] In one embodiment, the thread is further configured to perform the following processing: in response to an update of the second detection rule corresponding to the thread, a second container is determined; the second container encapsulates a second detection model corresponding to the updated second detection rule; a portion of the accounts to be detected are identified as gray-scale test accounts, and a third detection value of the gray-scale test accounts under the second detection rule is obtained using the second detection model encapsulated in the second container, and performance information of the second detection model is determined based on the third detection value; other accounts besides the gray-scale test accounts continue to obtain the first detection value based on the first detection model encapsulated in the first container; if the performance information of the second detection model meets a preset condition, the first container is stopped from being used and the third detection value of the subsequent accounts to be detected is obtained using the second container.

[0015] In one embodiment, determining the second detection result of the account based on each of the detection values ​​includes: determining the dynamic rule weights of each of the second detection rules; the dynamic rule weights are dynamically updated based on the abnormal account characteristics of multiple historical accounts after the target business is successfully processed; a weighted sum is performed based on each of the dynamic rule weights and the detection values ​​under each of the second detection rules, and the second detection result of the account is determined based on the weighted sum result.

[0016] Secondly, this application also provides a business processing apparatus, comprising:

[0017] The first detection module is used to respond to the target business processing request of the account, and when it is determined that the account fails the detection based on any first detection rule, it returns a business processing failure message to the account.

[0018] The second detection module is used to obtain the first detection result of the account when the account is determined to have passed the detection based on the first detection rules, and to call multiple threads in parallel to obtain the detection value of the account under the second detection rule according to their respective second detection rules; each thread is used to write the detection values ​​of the multiple accounts obtained by the thread into the database in batches when the cumulative number of detected accounts reaches a threshold, and to generate a detection value query index.

[0019] The result acquisition module is used to, when the detection value query index generated by each of the threads is obtained, retrieve the detection value of the account under each of the second detection rules from the database according to the detection value query index, and determine the second detection result of the account according to the detection value.

[0020] The business processing module is used to return a message of successful business processing to the account when it is determined that the account has passed the detection based on the first detection result and the second detection result.

[0021] Thirdly, this application also provides a computer device, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps of the method described in any of the preceding claims.

[0022] Fourthly, this application also provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of the method described in any of the preceding claims.

[0023] Fifthly, this application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of the method described in any of the preceding claims.

[0024] The aforementioned business processing method, apparatus, computer equipment, computer-readable storage medium, and computer program product, when determining that an account has passed detection based on various first detection rules, obtains the account's detection values ​​under various second detection rules and determines the second detection result based on these values, rather than determining whether an account passes detection solely based on individual second detection rules. This allows for accurate identification of account risks using multiple second detection rules, effectively improving the accuracy of account risk detection and reducing the likelihood of post-event anomalies and re-examinations. Simultaneously, the use of multi-threaded parallel acquisition of second detection rule detection values ​​significantly shortens the overall time spent on detection using various second detection rules. Furthermore, after the cumulative number of accounts detected by threads reaches a threshold, data is written to the database in batches and a query index is generated. This reduces the number of database interactions and lowers the database load; on the other hand, the index enables rapid retrieval of detection values, further improving the overall efficiency of the detection process. Therefore, this facilitates efficient and accurate identification and classification of account risks, improving business processing efficiency.

[0025] Furthermore, a columnar storage format can be used to centrally store multiple detection values ​​obtained by the thread corresponding to the same second detection rule. When querying the detection value under a specific second detection rule later, only the corresponding data column needs to be read, without reading irrelevant attribute data, thus reducing the amount of data read.

[0026] Furthermore, by using the detection value query index to accurately associate rule identifiers, account identifiers, and columnar storage files, and combining the order of account index identifiers to quickly deduce the storage location, the traversal of a large amount of irrelevant data in traditional queries is avoided, which greatly shortens the time spent locating and reading detection values. The efficiency improvement is even more significant in large-scale scenarios with multiple accounts and multiple rules.

[0027] Furthermore, when the response time of the first container exceeds a preset threshold, a second acquisition request is sent to an available backup container to obtain a second detection value using the same first detection model in the backup container. This avoids detection interruption caused by container abnormalities, ensures the continuity of account detection tasks, and reduces the probability of missed detections due to detection interruptions.

[0028] Furthermore, the second detection model can be validated only on a subset of accounts through gray-scale testing, while the first detection model is used on non-gray-scale accounts. This avoids large-scale detection errors caused by the substandard performance of the new model, ensures the reliability of the account detection service, and helps reduce the scope of loss when the second detection model malfunctions.

[0029] Furthermore, by obtaining the dynamic rule weights of each second detection rule, it can be ensured that the importance of the second detection rule changes in sync with the actual risk characteristics of the business. Compared with fixed weights, it can more accurately capture new risks and reduce the rate of missed detection of abnormal accounts. Attached Figure Description

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

[0031] Figure 1 This is a flowchart illustrating a business processing method in one embodiment;

[0032] Figure 2 This is a flowchart illustrating the steps for generating a detection value query index in one embodiment;

[0033] Figure 3 This is a flowchart illustrating the steps for obtaining target detection values ​​in one embodiment;

[0034] Figure 4 This is a flowchart illustrating the business processing method in another embodiment;

[0035] Figure 5 This is a flowchart of the scoring process for a weak validation rule model in one embodiment;

[0036] Figure 6 This is a structural block diagram of a service processing device in one embodiment;

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

[0038] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application. It should be noted that existing industry solutions such as software, components, and models may be mentioned in the embodiments of this application. These should be considered exemplary and are intended only to illustrate the feasibility of implementing the technical solutions of this application, but do not imply that the applicant has already used or necessarily used such solutions.

[0039] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties, and the collection, use and processing of related data must comply with relevant regulations. The acquisition, storage, use and processing of data in the technical solution of this application all comply with the relevant provisions of national laws and regulations.

[0040] The terms "first," "second," etc., used in this application may be used to describe various objects, but these objects are not limited by these terms. These terms are only used to distinguish the first object from the second object. The terms "comprising" and "having," and any variations thereof, used in this application, are intended to cover non-exclusive inclusion. The term "multiple" used in this application refers to two or more. The term "and / or" used in this application refers to one of the embodiments, or any combination of multiple embodiments.

[0041] In one embodiment, such as Figure 1 As shown, a business processing method is provided. This embodiment illustrates the method applied to a server. It is understood that this method can also be applied to a terminal, or to a system including both a terminal and a server, and is implemented through interaction between the terminal and the server. In this embodiment, the method includes the following steps:

[0042] S101, in response to the target business processing request of the account, when it is determined that the account detection fails based on any of the first detection rules, a business processing failure message is returned to the account.

[0043] In this context, a business processing request can refer to an account-initiated request for information regarding a target business transaction. This request can trigger a server-side account verification process. In some possible examples, a business processing request might be a request initiated for a financial transaction with a risk level exceeding a preset threshold.

[0044] The first detection rule, also known as the strong detection rule, can be understood as the basic detection rule, which is used to quickly screen accounts that have obvious risks or do not meet the basic requirements.

[0045] In practice, when the server receives a target business processing request initiated by an account, it can first trigger the detection process corresponding to the first detection rule. In this detection process, the server can invoke all preset first detection rules to perform a check on the account one by one. In one example, the first detection rules may include account status detection, basic information compliance detection, etc.

[0046] During the detection process, as long as the account fails the detection based on any of the first detection rules, the server can terminate the subsequent detection and return a business processing failure message to the account. The message may contain the reason for the request failure.

[0047] S102, when an account passes the detection based on the first detection rules, the first detection result of the account is obtained, and multiple threads are called. The multiple threads in parallel obtain the detection value of the account under the second detection rule according to their respective second detection rules. Each thread is used to write the detection values ​​of multiple accounts obtained by the thread into the database in batches when the cumulative number of detected accounts reaches the threshold, and generate a detection value query index.

[0048] The first detection result can be understood as the detection result generated after the account passes all the first detection rules. This first detection result reflects the degree to which the account matches each first detection rule, provided it meets the basic requirements of that rule. In some examples, the first detection result can be called the basic detection result, or a basic score.

[0049] The second detection rule, also known as the weak detection rule, can be understood as the deep detection rule. It is used to conduct more detailed risk or compliance checks on accounts that have passed the first detection rule.

[0050] The detection value refers to the specific quantitative result of an account under a certain second detection rule. It can be understood as a numerical value obtained after calculating a specific attribute or status of the account. For example, under the second detection rule R1, the detection value can be 5; under the second detection rule R2, the detection value can be 7.

[0051] The detection value query index is used to quickly locate the identification information of the account detection value in the database. For example, it can be a combination string generated based on the account identifier, the detection rule identifier, and the detection time. The detection value query index can be used to directly query the database the detection value of a specific account under a specific second detection rule.

[0052] The threshold refers to the critical value N of the cumulative number of accounts detected when a thread writes data to the database in batches. That is, when a thread has accumulated the detection values ​​of N accounts, it can write the detection values ​​of each of the N accounts to the database in batches.

[0053] When related technologies check whether a user meets business processing requirements, they directly reject the user's request if the user fails any of the detection rules, and process the user's business request only if the user passes all the detection rules. However, this processing method is simplistic, failing to differentiate between users who have passed the checks, making it difficult to stratify and identify user risks, and hindering the timely identification and monitoring of potential risk targets, thus affecting risk control results. Furthermore, relevant business personnel need to conduct risk checks again afterward, impacting business processing efficiency.

[0054] In this embodiment, when an account is determined to have passed the detection based on each of the first detection rules, a first detection result for that account can be generated and obtained. The first detection result is used to identify whether the account has ultimately passed the detection in conjunction with the second detection result.

[0055] Subsequently, the server can invoke multiple threads, each corresponding to a preset second detection rule. These parallel threads then obtain the account's detection value under their respective second detection rules. These multiple second detection rules can include risk detection across multiple dimensions, such as rules targeting credit, regulations, and market operations.

[0056] During operation, each thread, in addition to determining the detection value of each account under the second detection rule, can also accumulate statistics on the number of accounts detected within a preset time interval. When the cumulative number of detected accounts reaches a preset threshold, the thread can batch write the detection values ​​of these multiple accounts into a preset database, and can generate a corresponding detection value query index based on the detection information of each account.

[0057] For example, the system initiates a second detection for a batch of accounts that passed the first detection (including accounts C, D, etc.), calling three threads corresponding to three second detection rules (rule 1, rule 2, and rule 3), with a threshold set to N. After accumulating the detection values ​​of N accounts (including accounts C and D) under rule 1, thread 1 writes the detection values ​​of these N accounts into the database in batches and generates a query index for the detection values ​​of rule 1 for the N accounts. Simultaneously, after accumulating the detection values ​​of N accounts (including accounts C and D) under rule 2, thread 2 also performs the batch writing to the database and generating the query index. In some examples, the threshold for each thread can be different, and the specific threshold setting can be determined based on the thread processing performance of each thread.

[0058] S103, when the query index of the detection value generated by each thread is obtained, the detection value of the account under each second detection rule is obtained from the database according to the query index of each detection value, and the second detection result of the account is determined according to each detection value.

[0059] In practical applications, once the system obtains the query indexes for the detection values ​​generated by all threads (e.g., threads 1, 2, and 3 each generate query indexes for a specific account), for the same account, the corresponding detection value can be retrieved from the detection value database based on these indexes. For example, based on the account identifier, three query indexes corresponding to the account can be selected from the query indexes for the detection values ​​corresponding to the three second detection rules. Each query index can then be used to directly locate the corresponding detection value record in the database. Subsequently, the second detection result for the account can be determined based on each detection value. For instance, the weighted sum of the detection values ​​can be used as the second detection result for the account.

[0060] S104, when the account is determined to have passed the test based on the first test result and the second test result, a message indicating successful business processing is returned to the account.

[0061] In one embodiment, after obtaining the second detection result, the first and second detection results can be combined to obtain the target detection result. For example, the target detection result can be a detection value obtained by combining the first and second detection results; for ease of distinction, this detection value can also be referred to as the target detection value. When the target detection value exceeds a threshold, a message indicating successful business processing can be returned to the account.

[0062] In addition, in some other embodiments, different business processing strategies can be adopted to process the target business of the account according to the detection value range to which the target detection value belongs. For example, different business processing strategies can be set for different detection value ranges. After obtaining the target detection value, the corresponding target business processing strategy is determined according to the range to which the target detection value belongs, and then the target business of the account is processed using the target business processing strategy.

[0063] In this embodiment, when an account passes the detection based on the first detection rules, the second detection result is determined by acquiring the account's detection values ​​under the second detection rules, rather than solely relying on individual second detection rules to determine whether an account passes the detection. This approach leverages multiple second detection rules to achieve accurate identification of account risks, effectively improving the detection accuracy and reducing the likelihood of post-event anomalies and re-examinations. Simultaneously, the use of multi-threaded parallel acquisition of the second detection rule values ​​significantly shortens the overall time spent on detection using each rule. Furthermore, once the cumulative number of accounts detected by the threads reaches a threshold, data is written to the database in batches and a query index is generated. This reduces database interactions and load, while the index enables rapid retrieval of detection values, further improving the overall efficiency of the detection process. Therefore, this approach facilitates efficient and accurate identification and classification of account risks, enhancing business processing efficiency.

[0064] In one embodiment, such as Figure 2 As shown, in step S102, the detection values ​​of multiple accounts obtained by the thread are written to the database in batches, and a detection value query index is generated. This may include the following steps:

[0065] S201, generate at least one columnar storage file based on the detection values ​​of multiple accounts; each columnar storage file stores multiple detection values ​​in a columnar storage format.

[0066] Columnar storage file: refers to a file that organizes data using a columnar storage format. Unlike traditional row-based storage (which stores a complete piece of data in a row), columnar storage stores multiple detection values ​​corresponding to the same second detection rule in a group. For example, the detection values ​​of N accounts under rule 1 are stored in one data column, and the detection values ​​of N accounts under rule 2 are stored in another data column. This format can improve the query efficiency of detection values ​​under a specific second detection rule.

[0067] In this step, each thread can first obtain detection values ​​for multiple accounts and, based on the file size, generate one or more columnar storage files according to the detection values ​​for each account. For example, each columnar storage file can contain M detection values, where M is less than or equal to N. For instance, N detection values ​​obtained according to the processing order can be obtained, and then these N detection values ​​can be divided into M detection value sets, with a columnar storage file generated based on each detection value set.

[0068] S202, For each columnar storage file, generate an account index for the columnar storage file based on the account identifiers corresponding to each detection value contained in the columnar storage file; the account identifier corresponding to the detection value is the identifier of the account corresponding to the detection value.

[0069] The account index refers to the mapping relationship between the columnar storage file and the account identifier corresponding to the detection value therein. This index can reflect the association information between "account identifier and columnar storage file". Through the account index, the columnar storage file where the detection value of a specific account is located can be quickly located.

[0070] In the specific implementation, for each columnar storage file generated in step S201, all detection values ​​in the file can be traversed first to extract the account identifier corresponding to the account associated with each detection value. Then, the traversed account identifiers can be organized into a structured account index. For example, the account identifiers can be concatenated, or an account index can be generated in the form of a table, key-value pair, or database table to ensure that the columnar storage file where the corresponding detection value is located can be quickly queried through the account identifier.

[0071] S203: Write the columnar storage file to the database, and generate a query index for the detection value corresponding to the columnar storage file based on the rule identifier and account index of the second detection rule corresponding to the thread.

[0072] In some embodiments, on the one hand, the columnar storage files generated in step S201 can be written to the corresponding database according to the database's storage specifications, ensuring that the columnar storage format within the files remains unchanged after writing and is compatible with the database's storage structure. On the other hand, the thread can determine the second detection rule corresponding to the thread and obtain the rule identifier corresponding to the second detection rule. Then, the rule identifier can be associated with the account index generated in step S202 to establish a mapping relationship of "rule identifier - account index - columnar storage file location," generating a detection value query index. This allows the target data to be directly located through the query index when querying detection values ​​based on the detection rule.

[0073] In this embodiment, on the one hand, a columnar storage format can be used to centrally store multiple detection values ​​corresponding to the same second detection rule obtained by the thread. When querying the detection value under a specific second detection rule, only the corresponding data column needs to be read, without reading irrelevant attribute data, thus reducing the amount of data read. On the other hand, the account index can help to quickly locate the detection value of a specific account, avoiding traversing the entire columnar storage file. Finally, by binding the detection rule with the account index, a detection value query index is formed, enabling rule-based queries to directly locate the target data. The three aspects work together to significantly improve the storage efficiency of detection values ​​and the query response speed.

[0074] In one embodiment, the identifier order of each account identifier in the account index can be determined based on the storage location of the corresponding detection value in the columnar storage file. Specifically, for each account, its corresponding detection value can be stored in a specific storage location in the columnar storage file, and the arrangement order of multiple account identifiers in the account index is consistent with the storage location order of the detection values ​​of these accounts in the corresponding columnar storage file. In an exemplary embodiment, assume there are 3 accounts with account identifiers "10001", "10002", and "10003", corresponding to detection values ​​of 85, 62, and 91, respectively, and these detection values ​​are stored in the second, fifth, and eighth positions in a certain columnar storage file, respectively. In this case, the identifier order of these 3 account identifiers in the account index is the second, fifth, and eighth, respectively, corresponding to the storage location order of the detection values ​​2→5→8. In a specific implementation, after generating the columnar storage file, the storage location of each detection value can be read, and then the account identifiers can be sorted according to the order of their storage locations, thereby updating the identifier order of the account index to ensure consistency between the index order and the storage location order.

[0075] Accordingly, such as Figure 3 As shown, in step S103, retrieving the account's detection value under each second detection rule from the database based on the query index of each detection value may include the following steps:

[0076] S301, for each second detection rule, determine the target columnar storage file based on the rule identifier of the second detection rule, the account identifier of the account, and the detection value query index, and request the database to obtain the target detection value located at the target storage location in the target columnar storage file; the target storage location is determined according to the identifier order of the account identifier.

[0077] In specific implementation, after obtaining the detection value query index, for each second detection rule to be queried, the rule identifier of the rule (e.g., "R001" represents rule 1 among multiple second detection rules) is first obtained, and then combined with the account identifier of the account to be queried (e.g., "10002"), a "rule identifier - account identifier" combination information (e.g., "R001-10002") is constructed. Subsequently, based on the matching result of the combination information and the detection value query index, the columnar storage file that contains the specified account identifier in the account index and corresponds to the specific second detection rule is determined; this file is the target columnar storage file. In some embodiments, the detection value query index can be stored in a cache database such as Redis to improve the query speed of the combination information and ensure the rapid location of the target columnar storage file.

[0078] After determining the target columnar storage file, the target storage location can be determined based on the identifier order of the account identifiers. Specifically, the identifier order of the account identifier to be queried can be queried from the account index first. Then, according to the preset location mapping relationship and the identifier order of the account identifiers, the storage location of the detection value corresponding to that account identifier in the target columnar storage file can be determined, thus obtaining the target storage location. Subsequently, a data request is sent to the database to retrieve the target detection value located at the target storage location in the target columnar storage file.

[0079] S302, Receive the target detection values ​​returned by the database.

[0080] After receiving a request to retrieve a detection value, the database can read the corresponding detection value based on the file identifier and target storage location of the target columnar storage file in the request, and return this detection value as the target detection value to the requesting end. Upon receiving the target detection value returned by the database, the requesting end can use it as the detection value for the account for which the second detection result is to be obtained under the corresponding second detection rule.

[0081] In this embodiment, the precise association between the rule identifier, account identifier, and columnar storage file is achieved by querying the detection value index. Combined with the rapid deduction of the storage location by the order of the account index identifier, the traversal of a large amount of irrelevant data in traditional queries is avoided, which greatly shortens the time spent locating and reading the detection value. The efficiency improvement is even more significant in large-scale scenarios with multiple accounts and multiple rules.

[0082] In one embodiment, step S102, in which multiple threads in parallel obtain the detection value of the account under the second detection rule according to their respective second detection rules, may include:

[0083] S1021, multiple parallel threads determine their respective first containers and send a first acquisition request to the corresponding first container; the first acquisition request is used to trigger the acquisition of the first detection value of the account under the second detection rule using the first detection model encapsulated in the first container; the first detection model is a detection model configured for the second detection rule corresponding to the thread.

[0084] In this context, multiple parallel threads can be understood as independent task units that are created and run simultaneously by the server. Each thread can be responsible for only processing the detection value calculation task corresponding to the second detection rule it is bound to, thus avoiding resource contention between tasks.

[0085] The first container can refer to an environment unit created based on containerization technology, used to isolate and run a specific detection model. It has the characteristics of independent resource allocation and strong environment consistency. Each first container can encapsulate a first detection model corresponding to a thread. The first detection model refers to the algorithm model set up to match a specific second detection rule.

[0086] In practical implementation, a corresponding first detection model can be set for each second detection rule, and it can be encapsulated in a first container and a corresponding backup container. For example, multiple second detection rules may include credit detection rules, regulatory detection rules, market operation activity detection rules, and environmental protection detection rules. For the above four second detection rules, the following four first detection models can be configured respectively: F1, F2, F3, and F4, thereby obtaining the first detection value of each of the four second detection rules, namely, the credit detection scoring index, the regulatory detection scoring index, the market operation activity detection rule scoring index, and the environmental protection detection rule scoring index. Specifically, it can be as follows:

[0087]

[0088]

[0089]

[0090]

[0091] in, Let i be the scoring index for the i-th credit detection rule. Let be the scoring index for the i-th regulatory testing rule. For the i-th market operation activity detection rule scoring index, This is the scoring index for the i-th environmental protection testing rule; Let be the parameters of the scoring index model for the i-th credit scoring rule (i.e., the detection model corresponding to the credit scoring rule). Let be the parameters of the scoring index model for the i-th regulatory testing rule (i.e., the testing model corresponding to the regulatory testing rule). Let be the parameters of the scoring index model for the i-th market operation activity detection rule (i.e., the detection model corresponding to the market operation activity detection rule). represents the parameters of the scoring index model for the i-th environmental protection testing rule (i.e., the testing model corresponding to the environmental protection testing rule).

[0092] Furthermore, once it is determined that the account meets all the first detection rules, multiple threads can be invoked in parallel. Each thread can query the first container that matches the second detection rule bound to it and send a first retrieval request to the first container. When the first container receives the first retrieval request, it can call the internally encapsulated first detection model to process the data contained in the first retrieval request and output the first detection value.

[0093] S1022, when the request response time of the first container exceeds a preset threshold, the first container is determined to be abnormal and a second acquisition request is sent to the available backup container corresponding to the first container, and the detection value is obtained based on the second detection value; the first acquisition request is used to trigger the acquisition of the second detection value using the same first detection model encapsulated in the available backup container.

[0094] The request response time can refer to the time interval from when the thread sends the first request to when it receives the first detection value returned by the first container. The preset threshold is an upper limit for the request response time set in advance according to performance requirements. When this threshold is exceeded, it can be determined that the container cannot respond normally.

[0095] The backup container can be a redundant container that is in an available state and has the same configuration as the first container (including the same operating system environment, dependent libraries, and first detection model), and can take over the detection task when the first container fails.

[0096] In specific implementation, when a thread detects that the response time of the first container exceeds a preset threshold, it can immediately determine the available backup container corresponding to the first container and send a second retrieval request to that backup container. For example, the content of the second retrieval request can be the same as that of the first retrieval request. After receiving the second retrieval request, the available backup container can call the same internal first detection model to process the data and output a second detection value. The thread then uses this second detection value as the final detection value under the corresponding second detection rule.

[0097] In this embodiment, on the one hand, by encapsulating the first detection model configured for the second detection rule in the first container, the model's runtime environment is isolated, avoiding runtime anomalies caused by dependency library version conflicts and resource contention between different models. This ensures that the detection logic corresponding to each second detection rule can be executed stably, reducing deviations in detection results caused by environmental issues. On the other hand, when the response time of the first container exceeds a preset threshold, a second acquisition request is sent to an available backup container to obtain the second detection value using the same first detection model in the backup container. This avoids detection interruptions caused by container anomalies, ensuring the continuity of account detection tasks and reducing the probability of missed detections due to detection interruptions.

[0098] In one embodiment, the aforementioned threads may also perform the following processing:

[0099] In response to an update to the second detection rule corresponding to a thread, a second container is determined; the second container encapsulates a second detection model corresponding to the updated second detection rule; a portion of the accounts currently to be detected are identified as gray-scale test accounts, and the third detection value of the gray-scale test accounts under the second detection rule is obtained using the second detection model encapsulated in the second container, and the performance information of the second detection model is determined based on the third detection value; other accounts besides the gray-scale test accounts continue to obtain the first detection value based on the first detection model encapsulated in the first container; if the performance information of the second detection model meets preset conditions, the first container is stopped and the third detection value of the accounts to be detected subsequently is obtained using the second container.

[0100] The second container refers to an independent operating environment created based on containerization technology. The container encapsulates the dependency libraries, configuration files and the second detection model itself required for the updated detection model (i.e., the second detection model) to run, enabling isolated deployment and rapid start-up and shutdown of the detection model.

[0101] Among them, gray-scale test accounts refer to a portion of the accounts selected from the accounts to be tested, used to verify the performance of the second detection model. Their number or proportion can be set according to actual needs to ensure that the test results are representative.

[0102] Here, performance information refers to metrics used to evaluate the effectiveness of the second detection model, which may, for example, include one or more metrics such as accuracy, recall, and false positive rate. Preset conditions may refer to pre-defined performance criteria for determining whether the second detection model is usable.

[0103] In practice, the second detection rule can be updated, and the corresponding detection model can be updated accordingly. After the second detection rule is updated, the creation process of the second container can be automatically triggered. For example, the containerization management module can be called to create the second container, and the second detection model trained based on the updated second detection rule and its configuration files (such as model weight files and feature mapping tables) can be encapsulated in the second container to complete the initialization of the second container.

[0104] Then, a set of accounts to be tested within the current testing period can be obtained, and gray-scale test accounts can be filtered from this set using a preset selection strategy. For example, the selection strategy may include random selection, stratified selection, etc., wherein stratified selection can be based on the key attributes of the accounts to ensure that all types of accounts are distributed in the gray-scale test accounts, avoiding bias in the test results.

[0105] Then, the account data of the gray-scale test accounts can be sent to the second container. After receiving the data, the second detection model in the second container performs feature extraction and calculation according to the updated second detection rules, and outputs a third detection value for each gray-scale test account based on the model algorithm. Subsequently, reference detection values ​​for the gray-scale test accounts can be obtained through manual calculation and review. The third detection value is compared with the reference detection value to calculate the performance information of the second detection model. At the same time, while the second detection model is conducting gray-scale testing, in order to avoid the unknown performance of the new model affecting the overall account detection, the original detection process can still be used for non-gray-scale test accounts. That is, the account data of non-gray-scale test accounts can be sent to the first container. The first detection model completes feature calculation and detection according to the first detection rules and outputs a first detection value for each non-gray-scale test account.

[0106] Subsequently, the performance information of the second detection model can be compared with preset conditions. If all performance indicators meet the preset conditions, the second detection model is deemed usable. At this point, a command can be sent to stop the first container, thereby releasing the computing resources occupied by the first container, such as CPU and memory, and redirecting all accounts to be detected in subsequent detection cycles to the second container. After receiving the account data of the subsequent accounts to be detected, the second container calls the second detection model to output a third detection value, and completes the calculation of the account detection value based on the third detection value.

[0107] In this embodiment, the second detection model can be validated only on a subset of accounts through gray-scale testing, while the first detection model is used for non-gray-scale accounts. This avoids large-scale detection errors caused by the new model's substandard performance, ensuring the reliability of the account detection service and helping to reduce the scope of loss when the second detection model malfunctions. Simultaneously, containerized deployment enables the parallel operation of the old and new models, without interrupting the overall detection process during updates. This solves the detection vacuum caused by traditional service downtime updates, ensuring that accounts to be detected in each detection cycle are processed promptly.

[0108] In one embodiment, determining the second detection result of the account based on the various detection values ​​in step S103 may include the following steps:

[0109] Determine the dynamic rule weights for each of the second detection rules; the dynamic rule weights are dynamically updated based on the abnormal account characteristics of multiple historical accounts after the target business is successfully processed; perform a weighted summation based on the dynamic rule weights and the detection values ​​under each of the second detection rules, and determine the second detection result of the account based on the weighted summation result.

[0110] In this context, dynamic rule weights refer to the importance coefficients that can be adjusted in real time and assigned to each second detection rule based on changes in the actual risk characteristics of the business. The larger the weight value, the greater the influence of that rule on the judgment of abnormal account risks. In the specific implementation, the sum of the weights of multiple dynamic rules is 1.

[0111] Here, "historical accounts" refers to accounts that have completed business processing in the target business. The abnormal account characteristics after successful business processing can be understood as the characteristic performance corresponding to the second detection rule when some historical accounts are confirmed as abnormal accounts based on their subsequent behavior after completing business processing.

[0112] In practical applications, before determining the dynamic rule weights, account detection can be performed based on each of the second detection rules, and multiple historical accounts that have completed the corresponding target business processing can be identified. Then, based on the business data and risk characteristics of the historical accounts, the dynamic weights corresponding to each of the second detection rules can be calculated and determined to ensure that the weight allocation matches the actual risk distribution of the current business.

[0113] In some embodiments, abnormal behavior information of all historical accounts within a past statistical period can be extracted from the business database at preset time intervals. The characteristic distribution of abnormal accounts within the period can be analyzed based on the abnormal behavior information. The contribution of each second detection rule to the identification of abnormal accounts can be calculated. Then, the dynamic weight of each second detection rule can be adjusted based on the change in contribution to achieve dynamic updating of the weight.

[0114] For example, within the y-th update cycle, extracting historical account data from the past 7 days reveals that the proportion of abnormal accounts triggering the second detection rule C increases from 25% to 45%, the proportion triggering the second detection rule B decreases from 40% to 25%, and the proportion triggering the second detection rule A remains unchanged. At this point, the weights can be recalculated using the risk contribution model, ultimately determining the updated weights as follows: Rule A = 0.3, Rule B = 0.25, and Rule C = 0.45.

[0115] Furthermore, for the obtained unified account's detection values ​​under each of the second detection rules, each detection value can be multiplied by the dynamic rule weight of the second detection rule, and the sum can be obtained to get the total score. This total score is then used as the account's second detection result.

[0116] For example, the second test result can be determined in the following way:

[0117] Second test result = Credit scoring index (based on credit scoring rules) Dynamic rule weight 1 + regulatory detection rule scoring index Dynamic rule weight 2 + market operation activity detection rule scoring index Dynamic rule weight 3 + environmental monitoring rule scoring index Dynamic rule weight 4.

[0118] Accordingly, the target detection value = first detection result + second detection result.

[0119] In this embodiment, by obtaining the dynamic rule weights of each second detection rule, it can be ensured that the importance of the second detection rule changes synchronously with the actual risk characteristics of the business. Compared with fixed weights, it can more accurately capture new risks and reduce the false negative rate of abnormal accounts.

[0120] To enable those skilled in the art to better understand this application, an exemplary application scenario is provided below. However, it should be understood that the embodiments of this application are not limited thereto. In the following text, a resource application in a financial business scenario will be used as an example for illustration.

[0121] In related technologies, when using detection models to determine whether to provide a user with the requested resource, the detection model mainly checks whether the user meets each of the detection rules sequentially. If the user fails any detection rule, the request is directly rejected; if the user meets all detection rules, the business request is processed. However, this business processing method is difficult to accurately and effectively identify user risks and anomalies, which can easily lead to an increased failure rate for some resource requests. Business personnel often need to re-identify users who have passed the checks, resulting in low business processing efficiency.

[0122] In this embodiment, a resource application admission method based on a strong / weak rule detection model is provided, the process of which can be combined with... Figure 4 By understanding the flowchart shown, this method can make orderly and accurate access judgments on resource applications of each account, so as to effectively identify and control the risks of resource applications.

[0123] When an account submits a resource request, the account and its identity information must first be screened against a blacklist. If the account is found to be on a pre-defined blacklist, the resource request is rejected immediately and will not proceed to further review. If the screening confirms that the account is not on the blacklist, the blacklist check is passed, and the request proceeds to the next stage of access rule verification to further assess the compliance and feasibility of the resource request.

[0124] The access rule verification process is divided into two levels: strong verification rule verification (i.e., the first detection rule) and weak verification rule verification (i.e., the second detection rule). Strong verification rules are the hard standards for resource applications, and their verification results play a decisive role in the initial screening of resource applications. During the strong verification rule verification process, the account's resource application is reviewed based on multiple preset strong verification rules. If the account's resource application fails to meet any one of the strong verification rules, i.e., the strong verification rule verification fails, the application is determined to not meet the basic access requirements, and the system will directly reject its resource application.

[0125] If an account's resource request successfully passes all strong validation rules, it can proceed to the weak validation rule check stage. In this stage, each weak validation rule can be checked one by one according to a pre-defined list. Unlike the strong validation rule processing, during the weak validation rule check, regardless of whether a weak validation rule passes or fails, the server will fully record the corresponding metric value for that weak validation rule.

[0126] like Figure 5 As shown, in the resource application admission method based on a strong / weak rule detection model provided in this application, to detect weak validation rules for accounts, a weak validation admission rule set data source can first be obtained. This data source serves as the basic input for the subsequent scoring process. Its acquisition can be accomplished by establishing a communication connection between the system and a preset data storage module. Alternatively, it can be achieved by receiving datasets transmitted from external devices. This ensures the integrity and accuracy of the data source, providing reliable data support for subsequent rule traversal and indicator calculation.

[0127] After acquiring the data source for the weak validation admission rule set, the system can iterate through each rule in the set, recording the results of each rule's execution metrics during the process. For example, during iteration, the system can execute each weak validation admission rule sequentially according to a preset rule order. For each rule's corresponding execution metrics (such as rule matching degree, rule execution time, etc.), the system can collect and store the corresponding execution result data, ensuring that complete metric execution information can be directly accessed during subsequent scoring calculations, avoiding data gaps that could affect scoring accuracy.

[0128] After obtaining the execution results of each weak validation admission rule, the score value corresponding to each indicator will be calculated based on the weak validation indicator and its model. Specifically, based on a preset weak validation indicator scoring model, the execution result data of each indicator can be substituted into the corresponding calculation logic in the model. For example, for quantitative indicators, the indicator execution result can be converted into a corresponding score through a set numerical mapping algorithm; for qualitative indicators, the corresponding scoring level can be determined through a preset level judgment standard and converted into a specific score value, thereby obtaining an independent score value for each weak validation indicator. In some embodiments, multiple threads can be invoked, and the detection model encapsulated in the threads and their corresponding containers can be used to obtain an independent score value for each weak validation indicator.

[0129] Finally, the final weak validation rule score is calculated based on the weak validation rule model. In one embodiment, the scores of each indicator obtained in the preceding steps can be weighted and summed according to a pre-determined or dynamically updated weight allocation scheme in the weak validation rule model. Alternatively, the scores of each indicator can be fused and calculated using a comprehensive evaluation algorithm set in the model to obtain a final score that reflects the overall situation of the weak validation admission rule set. This score can be used as a basis for subsequent determination of whether the target object meets the weak validation admission conditions.

[0130] After completing the inspection and recording of all weak validation rules, the server can call the pre-built rule models to calculate the rule indicator score (i.e., detection value) for each weak validation rule based on the recorded indicator values. After obtaining the rule indicator scores for each weak validation rule, the server can summarize and calculate these individual rule indicator scores according to a preset scoring aggregation algorithm to obtain the total score for the weak validation rules.

[0131] Finally, the system will compare the calculated total score with the preset score threshold. If the total score reaches or exceeds the preset score threshold, the resource application will be accepted; if the total score does not reach the preset score threshold, the resource application will not be accepted.

[0132] In this application embodiment, a strong-weak rule scoring model for access detection is proposed as an access indicator for resource application, enriching the access rule model. This model enables hierarchical identification of users. In this application, this model can further identify potential risk users and trusted users, which is beneficial for user information management and improves business processing efficiency. Furthermore, by identifying potential risk users and strengthening risk prevention measures for potential risk customers, the business failure rate can be further reduced.

[0133] It should be understood that although the steps in the flowcharts of the embodiments described above are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowcharts of the embodiments described above may include multiple steps or multiple stages. These steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the steps or stages in other steps. It is understood that the steps in different embodiments can be freely combined as needed, and all non-contradictory solutions formed by such combinations are within the scope of protection of this application.

[0134] Based on the same inventive concept, this application also provides a business processing apparatus for implementing the business processing method described above. The solution provided by this apparatus is similar to the implementation scheme described in the above method; therefore, the specific limitations in one or more business processing apparatus embodiments provided below can be found in the limitations of the business processing method described above, and will not be repeated here.

[0135] In one exemplary embodiment, such as Figure 6 As shown, a business processing apparatus is provided, including:

[0136] The first detection module 601 is used to respond to the target business processing request of the account, and when it is determined that the account fails the detection based on any first detection rule, it returns a business processing failure message to the account.

[0137] The second detection module 602 is used to obtain the first detection result of the account when the account is determined to have passed the detection based on the first detection rules, and to call multiple threads in parallel to obtain the detection value of the account under the second detection rule according to their respective second detection rules; each thread is used to write the detection values ​​of the multiple accounts obtained by the thread into the database in batches when the cumulative number of detected accounts reaches a threshold, and to generate a detection value query index.

[0138] The result acquisition module 603 is used to, when the detection value query index generated by each of the threads is obtained, retrieve the detection value of the account under each of the second detection rules from the database according to the detection value query index, and determine the second detection result of the account according to the detection value.

[0139] The business processing module 604 is used to return a message of successful business processing to the account when it is determined that the account has passed the detection based on the first detection result and the second detection result.

[0140] In one embodiment, the second detection module 602 is configured to: generate at least one columnar storage file based on the detection values ​​of each of the plurality of accounts; each columnar storage file stores a plurality of detection values ​​in a columnar storage format; for each columnar storage file, generate an account index for the columnar storage file based on the account identifier corresponding to each detection value contained in the columnar storage file; the account identifier corresponding to the detection value is the identifier of the account corresponding to the detection value; write the columnar storage file into the database, and generate a detection value query index corresponding to the columnar storage file based on the rule identifier of the second detection rule corresponding to the thread and the account index.

[0141] In one embodiment, the identifier order of each account identifier in the account index is determined according to the storage location of the corresponding detection values ​​in the columnar storage file; the result acquisition module 603 is configured to: for each of the second detection rules, query the index according to the rule identifier of the second detection rule, the account identifier of the account, and the detection value to determine the target columnar storage file, and request the database to obtain the target detection value located at the target storage location in the target columnar storage file; the target storage location is determined according to the identifier order of the account identifiers of the account; and receive each of the target detection values ​​returned by the database.

[0142] In one embodiment, the second detection module 602 is configured to: determine a first container corresponding to each of the multiple threads in parallel and send a first acquisition request to the corresponding first container; the first acquisition request is used to trigger the acquisition of a first detection value of the account under the second detection rule using a first detection model encapsulated in the first container; the first detection model is a detection model configured for the second detection rule corresponding to the thread; when the request response time of the first container exceeds a preset threshold, determine that the first container is abnormal and send a second acquisition request to an available backup container corresponding to the first container, and obtain the detection value based on the second detection value; the first acquisition request is used to trigger the acquisition of the second detection value using the same first detection model encapsulated in the available backup container.

[0143] In one embodiment, the second detection module 602 is further configured to: determine a second container in response to an update of the second detection rule corresponding to the thread; the second container encapsulates a second detection model corresponding to the updated second detection rule; determine a portion of the accounts to be detected as gray-scale test accounts, obtain a third detection value of the gray-scale test accounts under the second detection rule using the second detection model encapsulated in the second container, and determine the performance information of the second detection model based on the third detection value; other accounts besides the gray-scale test accounts continue to obtain the first detection value based on the first detection model encapsulated in the first container; when the performance information of the second detection model meets a preset condition, stop using the first container and obtain the third detection value of the subsequent accounts to be detected using the second container.

[0144] In one embodiment, the result acquisition module 603 is configured to: determine the dynamic rule weights of each of the second detection rules; dynamically update the dynamic rule weights based on the abnormal account characteristics of multiple historical accounts after the target business is successfully processed; perform a weighted summation based on each of the dynamic rule weights and the detection values ​​under each of the second detection rules, and determine the second detection result of the account based on the weighted summation result.

[0145] Each module in the aforementioned business processing device can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in or independent of the processor in a computer device in hardware form, or stored in the memory of a computer device in software form, so that the processor can call and execute the operations corresponding to each module.

[0146] In one exemplary embodiment, a computer device is provided, which may be a server, and its internal structure diagram may be as follows: Figure 7 As shown, this computer device includes a processor, memory, input / output interfaces (I / O), and a communication interface. The processor, memory, and I / O interfaces are connected via a system bus, and the communication interface is also connected to the system bus via the I / O interfaces. The processor provides computing and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system, computer programs, and a database. The internal memory provides the environment for the operation of the operating system and computer programs stored in the non-volatile storage media. The database stores account data. The I / O interfaces are used for exchanging information between the processor and external devices. The communication interface is used for communicating with external terminals via a network connection. The computer program, executed by the processor, can implement a business processing method.

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

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

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

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

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

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

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

Claims

1. A business processing method, characterized in that, The method includes: In response to a target business processing request from an account, if the account fails the detection based on any of the first detection rules, a business processing failure message is returned to the account. When the account passes the detection based on the first detection rules, the first detection result of the account is obtained, and multiple threads are invoked in parallel. The multiple threads obtain the detection value of the account under the second detection rule according to their respective second detection rules. Each thread is used to write the detection values ​​of the multiple accounts obtained by the thread into the database in batches when the cumulative number of detected accounts reaches the threshold, and generate a detection value query index. When the detection value query index generated by each thread is obtained, the detection value of the account under each of the second detection rules is obtained from the database according to the detection value query index, and the second detection result of the account is determined according to the detection value. When the account passes the test based on the first test result and the second test result, a message indicating successful business processing is returned to the account.

2. The method according to claim 1, characterized in that, The step of batch writing the detection values ​​of multiple accounts obtained by the thread into the database and generating a detection value query index includes: At least one columnar storage file is generated based on the detection values ​​of each of the multiple accounts; each columnar storage file stores multiple detection values ​​in a columnar storage format; For each columnar storage file, an account index is generated based on the account identifier corresponding to each detection value contained in the columnar storage file; the account identifier corresponding to the detection value is the identifier of the account corresponding to the detection value. The columnar storage file is written to the database, and a query index for the detection value corresponding to the columnar storage file is generated based on the rule identifier of the second detection rule corresponding to the thread and the account index.

3. The method according to claim 2, characterized in that, The order of the account identifiers in the account index is determined according to the storage location of the corresponding detection values ​​in the columnar storage file. The step of retrieving the detection value of the account under each of the second detection rules from the database based on the query index of each detection value includes: For each of the second detection rules, a target columnar storage file is determined based on the rule identifier of the second detection rule, the account identifier of the account, and the detection value query index. The database is then requested to retrieve the target detection value located at the target storage location in the target columnar storage file. The target storage location is determined according to the identifier order of the account identifiers of the account. Receive the target detection values ​​returned by the database.

4. The method according to claim 1, characterized in that, The process of having multiple threads in parallel obtain the detection value of the account under the second detection rule according to their respective second detection rules includes: The multiple threads in parallel determine their respective first containers and send a first acquisition request to the corresponding first container; the first acquisition request is used to trigger the acquisition of the first detection value of the account under the second detection rule using the first detection model encapsulated in the first container; the first detection model is a detection model configured for the second detection rule corresponding to the thread; When the request response time of the first container exceeds a preset threshold, the first container is determined to be abnormal and a second acquisition request is sent to the available backup container corresponding to the first container, and the detection value is obtained based on the second detection value; the first acquisition request is used to trigger the acquisition of the second detection value using the same first detection model encapsulated in the available backup container.

5. The method according to claim 4, characterized in that, The thread is also used to perform the following processing: In response to the update of the second detection rule corresponding to the thread, a second container is determined; the second container encapsulates the second detection model corresponding to the updated second detection rule; From the accounts currently to be detected, a portion are identified as gray-scale test accounts. The third detection value of the gray-scale test accounts under the second detection rule is obtained using the second detection model encapsulated in the second container. The performance information of the second detection model is determined based on the third detection value. Other accounts besides the gray-scale test accounts continue to obtain the first detection value based on the first detection model encapsulated in the first container. If the performance information of the second detection model meets the preset conditions, the first container is stopped and the third detection value of the account to be detected is obtained using the second container.

6. The method according to any one of claims 1 to 5, characterized in that, The step of determining the second detection result of the account based on each of the detection values ​​includes: Determine the dynamic rule weights for each of the second detection rules; the dynamic rule weights are dynamically updated based on the abnormal account characteristics of multiple historical accounts after the target business is successfully processed; Based on the weights of each dynamic rule and the detection values ​​under each of the second detection rules, a weighted sum is performed, and the second detection result of the account is determined based on the weighted sum result.

7. A business processing apparatus, characterized in that, The device includes: The first detection module is used to respond to the target business processing request of the account, and when it is determined that the account fails the detection based on any first detection rule, it returns a business processing failure message to the account. The second detection module is used to obtain the first detection result of the account when the account is determined to have passed the detection based on the first detection rules, and to call multiple threads in parallel to obtain the detection value of the account under the second detection rule according to their respective second detection rules; each thread is used to write the detection values ​​of the multiple accounts obtained by the thread into the database in batches when the cumulative number of detected accounts reaches a threshold, and to generate a detection value query index. The result acquisition module is used to, when the detection value query index generated by each of the threads is obtained, retrieve the detection value of the account under each of the second detection rules from the database according to the detection value query index, and determine the second detection result of the account according to the detection value. The business processing module is used to return a message of successful business processing to the account when it is determined that the account has passed the detection based on the first detection result and the second detection result.

8. The apparatus according to claim 7, characterized in that, The second detection module is used for: At least one columnar storage file is generated based on the detection values ​​of each of the multiple accounts; each columnar storage file stores multiple detection values ​​in a columnar storage format; For each columnar storage file, an account index is generated based on the account identifier corresponding to each detection value contained in the columnar storage file; the account identifier corresponding to the detection value is the identifier of the account corresponding to the detection value. The columnar storage file is written to the database, and a query index for the detection value corresponding to the columnar storage file is generated based on the rule identifier of the second detection rule corresponding to the thread and the account index.

9. The apparatus according to claim 8, characterized in that, The order of the account identifiers in the account index is determined according to the storage location of the corresponding detection values ​​in the columnar storage file. The result acquisition module is used for: For each of the second detection rules, the target columnar storage file is determined based on the rule identifier of the second detection rule, the account identifier of the account, and the detection value query index, and the database is requested to obtain the target detection value located at the target storage location in the target columnar storage file; The target storage location is determined according to the identifier order of the account identifier of the account; Receive the target detection values ​​returned by the database.

10. The apparatus according to claim 7, characterized in that, The second detection module is used for: The multiple threads in parallel determine their respective first containers and send a first acquisition request to the corresponding first container; the first acquisition request is used to trigger the acquisition of the first detection value of the account under the second detection rule using the first detection model encapsulated in the first container; The first detection model is a detection model configured for the second detection rule corresponding to the thread; When the request response time of the first container exceeds a preset threshold, the first container is determined to be abnormal and a second acquisition request is sent to the available backup container corresponding to the first container, and the detection value is obtained based on the second detection value; the first acquisition request is used to trigger the acquisition of the second detection value using the same first detection model encapsulated in the available backup container.

11. The apparatus according to claim 10, characterized in that, The second detection module is also used for: In response to the update of the second detection rule corresponding to the thread, a second container is determined; the second container encapsulates the second detection model corresponding to the updated second detection rule; From the accounts currently to be detected, a portion are identified as gray-scale test accounts. The third detection value of the gray-scale test accounts under the second detection rule is obtained using the second detection model encapsulated in the second container. The performance information of the second detection model is determined based on the third detection value. Other accounts besides the gray-scale test accounts continue to obtain the first detection value based on the first detection model encapsulated in the first container. If the performance information of the second detection model meets the preset conditions, the first container is stopped and the third detection value of the account to be detected is obtained using the second container.

12. The apparatus according to any one of claims 7 to 11, characterized in that, The result acquisition module is used for: Determine the dynamic rule weights for each of the second detection rules; the dynamic rule weights are dynamically updated based on the abnormal account characteristics of multiple historical accounts after the target business is successfully processed; Based on the weights of each dynamic rule and the detection values ​​under each of the second detection rules, a weighted sum is performed, and the second detection result of the account is determined based on the weighted sum result.

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

14. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 6.

15. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 6.

Images