Message push method, device, equipment and medium

Abstract

The present application provides a message push method, apparatus, device and medium, which are applied to the field of computer technology. The method includes: in response to a received message push task, obtaining the traffic processing capacity of the push server based on historical push data, and the message push task includes at least: total message traffic and expected push time; obtaining the number of servers that can carry the total message traffic within the expected push time based on the traffic processing capacity; obtaining the push rate of each push server based on the total message traffic, expected push time and the number of servers; adding the total message traffic to a message queue based on the push rate, and the message queue is used to send message traffic to the push server at the push rate, so that each push server executes the message push task at the push rate.

Description

Technical Field

[0001] The present application relates to the field of computer technology, and in particular to a message push method, apparatus, device, and medium. Background Art

[0002] Message push technology is widely used by many service providers as a way for the server to actively send messages to the client.

[0003] In the related art, a fixed number of push servers are usually selected by using a constant server instance to execute a push task and send the required push message content to the client.

[0004] However, the pulse-like changes in push message traffic are difficult to predict. If push messages are processed by a fixed number of push servers, a sudden increase in push traffic and an insufficient number of push servers may cause push messages to be difficult to send in a timely manner, leading to message congestion on the servers. Alternatively, a sudden decrease in push traffic and an excessive number of push servers may cause the traffic resources of each push server to be unused, resulting in wasted traffic resources. Furthermore, due to the unstable traffic changes, the push server may need to handle too much traffic at certain times, making it difficult to process the traffic in a timely manner, or too little traffic at certain times, resulting in wasted traffic resources. Summary of the Invention

[0005] In view of this, the present application provides a message push method, device, equipment and medium to solve the technical problems in the related technology that the server instances used to select the number of push servers are constant, resulting in message blocking due to insufficient number of push servers when encountering pulsed push traffic, and the traffic resources of each push server cannot be used due to excessive number of push servers, resulting in waste of traffic resources of the push servers.

[0006] This application provides a message push method, including:

[0007] In response to a received message push task, obtaining the traffic processing capacity of the push server based on historical push data, wherein the message push task includes at least: total message traffic and expected push time;

[0008] Obtaining the number of servers that can carry the total message traffic within the expected push time based on the traffic processing capacity;

[0009] Obtaining a push rate for each push server based on the total message traffic, expected push time, and the number of servers;

[0010] The total message traffic is added to a message queue based on the push rate. The message queue is used to send message traffic to the push servers according to the push rate, so that each push server performs the message push task according to the push rate.

[0011] Optionally, the historical push data includes at least: the historical expected push time and the historical actual push time of the push server when executing the message push task last time;

[0012] The method of obtaining the traffic processing capacity of the push server based on historical push data includes:

[0013] Comparing the historical expected push time with the historical actual push time to obtain a time comparison result;

[0014] When it is confirmed that the time comparison result meets the adjustment condition, the traffic processing capacity of the push server is adjusted according to the time comparison result, wherein the traffic processing capacity is used to represent the traffic processing amount of the push server per unit time.

[0015] Optionally, confirming that the time comparison result meets the adjustment condition includes:

[0016] When the historical actual push time is greater than the historical expected push time, or the historical actual push time is less than the difference between the historical expected push time and the push time threshold, it is confirmed that the time comparison result meets the adjustment condition.

[0017] Optionally, adjusting the traffic processing capability of the push server according to the time comparison result includes:

[0018] Calculate the time ratio between the historical expected push time and the historical actual push time;

[0019] The product of the time ratio and the traffic processing capacity of the push server is rounded up to an integer to obtain the adjusted traffic processing capacity.

[0020] Optionally, acquiring the push rate of each push server based on the total message traffic, expected push time, and the number of servers includes:

[0021] Dividing the total message flow according to the number of servers to obtain the message flow distribution of each push server;

[0022] Based on the ratio of the message flow rate to the expected push time, the push rate of each push server is obtained.

[0023] Optionally, acquiring the push rate of each push server based on the ratio of the message split flow rate to the expected push time includes:

[0024] Dividing the expected push time into multiple time periods;

[0025] Evenly distribute the message traffic to each time-sharing time period to obtain the time-sharing traffic corresponding to each time-sharing time period;

[0026] When the variance between each of the time-sharing flows is less than the variance threshold, the ratio between the time-sharing flow and the duration corresponding to any of the time-sharing time periods is used as the push rate.

[0027] Optionally, obtaining the number of servers that can carry the total message traffic within the expected push time based on the traffic processing capability includes:

[0028] Obtaining, according to the traffic processing capability of the push server, the processable traffic of the push server within the expected push time;

[0029] Based on the ratio of the total message traffic to the processable traffic, the number of servers that can bear the total message traffic within the expected push time is determined.

[0030] This application provides a message push device, including:

