A load-aware intelligent insurance pushing scheduling method and system

Abstract

The application provides a load-aware intelligent insurance pushing scheduling method and system, relates to the technical field of insurance product pushing scheduling, and comprises the following steps: S1, determining the maximum task pushing amount of the next pushing period based on the load parameter set and the task pushing amount in the current period; S2, extracting task information of each to-be-pushed task in the task queue to screen out real-time pushing objects and a real-time pushing task set of the real-time pushing objects, and calculating the dynamic recommendation score of each to-be-pushed task in the next pushing period; and S3, taking the maximum task pushing amount as a judgment benchmark to select a general pushing scheduling scheme or a selective pushing scheduling scheme for pushing scheduling. The application takes the maximum task pushing amount as a constraint benchmark, takes the maximum of the fitness value calculated based on the dynamic recommendation score as an optimization target, adopts a genetic algorithm to solve the optimal pushing scheme of each real-time pushing object in the next pushing period, so that the accuracy and timeliness of touch are improved while the cluster load is ensured to be stable.

Description

Technical Field

[0001] This invention relates to the field of insurance product push scheduling technology, specifically to an intelligent insurance push scheduling method and system based on load awareness. Background Technology

[0002] In the application field of insurance product recommendation, insurance companies typically use their own or third-party task generation engines to conduct big data analysis on customer identity information, short-term and long-term behavioral data, etc., to generate push tasks to push corresponding insurance products to customers. After receiving the push task, the push server cluster pushes the insurance product to the corresponding customer based on the push task, thereby completing the push work.

[0003] However, due to limitations in hardware resources, network bandwidth, and concurrent processing capabilities, push server clusters often cannot process massive push tasks instantly, resulting in some push tasks accumulating in the push server cluster to form a task sequence (or task buffer). The task of the push server cluster is to selectively push push tasks in the task queue according to the set push scheduling scheme. How to set up a push scheduling scheme to scientifically select push tasks from the task sequence in high-concurrency scenarios, and improve the accuracy and timeliness of delivery while ensuring stable cluster load, is the technical problem that this technical solution aims to solve.

[0004] The information disclosed in the background section is only intended to enhance the understanding of the background of this disclosure, and therefore may include information that does not constitute prior art known to those skilled in the art. Summary of the Invention

[0005] The purpose of this invention is to provide a load-aware intelligent insurance push scheduling method and system to solve the problems mentioned in the background art.

[0006] To achieve the above objectives, the present invention provides the following technical solution: A load-aware intelligent insurance push scheduling method includes the following steps: S1: Real-time acquisition of the load parameter set and task push volume of the push server cluster in the current time period to determine the maximum task push volume in the next push cycle. The load parameter set includes three load parameters: CPU utilization, memory usage ratio and database connection pool utilization. S2, for the task queue of the push server cluster at the end of the current time period, extract the task information of each task to be pushed, and query the behavior scenario of the push object to filter out the real-time push object and its real-time push task set, and calculate the dynamic recommendation score of each task to be pushed in the real-time push task set in the next push cycle. S3, determine whether the maximum number of tasks to be pushed in the next push cycle is less than the total number of tasks to be pushed in all real-time push task sets. If yes, push scheduling is performed based on the overall push scheduling scheme; otherwise, push scheduling is performed based on the selective push scheduling scheme. The selective push scheduling scheme is as follows: a push scheme for the corresponding real-time push object is constructed based on the real-time push task set, and a scheme recommendation score is generated for each push scheme based on the dynamic recommendation score. The maximum task push volume is used as the constraint benchmark, and the fitness value calculated based on the scheme recommendation score is used as the optimization objective. The optimal push scheme for each real-time push object is solved by a genetic algorithm. The push tasks to be pushed in the optimal push scheme are used as real-time push tasks. The push server cluster executes the push work for each real-time push task one by one in the next push cycle.

[0007] Furthermore, the current time period is a time interval formed by tracing back a first time threshold from the end time of the current push cycle. The duration of the first time threshold is greater than the duration of the push cycle and is an integer multiple of the duration of the push cycle. The logic for determining the current push cycle is as follows: if a push cycle satisfies that its end time is not earlier than the current time and its start time is earlier than the current time, then the push cycle is taken as the current push cycle.

[0008] Furthermore, the calculation logic for the maximum task push volume in the next push cycle is as follows: 1) Take each push period in the current time period as the target push period. For each target push period, obtain the task push volume of the push server cluster in the target push period in real time, as well as the load parameters at the start and end times of the target push period. 2) For any target push period, calculate the difference between various load parameters at the end time and the start time to obtain the net increase in various load consumption caused by task push under the target push period, including the net increase in CPU consumption, the net increase in memory consumption and the net increase in database connection pool consumption. Divide the net increase in various load consumption by the number of tasks pushed under the same target push period to obtain the boundary consumption rate of various loads per task under the target push period, including the boundary consumption rate of CPU, the boundary consumption rate of memory and the boundary consumption rate of database connection pool. 3) Average the various load boundary consumption rates of each unit task under each target push cycle to obtain the various load boundary consumption rates of each unit task under the current time period. 4) Retrieve the CPU utilization, memory usage percentage, and database connection pool occupancy rate at the end of the current push cycle, and compare them one by one with the corresponding comparison thresholds. If at least one of the three is not less than the corresponding comparison threshold, then set the maximum task push volume of the next push cycle to 0; otherwise, proceed to step 5). The comparison thresholds include the CPU utilization threshold, memory usage percentage threshold, and database connection pool occupancy rate threshold. 5) Subtract the CPU utilization, memory usage percentage, and database connection pool utilization rates at the end of the current push cycle from the CPU utilization threshold, memory usage percentage threshold, and database connection pool utilization rate threshold, respectively, to obtain the remaining capacity of CPU utilization, memory usage percentage, and database connection pool utilization rate for the next push cycle. Then divide each of these three values ​​by the CPU boundary consumption rate, memory boundary consumption rate, and database connection pool boundary consumption rate of the unit task in the current time period to obtain three values. Round down the minimum of the three values ​​to obtain the maximum task push volume for the next push cycle.

[0009] Furthermore, for any task to be pushed, its task information includes: 1) the number of the product to be pushed, which is the insurance product to be pushed in the task; 2) the identity code of the target audience, which is the customer to whom the insurance product in the task is to be pushed; 3) the recommendation score of the task to be pushed; and 4) the suggested push time period for the task to be pushed.

[0010] Furthermore, the logic for determining the dynamic recommendation score, the real-time push object, and the real-time push task set is as follows: 1) For any task to be pushed in the task queue of the push server cluster at the end of the current time period, extract its task information and classify the tasks to be pushed with the same identity code of the push object into the same set, thereby forming a set of tasks to be pushed that corresponds one-to-one with each push object. 2) For any push target, based on its identity code, query its behavior scenario at the start of the current push cycle, and analyze the behavior scenario based on the preset judgment logic to determine the push status of the push target at the start of the current push cycle, which is suggested push, normal push or blocked push. Behavior scenarios include insurance access scenario, do not want to be disturbed scenario and other scenarios. 3) Extract the push objects whose push status is suggested push or normal push at the start of the current push cycle, and use them as real-time push objects; 4) For any real-time push target, select push tasks from its push task set that have an overlap between the suggested push period and the next push week, and summarize them to form the preferred push task set for that real-time push target. 5) For any real-time push target, combine the number of push records of insurance products pushed to it in the historical period and its push status at the beginning of the current push period to determine its maximum push volume in the next push period, and remove real-time push targets whose maximum push volume in the next push period is 0. 6) For any task to be pushed in the preferred push set, the recommendation score of the task to be pushed is corrected based on the time relationship between the end time of its suggested push period and the end time of the next push cycle, so as to obtain the dynamic recommendation score of the task to be pushed in the next push cycle. The later the end time of the suggested push period of a task to be pushed is compared with the end time of the next push cycle, the smaller the dynamic recommendation score obtained after correction is compared with the recommendation score. 7) For any real-time push target, if the number of pushable tasks in its preferred push task set is less than its maximum push volume in the next push cycle, then its preferred push task set is used as its real-time push task set. Otherwise, the pushable tasks in its preferred push task set are sorted in descending order according to their dynamic recommendation scores in the next push cycle, and the top few pushable tasks are selected to construct its real-time push task set. The selected pushable tasks are equal to its maximum push volume in the next push cycle, thus completing the construction of the real-time push task set.

