Request processing method and device, storage medium and electronic equipment

Abstract

The invention discloses a request processing method and device, a storage medium and electronic equipment, and belongs to the technical field of computers, the method is applied to a decision engine for synchronously operating a main strategy and a running accompanying strategy in a production environment, and the method comprises the following steps: generating a decision obtaining request based on a decision request identifier, sending the decision obtaining request to a header component of the first component link and a header component of the second component link, triggering the first component link to make a main strategy decision according to the topology corresponding to the main strategy until a strategy result is obtained, and triggering the second component link to make a running accompanying strategy decision according to the topology corresponding to the running accompanying strategy; executing a target data request identifier generation operation by using preset data to obtain a target data request identifier; and executing a data acquisition operation based on the target data request identifier to obtain target data for generating a decision result, both the target data request identifier generation operation and the data acquisition operation being idempotent operations. According to the invention, idempotency when the same data is requested for multiple times is ensured.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to request processing methods, apparatus, storage media, and electronic devices. Background Technology

[0002] A decision engine is a software component or system that automates decision-making through logic and rules. The strategy actually used by the decision engine to execute automated decisions is the primary strategy, while the strategies executed by the decision engine but not outputting automated decision results are called supporting strategies.

[0003] Related technologies typically set up a test environment similar to the production environment where the main strategy resides to deploy the run-through strategy, and it is necessary to ensure that the test environment is highly identical to the production environment. However, the test environment may not be able to fully simulate the production environment, resulting in inaccurate run-through results or increased run-through analysis costs. In addition, related technologies usually cannot run the main strategy and the run-through strategy synchronously, but only sequentially, which leads to increased run-through time costs.

[0004] Furthermore, when executing the main strategy or the accompanying strategy, the decision engine may request data from third-party services, and the main strategy and the accompanying strategy may request the same data. This results in the problem of requesting the same data multiple times, which will lead to multiple billing and idempotency issues. Summary of the Invention

[0005] This application provides a request processing method, apparatus, storage medium, and electronic device, which can avoid the cost of building a separate test environment for the accompanying strategy, avoid the time consumption caused by the accompanying method in which the main strategy and the accompanying strategy run sequentially, and at the same time avoid the problem of duplicate billing caused by strategy accompanying, and ensure the idempotency of multiple requests for the same data.

[0006] According to one aspect of the embodiments of this application, a request processing method is provided, the method being applied to a decision engine, the decision engine synchronously running a main strategy and a follow-up strategy in a production environment, the method comprising:

[0007] Upon receiving a target request from a client, a corresponding decision request identifier is generated, and the target request is used to trigger the decision engine to output the corresponding decision result;

[0008] A decision acquisition request is generated based on the decision request identifier, and the decision acquisition request is sent to the head component of the first component link, triggering the first component link to make a decision based on the main strategy according to the topology corresponding to the main strategy, until the tail of the first component link outputs the decision result;

[0009] The decision acquisition request is sent to the head component in the second component link, triggering the second component link to make a decision based on the running strategy according to the topology corresponding to the running strategy;

[0010] When the target component receives preset data, it uses the preset data to perform a target data request identifier generation operation to obtain a target data request identifier; based on the target data request identifier, it performs a data acquisition operation to obtain target data for generating decision results. The target component is the component in the first component link or the second component link used to request data. Both the target data request identifier generation operation and the data acquisition operation are idempotent operations.

[0011] The decision result is then fed back to the client.

[0012] According to one aspect of the embodiments of this application, a request processing apparatus is provided, the apparatus being applied to a decision engine, the decision engine synchronously running a main strategy and a follow-up strategy in a production environment, the apparatus comprising:

[0013] The target request acquisition module is used to generate a corresponding decision request identifier when a target request is received from a client. The target request is used to trigger the decision engine to output the corresponding decision result.

[0014] The decision engine execution module is used to perform the following operations:

[0015] A decision acquisition request is generated based on the decision request identifier, and the decision acquisition request is sent to the head component of the first component link, triggering the first component link to make a decision based on the main strategy according to the topology corresponding to the main strategy, until the tail of the first component link outputs the decision result;

[0016] The decision acquisition request is sent to the head component in the second component link, triggering the second component link to make a decision based on the running strategy according to the topology corresponding to the running strategy;

[0017] When the target component receives preset data, it uses the preset data to perform a target data request identifier generation operation to obtain a target data request identifier; based on the target data request identifier, it performs a data acquisition operation to obtain target data for generating decision results. The target component is the component in the first component link or the second component link used to request data. Both the target data request identifier generation operation and the data acquisition operation are idempotent operations.

[0018] The decision result is then fed back to the client.

[0019] According to one aspect of the embodiments of this application, a computer device is provided, the computer device including a processor and a memory, the memory storing at least one instruction, at least one program, code set or instruction set, the at least one instruction, the at least one program, the code set or instruction set being loaded and executed by the processor to implement the above-described request processing method.

[0020] According to one aspect of the embodiments of this application, a computer-readable storage medium is provided, the storage medium storing at least one instruction, at least one program, code set, or instruction set, wherein the at least one instruction, the at least one program, the code set, or the instruction set is loaded and executed by a processor to implement the above-described request processing method.

[0021] According to one aspect of this application, a computer program product is provided, the computer program product including computer instructions stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium, and the processor executes the computer instructions, causing the computer device to perform to implement the above-described request processing method.

[0022] The technical solution provided in this application can bring the following beneficial effects:

[0023] This application provides a request processing method, apparatus, storage medium, and electronic device. This application applies to a decision engine that synchronously runs a main strategy and a follow-up strategy in a production environment. This avoids the cost of building a separate test environment for the follow-up strategy and the time consumption caused by the follow-up method where the main strategy and the follow-up strategy run sequentially.