[0031] an acquisition module, configured to acquire the traffic processing capacity of the push server based on historical push data in response to a received message push task, wherein the message push task includes at least: total message traffic and expected push time;

[0032] An adjustment module, configured to obtain, based on the traffic processing capability, the number of servers that can carry the total message traffic within the expected push time;

[0033] A push module, configured to obtain a push rate of each push server based on the total message traffic, the expected push time, and the number of servers;

[0034] The total message traffic is added to a message queue based on the push rate. The message queue is used to send message traffic to the push servers according to the push rate, so that each push server performs the message push task according to the push rate.

[0035] Optionally, the historical push data includes at least: the historical expected push time and the historical actual push time of the push server when executing the message push task last time;

[0036] The acquisition module is further used to:

[0037] Comparing the historical expected push time with the historical actual push time to obtain a time comparison result;

[0038] When it is confirmed that the time comparison result meets the adjustment condition, the traffic processing capacity of the push server is adjusted according to the time comparison result, wherein the traffic processing capacity is used to represent the traffic processing amount of the push server per unit time.

[0039] Optionally, the acquisition module is further configured to:

[0040] When the historical actual push time is greater than the historical expected push time, or the historical actual push time is less than the difference between the historical expected push time and the push time threshold, it is confirmed that the time comparison result meets the adjustment condition.

[0041] Optionally, the acquisition module is further configured to:

[0042] Calculate the time ratio between the historical expected push time and the historical actual push time;

[0043] The product of the time ratio and the traffic processing capacity of the push server is rounded up to an integer to obtain the adjusted traffic processing capacity.

[0044] Optionally, the push module is further configured to:

[0045] Dividing the total message flow according to the number of servers to obtain the message flow distribution of each push server;

[0046] Based on the ratio of the message flow rate to the expected push time, the push rate of each push server is obtained.

[0047] Optionally, the push module is further configured to:

[0048] Dividing the expected push time into multiple time periods;

[0049] Evenly distribute the message traffic to each time-sharing time period to obtain the time-sharing traffic corresponding to each time-sharing time period;

[0050] When the variance between each of the time-sharing flows is less than the variance threshold, the ratio between the time-sharing flow and the duration corresponding to any of the time-sharing time periods is used as the push rate.

[0051] Optionally, the adjustment module is further configured to:

[0052] Obtaining, according to the traffic processing capability of the push server, the processable traffic of the push server within the expected push time;

[0053] Based on the ratio of the total message traffic to the processable traffic, the number of servers that can bear the total message traffic within the expected push time is determined.

[0054] The present application provides an electronic device, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor implements the above-mentioned message push method when executing the computer program.

[0055] The present application provides a computer-readable storage medium, on which a computer program is stored. When the computer program is executed by a processor, the above-mentioned message push method is implemented.

[0056] With respect to related technologies, this application has the following advantages:

[0057] The present application provides a message push method, apparatus, device and medium, which, before sending a message push task to a push server, automatically and dynamically adjusts the number of servers executing the message push task according to the traffic processing capacity of the push server by applying changes in the total message traffic and expected push time included in the message push task, and sends the message traffic to the message queue of the push server at a determined push rate, thereby improving the stability and resource utilization of the server push messages.

[0058] The above description is only an overview of the technical solution of the present application. In order to more clearly understand the technical means of the present application, it can be implemented in accordance with the contents of the specification. In order to make the above and other purposes, features and advantages of the present application more obvious and easy to understand, the specific implementation methods of the present application are listed below. BRIEF DESCRIPTION OF THE DRAWINGS

[0059] Various other advantages and benefits will become apparent to those skilled in the art upon reading the detailed description of the preferred embodiment below. The accompanying drawings are for illustration purposes only and are not to be considered as limiting the present application. The same reference symbols are used throughout the drawings to represent the same components. In the drawings:

[0060] Figure 1 This is a flowchart of a message push method provided by an embodiment of the present application;

[0061] Figure 2 This is one of the step flow charts of another message push method provided in an embodiment of the present application;

[0062] Figure 3 This is the second step flow chart of another message push method provided by an embodiment of the present application;

[0063] Figure 4This is the third step flow chart of another message push method provided by an embodiment of the present application;

[0064] Figure 5 This is the fourth step flow chart of another message push method provided in an embodiment of the present application;

[0065] Figure 6 This is the fifth step flow chart of another message push method provided by an embodiment of the present application;

[0066] Figure 7 This is a logic flow chart of a message push method provided by an embodiment of the present application;

[0067] Figure 8 This is a structural block diagram of a message push device provided in an embodiment of the present application;

[0068] Figure 9 This is a structural block diagram of an electronic device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0069] The following describes exemplary embodiments of the present application in more detail with reference to the accompanying drawings. Although exemplary embodiments of the present application are shown in the accompanying drawings, it should be understood that the present application can be implemented in various forms and should not be limited by the embodiments set forth herein. Rather, these embodiments are provided to enable a more thorough understanding of the present application and to fully convey the scope of the present application to those skilled in the art.

