Popup strategy task processing method and device, equipment and medium

Abstract

The invention relates to the technical field of data processing, can be applied to business scenes such as financial science and technology and medical health, and discloses a popup strategy task processing method which comprises the following steps: defining a life cycle node of a popup queue in a task queue processing center, dividing a popup task into an independent execution thread task and a shared execution thread task according to priority, binding to life cycle nodes respectively; creating an exclusive policy execution assembly line in the independent execution thread, and creating an interruptible policy execution assembly line in the shared execution thread; a strategy execution state judgment node is arranged in the two strategy execution assembly lines, and a standby strategy execution assembly line is triggered when strategy execution is abnormal; and uniformly storing output data generated by the three policy execution assembly lines through a public data cache region. By setting the priority-based thread task binding mechanism and the strategy execution state judgment node, decoupling and exception handling automation of the pop-up window strategy execution process are realized, and the strategy maintenance cost is reduced.

Description

Technical Field

[0001] The present invention relates to the field of data processing technology, and in particular to a pop-up strategy task processing method, device, equipment and storage medium. Background Art

[0002] Existing pop-up policy task processing systems generally adopt a flat architecture design, typically integrated around a fixed policy configuration center, a scheduling engine, and a policy execution module. This results in a "large and comprehensive" centralized structure in the policy chain design. This structure offers certain efficiency advantages during initial deployment and unified management, but it has gradually exposed a series of technical bottlenecks as policy complexity increases and the demand for personalized configuration grows.

[0003] In the current fintech business landscape, pop-up strategies are often used to implement core functions such as dynamic marketing, risk warnings, and behavioral guidance. To improve user response rates and risk identification capabilities, business systems must continuously update policy configurations, adjust triggering rules, and optimize response logic. However, due to the tight coupling between policy processing modules and queue scheduling, task threads, and data storage in existing technologies, each policy rule change requires comprehensive regression testing and even system refactoring, increasing policy operation and maintenance costs and severely limiting business response flexibility.

[0004] In the healthcare sector, pop-up windows primarily serve functions such as clinical assistance reminders, medication risk warnings, and patient pathway intervention, placing higher demands on real-time performance, accuracy, and exceptional responsiveness. Existing pop-up policy systems lack fine-grained control over execution processes, making it difficult to effectively detect and intervene in changes in the status of different nodes in the policy chain. If a pop-up window executes abnormally or a policy fails, it cannot be blocked or switched to an alternative strategy before scheduling, impacting the continuity and stability of critical business processes and potentially interfering with physician operations or misleading patient behavior.

[0005] Furthermore, from a technical architecture perspective, the policy execution process in traditional pop-up policy solutions is typically deployed inline within business threads or scheduling nodes, lacking a modular decoupling mechanism. This tightly coupled design limits the flexible expansion and local upgrade capabilities of the policy chain, making it difficult to support the parallel execution of multiple policies, dynamic switching across multiple scenarios, and unified storage and sharing of policy data. Furthermore, it is unable to adapt to the complex requirements of policy operations and maintenance in the context of heterogeneous business operations.

[0006] In summary, existing pop-up policy technologies lack process decoupling, task scheduling flexibility, closed-loop exception handling, and unified data management. These technologies struggle to meet the growing demands for refined operations and rapid policy iteration in industries like finance and healthcare. As policy configuration scale expands and policy execution paths become increasingly complex, there's an urgent need for a new, scalable, reconfigurable, and perceptible pop-up policy architecture to achieve efficient and stable policy execution and data flow. Summary of the Invention

[0007] The main purpose of the present invention is to provide a pop-up policy task processing method, device, equipment and storage medium, aiming to solve the technical problems in the existing technology that the pop-up policy execution process has a high degree of coupling, lacks a thread separation mechanism based on task priority and a closed loop of judgment and response of policy exceptions, resulting in inflexible policy changes, delayed exception processing and inability to uniformly manage data.

[0008] To achieve the above objectives, the present invention provides a pop-up strategy task processing method, comprising:

[0009] Define the lifecycle nodes of the pop-up queue in the task queue processing center, including the pre-queue node and the post-queue node;

[0010] Divide pop-up tasks into independent execution thread tasks and shared execution thread tasks according to priority, and bind independent execution thread tasks to the node before entering the queue, and bind shared execution thread tasks to the node after leaving the queue;

[0011] Create an exclusive policy execution pipeline in an independent execution thread and an interruptible policy execution pipeline in a shared execution thread;

[0012] Setting a policy execution status judgment node in the exclusive policy execution pipeline and the interruptible policy execution pipeline;

[0013] When the policy execution status judgment node detects that the execution time of the current policy in the exclusive policy execution pipeline or the interruptible policy execution pipeline exceeds a preset threshold or the execution result returns a failure status, the backup policy execution pipeline is triggered;

[0014] The output data generated by the exclusive policy execution pipeline, the output data generated by the interruptible policy execution pipeline and the output data generated by the backup policy execution pipeline are uniformly stored through the public data cache.

[0015] Furthermore, to achieve the above-mentioned purpose, the present invention provides a pop-up strategy task processing device, comprising:

[0016] The queue node registration module is used to define the life cycle nodes of the pop-up queue in the task queue processing center. The life cycle nodes include the pre-queue node and the post-queue node.

[0017] The task allocation module is used to divide pop-up tasks into independent execution thread tasks and shared execution thread tasks according to priority, and bind the independent execution thread tasks to the node before entering the queue and the shared execution thread tasks to the node after leaving the queue;

[0018] A policy pipeline building module, used to create exclusive policy execution pipelines in independent execution threads and interruptible policy execution pipelines in shared execution threads;

[0019] A state judgment configuration module is used to set a policy execution state judgment node in the exclusive policy execution pipeline and the interruptible policy execution pipeline;

[0020] A backup strategy triggering module is configured to trigger a backup strategy execution pipeline when the strategy execution status judgment node detects that the execution time of the current strategy in the exclusive strategy execution pipeline or the interruptible strategy execution pipeline exceeds a preset threshold or the execution result returns a failure status;

[0021] The unified data storage module is used to uniformly store the output data generated by the exclusive policy execution pipeline, the output data generated by the interruptible policy execution pipeline and the output data generated by the backup policy execution pipeline through a public data cache area.

[0022] Furthermore, to achieve the above-mentioned purpose, the present invention also provides a computer device, which includes a memory, a processor, and a pop-up policy task handler stored in the memory and runnable on the processor. When the pop-up policy task handler is executed by the processor, the steps of the pop-up policy task processing method described above are implemented.

[0023] Furthermore, to achieve the above-mentioned purpose, the present invention also provides a computer-readable storage medium, on which a pop-up policy task processing program is stored, and when the pop-up policy task processing program is executed by the processor, the steps of the pop-up policy task processing method as described above are implemented.

[0024] Beneficial effects: The present invention relates to the field of data processing technology and can be applied to business scenarios such as financial technology and medical health. A method for processing pop-up policy tasks is disclosed, including: defining a life cycle node of a pop-up queue in a task queue processing center, dividing pop-up tasks into independent execution thread tasks and shared execution thread tasks according to priority, and binding them to life cycle nodes respectively; creating an exclusive policy execution pipeline in an independent execution thread, and creating an interruptible policy execution pipeline in a shared execution thread; setting a policy execution status judgment node in the two policy execution pipelines, and triggering a backup policy execution pipeline when the policy execution is abnormal; and uniformly storing the output data generated by the three policy execution pipelines through a public data cache area. The present invention realizes the decoupling of the pop-up policy execution process and the automation of exception handling by setting a priority-based thread task binding mechanism and a policy execution status judgment node, and improves the sharing and consistency of policy data through a unified data caching mechanism, thereby reducing the policy maintenance cost, improving the policy processing efficiency and the stability of the system. BRIEF DESCRIPTION OF THE DRAWINGS

[0025] The present invention will be further described below with reference to the accompanying drawings and embodiments, in which:

[0026] Figure 1 A schematic diagram of an application environment of a pop-up strategy task processing method according to an embodiment of the present invention;

[0027] Figure 2 This is a flow chart of an embodiment of a pop-up window strategy task processing method of the present invention;

[0028] Figure 3 This is a functional module diagram of a preferred embodiment of the pop-up strategy task processing device of the present invention;

[0029] Figure 4 A schematic diagram of the structure of a computer device according to an embodiment of the present invention;

[0030] Figure 5 FIG. 2 is another structural diagram of a computer device according to an embodiment of the present invention. DETAILED DESCRIPTION

[0031] It should be understood that the specific embodiments described herein are only used to explain the present invention and are not intended to limit the present invention.

[0032] The pop-up strategy task processing method provided by the embodiment of the present invention can be applied in the following situations: Figure 1In an application environment, the user terminal communicates with the server terminal through a network. The server terminal can define the life cycle node of the pop-up queue in the task queue processing center through the user terminal, and the pop-up tasks are divided into independent execution thread tasks and shared execution thread tasks according to priority, and are respectively bound to the life cycle nodes; an exclusive policy execution pipeline is created in the independent execution thread, and an interruptible policy execution pipeline is created in the shared execution thread; a policy execution status judgment node is set in the two policy execution pipelines, and the backup policy execution pipeline is triggered when the policy execution is abnormal; the output data generated by the three policy execution pipelines is uniformly stored in a public data cache area. The present invention realizes the decoupling of the pop-up policy execution process and the automation of exception handling by setting a priority-based thread task binding mechanism and a policy execution status judgment node, and improves the sharing and consistency of policy data through a unified data caching mechanism, thereby reducing the policy maintenance cost, improving the policy processing efficiency and the stability of the system. Among them, the user terminal can be but is not limited to various personal computers, laptops, smart phones, tablet computers and portable wearable devices. The server terminal can be implemented with an independent server or a server cluster composed of multiple servers. The present invention is described in detail below through specific embodiments.

[0033] See also Figure 2 , Figure 2 This is a flow chart of an embodiment of a pop-up strategy task processing method provided by the present invention. It should be noted that although a logical order is shown in the flow chart, in some cases, the steps shown or described may be performed in a different order than that shown here.

[0034] like Figure 2 As shown, the pop-up strategy task processing method proposed by the present invention includes the following steps:

[0035] S10, defining the lifecycle nodes of the pop-up queue in the task queue processing center, wherein the lifecycle nodes include a pre-queue node and a post-queue node;

[0036] In this embodiment, the life cycle nodes of the pop-up queue are defined in the task queue processing center. The core purpose is to standardize and structure the management process of the pop-up tasks so that the scheduling of tasks, policy loading and data synchronization have clear boundaries and control points. The task queue processing center is the main control module in the task scheduling system, which is usually used to receive pop-up tasks, coordinate resources, distribute policy processing procedures and control task status. The setting of the life cycle node is to set two processing anchor points with definite boundaries and scalability in the process control system of the task queue processing center to support the loading and unloading of policies and the pre-processing and post-processing of data.

[0037] The pre-queue node refers to the processing phase after a pop-up task is received but before it officially enters the scheduling queue. This phase is a key location for policy preprocessing logic. Typical implementations include analyzing the task source, user context, or terminal status before the task enters the queue, determining priority based on the task content, and attaching logical units such as pre-screening modules, user permission verification modules, and policy assembly modules to this node. This node supports dynamic policy injection, allowing policy modules to be switched, combined, or adjusted without affecting the core queue structure.

[0038] The post-queue node is the processing stage entered after a task completes its core policy execution logic and is dequeued. It primarily handles post-processing, such as recording policy hits, logging execution behavior, invoking asynchronous receipt mechanisms, or pushing data to data analysis modules. This node is typically implemented using event-driven or callback mechanisms, supporting connections to logging systems, performance evaluation systems, and downstream triggering modules.

[0039] The pre-queue and post-queue nodes form a logically closed loop for the entire pop-up task lifecycle, ensuring a clear division of labor and synchronization between policy processing, behavior tracking, and resource release. This configuration can be implemented using process engine modeling tools, a configurable scheduling system, or a custom hook system. This lifecycle node must be highly pluggable, scalable, and visually manageable.

[0040] One implementation method is to configure a task processing context structure for each pop-up task in the process control framework of the task queue processing center, in which a lifecycle node structure is reserved. The pre-queue node can trigger an event before the task is enqueued, and register the preprocessing function to the node to implement logical mounting. The processing function can support policy instantiation based on task meta-information, such as calling the priority evaluator to load the exclusive policy module according to the user's identity level and behavior trajectory. The post-queue node completes the result writing, calls the post-processing strategy chain, etc. through the asynchronous task completion callback method, and supports status reporting and exception archiving operations. The node can also be configured as a delayed trigger mechanism to alleviate the performance pressure of the main thread.

[0041] Lifecycle nodes can also be independently registered as plugins in the task scheduling center's hook management component, allowing for dynamic addition and deletion of policy chains and processing logic without modifying the core scheduling engine. Visual modeling can also be used to define different lifecycle processing templates for different types of pop-up tasks, and parameterize the node attachment logic with the policy management module.

