Distributed outbound system optimization method based on cloud computing

Abstract

The invention relates to a distributed outbound system optimization method based on cloud computing. The method comprises the following steps: disassembling an outbound task into fine-grained subtasks including dialing, recording, interaction and recording; generating a unique identifier for each subtask; based on a distributed task scheduler; according to node real-time performance and network delay, dynamically distributing tasks, and introducing a task priority rule; monitoring a task execution state in real time through a distributed tracking system; recovering and redistributing abnormal and failed tasks; fragmenting the call-out data according to regions or customer groups, and distributing the call-out data to different nodes; processing the call record and the client feedback by using a stream processing framework comprising Apache Flink; adding a call task including Kafka into a distributed task queue; setting a dynamic priority queue, and adjusting the priority according to the task timeliness; setting an overtime threshold value for the call task, and monitoring a task state in real time; and when the task is overtime or failed, triggering a retry strategy including adjusting the call period and switching the node.

Description

Technical Field

[0001] The present invention relates to a distributed outbound call system optimization method, in particular to a distributed outbound call system optimization method based on cloud computing. Background Art

[0002] At present, there are still many deficiencies and drawbacks in the practical application of the distributed outbound call system optimization method, especially in terms of dynamic load optimization, task scheduling, real-time strategy adjustment and customer experience. Taking the Chinese invention patent with patent number 2020103428168 as an example, the patent proposes a method for configuring an intelligent outbound call system, which mainly assembles node sets through cost calculation and optimization of outbound call nodes, builds a diversion structure and matches outbound call strategies, and uses blockchain technology to store outbound call service sets. Although this method has a certain effect in reducing telephone sales costs and improving efficiency, it still faces the following significant problems: First, this method overemphasizes node cost optimization, but pays insufficient attention to the dynamic load of the system.

[0003] In practical applications, the load status of outbound call nodes will fluctuate with the changes in the task volume and external environment. Relying solely on cost optimization may lead to node performance overload or resource waste. For example, during the peak period of tasks, some nodes may be delayed or fail due to overload, while other nodes may be idle due to improper allocation, resulting in inefficient use of resources. Therefore, this method lacks a dynamic monitoring and adjustment mechanism for the real-time performance of nodes (such as CPU, memory, and network bandwidth load), and it is difficult to meet the needs of modern distributed systems. Secondly, the diversion structure in this method is designed as a static architecture, which fails to consider the dynamic adjustment ability of the diversion strategy. In actual business scenarios, the number and attributes of outbound call tasks may fluctuate greatly due to changes in business needs, and the static diversion structure is difficult to respond to such dynamic changes in time. This deficiency may lead to unbalanced resource allocation, especially in multi-regional or multi-task type outbound call environments, further reducing the flexibility and robustness of the system. In addition, this method lacks a detailed description of task priority and scheduling mechanism. In a distributed outbound call system, there are significant differences in the urgency and timeliness of different tasks. For example, urgent customer notification tasks need to be processed first, while routine marketing tasks can be postponed. Without a priority scheduling mechanism, high-priority tasks may be occupied by low-priority tasks, affecting the completion rate of critical tasks and business response speed. The lack of task priority management obviously limits the practical application scope of the system, especially in critical mission scenarios that require real-time response.

[0004] The method also does not provide a clear solution for the processing of timed tasks and failed tasks. In outbound call tasks, task failures due to network interruptions or customer non-answering are common phenomena, but the method does not mention a task retry mechanism, such as adjusting the call time period, switching to other nodes, or dynamically adjusting the task priority to improve the success rate. The lack of an effective processing solution for failed tasks will directly affect the task completion rate and the overall efficiency of the system. In addition, the patent shows obvious deficiencies in outbound call strategy adjustment. Its outbound call strategy matching is only based on a static policy content set and business information, and fails to achieve real-time policy feedback and closed-loop optimization. In actual outbound call systems, key indicators such as call success rate, customer response rate, and feedback sentiment ratio need to be monitored in real time and fed back to the policy engine to optimize the dialing time period, adjust the speech, or change the task allocation strategy. The lack of such dynamic adjustment capabilities may lead to the lag of outbound call strategies and reduce the system's ability to adapt to changes in the business environment. Regarding the introduction of blockchain technology, the patent is mainly used for the storage of outbound call business sets, emphasizing the immutability and security of data. Summary of the invention

[0005] The purpose of the present invention is to provide a distributed outbound call system optimization method based on cloud computing, so as to solve some of the disadvantages and shortcomings pointed out in the background technology.

[0006] The present invention solves the above-mentioned technical problems by adopting the following technical solution, which includes the following steps:

[0007] S1. Distributed outbound call task decomposition and dynamic scheduling mechanism:

[0008] S1.1. Decompose the outbound call task into fine-grained subtasks including dialing, recording, interaction, and recording; generate a unique identifier for each subtask;

[0009] S1.2, based on distributed task scheduler; dynamically allocate tasks according to node real-time performance and network delay, and introduce task priority rules;

[0010] S1.3 monitors the task execution status in real time through a distributed tracking system; recovers and reallocates abnormally failed tasks;

[0011] S2, Distributed outbound call data stream efficient transmission and processing framework:

[0012] S2.1. Slice the outbound call data according to regions or customer groups and distribute them to different nodes;

[0013] S2.2, using stream processing frameworks including Apache Flink to process call records and customer feedback;

[0014] S3, distributed call queue and timeout retry mechanism:

[0015] S3.1. Add call tasks including Kafka to the distributed task queue; set up a dynamic priority queue and adjust the priority according to the timeliness of the task;

[0016] S3.2. Set a timeout threshold for the call task and monitor the task status in real time; when the task times out or fails, trigger a retry strategy including adjusting the call period and switching nodes;

[0017] S3.3. Regularly clean up long-unfinished tasks and distribute the peak task load through the sharding mechanism;