[0070] Figure 1 This is a flowchart of the steps of a message push method provided in an embodiment of the present application, including:

[0071] It should be noted that the execution entity of some embodiments of the present application may be a management server, which is a server used to edit and manage message push tasks. Users can generate message push tasks by setting configuration parameters such as the message content, push target, expected push time, and total message traffic on the upstream management server, and then send the generated message push task to the push server, so that the push server sends the message content to the push target by executing the message push task. The push target refers to the terminal device of the user to be pushed, the push content refers to the text, audio and video, website link and other types of data in the push message, and the expected push time is the time the user expects the push server to complete the message push task. The total message traffic refers to the total number of times the message content is required.

[0072] A push server is a server that sends push messages to the target server in response to push tasks issued by the management server. Because a single server typically has limited data processing capabilities, a push server is typically a server cluster consisting of multiple servers. Multiple push servers in a cluster can collaborate to complete the same push task, improving push efficiency.

[0073] Step 101: In response to a received message push task, the traffic processing capacity of the push server is obtained according to historical push data. The message push task includes at least: total message traffic and expected push time.

[0074] It should be noted that historical push data is a record of the message push tasks that the push server has completed in the past event end. It may include parameters such as throughput, push time, and number of pushes that can reflect the performance of the push server. The specific settings can be based on actual needs and are not limited here.

[0075] Traffic processing capacity refers to the ability of a push server to send push messages. It can be measured by the number of push messages sent by the push server per unit time, or by the total number of push messages sent by the push server within a certain time period. The specific setting can be based on actual needs and is not limited here.

[0076] In this embodiment of the present application, after a user configures and generates a message push task on the management server, they can submit the message push task to the management server without specifying the push server to execute the message push task. The management server will then dispatch the message push task to the push server based on the total message traffic carried by the message push task and the expected push time. In order to set a reasonable number of push servers to execute this message push task, the management server first needs to evaluate the push server's traffic push capacity based on its historical push data, which will be used for further evaluation of the number of servers required to call the push server.

[0077] Specifically, the traffic processing capacity of the push server can be determined based on the historical push data of the push server in the past when executing message push tasks. For example, the number of message pushes per unit time for all message push tasks completed by the push server in the past can be used as the message push capacity, or the expected push time and actual push time of the last completed message push task can be compared. Of course, this is only an exemplary description. The specific method of determining the traffic processing capacity can be set according to actual needs and is not limited here.

[0078] Step 102: Obtain the number of servers that can carry the total message traffic within the expected push time based on the traffic processing capability.

[0079] In the embodiment of the present application, considering that a server cluster composed of many servers to be pushed can execute multiple message push tasks at the same time, this involves the question of which servers execute which message push tasks. This problem usually depends on which push servers the upstream management server sends the same message push task to. For this problem, users usually customize fixed server instances for different types of message push tasks based on their personal experience, and the management server specifies the number of push servers that execute the message push tasks based on the type of message push task and the server instance. However, this method is too rigid and difficult to adapt to the pulse-like traffic that occurs during the message push task. That is, the traffic of message push doubles in a certain period of time, which will lead to insufficient number of push servers and cause message push blockage. The traffic of message push drops sharply in a certain period of time, which will cause some push servers to have no messages to push, resulting in a waste of server resources.

[0080] However, some embodiments of the present application abandon the method of pre-customizing personalized server instances in related technologies. Before issuing a message push task, the management server evaluates the number of servers that can complete the message push task with a total message traffic within the expected push time based on the traffic processing capacity of the currently evaluated push server. In this way, the number of push servers can be adjusted in real time to adapt to changes in the total message traffic. If the traffic doubles, the number of servers can be increased, and if the traffic drops sharply, the number of servers can be reduced, so that the traffic resources of the push server can be used reasonably.

[0081] Step 103: Obtain the push rate of each push server based on the total message traffic, expected push time, and the number of servers.

[0082] In the embodiment of the present application, considering that the key to the push capability of a stable push server lies not only in the number of push servers, but also in the push rate of each push server at each time point, it is understandable that even if the push traffic allocated to a push server can theoretically be processed within the expected push time, if the push rate of the push server at a certain time point is too fast, it will still cause message push blocking, and if the push rate is too slow, it will still cause push resource waste. Therefore, when allocating push traffic to a push server, the message traffic that the push server needs to be responsible for can be allocated to the message queue of the push server, and the message traffic can be processed uniformly at a reasonable push rate throughout the expected push time, thereby ensuring that a single push server will not experience push blocking or resource waste during the message push task.

[0083] Step 104: Add the total message traffic to a message queue based on the push rate. The message queue is used to send message traffic to the push servers at the push rate, so that each push server executes the message push task at the push rate.

