Business request processing method, apparatus, device, storage medium, and program product

Abstract

The application provides a service request processing method, device and equipment, a storage medium and a program product, and relates to the technical field of data processing. The method comprises the following steps: determining a first risk control list from a first storage medium, the first risk control list being used to determine the risk situation of different service requests, and the first storage medium being used to store the risk control list corresponding to a distributed system; generating a first identification result corresponding to a service request based on the first risk control list, the first identification result being used to represent whether a first node processes the service request; in the case that the identification result represents that the service request is processed, determining a first processing strategy identifier corresponding to the service request from a second storage medium, the second storage medium being used to store the processing strategy corresponding to the distributed system; obtaining a first processing strategy based on the first processing strategy identifier, and processing the service request based on the first processing strategy. The application can improve the security of service data.

Description

Technical Field

[0001] This invention relates to the field of data processing technology, specifically to a business request processing method, apparatus, device, storage medium, and program product. Background Technology

[0002] Security is a key concern when processing business requests. Current technologies employ risk control lists and processing policies on servers. The risk control list determines whether a business request needs processing, and the processing policy determines how to handle it, thus improving security during request processing. However, in current technologies, both the risk control list and processing policies are stored locally on the server node. This poses a risk of simultaneous leakage of both, allowing attackers to exploit this information to attack the server, resulting in low security for business data.

[0003] It is evident that existing technologies suffer from low security for business data. Summary of the Invention

[0004] This invention provides a business request processing method, apparatus, device, storage medium, and program product to address the problem of low security of business data in the prior art.

[0005] To solve the above problems, the present invention is implemented as follows: In a first aspect, embodiments of the present invention provide a service request processing method, including: A first risk control list is determined from a first storage medium. The first risk control list is used to determine the risk status of different business requests. The first storage medium is used to store the risk control list corresponding to the distributed system. The distributed system includes multiple nodes, including the first node. The node where the first storage medium is located and the first node are different nodes. A first identification result is generated based on the first risk control list to correspond to the business request. The first identification result is used to characterize whether the first node processes the business request. When the identification result indicates that the service request is being processed, a first processing strategy identifier corresponding to the service request is determined from the second storage medium. The second storage medium is used to store the processing strategy identifier of the distributed system, and the node where the second storage medium is located is a different node from the first node. The first processing strategy is obtained based on the first processing strategy identifier, and the business request is processed based on the first processing strategy.

[0006] Secondly, embodiments of the present invention also provide a service request processing apparatus, comprising: The first determining module is used to determine the first risk control list from the first storage medium. The first risk control list is used to determine the risk status of different business requests. The first storage medium is used to store the risk control list corresponding to the distributed system. The distributed system includes multiple nodes, including the first node. The node where the first storage medium is located and the first node are different nodes. The first generation module is used to generate a first identification result corresponding to the business request based on the first risk control list. The first identification result is used to characterize whether the first node processes the business request. The second determining module is used to determine the first processing strategy identifier corresponding to the service request from the second storage medium when the identification result indicates that the service request is processed. The second storage medium is used to store the processing strategy identifier of the distributed system. The node where the second storage medium is located is a different node from the first node. The processing module is configured to obtain the first processing strategy based on the first processing strategy identifier, and process the business request based on the first processing strategy.

[0007] Thirdly, embodiments of the present invention provide an electronic device, including: a processor, a memory, and a program stored in the memory and executable on the processor, wherein when the program is executed by the processor, it implements the steps of the service request processing method described in the first aspect.

[0008] Fourthly, embodiments of the present invention provide a computer-readable storage medium storing a computer program, which, when executed by a processor, implements the steps of the business request processing method described in the first aspect.

[0009] Fifthly, the present invention also provides a computer program product, including computer instructions, which, when executed by a processor, implement the steps of the business request processing method described in the first aspect.

[0010] In this embodiment of the invention, a first risk control list is determined from a first storage medium. This first risk control list is used to determine the risk status of different business requests. The first storage medium stores the risk control list corresponding to a distributed system, which includes multiple nodes, including the first node. The node containing the first storage medium is different from the first node. A first identification result corresponding to a business request is generated based on the first risk control list. This first identification result indicates whether the first node processes the business request. If the identification result indicates that the business request has been processed, a first processing strategy identifier corresponding to the business request is determined from a second storage medium. The second storage medium stores the processing strategy identifier of the distributed system, and the node containing the second storage medium is different from the first node. A first processing strategy is obtained based on the first processing strategy identifier, and the business request is processed based on the first processing strategy. By storing the first risk control list in the first storage medium and the processing strategy identifier in the second storage medium, the storage of the first risk control list and the processing strategy is decoupled, preventing simultaneous leakage and effectively improving data security. Attached Figure Description

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