[0011] Furthermore, the logic for determining the push status based on the judgment logic is as follows: 2.1) If a push object is performing an insurance access action at the start of the current push period, then set its behavior scenario at the start of the current push period to the insurance access scenario, and set the push status of the push object at the start of the current push period to suggested push. 2.2) If a push target is performing payment, identity verification, immersive entertainment, or vehicle driving actions at the start of the current push period, then set its behavior scenario at the start of the current push period to an inappropriate scenario, and set the push status of the push target at the start of the current push period to prohibited push. 2.3) If a push object does not perform the actions belonging to the insurance access scenario and the unsuitable disturbance scenario at the start of the current push period, then its behavior scenario at the start of the current push period is set to other scenarios, and the push status of the push object at the start of the current push period is set to normal push.

[0012] Furthermore, for any real-time push target, the logic for determining the maximum number of pushes it can receive in the next push cycle is as follows: 5.1) Set a maximum push threshold and determine whether the number of push records for insurance products sent to the real-time push target within the historical period is not less than the maximum push threshold. If the result is yes, set the maximum number of pushes that can be received in the next push cycle to 0; otherwise, proceed to step 2). 5.2) Set a static push threshold that is less than the maximum push threshold, and calculate the difference between the static push threshold and the number of push records that push insurance products to the real-time push target in the historical period. If the difference is not greater than 0, set the baseline value of the push volume received in the next push cycle to 0; otherwise, set the difference to the baseline value of the push volume received in the next push cycle. 5.3) Determine whether the push status of the real-time push object at the start of the current push cycle is a suggested push. If it is, set its dynamic push increment in the next push cycle to an integer not less than 1, and the dynamic push increment is less than the maximum push threshold. Otherwise, set its dynamic push increment in the next push cycle to 0. 5.4) The baseline value of the number of pushes received by the real-time push target in the next push period, the dynamic push increment, and the number of push records of insurance products pushed to the real-time push target in the historical period are accumulated. If the sum is not less than the maximum push threshold, the difference between the maximum push threshold and the number of push records of insurance products pushed to the real-time push target in the historical period is calculated as the maximum number of pushes received by the real-time push target in the next push period. Otherwise, the sum of the baseline value of the number of pushes received by the real-time push target and the dynamic push increment in the next push period is calculated as the maximum number of pushes received by the real-time push target in the next push period.

[0013] Furthermore, the calculation logic for the dynamic recommendation score is as follows: 6.1) For any task to be pushed in the preferred push set, calculate the time difference between the end time of the suggested push period and the end time of the next push cycle. When the end time of the suggested push period is later than the end time of the next push cycle, the time difference is represented by a positive value, and otherwise by a negative value. 6.2) Substitute the time difference into the exponential decay formula to obtain the push urgency index of the task to be pushed in the next push cycle; 6,3) Set an urgency threshold greater than 1, take the minimum value between the urgency threshold and the push urgency index of the task to be pushed in the next push cycle, and multiply it with the recommendation score of the task to be pushed to obtain the dynamic recommendation score of the task to be pushed in the next push cycle.

[0014] Furthermore, the overall push scheduling scheme is as follows: all tasks to be pushed in the central group of real-time push tasks are treated as real-time push tasks, and the push server cluster performs push work on each real-time push task one by one in the next push cycle. For any real-time push object, the construction logic of its push scheme is as follows: construct a push scheme with no internal push tasks, and sort the push tasks in the real-time push task set of the real-time push object in descending order according to the dynamic recommendation score in the next push cycle, and input them into the push scheme one by one in order to update the push scheme. A new push scheme is generated after each update. The logic for calculating the recommendation score for any push plan is as follows: First, determine if the tasks to be pushed in the push plan are empty. If so, set the recommendation score for the push plan to 0. Otherwise, sort the tasks to be pushed in the push plan in descending order according to their dynamic recommendation scores in the next push cycle to determine their position. For any task to be pushed in the push plan, calculate a correction weight with its position minus one as the exponent and a decay factor as the base. The decay factor is a positive decimal. Then, multiply the dynamic recommendation scores of each task to be pushed in the push plan in the next push cycle by the corresponding correction weight and sum them up to obtain the recommendation score for the push plan. The decay factor corresponding to a push status of "suggested push" is greater than the decay factor corresponding to a push status of "normal push". The logic for finding the optimal push scheme based on the genetic algorithm is as follows: With the constraint that the total number of tasks to be pushed within an individual does not exceed the maximum push volume of the next push cycle, several push schemes are randomly selected from the push schemes of each real-time push object and arranged in combination to form multiple individuals to construct an initial population. Each individual is composed of a push scheme from each real-time push object. Each push scheme is considered a gene of the individual. For any individual, the recommendation scores of each push scheme within it are accumulated to obtain the individual's fitness value. Individuals are sorted in descending order of fitness value, and the top 50% of individuals are selected as parents. Crossover and mutation operations are performed between each pair of parents to generate offspring. The fitness value of the offspring is calculated using the same method. The offspring and parents are then combined to form a new population. Individuals whose total number of tasks to be pushed exceeds the maximum push volume of the next push cycle are removed. The selection, crossover, and mutation operations are repeated until the predetermined number of iterations is reached. From the individuals that meet the constraints, the individual with the highest fitness value is selected as the optimal individual. The push schemes within the optimal individual are the optimal push schemes for the corresponding real-time push object.

[0015] A load-aware intelligent insurance push scheduling system, used to execute the aforementioned load-aware intelligent insurance push scheduling method, includes: The push volume determination module is used to obtain the load parameter set and task push volume of the push server cluster in real time during the current period, so as to determine the maximum task push volume in the next push cycle. The load parameter set includes three load parameters: CPU utilization, memory usage ratio, and database connection pool utilization. The task set construction module is used to extract task information from the task queue of the push server cluster at the end of the current time period, query the behavior scenario of the push object, filter out the real-time push object and its real-time push task set, and calculate the dynamic recommendation score of each push task in the real-time push task set in the next push cycle. The scheduling module is used to determine whether the maximum number of tasks to be pushed in the next push cycle is less than the total number of tasks to be pushed in all real-time push task sets. If so, the push is scheduled based on the overall push scheduling scheme; otherwise, the push is scheduled based on the selective push scheduling scheme.

[0016] Compared with the prior art, the beneficial effects of the present invention are: The present invention relates to a load-aware intelligent insurance push scheduling method and system. First, based on the load parameters and task push volume of the current time period, the maximum task push volume for the next push cycle is determined. Then, based on behavioral scenarios, real-time push objects and their real-time push task sets are dynamically filtered, and the dynamic recommendation score of each task to be pushed in the real-time push task set is calculated in the next push cycle. Finally, based on the real-time push task sets of each real-time push object, several push schemes are determined. With the maximum task push volume as a constraint benchmark and the maximization of the fitness value calculated based on the dynamic recommendation score as the optimization objective, a genetic algorithm is used to solve for the optimal solution to determine the optimal push scheme for each real-time push object in the next push cycle. This improves the accuracy and timeliness of the reach while ensuring the stability of the cluster load. Attached Figure Description

[0017] Figure 1 This is a schematic flowchart of the overall method of the present invention; Figure 2 This is a modular unit diagram of the overall system of the present invention; Figure 3 This is a schematic diagram illustrating the relationship between time difference and push urgency index in this invention; Figure 4 This is a schematic diagram illustrating the changes in the recommendation scores for each push scheme in this invention. Detailed Implementation

[0018] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be further described in detail below with reference to specific embodiments.