[0042] Example: In healthcare scenarios, the design of pop-up queue lifecycle nodes directly impacts task processing stability and policy response timeliness. For example, for a pop-up task called "Key Indicator Abnormality Warning" in a chronic disease management system, a personalized health risk analysis module can be attached to the pre-queue node to dynamically determine the risk level based on the user's historical test records (such as blood pressure, blood sugar, and weight curves) and currently uploaded health data. If the result indicates a high abnormality level, the task is marked as high priority and injected into an exclusive policy execution channel. By binding a personalized policy loading module to this node, data normalization, policy module matching, and resource tagging can be completed before the task is officially queued. At the post-queue node, after the pop-up task is displayed, it can be connected to the health feedback collection system, where user interaction information (such as whether the task was viewed, whether it was delayed, and whether help was requested) is written as a behavior log to the health behavior database. This simultaneously triggers the generation of the next stage of the chronic disease follow-up plan, forming a closed-loop task chain based on the linkage of lifecycle nodes.

[0043] In financial business scenarios, such as the "Loan Approval Status Update" pop-up task triggered in the intelligent customer service system, the pre-queue node will assume the important responsibility of selecting the strategy path. The system can attach the user portrait module to this node and dynamically load the corresponding approval strategy configuration based on the user's credit score, loan product type, and past approval history. If the user is in the credit edge range, the system can directly trigger the risk control strategy nested processing before the queue entrance to avoid entering the standard queue path and affecting the response efficiency. The post-queue node is used for logging and exception feedback. For example, when the user clicks the "Appeal Entry" in the pop-up window, the interactive behavior will trigger the exception process channel at the post-queue node and synchronize it to the credit review manual intervention system to ensure the flexibility and closed-loop control of the approval path.

[0044] By defining and splitting the lifecycle nodes of the task scheduling process, the policy processing process of the pop-up task has a structured and scalable control boundary, which can effectively realize the plug-in management and logical decoupling of the policy module, and improve the reusability and flexibility of the pop-up policy system in multiple business scenarios.

[0045] S20, dividing the pop-up task into independent execution thread tasks and shared execution thread tasks according to priority, and binding the independent execution thread tasks to the node before entering the queue, and binding the shared execution thread tasks to the node after leaving the queue;

[0046] In this embodiment, a pop-up task generally refers to an information display operation that the system actively pushes at a specific point in time according to business rules. These tasks may have different scheduling and response requirements based on factors such as business urgency, execution time, and data dependency. In order to adapt to the execution characteristics of multiple types of pop-up tasks, classifying pop-up tasks according to priority becomes a key step. Priority determination can be set based on indicators such as response time expectations, strategic goal urgency, and user interaction expectation levels. For example, financial risk warnings and system abnormality recovery are high priority, while holiday marketing recommendations and product update reminders are low priority. Based on the priority results, tasks are further divided into independent execution thread tasks and shared execution thread tasks. Independent execution thread tasks usually require stable thread occupancy, fixed resource quotas, and less interruption possibilities, and are suitable for scenarios with high real-time and high reliability requirements; while shared execution thread tasks are suitable for scheduling and reuse in the thread pool to meet task scenarios with optimized resource utilization and strong fault tolerance.

[0047] Independent execution thread tasks are bound to the node before entering the queue, which means that such tasks already have an independent execution context and are bound to the policy processing module before entering the main task scheduling queue. This design allows tasks to complete policy loading, data parsing, and resource pre-allocation before queuing, reducing scheduling delays. The binding process can be implemented through task label mapping, thread pool resource isolation, and pre-processing module loading. In contrast, shared execution thread tasks are bound to the node after leaving the queue. Such tasks undergo standard sorting and queuing mechanisms in the main scheduling queue until they are released by the scheduler and then enter the execution channel. The binding mechanism is to attach the task to the corresponding post-processing module after leaving the queue, and it is scheduled for execution by the shared thread pool. This separate binding method effectively guarantees the timeliness of critical tasks and the resource reuse rate of non-critical tasks, and realizes differentiated control of pop-up window processing at the resource scheduling layer.

[0048] In the specific implementation, the priority determination basis can be based on the task type, policy source, user level and other fields contained in the metadata of the pop-up task. The system presets multiple priority levels, such as "high", "medium", "low" or numerical rating levels, and sets the response time threshold and the task impact range to determine the task type. When a task enters the scheduling system, the task is first classified as an independent execution thread task or a shared execution thread task through the judgment logic module, and written into different thread pool entries respectively. At the node before entering the queue, the message interceptor can be used to connect to the task identification service, and the policy module and parameter pre-binding processing are performed on high-priority tasks. After building a complete policy chain, the task status is marked as "schedulable". At the node after dequeuing, an asynchronous listening service is set to dynamically detect dequeued tasks, and the shared execution thread tasks are injected into the shared thread pool execution queue, and the corresponding policy component is called for processing. In the thread pool implementation, a fixed number of threads strategy can be used for independent thread pools, and an elastic scaling strategy can be used for shared thread pools to adapt to concurrent fluctuation scenarios.

[0049] Example: In the healthcare business, pop-up tasks for sudden high-risk warnings, such as abnormal ECG prompts and medication conflict warnings, usually need to be pushed to the doctor's workstation or patient terminal as soon as the data is reported, and are high-priority tasks. Such tasks are identified as independent execution thread tasks and bound to the node before entering the queue. Before entering the queue, the patient's medical history information and risk rule model are loaded, and the independent policy chain is triggered for initial judgment to reduce response delays. Tasks such as daily health check-in reminders and popular science article push are determined to be low-priority shared execution thread tasks. They wait in the queue until they are out of the queue and then call the shared policy module for execution, reducing the immediate pressure on system resources.

[0050] In fintech businesses, tasks such as temporary credit limit changes and transaction risk control anomaly alerts have strict time-sensitive requirements and are therefore classified as independent execution threads. Before entering the queue, the node immediately loads the user's credit profile and risk control model strategy, combining real-time transaction information to quickly make decisions and display a pop-up window. Month-end bill notifications and financial product recommendations, on the other hand, are shared execution threads. After leaving the queue, the node calls the marketing strategy component to complete the processing. This mechanism ensures timely response to critical business operations and efficient scheduling of routine business operations, meeting the dual requirements of real-time performance and stability in financial systems.

[0051] By differentiating the priorities of pop-up tasks and establishing an execution thread binding mechanism, we achieve refined task scheduling granularity, avoiding resource congestion and response delays caused by the unified queuing of all tasks. At the same time, independent execution thread tasks are prioritized and bound to policies and resources before queuing, significantly shortening the waiting time for critical tasks and improving task processing response speed and system stability. Shared execution thread tasks reuse thread resources for execution, improving thread utilization efficiency and system throughput, and effectively reducing overall scheduling resource consumption. This mechanism provides a solution for pop-up task scheduling in complex businesses that balances timeliness and resource economy.

[0052] S30, creating an exclusive policy execution pipeline in the independent execution thread and creating an interruptible policy execution pipeline in the shared execution thread;

[0053] In this embodiment, the policy execution pipeline refers to a linear executable structure composed of multiple policy units within the task processing architecture, used to perform step-by-step policy processing, state assessment, and control decisions for pop-up tasks. This pipeline features clear phase divisions, a fixed execution path, and independent node responsibilities. It is typically constructed in a serialized node format, with the data and control flows between nodes strictly dependent on the output of the previous node. Its design objective is to ensure that various policies can operate stably in a controllable and scalable manner under different priority and scheduling conditions, while also improving the flexibility of policy iteration and the observability of the policy execution process. This pipeline is generally divided into three categories: one is a policy execution pipeline bound to an independent execution thread, with exclusive resource access rights, specifically for processing high-priority, non-interruptible, or response-time-sensitive policies; one is a policy execution pipeline bound to a shared execution thread, suitable for processing fault-tolerant, non-critical path policies; and the other is a backup policy execution pipeline that exists as a disaster recovery mechanism, providing a fallback and backup processing logic when the aforementioned policy link fails. The policy nodes in each pipeline can include multiple stages such as pre-processing judgment, business condition judgment, policy rule execution, exception marking processing, context data update, etc. The modules in each stage can complete automatic configuration and response based on configuration files, real-time status or external interfaces.

[0054] For example, in healthcare systems, for tasks like displaying patient checkup alerts in pop-up windows, an exclusive policy execution pipeline might include nodes like user login status detection, disease risk model scoring, and privacy compliance verification. The order of these nodes is fixed and cannot be skipped. In financial services, an interruptible policy execution pipeline for marketing recommendation pop-up tasks might include policy nodes like user browsing behavior analysis, activity validity period verification, and risk control level matching. Some of these policy modules can be dynamically suspended or downgraded based on real-time system load. If these policy links fail during processing, such as when the risk control interface returns an exception or the model service becomes unavailable, a backup policy execution pipeline is triggered, using pre-set default rules to generate recommended pop-up content or directly blocking the pop-up, ensuring an uninterrupted user experience. Overall, the policy execution pipeline, as an orchestrated link for task policy processing, provides a clear structural carrier and scheduling control capabilities for the policy execution process, which is of great significance in terms of system stability, responsiveness, and scalability.

[0055] Building a stable and continuous policy processing flow within an independent execution thread focuses on ensuring that each policy can run in an orderly and uninterrupted manner with dedicated resources. This type of execution path is typically used in scenarios where processing tasks have high priority and require high results accuracy and processing atomicity. In practice, this processing flow can be organized in a linear topology, with each node representing a policy processing module with clear functionality, and modules connected in series with strict input-output logical dependencies. Whenever a pop-up task is assigned to an independent execution thread, it will pass through all policy processing nodes in a predetermined order, without support for jumps, interruptions, or dynamic changes, thus forming a closed path from policy loading to result output. Common operations in this path include risk parameter extraction, user status assessment, policy script execution, and rule expression determination. Each module passes control to the next module only after successfully completing its processing task.

[0056] In contrast, a processing path with a flexible structure is built in the shared execution thread to carry tasks with lower priority or acceptable intermediate failures. This type of path is usually composed of weakly coupled modules, and supports flexible scheduling capabilities such as state judgment, conditional jumps, and interrupt continuation during operation. During the construction process, the task path does not rely entirely on static process definitions, but dynamically decides whether to load certain policy modules based on the current context state of the task. For example, in the case of resource constraints or missing policy data, some modules will be dynamically skipped to ensure that the main process is not interrupted. In this type of path, each policy node can be equipped with a status monitor and a timeout logic unit to provide real-time feedback on whether the current node continues to execute or terminates processing based on the response time, resource status or return flag. In addition, policy priority labels and policy result default value mechanisms can be introduced to ensure that the functional closed loop of the overall process can be maintained even if some nodes fail.

[0057] To achieve scheduling isolation and operational constraints within the overall execution path, different thread pool policies and resource scheduling rules can be configured for independent and shared threads at the operating system level. Independent threads take precedence over shared threads in resource allocation and are submitted using a blocking strategy during execution to avoid jitter caused by resource competition. Shared threads are typically bound to an elastically scalable thread pool, allowing for the concurrent processing of multiple lightweight tasks, and the policy execution process supports non-blocking operations. The parallel existence of these two types of execution paths establishes a two-tiered policy-carrying system tailored to business importance and operational risk, enabling the system to provide both strong consistency guarantees and the concurrent processing capabilities for large-scale tasks.

[0058] This process design also supports error control and process self-repair based on runtime feedback. For example, in an independent execution path, once a policy anomaly or resource bottleneck is detected, a callback mechanism can be used to suspend the current thread and enter an alternate path. In a shared path, if policy execution fails, the default configuration or historical cached results can be returned to avoid affecting the main process. At the underlying implementation level, all policy modules are registered through standardized interfaces. When a task arrives, the scheduler dynamically loads the corresponding module set based on the task tag, enabling automatic assembly of the process and replacement of the smallest unit.

[0059] Example: In a healthcare system, when the emergency monitoring system detects a sudden increase in a patient's heart rate or a sharp drop in blood oxygen, it immediately triggers a pop-up alert and initiates an independent execution thread. The system then invokes an exclusive policy execution pipeline, sequentially executing the patient risk assessment strategy, the medical history analysis strategy, and the emergency procedure matching strategy. After all nodes are completed seamlessly, a high-priority pop-up window is pushed to the on-duty medical terminal. Throughout this entire process, no policy is skipped, ensuring the accuracy of the alert content and the feasibility of the recommended actions.

[0060] In the health science information push module, the system regularly detects user browsing habits, regional tags, device information, and other characteristics, and activates pop-up tasks through a shared execution thread. The system starts an interruptible strategy execution pipeline, sequentially trying marketing preference matching strategies, frequency control strategies, and time period adaptation strategies. If a strategy node responds with a timeout or the data source is unavailable, the node is automatically skipped and subsequent execution continues, ultimately determining whether to trigger a pop-up display. This ensures the continuity of business processes while reducing performance bottlenecks caused by system pressure.

[0061] In the financial industry, credit card risk interception uses independent execution threads and a dedicated policy execution pipeline to ensure that each credit decision fully evaluates multiple dimensions, including user transaction behavior, historical overdue payments, and the latest credit score. In marketing campaigns, the financial product recommendation process is completed through an interruptible policy execution pipeline, allowing for policy jumps or downgrades in the event of network fluctuations or missing policy parameters, thereby improving business resilience.