[0084] In an embodiment of the present application, the management server adds the total push traffic of the message push task to the management server's message queue and performs peak shaving and valley filling. That is, the excess traffic per unit time in the message queue is reduced and filled with the less traffic per unit time, to ensure that the traffic in the message queue is evenly distributed, so that the number of messages required to be pushed per unit time in the message queue remains substantially consistent. Therefore, when each push server extracts message content from the message queue, it can extract the content of a fixed number of messages per unit time, thereby ensuring that the number of messages pushed by the push server per unit time is fixed, that is, the message push rate of the push server remains substantially stable.

[0085] It is worth noting that there can be one or more message queues in the management server. If there is only one message queue, multiple push servers can queue up to extract message content from the message queue of the management server one by one. Since the message traffic distributed per unit time in the message queue is evenly distributed, the number of messages that the push server needs to push within the unit time will also remain consistent, that is, the push rate of the push server will basically remain consistent.

[0086] If there are multiple message queues, there can be a setting method in which each push server corresponds to one message queue. At this time, different message queues can add message traffic according to the push rate of the corresponding push server, so as to achieve the effect of different push servers executing push tasks at different push rates. Of course, the message traffic in each message queue is still evenly distributed. Therefore, although the push rate of each push server is different, the push rate of a single push server remains basically consistent.

[0087] If there are multiple message queues, each message queue can be used by one or more push servers. In this case, in order to ensure that the push rate of a single push server can remain basically consistent, the message traffic in the one or more message queues used by a single push server needs to be distributed according to the same push rate.

[0088] Furthermore, the push server periodically feeds back the completion progress of its own message push task to the management server. After each push server completes the message push task, the management server will statistically analyze the completion status of each push server for the message push task, and record the completion status as historical push data for use when executing the message push task next time.

[0089] The embodiment of the present application automatically and dynamically adjusts the number of servers executing the message push task according to the traffic processing capacity of the push server before issuing the message push task to the push server by applying the changes in the total message traffic and the expected push time included in the message push task, and smoothes the message traffic according to the determined push rate, and evenly sends the message traffic to the message queue of the push server. This not only avoids the push congestion caused by too many servers and too fast a push rate, but also avoids the waste of traffic resources caused by too few servers and too slow a push rate, thereby improving the stability and resource utilization of server push messages.

[0090] Optionally, the historical push data includes at least: the historical expected push time and historical actual push time of the push server when it last executed the message push task, Figure 2 , the step 101 comprises:

[0091] Step 1011 : Compare the historical expected push time with the historical actual push time to obtain a time comparison result.

[0092] Step 1012: When it is confirmed that the time comparison result meets the adjustment conditions, the traffic processing capacity of the push server is adjusted according to the time comparison result, wherein the traffic processing capacity is used to represent the traffic processing volume of the push server per unit time.

[0093] It should be noted that the historical expected push time is the specified expected push time when the push server last executed the message push task, and the historical actual push time is the actual time the push server last executed and completed the message push task.

[0094] In the embodiment of the present application, the traffic processing capacity of the push server when it last executed a message push task is the closest to the traffic processing capacity of the push server at the current moment. Therefore, the embodiment of the present application will compare the historical expected push time and the historical actual push time when the push server last executed a message push task, and then reflect whether the traffic processing capacity of the push server is accurate based on the obtained time comparison result. Correspondingly, considering that calculating the traffic processing capacity of the push server every time a message is pushed will increase the resource consumption and time of the message push process, and reduce the efficiency of the message push, it is possible to set adjustment conditions and compare the time comparison results with the adjustment conditions each time a message push task is executed, so that the traffic processing capacity is adjusted only when the adjustment conditions are met, thereby effectively reducing the calculation frequency of the traffic processing capacity of the push server and improving the efficiency of the message push task.

[0095] Specifically, the adjustment condition can be set by setting a time range. If the time comparison result exceeds the time range, it is determined that the adjustment condition is met and the traffic processing capacity needs to be adjusted. If the time comparison result does not exceed the time range, it is determined that the adjustment condition is not met and the traffic processing capacity does not need to be adjusted. The adjustment condition can also be set by setting a time threshold. If the time comparison result exceeds the time threshold, it is determined that the adjustment condition is met and the traffic processing capacity needs to be adjusted. If the time comparison result does not exceed the time threshold, it is determined that the adjustment condition is not met and the traffic processing capacity does not need to be adjusted.

[0096] The embodiment of the present application sets adjustment conditions to judge the time comparison results between the actual time used by the push server and the expected time used, and adjusts the traffic processing capacity of the push server only when the adjustment conditions are met. This can effectively reduce the calculation frequency of the traffic processing capacity of the push server and improve the efficiency of the message push task.

[0097] Optionally, refer to Figure 3 , the step 1012 includes:

[0098] Step 10121: When the historical actual push time is greater than the historical expected push time, or the historical actual push time is less than the difference between the historical expected push time and the push time threshold, confirm that the time comparison result meets the adjustment conditions.

[0099] Step 10122: Calculate the time ratio between the historical expected push time and the historical actual push time.

[0100] Step 10123: round up the product of the time ratio and the traffic processing capacity of the push server to an integer to obtain the adjusted traffic processing capacity.

[0101] In an embodiment of the present application, considering that adjusting the traffic processing result of the push server as long as the historical actual push time does not reach the historical expected push time will cause the evaluation process of the traffic processing capacity to be too frequent, it is possible to determine whether the traffic processing capacity needs to be adjusted by setting a limit condition on the size relationship between the historical expected push time and the historical actual push time.

[0102] Specifically, if the historical actual push time is greater than the historical expected push time, it indicates that the traffic processing capacity of the push server is overestimated. It is necessary to ensure that the historical actual push time is less than or equal to the historical expected push time. In this case, the traffic processing capacity is adjusted when the historical actual push time is greater than the historical expected push time. In order to avoid the situation where the traffic resources are wasted excessively due to the excessive underestimation of the traffic processing capacity of the push server, the traffic processing capacity can be adjusted when the historical actual push time is much less than the historical expected push time. The relationship of being much less than can be measured by setting a push time threshold, that is, when the historical actual push time is less than the difference between the historical expected push time and the push time threshold, the traffic processing capacity is adjusted. The push time threshold can be set by the user or by the system default setting. It can be set according to actual needs and is not limited here.

[0103] Furthermore, the traffic processing capacity has been evaluated once when the message push task was last executed, and is set to x2. If the message push task has not been executed, x1 can take the default value. And let the historical expected push time be t, the historical actual push time be t1, and the push time threshold be a. Then, when t1>t or t1<ta, the adjusted message processing capacity of the push server can be calculated by the following formula (1):

[0104] x2=ROUNDUP((t*x1) / t1) (1)

[0105] ROUNDUP() is a function that rounds up to an integer. As can be seen, when the historical actual time is less than the historical expected time, the ratio t / t1 will be greater than 1, and the resulting x2 will be greater than x1. This increases the traffic processing capacity of the push server, reduces the number of servers executing push tasks, and avoids resource waste caused by too many servers. When the historical actual time is greater than the historical expected time, the ratio t / t1 will be less than 1, and the resulting x2 will be less than x1. This reduces the traffic push capacity and increases the number of servers executing push tasks, avoiding message blocking caused by too few servers.

[0106] Optionally, refer to Figure 4 , the step 103 includes:

[0107] Step 1031: Divide the total message traffic according to the number of servers to obtain the message traffic of each push server.

[0108] Step 1032: Obtain the push rate of each push server based on the ratio of the message flow rate to the expected push time.

[0109] In an embodiment of the present application, in order to enable the push server to complete the task within the expected push time while maintaining uniform push efficiency, the total amount of messages in the message push task can first be evenly divided among each push server to obtain the message traffic that each push server needs to carry. Then, the message traffic is evenly distributed to each time point of the expected push time, so as to obtain the push rate of the push server executing the message push task this time. In other words, the traffic at the time point with excessive message traffic is distributed to the time point with less message traffic. By shaving peaks and filling valleys for the distribution of message traffic in the expected push time, the message traffic allocated at each time point is ensured to be basically consistent. In this way, the amount of message traffic sent by the message queue to the push server per unit time can be kept stable, avoiding message congestion caused by the push server being unable to process the message traffic in a timely manner due to a sudden increase in message traffic, and resource waste caused by the push server having no traffic to process due to a sudden decrease in message traffic.

[0110] The embodiment of the present application obtains the push rate based on the ratio of the message traffic required to be carried by each push server and the expected push time, so that each push server can perform message push tasks at a smooth push rate, avoiding message push congestion or waste of traffic resources due to the push rate being too fast or too slow at individual time points.

[0111] Optionally, refer to Figure 5 , the step 1032 includes:

[0112] Step 10321: Divide the expected push time into multiple time periods.

[0113] Step 10322: Evenly distribute the message traffic to each of the time-sharing time periods to obtain the time-sharing traffic corresponding to each of the time-sharing time periods.

[0114] Step 10323: When the variance between each of the time-sharing flows is less than the variance threshold, the ratio between the time-sharing flow and the duration corresponding to any of the time-sharing time periods is used as the push rate.

[0115] In the embodiment of the present application, it is difficult to achieve completely uniform distribution of message traffic, taking into account that there are certain errors in the distribution process, but if the change curve of the push rate is smooth, the stability of the message push can still be guaranteed to a certain extent. Therefore, the embodiment of the present application divides the expected push time into multiple time-sharing time periods according to the preset duration, and then characterizes the smoothness of the push rate by calculating the variance between the time-sharing traffic obtained by each time-sharing time period. Specifically, when the variance is less than the variance threshold, it can be determined that the smoothness of the push rate meets expectations, so that the push rate of any time-sharing time period can be used as the push task for the push server to execute the message push task. The variance threshold can be a user setting or a system default setting. It can be set according to actual needs and is not limited here.