[0018] S4. Distributed call record storage and fast retrieval mechanism:

[0019] S4.1. Use a distributed database including Cassandra to store call records, and store data by time, region, and customer.

[0020] S4.2. Use inverted index and column family-based indexing technology to improve the retrieval efficiency of key fields including customer name and call status, and introduce a dynamic index update mechanism;

[0021] S4.3. Supports multi-dimensional retrieval including by time range and customer classification; provides real-time statistical analysis function.

[0022] Furthermore, the method of the distributed outbound call data stream efficient transmission and processing framework includes:

[0023] Pre-clean the incoming data in real time; based on Apache Flink's DataStream API, use MapFunction and FlatMapFunction to deduplicate, format, and fill in missing values ​​on the data; use the sliding window and jumping window mechanisms to incrementally clean the data in small time slices, evaluate the effects of deduplication and missing value filling operations, and make adjustments using the following formula:

[0024]

[0025] in:

[0026] R(t) represents the cumulative cleaning effect from time 0 to T; C d (x) is the complexity function of the deduplication operation, where x represents the amount of data at the current moment; C ｆ (y) is the accuracy function of the missing value filling operation, y represents the data missing rate at the current moment; w1 and w2 are dynamic weight coefficients used to balance deduplication and missing value filling.

[0027] Furthermore, the method of the distributed outbound call data stream efficient transmission and processing framework includes:

[0028] Based on the Apache Flink stream processing framework, combined with the FlinkML library, stream classification is implemented. The real-time classification task includes labeling the results of each call, performing sentiment analysis and intent recognition on customer feedback data, and judging customer attitudes in real time. Through the joint training of the distributed feature model of each outbound call node, data sharing across nodes is achieved. The formula is as follows:

[0029]

[0030] in:

[0031] M * is the model selected at the current time t; M is the candidate model set, L(M i , D t ) is the model M i In the current input data D t The loss function value on represents the model prediction error; P(M i ) is the model M i The complexity penalty term of ; α and β are balance coefficients, which are used to control the loss function and the complexity penalty term respectively.

[0032] Furthermore, the method of the distributed outbound call data stream efficient transmission and processing framework includes:

[0033] Based on Apache Flink's window operation, key indicators in the outbound call process, including call success rate, customer response rate, and feedback sentiment ratio, are counted and fed back to the outbound call strategy engine to adjust the outbound call strategy, including changing the call time period, optimizing the call script, or adjusting the call priority, forming a strategy feedback loop. The following formula is used for evaluation:

[0034]

[0035] in:

[0036] S opt is the current time window Δ t The outbound call strategy selected from the internal; S is the candidate strategy set, E(S i , Δ t ) is strategy S i In the time window Δ t The effect improvement function inside, C(S i ) is strategy S i , γ and δ are balance coefficients, which are used to measure the strategy effect and cost respectively.

[0037] Furthermore, the method of the distributed call queue and timeout retry mechanism includes:

[0038] Distributed message middleware is introduced to realize the transmission and scheduling of outbound call tasks among multiple nodes through distributed message queues including Kafka, RabbitMQ, and RedisStreams; sharding is performed according to business attributes, and the task distribution strategy is dynamically adjusted based on the node load; the load balancing coefficient is calculated by the following function:

[0039]

[0040] in:

[0041] B(N i ) is node N i The load balancing factor, L cpu (t) is the node N i The CPU load at time t represents the CPU resources; L mem (t) is the node N i The memory load at time t indicates the memory usage; L net (t) is the node N i The network load at time t represents the usage of network bandwidth; T is the load monitoring time window, which represents the overall evaluation of node load within the time range [0, T].

[0042] Furthermore, the method of the distributed call queue and timeout retry mechanism includes:

[0043] When a task is added to the queue, its initial priority is calculated based on the task's urgency, timeliness, and business dynamic weight. The calculation formula for the initial priority P0 is as follows:

[0044]

[0045] in:

[0046] P0 is the initial priority of the task, U is the urgency of the task, T is the remaining time of the task; W b is the business dynamic weight of the task, α and β are weight coefficients, which respectively control the influence of urgency and timeliness on priority.

[0047] Furthermore, the method of the distributed call queue and timeout retry mechanism includes:

[0048] A global task coordinator is introduced to monitor the task queue length and load of all outbound call nodes. When the task load is too high, the coordinator triggers the task migration mechanism to transfer tasks to idle nodes. When a high-priority task is generated, the coordinator interrupts the low-priority task being processed and gives priority to the high-priority task.

[0049] The triggering of task preemption is based on the preemption weight Wpreempt The preemption weight is calculated by the following formula:

[0050] W preempt =γ·(P high P low )δ·C interrupt

[0051] in:

[0052] W preempt is the preemption weight, which is used to measure the benefit of high-priority tasks preempting low-priority tasks; when W preempt >0 triggers the preemption operation; P high and P low To represent the current priorities of high priority tasks and low priority tasks respectively; C interrupt is the task interruption cost, γ and δ are balance coefficients, which respectively control the impact of priority difference and interruption cost on preemption weight.

[0053] The distributed outbound call system optimization method based on cloud computing of the present invention significantly improves the performance and flexibility of the outbound call system by introducing distributed architecture, dynamic scheduling mechanism and intelligent analysis technology, and has the following beneficial effects:

[0054] The real-time preprocessing, classification and sentiment analysis of call tasks are realized through the streaming data processing framework based on Apache Flink, which effectively reduces the delay, ensures the rapid response of key tasks, and improves the real-time performance of the system. The task priority is dynamically calculated based on the task urgency, timeliness and business dynamic weight, so that high-priority tasks can be processed first, optimizing the efficiency and accuracy of task scheduling.