[0024] To address the idempotency issue arising from multiple high-concurrency requests for the same data within a short period in a production environment where the main strategy and the accompanying strategy run synchronously, this application embodiment designs a target data request identifier generation operation and a data acquisition operation for the component sending data acquisition requests. Both of these operations are idempotent, ensuring that neither the main strategy nor the accompanying strategy will encounter idempotency issues during operation. If the data acquisition request involves billing, there will be no duplicate billing issues. This avoids the cost of building a separate test environment for the accompanying strategy, the time overhead of running the accompanying methods sequentially with the main strategy, and the duplicate billing issues caused by strategy accompanying, thus ensuring idempotency when multiple requests for the same data are made during strategy accompanying. Attached Figure Description

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

[0026] Figure 1 This is a schematic diagram of an application runtime environment provided in one embodiment of this application;

[0027] Figure 2 This is a flowchart of a request processing method provided in one embodiment of this application;

[0028] Figure 3 This is a flowchart of a data acquisition operation method provided in one embodiment of this application;

[0029] Figure 4 This is a schematic diagram of a data acquisition operation method provided in one embodiment of this application;

[0030] Figure 5 This is a schematic diagram of a lock request response process provided in one embodiment of this application;

[0031] Figure 6 This is a block diagram of a request processing apparatus provided in one embodiment of this application;

[0032] Figure 7 This is a structural block diagram of a computer device provided in one embodiment of this application. Detailed Implementation

[0033] To make the purpose, technical solution, and advantages of this application clearer, a brief introduction to the relevant background of this application is given first:

[0034] A decision engine is a software component or system that automates decision-making through logic and rules. Decision engines are widely used in business processes, risk management, marketing automation, credit scoring, and risk detection. A decision engine typically supports strategy "runners," meaning the strategy actually used by the decision engine to execute the automated decision is the primary strategy, while strategies executed by the decision engine but not outputting automated decision results are called runner strategies. A decision engine can support at least one runner strategy.

[0035] Specifically, strategy profiling involves running one or more profiling strategies and comparing their results with the main strategy to verify the merits of either the main strategy or the profiling strategies. Furthermore, the decision engine can obtain important intermediate data by running profiling strategies, thereby optimizing the decision engine. Although the decision engine runs both the main strategy and profiling strategies, only the results of the main strategy have a practical impact. The results of the profiling strategies do not have a practical impact; they are merely internal data for the decision engine, primarily used to evaluate the effectiveness of different strategies so that the decision engine can switch strategies when necessary.

[0036] Related technologies typically set up a test environment similar to the production environment where the main strategy resides to deploy the run-through strategy. It's crucial to ensure that the data in the test environment is synchronized with the production environment so that it can handle real-world data during the run-through. However, the test environment may not fully simulate all conditions in the production environment, such as network latency and load, which could lead to inaccurate results from the run-through. Furthermore, maintaining a test environment similar to production requires additional hardware and software resources, potentially increasing costs. If the execution results of the run-through strategy in the test environment differ from those of the main strategy in the production environment, significant effort may be needed to analyze whether the inconsistency stems from environmental variables or strategy differences, further increasing the analytical costs associated with the run-through.

[0037] Some technical solutions further reduce the impact of the accompanying strategy on the main strategy's operation by storing the processing results in the feature center after the main strategy has processed a portion of the data, and then restarting the accompanying strategy to process the same data again. Clearly, this sequential execution of the main and accompanying strategies increases the time cost of the accompanying strategy.

[0038] When executing the primary strategy or the accompanying strategy, the decision engine may request data from third-party services. In other words, the data returned by the third-party services is the necessary data that the decision engine needs to use when executing the primary or accompanying strategy. For example, if a first entity needs to use the decision engine to run the primary or accompanying strategy to assess the loan limit for a certain account, it needs to obtain the account's credit data. This credit data may be managed by a second entity. Since the second entity and the first entity are different entities, the credit data management service run by the second entity is considered a third-party service by the first entity's decision engine. The decision engine can only obtain the credit data and thus assess the loan limit for the account by interacting with the credit data management service run by the second entity.

[0039] When the decision engine executes the primary strategy or the accompanying strategy, each request to a third-party service may incur charges. When implementing the accompanying strategy, both the primary and accompanying strategies may send requests to third-party services, and these requests may involve the same data. Continuing the previous example, both the primary and accompanying strategies request the same account's credit data, leading to multiple requests for the same data. Multiple requests for the same data result in multiple charges, causing idempotency issues such as duplicate billing and data inconsistency. Idempotency is crucial in distributed systems and network-based services. If an operation is not idempotent, repeated execution may lead to data inconsistency or abnormal states. In the accompanying strategy scenario, not only can network instability cause idempotency issues, but the accompanying strategy mechanism itself inherently generates multiple requests for the same data, naturally leading to idempotency problems.

[0040] In a decision engine, "puppet strategy" involves sending the same data and requests to a primary strategy without affecting its execution. This puppet strategy can run in a test environment to verify the effectiveness and accuracy of both the primary and secondary strategies. Often, the purpose of puppet strategy is to test and evaluate it without disrupting normal business processes. Therefore, the processing results of the puppet strategy are not used for actual business decisions, but only for analysis and comparison. In this model, the primary and puppet strategies often send requests for the same data to third-party services, resulting in duplicate billing. Since the puppet strategy is not used for business decisions, this duplicate billing is unnecessary and unreasonable.

[0041] The aforementioned technologies can naturally distinguish between the main strategy and the supporting strategy by deploying the main strategy and the supporting strategy in different environments, or by executing the main strategy and the supporting strategy sequentially. Combined with some technical means, this can alleviate the idempotency problem to a certain extent. However, the cost of this natural distinction is also high.

[0042] In order to avoid the cost of building a separate test environment for the accompanying strategy in the strategy-accompanying scenario, avoid the time consumption caused by the accompanying method of running the main strategy and the accompanying strategy in sequence, and avoid the problem of duplicate billing caused by strategy accompanying, and ensure idempotency when making multiple requests for the same data during strategy accompanying, this application provides a request processing method.

[0043] To make the objectives, technical solutions, and advantages of this application clearer, the embodiments of this application will be described in further detail below with reference to the accompanying drawings. It should be noted that all data used in the embodiments of this application has been fully authorized by the relevant parties before use.

[0044] Please refer to Figure 1 This diagram illustrates an application runtime environment provided in one embodiment of this application. The application runtime environment may include: terminal 10 and server 20.

