Message push system, method, management server and storage medium

By decoupling the management server and work server in the message push system and splitting the tasks into independent subtasks, the existing system's shortcomings in task execution progress control and self-repair capabilities are solved, and the efficiency of message push and the stability of the system are improved.

CN119766769APending Publication Date: 2025-04-04MICRO INSURANCE AGENCY LTD
View PDF 0 Cites 0 Cited by

Patent Information

Application Number
CN202510159388.8
Authority / Receiving Office
CN · China
Patent Type
Applications(China)
Current Assignee / Owner
Filing Date
2025-02-13
Publication Date
2025-04-04

AI Technical Summary

Technical Problem

The existing message push system has shortcomings in task execution progress control, and the inability to effectively allocate resources leads to inefficient task execution or task accumulation, and lacks self-repair ability when the server is down, resulting in interruption of message push tasks.

Method used

By decoupling the management server and the work server, it runs in multiple independent subtasks on the work server. The management server splits the message push task into several subtasks and stores the subtask information in the database. The work server obtains subtask information from the database and executes it.

Benefits of technology

Improve the efficiency of message push and the stability of the system, ensuring that each subtask does not interfere with each other, and because each subtask runs independently, the failure of one subtask will not affect the normal operation of other processes.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN119766769A_ABST
    Figure CN119766769A_ABST
Patent Text Reader

Abstract

The present application relates to the field of communication technology, and discloses a message push system, method, management server and storage medium. The message push task is split into several subtasks through the management server, wherein each subtask corresponds to a working server; the subtask information corresponding to the subtask is stored in a database; the subtask information is then obtained from the database through the working server, and the message is pushed to the receiving end according to the subtask information. The present application can decouple the management server and the working server, and run in the form of multiple independent subtasks on the working server, thereby improving the efficiency of message push. At the same time, each subtask will not interfere with each other, and the normal operation of other processes will not be affected by the failure of a subtask, thereby improving the stability of the message push system.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] The embodiments of the present application relate to the field of communication technology, and in particular to a message push system, method, management server and storage medium. Background Art

[0002] Push Notification is a technology that actively sends information to users through a specific platform. It is widely used in various mobile applications such as social media, news applications, and e-commerce platforms. Push notifications allow operators to actively push messages to users' mobile devices through their own products or third-party tools. The implementation principles of push notifications mainly include polling (Pull), SMS (Push) and persistent connection (Push). Among them, the persistent connection method is the most commonly used method in modern push notification services. It establishes a long-term connection between the client and the server to achieve the timeliness and real-time nature of the message.

[0003] At present, the existing message push system has deficiencies in the control of task execution progress. Specifically, most message push systems do not fully consider the fine control of task execution progress when they are designed. When faced with a large number of push tasks, the existing message push system cannot effectively allocate resources, resulting in low task execution efficiency or task accumulation, which in turn leads to low efficiency of message push. In addition, the existing message push system does not have the ability to self-repair when the server goes down. For example, when a working server fails or goes down, the system cannot automatically restore the push task, resulting in the interruption of the entire message push task. Summary of the invention

[0004] The embodiments of the present application provide a message push system, method, management server and storage medium. By decoupling the management server and the working server, the message push efficiency is improved by running multiple independent subtasks on the working server. At the same time, each subtask will not interfere with each other, and the normal operation of other processes will not be affected by the failure of a subtask, thereby improving the stability of the message push system.

[0005] The embodiments of the present application provide the following technical solutions:

[0006] In a first aspect, an embodiment of the present application provides a message push system, the system comprising:

[0007] Front-end module, communication connection management server, front-end module is used to create message push tasks;

[0008] The management server is respectively connected to the front-end module and the working server in communication, and is used to split the message push task into a plurality of subtasks, wherein each subtask corresponds to a working server; and store the subtask information corresponding to the subtask in the database, wherein the subtask information includes the message;

[0009] The working server is respectively connected to the management server and the receiving end for communication. The working server is used to obtain subtask information from the database and push messages to the receiving end according to the subtask information.

[0010] In some embodiments, the front-end module is further used to obtain a push speed set by a user;

[0011] The management server is specifically used to split the message push task into several subtasks according to the push speed set by the user, the number of users and the total push time, where the number of subtasks = the number of users / (the push speed set by the user*the total push time).

[0012] In some embodiments, the management server is also used to slice the subtasks to obtain task slices; assign a process to each task slice, and bind the task slice to the identification number corresponding to the process; and record the identification number corresponding to each process in the database.

[0013] In some embodiments, the subtask information includes task progress and task status;

[0014] The management server is also used to create a task progress management process, wherein the task progress management process is used to poll the task progress and task status in the database at fixed intervals; obtain the subtask with a task status of being executed through the task progress management process; obtain the IP address of the working server corresponding to the subtask with a task status of being executed from the database; obtain the current task progress and task status of the subtask through the IP address of the working server, and update the task progress and task status corresponding to the subtask in the database to the current task progress and task status of the subtask.

[0015] In some embodiments, the front-end module is further used to obtain a task suspension instruction and send the task suspension instruction to the management server;

[0016] The management server is also used to obtain subtask information corresponding to the task pause instruction from the database according to the task pause instruction; obtain the IP address of the working server that executes the subtask according to the subtask information; and send the task pause instruction to the working server according to the IP address;

[0017] The working server is further configured to send a task suspension signal to the process corresponding to the subtask after receiving the task suspension instruction, so as to interrupt the message push task.

[0018] In some embodiments, the front-end module is further used to obtain a task recovery instruction and send the task recovery instruction to the management server;

[0019] The management server is also used to obtain the subtask information corresponding to the task recovery instruction from the database according to the task recovery instruction; obtain the IP address of the working server that executes the subtask according to the subtask information; and send the task recovery instruction to the working server according to the IP address;

[0020] The working server is further used to send a task resumption signal to the process corresponding to the subtask after receiving the task resumption instruction, so as to resume the message push task.

[0021] In some embodiments, the front-end module is further used to obtain a task termination instruction and send the task termination instruction to the management server;

[0022] The management server is also used to obtain subtask information corresponding to the task termination instruction from the database according to the task termination instruction; obtain the IP address of the working server that executes the subtask according to the subtask information; and send the task termination instruction to the working server according to the IP address;

[0023] The working server is further configured to send a task termination signal to the process corresponding to the subtask after receiving the task termination instruction, so as to terminate the message push task.

[0024] In some embodiments, the working server includes a first working server and a second working server;

[0025] The management server is also used to query the first working server through the task progress management process, and determine whether the query is responded to by the first working server; if the query is not responded to by the first working server, the state of the first working server is changed to a downtime state; send a task allocation message to the second working server to allocate the subtask corresponding to the first working server to the second working server, wherein the second working server is an idle working server;

[0026] The second working server is used to receive a task assignment message, wherein the task assignment message includes subtask information and the execution progress of the subtask; create multiple processes corresponding to the subtask according to the task assignment message; and push the message to the receiving end through the process.