[0055] The global task coordinator monitors the node load in real time, and dynamically allocates tasks to appropriate nodes in combination with load balancing coefficient calculation, avoiding node overload or resource idleness and improving the utilization efficiency of system resources. For timeout or failed tasks, the system has designed a variety of intelligent retry strategies, including adjusting call time periods, switching nodes, and reallocating tasks, which significantly improves the success rate of tasks and the stability of the system.

[0056] By collecting real-time statistics on key indicators such as call success rate, customer response rate and feedback sentiment ratio, and feeding the analysis results into the strategy engine, the outbound call strategy is dynamically optimized (such as adjusting the dialing time period, optimizing the wording and adjusting the priority), thus achieving adaptive optimization of the outbound call system. BRIEF DESCRIPTION OF THE DRAWINGS

[0057] Figure 1 This is a flow chart of the distributed outbound call system optimization method based on cloud computing of the present invention.

[0058] Figure 2 The present invention is a method flow chart of the distributed outbound call data stream efficient transmission and processing framework.

[0059] Figure 3 The present invention is a method flow chart of the distributed call queue and timeout retry mechanism. DETAILED DESCRIPTION

[0060] The specific implementation modes of the present invention will be described in detail below in conjunction with the accompanying drawings.

[0061] Combined with Figure 1 As shown in the flow chart, the distributed outbound call system optimization method based on cloud computing includes the following steps: S1. The distributed outbound call task decomposition and dynamic scheduling mechanism aims to improve the parallel processing capability of the system and the flexibility of task scheduling by fine-grained processing of outbound call tasks. In the outbound call process, each task usually includes multiple steps such as dialing, recording, interaction and recording. Therefore, this method first decomposes the entire outbound call task into independent fine-grained subtasks, such as dialing subtasks, recording subtasks, interaction subtasks and recording subtasks. Each subtask is assigned a unique identifier when it is generated for subsequent task tracking and scheduling. In order to ensure efficient execution of tasks, the system uses a distributed task scheduler to dynamically schedule the decomposed subtasks. When scheduling tasks, the system will comprehensively consider the real-time performance indicators of each node (such as CPU usage, memory usage) and network delay, and select the optimal node to assign tasks. In order to further improve the priority management capability of task processing, the system introduces task priority rules to dynamically adjust the processing order of tasks according to the urgency and timeliness of tasks to ensure that high-priority tasks can be processed first. During the task execution process, in order to achieve real-time monitoring of the task status, this method introduces a distributed tracking system, which can track the execution status of each subtask throughout the process and record the start time, execution progress, completion status and other information of each subtask. When the system detects that a subtask is abnormal or fails, it will trigger the exception handling mechanism, automatically recycle the task and reallocate it to other suitable nodes for execution, ensuring that the task can be completed in the shortest time, improving the reliability of the task and the overall stability of the outbound call system.

[0062] S2. The distributed outbound call data stream efficient transmission and processing framework aims to solve the problems of transmission delay and low processing efficiency caused by large data volume and scattered nodes in distributed outbound call systems. In order to improve the efficiency of data transmission and processing, this method first shards the outbound call data and logically divides the data according to region or customer group. Each shard contains outbound call tasks for a specific region or a specific type of customer. In this way, different outbound call nodes can process their respective data slices, thereby effectively reducing cross-node data interaction, reducing network transmission delays, and improving the locality of processing to a certain extent. The sharded data is assigned to the appropriate node. The basis for node selection includes the node's geographical location, current load conditions, and network delay with the target customer to ensure that the task can be processed on the optimal node.

[0063] In terms of real-time processing of outbound call data streams, this method uses stream processing frameworks including Apache Flink to process call records and customer feedback data in real time through streaming computing. Specifically, when the call task is completed, the system will write call results, call recordings and other information as data streams into the stream processing framework, and pre-process these data as soon as possible, such as data cleaning, formatting, deduplication, etc. After that, the system will perform further real-time analysis on the cleaned data, including sentiment analysis, intent recognition, and outbound call effect statistics on customer feedback. By using the stream processing framework, the system can perform real-time analysis and processing of outbound call data within millisecond delays, thereby generating outbound call results in a timely manner and providing data support for subsequent strategy adjustments.

[0064] S3, distributed call queue and timeout retry mechanism are designed to improve the task scheduling efficiency and failure recovery capability of the outbound call system in a high concurrency environment. To this end, this method introduces all outbound call tasks into a distributed task queue, and uses distributed message middleware including Kafka to manage tasks to ensure that tasks can be efficiently transmitted and scheduled between multiple nodes. In the task queue, the system sets up a dynamic priority queue. Each task is assigned an initial priority when it joins the queue. The priority is dynamically calculated based on the urgency and timeliness of the task. During the task waiting process, the system monitors the status of the task in real time, and dynamically adjusts its priority based on the waiting time and timeliness of the task, ensuring that high-priority tasks can be processed first, while preventing ordinary tasks from being processed in time due to long waiting.

[0065] For each call task, the system sets a timeout threshold and monitors its status in real time during the task execution process. When the task times out or fails to execute, the system will immediately trigger a retry strategy, including adjusting the call period, switching to other nodes with lower loads to re-execute the task, etc., to improve the success rate of the task and reduce task failures caused by node failures or network problems. In addition, in order to prevent the system performance from degrading due to task accumulation in the task queue, the system has designed a regular cleanup mechanism, which will clean up or reallocate tasks that have not been completed for a long time to ensure that efficient and executable tasks are always retained in the queue. In order to further alleviate the task processing pressure during peak hours, this method introduces a task sharding mechanism, which divides a large number of tasks during peak hours by business type or region and distributes them to different nodes for processing, thereby effectively balancing the node load and improving the system's stability and task processing efficiency in a high-concurrency environment.