[0019] It should be noted that, unless otherwise defined, the technical or scientific terms used in this invention should have the ordinary meaning understood by one of ordinary skill in the art to which this invention pertains. The terms "first," "second," and similar terms used in this invention do not indicate any order, quantity, or importance, but are merely used to distinguish different components. Terms such as "comprising" or "including" mean that the element or object preceding the word encompasses the elements or objects listed following the word and their equivalents, without excluding other elements or objects. Terms such as "connected" or "linked" are not limited to physical or mechanical connections, but can include electrical connections, whether direct or indirect. Terms such as "upper," "lower," "left," and "right" are used only to indicate relative positional relationships; when the absolute position of the described object changes, the relative positional relationship may also change accordingly.

[0020] Example 1: Please see Figure 1 , Figure 3 and Figure 4 This embodiment provides a load-aware intelligent insurance push scheduling method, including the following steps: S1: Real-time acquisition of the load parameter set and task push volume of the push server cluster in the current time period to determine the maximum task push volume in the next push cycle. The load parameter set includes three load parameters: CPU utilization, memory usage ratio and database connection pool utilization. It should be noted that when pushing insurance products, the push server cluster generally adopts the "micro-batch scheduling" method, which divides time into several consecutive time segments and pushes the corresponding insurance products in each time segment. Each time segment is a push cycle, and the end time of the previous push cycle is the start time of the next push cycle. The duration of the push cycle is generally set between 500ms and 1s. This can quickly respond to changes in the load of the push server cluster without generating too much scheduling overhead. The current time period is the time interval formed by tracing back the first time threshold from the end time of the current push cycle. The logic for determining the current push cycle is as follows: if a push cycle meets the condition that its end time is no earlier than the current time and its start time is earlier than the current time, it means that the push cycle is in progress at the current time, and the push cycle is taken as the current push cycle. This avoids the problem of unclear definition between the current push cycle and the next push cycle. The duration of the first time threshold is longer than the duration of the push cycle and is an integer multiple of the duration of the push cycle. It can generally be set between 5 and 10 seconds. This facilitates the subsequent analysis of the load parameters and task push volume of the push server cluster in the recent push cycles, determines the recent working status of the push server cluster, and then accurately determines the maximum task push volume of the next push cycle based on the working status. The setting of 5-10 seconds, while fully collecting the load parameters and task push volume in the recent push cycles, avoids including the load parameters and task push volume in the push cycle that is too early in the calculation, which would lead to the distortion of the calculated maximum task push volume of the next push cycle. That is, when calculating the maximum task push volume of the next push cycle, only the recent working status of the push server cluster is considered. Since the end time of the current push cycle is the start time of the next push cycle, the maximum task push volume of the next push cycle is calculated at the end time of the current push cycle. The specific calculation logic is as follows: 1) Take each push period in the current time period as the target push period. For each target push period, obtain the task push volume of the push server cluster in the target push period in real time, as well as the load parameters at the start and end times of the target push period. As one implementation method, an Agent is deployed on the push server cluster. The Agent is used to obtain the CPU utilization, memory usage percentage, and database connection pool usage percentage of the push server cluster at the start and end of the target push period in real time, as well as the number of tasks pushed within the target push period. The number of tasks pushed by the push server cluster within a push period is the total number of tasks to be pushed by the push server cluster to complete the push work within that push period. The Agent can generally adopt lightweight technologies such as Prometheus Exporter or Telegraf to avoid the Agent itself consuming too much push server cluster resources. Using the Agent to obtain the number of tasks pushed, CPU utilization, memory usage percentage, and database connection pool usage percentage is a conventional technique for those skilled in the art, and will not be elaborated here. 2) For any target push period, calculate the difference between various load parameters at the end time and the start time to obtain the net increase in various load consumption caused by task push under the target push period, including the net increase in CPU consumption, the net increase in memory consumption and the net increase in database connection pool consumption. Divide the net increase in various load consumption by the number of tasks pushed under the same target push period to obtain the boundary consumption rate of various loads per task under the target push period, including the boundary consumption rate of CPU, the boundary consumption rate of memory and the boundary consumption rate of database connection pool. Specifically, for any target push period, the CPU utilization at the end time is subtracted from the CPU utilization at the start time to obtain the net increase in CPU consumption caused by task push under that target push period. The net increase in CPU consumption is divided by the number of tasks pushed under the same target push period to obtain the CPU boundary consumption rate per task under that target push period. The calculation methods for the net increase in memory consumption, the net increase in database connection pool consumption, the memory boundary consumption rate, and the database connection pool boundary consumption rate are similar and will not be elaborated here. It should be noted that, under normal circumstances, the more tasks are pushed within a push cycle, the higher the net increase in the various loads of the push server cluster will be. Here, we calculate the boundary consumption rate of various loads of a unit task by first calculating the difference and then the ratio, so as to homogenize the impact of each push task on the load of the push server cluster. That is, we assume that each push task has the same impact on the same load in the push server cluster, which greatly improves the efficiency of calculating the maximum number of tasks pushed in the next push cycle. 3) Average the various load boundary consumption rates of each unit task under each target push cycle to obtain the various load boundary consumption rates of each unit task under the current time period. Specifically, the logic for averaging the CPU boundary consumption rate of a unit task under each target push cycle is as follows: the CPU boundary consumption rate of a unit task under each target push cycle in the current time period is accumulated, and the accumulated result is divided by the number of target push cycles in the current time period to obtain the CPU boundary consumption rate of a unit task in the current time period. The calculation methods for memory boundary consumption rate and database connection pool boundary consumption rate are similar and will not be elaborated here. Here, the averaging method is used to further homogenize the impact of each push task on the same load of the push server cluster in the current time period, so as to avoid the problem that the maximum task push volume calculated in the subsequent calculation is unreasonable due to random errors. 4) Retrieve the CPU utilization, memory usage percentage, and database connection pool utilization rate at the end of the current push cycle, and compare them with the corresponding comparison thresholds. If at least one of the three is not less than the corresponding comparison threshold, it means that at least one of the CPU utilization, memory usage percentage, and database connection pool utilization rate of the push server cluster has exceeded the limit at the end of the current push cycle. In this case, the maximum task push volume of the next push cycle is set to 0 to avoid the push server cluster crashing due to the continued execution of push tasks. Otherwise, proceed to step 5). The comparison thresholds include the CPU utilization threshold, memory usage percentage threshold, and database connection pool utilization rate threshold. It should be noted that the specific values ​​of the CPU utilization threshold, memory usage threshold, and database connection pool utilization threshold are set by the staff according to the actual situation. In normal applications, when the CPU utilization exceeds 80%, the overhead of thread context switching will increase significantly, leading to a non-linear decrease in processing capacity. Generally, 20% should be reserved to cope with the overhead of sudden tasks or system management processes. When the memory usage exceeds 85%, Full GC may be frequently triggered, causing the system to "pause," which in turn leads to a backlog of push tasks or even an OOM crash. In addition, when the database connection pool utilization is full (100%), new push task threads will be forced to suspend and wait. A large number of suspended threads will consume CPU and memory in turn, quickly triggering a cascading effect. Generally, 15% of idle connections should be reserved to handle urgent database management operations or high-priority single policy queries. Therefore, the CPU utilization threshold is set to 80%, the memory usage threshold is set to 85%, and the database connection pool utilization threshold is set to 85%. Of course, the specific values ​​can also be adjusted by the staff according to the actual situation, and no restrictions are imposed here. 5) Subtract the CPU utilization, memory usage percentage, and database connection pool utilization rates at the end of the current push cycle from the CPU utilization threshold, memory usage percentage threshold, and database connection pool utilization rate threshold, respectively, to obtain the remaining capacity of CPU utilization, memory usage percentage, and database connection pool utilization rate for the next push cycle. Then divide each of these three values ​​by the CPU boundary consumption rate, memory boundary consumption rate, and database connection pool boundary consumption rate of the unit task in the current time period, respectively, to obtain three values. Round down the minimum of the three values ​​to obtain the maximum task push volume for the next push cycle. It should be noted that the remaining capacity of CPU utilization, the remaining capacity of memory usage percentage, and the remaining capacity of database connection pool occupancy percentage represent the available CPU, memory, and database connection pool of the push server cluster in the next push cycle, respectively. Therefore, the remaining capacity of CPU utilization is divided by the CPU boundary consumption rate of a unit task in the current period. The resulting value is the maximum task push volume calculated from the perspective of ensuring CPU safety. Similarly, the remaining capacity of memory usage percentage is divided by the memory boundary consumption rate of a unit task in the current period. The resulting value is the maximum task push volume calculated from the perspective of ensuring memory safety. The remaining capacity of database connection pool occupancy percentage is divided by the database connection pool boundary consumption rate of a unit task in the current period. The resulting value is the maximum task push volume calculated from the perspective of ensuring database connection pool safety. To ensure the safe operation of the push server cluster and prevent it from crashing, based on conservative estimates and the principle of safety redundancy, the minimum value among the three values ​​is taken and rounded down as the maximum task push volume for the next push cycle.