[0027] In a second aspect, an embodiment of the present application provides a message push method, which is applied to a management server, where the management server is connected to a working server in communication, and the method includes:

[0028] Get the message push task;

[0029] Split the message push task into several subtasks, where each subtask corresponds to a working server;

[0030] The subtask information corresponding to the subtask is stored in the database, so that the working server obtains the subtask information from the database and pushes the message to the receiving end according to the subtask information.

[0031] In a third aspect, an embodiment of the present application provides a management server, including:

[0032] at least one processor; and

[0033] a memory communicatively connected to at least one processor; wherein,

[0034] The memory stores instructions that can be executed by at least one processor, and the instructions are executed by at least one processor so that the at least one processor can execute the message pushing method as described in the second aspect.

[0035] In a fourth aspect, an embodiment of the present application provides a non-volatile computer-readable storage medium, which stores computer-executable instructions, and the computer-executable instructions are used to enable an electronic device to execute the message push method of the second aspect.

[0036] The beneficial effects of the implementation mode of the present application are as follows: Different from the prior art, the implementation mode of the present application provides a message push system, the system includes: a front-end module, a communication connection management server, the front-end module is used to create a message push task; a management server, which is respectively connected to the front-end module and the working server, and the management server is used to split the message push task into a number of subtasks, wherein each subtask corresponds to a working server; the subtask information corresponding to the subtask is stored in a database, wherein the subtask information includes a message; the working server, which is respectively connected to the management server and the receiving end, and the working server is used to obtain the subtask information from the database, and push the message to the receiving end according to the subtask information. By decoupling the management server and the working server, the working server is operated in the form of multiple independent subtasks, which improves the efficiency of message push. At the same time, each subtask will not interfere with each other, and the normal operation of other processes will not be affected by the failure of a subtask. The present application can improve the stability of the message push system. BRIEF DESCRIPTION OF THE DRAWINGS

[0037] One or more embodiments are exemplarily described by corresponding drawings, which do not constitute limitations on the embodiments. Elements with the same reference numerals in the drawings represent similar elements, and the figures in the drawings do not constitute proportional limitations unless otherwise stated.

[0038] Figure 1It is a structural diagram of a message push system provided in an embodiment of the present application;

[0039] Figure 2 This is a schematic diagram of interaction between a management server and a working server provided in an embodiment of the present application;

[0040] Figure 3 This is an interaction sequence diagram between a message push system front end and a message push system back end provided in an embodiment of the present application;

[0041] Figure 4 This is a timing diagram of interaction between a management server and a working server when a working server fails, provided in an embodiment of the present application;

[0042] Figure 5 It is a flowchart of a message push method provided in an embodiment of the present application;

[0043] Figure 6 It is a structural schematic diagram of an electronic device provided in an embodiment of the present application.

[0044] Description of Figure Numbers:

[0045] Label name Label name 10 Message push system 110 Front-end module 120 Management Server 130 Worker Server 60 Electronic devices 601 processor 602 Memory DETAILED DESCRIPTION

[0046] In order to facilitate the understanding of the present application, the present application is described in more detail below in conjunction with the accompanying drawings and specific embodiments. It should be noted that when an element is described as "fixed to" another element, it can be directly on the other element, or there can be one or more centered elements therebetween. When an element is described as "connected to" another element, it can be directly connected to the other element, or there can be one or more centered elements therebetween. The terms "vertical", "horizontal", "left", "right" and similar expressions used in this specification are for illustrative purposes only.

[0047] Unless otherwise defined, all technical and scientific terms used in this specification have the same meaning as those commonly understood by those skilled in the art to which this application belongs. The terms used in this specification and in the specification of this application are only for the purpose of describing specific embodiments and are not intended to limit this application. The term "and / or" used in this specification includes any and all combinations of one or more of the related listed items.

[0048] In the field of communication technology, push notifications are a technology that actively sends information to users through a specific platform. They are widely used in various mobile applications such as social media, news applications, and e-commerce platforms. They increase the frequency and activity of users, enhance their dependence on and love for products, and drive the usage rate of functional modules. Specifically, push notifications refer to active message pushes by operators to users' mobile devices through their own products or third-party tools. Users can see these push messages on the lock screen and notification bar of their mobile devices, and can directly wake up the APP and jump to the corresponding page by clicking.

[0049] The message push system supports the message sender to convey the message to the message receiver in real time and accurately through various device terminals (such as mobile phones, tablets, etc.). The system usually consists of three parts: the sender, the message service, and the receiver. Through efficient communication protocols and push mechanisms, the rapid transmission of information is achieved. The message push system plays an indispensable role in modern mobile applications and Internet services. It can help users obtain important information in a timely manner and improve user activity and application stickiness.

[0050] At present, the existing message push system has deficiencies in the control of task execution progress. Specifically, most message push systems do not fully consider the fine control of task execution progress when they are designed. When faced with a large number of push tasks, the existing message push system cannot effectively allocate resources, resulting in low task execution efficiency or task accumulation, which in turn leads to low efficiency of message push. In addition, the existing message push system does not have the ability to self-repair when the server goes down. For example, when a working server fails or goes down, the system cannot automatically restore the push task, resulting in the interruption of the entire message push task.

[0051] In response to the above-mentioned defects, the present application provides a message push system, which includes: a front-end module, which communicates and connects to a management server, and the front-end module is used to create a message push task; a management server, which communicates and connects to the front-end module and the working server respectively, and the management server is used to split the message push task into a number of subtasks, wherein each subtask corresponds to a working server; the subtask information corresponding to the subtask is stored in a database, wherein the subtask information includes a message; the working server, which communicates and connects to the management server and the receiving end respectively, and the working server is used to obtain the subtask information from the database, and push the message to the receiving end according to the subtask information.

[0052] The message push task is split into several subtasks through the management server, where each subtask corresponds to a working server; the subtask information corresponding to the subtask is stored in the database; the subtask information is then obtained from the database through the working server, and the message is pushed to the receiving end based on the subtask information. The present application can decouple the management server and the working server, and run in the form of multiple independent subtasks on the working server, thereby improving the efficiency of message push. At the same time, each subtask will not interfere with each other, and the normal operation of other processes will not be affected by the failure of a subtask. The present application can improve the stability of the message push system.

[0053] The technical solution of the present application is described in detail below in conjunction with the accompanying drawings:

[0054] See also Figure 1 , Figure 1 It is a structural diagram of a message push system provided in an embodiment of the present application;