[0045] Terminal 10 includes, but is not limited to, electronic devices such as mobile phones, computers, smart voice interaction devices, smart home appliances, in-vehicle terminals, game consoles, e-book readers, multimedia playback devices, and wearable devices. Application clients can be installed on terminal 10.

[0046] In this embodiment, the application described above can be any application that requires the use of a request processing method; typically, this application is an electronic payment application. Of course, other types of applications besides electronic payment applications can also use the request processing method. Examples include news applications, social networking applications, search applications, interactive entertainment applications, browser applications, shopping applications, content sharing applications, virtual reality (VR) applications, and augmented reality (AR) applications, etc. This embodiment does not limit the scope of these applications. Optionally, the terminal 10 runs a client application of the aforementioned application.

[0047] Server 20 provides background services to clients of applications in terminal 10. For example, server 20 can be a background server for the aforementioned applications. Server 20 can be a standalone physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server providing basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, CDN (Content Delivery Network), and big data and artificial intelligence platforms. Optionally, server 20 can simultaneously provide background services to applications in multiple terminals 10.

[0048] Optionally, terminal 10 and server 20 can communicate with each other via network 30. Terminal 10 and server 20 can be directly or indirectly connected via wired or wireless communication, which is not limited herein.

[0049] Please refer to Figure 2 The diagram illustrates a flowchart of a request processing method according to an embodiment of this application. This method can be applied to a computer device, which refers to an electronic device capable of data computation and processing. For example, the entity executing each step may be... Figure 1 The application is running on the relevant devices in the environment shown.

[0050] The relevant devices running this method, such as servers, are equipped with a decision engine. This decision engine runs the main strategy and the accompanying strategy synchronously in the production environment. This embodiment does not inherently distinguish between the main strategy and the accompanying strategy, nor does it place them in different environments; instead, both are run in the production environment, and no test environment is set up for the accompanying strategy. Furthermore, this embodiment does not execute the main strategy and the accompanying strategy sequentially, but synchronously. Running the main strategy and the accompanying strategy synchronously in the production environment obviously saves the cost of building a test environment and avoids inaccurate accompanying results or increased accompanying analysis costs caused by a lack of strict consistency between the test environment and the production environment. It also saves the time cost associated with running the main strategy and the accompanying strategy sequentially. However, running the main strategy and the accompanying strategy synchronously in the production environment may also lead to the generation of high-concurrency data acquisition requests for the same data within a short period, resulting in an idempotency problem. This problem is properly solved in this embodiment.

[0051] The request processing method proposed in this application includes the following steps:

[0052] Step S201. Upon receiving a target request from the client, generate a corresponding decision request identifier. The target request is used to trigger the decision engine to output the corresponding decision result.

[0053] In a client-server architecture, the client can send a target request to the server's decision engine. This target request triggers the server's decision engine to output a corresponding decision result, which is then returned to the client. This application does not limit the specific decision content requested by the target request, as long as it can trigger the decision engine to run the main strategy and the accompanying strategy. For example, if the main strategy and the accompanying strategy are strategies for calculating account credit ratings, the target request can request the decision engine to output a credit rating for account A; if the main strategy and the accompanying strategy are strategies for outputting the account's disposable virtual resource limit, the target request can request the decision engine to output the disposable virtual resource limit for account A.

[0054] In this embodiment, the decision engine runs the main strategy and the accompanying strategy synchronously in the production environment. Since the main strategy and the accompanying strategy make decisions on the same target request, the requests used to trigger the main strategy and the accompanying strategy have the same decision request identifier.

[0055] Step S202. Generate a decision acquisition request based on the decision request identifier, and send the decision acquisition request to the head component of the first component link to trigger the first component link to make a decision based on the main strategy according to the topology corresponding to the main strategy, until the tail of the first component link outputs the decision result; send the decision acquisition request to the head component in the second component link to trigger the second component link to make a decision based on the accompanying strategy according to the topology corresponding to the accompanying strategy.

[0056] This application does not limit the method of isolating the main strategy and the accompanying strategy. For example, in the process of decision acquisition request flow, the main strategy and the accompanying strategy can add specific identifiers or tags to the relevant data interaction process to achieve the distinction and isolation between the main strategy and the accompanying strategy. This application does not elaborate on this, nor does it constitute an obstacle to implementation.

[0057] In this embodiment, the main strategy and the accompanying strategy can be implemented using different logical components. The logical components implementing the main strategy form a first component link according to the topology of executing the main strategy, and the logical components implementing the accompanying strategy form a second component link according to the topology of executing the accompanying strategy. Sending a decision retrieval request to the head component of the first component link triggers the components of the first component link to be triggered sequentially according to the topology of the main strategy to execute the main strategy, and the execution result of the main strategy, i.e., the decision result of the main strategy, is output at the tail component of the first component link. Sending a decision retrieval request to the head component of the second component link triggers the components of the second component link to be triggered sequentially according to the topology of the accompanying strategy to execute the accompanying strategy, and the execution result of the accompanying strategy, i.e., the decision result of the accompanying strategy, is output at the tail component of the second component link. The decision result of the accompanying strategy is not fed back to the client, but is only recorded as the accompanying result in the decision engine or related storage device.

[0058] Step S203. When the target component receives preset data, a target data request identifier generation operation is performed using the preset data to obtain a target data request identifier; a data acquisition operation is performed based on the target data request identifier to obtain target data for generating decision results. The target component is a component in the first component link or the second component link used to request data. Both the target data request identifier generation operation and the data acquisition operation are idempotent operations.

[0059] The target component is the component that requests data from the decision engine or a third-party service; that is, the target component needs to interact with other components to obtain the necessary data to perform its work. For example, the target component may be used to send a data retrieval request to a third-party service; or, the target component may be used to send a data retrieval request for internal data to the decision engine itself.

[0060] Third-party services can be provided by external companies or organizations independent of the business application where the decision engine resides. These services are typically offered through application programming interfaces (APIs) or other integration methods, extending the decision engine's functionality. Billing is generally based on the number of requests. Therefore, without idempotency control, duplicate billing may occur at the target component level due to multiple requests for the same data.