[0021] S2, for the task queue of the push server cluster at the end of the current time period, extract the task information of each task to be pushed, and query the behavior scenario of the push object to filter out the real-time push object and its real-time push task set, and calculate the dynamic recommendation score of each task to be pushed in the real-time push task set in the next push cycle. It should be noted that in the application field of insurance product recommendation, insurance companies typically use their own or third-party task generation engines to conduct big data analysis on customer identity information, short-term and long-term behavioral data, etc., to generate insurance product recommendation plans for each customer. These plans include a set of insurance products to be pushed to the corresponding customer. For any insurance product in this set, it is bound to the corresponding customer, forming a task to be pushed. When generating a task, the task generation engine also generates a recommendation score and a suggested push time period. The recommendation score (also called a score, prediction score, potential value, etc.) reflects the quality of the task; the higher the value, the higher the probability that the target customer will purchase the recommended product, and the better the task. The recommendation score is generally on a 100-point scale, ranging from 0 to 100. The suggested push time period indicates the appropriate time to push the task. Generating tasks, recommendation scores, and suggested push time periods through task generation engines is a common technique used by those skilled in the art, such as Pega Systems' "Customer Decision Hub" and Salesforce Marketing Cloud's Einstein. AI, Ping An Life's "Intelligent Dispatch Platform", and ZhongAn's self-developed "Poseidon" marketing decision-making platform can all achieve the above functions, which will not be elaborated here. It should be noted that after receiving the push task, the push server cluster pushes the insurance product in the push task to the customer bound to it, thus completing the push task. However, due to the limitations of hardware resources, network bandwidth and concurrent processing capabilities, the push server cluster often cannot process a massive number of push tasks instantly, resulting in some push tasks accumulating in the push server cluster to form a task sequence (or task buffer). The push server cluster needs to selectively push the push tasks in the task queue according to the set push scheduling scheme. How to set up a push scheduling scheme to scientifically select push tasks from the task sequence in high-concurrency scenarios, and improve the accuracy and timeliness of the reach while ensuring the stability of the cluster load, is the technical problem that this technical solution aims to solve. For any task to be pushed, the task information includes: 1) the number of the product to be pushed, which is the insurance product to be pushed in the task; 2) the identity code of the target user, which is the customer to whom the insurance product is to be pushed in the task; 3) the recommendation score of the task to be pushed; and 4) the suggested push time period for the task to be pushed. In addition, the insurance product number and the user identity code are custom names for insurance products and users in the insurance company's own database. Extracting the above task information from the task to be pushed is a conventional technical means for those skilled in the art, and will not be elaborated here. Furthermore, the task information may also include the expiration time of the task to be pushed. The push server cluster checks each task to be pushed in the task queue in real time to remove tasks whose expiration time is earlier than the current time, so as to avoid pushing insurance products in expired tasks to customers and causing their dissatisfaction. The expiration time is also generated by the task generation engine. In addition, the well-known methods of those skilled in the art will not be described in detail here. In this context, the generation of the push scheduling scheme for any push cycle requires a certain amount of time. If the relevant analysis and processing are only performed at the beginning of the push cycle to generate the push scheduling scheme for that push cycle, the push time of that push cycle will be shortened. Therefore, in this technical solution, at the beginning of each push cycle, the real-time push task filtering and push scheduling scheme generation for the next push cycle are executed to ensure that the corresponding push scheduling scheme is generated before the start of the next push cycle. Therefore, in the subsequent real-time push task filtering step 2), the behavior scenario at the beginning of the current push cycle is used, rather than the behavior information at the end of the current push cycle. Moreover, the task queue of the push server cluster at the end of the current time period is not directly extracted. Instead, at the beginning of the current push cycle, the task queue of the push server cluster at the beginning of the current time period is retrieved, and the tasks to be pushed in the push scheduling scheme of the current push cycle are retrieved. From the task queue of the push server cluster at the beginning of the current time period, the tasks to be pushed in the push scheduling scheme of the current push cycle are removed to obtain the task queue of the push server cluster at the end of the current time period. The logic for determining dynamic recommendation scores, real-time push targets, and their real-time push task sets is as follows: 1) For any task to be pushed in the task queue of the push server cluster at the end of the current time period, extract its task information. If the push object identity code of two push tasks is the same, it means that the push object of the two push tasks is the same customer. The push tasks with the same push object identity code are grouped into the same set to form a push task set that corresponds one-to-one with each push object. Here, the push tasks are first clustered based on the push object identity code. The clustering setting is used to improve the efficiency of subsequent push scheme generation and real-time push task generation. 2) For any push target, based on its identity code, query its behavior scenario at the start of the current push cycle. The identity code is the identification benchmark for the push target, which facilitates the organization and summarization of information collected from the same push target in different dimensions. Based on the preset judgment logic, the behavior scenario is analyzed to determine the push status of the push target at the start of the current push cycle, which is suggested push, normal push, or prohibited push. The behavior scenario includes insurance access scenario, do not disturb scenario, and other scenarios. The logic for determining the push status based on the judgment logic is as follows: 2.1) If a target is performing insurance access actions such as browsing insurance product details pages or consulting online customer service at the start of the current push period, it indicates that the target has a strong demand for insurance purchase at the start of the current push period. Therefore, the behavior scenario at the start of the current push period is set as an insurance access scenario, and the push status of the target at the start of the current push period is set as a suggested push. In addition, the specific insurance access actions such as browsing insurance product details pages and consulting online customer service can be identified and determined through internal data points of the insurance APP. This is existing technology and will not be elaborated here. 2.2) If a push notification recipient is performing actions that require focused attention and should not be disturbed at the start of the current push period, such as payment, identity verification, immersive entertainment, or driving, it indicates that the recipient should not be disturbed at the start of the current push period. Pushing insurance products to them would likely cause them to feel averse to the activity. Therefore, their behavior scenario at the start of the current push period is set to an indisturbed scenario, and their push status is set to prohibited. In addition, payment actions can be identified and determined through SDK lifecycle callbacks, identity verification actions can be identified and determined through biometric API calls, immersive entertainment actions can be identified and determined through game mode monitoring, landscape mode monitoring, etc., and driving actions can be identified and determined through navigation API calls, GPS speed analysis, and in-vehicle Bluetooth / CarPlay connection monitoring, etc. These are existing technologies and will not be elaborated here. 2.3) If a push target does not perform the actions belonging to the insurance access scenario and the unbearable disturbance scenario at the beginning of the current push period, it means that the push target does not have a strong need to purchase insurance or a strong aversion to insurance push at the beginning of the current push period. In this case, the behavior scenario of the push target at the beginning of the current push period is set to other scenarios, and the push status of the push target at the beginning of the current push period is set to normal push. 3) Extract the push objects whose push status is suggested push or normal push at the beginning of the current push cycle, and use them as real-time push objects. By identifying whether the push objects are willing to receive push insurance products to them in the next push cycle, select the real-time push objects to perform push work on them in the next push cycle, thus providing a basis for filtering real-time push tasks. 4) For any real-time push target, select push tasks from its push task set that have an overlap between the suggested push period and the next push week, and summarize them to form the preferred push task set for that real-time push target. It should be noted that if the suggested push period of a task to be pushed overlaps with the next push cycle, it means that there is a suitable time interval for the task to be pushed to perform push work in the next push cycle. Therefore, the tasks to be pushed that overlap between the suggested push period and the next push cycle are selected to form the preferred push task set for the real-time push object, which is convenient for further selection of the real-time push task set from the preferred push task set. 5) For any real-time push target, combine the number of push records of insurance products pushed to it in the historical period and its push status at the beginning of the current push period to determine its maximum push volume in the next push period. If the maximum push volume of a real-time push target in the next push period is 0, it means that insurance products will not be pushed to it in the next push period. Therefore, real-time push targets with a maximum push volume of 0 in the next push period are removed to reduce the amount of computation when using the genetic algorithm to determine the real-time push task. The logic for determining the maximum number of push notifications a given real-time push recipient can receive in the next push cycle is as follows: 5.1) Set a maximum push threshold and determine whether the number of push records of insurance products pushed to the real-time push target in the historical period is not less than the maximum push threshold. If the result is yes, it means that the real-time push target has received enough insurance product pushes in the historical period, and continuing to push to it is likely to arouse its resentment. Then, set the maximum number of pushes it can receive in the next push cycle to 0. Otherwise, proceed to step 2). As one implementation method, the historical period is the time interval that starts from the start time of the current day and ends at the end time of the current push cycle. The maximum push threshold is generally set to 4 or 5. Under normal circumstances, customers will inevitably develop a sense of resistance and resentment after receiving 5 or more insurance product pushes in a day. Therefore, the maximum push threshold can be set to 4 or 5. It should be noted that the end of the historical period is the end of the current push cycle. However, in this technical solution, the real-time push task screening and push scheduling scheme generation work begins at the start of the current push cycle. Therefore, it is not possible to directly retrieve the number of push records of insurance products pushed to the real-time push object within the historical period. The calculation method is as follows: First, a time interval is divided with the start time of the current day as the starting time and the start time of the current push cycle as the ending time. For any real-time push object, the number of push records of insurance products pushed to the real-time push object within this time interval is retrieved. That is, the number of push tasks to be pushed to the real-time push object by the push server cluster within this time interval. Then, the number of push records of insurance products pushed to the real-time push object within the current push cycle is retrieved from the push scheduling scheme of the current push cycle. That is, the number of push tasks to be pushed to the real-time push object by the push server cluster according to the push scheduling scheme of the current push cycle. The two are then summed to obtain the number of push records of insurance products pushed to the real-time push object within the historical period. 5.2) Set a static push threshold that is less than the maximum push threshold, and calculate the difference between the static push threshold and the number of push records of insurance products pushed to the real-time push target in the historical period. If the difference is not greater than 0, it means that under normal circumstances, it is not appropriate to push insurance products to the real-time push target. Then, the baseline value of the push volume received in the next push cycle is set to 0. Otherwise, it means that under normal circumstances, it is still possible to continue pushing insurance products to the real-time push target. Then, this difference is set as the baseline value of the push volume received in the next push cycle. As an implementation method, based on industry best practices and user experience red lines summarized from insurance marketing practices, under normal circumstances, the number of times insurance products are pushed to customers within 24 hours should not exceed 1, so as to avoid the problem of frequent pushes causing customer resentment. Therefore, the static push threshold is set to 1. Of course, the specific value of the static push threshold can also be adjusted by staff according to the actual situation, but it should generally not be greater than 2. 5.3) Determine whether the push status of the real-time push target at the start of the current push period is a suggested push. If it is, it means that the real-time push target has a strong purchase demand at the start of the current push period. Then, set the dynamic push increment of the target in the next push period to an integer not less than 1, and the dynamic push increment is less than the maximum push threshold. Generally, it can be set to 1 or 2. That is, when the real-time push target has a strong purchase demand, it is exempt from the limitation of the static push threshold and can push 1-2 more insurance products in the next push period. This achieves the effect of dynamically updating the push volume based on the purchase demand of the real-time push target. Conversely, if the real-time push target does not have a strong purchase demand at the start of the current push period, set the dynamic push increment of the target in the next push period to 0. That is, in the next push period, it will still strictly follow the limitation of the static push threshold and will not push additional insurance products. 5.4) The baseline value of push notifications received by the real-time push recipient in the next push cycle, the dynamic push increment, and the number of push records of insurance products pushed to the real-time push recipient in the historical period are summed. The sum is the result of the sum of the above three. If the sum is not less than the maximum push threshold, it means that the sum of the number of insurance products pushed to the real-time push recipient up to the next push cycle and the number of insurance products planned to be pushed to the real-time push recipient in the next push cycle has reached / exceeded the maximum push threshold. Even with the influence of the real-time push recipient's purchase demand, there is still a risk of excessive pushes leading to customer backlash. To address the issue of sensitivity, the difference between the maximum push threshold and the number of push records of insurance products pushed to the real-time push target within a historical period is calculated. This difference serves as the maximum number of pushes the real-time push target can receive in the next push cycle. By setting this maximum push threshold as a red line, the reasonableness of the maximum number of pushes received in the next push cycle is ensured. Conversely, if the threshold is too low, the sum of the baseline value of the number of pushes received by the real-time push target in the next push cycle and the dynamic push increment is calculated as the maximum number of pushes the real-time push target can receive in the next push cycle. This achieves the effect of dynamically setting the maximum number of pushes received based on the purchase needs of the real-time push target. 6) For any task to be pushed in the preferred push set, the recommendation score of the task to be pushed is corrected based on the time relationship between the end time of its suggested push period and the end time of the next push cycle, so as to obtain the dynamic recommendation score of the task to be pushed in the next push cycle. The later the end time of the suggested push period of a task to be pushed is compared with the end time of the next push cycle, the smaller the dynamic recommendation score obtained after correction is compared with the recommendation score. The calculation logic for the dynamic recommendation score is as follows: 6.1) For any task to be pushed in the preferred push set, calculate the time difference between the end time of the suggested push period and the end time of the next push cycle. When the end time of the suggested push period is later than the end time of the next push cycle, the time difference is represented by a positive value, and otherwise by a negative value. In this way, the time difference characterizes the temporal relationship between the end time of the suggested push period and the end time of the next push cycle. 6.2) Substitute the time difference into the exponential decay formula to obtain the push urgency index of the task to be pushed in the next push cycle. The specific mathematical expression is as follows:

[0022] In the formula, This is the time difference, in minutes. For tasks to be pushed out in time difference The urgency index of the push notification This is the decay constant; the larger the value, the faster the decay. The specific setting is determined by the staff based on the actual situation. For example, in the application scenario of this technical solution, the midpoint of the suggested push period for the task to be pushed is used as the dividing point. If the end time of the next push cycle is earlier than the dividing point of the task to be pushed, it is considered that the task still has a relatively ample push time interval and the urgency of pushing is low. Conversely, if the end time of the next push cycle is later than the dividing point of the task to be pushed, it is considered that the task no longer has a relatively ample push time interval and the urgency of pushing is high. Therefore, the half-life of the task to be pushed can be set to half the duration of its suggested push period. For example, if the suggested push period is 10:00-12:00, the half-life is set to 1 hour, or 60 minutes. The decay constant can generally be set to... The ratio to the half-life can, of course, be set by the staff according to the actual situation, which will not be elaborated here; 6,3) Set an urgency threshold greater than 1, take the minimum value between the urgency threshold and the push urgency index of the task to be pushed in the next push cycle, and multiply it with the recommendation score of the task to be pushed to obtain the dynamic recommendation score of the task to be pushed in the next push cycle. The higher the push urgency index, the higher the urgency of the task to be pushed in the next push cycle, and the more it needs to be pushed in the next push cycle. Therefore, its dynamic recommendation score in the next push cycle will also be higher. It should be noted that setting an urgency threshold and taking the minimum value is to avoid over-amplifying the recommendation score, which would lead to an unreasonable dynamic recommendation score. The urgency threshold can generally be set between 1.2 and 1.5 to avoid the dynamic recommendation score being too large. For example, a value of 1.2 means that the maximum amplification ratio of the recommendation score is considered to be 1.2. Further amplification would lead to data distortion. 7) For any real-time push target, if the number of pushable tasks in its preferred push task set is less than its maximum push volume in the next push cycle, then its preferred push task set is used as its real-time push task set. Otherwise, the pushable tasks in its preferred push task set are sorted in descending order according to their dynamic recommendation scores in the next push cycle, and the top few pushable tasks are selected to construct its real-time push task set. The selected pushable tasks are equal to its maximum push volume in the next push cycle, thus completing the construction of the real-time push task set.