[0012] Figure 1 This is a flowchart of a business request processing method provided in an embodiment of the present invention; Figure 2 This is a flowchart of a risk control list and processing strategy update provided by an embodiment of the present invention; Figure 3 This is a structural diagram of a service request processing device provided in an embodiment of the present invention; Figure 4 This is a structural diagram of an electronic device provided in an embodiment of the present invention. Detailed Implementation

[0013] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of the present invention. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0014] Please see Figure 1 , Figure 1 This is a flowchart of a business request processing method provided in an embodiment of the present invention, such as... Figure 1 As shown, it includes the following steps: Step 101: Determine the first risk control list from the first storage medium. The first risk control list is used to determine the risk status of different business requests. The first storage medium is used to store the risk control list corresponding to the distributed system. The distributed system includes multiple nodes, including the first node. The node where the first storage medium is located and the first node are different nodes.

[0015] The aforementioned first storage medium is used to store the risk control list corresponding to the distributed system. Each node in the distributed system needs to obtain the risk control list through the first storage medium in order to determine whether the received business request needs to be processed based on the obtained risk control list.

[0016] The distributed system is a system deployed on the server side. It includes multiple nodes, each of which receives service requests sent from the terminal and responds to them (including processing the request or returning an indicator light to the terminal indicating that it was not processed). The multiple nodes include a first node; this embodiment uses the first node as an example to illustrate the specific processing flow after a node receives a service request in the distributed system.

[0017] It should be noted that the first storage medium can be set in a node in the distributed system. This node (hereinafter referred to as the first storage node) is not used to receive and respond to business requests, but to store the risk control list that is published periodically to the first storage medium, so that other nodes (including the first node) can obtain the stored risk control list from the first storage medium of the first storage node.

[0018] In some implementations, the first storage medium can be a storage unit built on the basis of a remote dictionary server (Redis). Redis, as a distributed cache, has rich data structures and excellent read and write performance. Redis is associated with local memory. In the P99 scenario, the time taken by Redis is less than 10ms, and the time taken by local memory is also in the millisecond range. It can handle the high-concurrency access traffic of distributed systems (for example, it can withstand a traffic of 300,000+ queries per second (QPS)).

[0019] This approach utilizes Redis's hash table to store the risk control list. The hash table includes key, field, and value parameters. The key parameter identifies the business dimension set of the risk control list, typically including parameters such as business type, list type, version, or environment. For example, `whitelist:vip:device` or `blacklist:bizA:user`. Each key represents a list set for a single dimension, determining the whitelist or blacklist corresponding to the business, as well as the current version of the whitelist or blacklist. The field parameter represents the specific dimension parameter (list item primary key) corresponding to different businesses, i.e., the identifier of the object to be queried, such as user identifier (ID), device ID, Internet Protocol (IP) address, etc. Each field uniquely corresponds to a list item. The value parameter contains additional information for the list item, commonly stored as JSON / serialized strings, including list status / type (white / black / gray), business tag or source, expiration timestamp (milliseconds / seconds) or TTL, remarks, operator, creation time, etc., used for matching different business requests. When querying through the risk control list, the key parameter, field parameter, and value parameter can be used to match whether the business request is in the whitelist or the blacklist. The business side can then parse and verify whether the request has expired (or combine it with a separate expiration flag) to determine whether to process the business request.

[0020] For example, in the risk control list, the key parameter represents the whitelist, the field parameter represents the dimension parameters corresponding to different businesses, including music business and video business, and the value parameter represents the parameters corresponding to the business request. When a business request is received, the value parameter corresponding to the music business in the risk control list is matched with the parameters corresponding to the business request. That is, the business request is in the whitelist of the music business in the risk control list. At this time, the first recognition result is generated as the first node to process the business request.

[0021] In this way, by configuring the type of the risk control list through the key parameter, configuring the dimension parameters corresponding to the business through the field parameter, and configuring the parameters corresponding to the specific business request through the value parameter, when configuring risk control lists for different business needs, only one value parameter needs to be configured to correspond to different business requests. Different field parameters are used to distinguish different businesses, and the key parameter is used to determine the whitelist or blacklist to determine the identification result. This eliminates the need to configure the corresponding business and identification result separately for each business request, thereby reducing storage costs.

[0022] The aforementioned first risk control list is the risk control list currently used by the distributed system. By storing the first risk control list in the first storage medium, the first node can determine the first risk control list from the first storage medium after receiving a business request, and then determine whether the business request needs to be processed.

[0023] Step 102: Generate a first identification result corresponding to the business request based on the first risk control list. The first identification result is used to characterize whether the first node processes the business request.

[0024] In some implementations, the first risk control list includes a blacklist and a whitelist, which are used to determine whether a business request needs to be processed.

[0025] Specifically, if a business request matches the blacklist, the business request is not processed, and an identification result is generated to indicate that the business request is not processed; conversely, if a business request matches the whitelist, the business request is processed, and an identification result is generated to indicate that the business request is processed.