[0055] like Figure 1 As shown, the message push system 10 includes: a front-end module 110, a management server 120 and a working server 130, wherein the front-end module 110 includes a web page or an application program, and it can be understood that the web page or the application program is applied on an electronic device, and the front-end module is connected to the management server 120 through a WebSocket protocol, wherein the electronic device can be a mobile electronic device or a non-mobile electronic device, wherein the mobile electronic device includes but is not limited to mobile phones, tablet computers, laptop computers, PDAs, vehicle-mounted electronic devices, wearable devices, ultra-mobile personal computers (ultra-mobile personal computers, UMPCs), netbooks or personal digital assistants (personal digital assistants, PDAs), etc., and the non-mobile electronic devices include but are not limited to servers, network attached storage (Network Attached Storage, NAS), personal computers (personal computers, PCs), televisions (television, TVs), etc.

[0056] The types of the management server 120 and the working server 130 include but are not limited to cloud servers, streaming media servers or CDN servers. The embodiment of the present application does not specifically limit the types of the management server and the working server. In actual applications, the application scenario may include multiple working servers. Figure 1In the example of a working server, the management server 120 and the working server 130 are connected through network communication, wherein the network includes a wired network and / or a wireless network. It is understood that the network includes wireless networks such as 2G, 3G, 4G, 5G, wireless LAN, Bluetooth, etc., and may also include wired networks such as serial cables and network cables.

[0057] In an embodiment of the present application, the front-end module 110 is used to create a message push task; specifically, the front-end module receives a message push request sent by a user, and creates a corresponding message push task based on the message push request. The message push task usually includes the message content to be pushed, the device identification information of the receiving end (such as the user device), and the time requirement for the push, etc., wherein the message includes but is not limited to WeChat template messages, App application notifications, etc., and the device identification information includes but is not limited to the device name, device model, device number, device status, etc.

[0058] In an embodiment of the present application, the management server 120 is used to split the message push task into a plurality of subtasks, wherein each subtask corresponds to a working server; the subtask information corresponding to the subtask is stored in a database, wherein the subtask information includes a message; specifically, the management server splits the message push task into a plurality of subtasks, and assigns different subtasks to different working servers, wherein each subtask corresponds to a working server, a configuration list is provided in the management server, the configuration list is used to record the IP address of the working server, the method of assigning subtasks includes obtaining the IP address of the working server from the configuration list, and assigning the subtask to the working server. The IP address of the working server is bound to the receiving end, and the IP address of the working server is written into the subtask information corresponding to the subtask. The working server is used to push messages to the receiving end according to the subtask information corresponding to each subtask. The management server stores the subtask information corresponding to the subtask in the database, so that the subsequent working server can read the subtask information from the database and execute the subtask. It can be understood that the message is the content pushed by the server, and the subtask information corresponding to the subtask is stored in the database, wherein the subtask information includes the message. Furthermore, taking the WeChat automatic renewal notification as an example, the subtask information also includes the project name, start and end time, fee, and deduction time subscribed by the user.

[0059] In an embodiment of the present application, the working server 130 is used to obtain subtask information from a database, and push messages to a receiving end based on the subtask information; specifically, after the management server stores the subtask information corresponding to each subtask in the database, the working server obtains the subtask information from the database, thereby executing the subtask based on the subtask information. It can be understood that the subtask information also includes user information, wherein the user information includes a user name and a user ID. For example, in the WeChat application scenario, the user information includes but is not limited to a WeChat nickname and a WeChat account (unique ID). The working server obtains the user information and the message to be pushed from the database, and pushes the message to the receiving end based on the user information. The working server is also used to write the IP address of the working server into the subtask information corresponding to the current subtask before executing the current subtask, so as to bind the IP address of the working server to the current subtask, so as to facilitate the subsequent management server to monitor the task progress of the subtask.

[0060] In an embodiment of the present application, the front-end module 110 is also used to obtain the push speed set by the user; specifically, the user sends a push request to the front-end module, wherein the push request includes the push speed set by the user, so that after receiving the push request, the front-end module can obtain the push speed set by the user, and send the push speed set by the user to the management server, so that the management server can split the message push task into several subtasks according to the push speed set by the user, the number of users and the total push time. It should be noted that the push speed set by the user is set by the user according to actual needs, and this application does not limit the specific value of the push speed.

[0061] In an embodiment of the present application, the management server 120 is specifically used to split the message push task into several subtasks according to the push speed set by the user, the number of users and the total push time, wherein the number of subtasks = the number of users / (the push speed set by the user*the total push time); specifically, after receiving the push speed set by the user sent by the front-end module, the management server splits the message push task into several subtasks according to the push speed set by the user. For example, assuming that the push speed set by the user, that is, the push speed of a single work process is 10000 / s, the number of users pushed is 10 million, and the operator hopes to complete the push within 100s, then the number of subtasks = 10 million / (10000 / s*100s), that is, the task is split into 10 subtasks, and the number of users of each subtask is 1 million.

[0062] In the embodiment of the present application, the management server 120 is also used to slice the subtasks to obtain task slices; assign a process to each task slice, and bind the task slice to the identification number corresponding to the process; record the identification number corresponding to each process in the database; specifically, the management server slices the subtasks to obtain a number of task slices. The main purpose of splitting the task slices is to utilize the multi-threading capability of the machine to start multiple processes to execute tasks concurrently. For example, if a management server wants to push 10,000 messages, then in order to improve the push efficiency, the management server will divide these messages into 1 in advance. 0 copies, 1,000 copies per copy, then each copy is a task slice, which is about to split a large subtask into multiple small parts (i.e. the slices of subtasks), each small part is executed independently, and finally the execution results are merged. It should be noted that the slice strategy of task slices includes vertical slices and horizontal slices, wherein vertical slices refer to dividing by the nature or function of subtasks, and horizontal slices refer to dividing by the data volume or execution order of subtasks. In some embodiments, subtasks can also be divided into multiple task slices according to task id, time, etc., and the present application does not limit the slice mode of subtasks. After obtaining several task slices, a process is assigned to each task slice, and the identification number corresponding to the task slice and the process is bound, and then the identification number corresponding to each process is recorded to the database, wherein the identification number corresponding to the process refers to a process identifier (Process ID). It is a unique number for identifying a running process. Each running process can be assigned a PID so that the operating system can identify and manage them. In a database environment, PID is usually associated with a session or connection, and is used to track and manage active processes in a database. Task slices are associated through PIDs. One process corresponds to one PID. PID is used to uniquely identify each task slice. In this way, each process can be correctly identified and managed. For example, in database operations, each database process that performs a specific operation will have a unique PID. Through this PID, you can track and monitor the process status, resource usage, and other information. You can also terminate or restart a specific database process through the PID.