[0062] By building differentiated policy execution pipelines across different thread types, the pop-up policy processing system achieves enhanced execution efficiency and policy adaptability for diverse tasks. Exclusive policy execution pipelines ensure that high-priority tasks can run stably in an isolated environment, eliminating external interruptions and ensuring policy integrity and reliable results. Interruptible policy execution pipelines enhance the system's survivability in high-concurrency or abnormal environments. Through flexible control between policy nodes, they support task downgrade execution and fault-tolerant jumps, effectively reducing the risk of overall failure due to individual policy anomalies.

[0063] S40, setting a policy execution state judgment node in the exclusive policy execution pipeline and the interruptible policy execution pipeline;

[0064] In this embodiment, when processing policy execution processes in different threads, it is necessary to continuously perceive and respond to the status of the policy execution process. To this end, independent status judgment nodes are introduced in each policy execution path. These status judgment nodes are deployed in the exclusive policy execution pipeline and the interruptible policy execution pipeline, respectively, and are usually placed in the middle or end stage of the policy chain. Their purpose is to collect performance indicators of the task and make decisions when the policy execution is completed or about to be completed.

[0065] A status judgment node refers to a control unit with runtime monitoring capabilities. Its core functions include: recording the actual execution time of the policy, collecting the status code of the policy execution result, judging whether the configured failure condition has been met, triggering the exception flag and controlling the direction of the subsequent processing path. The judgment node set in the exclusive policy execution pipeline focuses on execution timeouts and serious failures. For example, when the policy execution time exceeds the maximum tolerance threshold (such as 100 milliseconds) or returns an unacceptable error code (such as non-idempotent error, service denial, etc.), the judgment node will immediately output an exception flag to notify the scheduling module to suspend the current task, switch to the backup link, or record it as a blocking event. The judgment node set in the interruptible policy execution pipeline pays more attention to the pattern of continuous failure, recovery capability assessment and partial exception tolerance. Its judgment criteria are relatively loose, allowing non-fatal errors to exist, but when the error code appears in a concentrated manner or the response delay is higher than the set percentile, the process correction mechanism will still be triggered.

[0066] A status judgment node typically includes multiple submodules: an execution time acquisition module, a failure status identification module, an anomaly attribution module, and a trigger controller. Each submodule can be flexibly enabled or parameterized based on configuration. For example, the execution time acquisition module can complete data sampling by injecting a timer or calling a middleware execution hook. The failure status identification module can match and compare the status field returned by the policy module with a preset set of error codes. The trigger controller then activates a backup policy link, records policy operation anomaly logs, or notifies the queue control center to perform task migration based on different types of judgment results.

[0067] The judgment node can be deployed inside the service in the form of a middleware plug-in, for example, embedded in the policy execution method in the form of an interceptor, observer or policy fragment, and bound to the asynchronous thread context. An object-oriented approach can also be used to encapsulate the state judgment logic as an independent monitoring component and inject it into the end of each policy path through an interface. For complex policy scenarios, configurable rules can also be used to dynamically set judgment thresholds, error code sets and processing strategies based on different policy types, such as setting stricter delay limits for risk-based policies and more relaxed failure retry logic for recommended policies. In addition, in a microservice architecture, these judgment nodes can be included in a unified console as part of the service governance framework for parameter distribution and result feedback.

[0068] By embedding a status judgment node in each policy processing path, fine-grained perception and controllable interruption of the policy execution process can be achieved, solving the problems of opaque policy execution status, slow response to exceptions, and difficulty in tracking link degradation, thereby improving the policy system's elastic processing capabilities and exception closed-loop capabilities.

[0069] S50, when the policy execution status judgment node detects that the execution time of the current policy in the exclusive policy execution pipeline or the interruptible policy execution pipeline exceeds a preset threshold or the execution result returns a failure status, triggering the backup policy execution pipeline;

[0070] In this embodiment, the core purpose of introducing a backup policy processing mechanism into the policy scheduling architecture is to ensure the business continuity of the system and the stability of the pop-up window response on the user side. When the policy execution status judgment node identifies during the monitoring process that the policy execution behavior no longer meets the established operating specifications, that is, when an abnormal execution time or an execution failure signal occurs, the system needs to have the ability to quickly switch to other stable policy processes. The monitoring of execution time is usually based on a set time threshold, which is a tolerance limit preset by the system for different policy types, thread scheduling structures or terminal response requirements. For example, for exclusive policy execution pipelines, such tasks often involve key business judgments (such as identity authentication, risk control scoring, etc.), so their time thresholds are often controlled more strictly, usually not exceeding 100 milliseconds. The interruptible policy execution pipeline usually carries relatively secondary display logic (such as activity recommendations, page animations, etc.), and its threshold setting is relatively loose, which may reach 200 to 500 milliseconds.

[0071] The identification of the failure status is based on the comparison of the status code, exception code or diagnostic field of the response body returned by the policy execution module. The judgment node will call the failure status identification module to compare whether the status value is within the pre-configured failure code set. Once it is hit, the current policy is deemed unavailable. Regardless of whether it is a timeout or a failure judgment, once the trigger condition is met, the status judgment node will immediately activate the backup policy execution control logic. This control logic will initiate a policy flow request through the scheduling center, guide the task to jump to the backup policy execution pipeline, and synchronously transfer some necessary context information, such as the original request parameters, some processing intermediate states, user identification, etc., to maintain the continuity and consistency of the backup processing logic.

[0072] The backup policy execution pipeline itself is a lightweight, stable, and fault-tolerant execution path. It typically does not rely on real-time external services, but instead generates pop-up responses based on local cache, default configurations, or preset templates. After the trigger action occurs, the policy switch is typically completed within a few milliseconds to avoid long task blocking. Throughout this process, a clear signal binding relationship exists between the policy judgment node and the backup policy execution process, typically implementing state transitions using event-driven mechanisms or asynchronous callbacks.

[0073] During the implementation process, a monitoring mechanism can be adopted between the status judgment node and the backup strategy execution pipeline. For example, after the judgment node detects a timeout or failure event, it sends a task switching signal to the queue control center. The control center reallocates thread resources and schedules the backup strategy module on the premise that the current task has not yet output the result. In addition, to ensure the accuracy of the judgment, the start and end time of each strategy execution can be marked by the link tracking system, and the timer can be combined to achieve millisecond-level monitoring capabilities. The recognition of failure codes can be dynamically loaded based on the configuration file, or it can be achieved by registering and monitoring the response events output by the business service. The configuration of the backup strategy execution pipeline can dynamically load different templates according to the business type, such as loading the default discount plan in the marketing strategy scenario, and loading fixed prompt content in the medical strategy scenario.

[0074] You can also set different trigger priorities and fallback sequences based on policy types. For example, if a task is marked as "high risk" or "critical user," you can force the backup policy branch to take precedence and disable the retry channel that interrupts the policy. You can also design a feedback marking mechanism after the backup policy is processed to record whether the task falls into an abnormal path for subsequent operational review and analysis.

[0075] By defining fault-sensing rules within the policy execution status judgment node and linking them to a backup policy execution process, we can effectively avoid user blocking, page lag, or pop-up policy failures caused by policy execution anomalies. This significantly improves the policy system's fault tolerance and business continuity, while also enhancing the overall user experience. This ensures uninterrupted basic pop-up responses, especially in environments with network fluctuations, occasional service failures, or high concurrency.

[0076] S60 , uniformly storing the output data generated by the exclusive policy execution pipeline, the output data generated by the interruptible policy execution pipeline, and the output data generated by the backup policy execution pipeline through a public data cache.

[0077] In this embodiment, to support rapid response and precise configuration of pop-up behaviors, the data generated by different policy branches during execution needs to be integrated into a controllable and manageable data processing system. To this end, a public data cache is introduced as a unified data storage area, serving as a central cache and state coordination function within the system architecture.

[0078] The scope of output data covers three types of policy processing paths: the first type is the result data generated by the exclusive policy execution pipeline, which usually includes risk assessment conclusions, identity identification tags or business trigger signals that are strongly related to the user's unique identifier. This type of data has high priority, strong consistency and low latency requirements; the second type is the behavioral feedback information generated by the interruptible policy execution pipeline, such as frequency control records, dynamic advertising parameters or scene degradation configuration. Its data has the characteristics of weak context binding and high update frequency; the third type is the output data of the backup policy execution pipeline, which is mainly used for fault fallback, backup display, status prompts and other needs. Its data content is relatively stable but must have historical compatibility and version management capabilities.

[0079] To aggregate these three types of data into a common data cache for unified management, it's first necessary to logically structure and classify the output data from different policy sources into separate storage partitions, shared storage partitions, and version rollback storage partitions. These storage partitions are not physically isolated; instead, they are grouped and managed within the logical cache space through a label-based isolation mechanism. Before being written, each set of data must be encapsulated in a unified data storage format. This format includes a generation timestamp, policy type identifier, data hash value, and output data version identifier, meeting core requirements such as data integrity verification, source tracking, and version comparison.

[0080] Data storage operations must be integrated with the encryption process for unified storage. The encryption process typically relies on asymmetric encryption mechanisms or content hash-based signature generation to ensure secure data transmission and persistent storage. The final storage results are synchronized with the global index table via the write interface. The index content describes the mapping between the physical path of each data item, the policy type identifier, and the output data version identifier, enabling subsequent rapid retrieval and version traceability.

[0081] Furthermore, to ensure the security of multi-threaded concurrent data access, different levels of access control policies are applied to different partitions. Exclusive read-write locks are enabled on the independent storage partition where the output data of the exclusive strategy resides, limiting write access to the exclusive strategy thread and preventing resource conflicts. Because the output data of the interruptible and backup strategies is shared, their storage partitions utilize shared read-write locks. This implements multi-threaded read-only access and limits concurrent writes, improving system responsiveness and ensuring data consistency.

[0082] This can be designed based on an in-memory distributed cache component such as Redis or RocksDB, with logical partition keys set to identify and isolate the three types of policy data. The storage format can use Protocol Buffers or a custom serialization protocol to describe and encapsulate each piece of data. Before each data write, a hash function such as SHA-256 is executed on the data to generate a checksum. This, combined with the output data version identifier, forms a complete index entry and is written to a global index table. This table can be persisted to a lightweight metadata repository such as SQLite or stored in an in-memory cache module. This mechanism can also be deployed on service edge nodes or CDN edge services, allowing partial policy execution results to be cached centrally on nodes close to users, thereby improving the response time of terminal pop-up windows. For the management of historical version data, an automatic version number archiving strategy can be implemented to periodically roll over data and retain the most recent valid versions to prevent the long-term accumulation of redundant data. In some high-frequency scenarios, a delayed batch write strategy can be implemented. When policy output data traffic surges, it is first written to the in-memory buffer and then encrypted and written to the cache in batches to reduce write pressure and improve system processing efficiency.

[0083] Example: In a healthcare data service scenario, the output data generated by the exclusive policy execution pipeline may include high-risk drug reminders triggered by patient tags. This information needs to be quickly pushed to a pop-up window on the main interface and accurately recorded. This data is written to the cache in a separate storage partition and an exclusive write lock is set to ensure the uniqueness and traceability of the information pushed.

[0084] The interruptible policy path may be responsible for generating loading speed optimization parameters or interface degradation information based on the user device status. This information is stored in a shared storage partition and supports concurrent reading through a shared lock mechanism to serve the dynamic loading of multiple user interface layers.

[0085] When a network anomaly or algorithm service interruption causes the primary strategy to fail, the backup strategy path triggers a fixed prompt message, such as "Current service is undergoing maintenance, please try again later," and writes it to the version rollback partition for unified backup processing. By managing the unified storage and isolated access of these three types of data in a common data cache, we ensure the stability and consistency of policy responses in various scenarios.

[0086] In financial business systems, risk scoring results are generated and stored in a separate partition, where only risk control threads can modify them. Advertising recommendation strategies are generated through interruptible processes and stored in a shared partition, where user profile analysis threads can read them in parallel to support the next recommendation decision. If the scoring process fails, the backup strategy process automatically switches to outputting a fixed prompt, such as "Personalized service is temporarily unavailable," which is also centrally managed within the cache. This mechanism fully demonstrates the core coordination role of the public data cache in complex business strategy environments.

[0087] By building a common data cache and integrating the output results of multiple policies into a structured management process, we can centrally manage and rapidly call pop-up policy results across multiple threads and policy modules, significantly improving the system's data consistency, response efficiency, and version control capabilities. Data output from different policy paths can be efficiently orchestrated within a unified structure, significantly reducing data transmission overhead and storage clutter associated with cross-policy execution. This facilitates subsequent task scheduling, configuration verification, and log review, further enhancing the robustness and maintainability of the policy system.