[0023] S3. Determine whether the maximum number of tasks to be pushed in the next push cycle is less than the total number of tasks to be pushed in all real-time push task sets. If yes, it means that the push server cluster can complete the push work of all real-time push task sets in the next push cycle. Then push scheduling is carried out based on the overall push scheduling scheme. Otherwise, push scheduling is carried out based on the selective push scheduling scheme. The overall push scheduling scheme is as follows: all real-time push tasks are concentrated into a group of tasks to be pushed as real-time push tasks. The push server cluster will execute the push work for each real-time push task one by one in the next push cycle. Specifically, the push work can be executed for each real-time push task one by one in order of dynamic recommendation score from high to low in the next push cycle. The selective push scheduling scheme is as follows: a push scheme for the corresponding real-time push object is constructed based on the real-time push task set, and a scheme recommendation score for each push scheme is generated based on the dynamic recommendation score. The maximum task push volume is used as the constraint benchmark, and the fitness value calculated based on the scheme recommendation score is used as the optimization objective. The optimal push scheme for each real-time push object is solved by a genetic algorithm. The push tasks to be pushed in the optimal push scheme are used as real-time push tasks. The push server cluster performs push work on each real-time push task one by one in the next push cycle. Specifically, the push work can be performed on each real-time push task one by one in the order of the dynamic recommendation score of each real-time push task in the next push cycle from high to low. Specifically, for any real-time push target, the logic for constructing its push scheme is as follows: Construct a push scheme with an empty internal task pool, and then sort the tasks in the real-time push task pool of the target in descending order according to their dynamic recommendation scores in the next push cycle. Input these tasks sequentially into the push scheme to update it. A new push scheme is generated after each update, thus completing the construction of the push scheme for the target. This method ensures that the push server cluster prioritizes tasks with higher dynamic recommendation scores, guaranteeing that insurance products with high suitability and urgent push requirements are recommended to customers first. Compared to constructing a push scheme by arranging and combining tasks, this significantly reduces the number of push schemes and the workload of subsequent genetic algorithm iterations and optimizations. As one implementation method, if a real-time push task set for a real-time push object includes three push tasks, then a total of four push schemes are constructed. The push task set in the first push scheme is empty, which means that in this push scheme, insurance products are not pushed to the real-time push object. In other push schemes, it means that the corresponding insurance products are pushed to the real-time push object based on the push tasks in the corresponding push scheme. The second push scheme only includes the push task with the largest dynamic recommendation score in the real-time push task set. The third push scheme includes the two push tasks with the largest and second largest dynamic recommendation scores in the real-time push task set. The fourth push scheme includes all push tasks in the real-time push task set. Furthermore, if two or more tasks to be pushed have the same dynamic recommendation score in the next push cycle within the same real-time push task set, they will be sorted a second time based on the end time of the suggested push period. That is, the tasks to be pushed with the earlier end time of the suggested push period will be sorted first, so as to prioritize the tasks to be pushed with higher urgency. If the end time of the suggested push period is still the same, the tasks to be pushed with the same end time of the suggested push period will be randomly sorted. The calculation logic for the recommendation score of any push plan is as follows: First, determine if the tasks to be pushed in the plan are empty. If so, it means that executing the push plan cannot process the tasks, and the recommendation score for the plan is set to 0, meaning the beneficial value of the plan is minimized. Otherwise, sort the tasks to be pushed in the plan in descending order according to their dynamic recommendation scores in the next push cycle to determine their position. For any task to be pushed in the plan, calculate a correction weight with its position minus one as the exponent and a decay factor as the base (the decay factor is a positive decimal). Then, multiply the dynamic recommendation scores of all tasks to be pushed in the plan in the next push cycle by the corresponding correction weight and sum them up to obtain the recommendation score for the push plan. The specific mathematical expression is as follows: In the formula, represents the dynamic recommendation score of the task to be pushed in the next push cycle, with the position . This refers to the order of tasks to be pushed within the push plan. This represents the number of tasks to be pushed within the push plan. This is the attenuation factor, which is determined based on the push status of the real-time push object at the start of the current push cycle. The attenuation factor corresponding to the push status of "suggested push" is greater than the attenuation factor corresponding to the push status of "normal push". The recommended score for the push notification scheme; It should be noted that if multiple insurance products are pushed to the same customer in the same push cycle, the customer's annoyance will gradually increase as the number of insurance products pushed increases. Therefore, for any push scheme, the real-time push recipient will still have a high level of interest in the insurance products in the first-ranked (i.e., the one with the highest dynamic recommendation score) task in the push scheme. However, starting from the second-ranked (i.e., the one with the second highest dynamic recommendation score) task in the push scheme, the real-time push recipient's annoyance with the pushed insurance products will gradually increase. Therefore, it is necessary to gradually reduce the dynamic recommendation score of the task starting from the second-ranked task to reflect the true beneficial value of the push scheme. Thus, an exponential decay formula is used to calculate the scheme recommendation score of the push scheme. For real-time push recipients whose push status is "suggested push" at the start of the current push cycle, they have a strong need for insurance. Therefore, when calculating the recommended score for their push plan, a larger attenuation factor is used, such as between 0.6 and 0.8, to fully consider their strong need for insurance and reduce their aversion to insurance pushes. For real-time push recipients whose push status is "normal push" at the start of the current push cycle, they have a moderate need for insurance. Therefore, when calculating the recommended score for their push plan, a smaller attenuation factor is used, such as between 0.3 and 0.5, to reflect the effect that the aversion to insurance pushes increases approximately doubling with the number of pushes. The specific value of the attenuation factor is set by the staff according to the actual situation and will not be elaborated here. As one implementation, a real-time push object's real-time push task set includes three tasks to be pushed, with dynamic recommendation scores of 92, 83, and 72 respectively. Therefore, there are four push schemes for this real-time push object: Push Scheme 1, Push Scheme 2, Push Scheme 3, and Push Scheme 4. Push Scheme 1 has no tasks to be pushed; Push Scheme 2 includes only the task with a dynamic recommendation score of 92; Push Scheme 3 includes only two tasks with dynamic recommendation scores of 92 and 83; and Push Scheme 4 includes all three tasks mentioned above. If the push status of this real-time push object at the start of the current push cycle is "suggested push," its decay factor is set to... The recommended scores for push schemes 1, 2, 3, and 4 are 0.7, 92, 150.1, and 185.38, respectively. However, if the push status of the real-time push target at the start of the current push cycle is normal, and its attenuation factor is set to 0.4, the recommended scores for push schemes 1, 2, 3, and 4 are 0, 92, 125.2, and 136.72, respectively. This shows that the recommended score for the same push scheme varies depending on the push status, and the recommended score for a suggested push is significantly higher than that for a normal push. For a more intuitive representation of this characteristic, please refer to the accompanying diagram in the manual below. Figure 4 ,exist Figure 4 The blue line represents the recommended score calculated under suggested push notifications, while the orange line represents the recommended score calculated under normal push notifications. The logic for finding the optimal push scheme based on the genetic algorithm is as follows: With the constraint that the total number of tasks to be pushed within an individual does not exceed the maximum number of tasks to be pushed in the next push cycle, several push schemes are randomly selected from the push schemes of each real-time push object and arranged in combination to form multiple individuals to construct an initial population. Each individual is composed of a push scheme from each real-time push object. Each push scheme is considered a gene of the individual, and the number of gene positions within an individual is equal to the number of real-time push objects. One gene position corresponds to one real-time push object. For any individual, the recommendation scores of each push scheme are accumulated to obtain the individual's fitness value. Individuals are then sorted in descending order of fitness value. Select the top 50% of individuals as parents. Perform crossover and mutation operations on each pair of parents to generate offspring. The mutation operation specifically involves mutating the push scheme at the gene locus within an individual into other push schemes for the same real-time push object. Calculate the fitness value of the offspring using the same method. Combine the offspring and parents to form a new population. Remove individuals whose total number of push tasks exceeds the maximum number of push tasks in the next push cycle to ensure the rationality of individuals. Repeat the selection, crossover, and mutation operations until the predetermined number of iterations is reached. From the individuals that meet the constraints, select the individual with the highest fitness value as the optimal individual. The push schemes within the optimal individual are the optimal push schemes for the corresponding real-time push object. It should be noted that in the iterative optimization process based on genetic algorithms, the mutation probability of each gene locus can generally be set between 0.01 and 0.1 to balance population diversity and avoid introducing too much randomness. The population size can generally be set to 100, and the number of iterations can be set between 50 and 70. This is the conventional selection application of genetic algorithms. The specific selection, crossover, and mutation operations are conventional techniques of genetic algorithms and will not be elaborated here. Furthermore, if after removing individuals whose total number of pending tasks exceeds the maximum number of tasks to be pushed in the next push cycle, the number of remaining individuals in the population is less than 80% of the population size, then, with the constraint that the total number of pending tasks in an individual does not exceed the maximum number of tasks to be pushed in the next push cycle, several push schemes are randomly selected from the push schemes of each real-time push object and arranged and combined to form multiple individuals and supplement the population until the number in the population is restored to the set population size, so as to avoid the problem that the population size is too small and affects the optimization effect.