[0063] In an embodiment of the present application, subtask information includes task progress and task status; the management server 120 is also used to create a task progress management process, wherein the task progress management process is used to poll the task progress and task status in the database at fixed intervals; through the task progress management process, obtain the subtask with a task status of being executed; obtain the IP address of the work server corresponding to the subtask with a task status of being executed from the database; obtain the current task progress and task status of the subtask through the IP address of the work server, and update the task progress and task status corresponding to the subtask in the database to the current task progress and task status of the subtask; specifically, a subtask is completed by multiple processes. In order to manage each process, the management server will create a task progress management process, wherein the task progress management process is used to poll the task progress and task status in the database at fixed intervals through a timer, wherein the fixed The time can be set according to actual needs, and this application does not limit this. For example, the fixed time is set to 1 minute; each subtask corresponds to a task status, where the task status includes executing. It can be understood that when the task status of a subtask is executing, it means that the working server is executing the subtask; the IP address of the working server corresponding to the subtask with a task status of executing is obtained from the database; after the management server obtains the IP address of the working server, communication is established with the working server through the IP address of the working server. For example, the management server sends a query request to the working server, asking the working server about the current progress and status of the subtask. The working server responds to this request and provides the management server with the latest progress and status information of the subtask, so that the management server obtains the current task progress and task status of the subtask, and updates the task progress and task status corresponding to the subtask in the database to the current task progress and task status of the subtask.

[0064] It is understandable that when the operator queries the task progress on the page of the front-end module, the execution details of the task can be directly found in the database, and the execution details include the execution status and execution progress of each subtask of the task.

[0065] In an embodiment of the present application, the present application also provides a task scheduling mechanism, wherein the task scheduling mechanism includes allocating tasks to work servers with low loads and scheduling tasks to work servers with high loads, wherein the load is positively correlated with the number of processes currently allocated to the work server.

[0066] Allocating tasks to work servers with low loads specifically includes: the management server periodically inquiring the work server about the number of processes currently being executed. If the number of processes currently being executed is less than a first number threshold, the management server will allocate processes to the work server so that the number of processes of the work server is greater than or equal to the first number threshold, wherein the first number threshold can be set according to actual needs, for example, the first number threshold is set to 10.

[0067] Scheduling tasks for work servers with high loads specifically includes: the management server periodically inquires the work server about the number of processes currently being executed and the number of processes currently not being executed by the work server. If the sum of the number of processes currently being executed by the work server and the number of processes currently not being executed by the work server is greater than a second quantity threshold, the processes currently not being executed by the work server are obtained, and a new work server is added, that is, the number of work servers is expanded, the processes currently not being executed by the work server are assigned to the newly added work server, and the newly added work server is notified to start working, so that the newly added work server obtains the subtask information corresponding to the process from the database and executes the subtask according to the subtask information, wherein the second quantity threshold can be set according to actual needs, for example, the second quantity threshold is set to 20, and for another example, assuming that a work server can start 10 processes to execute tasks when fully loaded, and the second quantity threshold is set to 80%*full load number, and the number of processes currently being executed is 9, then it can be considered that the machine load is 90%, and the expansion rule is triggered. It is understandable that since the IP associated with the task has been replaced with the IP of the newly added work server, the original work server with too high load will no longer be able to find the original subtask information through its own IP.

[0068] In some embodiments, the load of each working server can also be comprehensively judged by analyzing the hardware occupancy rate of CPU, memory, etc. This application does not limit how to judge the load quantity of the working server.

[0069] Please refer to Figure 2 , Figure 2 This is a schematic diagram of interaction between a management server and a working server provided in an embodiment of the present application;

[0070] like Figure 2As shown, the user uploads a file to the management server through the front-end module. After receiving the file uploaded by the user, the management server creates a message push task and performs task slicing on the message push task to split the message push task into three subtasks. At the same time, the management server writes the subtask information corresponding to the subtask into the database, and assigns the three subtasks to three working servers (working server A, working server B, and working server C) respectively. For example, the management server can split a file into three sub-files and create three sub-tasks, wherein one subtask corresponds to one sub-file and one working server corresponds to one subtask, that is, one working server is used to push one sub-file. The management server records the IP address of the working server assigned to each subtask into the database to realize the binding of the subtask and the working server. Specifically, the management server sends a start work request to the working server assigned to the subtask, and the working server responds to the request and starts trying to obtain the subtask information from the database. The management server is also used to perform task slicing on each subtask and assign a working process to each task slicing. For example, Figure 2 The management server divides each subtask into two task slices, and the two task slices correspond to two work processes. After the work server obtains the subtask information from the database, the subfile is pushed to the receiving end through the two work processes. For example, work server A pushes the subfile to the receiving end through work process 1 and work process 2, work server B pushes the subfile to the receiving end through work process 3 and work process 4, and work server C pushes the subfile to the receiving end through work process 5 and work process 6.

[0071] Since the management server directly distributes subtasks to the working server, the following problems will arise: a. Assume that the distribution and execution actions are asynchronous, that is, the management server distributes tasks once, and the working server executes asynchronously. When the working server is down, this part of the task will fail to be pushed, and other retry mechanisms will be required to ensure the execution of the task. b. Assume that the distribution and execution actions are synchronous, that is, the management server sends a push request to the working server, and the message push is considered successful only when the working server completes the execution and responds successfully. If the management server goes down, the entire system will be paralyzed. In large-scale and high-concurrency scenarios, the management server will bear a large load, and maintaining its high availability may bring more costs. Therefore, the present application proposes a mechanism to achieve decoupling of the management server and the working server, so that the management server and the working server only need to interact with the database most of the time, without relying on each other's availability, and the management server can directly read the real-time results of task allocation and execution from the database and display them to the operators.

[0072] Please refer to Figure 3 , Figure 3This is an interaction sequence diagram between a message push system front end and a message push system back end provided in an embodiment of the present application;

[0073] like Figure 3 As shown, Figure 3 In the article, the management server and the working server are collectively referred to as the back-end module. The message push task is specifically divided into four stages. The first stage is that the user initiates a message push request to the front-end module. The front-end module creates a message push task according to the message push request and sends the message push task to the back-end module so that the back-end module writes the new message push task into the database; the second stage is that the user edits the message content to be pushed. After the front-end module obtains the message content sent by the user, it sends the edited message to the back-end module. The back-end module updates the message content field corresponding to the message push task in the database; the third stage is that the user uploads user information. After the front-end module receives the user information uploaded by the user, it sends the edited message to the back-end module. The back-end module sends user information so that the back-end module updates the user information corresponding to the message push task in the database, wherein the user information includes the user name and the user ID. For example, in the WeChat application scenario, the user information includes but is not limited to the WeChat nickname and WeChat account (unique ID); the fourth stage is that the user starts the push task through the front-end module. After the back-end module receives the instruction to start the push task, the task status of the message push task in the database is set to being executed; it can be understood that the order of the second stage and the third stage can be swapped. For example, the third stage can be executed first, and then the second stage. This application does not limit the order of the second stage and the third stage.

[0074] In an embodiment of the present application, when a user queries the progress of a task on the front-end page, the execution details of the task can be directly found in the database, where the execution details of the task include the execution status and execution progress of each subtask of the task.