[0066] S4. Distributed call record storage and fast retrieval mechanism aims to solve the problem of efficient storage and fast retrieval of a large number of call records in the outbound call system, ensuring that the system can still provide low-latency and high-concurrency query capabilities when facing massive data. This method uses distributed databases including Cassandra to store and manage call records, and improves the scalability and fault tolerance of data storage through a distributed architecture. In order to facilitate retrieval and analysis, the system classifies and stores data according to time, region and customer dimensions when storing call records. This classified storage method not only improves retrieval efficiency, but also provides structured support for subsequent multi-dimensional analysis. In terms of data retrieval, in order to speed up the query process of key fields, this method introduces inverted indexes and column family-based indexing technology to establish efficient indexes for commonly used query fields including customer name and call status, so that queries for these fields can maintain low-latency responses on large-scale data sets. In addition, in order to adapt to changing business needs, the system designs a dynamic index update mechanism. When new data fields are frequently queried, the system automatically indexes these fields, thereby improving retrieval performance and reducing query time.

[0067] Embodiment 1:

[0068] Combined with Figure 2 The distributed outbound call system of a large e-commerce platform needs to make millions of calls every day, mainly involving tasks such as customer order confirmation, after-sales return visits, and marketing promotion. These outbound call tasks have different priorities and urgency levels. At the same time, due to the wide distribution of customer groups, they involve multiple regions across the country. In order to ensure that the system can run stably in a high-concurrency environment and monitor and optimize the processing of call tasks in real time, the platform introduced a distributed outbound call data stream efficient transmission and processing framework based on Apache Flink, aiming to improve the data processing efficiency of the outbound call system through real-time pre-cleaning and dynamic adjustment mechanisms.

[0069] After the daily call tasks flow into the outbound call system, the first step is to pre-clean the data. In this process, the system receives call task data streams from different business departments in real time. These data may contain duplicate task records and missing key information (such as customer contact information or order number). To this end, the system uses MapFunction and FlatMapFunction based on ApacheFlink's DataStreamAPI to process the incoming data, where MapFunction is used for formatting and deduplication, and FlatMapFunction is used to detect and fill in missing fields.

[0070] Actual data: In a certain time window, the system received 10,000 call task records, of which 8%

[0071] There are duplicate records and 5% of the records have missing fields. To evaluate the pre-cleaning effect, the system uses the following formula for calculation:

[0072]

[0073] in:

[0074] C d (x) = k1·ln(1+x), k1 is the complexity coefficient of the deduplication operation, and its value range is [0.1,1.0]. Set the current k1 = 0.5;

[0075] C f (y) = k2·(1e -y ), k2 is the accuracy coefficient of the missing value filling operation, and its value range is [0.5, 2.0]. Set the current k2 = 1.2;

[0076] w1 and w2 are dynamic weight coefficients, and their value range is [0.1, 1.0]. Currently, w1 is set to 0.7 and w2 is set to 0.6.

[0077] T = 10 minutes (sliding window period).

[0078] First calculate the effect of each operation:

[0079] The current amount of data x = 10,000 × 8% = 800;

[0080] The data missing rate at the current moment is y=5%=0.05.

[0081] The complexity of the deduplication operation is:

[0082] C d (x)=0.5·ln(1+800)≈0.5·6.685=3.342

[0083] The accuracy of the missing value filling operation is:

[0084] C f (y) = 1.2·(1e -0.05 )≈1.2·0.0488=0.0586

[0085] Substituting the above results into the cumulative cleaning effect formula, we get:

[0086]

[0087] The cumulative cleaning effect R(t) = 23.7456 means that within the 10-minute sliding window, the system's comprehensive evaluation of the effect of deduplication and missing value filling operations is 23.7456. Based on this result, the system can dynamically adjust the weights of w1 and w2 to focus more on deduplication or missing value filling operations in the next time window.

[0088] In order to further improve data processing efficiency, the system uses sliding window and jumping window mechanisms so that the data in each time window can be processed incrementally. The current sliding window size is set to 10 minutes and the jumping window size is set to 5 minutes, which means that the system will start a new window every 5 minutes, while retaining the data processing status of the previous window to ensure continuous data processing effects.

[0089] For example, the current system completed pre-cleaning of 10,000 data in the first 10-minute window, retained 9,200 valid records after deduplication, and filled 90% of the missing fields. In the next 5-minute jump window, the system received 4,000 new data and performed incremental processing on these new data, bringing the total data volume to 13,200. By retaining the processing results of the previous window, the system reduces repeated calculations and further improves data processing efficiency.

[0090] Through the above pre-cleaning operation and real-time effect evaluation, the system will dynamically adjust the weights of w1 and w2 according to the value of R(t) at the end of each time window. If the data repetition rate in the current window is high, the system will increase the weight of w1 and reduce the weight of w2, giving priority to deduplication operations; otherwise, it will give priority to missing value filling operations. In addition, the system will feed back the processing results to the outbound call strategy engine for real-time adjustment of outbound call strategies, such as optimizing dialing time periods or reallocating outbound call tasks.

[0091] Since the results of outbound call tasks and customer feedback directly affect subsequent marketing strategies and customer relationship maintenance, it is necessary to label the results of each call (such as "successful call", "rejected call", "voice message", etc.), and perform sentiment analysis and intent recognition on customer feedback data to judge customer attitudes in real time (such as "positive", "neutral", "negative"). In order to improve the accuracy and efficiency of classification and analysis, the platform adopts a streaming classification method based on the Apache Flink stream processing framework and the FlinkML library, and combines the distributed characteristics of each outbound call node for model joint training to achieve cross-node data sharing and model optimization.

[0092] After each call, the system will receive the outbound call result data stream in real time. Each record in the data stream contains information such as call time, customer number, call duration, call status, etc. Based on this information, the system needs to label each call. For example, within a certain time window, the system receives 5,000 call records, of which the call status distribution is as follows: "Successful call" accounts for 60%, "Rejected call" accounts for 30%, and "Voice message" accounts for 10%. The system labels these records through the pre-trained classification model in FlinkML to generate a label for each record.