[0061] Both the main strategy and the follow-up strategy may require data acquisition. However, the difference lies in that the main strategy is used for formal business decisions and is the actual decision logic that takes effect. It is used to formally evaluate and process target requests, and its results are fed back to the client, thus directly affecting business processes, such as loan approval and credit scoring. On the other hand, the follow-up strategy is used to test and verify new strategies or optimize existing strategies. Its results do not affect the actual business processes, but it plays an important role in strategy optimization and adjustment.

[0062] Although the main strategy and the accompanying strategy have different functions and their execution of a series of predefined rules and logics differs, both strategies may reuse some data. For example, both the main strategy and the accompanying strategy may need to use account A's credit score, which is provided by a third-party server. This credit score is used three times in the main strategy and four times in the accompanying strategy. Therefore, the main strategy may have three target components requesting the credit score from the third-party service three times, while the accompanying strategy may have four target components requesting the credit score four times. Because this credit score is used three times in the main strategy and four times in the accompanying strategy, both the first component link of the main strategy and the second component link of the accompanying strategy may have at least one target component, meaning the total number of target components must be greater than or equal to two. In other words, in the production environment of the decision engine, at least two target components will request the same data multiple times, potentially leading to duplicate billing issues.

[0063] To address this issue, embodiments of this application stipulate that each data acquisition request sent by the target component must be an idempotent request, using idempotency to resolve the double billing problem. The target component possesses data acquisition capabilities and is a key module supporting rule execution and evaluation by the decision engine. By acquiring internal or external data, the decision engine can obtain real-time and accurate data, thereby making more effective decisions. The implementation of data acquisition by the target component may include configuring data requests, executing data requests, data processing, data transformation, and data cache management.

[0064] In this embodiment, the data request configuration step includes generating a target data request identifier, which is an idempotent operation. The data processing step includes a data acquisition operation, which is also an idempotent operation. This operation achieves idempotency through interaction with a data cache, and data cache management is used to support this idempotent operation. Data transformation is used to convert the acquired target data into a data format that can be directly processed by downstream components of the target component, thereby adapting the external or internal data acquired through the target component to the strategies supported by the target component.

[0065] The target component uses the preset data to perform a target data request identifier generation operation. During this process, the target data request identifier generation operation is idempotent. This means that regardless of which target component generates the identifier multiple times, as long as the same data is requested, the same target data request identifier will be obtained. In the following text, an idempotent data acquisition operation is performed on the same target data request identifier to obtain the target data. Therefore, the target data acquisition process is also idempotent. This means that regardless of how many times the target data is acquired, the same result is produced. Multiple data acquisition requests will not result in multiple data acquisition requests to third-party services or the decision engine itself, thus avoiding duplicate billing issues.

[0066] This application embodiment ensures that both the target data request identifier generation operation and the data acquisition operation are idempotent operations, thereby preventing multiple requests for the same data and thus avoiding duplicate billing. In this application embodiment, the data acquisition implemented in the target component is idempotent throughout. The data acquisition requests sent by the target component to the third-party service or the decision engine itself are idempotent. The target component can be a component in the first component link or a component in the second component link; that is, the target component is any component in either the first or second component link that sends an idempotent request. For example, even if the main strategy requires three requests for credit score from the third-party service, and the accompanying strategy requires four requests for credit score, in this application embodiment, only one request for credit score is actually sent to the third-party service.

[0067] The target component uses preset data to generate a target data request identifier. The generation of the target data request identifier is an idempotent operation, meaning that the same preset data will necessarily generate the same target data request identifier. The preset data refers to the data passed to the target component in the component chain, serving as the basic data source for performing the target data request identifier generation operation. This application embodiment does not limit the content of the preset data; it is related to the logic of the specific main strategy or accompanying strategy.

[0068] Using the previous example, both the main strategy and the accompanying strategy need to use the credit score of account A. Therefore, the preset data of the target component in their respective component links may be the account identifier and basic account information of account A, as well as the decision request identifier.

[0069] Since identical preset data will inevitably generate the same target data request identifier, both the main strategy and the accompanying strategy will generate the same target data request identifier and correspond to the same data acquisition request, thus achieving request merging between the main strategy and the accompanying strategy. For example, both the main strategy and the accompanying strategy need to use account A's credit score multiple times, but regardless of the target component corresponding to the main strategy or the accompanying strategy, only the same target data request identifier can be generated, resulting in an identical data acquisition request. In this embodiment, the identical data acquisition request will be treated as the same request and processed idempotently, thereby achieving request merging between the main strategy and the accompanying strategy.

[0070] This application does not limit the execution method of idempotent operations that necessarily generate the same target data request identifier using the same preset data, and does not constitute an obstacle to implementation. The purpose of this operation is to optimize the processing flow of data acquisition requests. By merging requests in conjunction with the idempotent data acquisition operation detailed below, it reduces repeated access to external data sources from third-party services and also reduces repeated access to internal data within the decision engine itself, thereby improving the performance and response speed of the decision engine and avoiding duplicate billing. Simultaneously, this merging method also facilitates comparing the decision results of the primary strategy and the accompanying strategy within the same data acquisition request context.

[0071] Of course, the embodiments of this application do not limit the content of the preset data. The preset data is the context data corresponding to the decision acquisition request. The preset data includes the decision request identifier, and the preset data may also include at least one of the following: data representing account information; the data type of the data to be requested; and the data content and data range of the data to be requested.

[0072] Step S204. Feed back the decision result to the client.

[0073] The target data acquired by the target component is used to generate corresponding decision results. Only the decision results output by the tail component of the first component link reflect the decision results of the main strategy and are fed back to the client. The decision results output by the tail component of the second component link reflect the decision results of the accompanying strategy and are not used for actual business. They can be stored in the decision engine or in a preset storage device.

[0074] This application embodiment designs a target data request identifier generation operation and a data acquisition operation for the component that sends data acquisition requests. Both operations are idempotent, ensuring that neither the main strategy nor the accompanying strategy will encounter idempotency issues during operation. If the data acquisition request involves billing, there will be no duplicate billing issues. This avoids the cost of building a separate test environment for the accompanying strategy, the time consumption caused by the accompanying method running the main strategy and the accompanying strategy sequentially, and the duplicate billing issues caused by strategy accompanying, ensuring idempotency when the strategy makes multiple requests for the same data during accompanying.