[0088] The present invention relates to the field of data processing technology and can be applied to business scenarios such as financial technology and medical health. A pop-up policy task processing method is disclosed, comprising: defining a lifecycle node of a pop-up queue in a task queue processing center, dividing pop-up tasks into independent execution thread tasks and shared execution thread tasks according to priority, and binding them to lifecycle nodes respectively; creating an exclusive policy execution pipeline in the independent execution thread, and creating an interruptible policy execution pipeline in the shared execution thread; setting a policy execution status judgment node in the two policy execution pipelines, and triggering a backup policy execution pipeline when the policy execution is abnormal; and uniformly storing the output data generated by the three policy execution pipelines through a public data cache area. The present invention realizes the decoupling of the pop-up policy execution process and the automation of exception handling by setting a priority-based thread task binding mechanism and a policy execution status judgment node, and improves the sharing and consistency of policy data through a unified data caching mechanism, thereby reducing the policy maintenance cost, improving the policy processing efficiency and the stability of the system.

[0089] In one embodiment, the above step S20 includes:

[0090] S201, setting a response time threshold for a pop-up task, and determining the response time from triggering the pop-up task to expected feedback;

[0091] S202, marking a pop-up task with a response time less than the response time threshold as a high-priority independent execution thread task, and marking a pop-up task with a response time greater than or equal to the response time threshold as a low-priority shared execution thread task;

[0092] S203, allocating exclusive memory resources and a fixed thread pool capacity to the high-priority independent execution thread task, and binding the high-priority independent execution thread task to the pre-processing module of the node before entering the queue;

[0093] S204, allocating shared memory resources and dynamic thread pool capacity to the low-priority shared execution thread task, and binding the low-priority shared execution thread task to the post-processing module of the post-dequeue node;

[0094] S205: Setting a resource locking flag for a high-priority independent execution thread task in the task queue processing center.

[0095] In this embodiment, separating the priorities of tasks is not only a reflection of the resource management strategy, but also the technical core of the service quality control mechanism. Pop-up tasks have a strong time-sensitive distinction in business operations. For example, the execution requirements of clinical emergency reminders and ordinary health advice pop-ups are completely different, so a unified processing thread model cannot be used to schedule execution. The introduction of a priority-based separation model is to dynamically determine the execution path and resource acquisition mode according to the response time limit characteristics of the task, thereby realizing intelligent diversion at the scheduling layer.

[0096] Priority is determined by a response time threshold, which can be statically configured or dynamically adjusted during system operation. It can be parameterized based on business requirements or strategically updated by automatically learning the response time distribution of user behavior through a model. Response time does not simply refer to the time required for task processing, but rather the complete time chain from when the scheduling system receives the task trigger instruction to when the target user terminal completes interaction preparation. This typically includes multiple stages, such as policy invocation, data loading, and user rendering.

[0097] After comparing task response times against a threshold, tasks with response times significantly below the threshold can be identified as high-priority tasks. These tasks require preemption of system computing resources, policy model caches, and data paths, so their scheduling requires clear thread isolation and resource exclusivity mechanisms. Placing them in independent execution threads completely avoids thread blocking interference between tasks, ensuring that these tasks are not impacted by competition from lower-priority tasks.

[0098] To ensure deterministic execution of independent tasks, they must be bound to the node before they are queued. This is the earliest control node in the entire task queue lifecycle, before large-scale resource allocation and multi-thread scheduling begin, providing greater controllability. The binding logic goes beyond physical thread mapping and also includes the injection of pre-execution processes, such as initializing the context, loading the policy model, and establishing a temporary user session. This allows the task to complete most of its preparations before actual execution, improving overall responsiveness.

[0099] Low-priority tasks are classified as shared execution thread tasks because they have a higher tolerance for latency. The system can schedule them for execution when resources are plentiful and automatically downgrade them when resources are scarce. Binding them to the post-dequeue node facilitates post-delay processing logic, alleviating pressure on the main task and allowing batch scheduling during post-processing to improve thread utilization.

[0100] Binding a node before or after a queue is not just a logical tag; instead, the node scheduler within the dispatch center controls the mapping between nodes and thread pools. For example, a node before a queue can be configured with a pre-policy execution hook to preload policy rules, while a node after a queue can be configured with a delayed task loader to implement non-blocking initialization of pop-up display elements.

[0101] After binding a node, high-priority tasks must also set a resource lock flag in the task management center. This locking mechanism enables pre-allocation of hardware resources, such as allocating independent cache pages, assigning non-shared CPU core execution, and locking core threads in the thread pool, ensuring that such tasks can still meet real-time response requirements when the system load fluctuates. The implementation of the lock flag is usually combined with thread scheduling strategies, such as setting thread priorities and configuring thread preemption rights to achieve resource-level isolation. It can even be connected to the operating system's thread scheduler to achieve cross-application resource control.

[0102] Furthermore, task separation introduces resource pool configuration strategies. Independent execution threads are typically assigned a fixed-capacity thread pool to prevent resource waste or starvation caused by an uncertain thread count. Shared execution threads, on the other hand, correspond to elastic thread pools, which support dynamic scaling and automatically adjust the number of threads and resource consumption based on the current load.

[0103] In specific implementations, the system can incorporate a response time collection component into the task scheduling module. After task completion, the system records the actual response time in real time, compares it against a preset response time threshold, and automatically assigns the task priority. Priority tags can be expressed using a tag field in the task's metadata, such as "priority=high" or "priority=low." The scheduler then interprets this field to determine whether the task should be assigned to an independent or shared thread pool. Exclusive memory resources can be instantiated using thread-bound memory blocks, for example, through thread-private memory space provided by the operating system or by binding to physical CPU cache. Fixed thread pools can have a fixed number of threads and prohibit dynamic capacity expansion to avoid resource contention. Shared memory resources utilize a unified memory management mechanism, such as heap space sharing, in conjunction with a dynamic thread pool framework (such as Java's ForkJoinPool or a custom thread pool management component) to dynamically create and recycle thread instances. Before a task is queued, the scheduling center inserts high-priority tasks into the pre-queue node processing list based on their priority tags and invokes a preprocessing module to load the model and initialize the context. The preprocessing module can utilize a lightweight rule engine or cache warming mechanism to reduce processing latency. After completing the main processing flow, low-priority tasks enter the post-processing module through the dequeue node, which loads scenario parameters and completes policy invocation or data population. Resource locking can be implemented through Boolean flags or status flags. For example, setting the exclusive_lock=true flag for high-priority tasks locks the corresponding resource slot in the task execution thread scheduler, preventing shared tasks from occupying the same thread resources and enhancing the system's scheduling controllability.

[0104] This embodiment prioritizes pop-up tasks based on response time and establishes a mechanism for separating independent and shared execution threads. This significantly improves the policy response time of high-priority tasks while reducing the impact of low-priority tasks on preempting system resources. The resource locking mechanism, thread pool capacity configuration, and module binding strategy together form a complete thread scheduling system that enables precise task processing and stable operation in multi-threaded concurrent scenarios, thereby achieving optimal performance and resource coordination within a complex policy system.

[0105] In one embodiment, the above step S40 includes:

[0106] S401, creating a first state judgment node after the policy execution module of the exclusive policy execution pipeline;

[0107] S402, creating a second state judgment node after the policy execution module of the interruptible policy execution pipeline;

[0108] S403: Setting an exclusive timeout threshold for the timeout detection module of the first state judgment node, where the exclusive timeout threshold is the maximum allowed execution time of the exclusive policy execution pipeline;

[0109] S404: Setting an exclusive policy error code set for the failure state detection module of the first state judgment node, wherein the exclusive policy error code set includes error codes that need to be matched by the exclusive policy execution result;

[0110] S405: Setting an interruptible timeout threshold for the timeout detection module of the second state determination node, wherein the interruptible timeout threshold is the maximum allowed execution time of the interruptible policy execution pipeline;

[0111] S406: Setting an interruptible policy error code set for the failure state detection module of the second state judgment node, wherein the interruptible policy error code set includes error codes that need to be matched by the interruptible policy execution result;

[0112] S407: Bind the timeout detection module and failure status detection module of the first status judgment node and the timeout detection module and failure status detection module of the second status judgment node to the trigger interface of the backup policy execution pipeline respectively;

[0113] S408: Generate unique version identifiers for the first status judgment node and the second status judgment node in the task queue processing center.

[0114] In this embodiment, establishing a judgment mechanism within different types of policy execution processes is crucial for achieving dynamic fault tolerance and an execution exception response mechanism within the policy processing process. Exclusive policy execution processes, with their finer execution granularity and complex policy call chains, often place extremely high demands on timeliness and accuracy. Execution delays or exceptions in such processes often pose a risk of blocking core business logic. In contrast, interruptible policy execution processes are designed with concurrency-friendly and interruption-tolerant design premises. The real-time and rigor requirements for their internal policies are slightly lower, allowing the system to downgrade execution when certain policies are anomalies.

[0115] The purpose of setting up a judgment node in the policy processing flow is to confirm the task status immediately after execution, ensuring the accuracy and rationality of subsequent system responses. Specifically, the first status judgment node is deployed at the end of the exclusive policy execution flow, serving as the status confirmation point after policy logic processing is completed. Similarly, the second status judgment node is deployed at the end of the interruptible policy execution flow. This deployment method ensures that the judgment logic strictly distinguishes between the two types of thread channels, preventing high-priority tasks from being mistakenly reused in the judgment logic.

[0116] Each judgment node has two functional modules, responsible for timeout detection and failure status detection respectively. The timeout detection module is used to identify whether there are situations in the policy process where the execution time exceeds the system's acceptable range. The timeout threshold setting for exclusive policies needs to be combined with the complexity of the policy model, data access latency, and the system load curve. The typical value may be set within 50 milliseconds; accordingly, interruptible policies can be set with a threshold of 100 milliseconds or higher due to lower response pressure. Such thresholds can be statically configured or dynamically adjusted through the performance monitoring system to form an adaptive execution strategy.

[0117] The failure status detection module primarily determines whether execution results meet requirements based on a set of error codes. Each policy type maintains a corresponding set of error codes. For example, in exclusive policies, issues such as identity verification failure and invalid model return values are uniformly identified by predefined error codes. Interruptible policies, on the other hand, include non-blocking exceptions such as frequency control trigger failure and content loading failure. The error code set is not only defined by business rules but also supports dynamic expansion to adapt to matching requirements after policy logic is updated.

[0118] The detection modules of the two status judgment nodes do not operate independently. Instead, they are connected to the trigger entry of the backup strategy processing channel through a binding relationship. This binding logic ensures that when either judgment module detects a timeout or failure, the system immediately switches the process to the backup strategy processing channel, improving the system's fault tolerance. Binding can be implemented using an event subscription mechanism. When a detection module issues a status exception event, the trigger interface takes over the task context and transfers the task flow to the backup path for execution, avoiding further resource consumption in the main process.

[0119] The judgment node itself also requires an independent identity within the task scheduling system to support functions such as monitoring, version control, and configuration rollback. To this end, a unique version identifier must be generated for the judgment node within the task scheduling module. This identifier can be used to record and manage judgment node upgrades, policy adjustments, or rule replacements, and also facilitates system tracing of anomalies. Version identifiers can be generated by combining timestamps and node indexes to support unified identification and distributed synchronization across systems.

[0120] In different system operating environments, the construction and deployment of judgment nodes and detection modules can be implemented in a variety of ways. In server-side architectures with limited resource constraints, the first and second status judgment nodes can be deployed as independent service components, operating in a containerized microservices architecture and centrally managed through a service registry. Each judgment node can act as a listening component, intercepting the response after the policy execution module returns a result and invoking the corresponding detection method.

[0121] In resource-sensitive edge services, status determination nodes can also be embedded as in-thread modules, using a lightweight plug-in registration method. Timeout detection can be achieved through thread pool monitoring combined with the system clock, and failure status detection can be performed by comparing the status field in the returned result with a preset error code set. Threshold and error code set management can be integrated with the configuration center, and policy judgment conditions can be centrally distributed and hot-updated using version numbers to ensure the consistency and maintainability of judgment logic.

[0122] To support stable responses under high concurrency conditions, the binding of judgment nodes can be accomplished using an event-driven architecture. Whenever a detection module generates a timeout or failure event, the system sends the event to the backup policy trigger via a message queue or event bus. This trigger then retrieves relevant policy context information from a cache or database based on the event context and reinitializes the execution flow of the backup policy channel.

[0123] When multiple judgment nodes coexist, the task scheduling center determines the currently active version of the judgment logic based on the node's unique version identifier. It can then compare this identifier with the version information carried in the task context to determine whether to reload the judgment rules or terminate the execution of outdated nodes. This version control mechanism can be used during the dynamic evolution of the system to prevent behavioral deviations caused by inconsistent policy judgment logic versions.

[0124] In actual deployments, a log analysis module can also be introduced to audit the behavior of judgment nodes. Each timeout or failure judgment result will be recorded, generating a structured audit log to provide decision support for subsequent optimization of policy execution processes, adjustment of threshold parameters, or updating of error code sets.