[0093] Assume that there are currently two candidate models M1 and M2 for selection, and the system needs to select the current optimal model M based on real-time data. * The model selection is based on minimizing the following objective function:

[0094]

[0095] in:

[0096] M*: the optimal model selected at the current time t;

[0097] M: candidate model set, including M1 and M2;

[0098] L(M i , D t ): Model M i In the current input data D t The loss function value on , which represents the prediction error of the model on 5,000 records;

[0099] P(M i ): Model M i The complexity penalty term represents the computational complexity of the model;

[0100] α and β: balance coefficients, which control the weights of the loss function and complexity penalty respectively, and the value range is [0.1, 1.0].

[0101] Actual data: Set L(M1, D t )=0.05,L(M2,D t )=0.04,P(M1)=0.8,P(M2)=0.5,and the current balance coefficients are α=0.7,β=0.3. Substitute these values ​​into the objective function:

[0102] For Model M1:

[0103] Target value (M1) = 0.7 0.05 + 0.3 0.8 = 0.035 + 0.24 = 0.275

[0104] For Model M2:

[0105] Target value (M2) = 0.7 0.04 + 0 . 3 0.5 = 0.028 + 0.15 = 0.178

[0106] Since the target value (M2) < the target value (M1), the system selects M * =M2 is the optimal model at the current time.

[0107] For customer feedback data, the system will perform sentiment analysis and intent recognition on each piece of feedback information. For example, after answering the phone, a customer gave the following feedback: "I am not interested in this event, please do not contact me again." The system detects that the feedback is "negative" through the sentiment analysis model in FlinkML, and determines that the customer's main intention is "refuse to receive more similar calls" through the intent recognition model. The system stores this information as a customer feedback record and simultaneously updates the outbound call strategy engine to ensure that subsequent outbound call tasks reduce harassment to the customer.

[0108] In order to continuously optimize the performance of the model, the platform adopts a distributed model joint training mechanism, which realizes cross-node data sharing and model incremental training through the distributed characteristics of each outbound call node. On each node, the system will use local real-time data to conduct online learning of the current model, and regularly send incremental update results to the global model coordinator. The coordinator will merge and optimize the incremental models of each node, generate a new global model, and distribute it to each node to ensure that the models used by all nodes are always up to date.

[0109] Since the effectiveness of outbound call tasks directly affects customer satisfaction and the platform's business conversion rate, the system needs to conduct real-time statistics and analysis of key indicators in the outbound call process, including call success rate, customer response rate, and feedback sentiment ratio, and adjust the outbound call strategy based on these indicators, such as changing the call time period, optimizing the call script, or adjusting the call priority, to form a strategy feedback loop, thereby improving the overall effectiveness of outbound calls and resource utilization efficiency.

[0110] Set in a 10 minute time window Δ t = Within 10 minutes, the system completed 6,000 outbound call tasks. The execution results of these tasks are as follows:

[0111] Number of successful calls: 3,600, with a success rate of

[0112] Number of customer responses (i.e. customers who gave clear feedback after successfully answering the call): 2,400 calls, with a response rate of

[0113] Among customer feedback, there are 1,200 positive responses, 600 neutral responses, and 600 negative responses. Therefore, the percentage of positive feedback is

[0114] After the system summarizes these statistical indicators, it will feed the results back to the outbound call strategy engine, which will decide whether the outbound call strategy needs to be adjusted, including whether the call time period needs to be changed, the words need to be optimized, or the call priority needs to be adjusted. In order to make the best strategy adjustment decision, the system will evaluate the candidate strategy set S in each time window and select the current optimal strategy using the following formula:

[0115]

[0116] in:

[0117] S opt : The optimal strategy selected in the current time window;

[0118] S: candidate strategy set, which includes three candidate strategies: changing the call time period S1, optimizing the speech technique S2, and adjusting the call priority S3;

[0119] E(S i , Δ t ): Strategy S i In the time window Δ t The effect improvement function in represents the comprehensive improvement effect of the strategy on call success rate, customer response rate and feedback sentiment ratio;

[0120] C(S i ): Strategy S i The implementation cost function represents the resource consumption or additional cost that may be caused by implementing the strategy;

[0121] γ and δ: balance coefficients, used to measure the effect and cost of the strategy, respectively, with a value range of [0.11.0]. The current setting is γ=0.8, δ=0.5.

[0122] 1. Strategy S1: Change the calling period:

[0123] After the call time period is changed, the call success rate is expected to increase by 10%, the customer response rate will increase by 5%, and the proportion of positive feedback will increase by 8% in the next time window. The comprehensive effect improvement function is E(S1, Δ t )=0.1+0.05+0.08=0.23.

[0124] The implementation cost is mainly to reschedule the dialing time, which may lead to certain resource consumption. The cost function is C(S1)=0.1.

[0125] 2. Strategy S2: Optimize the words:

[0126] It is assumed that by optimizing the speech, the customer's response willingness and the proportion of positive emotions can be significantly improved. It is expected that the call success rate will increase by 5%, the customer response rate will increase by 15%, and the proportion of positive feedback emotions will increase by 12%. The comprehensive effect improvement function is E(S2, Δ t )=0.05+0.15+0.12=0.32.

[0127] The implementation cost mainly includes the redesign of the speech and training, and the cost function is C(S2)=0.15.

[0128] 3. Strategy S3: Adjust call priority:

[0129] After setting and adjusting the call priority, the call success rate of high-priority customers increased significantly. It is expected that the call success rate will increase by 15%, the customer response rate will increase by 10%, and the positive feedback sentiment will increase by 5%. The comprehensive effect improvement function is E(S3, Δ t )=0.15+0.10+0.05=0.30.