[0075] This application does not limit the method for ensuring the idempotency of data acquisition operations. In one exemplary implementation, please refer to... Figure 3 The flowchart illustrates a method for data acquisition operations according to an embodiment of this application. The step of performing a data acquisition operation based on the target data request identifier to obtain target data for generating decision results includes:

[0076] S301. Generate a corresponding data acquisition request based on the target data request identifier; issue a locking request based on the data acquisition request.

[0077] This application does not limit the locking request; it can be used to acquire distributed locks, single-checked locks, or double-checked locks, etc. For example, the locking request can acquire a Redis lock, that is, the locking request can be expressed as a Set Redis lock. Redis is an open-source, high-performance key-value database that supports various data structures, such as strings, hashes, lists, sets, and sorted sets. Redis is also often used to implement distributed locks because it provides atomic operations, guaranteeing data consistency. When attempting to acquire a lock, the SET command is used to set a key-value pair with a unique key name. If the key does not exist, the SET command will execute successfully, and the lock will be acquired. If the key already exists, waiting is required. To prevent the lock from being never released, Redis locks typically have an expiration time. This can be achieved using the EX or PX options of the SET command, representing the expiration time (in seconds or milliseconds), respectively.

[0078] In embodiment S301 of this application, a Set Redis lock is used to uniquely acquire a resource for a data acquisition request corresponding to the target data request identifier. Other data acquisition requests with the same target data request identifier cannot obtain the resource and therefore cannot be executed, thus preventing duplicate billing. This achieves the first layer of idempotency protection.

[0079] Please refer to Figure 4This diagram illustrates a method for data acquisition operations according to an embodiment of this application. Regardless of whether it's a primary strategy or a secondary strategy, their synchronous execution may request the same target data, potentially generating the same preset data multiple times and producing the same target data request identifier. This results in multiple identical data acquisition requests. When these data requests are processed, they are treated as identical requests and processed idempotently, thus achieving request merging. When any data acquisition request with a target data request identifier is processed, it first performs a Set Redis lock on it.

[0080] S302. If the lock is successfully acquired within a first preset time, the cache is queried based on the target data request identifier, and the cache record in the cache includes the request identifier and the corresponding response data.

[0081] This application does not limit the first preset time; it can be set according to actual conditions. If the lock is not successfully acquired within the first preset time, the process continues to wait. This application does not allow responding to data acquisition requests without acquiring the lock, to ensure idempotency. In an exemplary embodiment, if the lock is not successfully acquired within the first preset time, the step of performing the data acquisition operation based on the target data request identifier to obtain the target data used to generate the decision result is re-executed after a second preset time interval. This application does not limit the second preset time; it can be set according to actual conditions.

[0082] S303. If a cache record containing the target data request identifier exists in the cache, the response data in the cache record is used as the response data for the data acquisition request, and the response data is the target data; the lock is released for the data acquisition request.

[0083] If a cached record containing the target data request identifier exists, it means that other data retrieval requests for the same target data request identifier have already been responded to, and the third-party service or decision engine has already provided response data. Therefore, it is unnecessary to send the same data retrieval request to the third-party service or decision engine again; only the response data in the cached record needs to be used. This response data is then returned to the target component as the feedback result of this data retrieval request, and the lock on the data retrieval request is released. Thus, in this case, it successfully prevents the sending of another data retrieval request for the same data to the third-party service or decision engine, ensuring idempotency.

[0084] S304. If no cache record containing the target data request identifier exists in the cache, the data acquisition request is sent to a third-party service or the decision engine; if response data is received from the third-party service or the decision engine, the response data is used as the target data, and a target cache record is generated based on the target data request identifier and the response data, and the target cache record is stored in the cache; the lock is released for the data acquisition request.

[0085] If no cache record containing the target data request identifier exists in the cache, it indicates that other data retrieval requests with the same target data request identifier have not been responded to, and the third-party service or decision engine has not provided response data. Therefore, a data retrieval request is sent to the third-party service or decision engine for the first time. Furthermore, a target cache record is generated based on the received response data. This ensures that subsequent data retrieval requests containing the same target data request identifier can be directly retrieved from the cache, preventing the issuance of a separate data retrieval request to the third-party service or decision engine and avoiding duplicate billing.

[0086] Please refer to Figure 4 If a cache record containing the target data request identifier exists in the cache, the target component can be directly returned the data from the cache to obtain the target data. If no cache record containing the target data request identifier exists in the cache, a data retrieval request must be sent to a third-party service or decision engine to obtain the target data, and the Redis lock is released after obtaining the target data.

[0087] In one implementation, before generating a target cache record based on the target data request identifier and the response data, the method further includes: querying the cache based on the target data request identifier; and deleting the cache record containing the target data request identifier if a cache record with the target data request identifier already exists in the cache. This implementation takes into account high-concurrency scenarios where, if concurrency is too high and two data retrieval requests with the same target data request identifier are issued at very close times, occasional lock failures may occur. This could result in a data retrieval request being sent to a third-party service or decision engine even if the response data corresponding to the target data request identifier exists in the cache, thus obtaining the latest response data. While idempotency is violated in this case, it is an extreme situation. This implementation ensures that in this extreme case, the cache only records the latest response data for the target data request identifier, mitigating the adverse effects of this extreme situation.

[0088] This application proposes a double-checked locking technique to address high-concurrency scenarios where, if concurrency is excessively high and two data acquisition requests with the same target data request identifier are issued at very close times, ordinary locking techniques may occasionally fail. To reduce the probability of locking failure, this application proposes using a double-checked locking technique. Please refer to... Figure 5 This diagram illustrates the locking request response process in an embodiment of this application. The step of issuing a locking request based on the data acquisition request includes:

[0089] S501. Check the lock status of the data acquisition request within a third preset time period, wherein the third preset time period is less than the first preset time period.