[0116] The implementation of this application measures the smoothness of the push rate by measuring the variance between the time-sharing traffic in each time-sharing period in the expected push time, and thus selects the push rate of any time-sharing period when the variance is less than the variance threshold, so that the push server can execute the message push task according to the smoothly changing push rate, thereby ensuring the stability of the message push.

[0117] Optionally, refer to Figure 6 , the step 102 includes:

[0118] Step 1021: Obtain the processable traffic of the push server within the expected push time according to the traffic processing capability of the push server.

[0119] Step 1022: Based on the ratio of the total message traffic to the processable traffic, determine the number of servers that can bear the total message traffic within the expected push time.

[0120] In the embodiment of the present application, the traffic processing capacity can be the throughput X of the push server, the expected push time is T, and the total message traffic is M. The number of push servers N can be calculated by the following formula (2):

[0121] N=M / (X*T) (2)

[0122] As can be seen, the throughput X of the push server multiplied by the expected push time T can be used to obtain the traffic that the push server can handle within the expected push time. Then, the total message traffic M is divided by the traffic that the push server can handle to determine the number of push servers required to complete the message push task of processing the total message traffic within the expected push time.

[0123] The embodiment of the present application evaluates the processable traffic of each push server within the expected push time based on the traffic processing capacity of the push server, and determines the required number of servers to be pushed based on the ratio of the total message traffic to the processable traffic, so that the number of push servers can be adjusted to suit different message push tasks and the performance status of the push servers, thereby improving the flexibility of the message push tasks.

[0124] For example, refer to Figure 7 In some embodiments of the present application, the method includes:

[0125] S1. The management server periodically schedules and obtains message push tasks;

[0126] S2. The management server sends the message push task to the message queue and performs peak-shaving and valley-filling on the message queue traffic.

[0127] S3. The management server calculates the throughput x of the push server based on historical push data.

[0128] S4. The management server calculates the number of servers n based on the push server throughput x, the expected push time t, and the total message traffic m;

[0129] S5. The management server adjusts the number of servers in the push server cluster to n.

[0130] S6. The push server processes the message traffic in the message queue of the management server;

[0131] S7. After the message push task is completed, the management server records the actual push time t1;

[0132] S8. When the actual push time t1 is greater than the expected push time t, or the actual push time t1 is less than the difference ta between the expected push time and the push time threshold a, execute step S9;

[0133] S9 , adjusting the throughput x of the push server based on the ratio of t1 to t, and proceeding to step S4 using the adjusted throughput x.

[0134] It can be seen that in addition to the throughput initially calculated based on historical push data, the above process will subsequently dynamically adjust the throughput based on the quantitative relationship between the actual push time and the expected push time to achieve the effect of dynamically adjusting the number of push servers. This not only avoids the push congestion caused by too many servers and too fast a push rate, but also avoids the waste of traffic resources caused by too few servers and too slow a push rate, thereby improving the stability and resource utilization of server push messages.

[0135] Figure 8: is a structural block diagram of a message push device 20 provided in an embodiment of the present application, including:

[0136] Acquisition module 201 is used to obtain the traffic processing capacity of the push server based on historical push data in response to a received message push task, wherein the message push task includes at least: total message traffic and expected push time;

[0137] An adjustment module 202 is configured to obtain, based on the traffic processing capability, the number of servers that can carry the total message traffic within the expected push time;

[0138] The push module 203 is configured to obtain a push rate of each push server based on the total message traffic, the expected push time, and the number of servers;

[0139] The total message traffic is added to a message queue based on the push rate. The message queue is used to send message traffic to the push servers according to the push rate, so that each push server performs the message push task according to the push rate.

[0140] Optionally, the historical push data includes at least: the historical expected push time and the historical actual push time of the push server when executing the message push task last time;

[0141] The acquisition module 201 is further configured to:

[0142] Comparing the historical expected push time with the historical actual push time to obtain a time comparison result;

[0143] When it is confirmed that the time comparison result meets the adjustment condition, the traffic processing capacity of the push server is adjusted according to the time comparison result, wherein the traffic processing capacity is used to represent the traffic processing amount of the push server per unit time.

[0144] Optionally, the acquisition module 201 is further configured to:

[0145] When the historical actual push time is greater than the historical expected push time, or the historical actual push time is less than the difference between the historical expected push time and the push time threshold, it is confirmed that the time comparison result meets the adjustment condition.

[0146] Optionally, the acquisition module 201 is further configured to:

[0147] Calculate the time ratio between the historical expected push time and the historical actual push time;