[0075] In an embodiment of the present application, the front-end module is also used to obtain a task pause instruction and send the task pause instruction to the management server; specifically, the user clicks the task pause button on the page of the front-end module to send the task pause instruction to the front-end module. After obtaining the task pause instruction issued by the user, the front-end module sends the task pause instruction to the management server.

[0076] In an embodiment of the present application, the management server is also used to obtain subtask information corresponding to the task pause instruction from the database according to the task pause instruction; obtain the IP address of the work server that executes the subtask according to the subtask information; and send the task pause instruction to the work server according to the IP address; specifically, the task pause instruction is used to suspend the message push task, and the task pause instruction includes task information, and the task information is used to determine the message push task that needs to be suspended. After receiving the task pause instruction sent by the front-end module, the management server determines the message push task that needs to be suspended, and obtains the subtask information corresponding to the message push task from the database, and then determines the work server that executes the subtask according to the IP address of the work server in the subtask information, and sends the task pause instruction to the work server according to the IP address.

[0077] In an embodiment of the present application, the working server is also used to send a task pause signal to the process corresponding to the subtask after receiving the task pause instruction to interrupt the message push task; specifically, the working server receives the task pause instruction sent by the management server, determines the multiple subtasks corresponding to the message push task, and then determines the PID of the process executing each subtask, and sends a task pause signal to the PIDs of the multiple processes corresponding to the multiple subtasks, so that the process pauses the subtask after receiving the task pause signal, thereby interrupting the message push task. It can be understood that when all the subtasks included in the message push task are suspended, the message push task can be interrupted, and the working server is also used to record the current progress of the message push task in the database, and set the task state of the message push task to the suspended state, so that after receiving the task resumption instruction later, the message push task can be continued to be executed according to the current progress of the message push task recorded in the database.

[0078] In an embodiment of the present application, the front-end module is also used to obtain task recovery instructions and send the task recovery instructions to the management server; specifically, the user clicks the task recovery button on the page of the front-end module to send the task recovery instructions to the front-end module. After obtaining the task recovery instructions issued by the user, the front-end module sends the task recovery instructions to the management server.

[0079] In an embodiment of the present application, the management server is also used to obtain subtask information corresponding to the task recovery instruction from the database according to the task recovery instruction; obtain the IP address of the work server that executes the subtask according to the subtask information; and issue the task recovery instruction to the work server according to the IP address; specifically, the task recovery instruction is used to resume the message push task that was previously suspended, and the task recovery instruction includes task information, which is used to determine the message push task that needs to be resumed. After receiving the task recovery instruction sent by the front-end module, the management server determines the message push task that needs to be resumed, and obtains the subtask information corresponding to the message push task from the database, and then determines the work server that executes the subtask according to the IP address of the work server in the subtask information, and issues the task recovery instruction to the work server according to the IP address.

[0080] In an embodiment of the present application, the work server is also used to send a task recovery signal to the process corresponding to the subtask after receiving the task recovery instruction to restore the message push task; specifically, the work server receives the task recovery instruction sent by the management server, determines the multiple subtasks corresponding to the message push task, and then determines the PID of the process that executes each subtask, and sends a task recovery signal to the PIDs of the multiple processes corresponding to the multiple subtasks, so that the process recovers the subtask after receiving the task recovery signal, and then continues to execute the message push task. It can be understood that when the subtasks included in the message push task are recovered, the message push task can be restored to the executing state. The work server is also used to obtain the current progress of the message push task in the database after obtaining the task recovery instruction, and set the task state of the message push task to the executing state, so that after receiving the task recovery instruction, the message push task can be continued to be executed according to the current progress of the message push task recorded in the database.

[0081] In an embodiment of the present application, the front-end module is also used to obtain a task termination instruction and send the task termination instruction to the management server; specifically, the user clicks a task termination button on the page of the front-end module to send a task termination instruction to the front-end module. After obtaining the task termination instruction issued by the user, the front-end module sends the task termination instruction to the management server.

[0082] In an embodiment of the present application, the management server is also used to obtain subtask information corresponding to the task termination instruction from the database according to the task termination instruction; obtain the IP address of the working server that executes the subtask according to the subtask information; and send the task termination instruction to the working server according to the IP address; specifically, the task termination instruction is used to terminate the message push task, that is, to stop the message push task. It can be understood that the task termination instruction is different from the task pause command. Once the message push task is terminated, the message push task can no longer be replied to through the task recovery instruction. The user is required to restart the message push task in the front-end module before the message push task can continue to be executed. The task termination instruction includes task information, and the task information is used to determine the message push task that needs to be terminated. After receiving the task termination instruction sent by the front-end module, the management server determines the message push task that needs to be terminated, and obtains the subtask information corresponding to the message push task from the database, and then determines the working server that executes the subtask according to the IP address of the working server in the subtask information, and sends the task termination instruction to the working server according to the IP address.

[0083] In an embodiment of the present application, the work server is also used to send a task termination signal to the process corresponding to the subtask after receiving the task termination instruction to terminate the message push task; specifically, the work server receives the task termination instruction sent by the management server, determines the multiple subtasks corresponding to the message push task, and then determines the PID of the process that executes each subtask, and sends a task termination signal to the PIDs of the multiple processes corresponding to the multiple subtasks, so that the process terminates the subtask after receiving the task termination signal, thereby terminating the message push task. It can be understood that when all the subtasks included in the message push task are terminated, the message push task can be terminated, and the work server is also used to record the current progress of the message push task in the database, and set the task state of the message push task to the terminated state.

[0084] In an embodiment of the present application, the working server includes a first working server and a second working server; the management server is also used to query the first working server through a task progress management process, and determine whether the query is responded to by the first working server; if the query is not responded to by the first working server, the state of the first working server is changed to a down state; a task assignment message is sent to the second working server to assign the subtask corresponding to the first working server to the second working server, wherein the second working server is an idle working server; specifically, in the process of executing the message push task, the working server may fail or crash. Assuming that there are two working servers, one named the first working server and the other named the second working server, the management server uses the task progress management process to query the first working server and determine whether the query is responded to by the first working server; if the query is not responded to by the first working server, the state of the first working server is changed to a down state; Process, inquires the first working server, and determines whether the inquiry is responded by the first working server. If the inquiry is not responded by the first working server, it is determined that the first server fails or crashes, and then the state of the first working server is modified to a crash state, and the subtask information is modified in the database to unbind the subtask information from the IP address of the first working server. The crash state is used to indicate that the first working server cannot currently execute the message push task, and the subtask being executed by the first working server needs to be assigned to other servers, wherein the other servers include a second working server, and the second working server is an idle working server. The management server sends a task assignment message to the second working server to assign the subtask corresponding to the first working server to the second working server.