[0090] This application does not impose a limit on the third preset time; it can be set according to the actual situation.

[0091] S502. If the lock status indication fails to be locked, the data acquisition request is added to the synchronization block. The synchronization block is used to check the lock status of the data acquisition request again and ensure that it is not locked by components other than the synchronization block. If the data acquisition request fails to be locked in the synchronization block, a locking operation is performed on the data acquisition request.

[0092] This embodiment performs two lock state checks, thus embodying a double-checked locking mechanism that improves performance and avoids unnecessary lock contention. The double-checked locking ensures that only one request from a target component can enter the synchronization block at any given time, thereby preventing data inconsistency. For example, if multiple identical requests from multiple target components attempt to acquire the lock simultaneously, double-checked locking effectively prevents lock failure. The locking scheme in this embodiment ensures that in high-concurrency situations where multiple requests are issued close together, only one request can be responded to, reducing the probability of lock failure.

[0093] The following are embodiments of the apparatus of this application, which can be used to execute embodiments of the method of this application. For details not disclosed in the apparatus embodiments of this application, please refer to the embodiments of the method of this application.

[0094] Please refer to Figure 6 This diagram illustrates a block diagram of a request processing apparatus according to an embodiment of this application. The apparatus has the function of implementing the above-described request processing method; this function can be implemented in hardware or by hardware executing corresponding software. The apparatus can be a computer device or can be installed within a computer device. The apparatus may include a logical component running on a decision engine, which synchronously runs a main strategy and a follower strategy. The apparatus may include:

[0095] The target request acquisition module 601 is used to generate a corresponding decision request identifier when a target request is received from a client. The target request is used to trigger the decision engine to output a corresponding decision result.

[0096] Decision engine execution module 602 is used to perform the following operations:

[0097] A decision acquisition request is generated based on the decision request identifier, and the decision acquisition request is sent to the head component of the first component link, triggering the first component link to make a decision based on the main strategy according to the topology corresponding to the main strategy, until the tail of the first component link outputs the decision result;

[0098] The decision acquisition request is sent to the head component in the second component link, triggering the second component link to make a decision based on the running strategy according to the topology corresponding to the running strategy;

[0099] When the target component receives preset data, it uses the preset data to perform a target data request identifier generation operation to obtain a target data request identifier; based on the target data request identifier, it performs a data acquisition operation to obtain target data for generating decision results. The target component is the component in the first component link or the second component link used to request data. Both the target data request identifier generation operation and the data acquisition operation are idempotent operations.

[0100] The decision result is then fed back to the client.

[0101] In one exemplary implementation, the target component is used to send a data acquisition request to a third-party service; or, the target component is used to send a data acquisition request for internal data to the decision engine itself.

[0102] In one exemplary embodiment, the preset data is the context data corresponding to the decision acquisition request. The preset data includes the decision request identifier and also includes at least one of the following: data representing account information; the data type of the data to be requested; and the data content and data range of the data to be requested.

[0103] In one exemplary embodiment, the decision engine execution module 602 is configured to perform the following operations:

[0104] Based on the target data request identifier, a corresponding data acquisition request is generated;

[0105] A lock request is issued based on the data acquisition request;

[0106] If the lock is successfully acquired within a first preset time, the cache is queried based on the target data request identifier, and the cache record in the cache includes the request identifier and the corresponding response data;

[0107] If a cache record containing the target data request identifier exists in the cache, the response data in the cache record is used as the response data for the data retrieval request, and the response data is the target data; the lock is released for the data retrieval request.

[0108] In one exemplary embodiment, the decision engine execution module 602 is configured to perform the following operations:

[0109] If no cache record containing the target data request identifier exists in the cache, the data retrieval request will be sent to a third-party service or the decision engine.

[0110] Upon receiving response data from the third-party service or the decision engine, the response data is used as the target data, and a target cache record is generated based on the target data request identifier and the response data, and the target cache record is stored in the cache.

[0111] Release the lock on the data acquisition request.

[0112] In one exemplary embodiment, the decision engine execution module 602 is configured to perform the following operations:

[0113] The cache is queried based on the target data request identifier;

[0114] If a cache record containing the target data request identifier exists in the cache, delete the cache record containing the target data request identifier.

[0115] In one exemplary embodiment, the decision engine execution module 602 is configured to perform the following operations:

[0116] If the lock is not successfully acquired within the first preset time, the step of re-executing the data acquisition operation based on the target data request identifier to obtain the target data used to generate the decision result is executed after a second preset time interval.

[0117] In one exemplary embodiment, the decision engine execution module 602 is configured to perform the following operations:

[0118] The lock status of the data acquisition request is checked within a third preset time period, which is less than the first preset time period;

[0119] If the lock status indication fails to be locked, the data acquisition request is added to the synchronization block. The synchronization block is used to check the lock status of the data acquisition request again and ensure that it is not locked by components other than the synchronization block.

[0120] If the data acquisition request fails to acquire a lock in the synchronization block, a locking operation is performed on the data acquisition request. It should be noted that the apparatus provided in the above embodiments is only illustrated by the division of the above functional modules. In practical applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above. Furthermore, the apparatus and method embodiments provided in the above embodiments belong to the same concept, and their specific implementation process is detailed in the method embodiments, which will not be repeated here.

[0121] Please refer to Figure 7 This illustrates a structural block diagram of a computer device provided in one embodiment of this application, used to execute the above-described request processing method. Specifically:

[0122] Computer device 700 includes a central processing unit (CPU) 701, a system memory 704 including random access memory (RAM) 702 and read-only memory (ROM) 703, and a system bus 705 connecting the system memory 704 and the CPU 701. Computer device 700 also includes a basic input / output system (I / O system) 706 that facilitates information transfer between various devices within the computer, and a mass storage device 707 for storing the operating system 713, application programs 714, and other program modules 715.

[0123] The basic input / output system 706 includes a display 708 for displaying information and an input device 709 for user input, such as a mouse or keyboard. Both the display 708 and the input device 709 are connected to the central processing unit 701 via an input / output controller 710 connected to the system bus 705. The basic input / output system 706 may also include the input / output controller 710 for receiving and processing input from multiple other devices such as a keyboard, mouse, or electronic stylus. Similarly, the input / output controller 710 also provides output to a display screen, printer, or other types of output devices.