[0125] Example: In the healthcare sector, a smart registration system embeds a risk strategy to determine whether users frequently cancel appointments. When user behavior triggers the exclusive policy execution process, the system invokes an anti-fraud detection module based on historical behavior models to determine whether the user is suspected of maliciously occupying appointments. If the module's response exceeds the set 20 millisecond threshold or returns an error code indicating model inference failure, the first state judgment node immediately triggers the backup policy execution process, such as switching to basic rule judgment logic to quickly respond to user registration requests and ensure timely medical services.

[0126] In financial trading systems, shared execution threads are used to implement non-critical frequency control strategies that impact the user experience, such as limiting the recurrence of certain pop-up ads within a short period of time. If a strategy execution exceeds 60 milliseconds or triggers a non-fatal error, such as missing trigger parameters, the secondary state judgment node can use an event notification mechanism to direct the system to a backup strategy, such as using the default frequency limit configuration or skipping ad loading to ensure normal user interface rendering.

[0127] This embodiment sets up independent status judgment nodes in the exclusive policy execution process and the interruptible policy execution process respectively, and configures timeout detection and failure status detection modules for each node. This not only achieves refined perception of the policy execution status, but also builds a complete path from anomaly identification to backup policy response. The independent deployment and logical decoupling of judgment nodes enable the system to set differentiated fault-tolerant logic for different policy channels, while the unified binding mechanism ensures that the backup path can be immediately switched to when a policy anomaly occurs, avoiding business interruption. The introduction of version identification further enhances the controllability and evolvability of the process, providing stable support for the high availability of the system and the dynamic upgrade of the policy.

[0128] In one embodiment, the above step S60 includes:

[0129] S601, allocating an independent storage partition for output data generated by the exclusive policy execution pipeline;

[0130] S602, allocating a shared storage partition for output data generated by the interruptible policy execution pipeline;

[0131] S603, allocating a version rollback storage partition for the output data generated by the backup strategy execution pipeline;

[0132] S604: Define a unified data storage format, encrypt the output data generated by the exclusive policy execution pipeline, the interruptible policy execution pipeline, and the backup policy execution pipeline according to the unified data storage format, and store them in the corresponding independent storage partition, shared storage partition, and version rollback storage partition;

[0133] S605, establishing a global index table in the public data cache area, wherein the global index table maps the association relationship between the storage path and the policy type identifier and the output data version identifier;

[0134] S606: Setting an exclusive read-write lock for the independent storage partition, wherein the exclusive read-write lock restricts only the exclusive policy execution thread from modifying the output data generated by the exclusive policy execution pipeline;

[0135] S607: Setting a shared read-write lock for the shared storage partition and the version rollback storage partition, wherein the shared read-write lock allows multiple threads to read but mutually exclusive write the output data generated by the interruptible policy execution pipeline and the output data generated by the backup policy execution pipeline;

[0136] S608, after verifying the consistency of the data hash value and data version number of the output data generated by the exclusive policy execution pipeline, the output data generated by the interruptible policy execution pipeline and the output data generated by the backup policy execution pipeline, a data synchronization ready notification is sent to the task queue processing center.

[0137] In this embodiment, unified storage of the output results of multiple policy channels is achieved through a public data cache, which is a key means to improve the data consistency and scheduling efficiency of the policy management system. The classified storage of output data is the basis of the entire mechanism. The output data generated by the exclusive policy execution pipeline is important at the decision-making level, such as those involving risk control or user portrait labels. Such data usually has strict requirements on system stability and response delay. Therefore, it is necessary to allocate independent storage partitions for such data to ensure that the data writing process is not interfered with by other tasks. The partition is allocated a fixed memory area or distributed storage path by the system to support high-priority access control.

[0138] Data generated by the interruptible policy execution pipeline, such as frequency control policy trigger records or degraded rendering parameters, while important, is not highly real-time or irreplaceable. Therefore, it is best allocated to a shared storage partition that supports multi-threaded read and write. This data is typically used to improve user experience or optimize system load strategies and has a certain tolerance.

[0139] The data generated by the backup policy execution pipeline is primarily used in system degradation or fault tolerance scenarios. This often involves old configuration versions and exception context logs, requiring traceability. Therefore, it is managed in a version rollback storage partition. This partition typically integrates with a version control system to maintain historical snapshots and allow for rapid restoration during system restarts or policy reloads.

[0140] A unified data storage format is a key prerequisite for the entire unified storage logic. Defined data fields include a generation timestamp, policy type identifier, data hash value, and output data version identifier. The generation timestamp ensures data sequentiality, the policy type identifier distinguishes data sources (such as anti-fraud, frequency control, and backup), the hash value is used for integrity verification, and the output data version identifier ensures data correctness in configuration change scenarios.

[0141] Before data is written, it must be encrypted according to a unified format, typically using symmetric encryption (such as AES) or a signed hash algorithm to enhance data security. The data is then written to the corresponding storage partition. The entire process must ensure atomicity to avoid partial writes that could lead to state errors.

[0142] To efficiently index and call data, a global index table is established in the public data cache. This index table uses the policy type identifier and output data version identifier as keys, mapping the corresponding storage paths, allowing the task queue processing center or other policy modules to accurately locate the required data.

[0143] The access control mechanism uses read-write locks. An exclusive read-write lock is applied to the partition containing the exclusive policy's output data, allowing only threads associated with that policy to modify it. Shared read-write locks are applied to the remaining two partitions, allowing multiple threads to read but only one thread to write, preventing concurrent write conflicts.

[0144] To prevent misbehavior caused by inconsistent data, after data is written, the system performs a hash check and version number comparison on all output data to ensure integrity and synchronization. Once all data is confirmed to meet consistency requirements, the system sends a synchronization readiness notification to the task queue processing center, indicating that the data can be safely loaded for subsequent policy decisions or interface rendering.

[0145] In high-concurrency systems, public data caches can be deployed on in-memory databases (such as Redis) or high-performance distributed KV storage systems (such as RocksDB) to improve read and write speeds. Independent storage partitions can be isolated and controlled by setting namespaces and access tokens, while shared storage partitions and version rollback partitions use label-based data buckets to achieve data archiving and concurrent scheduling.

[0146] During system initialization, a unified data storage format is distributed through a centralized configuration management platform, and all policy modules dynamically adapt their field structures based on this configuration. Encryption methods and hash algorithms can be dynamically switched to meet compliance requirements in different scenarios. The global index table utilizes a two-layer map structure. The first layer identifies the index by policy type, and the second layer identifies the index path by output data version, supporting rapid location and multi-version switching.

[0147] Output data write operations are packaged within a write transaction mechanism, with each policy channel independently submitting transactions to ensure write consistency and system fault tolerance. After detection is complete, data synchronization readiness notifications are sent to the task queue using an asynchronous event mechanism, avoiding main thread blocking and improving system responsiveness. In a microservices architecture, this mechanism can also be integrated into a unified data gateway service, which delegates storage operations for policy output results, further improving inter-module decoupling and maintainability.

[0148] Example: In healthcare scenarios, the exclusive policy execution process typically generates user health risk levels and medical history tags. These tags need to be written to a specific partition within a short period of time and accessed by the doctor's pre-consultation system. If the write fails or is corrupted by concurrent access, it may lead to incorrect diagnosis or recommendations. Therefore, an exclusive read-write lock is required to prevent interruptions in the write process.

[0149] In an interruptible strategy, the frequency control policy triggered when a patient browses health science content records the trigger time, page parameters, and recommendation degradation logic. This information is stored in a shared partition and read simultaneously by multiple browsing threads for real-time content rendering or dynamic adjustment of recommendation strategies.

[0150] The backup policy processing flow is used to deal with situations where the main policy fails. For example, when the remote health tag service is abnormal, the system extracts the most recently successfully calculated health risk score and operation log from the rollback storage and temporarily uses it for page display and background recording to ensure uninterrupted service.

[0151] In the financial field, exclusive strategy channels generate credit scoring results and customer profile indicators, which must be written to isolated partitions and restricted from access by other threads to ensure that the scoring results are not modified by mistake; the frequency control strategy records each advertising contact behavior and response speed, which is suitable for storage in a shared partition for behavior analysis and frequency adjustment module calls; if the main channel fails, the backup strategy restores the default quota by rolling back the data and recording the log, ensuring that the risk control system has good stability and traceability.

[0152] This embodiment not only improves data access efficiency and consistency by classifying and uniformly storing the output data of different policy channels, but also significantly enhances the system's stability control over concurrent and high-frequency write scenarios. The design of a unified data format ensures the parsing consistency of various types of data in multi-module calls, while the encryption and version control mechanisms improve data security and traceability. The access control logic implemented through the read-write lock mechanism prevents data contention and corruption while ensuring high concurrent reading performance, further enhancing the stability of the system. The synchronous readiness notification mechanism makes the data scheduling process highly automated, reduces the need for human intervention, and provides solid support for the closed-loop operation of the policy module.

[0153] In one embodiment, before step S60, the method further includes:

[0154] S501, when creating an exclusive policy execution pipeline, extracting threshold parameters of the anti-fraud policy from a local configuration file;

[0155] S502, when creating an interruptible policy execution pipeline, extracting the rule data of the frequency control policy from the content management system configuration platform;

[0156] S503, receiving the custom policy configuration parameters pushed by the business module and verifying their legitimacy;

[0157] S504: Merge the threshold parameters of the anti-fraud strategy, the rule data of the frequency control strategy, and the verified custom strategy configuration parameters into pop-up strategy configuration data.

[0158] In this embodiment, before executing a policy task, the policy configuration source must be loaded and integrated to ensure a clear, controllable, and flexible parameter support mechanism for subsequent policy execution logic. This entire configuration preparation process is triggered by the task scheduling center, which completes a series of parameter acquisition and parsing operations through policy initialization instructions.

[0159] Local configuration files are one of the sources of policy definitions in the current system architecture, designed to provide high stability, low update frequency, and minimal dependencies. They are primarily suitable for threshold control in risk control scenarios. For example, common thresholds defined in anti-fraud policies, such as account switching limits, IP change frequency, or abnormal behavior scoring limits, are all organized through local configuration files. These files use lightweight structured formats such as YAML or TOML and are regularly updated by policy maintainers using configuration management tools. The system loads and caches these configurations during initialization to avoid relying on disk I / O or remote pulls during runtime, ensuring deterministic and rapid loading.

[0160] Interruptible policies offer greater adaptability and require more frequent updates. These policies typically encompass pop-up behavior control logic, such as user frequency control, degraded rendering, and display window duration. These parameters cannot be stored locally and must therefore be dynamically extracted from a unified content management system platform. Content management systems feature centralized configuration management, allowing individual policy maintainers to edit and publish policy rules through a configuration panel. The system initiates a pull request to the platform using a registered policy identifier, retrieves the rule data, and automatically converts it to a local structure. Dynamic hot updates are supported through on-demand caching or persistent subscriptions.

[0161] In addition to the policy configurations defined at the system level, the custom policy configurations pushed by the business modules inject stronger business context into the policies. This type of configuration may include specific population group identifiers, custom channel priorities, session feature screening conditions, etc. The policy logic of each business domain is highly differentiated. To accommodate this type of configuration, the platform has designed a unified parameter receiving interface that supports registration and namespace allocation by module to avoid field conflicts or semantic inconsistencies. All received business configurations must undergo structural validity verification to ensure that field definitions, data types, dependencies, etc. meet the requirements of the current policy processing model. In some cases, it is also necessary to make constrained judgments on the parameter content, such as the frequency control period must not be lower than the minimum safety interval.

[0162] After the parameters are loaded, in order to avoid multi-source access, repeated pulling or version confusion in the policy logic, the system merges the policy parameters from the three sources into a single pop-up policy configuration data structure. This structure is organized using a hierarchical naming system, such as the top-level is the policy type (anti-fraud, frequency control, custom), and the lower-level nodes are the rule set name and specific parameter values. The entire merging process retains the source identifier and version identifier, and supports subsequent dynamic screening or priority judgment based on the source. Once created, the structure will be injected into the policy execution engine context and become the rule basis for the exclusive policy execution pipeline and the interruptible policy execution pipeline during operation, ensuring that policies from different sources can work together without confusion.

[0163] During the long-term operation of the system, this multi-source configuration integration mechanism not only ensures the integrity of policy execution parameters but also provides underlying support for policy tuning, phased releases, and version control. For example, in sensitive scenarios, it is possible to dynamically switch to a specific business configuration version to avoid operational failures. It is also possible to set policy validity periods and integrate with the scheduler to update parameter status on schedule, further enhancing platform resiliency.

[0164] During actual deployment, upon receiving the task queue initialization command, the system first triggers the configuration loading process. Exclusive policy configuration is extracted by reading local configuration files, and a timed refresh mechanism is used to synchronize local and master node configurations. Frequency control policy configuration is registered with the content management platform, which uses a RESTful interface to retrieve rule content and store it in a local cache, avoiding repeated requests during each task initialization. For custom policy parameters pushed by business modules, the platform has designed a unified receiving channel that supports multiple data formats (such as JSON and ProtoBuf). Upon receipt, the validation service module is invoked to quickly verify the structure's validity. After verification, all parameters are mapped to key-value pairs and stored in the policy configuration pool, awaiting subsequent invocation by the policy pipeline during the loading phase. The system supports parameter priority settings based on parameter dimensions. For example, when fields with the same name exist, real-time policy configuration pushed by a business module is prioritized. Versioned configuration is also supported, controlling configuration validity through version numbers. The configuration source and version identifier are recorded in the policy hit chain for easy backtracking and debugging.