[0148] The product of the time ratio and the traffic processing capacity of the push server is rounded up to an integer to obtain the adjusted traffic processing capacity.

[0149] Optionally, the push module 203 is further configured to:

[0150] Dividing the total message flow according to the number of servers to obtain the message flow distribution of each push server;

[0151] Based on the ratio of the message split flow rate to the expected push time, a push rate of each push server is obtained.

[0152] Optionally, the push module 203 is further configured to:

[0153] Dividing the expected push time into multiple time periods;

[0154] Evenly distribute the message traffic to each time-sharing time period to obtain the time-sharing traffic corresponding to each time-sharing time period;

[0155] When the variance between each of the time-sharing flows is less than the variance threshold, the ratio between the time-sharing flow and the duration corresponding to any of the time-sharing time periods is used as the push rate.

[0156] Optionally, the adjustment module 202 is further configured to:

[0157] Obtaining, according to the traffic processing capability of the push server, the processable traffic of the push server within the expected push time;

[0158] Based on the ratio of the total message traffic to the processable traffic, the number of servers that can bear the total message traffic within the expected push time is determined.

[0159] The embodiment of the present application improves the stability and resource utilization of server push messages by automatically and dynamically adjusting the number of servers executing the message push task based on the traffic processing capacity of the push server before sending the message push task to the push server, by applying the changes in the total message traffic and expected push time included in the message push task, and sending the message traffic to the message queue of the push server according to the determined push rate.

[0160] As for the above-mentioned server embodiment, since it is basically similar to the method embodiment, the description is relatively simple, and the relevant parts can be referred to the partial description of the method embodiment.

[0161] The present application also provides an electronic device, such as Figure 9 As shown, it includes a processor 301, a communication interface 302, a memory 303 and a communication bus 304, wherein the processor 301, the communication interface 302, and the memory 303 communicate with each other through the communication bus 304.

[0162] Memory 303, for storing computer programs;

[0163] The processor 301 is configured to implement any of the steps of the above-mentioned message pushing method when executing the program stored in the memory 303 .

[0164] The communication bus mentioned in the terminal can be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus. This communication bus can be divided into an address bus, a data bus, a control bus, etc. For ease of illustration, only one thick line is used in the figure, but this does not mean that there is only one bus or only one type of bus.

[0165] The communication interface is used for communication between the above terminal and other devices.

[0166] The memory may include random access memory (RAM) or non-volatile memory, such as at least one disk storage. Alternatively, the memory may be at least one storage device located away from the processor.

[0167] The above-mentioned processor can be a general-purpose processor, including a central processing unit (CPU), a network processor (NP), etc.; it can also be a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA) or other programmable logic devices, discrete gate or transistor logic devices, and discrete hardware components.

[0168] In another embodiment provided by the present application, a computer-readable storage medium is further provided, in which instructions are stored. When the computer-readable storage medium is executed on a computer, the computer executes the message push method described in any one of the above embodiments.

[0169] In another embodiment provided by the present application, a computer program product including instructions is also provided, which, when executed on a computer, enables the computer to execute the message pushing method described in any one of the above embodiments.

[0170] In the above embodiments, it can be implemented in whole or in part by software, hardware, firmware or any combination thereof. When software is used for implementation, it can be implemented in whole or in part in the form of a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, the process or function described in the embodiment of the present application is generated in whole or in part. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another computer-readable storage medium. For example, the computer instructions can be transmitted from a website, computer, server or data center to another website, computer, server or data center via a wired (e.g., coaxial cable, optical fiber, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) method. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that includes one or more available media integrations. The available medium can be a magnetic medium (e.g., a floppy disk, a hard disk, a tape), an optical medium (e.g., a DVD), or a semiconductor medium (e.g., a solid-state drive (SSD)).

[0171] It should be noted that, in this document, relational terms such as first and second, etc., are used only to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply the existence of any such actual relationship or order between these entities or operations. Moreover, the terms "comprises," "comprising," or any other variants thereof are intended to cover non-exclusive inclusion, so that a process, method, article, or device comprising a series of elements includes not only those elements, but also other elements not explicitly listed, or elements inherent to such process, method, article, or device. In the absence of further limitations, an element defined by the phrase "comprising a ..." does not exclude the presence of other identical elements in the process, method, article, or device comprising the element.

[0172] Each embodiment in this specification is described in a related manner. Similar parts between the various embodiments can be referred to in conjunction with each other. Each embodiment focuses on the differences between the other embodiments. In particular, the system embodiment is generally similar to the method embodiment, so the description is relatively simple. For related parts, refer to the description of the method embodiment.

[0173] The above description is only a preferred embodiment of the present application and is not intended to limit the scope of protection of the present application. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the present application are included in the scope of protection of the present application.

Claims