[0124] Mass storage device 707 is connected to central processing unit 701 via a mass storage controller (not shown) connected to system bus 705. Mass storage device 707 and its associated computer-readable media provide non-volatile storage for computer device 700. That is, mass storage device 707 may include computer-readable media (not shown) such as hard disk or CD-ROM (CompactDisc Read-Only Memory) drive.

[0125] Without loss of generality, computer-readable media can include computer storage media and communication media. Computer storage media include volatile and non-volatile, removable and non-removable media implemented using any method or technology for storing information such as computer-readable instructions, data structures, program modules, or other data. Computer storage media include RAM, ROM, EPROM (Erasable Programmable Read Only Memory), EEPROM (Electrically Erasable Programmable Read Only Memory), flash memory or other solid-state storage technologies, CD-ROM, DVD (Digital Video Disc) or other optical storage, magnetic tape cassettes, magnetic tape, disk storage, or other magnetic storage devices. Of course, those skilled in the art will recognize that computer storage media are not limited to the above-mentioned types. The system memory 704 and mass storage device 707 described above can be collectively referred to as memory.

[0126] According to various embodiments of this application, the computer device 700 can also be connected to a remote computer on a network, such as the Internet, for operation. That is, the computer device 700 can be connected to a network 712 via a network interface unit 711 connected to the system bus 705, or the network interface unit 711 can be used to connect to other types of networks or remote computer systems (not shown).

[0127] The aforementioned memory also includes a computer program stored in the memory and configured to be executed by one or more processors to implement the aforementioned request processing method.

[0128] In an exemplary embodiment, a computer-readable storage medium is also provided, which stores at least one instruction, at least one program, code set, or instruction set, wherein the at least one instruction, at least one program, code set, or instruction set is executed by a processor to implement the request processing method.

[0129] Specifically, the method is applied to a decision engine, which synchronously runs a main strategy and a follow-up strategy in a production environment. The method includes:

[0130] Upon receiving a target request from a client, a corresponding decision request identifier is generated, and the target request is used to trigger the decision engine to output the corresponding decision result;

[0131] A decision acquisition request is generated based on the decision request identifier, and the decision acquisition request is sent to the head component of the first component link, triggering the first component link to make a decision based on the main strategy according to the topology corresponding to the main strategy, until the tail of the first component link outputs the decision result;

[0132] The decision acquisition request is sent to the head component in the second component link, triggering the second component link to make a decision based on the running strategy according to the topology corresponding to the running strategy;

[0133] When the target component receives preset data, it uses the preset data to perform a target data request identifier generation operation to obtain a target data request identifier; based on the target data request identifier, it performs a data acquisition operation to obtain target data for generating decision results. The target component is the component in the first component link or the second component link used to request data. Both the target data request identifier generation operation and the data acquisition operation are idempotent operations.

[0134] The decision result is then fed back to the client.

[0135] In one exemplary implementation, the target component is used to send a data acquisition request to a third-party service; or, the target component is used to send a data acquisition request for internal data to the decision engine itself.

[0136] In one exemplary embodiment, the preset data is the context data corresponding to the decision acquisition request. The preset data includes the decision request identifier and also includes at least one of the following: data representing account information; the data type of the data to be requested; and the data content and data range of the data to be requested.

[0137] In one exemplary implementation, the step of performing a data acquisition operation based on the target data request identifier to obtain target data for generating decision results includes:

[0138] Based on the target data request identifier, a corresponding data acquisition request is generated;

[0139] A lock request is issued based on the data acquisition request;

[0140] If the lock is successfully acquired within a first preset time, the cache is queried based on the target data request identifier, and the cache record in the cache includes the request identifier and the corresponding response data;

[0141] If a cache record containing the target data request identifier exists in the cache, the response data in the cache record is used as the response data for the data retrieval request, and the response data is the target data; the lock is released for the data retrieval request.

[0142] In one exemplary embodiment, the step of performing a data acquisition operation based on the target data request identifier to obtain target data for generating decision results further includes:

[0143] If no cache record containing the target data request identifier exists in the cache, the data retrieval request will be sent to a third-party service or the decision engine.

[0144] Upon receiving response data from the third-party service or the decision engine, the response data is used as the target data, and a target cache record is generated based on the target data request identifier and the response data, and the target cache record is stored in the cache.

[0145] Release the lock on the data acquisition request.

[0146] In one exemplary embodiment, before generating the target cache record based on the target data request identifier and the response data, the method further includes:

[0147] The cache is queried based on the target data request identifier;

[0148] If a cache record containing the target data request identifier exists in the cache, delete the cache record containing the target data request identifier.

[0149] In one exemplary embodiment, the step of performing a data acquisition operation based on the target data request identifier to obtain target data for generating decision results further includes:

[0150] If the lock is not successfully acquired within the first preset time, the step of re-executing the data acquisition operation based on the target data request identifier to obtain the target data used to generate the decision result is executed after a second preset time interval.

[0151] In one exemplary implementation, issuing a lock request based on the data acquisition request includes:

[0152] The lock status of the data acquisition request is checked within a third preset time period, which is less than the first preset time period;

[0153] If the lock status indication fails to be locked, the data acquisition request is added to the synchronization block. The synchronization block is used to check the lock status of the data acquisition request again and ensure that it is not locked by components other than the synchronization block.

[0154] If the data acquisition request fails to be locked in the synchronization block, a locking operation is performed on the data acquisition request.

[0155] Optionally, the computer-readable storage medium may include: ROM (Read Only Memory), RAM (Random Access Memory), SSD (Solid State Drives), or optical disc, etc. The random access memory may include ReRAM (Resistance Random Access Memory) and DRAM (Dynamic Random Access Memory).

[0156] In an exemplary embodiment, a computer program product or computer program is also provided, which includes computer instructions stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the computer device to perform the aforementioned request processing method.