[0024] Example 2, please refer to Figure 2 This embodiment provides a load-aware intelligent insurance push scheduling system for executing the load-aware intelligent insurance push scheduling method in Embodiment 1 above, including: The push volume determination module is used to obtain the load parameter set and task push volume of the push server cluster in real time during the current period, so as to determine the maximum task push volume in the next push cycle. The load parameter set includes three load parameters: CPU utilization, memory usage ratio, and database connection pool utilization. The task set construction module is used to extract task information from the task queue of the push server cluster at the end of the current time period, query the behavior scenario of the push object, filter out the real-time push object and its real-time push task set, and calculate the dynamic recommendation score of each push task in the real-time push task set in the next push cycle. The scheduling module is used to determine whether the maximum number of tasks to be pushed in the next push cycle is less than the total number of tasks to be pushed in all real-time push task sets. If so, the push is scheduled based on the overall push scheduling scheme; otherwise, the push is scheduled based on the selective push scheduling scheme.

[0025] The above formulas are all dimensionless calculations. The formulas are derived from software simulations based on a large amount of collected data to obtain the most recent real-world results. The preset parameters in the formulas are set by those skilled in the art according to the actual situation.

[0026] The above embodiments can be implemented, in whole or in part, by software, hardware, firmware, or any other combination thereof. When implemented in software, the above embodiments can be implemented, in whole or in part, as a computer program product. Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented by electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution.

[0027] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment, depending on actual needs.

[0028] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any changes or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application.

Claims

1. A load-aware intelligent insurance push scheduling method, characterized in that, Includes the following steps: S1: Real-time acquisition of the load parameter set and task push volume of the push server cluster in the current time period to determine the maximum task push volume in the next push cycle. The load parameter set includes three load parameters: CPU utilization, memory usage ratio and database connection pool utilization. S2, for the task queue of the push server cluster at the end of the current time period, extract the task information of each task to be pushed, and query the behavior scenario of the push object to filter out the real-time push object and its real-time push task set, and calculate the dynamic recommendation score of each task to be pushed in the real-time push task set in the next push cycle. S3, determine whether the maximum number of tasks to be pushed in the next push cycle is less than the total number of tasks to be pushed in all real-time push task sets. If yes, push scheduling is performed based on the overall push scheduling scheme; otherwise, push scheduling is performed based on the selective push scheduling scheme. The selective push scheduling scheme is as follows: a push scheme for the corresponding real-time push object is constructed based on the real-time push task set, and a scheme recommendation score is generated for each push scheme based on the dynamic recommendation score. The maximum task push volume is used as the constraint benchmark, and the fitness value calculated based on the scheme recommendation score is used as the optimization objective. The optimal push scheme for each real-time push object is solved by a genetic algorithm. The push tasks to be pushed in the optimal push scheme are used as real-time push tasks. The push server cluster executes the push work for each real-time push task one by one in the next push cycle.

2. The load-aware based intelligent insurance push scheduling method of claim 1, wherein, The current time period is a time interval formed by tracing back a first time threshold from the end time of the current push cycle. The duration of the first time threshold is greater than the duration of the push cycle and is an integer multiple of the duration of the push cycle. The logic for determining the current push cycle is as follows: if a push cycle satisfies that its end time is not earlier than the current time and its start time is earlier than the current time, then the push cycle is taken as the current push cycle. 3.The load-aware based smart insurance push scheduling method of claim 2, wherein, The calculation logic for the maximum task push volume in the next push cycle is as follows: 1) Take each push period in the current time period as the target push period. For each target push period, obtain the task push volume of the push server cluster in the target push period in real time, as well as the load parameters at the start and end times of the target push period. 2) For any target push period, calculate the difference between various load parameters at the end time and the start time to obtain the net increase in various load consumption under the target push period, including the net increase in CPU consumption, the net increase in memory consumption, and the net increase in database connection pool consumption. Divide the net increase in various load consumption by the number of tasks pushed under the same target push period to obtain the boundary consumption rate of various loads per task under the target push period, including the boundary consumption rate of CPU, the boundary consumption rate of memory, and the boundary consumption rate of database connection pool. 3) Average the various load boundary consumption rates of each unit task under each target push cycle to obtain the various load boundary consumption rates of each unit task under the current time period. 4) Retrieve the CPU utilization, memory usage percentage, and database connection pool occupancy rate at the end of the current push cycle, and compare them one by one with the corresponding comparison thresholds. If at least one of the three is not less than the corresponding comparison threshold, then set the maximum task push volume of the next push cycle to 0; otherwise, proceed to step 5). The comparison thresholds include the CPU utilization threshold, memory usage percentage threshold, and database connection pool occupancy rate threshold. 5) Subtract the CPU utilization, memory usage percentage, and database connection pool utilization rates at the end of the current push cycle from the CPU utilization threshold, memory usage percentage threshold, and database connection pool utilization rate threshold, respectively, to obtain the remaining capacity of CPU utilization, memory usage percentage, and database connection pool utilization rate for the next push cycle. Then divide each of these three values ​​by the CPU boundary consumption rate, memory boundary consumption rate, and database connection pool boundary consumption rate of the unit task in the current time period to obtain three values. Round down the minimum of the three values ​​to obtain the maximum task push volume for the next push cycle.

4. The load-aware based intelligent insurance push scheduling method of claim 2, wherein, For any task to be pushed, its task information includes: 1) the number of the product to be pushed, which is the insurance product to be pushed in this task; 2) the identity code of the target audience, which is the customer to whom the insurance product in this task is to be pushed; 3) the recommendation score of the task to be pushed; and 4) the suggested push time period for the task to be pushed.

