Dynamic concurrency control and resource optimization method of smart phone outbound system

Abstract

The invention discloses a dynamic concurrency control and resource optimization method of a smart phone outbound system. According to the method, the calling resources are dynamically allocated through the multi-dimensional weight model, and line loads and risk management and control are effectively balanced on the premise of ensuring compliance requirements of operators. Real-time state monitoring of the calling number is combined with an intelligent cooling strategy, so that a risk control mechanism is prevented from being triggered by overuse of a single line, and high-efficiency access of high-value customers is ensured through priority scheduling. The concurrency scale and the calling rhythm are accurately controlled through double constraints of the double-token mechanism, the instant flow is prevented from impacting the bearing limit of the system, it is ensured that the outbound call rate is always within the safety threshold value of an operator, and therefore the call failure rate and resource waste are greatly reduced. A parameter optimization mechanism based on dynamic feedback can automatically adjust a resource allocation strategy according to historical data and operation environment changes, for example, rate limitation is temporarily relaxed and remainder smooth scheduling is started in a burst traffic scene, so that smooth transition of a service peak value is realized.

Description

Technical Field

[0001] The present invention belongs to the technical field of telephone outbound systems, and specifically relates to a method for dynamic concurrent control and resource optimization of an intelligent telephone outbound system. Background Art

[0002] With the continuous development of communication technologies, telephone outbound systems have become important tools for enterprises to carry out customer service, market promotion and other operations. When an outbound system built based on open-source platforms such as Freeswitch accesses the operator network (such as a mobile IMS dedicated line), it faces strict concurrent restrictions, specifically including: Operator's hard limit: The call initiation rate ≤ 30 times / second (basis: Mobile IMS technical specification); System configuration limit: The maximum concurrent call volume ≤ 1000 channels (determined by the performance of gateway devices and bandwidth configuration), so resource optimization is required.

[0003] However, the existing technical solutions have the following main defects: Concurrent control failure: Large-scale tasks are likely to exceed the system configuration limit, resulting in an increase in the call failure rate; Unbalanced resource allocation: The calling numbers are allocated by simple round-robin, triggering the operator's risk control strategy; Low scheduling efficiency: There is significant idle waiting time; Lack of exception handling: The retry mechanism for failed calls is imperfect, resulting in the loss of effective customers. Summary of the Invention

[0004] The purpose of the present invention is to provide a method for dynamic concurrent control and resource optimization of an intelligent telephone outbound system to solve the above-mentioned problems.

[0005] The technical solution adopted by the present invention is as follows: A method for dynamic concurrent control and resource optimization of an intelligent telephone outbound system, the method comprising the following steps:

[0006] S1: Establish a calling number resource pool, record the place of origin, operator, historical connection rate, maximum concurrent number (C_max_i) and cooling status; Generate a matching table of called numbers and calling numbers, and give priority to matching the regional consistency and operator preference strategy;

[0007] S2: Calculate the weight value of available calling numbers every 100 milliseconds, exclude the numbers in the cooling state or those that have reached the maximum concurrency, and allocate call tasks according to the weight ratio;

[0008] S3: Conduct a dual-token concurrent control check. Only when there are remaining tokens in both token pools, a new call is allowed to be initiated, and the number of calls is taken as the minimum of the two;

[0009] S4: Allocate the processable amount every 100ms, give priority to new calls, and the retry calls are dynamically de-weighted according to the number of failures;

[0010] S5: Retry failed calls according to the formula: When the calling number triggers risk control, calculate the cooling time according to the formula;

[0011] S6: Immediately release the capacity token after the call ends. For short-term failures, return the rate token. Continuously monitor the status of the calling number, the remaining capacity of the token pool, and the system concurrency.

[0012] S7: Reset the hourly usage count of the calling number every hour, update the status of the numbers in cooling, and release the resources that have completed cooling.

[0013] S8: Adjust the coefficient of the weight formula according to the historical connection rate and the operator's risk control feedback, and optimize the capacity of the dual token pool (1000 / 30) to adapt to changes in the network environment.