[0157] It should be understood that "multiple" as used herein refers to two or more. "And / or" describes the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A alone, A and B simultaneously, or B alone. The character " / " generally indicates that the preceding and following related objects are in an "or" relationship. Furthermore, the step numbers described herein are merely illustrative of one possible execution order. In some other embodiments, the steps may not be executed in numerical order, such as two steps with different numbers being executed simultaneously, or two steps with different numbers being executed in the reverse order of the illustration. This application does not limit this.

[0158] In addition, in the specific embodiments of this application, data such as user information are involved. When the above embodiments of this application are applied to specific products or technologies, user permission or consent is required, and the collection, use and processing of related data must comply with the relevant laws, regulations and standards of the relevant countries and regions.

[0159] The above are merely exemplary embodiments of this application and are not intended to limit this application. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application shall be included within the protection scope of this application.

Claims

1. A request processing method, characterized in that, The method is applied to a decision engine, which synchronously runs a main strategy and a follow-up strategy in a production environment. The method includes: Upon receiving a target request from a client, a corresponding decision request identifier is generated, and the target request is used to trigger the decision engine to output the corresponding decision result; A decision acquisition request is generated based on the decision request identifier, and the decision acquisition request is sent to the head component of the first component link, triggering the first component link to make a decision based on the main strategy according to the topology corresponding to the main strategy, until the tail of the first component link outputs the decision result; The decision acquisition request is sent to the head component in the second component link, triggering the second component link to make a decision based on the running strategy according to the topology corresponding to the running strategy; When the target component receives preset data, it uses the preset data to perform a target data request identifier generation operation to obtain a target data request identifier; based on the target data request identifier, it performs a data acquisition operation to obtain target data for generating decision results. The target component is the component in the first component link or the second component link used to request data. Both the target data request identifier generation operation and the data acquisition operation are idempotent operations. The decision result is then fed back to the client.

2. The method according to claim 1, characterized in that, The target component is used to send a data acquisition request to a third-party service; or, the target component is used to send a data acquisition request for internal data to the decision engine itself.

3. The method according to claim 1 or 2, characterized in that, The step of performing a data acquisition operation based on the target data request identifier to obtain target data for generating decision results includes: Based on the target data request identifier, a corresponding data acquisition request is generated; A lock request is issued based on the data acquisition request; If the lock is successfully acquired within a first preset time, the cache is queried based on the target data request identifier, and the cache record in the cache includes the request identifier and the corresponding response data; If a cache record containing the target data request identifier exists in the cache, the response data in the cache record is used as the response data for the data retrieval request, and the response data is the target data; the lock is released for the data retrieval request.

4. The method according to claim 3, characterized in that, The step of performing a data acquisition operation based on the target data request identifier to obtain the target data used to generate decision results further includes: If no cache record containing the target data request identifier exists in the cache, the data retrieval request will be sent to a third-party service or the decision engine. Upon receiving response data from the third-party service or the decision engine, the response data is used as the target data, and a target cache record is generated based on the target data request identifier and the response data, and the target cache record is stored in the cache. Release the lock on the data acquisition request.

5. The method according to claim 4, characterized in that, Before generating the target cache record based on the target data request identifier and the response data, the method further includes: The cache is queried based on the target data request identifier; If a cache record containing the target data request identifier exists in the cache, delete the cache record containing the target data request identifier.

6. The method according to claim 3, characterized in that, The step of performing a data acquisition operation based on the target data request identifier to obtain the target data used to generate decision results further includes: If the lock is not successfully acquired within the first preset time, the step of re-executing the data acquisition operation based on the target data request identifier to obtain the target data used to generate the decision result is executed after a second preset time interval.

7. The method according to claim 3, characterized in that, The step of issuing a lock request based on the data acquisition request includes: The lock status of the data acquisition request is checked within a third preset time period, which is less than the first preset time period; If the lock status indication fails to be locked, the data acquisition request is added to the synchronization block. The synchronization block is used to check the lock status of the data acquisition request again and ensure that it is not locked by components other than the synchronization block. If the data acquisition request fails to be locked in the synchronization block, a locking operation is performed on the data acquisition request.

8. The method according to claim 1 or 2, characterized in that, The preset data is the context data corresponding to the decision acquisition request. The preset data includes the decision request identifier and also includes at least one of the following: data representing account information. The data type of the requested data; The data content and range of the data to be requested.

9. A request processing apparatus, characterized in that, The device is applied to a decision engine, which synchronously runs a main strategy and a follow-up strategy in a production environment. The device includes: The target request acquisition module is used to generate a corresponding decision request identifier when a target request is received from a client. The target request is used to trigger the decision engine to output the corresponding decision result. The decision engine execution module is used to perform the following operations: A decision acquisition request is generated based on the decision request identifier, and the decision acquisition request is sent to the head component of the first component link, triggering the first component link to make a decision based on the main strategy according to the topology corresponding to the main strategy, until the tail of the first component link outputs the decision result; The decision acquisition request is sent to the head component in the second component link, triggering the second component link to make a decision based on the running strategy according to the topology corresponding to the running strategy; When the target component receives preset data, it uses the preset data to perform a target data request identifier generation operation to obtain a target data request identifier; based on the target data request identifier, it performs a data acquisition operation to obtain target data for generating decision results. The target component is the component in the first component link or the second component link used to request data. Both the target data request identifier generation operation and the data acquisition operation are idempotent operations. The decision result is then fed back to the client.

10. A computer device, characterized in that, The computer device includes a processor and a memory, the memory storing at least one instruction, at least one program, a code set, or an instruction set, the at least one instruction, the at least one program, the code set, or the instruction set being loaded and executed by the processor to implement the request processing method as described in any one of claims 1 to 8.

11. A computer-readable storage medium, characterized in that, The storage medium stores at least one instruction, at least one program, code set, or instruction set, wherein the at least one instruction, the at least one program, the code set, or the instruction set is loaded and executed by a processor to implement the request processing method as described in any one of claims 1 to 8.

12. A computer program product, characterized in that, The computer program product includes computer instructions, the processor of the computer device reads the computer instructions, and the processor of the computer device executes the computer instructions to implement the request processing method as described in any one of claims 1 to 8.

Images