[0026] In other implementations, multiple risk levels and corresponding business requests can be set in the first risk control list, and corresponding processing methods can be set for different risk levels. For example, the risk levels can be set as low risk, medium risk, and high risk. Nodes can execute business requests of low and medium risk levels, that is, when the business request is of low or medium risk level, an identification result is generated to indicate that the business request has been processed; and they do not execute business requests of high risk level, that is, when the business request is of high risk level, an identification result is generated to indicate that the business request has not been processed.

[0027] Furthermore, for medium-risk business requests, an additional verification method can be added to determine whether the request needs to be processed. For example, a human-machine verification or SMS verification can be added. If the verification is successful, the first node processes the business request; if the verification fails, the first node does not process the business request. Specifically, when the business request is of medium risk level, the first node sends a verification request to the terminal; after receiving the verification request, the terminal performs the verification and generates a verification result, which is then sent back to the first node; upon receiving the verification result, the first node generates a first identification result based on the verification result. Specifically, if the verification is successful, an identification result indicating that the business request has been processed is generated; if the verification fails, an identification result indicating that the business request has not been processed is generated.

[0028] In some implementations, a rule set is configured. A business request matching a rule in this rule set receives a score. If a business request matches multiple rules, these scores are summed. The sum is then compared to a custom threshold to determine the risk level of the business request.

[0029] In this embodiment of the invention, a first identification result corresponding to a business request is generated through a first risk control list. The first identification result can determine whether the business request needs to be processed, thus avoiding the leakage of business data due to processing high-risk business requests and improving data security.

[0030] Step 103: If the identification result indicates that the service request is processed, determine the first processing strategy identifier corresponding to the service request from the second storage medium. The second storage medium is used to store the processing strategy identifier of the distributed system. The node where the second storage medium is located is a different node from the first node.

[0031] The second storage medium is used to store the processing strategy identifier of the distributed system. Before a node processes a business request, it needs to determine the processing strategy identifier from the second storage medium and then obtain the specific processing strategy to process the business request.

[0032] The second storage medium can be set in a node in the distributed system. This node (hereinafter referred to as the second storage node, or the risk control engine) is not used to receive and respond to business requests, but to store the periodically published processing policy identifiers in the second storage medium, so that other nodes (including the first node) can obtain the stored processing policy identifiers from the second storage medium of the second storage node, and then obtain the specific processing policy based on the identifiers.

[0033] It should be noted that neither the node where the second storage medium is located (i.e., the second storage node) nor the node where the first storage medium is located (i.e., the first storage node) directly processes business requests. This means that even if a node receives an attack request, the processing strategy or risk control list will not be leaked because the node does not store the processing strategy or risk control list, thereby improving data security.

[0034] Furthermore, the second storage node and the first storage node are different nodes, which allows the processing strategy identifier and the risk control list to be stored separately. This way, even if the first storage node or the second storage node is attacked and compromised, resulting in the leakage of the processing strategy or the risk control list, the data stored on the other node can still be guaranteed to be safe, avoiding the situation where the processing strategy and the risk control list are leaked at the same time, and further improving data security.

[0035] In some implementations, ZooKeeper can be used as the secondary storage medium. ZooKeeper offers characteristics such as consistency, hot updates, and high read / write speeds, making it better suited for policy configuration and iterative updates. Furthermore, it eliminates the need for continuous application deployments, enabling faster policy configuration and deployment. Since the secondary storage medium only stores the identifier corresponding to the processing policy, rather than the complete policy content, configuration and updates are achieved more quickly. This also avoids policy leakage due to data breaches, further enhancing data security.

[0036] Step 104: Obtain the first processing strategy based on the first processing strategy identifier, and process the service request based on the first processing strategy.

[0037] It should be understood that since the second storage medium only stores the processing policy identifier, the complete processing policy content needs to be obtained based on the corresponding identifier. In some embodiments, the first processing policy may be pre-stored locally on each node, or stored on a node other than the first and second storage nodes (which may be referred to as a third storage node). This node only stores the processing policy and does not process the business request. After obtaining the first processing policy identifier of the business request pair from the second storage medium, the first node obtains the first processing policy from its local storage or the third storage node according to the first processing policy identifier, so that the business request can be processed according to the first processing policy.

[0038] Specifically, a MySQL table can be set up as a third storage medium on the third storage node to store the processing strategy. The first node can then obtain the complete content of the processing strategy through the MySQL table based on the processing strategy identifier.

[0039] In some implementations, a processing strategy actually consists of multiple rules. These rules can be basic logical expressions or complex data operations. In this invention, the data information constituting the rules of the processing strategy is stored in a MySQL table. This MySQL table allows for the retrieval of the complete content of the processing strategy. Specifically, information related to rule construction and deployment is stored in the MySQL table, including maintaining rule versions, rule details, and data bound to the rules.