[0014] S9: When a burst task is detected, temporarily increase the capacity of the rate token pool. Smooth cross-cycle scheduling through the remainder accumulation mechanism to avoid resource waste.

[0015] In a preferred embodiment, in step S2, the weight calculation model formula for dynamic allocation of the calling number is:

[0016] W_i = 0.6×(C_max_i - C_curr_i) / C_max_i + 0.3×(1 - U_hour_i) + 0.1×e^(-T_cool_i / 3600);

[0017] Where C_max_i represents the maximum system-configured concurrency of number i (the maximum concurrency of the calling number is 10, so C_max_i = 10); C_curr_i represents the current used concurrency of number i (for example, if there are 3 calls in progress, then C_curr_i = 3); U_hour_i represents the proportion of the usage times of number i in the past 1 hour; T_cool_i represents the remaining cooling time of number i.

[0018] In a preferred embodiment, in step S2, the weight sorting and allocation include the following steps:

[0019] Step 2-1: Calculate the weight values of all available numbers every 100 milliseconds.

[0020] Step 2-2: Sort in descending order according to the weight values.

[0021] Step 2-3: Allocate the current batch of call tasks according to the weight ratio.

[0022] In a preferred embodiment, in step S3, the token pool status calculation formula is:

[0023] Capacity token pool: Available tokens = 1000 - Current number of calls

[0024] Rate token pool: Available tokens = 30 - Number of tokens used this second.

[0025] In a preferred embodiment, in step S3, a new call is allowed to be initiated only when there are remaining tokens in both token pools. The calculation formula is as follows:

[0026] Number of allowed calls = min(Capacity tokens, Rate tokens).

[0027] In a preferred embodiment, in step S5, the calculation formula for failed call retry is as follows:

[0028] Retry interval = min(300 × 2^n_retry, 86400).

[0029] In a preferred embodiment, in step S5, the formula for calculating the cooling time is as follows:

[0030] Cooling time = 3600 × √(Actual usage / Threshold).

[0031] In a preferred embodiment, in step S6, the occupied capacity tokens are released immediately after the call ends. If the call is not connected, the rate tokens are returned synchronously to avoid invalid occupation. The system continuously monitors the concurrent load, cooling status, and remaining tokens in the token pool of the calling number. For example, it tracks in real time the calling numbers whose usage times per hour are close to the threshold, gives early warnings, and adjusts the allocation strategy. At the same time, core metrics such as the global concurrent volume and the number of initiations per second are displayed through a visualization panel to support the operation and maintenance personnel in quickly identifying bottlenecks.

[0032] In a preferred embodiment, in step S7, the global status is maintained once per hour. The hourly usage counters of all calling numbers are reset, and the blocked status of the numbers that have reached the cooling time limit is lifted. For example, after a certain number is cooled for 1 hour due to excessive usage, the maintenance cycle automatically restores its status to available. This mechanism ensures the periodic reset of the resource allocation strategy and avoids the excessive influence of historical data on real-time scheduling.

[0033] In a preferred embodiment, in step S8, the core parameters are continuously optimized based on historical operation data and risk control feedback. For example, by analyzing the changes in the connection rate in different regions and time periods through machine learning, the coefficient ratios of the load balancing term, frequency control term, and cooling optimization term in the weight formula are dynamically adjusted (such as from the default 0.6 / 0.3 / 0.1 to 0.55 / 0.35 / 0.1). At the same time, the capacity of the dual token pool is elastically expanded according to changes in the network environment. For example, when the operator temporarily relaxes the concurrent limit, the capacity token pool is increased from 1000 to 1200 to improve the throughput.

[0034] In summary, due to the adoption of the above technical solutions, the beneficial effects of the present invention are as follows:

[0035] 1. In the present invention, the calling resources are dynamically allocated through a multi-dimensional weight model, effectively balancing line load and risk control while ensuring the compliance requirements of the operator. The real-time status monitoring of the calling number is combined with an intelligent cooling strategy, which not only avoids the overuse of a single line triggering the risk control mechanism but also ensures the efficient reach of high-value customers through priority scheduling. The dual constraints of the dual-token mechanism precisely control the concurrency scale and call rhythm, preventing the instantaneous traffic from impacting the system's carrying limit and ensuring that the outbound call rate always remains within the operator's safety threshold, thereby significantly reducing the call failure rate and resource waste.