[0130] The implementation cost is mainly the priority adjustment and scheduling overhead of the system, and the cost function is C(S3)=0.12.

[0131] According to the given formula Calculate the score for each strategy:

[0132] Score of strategy S1:

[0133] γ·E(S1,Δ t )δ·C(S1)=0.8·0.230.5·0.1=0.1840.05=0.134

[0134] Score of strategy S2:

[0135] γ·E(S2,Δ t )δ·C(S2)=0.8·0.320.5·0.15=0.2560.075=0.181

[0136] Score for strategy S3:

[0137] γ·E(S3,Δ t )δ·C(S3)=0.8·0.300.5·0.12=0.240.06=0.18

[0138] Through calculation, we can see that strategy S2 (optimized speech) has the highest score of 0.181, so the system selects strategy S2 as the optimal strategy S in the current time window. opt The system will optimize the speech as the adjustment direction of the next outbound call strategy, generate new speech templates and push them to each outbound call node, and arrange operators to train the outbound call team to ensure that the new speech can be effectively implemented within the next time window.

[0139] Embodiment 2:

[0140] Combined with Figure 3 As shown in the figure, the distributed outbound call system of a large e-commerce platform needs to ensure efficient distribution of tasks among multiple nodes while processing millions of calls every day, avoiding overload of a single node or task accumulation, and effectively retrying and optimizing resources for timed tasks. To this end, the platform introduces a distributed call queue and timeout retry mechanism, and achieves efficient task delivery and scheduling through distributed message middleware including Kafka, RabbitMQ and RedisStreams. Task distribution is sharded based on business attributes (such as region, customer type), and the task allocation strategy is dynamically adjusted by calculating the load balancing coefficient of the node.

[0141] The platform adds all outbound call tasks to the distributed message queue. Each task is encapsulated as a message, which contains basic information such as task ID, customer number, priority, timeliness, etc. Assume that 10,000 outbound call task data are currently received. These tasks are divided into three shards according to regional attributes: 4,000 in East China, 3,000 in South China, and 3,000 in North China. After the tasks are sharded, they are distributed to three outbound call nodes N1, N2, and N3 through the distributed message middleware.

[0142] In order to avoid the problem of uneven node load during task distribution, the system will calculate the load balancing coefficient B (N) of each node in real time. i ), the calculation formula is as follows:

[0143]

[0144] B(N i ): Node N i The load balancing coefficient, the larger the value, the lighter the node load, and the more suitable it is for receiving more tasks;

[0145] L cpu (t): Node N i The CPU load at time t indicates the CPU usage rate, with a value range of [0, 1];

[0146] L mem (t): Node N i The memory load at time t represents the memory occupancy rate, with a value range of [0, 1];

[0147] L net (t): Node N i The network load at time t represents the network bandwidth utilization rate, with a value range of [0, 1];

[0148] T: Load monitoring time window, which represents the overall evaluation period of the node load and is set to 10 minutes.

[0149] Actual data: Assume that in the past 10-minute time window, the node load monitored by the system is as follows:

[0150] Node N1: L cpu (t) = 0.7, L mem (t) = 0.6, L net (t) = 0.5;

[0151] Node N2: L cpu (t) = 0.5, L mem (t) = 0.4, L net (t) = 0.6;

[0152] Node N3: L cpu (t) = 0.4, L mem (t) = 0.3, L net (t) = 0.4.

[0153] Substitute the above data into the formula to calculate the load balancing coefficient of each node:

[0154] For N1:

[0155]

[0156] For N2:

[0157]

[0158] For N3:

[0159]

[0160] The calculation results show that node N3 has the lightest load and the load balancing coefficient B(N3) = 0.0909 is the largest, so the system allocates more tasks to N3, and the specific allocation ratio is N1:N2:N3 = 3:4:5. This means that after the task allocation, N1 processes 2,500 tasks, N2 processes 3,000 tasks, and N3 processes 4,500 tasks.

[0161] During task execution, the system sets a timeout threshold for each call task. Assume that the timeout threshold for each task is 30 seconds. Tasks that are not completed after this time will be marked as timeout tasks and trigger a retry mechanism. Assume that on node N1, there are 100 tasks out of 2,500 that time out, 60 of which are caused by the customer's phone not being able to be connected and 40 due to a sudden increase in node load. After the retry mechanism is triggered, the system takes the following measures:

[0162] 1. For timeout tasks caused by node load, the system transfers these tasks to the node N3 with lighter load for re-execution;

[0163] 2. For overtime tasks caused by customer phone problems, the system adjusts the call time period, such as rescheduling the call during non-peak hours.

[0164] After the task is completed, the system will dynamically optimize the task distribution strategy according to the changes in the load balancing coefficient and the task success rate. For example, under the current strategy, the task completion rate of node N3 is 98%, which is significantly higher than that of nodes N1 and N2. Therefore, the system will further tilt resources to N3 in subsequent task distribution. In addition, the system will feed back the results of the retry task to the policy engine to optimize the task allocation rules and timeout handling strategy.

[0165] In the distributed outbound call system of this large e-commerce platform, millions of outbound call tasks need to be processed every day, and the urgency and timeliness of the tasks vary significantly. For example, some tasks are used to promptly notify customers of important changes in orders, which are highly urgent and time-sensitive; while other tasks are routine marketing and promotion tasks that can be completed within a more relaxed time window. In order to ensure that high-priority tasks are processed first, the system will calculate the initial priority of each task based on the urgency, remaining timeliness, and business dynamic weight when adding tasks to the queue, and use this as the basis for task scheduling.

[0166] The initial priority P0 of each task is calculated by the following formula:

[0167]

[0168] in:

[0169] P0: The initial priority of the task. The larger the value, the higher the urgency of the task.

[0170] U: The urgency of the task, ranging from 1 to 10. Urgent tasks have higher U values.