[0085] In an embodiment of the present application, the second work server is used to receive a task assignment message, wherein the task assignment message includes subtask information and the execution progress of the subtask; based on the task assignment message, multiple processes corresponding to the subtask are created; and the message is pushed to the receiving end through the process; specifically, after receiving the task assignment message, the second work server obtains the subtask information and the execution progress of the subtask through the task assignment message, wherein the task assignment message includes the subtask information and the execution progress of the subtask, creates multiple processes corresponding to the subtask based on the subtask information, and based on the execution progress of the subtask recorded in the database, pushes the message to the receiving end through the newly created process. It can be understood that the second work server can continue to complete the message push task that was not completed by the first work server.

[0086] Please refer to Figure 4 , Figure 4 This is a timing diagram of interaction between a management server and a working server when a working server fails, provided in an embodiment of the present application;

[0087] like Figure 4As shown, the message push system includes a first working server, a second working server and a monitoring and alarm system. The task progress management process is a management process created by the management server. The task progress management process is used to poll the task information and task progress in the database at fixed intervals. The database is used to record task information and task progress.

[0088] First, the task progress management process queries the database for subtask information of tasks in execution at fixed intervals, and after obtaining the subtask information, parses the subtask information to find the first working server that executes the subtask.

[0089] Then, the task progress management process inquires about the execution status of the task from the first working server that executes the subtask. If the first working server returns the task execution status and task progress, it means that the inquiry is successful, and the task progress management process will update the task progress in the database according to the task progress returned by the first working server; if the first working server does not return the task execution status and task progress, it means that the inquiry has failed, and the first working server may have a fault or is in a downtime state. The task progress management process will send an alarm message to the monitoring and alarm system, and assign the unfinished subtask of the first working server to the second working server. It can be understood that after the task progress management process sends an alarm message to the monitoring and alarm system, the relevant personnel will perform fault repair on the first working server.

[0090] Finally, after the failure of the first working server is restored, the first working server will query the database for the subtask information of the previously unfinished subtask. If the first working server finds that the subtask has been assigned to the second working server, the first working server will automatically exit the process of the subtask. If the first working server finds that the subtask has not been assigned to the second working server, the first working server will continue to execute the subtask, that is, continue to push the message to the receiving end through the process of the subtask.

[0091] In an embodiment of the present application, a message push system is provided, which includes: a front-end module, a communication connection management server, the front-end module is used to create a message push task; a management server, which is respectively communication connected to the front-end module and the working server, the management server is used to split the message push task into several subtasks, wherein each subtask corresponds to a working server; the subtask information corresponding to the subtask is stored in a database, wherein the subtask information includes a message; the working server, which is respectively communication connected to the management server and the receiving end, the working server is used to obtain the subtask information from the database, and push the message to the receiving end according to the subtask information.

[0092] The message push task is split into several subtasks through the management server, where each subtask corresponds to a working server; the subtask information corresponding to the subtask is stored in the database; the subtask information is then obtained from the database through the working server, and the message is pushed to the receiving end based on the subtask information. The present application can decouple the management server and the working server, and run in the form of multiple independent subtasks on the working server, thereby improving the efficiency of message push. At the same time, each subtask will not interfere with each other, and the normal operation of other processes will not be affected by the failure of a subtask. The present application can improve the stability of the message push system.

[0093] See also Figure 5 , Figure 5 It is a flowchart of a message push method provided in an embodiment of the present application;

[0094] The message push method is applied to a management server. Specifically, the execution subject of the method is one or more processors of the management server.

[0095] like Figure 5 As shown, the message push method includes:

[0096] Step S501: Obtain message push tasks;

[0097] Specifically, after receiving the message push request initiated by the user, the front-end module creates a message push task, and the management server obtains the message push task created by the front-end module.

[0098] Step S502: Split the message push task into several subtasks;

[0099] Specifically, the management server splits the message push task into several subtasks, and assigns different subtasks to different work servers, where each subtask corresponds to a work server. A configuration list is set in the management server, and the configuration list is used to record the IP address of the work server. The method of assigning subtasks includes obtaining the IP address of the work server from the configuration list, binding the subtask with the IP address of the work server, and writing the IP address of the work server into the subtask information corresponding to the subtask. The work server is used to push messages to the receiving end according to the subtask information corresponding to each subtask.

[0100] Step S503: storing the subtask information corresponding to the subtask in a database, so that the working server obtains the subtask information from the database, and pushes the message to the receiving end according to the subtask information;

[0101] Specifically, the management server stores the subtask information corresponding to the subtask in the database, so that the subsequent work server can read the subtask information from the database and execute the subtask. It can be understood that the message is the content pushed by the server, and the subtask information corresponding to the subtask is stored in the database, where the subtask information includes the message. Furthermore, taking the WeChat automatic renewal notification as an example, the subtask information also includes the project name, start and end time, fee, and deduction time subscribed by the user. The subsequent work server obtains the subtask information from the database and pushes the message to the receiving end based on the subtask information.

[0102] In an embodiment of the present application, subtask information includes task progress and task status; the management server creates a task progress management process, wherein the task progress management process is used to poll the task progress and task status in the database at fixed intervals; through the task progress management process, obtain the subtask with a task status of being executed; obtain the IP address of the working server corresponding to the subtask with a task status of being executed from the database; through the IP address of the working server, obtain the current task progress and task status of the subtask, and update the task progress and task status corresponding to the subtask in the database to the current task progress and task status of the subtask; it can be understood that a subtask is completed by multiple processes. In order to manage each process, the management server will create a task progress management process, wherein the task progress management process is used to poll the task progress and task status in the database at fixed intervals through a timer, wherein the fixed time can be set according to actual needs, and the present application does not limit this. For example, the fixed time is set to 1 minute.

[0103] In an embodiment of the present application, the message push method further includes:

[0104] The message push task is split into several subtasks according to the push speed set by the user, the number of users and the total push time, wherein the number of subtasks = the number of users / (the push speed set by the user*the total push time); specifically, after receiving the push speed set by the user sent by the front-end module, the management server splits the message push task into several subtasks according to the push speed set by the user. For example, assuming that the push speed set by the user, that is, the push speed of a single work process is 10,000 / s, the number of users pushed is 10 million, and the operator hopes to complete the push within 100 seconds, then the number of subtasks = 10 million / (10,000 / s*100s), that is, the task is split into 10 subtasks, and the number of users of each subtask is 1 million.