[0036] 2. In the present invention, the parameter optimization mechanism based on dynamic feedback can automatically adjust the resource allocation strategy according to historical data and changes in the operating environment. For example, in the case of sudden traffic, the rate limit is temporarily relaxed and the remainder smoothing scheduling is enabled to achieve a smooth transition during the business peak. The intelligent retry strategy gradually extends the retry interval of failed tasks, avoiding the ineffective occupation of resources by invalid calls and providing a reasonable reach window for potentially valid customers. The periodic status reset and global maintenance mechanism of the calling number further ensure the sustainable utilization of resources, forming a closed-loop optimization system, and ultimately achieving a double improvement in outbound call efficiency and customer experience. BRIEF DESCRIPTION OF THE DRAWINGS

[0037] Figure 1 It is a schematic diagram of the process principle of the present invention. DETAILED DESCRIPTION OF THE EMBODIMENTS

[0038] In order to make the objectives, technical solutions and advantages of the present invention clearer, the present invention will be further described in detail below with reference to the drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain the present invention and are not used to limit the present invention.

[0039] Embodiment:

[0040] Refer to Figure 1 , a method for dynamic concurrency control and resource optimization of an intelligent telephone outbound call system, the method comprising the following steps:

[0041] S1: Initialize the calling number resource pool and the matching table:

[0042] When the system starts up, a calling number resource pool is pre-constructed, and core parameters such as the area code of the place of origin, the type of the affiliated operator, the historical connection rate, and the maximum concurrent bearing capacity are marked for each calling number. At the same time, a dynamic matching rule library for called numbers and calling numbers is established, and the optimal mapping relationship is generated based on the customer's geographical location and operator preference. For example, for called numbers in the Beijing area, calling numbers from Beijing are preferentially allocated, and the operator line with the highest historical connection rate of the customer is matched to ensure the call success rate and compliance. During the initialization process of the resource pool, the cooling status flag and real-time concurrent load data of the calling number are synchronously loaded, laying a foundation for subsequent dynamic scheduling.

[0043] S2: Dynamically assign weights to calling numbers:

[0044] The intelligent allocation of calling resources is achieved through a multi-dimensional weight model. The weight calculation comprehensively considers three key indicators: the proportion of real-time concurrent margin, the decay coefficient of the usage frequency in the past hour, and the exponential decay effect of the remaining cooling time. The system traverses all calling numbers that are not in the cooling period and have not reached the maximum concurrency every 100 milliseconds, calculates their comprehensive weight values and sorts them. The number with the highest weight will undertake more call tasks proportionally. For example, when a number has a large remaining concurrent capacity, a low recent usage frequency, and does not require cooling, its weight is significantly increased, so it is preferentially allocated outbound call requests to achieve a balance between resource utilization and risk control avoidance.

[0045] S3: Dual-token concurrent control verification:

[0046] A dual-constraint mechanism of capacity tokens and rate tokens is adopted to ensure the stability of the system. The capacity token pool reflects the global concurrent call margin in real time. For example, when the system is already carrying 800 calls, there are 200 remaining tokens available for new calls; the rate token pool strictly limits the number of call initiations per second to ensure that it does not exceed the operator's specified upper limit of 30 times per second. Before each call is initiated, tokens need to be applied from both token pools simultaneously, and the actual allowed call volume is the minimum of the remaining token numbers in the two pools. This mechanism effectively prevents instantaneous traffic overload and avoids scheduling failures caused by the premature exhaustion of resources in a single dimension.

[0047] S4: Three-level priority scheduling execution:

[0048] The call tasks are divided into three priority queues: new requests, retry requests, and normal requests, and a differential weight allocation strategy is adopted. The new call queue fixedly occupies 60% of the scheduling quota to ensure the timeliness of tasks; the retry queue dynamically reduces the weight according to the number of failures. For example, the weight of the first retry task is 0.15, and the second is reduced to 0.075, preventing tasks with repeated failures from overusing resources; the normal queue retains a 10% basic quota to process low-priority tasks. Within each scheduling cycle, the system extracts tasks from each queue for execution according to the weight ratio, and at the same time, through the remainder accumulation mechanism, the unused scheduling quota is smoothly transferred to subsequent cycles to improve the continuity of resource utilization.

[0049] Among them, the three-level priority scheduling algorithm includes:

[0050] 3-1. Queue weight calculation:

[0051] Queue priority = [0.6, 0.3×2^(-n_retry), 0.1]

[0052] 3-2. Parameter description:

[0053] The first queue (new call): 0.6, that is, it fixedly occupies 60% of the scheduling quota

[0054] The second queue (retry call): The weight decays exponentially with the number of retries

[0055] The first retry: 0.3×2^(-1) = 0.15

[0056] The second retry: 0.3×2^(-2) = 0.075

[0057] The third queue (normal call): 0.1, that is, it fixedly occupies 10% of the quota

[0058] 3-3. Scheduling process:

[0059] Execute every scheduling cycle (100ms):

[0060] 3-3-1. Calculate the processable quantity:

[0061] Processable quantity = min(available capacity token, available rate token, 3)

[0062] Processable quantity += the remainder of the remaining quota in the previous cycle

[0063] 3-3-2. Determine the actual processed quantity:

[0064] Actual processed quantity = the floor of the processable quantity

[0065] Usage this time = min(actual processed quantity, 30 - used times this second)

[0066] 3-3-3. Update remainder:

[0067] Remainder = Processable amount - Current usage amount

[0068] Cumulative remainder = remainder

[0069] 3-3-4. Allocation by priority:

[0070] First queue: current usage × 0.6

[0071] Second queue: current usage × 0.3 × 2^(-n_retry)

[0072] The third queue: the current usage amount × 0.1.

[0073] S5: Intelligent exception retry and cooling strategy:

[0074] An adaptive recovery mechanism is designed for call failure scenarios. The retry interval of failed tasks is extended exponentially with the number of retries. For example, the first retry is extended to 10 minutes after 5 minutes, and the maximum interval is no more than 24 hours, which not only ensures customer reach opportunities but also avoids intensive retries triggering risk control. For the calling number that triggers the operator's alarm, the system dynamically calculates the cooling time based on the excess usage ratio. For example, when the usage of a number exceeds the threshold of 20%, it is forced to cool down for about 1.1 hours. The cooling time increases with the square root of the excess degree to ensure that high-risk numbers are fully "cooled" before being reused.

[0075] S6: Real-time resource release and monitoring:

[0076] The occupied capacity token is released immediately after the call ends. If the call is not connected, the rate token is returned synchronously to avoid invalid occupation. The system continuously monitors the concurrent load, cooling status and token pool balance of the calling number. For example, it tracks the calling number whose usage per hour is close to the threshold in real time, and warns in advance and adjusts the allocation strategy. At the same time, the core indicators such as global concurrency and number of initiations per second are displayed through the visualization panel to support operation and maintenance personnel to quickly identify bottlenecks.

[0077] S7: Periodic maintenance and status reset:

[0078] Global status maintenance is performed once an hour to reset the hourly usage counters of all calling numbers and release numbers that have reached the cooling-off period. For example, after a number is cooled down for 1 hour due to overuse, the maintenance cycle automatically restores its status to available. This mechanism ensures the periodic reset of resource allocation strategies to prevent historical data from excessively affecting real-time scheduling.

[0079] S8: Dynamic parameter optimization and feedback:

[0080] Continuously optimize core parameters based on historical operational data and risk control feedback. For example, through machine learning, analyze the changes in connection rates in different regions and time periods, and dynamically adjust the coefficient ratios of load balancing items, frequency control items, and cooling optimization items in the weight formula (such as from the default 0.6 / 0.3 / 0.1 to 0.55 / 0.35 / 0.1). At the same time, flexibly expand the capacity of the dual token pool according to changes in the network environment. For example, when the operator temporarily relaxes the concurrency restrictions, increase the capacity token pool from 1000 to 1200 to improve throughput.