[0171] T: The remaining time of the task (unit: minutes). The smaller the value, the closer the task is to the time limit.

[0172] W b : The business dynamic weight of the task, which is used to indicate the adjustment value of the task importance as the business changes, and the value range is [0.1,5.0];

[0173] α and β: respectively control the impact of urgency and timeliness on priority, with a value range of [0.1, 1.0]. Assume that currently α=0.6, β=0.4.

[0174] Assume that the current system receives three types of tasks:

[0175] 1. Task A: Customer order notification, urgency U = 9, remaining timeliness T = 30 minutes, business dynamic weight W b =2.0.

[0176] 2. Task B: Conventional marketing promotion, urgency U = 3, remaining timeliness T = 240 minutes, business dynamic weight W b =0.5.

[0177] 3. Task C: Customer satisfaction survey, urgency U = 5, remaining timeliness T = 120 minutes, business dynamic weight W b =1.0.

[0178] Substitute the data into the formula to calculate the priority of each task separately:

[0179] 1. Initial priority calculation of task A:

[0180]

[0181] The calculation results are:

[0182]

[0183] 2. Initial priority calculation of task B:

[0184]

[0185] The calculation results are:

[0186]

[0187] 3. Initial priority calculation of task C:

[0188]

[0189] The calculation results are:

[0190]

[0191] According to the calculated initial priority, the priority order of the tasks is Therefore, the task scheduling order is:

[0192] 1. Prioritize Task A (customer order notification);

[0193] 2. Next, handle Task C (customer satisfaction survey);

[0194] 3. Finally, handle Task B (regular marketing promotion).

[0195] After a task enters the queue, the system will dynamically adjust the priority based on the waiting time of the task. Assume that task A is still not completed after 10 minutes, and its remaining timeliness becomes T = 20 minutes, the dynamic weight W b Due to the increase in customer unanswered calls to W b =3.0. Recalculate the priority of task A:

[0196]

[0197] The priority is increased to 5.9744, and Task A is again prioritized by the system and transferred to a node with less load to ensure fast execution.

[0198] Based on the aforementioned distributed call queue and dynamic priority mechanism, the platform further introduces a global task coordinator to improve the intelligence level of task scheduling. The responsibilities of the global task coordinator include monitoring the task queue length and load of all outbound call nodes, triggering the task migration mechanism when the node load is too high, and giving priority to critical tasks through the preemption mechanism when high-priority tasks are generated, thereby maximizing the system's task processing efficiency and resource utilization.

[0199] Assume that the system currently has three outbound call nodes N1, N2, and N3, where the task queue length of node N1 is 3,000, the task queue length of node N2 is 2,000, and the task queue length of node N3 is 800. The global task coordinator monitors the load of each node in real time and determines that the task queue length of node N1 is too high, which may cause delays or task backlogs. Therefore, the task migration mechanism is triggered to transfer some tasks of node N1 to node N3 with lower load. Assuming that the number of migrated tasks is 1,200, after task migration, the node task distribution is N1 = 1,800, N2 = 2,000, and N3 = 2,000. This move significantly balances the node load and avoids the performance bottleneck of high-load nodes.

[0200] During task execution, suppose the system receives an urgent high-priority task T high , whose priority is p high =7.5, at this time node N2 is processing a low priority task T low , whose priority is P low =3.0. The global task coordinator calculates the preemption weight W according to the following formula preempt To decide whether to trigger preemption:

[0201] W preempt =γ·(P high P low )δ·C interrupt

[0202] in:

[0203] W preempt : Preemption weight, which is used to measure the benefit of high-priority tasks preempting low-priority tasks. The larger the value, the more favorable the preemption;

[0204] P high and P low : Respectively represent the current priorities of high-priority tasks and low-priority tasks;

[0205] C interrupt : Task interruption cost, which indicates the resource waste or system overhead caused by interrupting low-priority tasks. The value range is [0.1,5.0]. Assuming that the current C interrupt =2.0;

[0206] γ and δ: control the impact of priority difference and interruption cost respectively, with a value range of [0.1, 1.0]. Assume that currently γ=0.8 and δ=0.5.

[0207] Substitute the data into the formula to calculate the preemption weight:

[0208] W preempt =0.8·(7.53.0)0.5·2.0

[0209] W preempt =0.8·4.51.0=3.61.0=2.6

[0210] Since W preempt =2.6>0, the global task coordinator determines that the benefit of the preemption operation is greater than the interruption cost, so the preemption mechanism is triggered and the low-priority task T on node N2 is immediately interrupted. low , and give priority to high priority tasks T high To node N2 for execution. The interrupted low priority task T low It will be re-added to the distributed task queue and re-ordered according to its priority to wait for scheduling.

[0211] After preemption is completed, the system will dynamically adjust the priority of the task according to its actual completion time and status. low After being rescheduled, its priority may increase slightly due to the increase in waiting time to prevent it from being stranded in the queue for a long time without being processed. The global task coordinator also feeds back the relevant data of task preemption (such as the number of preempted tasks, priority difference, and preemption benefit) to the policy engine for subsequent optimization of preemption rules.

[0212] In actual operation, the global task coordinator not only triggers task migration when a node is overloaded, but also combines the preemption mechanism to further optimize resource allocation. For example, when the load on node N3 is light and there is no high-priority task, the system can directly transfer the high-priority task T high Assign it to node N3 without interrupting low-priority tasks of other nodes, thereby reducing the interruption cost C interrupt And improve the overall system efficiency.

[0213] From the above examples, we can see that the distributed call queue and timeout retry mechanism based on the global task coordinator can effectively solve the problems of uneven node load and task scheduling delay. At the same time, the preemption mechanism gives priority to high-priority tasks to ensure the optimal use of system resources. The actual calculation results show that by reasonably setting the balance coefficients γ and δ, and flexibly using the task migration and preemption mechanism, the system can dynamically adjust the task allocation strategy in different business scenarios, thereby significantly improving the overall performance and service quality of the outbound call system. This mechanism has wide applicability and practical value in high-concurrency distributed outbound call systems.