[0105] The subtasks are sliced ​​to obtain task slices; a process is assigned to each task slice, and the task slice is bound to the identification number corresponding to the process; the identification number corresponding to each process is recorded in the database; specifically, the management server slices the subtask to obtain a number of task slices. The task slices are split mainly to utilize the multi-threading capability of the machine to start multiple processes to execute tasks concurrently. For example, a management server wants to push 10,000 messages. Then, in order to improve the push efficiency, the management server will divide these messages into 10 parts in advance, each with 1,000 messages. Each of these parts is a task slice, that is, a large subtask is split into multiple small parts (i.e., slices of subtasks), each of which is executed independently, and finally the execution results are merged. It should be noted that the slicing strategy of task slicing includes vertical slicing and horizontal slicing, wherein vertical slicing refers to the division according to the nature or function of the subtask, and horizontal slicing refers to the division according to the data volume or execution order of the subtask. In some embodiments, the subtask can also be divided into multiple task slices according to task id, time, etc. The present application does not limit the slicing method of the subtask. After obtaining several task slices, a process is assigned to each task slice, and the task slice is bound to the identification number corresponding to the process, and then the identification number corresponding to each process is recorded in the database, where the identification number corresponding to the process refers to the process identifier (Process ID). It is a unique number used to identify the running process. Each running process is assigned a PID so that the operating system can identify and manage them. In a database environment, PID is usually associated with a session or connection to track and manage active processes in the database. Task slices are associated through PIDs, one process corresponds to one PID, and PID is a unique identifier used to represent each task slice. In this way, it can be ensured that each process can be correctly identified and managed. For example, in database operations, each database process that performs a specific operation will have a unique PID. Through this PID, the status of the process, resource usage and other information can be tracked and monitored, and a specific database process can also be terminated or restarted through the PID.

[0106] Create a task progress management process, where the task progress management process is used to poll the task progress and task status in the database at fixed intervals; obtain the subtask with a task status of being executed through the task progress management process; obtain the IP address of the working server corresponding to the subtask with a task status of being executed from the database; obtain the current task progress and task status of the subtask through the IP address of the working server, and update the task progress and task status corresponding to the subtask in the database to the current task progress and task status of the subtask. A subtask is completed by multiple processes. In order to manage each process, the management server will create a task progress management process, wherein the task progress management process is used to poll the task progress and task status in the database at fixed intervals through a timer, wherein the fixed time can be set according to actual needs, and the present application does not limit this. For example, the fixed time is set to 1 minute; each subtask corresponds to a task status, wherein the task status includes being executed. It can be understood that when the task status of a subtask is being executed, it indicates that the working server is executing the subtask; the IP address of the working server corresponding to the subtask with the task status being executed is obtained from the database; after the IP address of the working server of the management server is obtained, communication is established with the working server through the IP address of the working server, for example, the management server sends a query request to the working server, inquiring the working server about the current progress and status of the subtask, and the working server responds to this request and provides the management server with the latest progress and status information of the subtask, so that the management server obtains the current task progress and task status of the subtask, and updates the task progress and task status corresponding to the subtask in the database to the current task progress and task status of the subtask.

[0107] In an embodiment of the present application, the management server is also used to execute task pause instructions, task resume instructions, and task termination instructions issued by the user. For example, according to the task pause instruction, the subtask information corresponding to the task pause instruction is obtained from the database; according to the subtask information, the IP address of the work server that executes the subtask is obtained; according to the IP address, the task pause instruction is issued to the work server; or, according to the task resume instruction, the subtask information corresponding to the task resume instruction is obtained from the database; according to the subtask information, the IP address of the work server that executes the subtask is obtained; according to the IP address, the task resume instruction is issued to the work server; or, according to the task termination instruction, the subtask information corresponding to the task termination instruction is obtained from the database; according to the subtask information, the IP address of the work server that executes the subtask is obtained; according to the IP address, the task termination instruction is issued to the work server.

[0108] In some embodiments, the work server includes a first work server and a second work server; the message push method also includes: through the task progress management process, querying the first work server, and determining whether the query is responded to by the first work server; if the query is not responded to by the first work server, the state of the first work server is changed to a downtime state; sending a task assignment message to the second work server to assign the subtask corresponding to the first work server to the second work server, wherein the second work server is an idle work server.

[0109] In an embodiment of the present application, the present application embodiment provides a message push method, which is applied to a message push system, and the message push method includes: obtaining a message push task; splitting the message push task into a plurality of subtasks, wherein each subtask corresponds to a working server; storing the subtask information corresponding to the subtask in a database, so that the working server obtains the subtask information from the database, and pushes the message to the receiving end according to the subtask information. By decoupling the management server and the working server, the working server is operated in a manner of multiple independent subtasks, which improves the efficiency of message push. At the same time, each subtask will not interfere with each other, and the normal operation of other processes will not be affected by the failure of a subtask. The present application can improve the stability of the message push system.

[0110] Please refer to Figure 6 , Figure 6 A schematic diagram of the structure of a management server provided in an embodiment of the present application;

[0111] like Figure 6 As shown, the management server 60 includes one or more processors 601 and a memory 602. Figure 6 A processor 601 is taken as an example.

[0112] The processor 601 and the memory 602 may be connected via a bus or other means. Figure 6 The example of connecting through bus is taken in the following.

[0113] Processor 601 is used to provide computing and control capabilities to control the management server to perform corresponding tasks, for example, to control the management server to perform the above Figure 5 The message push method includes: obtaining a message push task; splitting the message push task into a plurality of subtasks, wherein each subtask corresponds to a working server; storing subtask information corresponding to the subtask in a database, so that the working server obtains the subtask information from the database, and pushes the message to the receiving end according to the subtask information.

[0114] By decoupling the management server and the working server, the working server is run in a manner of multiple independent subtasks, which improves the efficiency of message push. At the same time, each subtask will not interfere with each other, and the failure of a subtask will not affect the normal operation of other processes, thereby improving the stability of the message push system.

[0115] The processor 601 may be a general-purpose processor, including a central processing unit (CPU), a network processor (NP), a hardware chip or any combination thereof; it may also be a digital signal processor (DSP), an application specific integrated circuit (ASIC), a programmable logic device (PLD) or a combination thereof. The above-mentioned PLD may be a complex programmable logic device (CPLD), a field-programmable gate array (FPGA), a generic array logic (GAL) or any combination thereof.

[0116] The memory 602, as a non-transient computer-readable storage medium, can be used to store non-transient software programs, non-transient computer executable programs and modules, such as program instructions / modules corresponding to the message push method in the embodiment of the present application. The processor 601 can implement the message push method in any of the above method embodiments by running the non-transient software programs, instructions and modules stored in the memory 602. Specifically, the memory 602 may include a volatile memory (volatile memory, VM), such as a random access memory (random access memory, RAM); the memory 602 may also include a non-volatile memory (non-volatile memory, NVM), such as a read-only memory (read-only memory, ROM), a flash memory (flash memory), a hard disk drive (hard disk drive, HDD) or a solid-state drive (solid-state drive, SSD) or other non-transient solid-state storage devices; the memory 602 may also include a combination of the above types of memories.

[0117] The memory 602 may include a high-speed random access memory, and may also include a non-volatile memory, such as at least one disk storage device, a flash memory device, or other non-volatile solid-state storage devices. In some embodiments, the memory 602 may optionally include a memory remotely arranged relative to the processor 601, and these remote memories may be connected to the processor 601 via a network. Examples of the above-mentioned network include, but are not limited to, the Internet, an intranet, a local area network, a mobile communication network, and combinations thereof.