[0040] In this embodiment of the invention, a first risk control list is determined from a first storage medium. This first risk control list is used to determine the risk status of different business requests. The first storage medium stores the risk control list corresponding to a distributed system, which includes multiple nodes, including the first node. The node containing the first storage medium is different from the first node. A first identification result is generated based on the first risk control list, indicating whether the first node processes the business request. If the identification result indicates that the business request has been processed, a first processing strategy identifier corresponding to the business request is determined from a second storage medium. The second storage medium stores the processing strategy identifier of the distributed system, and the node containing the second storage medium is different from the first node. A first processing strategy is obtained based on the first processing strategy identifier, and the business request is processed based on the first processing strategy. Thus, storing the first risk control list in the first storage medium and the processing strategy identifier in the second storage medium prevents the simultaneous leakage of both the first risk control list and the processing strategy, thereby effectively improving data security.

[0041] In one embodiment, the first storage medium is used to store risk control lists corresponding to different version identifiers, and the second storage medium is used to store processing strategies corresponding to different version identifiers. Before step 101, which involves determining the first risk control list from the first storage medium, the method further includes: Obtain the first risk control list and the first processing strategy identifier; Generate a first version identifier; The first version identifier is bound to the first risk control list, and the bound first version identifier and the first risk control list are written into the first storage medium; The first version identifier is bound to the first processing policy identifier, and the bound first version identifier and the first processing policy identifier are written into the second storage medium.

[0042] It should be noted that the risk control list and processing strategies need to be iterated regularly to cope with the constantly changing internet environment. Therefore, multiple versions of the risk control list will be stored in the first storage medium, and multiple versions of the processing strategy identifiers will be stored in the second storage medium. When it is necessary to update the risk control list and processing strategies, new risk control list and processing strategy identifiers need to be written. In order to ensure that the written risk control list and processing strategy identifiers match, a first version identifier is introduced in this invention to achieve matching between the risk control list and processing strategy identifiers.

[0043] The first version identifier can be the risk view version number (riskViewId), and this first version identifier is different from the version identifiers already present in the first and second storage media. The first risk control list and the first processing strategy identifier are configured through the configuration console.

[0044] After generating the first version identifier, the first version identifier is bound to the first risk control list and the first processing strategy identifier respectively. Then, the bound first version identifier and the first risk control list are written to the first storage medium, and the bound first version identifier and the first processing strategy identifier are written to the second storage medium. This allows the first risk control list to be determined in the first storage medium by the first version identifier, and the first processing strategy identifier to be determined in the second storage medium by the second version identifier.

[0045] The binding of the first version identifier to the first risk control list can be achieved by writing the first version identifier into the data of the first risk control list. For example, if the first risk control list is in key-value pair format, where the key corresponds to the business identifier or routing data and the value corresponds to the risk level, the first version identifier can be written into the key or value to complete the binding between the first version identifier and the first risk control list. For instance, the format of the first risk control list key is list:{bizId}:{dim}, where bizId represents the business identifier and dim represents the parameter corresponding to the business. After writing the first version identifier, the format of the first risk control list key becomes list:{bizId}:{dim}:{riskViewId}, where riskViewId represents the first version identifier.

[0046] Similarly, binding the first version identifier with the first processing strategy identifier can be achieved by writing the first version identifier into the data of the first processing strategy identifier. For example, if the first processing strategy is in key-value pair format, the first version identifier can be written into the key or value of the first processing strategy identifier to complete the binding between the first version identifier and the first processing strategy identifier. For example, if the key format in the first processing strategy identifier is / risk / {bizId}, where / risk / {bizId} represents the identifier of the first processing strategy corresponding to the business representation, the format after writing the first version identifier would be / risk / {bizId} / riskViewId.

[0047] It should be understood that the first version update can only be achieved if the first version identifier and the first risk control list are successfully written to the first storage medium, and the first version identifier and the first processing strategy identifier are successfully written to the second storage medium. If the writing to the first storage medium or the second storage medium fails, the first risk control list or the first processing strategy identifier corresponding to the first version identifier cannot be used to process the business request.

[0048] It should be understood that the risk control lists corresponding to different versions of the identifier may contain the same or different business identifiers. Specifically, for the same business identifier, it may be on both the whitelist and blacklist in different versions of the risk control list simultaneously, or it may be on the whitelist in some versions and on the blacklist in others.

[0049] In this embodiment of the invention, by binding the first version identifier to the first risk control list and binding the first version identifier to the first processing strategy identifier, the version of the risk control list in the first storage medium and the version corresponding to the first processing strategy identifier in the second storage medium can be synchronized through the first version identifier. This allows the first node to process business requests through the first risk control list corresponding to the first version identifier and the identifier corresponding to the first processing strategy.