[0165] This embodiment integrates and pre-loads pop-up policy configurations from multiple sources, ensuring the integrity and flexibility of policy execution across the entire chain, from static configuration and dynamic pull to real-time push. By pre-verifying parameter legitimacy and uniformly encapsulating it, runtime error propagation or configuration conflicts are avoided. Configuration preparation is also completed before policy execution, ensuring the required context is available upon pipeline startup. This improves execution efficiency, reduces the probability of configuration loss, and provides an evolvable foundation for the policy system.

[0166] In one embodiment, after the above step S504, the method further includes:

[0167] S505, constructing a hierarchical structure of a tree-like funnel model, wherein the hierarchical structure includes a root node, strategy branch nodes, and parameter leaf nodes;

[0168] S506, storing the threshold parameters of the anti-fraud strategy, the rule data of the frequency control strategy, and the verified custom strategy configuration parameters in the parameter leaf node;

[0169] S507, locating the target parameter leaf node through a self-addressing path, wherein the self-addressing path is composed of a root node, a policy type, and a parameter type in sequence;

[0170] S508, when updating the pop-up window strategy configuration data, only modify the data of the target parameter leaf node, and increment the pop-up window strategy configuration data version identifier;

[0171] S509, monitoring the pop-up policy configuration data version identifiers of the exclusive policy execution pipeline and the interruptible policy execution pipeline;

[0172] S510, when it is detected that the version identifier of the pop-up policy configuration data of the exclusive policy execution pipeline or the interruptible policy execution pipeline is inconsistent with the version identifier of the pop-up policy configuration data of the target parameter leaf node, triggering data reloading processing of the target parameter leaf node to load the pop-up policy configuration data of the target parameter leaf node from the tree-like funnel model;

[0173] S511, when the data reloading is completed, updating the pop-up strategy configuration data version identifier of the target parameter leaf node in the tree-like funnel model.

[0174] In this embodiment, after integrating policy parameters from multiple sources, a hierarchical policy configuration model is introduced to enhance the organization and dynamic responsiveness of the policy configuration structure. This model supports version control, target queries, and minimally granular updates of policy parameters. This structure is designed as a multi-level tree-like funnel model, consisting of three basic node types: root nodes, policy branch nodes, and parameter leaf nodes.

[0175] The root node is the starting level of the entire configuration tree and is usually used to represent the environment to which the global policy configuration belongs, such as the policy platform identifier, configuration environment, or policy type grouping information to which the current configuration belongs. The policy branch node is located one level below the root node and is a logical division according to the policy module. For example, it can be set as an anti-fraud policy, frequency control policy, custom policy, etc.; multiple parameter leaf nodes are mounted under each policy branch node. As the lowest-level node, the parameter leaf node directly stores the specific parameters required for policy execution, including the threshold factor in the anti-fraud policy, the window interval in the frequency control policy, and the custom fields accessed from the business module. Each parameter leaf node contains fields such as the current parameter value, parameter data type, source identifier, last update time, and version identifier.

[0176] To quickly and accurately locate the target parameter during policy parameter reading, the system utilizes a self-addressing path mechanism. This path consists of a root node identifier, policy type, and parameter type, in that order. Unique path identifiers form a logical index for nodes within the tree structure. For example, a path chain such as root / anti-fraud / threshold / score_limit can be formed to locate the parameter leaf node for the score threshold in an anti-fraud policy. This path system offers the advantage of inherent hierarchical uniqueness, enabling efficient precise access, range retrieval, and backtracking reconstruction within complex structures.

[0177] The generation of a self-addressable path relies on the hierarchical position and semantic identity of policy parameters within the overall existing configuration structure. A combined path expression establishes a uniquely addressable location for each parameter within the tree-like funnel model. The path structure typically consists of three sequential identifiers: a root node identifier, a policy type identifier, and a parameter type identifier. The root node identifier is typically closely related to the business context to which the policy configuration belongs. For example, it distinguishes global contexts such as "production environment," "test environment," or "organization number," thereby supporting differentiated policy deployment across multiple environments. The policy type identifier is derived from the semantic classification of the policy domain to which the parameter belongs, such as "anti-fraud," "frequency control," or "popup display," and is used to indicate the functional domain of the current parameter. The parameter type identifier reflects the role attributes of the parameter within the policy, such as "threshold," "cooldown," or "trigger rule," and is used to identify the functional location.

[0178] This path generation method can not only be automatically constructed by the system, but also introduce a user-defined mechanism. During the policy initialization or configuration release phase, the system can automatically splice the path template through the policy configuration model and the parameter metadata dictionary, and automatically generate a complete path based on the index relationship in the policy tree structure. For example, when the user configures the "scoreThreshold" parameter in the anti-fraud policy, the environment identifier is "prod", and the policy type is "antiFraud", the final path is "prod / antiFraud / scoreThreshold". The system uses this path as the positioning index of the parameter node in the data structure to achieve precise positioning and automatic maintenance of structured parameters.

[0179] In other specific implementations, the path can also be constructed manually by the policy configurator or through a visual form interface. The system provides a parameter hierarchical management interface, allowing users to specify the root node, policy module, and parameter function label through drop-down selections. The system then automatically verifies the resulting structure according to standard path rules, generates a standardized path structure, and binds it to the parameter node. To prevent path ambiguity or conflicts, the system can also implement path uniqueness verification logic before path generation, ensuring that each policy parameter has a unique and valid access channel within the overall path space. For example, in a financial risk control system, a policy engineer might define the parameter path "branch001 / antiFraud / riskScoreLimit_v3," indicating that the parameter applies to institution 001, the anti-fraud domain, and the current version of the score limit control. In a healthcare system, a hospital administrator might define the path "hospital-A / alertPolicy / timeout" and bind it to a specific alert policy for the cardiology business line, achieving department-level parameter isolation and access control.

[0180] During parameter configuration updates, the system determines the self-addressing path specified in the update instruction, directly locates the target parameter leaf node, and performs a local replacement. To maintain policy stability and change traceability, the version identifier of the current node is automatically incremented after each modification. This identifier can be customized based on a timestamp hash, serial number, or business scenario, and is integrated into the global version monitoring scope for consistency verification.

[0181] During operation, the exclusive and interruptible policy execution pipelines periodically read their bound pop-up policy configuration data, or upon specific event triggering, and record the currently used version identifier. If a discrepancy is detected between the currently used version and the version identifier recorded in the target parameter leaf node in the tree-like funnel model, the system triggers a data reload process, re-extracting and overwriting the original policy configuration from the corresponding path node, ensuring that the latest valid parameter set is always loaded during operation.

[0182] After the data is reloaded, not only the parameter cache in the running context is updated, but also the latest status of the node in the tree-like funnel model is updated, ensuring that historical changes are traceable and the version chain is complete, and providing sufficient support for subsequent policy accountability and debugging backtracking.

[0183] This embodiment implements parameter structuring and version control through a tree-like funnel model, which can significantly improve the organizational efficiency and data access performance of policy parameters. Using parameter leaf nodes as the minimum update unit not only reduces the system consumption of full coverage, but also facilitates the rapid response of local policies to changes. At the same time, the self-addressing path mechanism realizes the controllability and accuracy of parameter access, so that the policy execution module can obtain the currently valid policy parameters at any time point, enhancing the stability and flexibility of the overall system. The reload mechanism further ensures that the system can automatically complete data refresh when the version is inconsistent, thereby ensuring the correctness of the policy results and avoiding business deviations caused by expired parameters.

[0184] In one embodiment, after the above step S60, the method further includes:

[0185] S701, monitoring the CPU occupancy rate and memory resource consumption of the exclusive policy execution pipeline;

[0186] S702, monitoring the number of task interruptions and the interrupt recovery time of the interruptible policy execution pipeline;

[0187] S703, when the CPU occupancy rate exceeds a preset resource threshold, reducing the number of concurrent tasks of the exclusive strategy execution pipeline;

[0188] S704, when the number of task interruptions exceeds a preset frequency threshold, triggering a policy configuration rollback operation of the interruptible policy execution pipeline;

[0189] S705 , writing the monitoring data of the CPU occupancy rate, memory resource consumption, task interruption times and interruption recovery time into a log database, and generating a visual monitoring report.

[0190] In this embodiment, in order to maintain the long-term stability of the policy execution system and efficient use of resources, a dynamic monitoring mechanism for resource usage can be introduced, especially when dealing with complex business processes or high-concurrency scenarios. This section focuses on the system resources used by the exclusive policy execution pipeline and the interruptible policy execution pipeline and their operating status. The CPU occupancy rate is a key indicator for measuring system load, especially for policy processes running in independent threads. Its CPU-intensive operations (such as complex rule matching and user risk model calls) can easily cause resource shortages, so they need to be monitored in real time. Memory resource consumption involves the residence of policy cache space, temporary computing structures, and context data structures, and is an important indicator for judging system stability and whether there are memory leaks.

[0191] In parallel, monitoring of interruptible policy execution processes focuses more on the stability and resilience of the policy itself. The number of task interruptions reflects the frequency of failures during policy execution, such as external interface response failures and policy service timeouts. The duration of interruption recovery is a measure of the effectiveness of the policy recovery mechanism. A chronically high recovery time will impact the overall policy timeliness and user experience.

[0192] When resource or exception frequency exceeds a threshold, the system must automatically respond. If the CPU utilization of an exclusive execution pipeline exceeds a preset resource threshold, the number of concurrent tasks in that pipeline should be reduced to prevent system imbalance or resource contention. This can be achieved by reducing the thread pool capacity or adjusting the task submission frequency. This reduction strategy must be dynamically adjustable and support adaptive configuration under varying load cycles.

[0193] For interruptible policies, if the interruption frequency exceeds the threshold, it indicates that the current configuration may have logical vulnerabilities, dependency failures, or unstable external dependencies. The policy configuration rollback operation should be triggered to switch to a verified historical configuration version or the default security configuration to ensure that the policy system can continue to provide services in abnormal scenarios.

[0194] The collection and storage of all monitoring data requires persistence to facilitate subsequent analysis and traceability. Therefore, all indicator data is written to the log database, including CPU utilization, peak memory usage, interruption frequency, and recovery time for each sampling. In addition, to improve the efficiency of operation and maintenance and policy optimization, the system can generate visual monitoring reports on the front end or policy management platform, graphically displaying the current operating status of each policy execution channel, fluctuation trends, and abnormal warning indicators, helping decision makers quickly identify bottlenecks.

[0195] In specific implementations, the system resource collection module can be used to collect CPU usage and memory consumption in real time based on the operating system's performance counter interface (such as / proc / stat and / proc / meminfo under Linux), and configure a certain time window and sampling frequency to ensure the continuity and stability of the collection. For monitoring the execution of interruptible policy tasks, the system can embed a status hook in the policy scheduling engine to capture interruption events and recovery completion time, and calculate the time consumption through the timestamp difference. When the collection result exceeds the preset threshold, the following methods can be used to reduce the number of concurrent tasks: dynamically adjust the maximum capacity of the thread pool; set the current limiting parameters for the task submission rate; temporarily freeze the execution entry of some low-priority policies, etc. The above actions are automatically issued by the policy scheduling management module to avoid manual intervention.

[0196] When a policy configuration rollback operation is triggered, the system will call the policy configuration management module, query the historical version configuration table, load the previous version configuration that meets the conditions and dynamically replace the current running configuration. At the same time, it will record the time, reason and configuration version number of the rollback operation to support future traceability analysis and rollback evaluation.

[0197] Using a time-series database (such as InfluxDB or Prometheus TSDB) for log databases improves data writing and query efficiency, making it particularly suitable for frequently collected data in large-scale policy systems. Visual reports can be created using Grafana or a proprietary dashboard. Key threshold alert mechanisms can be set to provide real-time visualization of CPU overloads, memory anomalies, and surges in interrupt frequency, and can be linked to the alert platform to trigger notifications.