1. A message push method, characterized in that: The method comprises: In response to a received message push task, obtaining the traffic processing capacity of the push server based on historical push data, wherein the message push task includes at least: total message traffic and expected push time; Obtaining the number of servers that can carry the total message traffic within the expected push time based on the traffic processing capacity; Obtaining a push rate for each push server based on the total message traffic, the expected push duration, and the number of servers, wherein the push rate is the ratio of the time-sharing traffic and the duration corresponding to any time-sharing time period, and the variance between the time-sharing traffic is less than a variance threshold. The time-sharing time periods are obtained by dividing the expected push duration, the time-sharing traffic corresponding to the time-sharing time periods is obtained by evenly dividing the message traffic into each time-sharing time period, and the message traffic is obtained by dividing the total message traffic by the number of servers. Adding the total message traffic to a message queue based on the push rate, and performing peak shaving and valley filling on the message queue, wherein the message queue is used to send message traffic to the push server at the push rate, so that each push server executes the message push task at the push rate; The historical push data includes at least: the historical expected push time and the historical actual push time of the push server when it last executed the message push task; The method of obtaining the traffic processing capacity of the push server based on historical push data includes: Comparing the historical expected push time with the historical actual push time to obtain a time comparison result; When the historical actual push time is greater than the historical expected push time, or the historical actual push time is less than the difference between the historical expected push time and the push time threshold, it is confirmed that the time comparison result meets the adjustment conditions, and the traffic processing capacity of the push server is adjusted according to the time comparison result, where the traffic processing capacity is used to characterize the traffic processing volume of the push server per unit time.

2. The method according to claim 1, characterized in that The adjusting the traffic processing capacity of the push server according to the time comparison result includes: Calculate the time ratio between the historical expected push time and the historical actual push time; The product of the time ratio and the traffic processing capacity of the push server is rounded up to an integer to obtain the adjusted traffic processing capacity.

3. The method according to claim 1, characterized in that The acquiring of the push rate of each push server based on the total message traffic, the expected push time, and the number of servers includes: Dividing the total message flow according to the number of servers to obtain the message flow distribution of each push server; Based on the ratio of the message flow rate to the expected push time, the push rate of each push server is obtained.

4. The method according to claim 3, characterized in that The acquiring the push rate of each push server based on the ratio of the message split flow rate to the expected push time includes: Dividing the expected push time into multiple time periods; Evenly distribute the message traffic to each time-sharing time period to obtain the time-sharing traffic corresponding to each time-sharing time period; When the variance between each of the time-sharing flows is less than the variance threshold, the ratio between the time-sharing flow and the duration corresponding to any of the time-sharing time periods is used as the push rate.

5. The method according to claim 1, wherein The obtaining, based on the traffic processing capability, the number of servers that can carry the total message traffic within the expected push time includes: Obtaining, according to the traffic processing capability of the push server, the processable traffic of the push server within the expected push time; Based on the ratio of the total message traffic to the processable traffic, the number of servers that can bear the total message traffic within the expected push time is determined.

6. A message push device, characterized in that: The device comprises: an acquisition module, configured to acquire the traffic processing capacity of the push server based on historical push data in response to a received message push task, wherein the message push task includes at least: total message traffic and expected push time; An adjustment module, configured to obtain, based on the traffic processing capability, the number of servers that can carry the total message traffic within the expected push time; a push module configured to obtain a push rate for each push server based on the total message traffic, the expected push duration, and the number of servers, wherein the push rate is the ratio of the time-sharing traffic to the duration corresponding to any time-sharing time period, the variance between the time-sharing traffic is less than a variance threshold, the time-sharing time period is obtained by dividing the expected push duration, the time-sharing traffic corresponding to the time-sharing time period is obtained by evenly dividing the message traffic into each time-sharing time period, and the message traffic is obtained by dividing the total message traffic according to the number of servers; Adding the total message traffic to a message queue based on the push rate, and performing peak shaving and valley filling on the message queue, wherein the message queue is used to send message traffic to the push server at the push rate, so that each push server executes the message push task at the push rate; The historical push data includes at least: the historical expected push time and the historical actual push time of the push server when it last executed the message push task; The acquisition module 201 is further configured to: Comparing the historical expected push time with the historical actual push time to obtain a time comparison result; When the historical actual push time is greater than the historical expected push time, or the historical actual push time is less than the difference between the historical expected push time and the push time threshold, it is confirmed that the time comparison result meets the adjustment conditions, and the traffic processing capacity of the push server is adjusted according to the time comparison result, where the traffic processing capacity is used to characterize the traffic processing volume of the push server per unit time.

7. An electronic device, characterized in that: The method comprises a memory, a processor and a computer program stored in the memory and executable on the processor, wherein the processor implements the message push method according to any one of claims 1 to 5 when executing the computer program.

8. A computer-readable storage medium, characterized in that The computer-readable storage medium stores a computer program, and when the computer program is executed by a processor, the message pushing method according to any one of claims 1 to 5 is implemented.

Images