5. The load-aware based intelligent insurance push scheduling method of claim 4, wherein, The logic for determining the dynamic recommendation score, the real-time push object, and the real-time push task set is as follows: 1) For any task to be pushed in the task queue of the push server cluster at the end of the current time period, extract its task information and classify the tasks to be pushed with the same identity code of the push object into the same set, thereby forming a set of tasks to be pushed that corresponds one-to-one with each push object. 2) For any push target, based on its identity code, query its behavior scenario at the start of the current push cycle, and analyze the behavior scenario based on the preset judgment logic to determine the push status of the push target at the start of the current push cycle, which is suggested push, normal push or blocked push. Behavior scenarios include insurance access scenario, do not want to be disturbed scenario and other scenarios. 3) Extract the push objects whose push status is suggested push or normal push at the start of the current push cycle, and use them as real-time push objects; 4) For any real-time push target, select push tasks from its push task set that have an overlap between the suggested push period and the next push week, and summarize them to form the preferred push task set for that real-time push target. 5) For any real-time push target, combine the number of push records of insurance products pushed to it in the historical period and its push status at the beginning of the current push period to determine its maximum push volume in the next push period, and remove real-time push targets whose maximum push volume in the next push period is 0. 6) For any task to be pushed in the preferred push set, the recommendation score of the task to be pushed is corrected based on the time relationship between the end time of its suggested push period and the end time of the next push cycle, so as to obtain the dynamic recommendation score of the task to be pushed in the next push cycle. The later the end time of the suggested push period of a task to be pushed is compared with the end time of the next push cycle, the smaller the dynamic recommendation score obtained after correction is compared with the recommendation score. 7) For any real-time push target, if the number of pushable tasks in its preferred push task set is less than its maximum push volume in the next push cycle, then its preferred push task set is used as its real-time push task set. Otherwise, the pushable tasks in its preferred push task set are sorted in descending order according to their dynamic recommendation scores in the next push cycle, and the top few pushable tasks are selected to construct its real-time push task set. The selected pushable tasks are equal to its maximum push volume in the next push cycle, thus completing the construction of the real-time push task set.

6. The load-aware based intelligent insurance push scheduling method of claim 5, wherein, The logic for determining the push status based on the judgment logic is as follows: 2.1) If a push object is performing an insurance access action at the start of the current push period, then set its behavior scenario at the start of the current push period to the insurance access scenario, and set the push status of the push object at the start of the current push period to suggested push. 2.2) If a push target is performing payment, identity verification, immersive entertainment, or vehicle driving actions at the start of the current push period, then set its behavior scenario at the start of the current push period to an inappropriate scenario, and set the push status of the push target at the start of the current push period to prohibited push. 2.3) If a push object does not perform the actions belonging to the insurance access scenario and the unsuitable disturbance scenario at the start of the current push period, then its behavior scenario at the start of the current push period is set to other scenarios, and the push status of the push object at the start of the current push period is set to normal push.

7. The intelligent insurance push scheduling method based on load awareness according to claim 5, characterized in that, The logic for determining the maximum number of push notifications a given real-time push recipient can receive in the next push cycle is as follows: 5.1) Set a maximum push threshold and determine whether the number of push records for insurance products sent to the real-time push target within the historical period is not less than the maximum push threshold. If the result is yes, set the maximum number of pushes that can be received in the next push cycle to 0; otherwise, proceed to step 2). 5.2) Set a static push threshold that is less than the maximum push threshold, and calculate the difference between the static push threshold and the number of push records that push insurance products to the real-time push target in the historical period. If the difference is not greater than 0, set the baseline value of the push volume received in the next push cycle to 0; otherwise, set the difference to the baseline value of the push volume received in the next push cycle. 5.3) Determine whether the push status of the real-time push object at the start of the current push cycle is a suggested push. If it is, set its dynamic push increment in the next push cycle to an integer not less than 1, and the dynamic push increment is less than the maximum push threshold. Otherwise, set its dynamic push increment in the next push cycle to 0. 5.4) The baseline value of the number of pushes received by the real-time push target in the next push period, the dynamic push increment, and the number of push records of insurance products pushed to the real-time push target in the historical period are accumulated. If the sum is not less than the maximum push threshold, the difference between the maximum push threshold and the number of push records of insurance products pushed to the real-time push target in the historical period is calculated as the maximum number of pushes received by the real-time push target in the next push period. Otherwise, the sum of the baseline value of the number of pushes received by the real-time push target and the dynamic push increment in the next push period is calculated as the maximum number of pushes received by the real-time push target in the next push period.

8. The intelligent insurance push scheduling method based on load awareness according to claim 5, characterized in that, The calculation logic for the dynamic recommendation score is as follows: 6.1) For any task to be pushed in the preferred push set, calculate the time difference between the end time of the suggested push period and the end time of the next push cycle. When the end time of the suggested push period is later than the end time of the next push cycle, the time difference is represented by a positive value, and otherwise by a negative value. 6.2) Substitute the time difference into the exponential decay formula to obtain the push urgency index of the task to be pushed in the next push cycle; 6,3) Set an urgency threshold greater than 1, take the minimum value between the urgency threshold and the push urgency index of the task to be pushed in the next push cycle, and multiply it with the recommendation score of the task to be pushed to obtain the dynamic recommendation score of the task to be pushed in the next push cycle.

9. The intelligent insurance push scheduling method based on load awareness according to claim 4, characterized in that, The overall push scheduling scheme is as follows: all tasks to be pushed in the set of real-time push tasks are taken as real-time push tasks, and the push server cluster performs push work on each real-time push task one by one in the next push cycle. For any real-time push object, the construction logic of its push scheme is as follows: construct a push scheme with no internal push tasks, and sort the push tasks in the real-time push task set of the real-time push object in descending order according to the dynamic recommendation score in the next push cycle, and input them into the push scheme one by one in order to update the push scheme. A new push scheme is generated after each update. The logic for calculating the recommendation score for any push plan is as follows: First, determine if the tasks to be pushed in the push plan are empty. If so, set the recommendation score for the push plan to 0. Otherwise, sort the tasks to be pushed in the push plan in descending order according to their dynamic recommendation scores in the next push cycle to determine their position. For any task to be pushed in the push plan, calculate a correction weight with its position minus one as the exponent and a decay factor as the base. The decay factor is a positive decimal. Then, multiply the dynamic recommendation scores of each task to be pushed in the push plan in the next push cycle by the corresponding correction weight and sum them up to obtain the recommendation score for the push plan. The decay factor corresponding to a push status of "suggested push" is greater than the decay factor corresponding to a push status of "normal push". The logic for finding the optimal push scheme based on the genetic algorithm is as follows: With the constraint that the total number of tasks to be pushed within an individual does not exceed the maximum task push volume of the next push cycle, several push schemes are randomly selected from the push schemes of each real-time push object and arranged in combination to form multiple individuals to construct an initial population. Each individual is composed of a push scheme from each real-time push object. For any individual, the recommendation scores of each push scheme within it are accumulated to serve as the individual's fitness value. Individuals are sorted in descending order of fitness value, and the top 50% of individuals are selected as parents. Crossover and mutation operations are performed on each pair of parents to generate offspring. The fitness value of the offspring is calculated using the same method, and the offspring and parents are combined to form a new population. Individuals whose total number of tasks to be pushed exceeds the maximum task push volume of the next push cycle are removed. The selection, crossover, and mutation operations are repeated until the predetermined number of iterations is reached. From the individuals that meet the constraints, the individual with the highest fitness value is selected as the optimal individual. The push schemes within the optimal individual are the optimal push schemes for the corresponding real-time push object.

10. A load-aware intelligent insurance push scheduling system, used to execute the load-aware intelligent insurance push scheduling method according to any one of claims 1-9, characterized in that, include: The push volume determination module is used to obtain the load parameter set and task push volume of the push server cluster in real time during the current period, so as to determine the maximum task push volume in the next push cycle. The load parameter set includes three load parameters: CPU utilization, memory usage ratio, and database connection pool utilization. The task set construction module is used to extract task information from the task queue of the push server cluster at the end of the current time period, query the behavior scenario of the push object, filter out the real-time push object and its real-time push task set, and calculate the dynamic recommendation score of each push task in the real-time push task set in the next push cycle. The scheduling module is used to determine whether the maximum number of tasks to be pushed in the next push cycle is less than the total number of tasks to be pushed in all real-time push task sets. If so, the push is scheduled based on the overall push scheduling scheme; otherwise, the push is scheduled based on the selective push scheduling scheme.

Images