[0050] For example, such as Figure 2 As shown, the first risk control list and the first processing strategy identifier are obtained through the strategy / list configuration console to enable configuration changes; the risk control engine generates a first version identifier; the first version identifier is bound to the first risk control list, and the bound first version identifier and the first risk control list are written to Redis; the first version identifier is bound to the first processing strategy identifier, and the bound first version identifier and the first processing strategy identifier are written to ZooKeeper to update the first risk control list and the first processing strategy identifier.

[0051] In one embodiment, after receiving a business request, the method further includes: Determine the second version identifier corresponding to the service request; The step of determining the first risk control list from the first storage medium includes: The first risk control list is determined from the first storage medium based on the second version identifier; Determining the first processing strategy identifier corresponding to the service request from the second storage medium includes: The first processing strategy identifier corresponding to the service request is determined from the second storage medium based on the second version identifier; Wherein, if the first version identifier matches the second version identifier, the policy corresponding to the first processing policy identifier is the new version policy; if the first version identifier does not match the second version identifier, the policy corresponding to the first processing policy identifier is the old version policy.

[0052] The aforementioned second version identifier is the version identifier required when processing business requests. The second version identifier may be the same as or different from the first version identifier. It should be noted that, typically, after updating the risk control list in the first storage medium and the processing strategy identifier in the second storage medium, nodes will use the latest version of the risk control list and processing strategy identifier to process business requests. However, for some new versions, the corresponding risk control list and processing strategy identifier may be unstable and require testing. In this case, most requests still need to be processed using the old version of the risk control list and processing strategy identifier, with only a small number of requests processed using the new version. Therefore, in this embodiment of the invention, a second version identifier is introduced. First, the second version identifier corresponding to the business request is determined. Then, based on the second version identifier, it is determined whether the risk control list used to process the business request is the new version of the risk control list, and whether the processing strategy used to process the business request is the new version of the processing strategy.

[0053] The first version identifier can be the version identifier of the latest risk control list and processing strategy identifier. If the second version identifier is the same as the first version identifier (i.e. the first version identifier matches the second version identifier), the new version of the risk control list and processing strategy will be used to process the business request. If the second version identifier is different from the first version identifier (i.e. the first version identifier does not match the second version identifier), the old version of the risk control list and processing strategy will be used to process the business request.

[0054] In this embodiment of the invention, a second version identifier corresponding to the business request is determined; a first risk control list is determined from a first storage medium based on the second version identifier; and a first processing strategy identifier corresponding to the business request is determined from a second storage medium based on the second version identifier. Thus, by determining the first risk control list and the first processing strategy identifier that need to be used currently through the second version identifier, the business request can be processed according to the first risk control list and the first processing strategy identifier.

[0055] For example, such as Figure 2 As shown, after the first risk control list and the first processing strategy identifier are updated, the risk control engine decision module generates a risk control decision result. The risk control decision result includes a first identification result, and if the first identification result indicates that the business request is to be processed, it also includes a first processing strategy identifier, so that the business request can be processed through the first processing strategy.

[0056] In one embodiment, determining the second version identifier corresponding to the service request includes: Obtain first routing data for the service request, wherein the first routing data is used to characterize the device-related information of the device sending the service request; The second version identifier corresponding to the first routing data is determined based on a preset candidate routing configuration table, which includes version identifiers corresponding to different routing data.

[0057] The aforementioned first routing data is used to characterize the address or path of the service request. For example, the first routing data can be parameters such as device type, device location, and the channel through which the service request is sent. The first routing data can be used to determine the user or terminal information sending the service request. Subsequently, a second version identifier corresponding to the first routing data can be determined by pre-setting a subsequent routing configuration table, thereby determining whether the service request needs to be processed using the latest risk control list and processing strategy identifier.

[0058] In some implementations, obtaining the first routing data of the service request can be achieved by adding the first routing data to the header of the service request, and then obtaining the first routing data by parsing the header of the service request after receiving the service request.

[0059] In other implementations, obtaining the first routing data of the service request may involve obtaining the address that sent the service request from the gateway receiving the service request and using that address as the first routing data of the service request.

[0060] The aforementioned preset candidate route configuration table is a routing data configuration for business requests. The preset candidate route configuration table includes version identifiers corresponding to different routing data. By using the preset candidate route configuration table, the user or terminal corresponding to different routing data can be determined, and then the version identifier corresponding to the routing data can be determined, thereby determining whether the business request needs to be processed using the latest risk control list and processing strategy identifier.

[0061] The preset candidate route configuration table is configured in both the first and second storage media, so that when the first risk control list is obtained from the first storage media, the risk control list corresponding to the second version identifier of the business request can be obtained, and when the first processing strategy identifier is obtained from the second storage media, the first processing strategy identifier corresponding to the second version identifier of the business request can be obtained.