[0081] S9: burst traffic adaptive processing:

[0082] In response to instantaneous traffic surges caused by marketing activities and other scenarios, the system automatically activates emergency mode. The rate token pool capacity is temporarily increased to 1.2-1.5 times the normal value, and the unused scheduling quotas in the previous cycle are added to the current cycle through the remainder accumulation mechanism. For example, 0.8 quotas remaining in a 100ms cycle can be accumulated to the next cycle to achieve smooth handling of sudden traffic. At the same time, the scheduling ratio of low-priority tasks is dynamically compressed to prioritize the reach of high-value customers, and normal parameter configuration is automatically restored after the peak.

[0083] The implementation process includes:

[0084] 1. Task initialization

[0085] 1-1. Create a calling number resource pool, including the following attributes:

[0086] Area code, operator type, historical connection rate

[0087] Maximum number of concurrent connections (C_max_i), cooling status flag

[0088] 1-2. Generate a matching table of called number and calling number, giving priority to:

[0089] Regional consistency (local numbers calling local customers)

[0090] Carrier selection (matching customers' frequently used carriers)

[0091] 2. Real-time scheduling (loop execution every 100ms)

[0092] 2-1. Calculate available resources:

[0093] Capacity token number = 1000 - current number of calls

[0094] Number of rate tokens = 30 - number of tokens initiated this second

[0095] 2-2. Determine the dispatching amount:

[0096] The amount that can be processed this time = min (number of capacity tokens, number of rate tokens, 3)

[0097] (Note: It can be processed at most 3 times in 100 ms. Since 30 times / second ÷ 10 cycles = 3 times / cycle) 2-3. Allocate the calling number:

[0098] Sort the available numbers according to Formula 1

[0099] Allocate the call tasks according to the weight ratio

[0100] 3. Status monitoring and recovery

[0101] 3-1. Call end processing:

[0102] Successful call: Immediately release the capacity token

[0103] Short-term failure (ringing but not answered): Return the rate token

[0104] 3-2. Perform maintenance every hour:

[0105] Reset the hourly usage count of the calling number

[0106] Update the status of the numbers in cooling

[0107] In step S2, the weight calculation model formula for dynamic allocation of the calling number is:

[0108] W_i = 0.6×(C_max_i - C_curr_i) / C_max_i + 0.3×(1 - U_hour_i) + 0.1×e^(-T_cool_i / 3600);

[0109] Where C_max_i represents the maximum concurrent number configured in the system for number i (if the maximum concurrent number of the calling number is 10, then C_max_i = 10); C_curr_i represents the current used concurrent number of number i (for example, if there are 3 calls in progress, then C_curr_i = 3); U_hour_i represents the proportion of the usage times of number i in the past 1 hour; T_cool_i represents the remaining cooling time of number i;

[0110] In step S2, the weight sorting and allocation include the following steps:

[0111] Step 2-1: Calculate the weight values of all available numbers every 100 ms;

[0112] Step 2-2: Sort in descending order according to the weight values;

[0113] Step 2-3: Allocate the call tasks of the current batch according to the weight ratio.

[0114] In step S3, the token pool status calculation formula is:

[0115] Capacity Token Pool: Available Tokens = 1000 - Current Call Count

[0116] Rate Token Pool: Available Tokens = 30 - Tokens Used This Second.

[0117] In step S3, a new call is only allowed when there are remaining tokens in both token pools. The calculation formula is:

[0118] Allowed Call Count = min(Capacity Tokens, Rate Tokens).

[0119] In step S5, the calculation formula for failed call retry is:

[0120] Retry Interval = min(300 × 2^n_retry, 86400).

[0121] In step S5, the formula for calculating the cooling time is:

[0122] Cooling Time = 3600 × √(Actual Usage / Threshold).

[0123] In step S6, the occupied capacity tokens are released immediately after the call ends. If the call is not connected, the rate tokens are returned synchronously to avoid invalid occupation. The system continuously monitors the concurrent load, cooling status, and token pool balance of the calling number. For example, it tracks in real-time the calling numbers whose hourly usage times are close to the threshold, gives early warnings, and adjusts the allocation strategy. At the same time, core metrics such as the global concurrency and the number of initiations per second are displayed through a visualization panel to support operation and maintenance personnel in quickly identifying bottlenecks.

[0124] In step S7, the global status is maintained once an hour. The hourly usage counters of all calling numbers are reset, and the block status of the numbers that have reached the cooling time limit is lifted. For example, after a certain number is cooled for 1 hour due to excessive usage, the maintenance cycle automatically restores its status to available. This mechanism ensures the periodic reset of the resource allocation strategy and avoids historical data from overly affecting real-time scheduling.

[0125] In step S8, the core parameters are continuously optimized based on historical operation data and risk control feedback. For example, by analyzing the change in the connection rate in different regions and time periods through machine learning, the coefficient ratios of the load balancing term, frequency control term, and cooling optimization term in the weight formula are dynamically adjusted (such as from the default 0.6 / 0.3 / 0.1 to 0.55 / 0.35 / 0.1). At the same time, the capacity of the dual token pools is elastically expanded according to changes in the network environment. For example, when the operator temporarily relaxes the concurrent limit, the capacity token pool is increased from 1000 to 1200 to improve throughput.

[0126] From the above, it can be known that:

[0127] In the present invention, the calling resources are dynamically allocated through a multi-dimensional weight model, which effectively balances the line load and risk control on the premise of ensuring the compliance requirements of the operator. The real-time status monitoring of the calling number is combined with an intelligent cooling strategy, which not only avoids the overuse of a single line from triggering the risk control mechanism, but also ensures the efficient reach of high-value customers through priority scheduling. The dual constraints of the dual-token mechanism precisely control the concurrency scale and call rhythm, which not only prevent the instantaneous traffic from impacting the system's bearing limit, but also ensure that the outbound call rate is always within the operator's safety threshold, thereby significantly reducing the call failure rate and resource waste.

[0128] In the present invention, the parameter optimization mechanism based on dynamic feedback can automatically adjust the resource allocation strategy according to historical data and changes in the operating environment. For example, in the case of sudden traffic, the rate limit is temporarily relaxed and the remainder smoothing scheduling is enabled to achieve a smooth transition during the business peak. The intelligent retry strategy gradually extends the retry interval of failed tasks, which not only avoids the ineffective occupation of resources by invalid calls, but also provides a reasonable reach window for potentially valid customers. The periodic status reset and global maintenance mechanism of the calling number further guarantee the sustainable utilization of resources, forming a closed-loop optimization system, and ultimately achieving a double improvement in outbound call efficiency and customer experience.

[0129] It should be noted that in this article, relational terms such as first and second are only used to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any actual relationship or order between these entities or operations. Moreover, the term "including" or any other variant thereof is intended to cover non-exclusive inclusion, so that a process, method, article, or device including a series of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such process, method, article, or device. Without further limitation, an element defined by the phrase "including a..." does not exclude the existence of additional identical elements in the process, method, article, or device including the element.

[0130] The above embodiments are only used to illustrate the technical solutions of the present invention, rather than to limit it; although the present invention has been described in detail with reference to the foregoing embodiments, those of ordinary skill in the art should understand that they can still modify the technical solutions recorded in the foregoing embodiments, or perform equivalent replacements for some of the technical features; and these modifications or replacements do not make the essence of the corresponding technical solutions deviate from the spirit and scope of the technical solutions of the various embodiments of the present invention.

Claims

1. A method for dynamic concurrency control and resource optimization of an intelligent telephone outbound call system, characterized in that: The method comprises the following steps: S1: Establish a calling number resource pool, record the location, operator, historical connection rate, maximum concurrent number and cooling status; generate a matching table of called numbers and calling numbers, giving priority to matching regional consistency and operator optimization strategy; S2: Calculate the weight value of the available calling numbers every 100 milliseconds, exclude the numbers that are in cooling down or have reached the maximum concurrency, and allocate call tasks according to the weight ratio; S3: Perform dual-token concurrency control verification. Only when both token pools have remaining tokens, a new call is allowed, and the number of calls is the minimum of the two. S4: Allocate available capacity every 100ms, give priority to new calls, and dynamically downgrade retry calls according to the number of failures; S5: Failed calls are retried according to the formula: When the calling number triggers risk control, the cooling time is calculated according to the formula; S6: Release the capacity token immediately after the call ends, return the rate token for a short-term failure, and continuously monitor the calling number status, token pool balance, and system concurrency; S7: reset the hourly usage count of the calling number every hour, update the status of the number in cooling down, and release the resources that have completed cooling down; S8: According to the historical connection rate and the operator's risk control feedback, adjust the weight formula coefficient and optimize the capacity of the dual token pool to adapt to changes in the network environment; S9: When a burst task is detected, the rate token pool capacity is temporarily increased to smooth cross-cycle scheduling through the remainder accumulation mechanism to avoid resource waste.

2. The method for dynamic concurrency control and resource optimization of an outbound call system of a smart phone according to claim 1, characterized in that: In step S2, the weight calculation model formula for dynamic allocation of calling number is: W_i=0.6×(C_max_i-C_curr_i) / C_max_i+0.3×(1-U_hour_i)+0.1×e^(-T_cool_i / 3600); Among them, C_max_i represents the maximum concurrent number of number i configured by the system; C_curr_i represents the current concurrent number of number i used; U_hour_i represents the percentage of number i used in the past hour; T_cool_i represents the remaining cooling time of number i.

3. The method for dynamic concurrency control and resource optimization of an outbound call system of a smart phone according to claim 1, characterized in that: In step S2, the weight sorting and allocation includes the following steps: Step 2-1: Calculate the weight values ​​of all available numbers every 100 milliseconds; Step 2-2: Sort by weight value from high to low; Step 2-3: Allocate the calling tasks of the current batch according to the weight ratio.

4. The method for dynamic concurrency control and resource optimization of an outbound call system of a smart phone as claimed in claim 1, characterized in that: In step S3, the token pool status calculation formula is: Capacity token pool: Available tokens = 1000 - current number of calls Rate token pool: Number of available tokens = 30 - number of tokens used this second.

5. The method for dynamic concurrency control and resource optimization of an outbound call system of a smart phone as claimed in claim 1, characterized in that: In step S3, a new call is allowed only when both token pools have tokens remaining. The calculation formula is: Number of allowed calls = min(number of capacity tokens, number of rate tokens).

6. The method for dynamic concurrency control and resource optimization of an outbound call system of a smart phone as claimed in claim 1, characterized in that: In step S5, the calculation formula for failed call retry is: Retry interval = min(300×2^n_retry,86400).

7. The method for dynamic concurrency control and resource optimization of an outbound call system of a smart phone as claimed in claim 1, characterized in that: In step S5, the cooling time is calculated as follows: Cooling time = 3600 × √ (actual usage / threshold value).

8. The method for dynamic concurrency control and resource optimization of an outbound call system of a smart phone as claimed in claim 1, characterized in that: In step S6, the occupied capacity token is released immediately after the call ends, and the rate token is returned synchronously if the call is not connected to avoid invalid occupation; the system continuously monitors the concurrent load, cooling status and token pool balance of the calling number.

9. The method for dynamic concurrency control and resource optimization of an outbound call system of a smart phone as claimed in claim 1, characterized in that: In step S7, global status maintenance is performed once every hour, the hourly usage counters of all calling numbers are reset, and the blocking status of numbers that have reached the cooling-off time limit is released.

10. The method for dynamic concurrency control and resource optimization of an intelligent phone outbound call system according to claim 1, characterized in that: In step S8, core parameters are continuously optimized based on historical operating data and risk control feedback.

Images