Claims

1. A distributed outbound call system optimization method based on cloud computing, characterized in that The following steps are involved: S1. Distributed outbound call task decomposition and dynamic scheduling mechanism: S1.

1. Decompose the outbound call task into fine-grained subtasks including dialing, recording, interaction, and recording; generate a unique identifier for each subtask; S1.2, based on distributed task scheduler; dynamically allocate tasks according to node real-time performance and network delay, and introduce task priority rules; S1.3 monitors the task execution status in real time through a distributed tracking system; recovers and reallocates abnormally failed tasks; S2, Distributed outbound call data stream efficient transmission and processing framework: S2.

1. Slice the outbound call data according to regions or customer groups and distribute them to different nodes; S2.2, using stream processing frameworks including Apache Flink to process call records and customer feedback; S3, distributed call queue and timeout retry mechanism: S3.

1. Add call tasks including Kafka to the distributed task queue; set up a dynamic priority queue and adjust the priority according to the timeliness of the task; S3.

2. Set a timeout threshold for the call task and monitor the task status in real time; when the task times out or fails, trigger a retry strategy including adjusting the call period and switching nodes; S3.

3. Regularly clean up long-unfinished tasks and distribute the peak task load through the sharding mechanism; S4. Distributed call record storage and fast retrieval mechanism: S4.

1. Use a distributed database including Cassandra to store call records, and store data by time, region, and customer. S4.

2. Use inverted index and column family-based indexing technology to improve the retrieval efficiency of key fields including customer name and call status, and introduce a dynamic index update mechanism; S4.

3. Supports multi-dimensional retrieval including by time range and customer classification; provides real-time statistical analysis function.

2. According to the method for optimizing a distributed outbound call system based on cloud computing of claim 1, it is characterized in that The method of the distributed outbound call data stream efficient transmission and processing framework includes: Pre-clean the incoming data in real time; based on Apache Flink's DataStream API, use MapFunction and FlatMapFunction to deduplicate, format, and fill in missing values ​​on the data; use the sliding window and jumping window mechanisms to incrementally clean the data in small time slices, evaluate the effects of deduplication and missing value filling operations, and make adjustments using the following formula: in: R(t) represents the cumulative cleaning effect from time 0 to T; C d (x) is the complexity function of the deduplication operation, where x represents the amount of data at the current moment; C f (y) is the accuracy function of the missing value filling operation, y represents the data missing rate at the current moment; w1 and w2 are dynamic weight coefficients used to balance deduplication and missing value filling.

3. The distributed outbound call system optimization method based on cloud computing according to claim 2 is characterized in that The method of the distributed outbound call data stream efficient transmission and processing framework includes: Based on the Apache Flink stream processing framework and combined with the FlinkML library, streaming classification is implemented. The real-time classification tasks include labeling the results of each call, performing sentiment analysis and intent recognition on customer feedback data, and judging customer attitudes in real time; through the joint training of the distributed feature models of each outbound call node, data sharing across nodes is enabled.

4. The distributed outbound call system optimization method based on cloud computing according to claim 3 is characterized in that The method of the distributed outbound call data stream efficient transmission and processing framework includes: Based on Apache Flink's window operation, key indicators in the outbound call process, including call success rate, customer response rate, and feedback sentiment ratio, are counted and fed back to the outbound call strategy engine to adjust the outbound call strategy, including changing the call time period, optimizing the call script, or adjusting the call priority, forming a strategy feedback loop. The following formula is used for evaluation: in: S opt is the current time window Δ t The outbound call strategy selected from the internal; S is the candidate strategy set, E(S i ,Δ t ) is strategy S i In the time window Δ t The effect improvement function inside, C(S i ) is strategy S i , γ and δ are balance coefficients, which are used to measure the strategy effect and cost respectively.

5. The distributed outbound call system optimization method based on cloud computing according to claim 1 is characterized in that The method of the distributed call queue and timeout retry mechanism includes: Distributed message middleware is introduced to realize the transmission and scheduling of outbound call tasks among multiple nodes through distributed message queues including Kafka, RabbitMQ, and RedisStreams; sharding is performed according to business attributes, and the task distribution strategy is dynamically adjusted based on the node load.

6. The distributed outbound call system optimization method based on cloud computing according to claim 5 is characterized in that The method of the distributed call queue and timeout retry mechanism includes: When a task is added to the queue, the initial priority is calculated based on the task urgency, timeliness and business dynamic weight. The calculation formula for the initial priority P0 is as follows: in: P0 is the initial priority of the task, U is the urgency of the task, T is the remaining time of the task; W b is the business dynamic weight of the task, α and β are weight coefficients, which respectively control the influence of urgency and timeliness on priority.

7. The distributed outbound call system optimization method based on cloud computing according to claim 6 is characterized in that The method of the distributed call queue and timeout retry mechanism includes: A global task coordinator is introduced to monitor the task queue length and load of all outbound call nodes. When the task load is too high, the coordinator triggers the task migration mechanism to transfer tasks to idle nodes. When a high-priority task is generated, the coordinator interrupts the low-priority task being processed and gives priority to the high-priority task. The triggering of task preemption is based on the preemption weight W preempt The preemption weight is calculated by the following formula: W preempt =γ·(P high P low )δ·C interrupt in: W preempt is the preemption weight, which is used to measure the benefit of high-priority tasks preempting low-priority tasks; when W preempt >0 triggers the preemption operation; P high and P low To represent the current priorities of high priority tasks and low priority tasks respectively; C interrupt is the task interruption cost, γ and δ are balance coefficients, which respectively control the impact of priority difference and interruption cost on preemption weight.

Images