[0062] For example, a preset candidate route configuration table is configured in the second storage medium. Before configuration, the key format of the first processing policy identifier is: / risk / {bizId}. After configuration, the key format of the first processing policy identifier is: / risk / {bizId} / route. The route field identifies the routing data. That is, the version identifier can be determined through the routing data, and the first processing policy identifier of the version identifier can be determined.

[0063] In some implementations, the preset candidate route configuration table can be configured according to preset rules. For example, the preset rule is to set version identifiers for the routing data of different users based on a set proportion. That is, a certain proportion of users are set, and the business requests sent by these users are processed using the latest risk control list and processing policy identifier. The routing data corresponding to the business requests of these users is configured in the preset candidate route configuration table with the corresponding new version identifier (i.e., the first version identifier). Meanwhile, the business requests sent by other users are processed using the old risk control list and processing policy identifier. The routing data of the business requests sent by other users is configured in the preset candidate route configuration table with the corresponding old version identifier.

[0064] Furthermore, the preset rules can also set different version identifiers for the routing data of business requests sent by new and old users. Newly registered users can be configured to use the latest risk control list and processing policy identifiers, meaning the routing data for business requests sent by newly registered users is configured with the corresponding new version identifier in the preset candidate route configuration table; while old users (users whose registration time exceeds a set period) are processed using the old risk control list and processing policy identifiers, meaning the routing data for business requests sent by old users is configured with the corresponding old version identifier in the preset candidate route configuration table.

[0065] Alternatively, the preset rules can also set different version identifiers for the routing data of business requests with different risk levels based on risk thresholds. That is, setting a risk threshold means that business requests with a risk level higher than the threshold are processed using the latest risk control list and processing strategy identifier; that is, for business requests with a risk level higher than the threshold, the routing data for that business request is configured with the corresponding new version identifier in the preset candidate route configuration table. Conversely, business requests with a risk level lower than the threshold are processed using the old risk control list and processing strategy identifier; that is, for business requests with a risk level lower than the threshold, the routing data for that business request is configured with the corresponding old version identifier in the preset candidate route configuration table.

[0066] In this way, by configuring a preset candidate route configuration table according to preset rules, the goal of "closing high-risk channels first and new customers first" is achieved.

[0067] In this embodiment of the invention, first routing data of the service request is obtained; a second version identifier corresponding to the first routing data is determined based on a preset candidate routing configuration table, wherein the preset candidate routing configuration table includes version identifiers corresponding to different routing data. Thus, by determining the version identifier through the preset candidate routing configuration table, it is possible to configure whether the service request is processed using the latest version of the risk control list and processing strategy identifier by adjusting the content of the preset candidate routing configuration table.

[0068] Furthermore, by configuring version identifiers for different versions, it is also possible to quickly switch between different versions, which facilitates the rapid rollback of risk control lists and processing strategy identifiers during use.

[0069] In one embodiment, the first risk control list includes a business dimension identifier set and an object identifier set. The business dimension identifier set includes identifiers for different business types, and the object identifier set includes identifiers for different routing data. Different business type identifiers and different routing data identifiers correspond to different identification results.

[0070] In this embodiment of the invention, after receiving a business request, the business type identifier and routing data corresponding to the business request are determined, and then a first identification result can be obtained by matching the first risk control list.

[0071] For example, the first risk control list includes a blacklist and a whitelist. The blacklist consists of a first set of business type identifiers and a first set of routing data; the identification result for the blacklist is not to process the business request. The whitelist consists of a second set of business type identifiers and a second set of routing data; the identification result for the whitelist is to process the business request. Upon receiving a business request, the business type identifier and routing data corresponding to the business request are determined. Then, based on the business type identifier and routing data, it is determined whether the request is on the blacklist or the whitelist, and the corresponding first identification result is generated.

[0072] In one embodiment, the second storage medium is used to store multiple root nodes, each root node including multiple child nodes, each root node corresponding to a service type, and each child node including a processing strategy identifier corresponding to a version identifier, with different version identifiers corresponding to different child nodes.

[0073] In this embodiment of the invention, the processing strategy identifier corresponding to the business request can be quickly determined based on the business type and version identifier corresponding to the business request, thereby obtaining the corresponding processing strategy.

[0074] For example, the second storage medium can be implemented using ZooKeeper (abbreviated as "zk"). Different business operations construct a root node for a zk branch, and the processing policy identification information is mounted on the leaf nodes of zk. Business information includes the business's authentication token, business identifier, and business parameter dimensions, etc.; processing policy identification information includes the processing policy identifier, version identifier, etc.

[0075] It should be understood that the second storage medium stores four main categories of data: business, processing strategies, rules, and data. Different businesses correspond to different processing strategies, typically one processing strategy per business. Business types can include login, withdrawal, voting, and other similar services.