[0198] To improve the efficiency of interactions between doctors and patients, a remote consultation system at a tertiary hospital requires dynamic pop-up notifications based on the current medical process node (e.g., consultation initiation, medical record submission, and test result transmission). Due to the high number of concurrent doctors and frequent business scenario switching in the hospital system, traditional flat pop-up notification control methods struggle to meet these requirements in terms of execution efficiency and policy flexibility. In the task queue processing center, the system first defines clear lifecycle nodes for all pop-up tasks. Before entering the queue, all tasks are assigned to the "pre-treatment prompt" scenario. Prompts such as patient information verification and medical history reminders are tied to the pre-queue node. After task execution, the system enters the "post-treatment prompt" scenario. Prompts such as result receipt and follow-up appointment suggestions are tied to the post-queue node. Tasks requiring high response speed (e.g., patient information verification prompts) are classified as high-priority tasks and assigned to independent execution threads. Within these threads, an exclusive policy execution pipeline is established to execute policies such as identity verification and drug allergy risk assessment. Low-priority tasks (such as printing suggestions and questionnaire invitations) are handled by a shared execution thread, on which an interruptible policy execution pipeline is deployed. Policy content includes personalized content frequency control and display resource scheduling. A status judgment node is set after each pipeline to monitor the policy execution duration and execution result status in real time. For example, if a risk assessment policy's execution time exceeds the set threshold or returns an exception identification code due to data source latency, a backup policy is automatically triggered, such as the display policy based on the most recent historical record. All policy execution results (such as recommended prompt content and graded suggestions) are stored in a public data cache. Different storage partitions are divided according to the execution policy type, and write permissions are controlled by read-write locks to ensure data consistency and concurrent access security. Data is stored in a unified format and encrypted. After version identification and hash verification, a synchronization readiness notification is sent, which is received and displayed by the downstream diagnosis and treatment interface. Through this architecture, the hospital system effectively implements on-demand scheduling, resource isolation, and policy fault tolerance for pop-up prompt tasks, improving pop-up configuration flexibility, operational stability, and patient interaction experience.

[0199] An online credit platform for small and medium-sized enterprises (SMEs) uses intelligent pop-up modules to present strategic content such as risk warnings, credit limit updates, and promotional recommendations to users. Due to the highly complex logic of financial risk control and marketing outreach, pop-up control must meet technical requirements such as refinement, interruptibility, low latency, and high reliability. The system establishes a lifecycle management structure for pop-up tasks within the task queue processing center. Tasks such as pre-credit risk warnings and KYC verification instructions are tied to the pre-queue node, while post-approval display logic such as credit limit reminders and installment recommendations are tied to the post-queue node, forming a clear execution chain from beginning to end. The platform assigns pop-up tasks that require immediate action before risk control (such as high-risk alerts for blacklisted users) to high-priority threads and allocates them to dedicated, exclusive policy execution pipelines, deploying policy modules such as anti-fraud scoring models and linked account transaction path determination. Tasks that can be displayed in the back-end of the service (such as loan product recommendations and credit authorization reminders) are assigned to shared threads, where display decisions are dynamically executed based on policy hit rates through an interruptible policy pipeline. A status judgment node is configured after each policy execution path to ensure that the policy model has not timed out and is executed normally. If the external interface call that a model relies on fails or the delay exceeds the limit, the backup strategy will be automatically activated, such as loading the credit limit records of the past three months and using them as a static decision reference to ensure the continuity of the user experience. All policy execution outputs, such as score values, risk labels, recommended content, etc., are encrypted in the public data cache and then enter independent or shared partition storage. A full-process data tracking system is formed through path mapping and version control. Once the data hash check matches the version identifier, the system pushes a ready signal to the task queue, and the control interface can display or hide the corresponding content according to the policy output. Through this structure, the platform not only strengthens the task-level management of pop-up control, but also realizes an operating system in which the policy execution path can be separated, the exception can be rolled back, and the data can be unified. While improving the quality of user perception, it reduces the risks of financial policy maintenance and business delivery.

[0200] This embodiment monitors the use and operating status of key resources during policy execution, enabling responses before problems occur, thereby improving the system's sustainable operation and flexible scheduling capabilities. The exclusive policy pipeline can effectively alleviate resource constraints and avoid policy processing delays caused by main policy congestion by dynamically adjusting the number of concurrent calls. Interruptible policies achieve fault tolerance and rapid recovery through interruption monitoring and configuration rollback mechanisms, improving the robustness of the policy system. Combining logging with visual reports, policy managers can quickly locate bottleneck modules, identify resource waste, and provide data support for subsequent optimization, thereby reducing maintenance costs and the risk of human intervention.

[0201] In one embodiment, a pop-up strategy task processing device is provided, which corresponds one-to-one to the pop-up strategy task processing method in the above embodiment. Figure 3 , Figure 3 This is a functional module diagram of a preferred embodiment of the pop-up policy task processing device of the present invention. It includes a queue node registration module 10, a task allocation module 20, a policy pipeline construction module 30, a status judgment configuration module 40, a backup policy triggering module 50, and a unified data storage module 60. Each functional module is described in detail below:

[0202] The queue node registration module 10 is used to define the life cycle nodes of the pop-up queue in the task queue processing center, and the life cycle nodes include the pre-queue node and the post-queue node;

[0203] The task allocation module 20 is used to divide the pop-up tasks into independent execution thread tasks and shared execution thread tasks according to their priorities, and bind the independent execution thread tasks to the node before entering the queue and the shared execution thread tasks to the node after leaving the queue;

[0204] A policy pipeline construction module 30 is used to create an exclusive policy execution pipeline in an independent execution thread and an interruptible policy execution pipeline in a shared execution thread;

[0205] A state judgment configuration module 40 is used to set a policy execution state judgment node in the exclusive policy execution pipeline and the interruptible policy execution pipeline;

[0206] A backup strategy triggering module 50 is configured to trigger a backup strategy execution pipeline when the strategy execution status judgment node detects that the execution time of the current strategy in the exclusive strategy execution pipeline or the interruptible strategy execution pipeline exceeds a preset threshold or the execution result returns a failure status;

[0207] The unified data storage module 60 is used to uniformly store the output data generated by the exclusive policy execution pipeline, the output data generated by the interruptible policy execution pipeline, and the output data generated by the backup policy execution pipeline through a public data buffer area.

[0208] In one embodiment, the task allocation module 20 is specifically configured to:

[0209] Set the response time threshold for pop-up tasks and determine the response time from the triggering of the pop-up task to the expected feedback;

[0210] Marking a pop-up task with a response time less than the response time threshold as a high-priority independent execution thread task, and marking a pop-up task with a response time greater than or equal to the response time threshold as a low-priority shared execution thread task;

[0211] Allocate exclusive memory resources and fixed thread pool capacity for high-priority independent execution thread tasks, and bind the high-priority independent execution thread tasks to the pre-processing module of the node before entering the queue;

[0212] Allocating shared memory resources and dynamic thread pool capacity for low-priority shared execution thread tasks, and binding the low-priority shared execution thread tasks to the post-processing module of the post-dequeue node;

[0213] A resource locking flag is set for a high-priority independent execution thread task in the task queue processing center.

[0214] In one embodiment, the status determination configuration module 40 is specifically configured to:

[0215] Creating a first state determination node after the policy execution module of the exclusive policy execution pipeline;

[0216] Creating a second state determination node after the policy execution module of the interruptible policy execution pipeline;

[0217] Setting an exclusive timeout threshold for the timeout detection module of the first state judgment node, wherein the exclusive timeout threshold is the maximum allowed execution time of the exclusive policy execution pipeline;

[0218] Setting an exclusive policy error code set for the failure state detection module of the first state judgment node, wherein the exclusive policy error code set includes error codes that need to be matched by the exclusive policy execution result;

[0219] Setting an interruptible timeout threshold for the timeout detection module of the second state judgment node, wherein the interruptible timeout threshold is the maximum allowed execution time of the interruptible policy execution pipeline;

[0220] Setting an interruptible policy error code set for the failure state detection module of the second state judgment node, wherein the interruptible policy error code set includes error codes that need to be matched by the interruptible policy execution result;

[0221] Binding the timeout detection module and failure state detection module of the first state judgment node and the timeout detection module and failure state detection module of the second state judgment node to the trigger interface of the backup strategy execution pipeline respectively;

[0222] A unique version identifier is generated for the first status judgment node and the second status judgment node in the task queue processing center.

[0223] In one embodiment, the unified data storage module 60 is specifically configured to:

[0224] Allocating independent storage partitions for output data generated by the exclusive policy execution pipeline;

[0225] Allocating a shared storage partition for output data generated by the interruptible policy execution pipeline;

[0226] Allocating a version rollback storage partition for output data generated by the backup strategy execution pipeline;

[0227] Define a unified data storage format, encrypt the output data generated by the exclusive policy execution pipeline, the interruptible policy execution pipeline, and the backup policy execution pipeline according to the unified data storage format, and store them in the corresponding independent storage partition, shared storage partition, and version rollback storage partition;

[0228] Establishing a global index table in the public data cache area, wherein the global index table maps the association relationship between the storage path and the policy type identifier and the output data version identifier;

[0229] Setting an exclusive read-write lock for the independent storage partition, wherein the exclusive read-write lock restricts only the exclusive policy execution thread from modifying the output data generated by the exclusive policy execution pipeline;

[0230] Setting a shared read-write lock for the shared storage partition and the version rollback storage partition, wherein the shared read-write lock allows multiple threads to read but mutually exclusively write the output data generated by the interruptible policy execution pipeline and the output data generated by the backup policy execution pipeline;

[0231] After verifying the consistency of the data hash values and data version numbers of the output data generated by the exclusive policy execution pipeline, the output data generated by the interruptible policy execution pipeline, and the output data generated by the backup policy execution pipeline, a data synchronization ready notification is sent to the task queue processing center.

[0232] In one embodiment, the unified data storage module 60 is specifically configured to:

[0233] When creating an exclusive policy execution pipeline, extract the threshold parameters of the anti-fraud policy from the local configuration file;

[0234] When creating an interruptible policy execution pipeline, extract the frequency control policy rule data from the content management system configuration platform;

[0235] Receive custom policy configuration parameters pushed by the business module and verify their legitimacy;

[0236] The threshold parameters of the anti-fraud strategy, the rule data of the frequency control strategy and the customized strategy configuration parameters after verification are merged into the pop-up strategy configuration data.

[0237] In one embodiment, the unified data storage module 60 is specifically configured to:

[0238] Constructing a hierarchical structure of a tree-like funnel model, wherein the hierarchical structure includes a root node, a strategy branch node, and a parameter leaf node;

[0239] The parameter leaf node stores the threshold parameters of the anti-fraud strategy, the rule data of the frequency control strategy, and the customized strategy configuration parameters after verification;

[0240] Locating the target parameter leaf node through a self-addressing path, wherein the self-addressing path is composed of a root node, a policy type, and a parameter type in sequence;

[0241] When updating the pop-up strategy configuration data, only the data of the target parameter leaf node is modified, and the pop-up strategy configuration data version identifier is incremented;

[0242] Monitor the pop-up policy configuration data version identifiers of the exclusive policy execution pipeline and the interruptible policy execution pipeline;

[0243] When it is detected that the pop-up policy configuration data version identifier of the exclusive policy execution pipeline or the interruptible policy execution pipeline is inconsistent with the pop-up policy configuration data version identifier of the target parameter leaf node, the data reload processing of the target parameter leaf node is triggered to load the pop-up policy configuration data of the target parameter leaf node from the tree-like funnel model;

[0244] When the data reloading is completed, the pop-up strategy configuration data version identifier of the target parameter leaf node in the tree-like funnel model is updated.

[0245] In one embodiment, the unified data storage module 60 is specifically configured to:

[0246] Monitor the CPU occupancy and memory resource consumption of the exclusive strategy execution pipeline;

[0247] Monitor the number of task interruptions and the time it takes to recover from interruptions in the interruptible strategy execution pipeline;

[0248] When the CPU occupancy rate exceeds a preset resource threshold, reducing the number of concurrent tasks of the exclusive strategy execution pipeline;

[0249] When the number of task interruptions exceeds a preset frequency threshold, a policy configuration rollback operation of the interruptible policy execution pipeline is triggered;

[0250] The monitoring data of the CPU occupancy rate, memory resource consumption, task interruption times and interruption recovery time are written into the log database, and a visual monitoring report is generated.

[0251] In one embodiment, a computer device is provided. The computer device may be a server, and its internal structure diagram may be as follows: Figure 4As shown. The computer device includes a processor, a memory, a network interface and a database connected via a system bus. The processor of the computer device is used to provide computing and control capabilities. The memory of the computer device includes a non-volatile and / or volatile storage medium and an internal memory. The non-volatile storage medium stores an operating system, a computer program and a database. The internal memory provides an environment for the operation of the operating system and the computer program in the non-volatile storage medium. The network interface of the computer device is used to communicate with an external user terminal via a network connection. When the computer program is executed by the processor, it implements the functions or steps on the server side of a pop-up strategy task processing method.

[0252] In one embodiment, a computer device is provided. The computer device may be a user terminal, and its internal structure diagram may be as follows: Figure 5 As shown. The computer device includes a processor, memory, network interface, display screen and input device connected via a system bus. The processor of the computer device is used to provide computing and control capabilities. The memory of the computer device includes a non-volatile storage medium and an internal memory. The non-volatile storage medium stores an operating system and a computer program. The internal memory provides an environment for the operation of the operating system and computer program in the non-volatile storage medium. The network interface of the computer device is used to communicate with an external server via a network connection. When the computer program is executed by the processor, it realizes the functions or steps on the user side of a pop-up strategy task processing method.

[0253] In one embodiment, a computer device is provided, including a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, the following steps are performed:

[0254] Define the lifecycle nodes of the pop-up queue in the task queue processing center, including the pre-queue node and the post-queue node;