[0118] One or more modules are stored in the memory 602, and when executed by one or more processors 601, the message push method in any of the above method embodiments is executed, for example, the message push method described above is executed. Figure 5 The steps shown.

[0119] In the embodiment of the present application, the management server 60 may also have components such as a wired or wireless network interface, a keyboard, and an input / output interface for input and output. The management server 60 may also include other components for implementing device functions, which will not be described in detail here.

[0120] The embodiment of the present application also provides a non-volatile computer-readable storage medium, such as a memory including a program code, and the program code can be executed by a processor to complete the message push method in the above embodiment. For example, the non-volatile computer-readable storage medium can be a read-only memory (ROM), a random access memory (RAM), a compact disc read-only memory (CDROM), a magnetic tape, a floppy disk, and an optical data storage device.

[0121] The embodiment of the present application also provides a computer program product, which includes one or more program codes, and the program codes are stored in a non-volatile computer-readable storage medium. The processor of the electronic device reads the program code from the non-volatile computer-readable storage medium, and the processor executes the program code to complete the method steps of the message push method provided in the above embodiment.

[0122] A person skilled in the art will appreciate that all or part of the steps for implementing the above embodiments may be accomplished by hardware or by hardware associated with a program code, and the program may be stored in a computer-readable storage medium, and the above-mentioned storage medium may be a read-only memory, a disk or an optical disk, etc.

[0123] Through the description of the above implementation methods, a person of ordinary skill in the art can clearly understand that each implementation method can be implemented by means of software plus a general hardware platform, and of course, can also be implemented by hardware. A person of ordinary skill in the art can understand that all or part of the processes in the above-mentioned embodiment method can be completed by instructing the relevant hardware through a computer program, and the program can be stored in a non-volatile computer-readable storage medium. When the program is executed, it can include the processes of the embodiments of the above-mentioned methods. Among them, the non-volatile computer-readable storage medium can be a disk, an optical disk, a read-only memory (ROM) or a random access memory (RAM), etc.

[0124] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present application, rather than to limit them. Under the concept of the present application, the technical features in the above embodiments or different embodiments can also be combined, the steps can be implemented in any order, and there are many other changes in different aspects of the present application as mentioned above, which are not provided in detail for the sake of simplicity. Although the present application has been described in detail with reference to the aforementioned embodiments, a person of ordinary skill in the art should understand that the technical solutions described in the aforementioned embodiments can still be modified, or some of the technical features can be replaced by equivalents. These modifications or replacements do not deviate the essence of the corresponding technical solutions from the scope of the technical solutions of the embodiments of the present application.

Claims

1. A message push system, characterized in that: The system comprises: A front-end module, a communication connection management server, wherein the front-end module is used to create a message push task; A management server, which is respectively connected to the front-end module and the working server in communication, and is used to split the message push task into a plurality of subtasks, wherein each subtask corresponds to a working server; and store the subtask information corresponding to the subtask in a database, wherein the subtask information includes a message; The working server is respectively connected to the management server and the receiving end for communication. The working server is used to obtain subtask information from the database and push a message to the receiving end according to the subtask information.

2. The system according to claim 1, characterized in that The front-end module is also used to obtain the push speed set by the user; The management server is specifically used to split the message push task into a number of subtasks according to the push speed set by the user, the number of users and the total push duration, wherein the number of subtasks = the number of users / (the push speed set by the user*the total push duration).

3. The system according to claim 1, characterized in that The management server is also used to slice the subtask to obtain task slices; assign a process to each task slice, and bind the task slice to an identification number corresponding to the process; The identification number corresponding to each process is recorded in the database.

4. The system according to claim 3, characterized in that The subtask information includes task progress and task status; The management server is also used to create a task progress management process, wherein the task progress management process is used to poll the task progress and task status in the database at fixed intervals; obtain the subtask with the task status of being executed through the task progress management process; obtain the IP address of the work server corresponding to the subtask with the task status of being executed from the database; obtain the current task progress and task status of the subtask through the IP address of the work server, and update the task progress and task status corresponding to the subtask in the database to the current task progress and task status of the subtask.

5. The system according to claim 4, characterized in that The front-end module is also used to obtain a task suspension instruction and send the task suspension instruction to the management server; The management server is further configured to obtain, from the database, subtask information corresponding to the task pause instruction according to the task pause instruction; obtain, according to the subtask information, an IP address of a work server executing the subtask; and issue the task pause instruction to the work server according to the IP address; The working server is further configured to send a task suspension signal to the process corresponding to the subtask after receiving the task suspension instruction, so as to interrupt the message push task.

6. The system according to claim 5, characterized in that The front-end module is also used to obtain a task recovery instruction and send the task recovery instruction to the management server; The management server is further used to obtain subtask information corresponding to the task recovery instruction from the database according to the task recovery instruction; obtain the IP address of the working server executing the subtask according to the subtask information; and send the task recovery instruction to the working server according to the IP address; The working server is further configured to, after receiving the task resumption instruction, send a task resumption signal to the process corresponding to the subtask to resume the message push task.

7. The system according to claim 5, characterized in that The front-end module is also used to obtain a task termination instruction and send the task termination instruction to the management server; The management server is further used to obtain subtask information corresponding to the task termination instruction from the database according to the task termination instruction; obtain the IP address of the work server executing the subtask according to the subtask information; and send the task termination instruction to the work server according to the IP address; The working server is further configured to send a task termination signal to the process corresponding to the subtask after receiving the task termination instruction, so as to terminate the message push task.

8. The system according to claim 4, characterized in that The working server includes a first working server and a second working server; The management server is also used to query the first work server through the task progress management process, and determine whether the query is responded to by the first work server; if the query is not responded to by the first work server, the state of the first work server is changed to a downtime state; send a task assignment message to the second work server to assign the subtask corresponding to the first work server to the second work server, wherein the second work server is an idle work server; The second working server is used to receive the task assignment message, wherein the task assignment message includes subtask information and the execution progress of the subtask; create multiple processes corresponding to the subtask according to the task assignment message; and push the message to the receiving end through the process.

9. A message push method, characterized in that: Applied to a management server, the management server being communicatively connected to a working server, the method comprising: Get the message push task; Splitting the message push task into several subtasks, wherein each subtask corresponds to a working server; The subtask information corresponding to the subtask is stored in a database, so that the working server obtains the subtask information from the database, and pushes the message to the receiving end according to the subtask information.

10. A management server, characterized in that: include: at least one processor; as well as, a memory communicatively connected to the at least one processor; wherein, The memory stores instructions that can be executed by the at least one processor, and the instructions are executed by the at least one processor so that the at least one processor can execute the message pushing method as claimed in claim 9.

11. A non-volatile computer-readable storage medium, characterized in that: The non-volatile computer storage medium stores a computer program or instruction, and when the computer program or instruction is executed, the message push method according to claim 9 is implemented.