[0076] Please see Figure 3 , Figure 3 This is a structural diagram of a service request processing device provided in an embodiment of the present invention, as shown below. Figure 3 As shown, the service request processing device 300 includes: The first determining module 301 is used to determine a first risk control list from a first storage medium. The first risk control list is used to determine the risk status of different business requests. The first storage medium is used to store the risk control list corresponding to the distributed system. The distributed system includes multiple nodes, including the first node. The node where the first storage medium is located and the first node are different nodes. The first generation module 302 is used to generate a first identification result corresponding to a business request based on the first risk control list. The first identification result is used to characterize whether the first node processes the business request. The second determining module 303 is used to determine the first processing strategy identifier corresponding to the service request from the second storage medium when the identification result indicates that the service request is processed. The second storage medium is used to store the processing strategy identifier of the distributed system. The node where the second storage medium is located is a different node from the first node. The processing module 304 is used to obtain the first processing strategy based on the first processing strategy identifier, and to process the service request based on the first processing strategy.

[0077] In one embodiment, the first storage medium is used to store risk control lists corresponding to different version identifiers, and the second storage medium is used to store processing strategies corresponding to different version identifiers. The service request processing device 300 further includes: The acquisition module is used to acquire the first risk control list and the first processing strategy identifier; The second output module is used to generate the first version identifier; The first writing module is used to bind the first version identifier with the first risk control list, and write the bound first version identifier and the first risk control list into the first storage medium. The second writing module is used to bind the first version identifier with the first processing policy identifier, and write the bound first version identifier and the first processing policy identifier into the second storage medium.

[0078] In one embodiment, the service request processing device 300 further includes: The third determining module is used to determine the second version identifier corresponding to the service request; The first determining module 301 includes: The first determining unit is used to determine the first risk control list from the first storage medium based on the second version identifier; The second determining module 303 includes: The second determining unit is configured to determine the first processing strategy identifier corresponding to the service request from the second storage medium based on the second version identifier; Wherein, if the first version identifier matches the second version identifier, the policy corresponding to the first processing policy identifier is the new version policy; if the first version identifier does not match the second version identifier, the policy corresponding to the first processing policy identifier is the old version policy.

[0079] In one embodiment, the third determining module includes: The acquisition unit is used to acquire first routing data of the service request, wherein the first routing data is used to characterize the device-related information of the device sending the service request. The third determining unit is used to determine the second version identifier corresponding to the first routing data based on a preset candidate routing configuration table, wherein the preset candidate routing configuration table includes version identifiers corresponding to different routing data.

[0080] In one embodiment, the first risk control list includes a business dimension identifier set and an object identifier set. The business dimension identifier set includes identifiers for different business types, and the object identifier set includes identifiers for different routing data. Different business type identifiers and different routing data identifiers correspond to different identification results.

[0081] In one embodiment, the second storage medium is used to store multiple root nodes, each root node including multiple child nodes, each root node corresponding to a service type, and each child node including a processing strategy identifier corresponding to a version identifier, with different version identifiers corresponding to different child nodes.

[0082] The business request processing apparatus provided in this embodiment of the invention can implement each process of each embodiment of the above-described business request processing method. The technical features are one-to-one and can achieve the same technical effect. To avoid repetition, it will not be described again here.

[0083] It should be noted that the service request processing device in the embodiments of the present invention can be a device, or it can be a component, integrated circuit, or chip in an electronic device.

[0084] This invention also provides an electronic device, see [link to relevant documentation]. Figure 4 , Figure 4This is a schematic diagram of the structure of an electronic device provided by an embodiment of the present invention. The electronic device includes a memory 401, a processor 402, and a program or instructions stored in the memory 401 that run on the memory. When the program or instructions are executed by the processor 402, they can achieve the following: Figure 1 The steps in the corresponding business request processing method embodiments and the achievement of the same beneficial effects will not be elaborated here.

[0085] The processor 402 can be a central processing unit (CPU), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or a graphics processing unit (GPU).

[0086] Those skilled in the art will understand that all or part of the steps of the above-described embodiments of the business request processing method can be implemented by hardware related to program instructions, and the program can be stored in a readable medium.

[0087] This invention also provides a readable storage medium storing a computer program, which, when executed by a processor, can perform the above-described functions. Figure 1 Any step in the corresponding business request processing method embodiment, which can achieve the same technical effect, will not be described again here to avoid repetition. The storage medium mentioned includes, for example, read-only memory (ROM), random access memory (RAM), magnetic disk, or optical disk.

[0088] This invention also provides a computer program product, including computer instructions that, when executed by a processor, implement the above-described... Figure 1 Any step in the corresponding business request processing method embodiment, or, implementing the above Figure 2 Any step in the corresponding business request processing method embodiment can achieve the same technical effect, and will not be described again here to avoid repetition.

[0089] In the embodiments of this invention, the terms "first," "second," etc., are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion. For example, a process, method, system, product, or device that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to these processes, methods, products, or devices. Additionally, the use of "and / or" in this application indicates at least one of the connected objects, such as A and / or B and / or C, representing seven possibilities: A alone, B alone, C alone, both A and B present, both B and C present, both A and C present, and A, B, and C present.