[0255] Divide pop-up tasks into independent execution thread tasks and shared execution thread tasks according to priority, and bind independent execution thread tasks to the node before entering the queue, and bind shared execution thread tasks to the node after leaving the queue;

[0256] Create an exclusive policy execution pipeline in an independent execution thread and an interruptible policy execution pipeline in a shared execution thread;

[0257] Setting a policy execution status judgment node in the exclusive policy execution pipeline and the interruptible policy execution pipeline;

[0258] When the policy execution status judgment node detects that the execution time of the current policy in the exclusive policy execution pipeline or the interruptible policy execution pipeline exceeds a preset threshold or the execution result returns a failure status, the backup policy execution pipeline is triggered;

[0259] The output data generated by the exclusive policy execution pipeline, the output data generated by the interruptible policy execution pipeline and the output data generated by the backup policy execution pipeline are uniformly stored through the public data cache.

[0260] In one embodiment, a computer-readable storage medium is provided, on which a computer program is stored. When the computer program is executed by a processor, the following steps are implemented:

[0261] Define the lifecycle nodes of the pop-up queue in the task queue processing center, including the pre-queue node and the post-queue node;

[0262] Divide pop-up tasks into independent execution thread tasks and shared execution thread tasks according to priority, and bind independent execution thread tasks to the node before entering the queue, and bind shared execution thread tasks to the node after leaving the queue;

[0263] Create an exclusive policy execution pipeline in an independent execution thread and an interruptible policy execution pipeline in a shared execution thread;

[0264] Setting a policy execution status judgment node in the exclusive policy execution pipeline and the interruptible policy execution pipeline;

[0265] When the policy execution status judgment node detects that the execution time of the current policy in the exclusive policy execution pipeline or the interruptible policy execution pipeline exceeds a preset threshold or the execution result returns a failure status, the backup policy execution pipeline is triggered;

[0266] The output data generated by the exclusive policy execution pipeline, the output data generated by the interruptible policy execution pipeline and the output data generated by the backup policy execution pipeline are uniformly stored through the public data cache.

[0267] It should be noted that the above functions or steps that can be implemented by the computer-readable storage medium or computer device can be found in the relevant descriptions of the server side and the user side in the aforementioned method embodiment. To avoid repetition, they will not be described one by one here.

[0268] Those skilled in the art will appreciate that all or part of the processes in the above-mentioned embodiments can be implemented by instructing the relevant hardware through a computer program. The computer program can be stored in a non-volatile computer-readable storage medium. When the computer program is executed, it can include the processes of the embodiments of the above-mentioned methods. Among them, any reference to memory, storage, database or other media used in the embodiments provided in this application can include non-volatile and / or volatile memory. Non-volatile memory can include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM) or flash memory. Volatile memory can include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in various forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), double data rate SDRAM (DDRSDRAM), enhanced SDRAM (ESDRAM), synchronous link (Synchlink) DRAM (SLDRAM), memory bus (Rambus) direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM).

[0269] Those skilled in the art will clearly understand that for the sake of convenience and brevity of description, only the division of the above-mentioned functional units and modules is used as an example. In actual applications, the above-mentioned functions can be distributed and completed by different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above.

[0270] It should be noted that if any software tools or components other than those of the Company appear in the embodiments of this application, they are merely for illustration and do not represent actual use. The above embodiments are intended only to illustrate the technical solutions of the present invention, not to limit them. Although the present invention has been described in detail with reference to the above embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the above embodiments, or replace some of the technical features therein with equivalents. These modifications or replacements do not deviate the essence of the corresponding technical solutions from the spirit and scope of the technical solutions of the embodiments of the present invention, and should all be included in the scope of protection of the present invention.

Claims

1. A pop-up strategy task processing method, characterized in that: The following steps are involved: Define the lifecycle nodes of the pop-up queue in the task queue processing center, including the pre-queue node and the post-queue node; Divide pop-up tasks into independent execution thread tasks and shared execution thread tasks according to priority, and bind independent execution thread tasks to the node before entering the queue, and bind shared execution thread tasks to the node after leaving the queue; Create an exclusive policy execution pipeline in an independent execution thread and an interruptible policy execution pipeline in a shared execution thread; Setting a policy execution status judgment node in the exclusive policy execution pipeline and the interruptible policy execution pipeline; When the policy execution status judgment node detects that the execution time of the current policy in the exclusive policy execution pipeline or the interruptible policy execution pipeline exceeds a preset threshold or the execution result returns a failure status, the backup policy execution pipeline is triggered; The output data generated by the exclusive policy execution pipeline, the output data generated by the interruptible policy execution pipeline and the output data generated by the backup policy execution pipeline are uniformly stored through the public data cache.

2. The pop-up strategy task processing method according to claim 1, characterized in that: Pop-up tasks are divided into independent execution thread tasks and shared execution thread tasks according to priority. Independent execution thread tasks are bound to the node before entering the queue, and shared execution thread tasks are bound to the node after leaving the queue, including: Set the response time threshold for pop-up tasks and determine the response time from the triggering of the pop-up task to the expected feedback; Marking a pop-up task with a response time less than the response time threshold as a high-priority independent execution thread task, and marking a pop-up task with a response time greater than or equal to the response time threshold as a low-priority shared execution thread task; Allocate exclusive memory resources and fixed thread pool capacity for high-priority independent execution thread tasks, and bind the high-priority independent execution thread tasks to the pre-processing module of the node before entering the queue; Allocating shared memory resources and dynamic thread pool capacity for low-priority shared execution thread tasks, and binding the low-priority shared execution thread tasks to the post-processing module of the post-dequeue node; A resource locking flag is set for a high-priority independent execution thread task in the task queue processing center.

3. The pop-up strategy task processing method according to claim 1, characterized in that: Set the policy execution status judgment node in the exclusive policy execution pipeline and the interruptible policy execution pipeline, including: Creating a first state determination node after the policy execution module of the exclusive policy execution pipeline; Creating a second state determination node after the policy execution module of the interruptible policy execution pipeline; Setting an exclusive timeout threshold for the timeout detection module of the first state judgment node, wherein the exclusive timeout threshold is the maximum allowed execution time of the exclusive policy execution pipeline; Setting an exclusive policy error code set for the failure state detection module of the first state judgment node, wherein the exclusive policy error code set includes error codes that need to be matched by the exclusive policy execution result; Setting an interruptible timeout threshold for the timeout detection module of the second state judgment node, wherein the interruptible timeout threshold is the maximum allowed execution time of the interruptible policy execution pipeline; Setting an interruptible policy error code set for the failure state detection module of the second state judgment node, wherein the interruptible policy error code set includes error codes that need to be matched by the interruptible policy execution result; Binding the timeout detection module and failure state detection module of the first state judgment node and the timeout detection module and failure state detection module of the second state judgment node to the trigger interface of the backup strategy execution pipeline respectively; A unique version identifier is generated for the first status judgment node and the second status judgment node in the task queue processing center.

4. The pop-up strategy task processing method according to claim 1, characterized in that: The output data generated by the exclusive policy execution pipeline, the output data generated by the interruptible policy execution pipeline, and the output data generated by the backup policy execution pipeline are uniformly stored through the public data cache, including: Allocating independent storage partitions for output data generated by the exclusive policy execution pipeline; Allocating a shared storage partition for output data generated by the interruptible policy execution pipeline; Allocating a version rollback storage partition for output data generated by the backup strategy execution pipeline; Define a unified data storage format, encrypt the output data generated by the exclusive policy execution pipeline, the interruptible policy execution pipeline, and the backup policy execution pipeline according to the unified data storage format, and store them in the corresponding independent storage partition, shared storage partition, and version rollback storage partition; Establishing a global index table in the public data cache area, wherein the global index table maps the association relationship between the storage path and the policy type identifier and the output data version identifier; Setting an exclusive read-write lock for the independent storage partition, wherein the exclusive read-write lock restricts only the exclusive policy execution thread from modifying the output data generated by the exclusive policy execution pipeline; Setting a shared read-write lock for the shared storage partition and the version rollback storage partition, wherein the shared read-write lock allows multiple threads to read but mutually exclusively write the output data generated by the interruptible policy execution pipeline and the output data generated by the backup policy execution pipeline; After verifying the consistency of the data hash values and data version numbers of the output data generated by the exclusive policy execution pipeline, the output data generated by the interruptible policy execution pipeline, and the output data generated by the backup policy execution pipeline, a data synchronization ready notification is sent to the task queue processing center.

5. The pop-up strategy task processing method according to claim 1, characterized in that: Before the output data generated by the exclusive policy execution pipeline, the output data generated by the interruptible policy execution pipeline, and the output data generated by the backup policy execution pipeline are uniformly stored in the public data cache, the following steps are also included: When creating an exclusive policy execution pipeline, extract the threshold parameters of the anti-fraud policy from the local configuration file; When creating an interruptible policy execution pipeline, extract the frequency control policy rule data from the content management system configuration platform; Receive custom policy configuration parameters pushed by the business module and verify their legitimacy; The threshold parameters of the anti-fraud strategy, the rule data of the frequency control strategy and the customized strategy configuration parameters after verification are merged into the pop-up strategy configuration data.

6. The pop-up strategy task processing method according to claim 5, characterized in that: After merging the threshold parameters of the anti-fraud strategy, the rule data of the frequency control strategy, and the verified custom strategy configuration parameters into the pop-up strategy configuration data, the following is also included: Constructing a hierarchical structure of a tree-like funnel model, wherein the hierarchical structure includes a root node, a strategy branch node, and a parameter leaf node; The parameter leaf node stores the threshold parameters of the anti-fraud strategy, the rule data of the frequency control strategy, and the customized strategy configuration parameters after verification; Locating the target parameter leaf node through a self-addressing path, wherein the self-addressing path is composed of a root node, a policy type, and a parameter type in sequence; When updating the pop-up strategy configuration data, only the data of the target parameter leaf node is modified, and the pop-up strategy configuration data version identifier is incremented; Monitor the pop-up policy configuration data version identifiers of the exclusive policy execution pipeline and the interruptible policy execution pipeline; When it is detected that the pop-up policy configuration data version identifier of the exclusive policy execution pipeline or the interruptible policy execution pipeline is inconsistent with the pop-up policy configuration data version identifier of the target parameter leaf node, the data reload processing of the target parameter leaf node is triggered to load the pop-up policy configuration data of the target parameter leaf node from the tree-like funnel model; When the data reloading is completed, the pop-up strategy configuration data version identifier of the target parameter leaf node in the tree-like funnel model is updated.

7. The pop-up strategy task processing method according to claim 1, characterized in that: After uniformly storing the output data generated by the exclusive policy execution pipeline, the output data generated by the interruptible policy execution pipeline, and the output data generated by the backup policy execution pipeline in a public data buffer area, the system further includes: Monitor the CPU occupancy and memory resource consumption of the exclusive strategy execution pipeline; Monitor the number of task interruptions and the time it takes to recover from interruptions in the interruptible strategy execution pipeline; When the CPU occupancy rate exceeds a preset resource threshold, reducing the number of concurrent tasks of the exclusive strategy execution pipeline; When the number of task interruptions exceeds a preset frequency threshold, a policy configuration rollback operation of the interruptible policy execution pipeline is triggered; The monitoring data of the CPU occupancy rate, memory resource consumption, task interruption times and interruption recovery time are written into the log database, and a visual monitoring report is generated.

8. A pop-up strategy task processing device, characterized in that: The pop-up strategy task processing device includes: The queue node registration module is used to define the life cycle nodes of the pop-up queue in the task queue processing center. The life cycle nodes include the pre-queue node and the post-queue node. The task allocation module is used to divide pop-up tasks into independent execution thread tasks and shared execution thread tasks according to priority, and bind the independent execution thread tasks to the node before entering the queue and the shared execution thread tasks to the node after leaving the queue; A policy pipeline building module, used to create exclusive policy execution pipelines in independent execution threads and interruptible policy execution pipelines in shared execution threads; A state judgment configuration module is used to set a policy execution state judgment node in the exclusive policy execution pipeline and the interruptible policy execution pipeline; A backup strategy triggering module is configured to trigger a backup strategy execution pipeline when the strategy execution status judgment node detects that the execution time of the current strategy in the exclusive strategy execution pipeline or the interruptible strategy execution pipeline exceeds a preset threshold or the execution result returns a failure status; The unified data storage module is used to uniformly store the output data generated by the exclusive policy execution pipeline, the output data generated by the interruptible policy execution pipeline and the output data generated by the backup policy execution pipeline through a public data cache area.

9. A computer device, characterized in that: The computer device includes a memory, a processor, and a pop-up policy task processing program stored in the memory and capable of running on the processor. When the pop-up policy task processing program is executed by the processor, the steps of the pop-up policy task processing method according to any one of claims 1 to 7 are implemented.

10. A computer-readable storage medium, characterized in that The storage medium stores a pop-up policy task processing program, which, when executed by a processor, implements the steps of the pop-up policy task processing method according to any one of claims 1 to 7.

Images