[0090] It should be noted that, in this document, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element.

[0091] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods of the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk) and includes several instructions to cause a terminal (which may be a mobile phone, computer, server, air conditioner, or second terminal device, etc.) to execute the methods of the various embodiments of this application.

[0092] The embodiments of this application have been described above with reference to the accompanying drawings. However, this application is not limited to the specific embodiments described above. The specific embodiments described above are merely illustrative and not restrictive. Those skilled in the art can make many other forms under the guidance of this application without departing from the spirit and scope of the claims, and all of these forms are within the protection scope of this application.

Claims

1. A business request processing method, applied to a first node, characterized in that, include: A first risk control list is determined from a first storage medium. The first risk control list is used to determine the risk status of different business requests. The first storage medium is used to store the risk control list corresponding to the distributed system. The distributed system includes multiple nodes, including the first node. The node where the first storage medium is located and the first node are different nodes. A first identification result is generated based on the first risk control list to correspond to the business request. The first identification result is used to characterize whether the first node processes the business request. When the identification result indicates that the service request is being processed, a first processing strategy identifier corresponding to the service request is determined from the second storage medium. The second storage medium is used to store the processing strategy identifier of the distributed system, and the node where the second storage medium is located is a different node from the first node. The first processing strategy is obtained based on the first processing strategy identifier, and the business request is processed based on the first processing strategy.

2. The method as described in claim 1, characterized in that, The first storage medium is used to store the risk control list corresponding to different version identifiers, and the second storage medium is used to store the processing strategy corresponding to different version identifiers. Before determining the first risk control list from the first storage medium, the method further includes: Obtain the first risk control list and the first processing strategy identifier; Generate a first version identifier; The first version identifier is bound to the first risk control list, and the bound first version identifier and the first risk control list are written into the first storage medium; The first version identifier is bound to the first processing policy identifier, and the bound first version identifier and the first processing policy identifier are written into the second storage medium.

3. The method as described in claim 2, characterized in that, The method further includes: determining a second version identifier corresponding to the service request; The step of determining the first risk control list from the first storage medium includes: determining the first risk control list from the first storage medium based on the second version identifier; Determining the first processing strategy identifier corresponding to the service request from the second storage medium includes: determining the first processing strategy identifier corresponding to the service request from the second storage medium based on the second version identifier; Wherein, if the first version identifier matches the second version identifier, the policy corresponding to the first processing policy identifier is the new version policy; if the first version identifier does not match the second version identifier, the policy corresponding to the first processing policy identifier is the old version policy.

4. The method as described in claim 3, characterized in that, Determining the second version identifier corresponding to the service request includes: Obtain first routing data for the service request, wherein the first routing data is used to characterize the device-related information of the device sending the service request; The second version identifier corresponding to the first routing data is determined based on a preset candidate routing configuration table, which includes version identifiers corresponding to different routing data.

5. The method according to any one of claims 1 to 4, characterized in that, The first risk control list includes a set of business dimension identifiers and a set of object identifiers. The set of business dimension identifiers includes identifiers for different business types, and the set of object identifiers includes identifiers for different routing data. Different business type identifiers and different routing data identifiers correspond to different identification results.

6. The method according to any one of claims 2 to 4, characterized in that, The second storage medium is used to store multiple root nodes, each root node including multiple child nodes. Each root node corresponds to a service type, and each child node includes a processing strategy identifier corresponding to a version identifier. Different child nodes have different version identifiers.

7. A service request processing apparatus, characterized in that, include: The first determining module is used to determine a first risk control list from a first storage medium. The first risk control list is used to determine the risk status of different business requests. The first storage medium is used to store the risk control list corresponding to the distributed system. The distributed system includes multiple nodes, including a first node. The node where the first storage medium is located and the first node are different nodes. The first generation module is used to generate a first identification result corresponding to the business request based on the first risk control list. The first identification result is used to characterize whether the first node processes the business request. The second determining module is used to determine the first processing strategy identifier corresponding to the service request from the second storage medium when the identification result indicates that the service request is processed. The second storage medium is used to store the processing strategy identifier of the distributed system. The node where the second storage medium is located is a different node from the first node. The processing module is configured to obtain the first processing strategy based on the first processing strategy identifier, and process the business request based on the first processing strategy.

8. An electronic device, characterized in that, include: A processor, a memory, and a program stored in the memory and executable on the processor, wherein the program, when executed by the processor, implements the steps of the service request processing method as described in any one of claims 1 to 6.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, implements the steps of the service request processing method as described in any one of claims 1 to 6.

10. A computer program product, characterized in that, It includes computer instructions, which, when executed by a processor, implement the steps of the service request processing method as described in any one of claims 1 to 6.

Images