Message push method, system, service gateway and storage medium

Abstract

The embodiments of this specification provide a message push method, system, service gateway, and storage medium. The method includes: receiving a message to be pushed; obtaining health check data for each edge gateway; selecting an edge gateway whose health meets preset requirements as a target edge gateway based on the health check data; and pushing the message to be pushed to the target edge gateway. This solution can improve service availability during message transmission and the success rate of message push while ensuring lightweight edge connectivity.

Description

Technical Field

[0001] The embodiments of this specification relate to the field of data processing technology, and in particular to a message push method, system, service gateway, and storage medium. Background Art

[0002] Currently, the service portion of communication gateways utilizes a protocol-data decoupling approach, resulting in a decoupled model between the protocol and service layers. This decoupling weakens the protocol layer's data processing, enhancing inbound traffic capacity to a certain extent. However, in the communication gateway field, due to the use of a Transmission Control Protocol (TCP) persistent connection between protocols, the service gateway corresponding to the service layer can only transmit service processing results to the edge gateway corresponding to the protocol layer via a directed Internet Protocol (IP) connection. Due to the complete decoupling of the protocol and service layers, service unavailability often occurs at the target edge gateway for receipt pushes. Furthermore, due to the service gateway's lack of monitoring of the edge gateway's load capacity, TCP connection congestion at the edge gateway due to excessive traffic can be a significant issue. This is undesirable for response messages requiring high timeliness, such as receipt messages. Ensuring high service availability during response message transmission and improving the success rate of response message pushes has become a pressing challenge.

[0003] The contents of the background technology section are merely technologies known to the public and do not necessarily represent the existing technologies in this field. Summary of the Invention

[0004] In view of this, the embodiments of this specification provide a message push method, system, service gateway and storage medium, which can improve the high service availability during message transmission and increase the success rate of message push while ensuring edge lightweight.

[0005] First, the embodiment of this specification provides a message push method, including:

[0006] Receive messages to be pushed;

[0007] Obtain health detection data of each edge gateway;

[0008] Based on the health detection data, select an edge gateway whose health meets preset requirements as a target edge gateway;

[0009] Push the message to be pushed to the target edge gateway.

[0010] Optionally, obtaining health detection data of each edge gateway includes obtaining at least one type of detection data of each edge gateway:

[0011] Heartbeat data of each edge gateway;

[0012] Data on the number of user connections corresponding to each edge gateway;

[0013] Traffic status data of each edge gateway.

[0014] Optionally, obtaining at least two types of detection data from each edge gateway;

[0015] The selecting, based on the health detection data, an edge gateway whose health meets preset requirements as a target edge gateway includes:

[0016] Based on the detection data of each type corresponding to each edge gateway and the preset health weight factor of the corresponding type, the health detection data of each edge gateway is obtained;

[0017] Select the edge gateway with the best health detection data as the target edge gateway.

[0018] Optionally, the health detection data of each edge gateway is obtained at preset time intervals.

[0019] Optionally, before pushing the message to be pushed to the target edge gateway, the method further includes:

[0020] Filter push messages according to preset scheduling filter conditions;

[0021] The filtered messages that meet the preset scheduling filter conditions are used as the current messages to be pushed.

[0022] Optionally, the filtering of the messages to be pushed according to a preset scheduling filtering condition includes:

[0023] Obtaining multiple types of attribute information of the message to be pushed;

[0024] Based on the attribute information of the multiple types of messages to be pushed and the priority weight factors corresponding to the attribute information of the corresponding types, the priorities of the messages to be pushed are obtained, and the messages are sorted in order of priority;

[0025] A preset number of to-be-pushed messages that meet a preset priority level are used as current to-be-pushed messages.

[0026] Optionally, the acquiring of multiple types of attribute information of the received message to be pushed includes:

[0027] Obtain the reception time information, type information and corresponding user priority information of the message to be pushed.

[0028] Optionally, after pushing the message to be pushed to the target edge gateway, the method further includes:

[0029] When a push exception occurs, the message to be pushed is processed according to the corresponding exception handling strategy.

[0030] Optionally, when a push exception occurs, the message to be pushed is processed according to a corresponding exception handling strategy, including at least one of the following:

[0031] When an abnormality is detected in the service corresponding to the message to be pushed, reconnect with the service, obtain the message to be pushed corresponding to the service, and push it to the corresponding target edge gateway;

[0032] When a user exception corresponding to the message to be pushed is detected, the message to be pushed is processed accordingly based on a preset user exception processing strategy.

[0033] Accordingly, the embodiment of this specification also provides a message push system, including:

[0034] A receiving unit, adapted to receive messages to be pushed;

[0035] a target edge gateway determining unit adapted to obtain health detection data of each edge gateway and, based on the health detection data, select an edge gateway whose health meets preset requirements as the target edge gateway;

[0036] The push unit is adapted to push the message to be pushed to the target edge gateway.

[0037] Optionally, the system further comprises:

[0038] The scheduling screening unit is adapted to screen the messages to be pushed according to preset scheduling screening conditions, and use the screened messages that meet the preset scheduling screening conditions as the current messages to be pushed.

[0039] Optionally, the system further comprises:

[0040] The exception push processing unit is adapted to process the message to be pushed according to a corresponding exception handling strategy when a push exception occurs.

[0041] Accordingly, an embodiment of this specification also provides a service gateway, including a memory and a processor, wherein the memory stores a computer program that can be run on the processor, wherein the processor executes the steps of the method described in any of the above embodiments when running the computer program.

[0042] Accordingly, an embodiment of this specification further provides a computer-readable storage medium on which a computer program is stored, wherein when the computer program is run, the steps of the method described in any of the aforementioned embodiments are executed.

[0043] The message push method of the embodiment of this specification is adopted, by obtaining the health detection data of each edge gateway, and based on the health detection data, selecting the edge gateway whose health meets the preset requirements as the target edge gateway, and pushing the message to be pushed to the target edge gateway. Among them, selecting the target edge gateway based on the health detection data can alleviate the TCP connection congestion problem and improve the stability of the message push service, thereby ensuring high service availability during message transmission and improving the success rate of message push; and since the entire process only requires each edge gateway to report the health detection data without the need for complex decision-making, it can take into account the lightweight requirements of the edge gateway and facilitate edge deployment and implementation.

[0044] Furthermore, by acquiring multiple types of detection data, such as heartbeat data from each edge gateway, corresponding user connection data, and traffic status data for each edge gateway, and then based on each type of detection data corresponding to each edge gateway and a preset health weight factor for that type, a more comprehensive and accurate health detection data for each edge gateway can be obtained. Therefore, the healthier edge gateway can be selected as the target edge gateway, thereby improving the stability of the message push service. Specifically, by adopting different push strategies for edge gateways with different numbers of user connections, it is possible to avoid putting pressure on the services of the corresponding edge gateways.

[0045] Furthermore, the health detection data of each edge gateway is obtained at preset time intervals, so that the obtained health detection data can more truly reflect the current health status of the corresponding edge gateway. Therefore, the target edge gateway selected based on the health detection data of each edge gateway dynamically obtained at preset time intervals has better reliability and stability, thereby further improving the reliability of message push.

[0046] Furthermore, before pushing the pending messages to the target edge gateway, the pending messages are screened according to preset scheduling screening conditions, and the selected messages that meet the preset scheduling screening conditions are used as the current pending messages. This ensures the orderly push of messages in the event of a traffic surge. In addition, scheduling screening can avoid storing all pending push messages that have not been pushed, thereby saving storage resources.

[0047] Furthermore, by obtaining the receiving time information, type information and corresponding user priority information of the message to be pushed, and based on the corresponding priority weight factor, the priority of the message to be pushed is obtained, and sorted in order of priority, a preset number of messages to be pushed that meet the preset priority level are used as the current messages to be pushed. From a large number of messages to be pushed, more important messages can be screened out as the current messages to be pushed and pushed to the target edge gateway, thereby improving the push efficiency of important messages and improving the overall user experience.

[0048] Furthermore, when a push exception occurs, the reliability of the message push service can be further improved by processing the message to be pushed according to the corresponding exception handling strategy.

[0049] Furthermore, when pushing exceptions, by distinguishing the exception types and adopting different processing strategies for service exceptions and user exceptions, when determining the corresponding service exception, by re-establishing a connection with the service, obtaining the corresponding message to be pushed for the service and pushing it to the corresponding target edge gateway, the timeliness guarantee required by the service level agreement for message push can be improved. BRIEF DESCRIPTION OF THE DRAWINGS

[0050] In order to more clearly illustrate the technical solutions of the embodiments of this specification, the following briefly introduces the drawings required for use in the embodiments of this specification or the description of the prior art. Obviously, the drawings described below are only some embodiments of this specification. For ordinary technicians in this field, other drawings can be obtained based on these drawings without any creative work.

[0051] Figure 1 A schematic diagram of a model architecture of a communication system is shown;

[0052] Figure 2 and Figure 3 Schematic diagrams showing two scenario examples of message push methods in the prior art are shown respectively;

[0053] Figure 4 A flow chart of a message push method according to an embodiment of the present specification is shown;

[0054] Figure 5 A flowchart of another message push method according to an embodiment of this specification is shown;

[0055] Figure 6 A flowchart of a scheduling screening method according to an embodiment of this specification is shown;

[0056] Figure 7 A schematic diagram showing an example scenario of a message push method in an embodiment of this specification is shown;

[0057] Figure 8 A schematic diagram of the structure of a message push system according to an embodiment of this specification is shown;

[0058] Figure 9 A schematic diagram of the structure of a service gateway in an embodiment of this specification is shown. DETAILED DESCRIPTION

[0059] As described in the Background section, the current communication gateway service component utilizes protocol and data decoupling, resulting in a decoupled access and service layer model. To help those skilled in the art better understand the technical challenges inherent in the prior art, the following detailed description of the model architecture for decoupling the protocol and service layers is provided with accompanying figures.

[0060] Reference Figure 1 The model architecture diagram of the communication system shown in the figure, wherein the communication system 10 includes multiple clients 11 and an edge gateway 12 and a service gateway 13 that have communication connections with the clients 11, wherein: the edge gateway 12 mainly completes the establishment of connection and data transmission with the client 11 through the protocol plug-in and the session management module, while the service gateway 13 is specifically responsible for business data processing and data conversion.

[0061] By decoupling the protocol layer and the service layer, the edge gateway 12 is weakened in processing data, which can enhance the edge gateway's ability to process ingress traffic to a certain extent. On the edge gateway side, since the TCP long connection is used between the protocols, the service gateway 13 can only transmit the service processing results to the edge gateway 12 through the directional IP method, such as Figure 1 The middle arrow 2 indicates.

[0062] However, in actual applications, it is often the case that the edge gateway (hereinafter referred to as the target edge gateway) to which messages (such as receipt messages) are pushed becomes unavailable. Since the protocol layer and the service layer are completely decoupled, and the service gateway 13 lacks perception of the edge gateway 12, it is easy to cause TCP congestion at the protocol layer due to excessive traffic. This is not desirable for messages with high timeliness guarantees (such as receipt messages).

[0063] In order to solve the TCP congestion problem that is prone to occur due to the complete decoupling of the protocol layer and the service layer and to improve the high service availability of message transmission, there are the following two solutions in the prior art.

[0064] Solution 1: Push messages based on static IP selection strategy. Figure 2In the schematic diagram of a scenario of a message push method in the prior art shown, the client 11 establishes a persistent connection with the service gateway 13 through an edge gateway in the edge gateway cluster E0, such as edge gateway E0-1, and stores the connection information of the persistent connection in the database DB0, which is referred to as persistent connection information LM0 for ease of description. After the service gateway 13 processes the service and data, the persistent connection information established by the client can be queried through the database DB0. The receipt message can be pushed to the specified target edge gateway by selecting an IP address to complete the push of the receipt message.

[0065] However, the inventors found through research that the long connection information stored in the database DB0 is static information, which cannot reflect the current load situation of the corresponding edge gateway. In the case of a surge in traffic, it is very easy to cause TCP congestion in the edge gateway cluster E0, affecting the push of receipt messages.

[0066] In addition, it adopts the same push strategy for all edge gateways. Some edge gateways may not be able to complete the processing of push messages in a short time, which may bring processing pressure to the edge gateways.

[0067] Solution 2: All edge gateways subscribe to receipt information uniformly, and match whether to push messages within the edge gateway cluster. Figure 3 The client 11 establishes a connection with the service gateway 13 through the edge gateway cluster E0 and can send requests to be processed to the service gateway 13. After performing business processing and data processing based on the request, the service gateway 13 can asynchronously send the processing results to the edge gateway cluster E0 through the receipt message middleware MQ. Matching processing is performed within the edge gateway cluster E012, and the matching edge gateway pushes the results corresponding to the client request established with it.

[0068] However, the inventors discovered that because all devices in edge gateway cluster E0 share the receipt message middleware MQ, all edge gateways in the cluster need to store it, which consumes a large amount of storage resources. Furthermore, the internal logic screening and matching performed by edge gateway cluster 12 causes the edge gateway cluster to overly focus on service-related logic, hindering the lightweight nature of edge gateways and increasing the difficulty of edge deployment.

[0069] In summary, it can be seen that the existing message push solutions are difficult to improve the high service availability during message transmission and the success rate of message push while ensuring the lightweight edge.

[0070] In response to the above problems, this specification provides corresponding solutions. First, an embodiment of this specification provides a message push method, which obtains the health detection data of each edge gateway, and based on the health detection data, selects an edge gateway whose health meets the preset requirements as the target edge gateway, and pushes the message to be pushed to the target edge gateway. Among them, selecting the target edge gateway based on the health detection data can alleviate the TCP connection congestion problem and improve the stability of the message push service, thereby ensuring high service availability during message transmission and improving the success rate of message push; and since the entire process only requires each edge gateway to report health detection data without the need for complex decision-making, it can take into account the lightweight requirements of the edge gateway and facilitate edge deployment and implementation.

[0071] In order to enable those skilled in the art to better understand the technical concepts, working principles and advantages of the embodiments of this specification and implement the technical solutions of the embodiments of this specification, the embodiments of this specification are described in detail below with reference to the accompanying drawings and in combination with specific application scenarios through some specific optional examples.

[0072] As a specific application scenario, after the service gateway completes the corresponding service data processing based on the client request, it can return the corresponding processing result, for example, it can return a receipt message to the client. Since the service gateway of the service layer cannot perceive the status of the edge gateway of the protocol layer after the protocol layer is decoupled from the service layer, the service gateway needs to push the message to the matching edge gateway first, and then the edge gateway can transmit the message to the corresponding client through a long connection. In a specific implementation, the client can be a web browser client, or a special application client, or a client electronic device that carries the corresponding application or is suitable for running the corresponding web page, such as a mobile phone terminal, a personal computer, a car-mounted electronic terminal, a smart home terminal or other Internet of Things terminals, etc. The specific client type is not limited in the embodiments of this specification. The user can obtain the corresponding service through the client.

[0073] Reference Figure 4 In some embodiments of the present specification, the service gateway can complete the message push by the following steps:

[0074] S11, receiving the message to be pushed.

[0075] In a specific implementation, the service gateway can be a service gateway or service gateway cluster in the cloud or core network. If it is a service gateway cluster, it can receive messages to be pushed from the central cloud cluster of the core network based on a preset load balancing strategy, such as receipt messages, reply messages, response messages, etc. The embodiments of this specification do not limit the specific content of the message, nor do they limit the specific type of the message.

[0076] S12, obtaining health detection data of each edge gateway.

[0077] In a specific implementation, a corresponding monitoring device can be set in the edge gateway cluster to monitor the health status of each edge gateway and report the corresponding health detection data, or each edge gateway can monitor its own health status and actively report its own health detection data.

[0078] The health status of each edge gateway refers to whether it is operating normally and providing normal services to users. In practice, to improve the reliability of message push services, the health detection data is suitable for reflecting the normal operation and processing capacity of the corresponding edge gateway, thereby avoiding TCP congestion caused by insufficient edge gateway processing power, which may lead to the delay of message transmission to the client.

[0079] In a specific implementation, the health detection data may include one or more types. As an optional example, it may include at least one type of detection data as follows:

[0080] Heartbeat data of each edge gateway;

[0081] Data on the number of user connections corresponding to each edge gateway;

[0082] Traffic status data of each edge gateway.

[0083] Heartbeat data is used to indicate whether the corresponding edge gateway is operating normally. For example, a heartbeat value of 1 indicates that the corresponding edge gateway is operating normally, while a heartbeat value of 0 indicates that the corresponding edge gateway is faulty or not processing the work. The number of user connections corresponding to an edge gateway reflects its current load, and the traffic status of each edge gateway can reflect its overall traffic status and whether congestion occurs.

[0084] Since the actual load capacity of each edge gateway may be different, combining its corresponding number of user connections and its traffic status data can more comprehensively reflect its overall health status.

[0085] In specific implementations, if a heartbeat exists on an edge gateway, its health status can be further determined by combining its corresponding number of user connections and its traffic status data.

[0086] In a specific implementation, the health detection data of each edge gateway can be obtained according to a preset time interval, so that the current health detection data of each edge gateway can be dynamically obtained.

[0087] S13: Based on the health detection data, select an edge gateway whose health meets preset requirements as a target edge gateway.

[0088] In a specific implementation, as described in step S12, one type of detection data can be obtained for each edge gateway, or multiple types of detection data can be obtained. If two or more types of detection data are obtained, the health detection data of each edge gateway can be obtained based on the detection data of each type corresponding to each edge gateway and the preset health weight factors of the corresponding types. As an optional example, the edge gateway with the best health detection data can be selected as the target edge gateway.

[0089] In a specific implementation, the most suitable edge gateway can be dynamically selected as the target edge gateway based on the current health detection data of each edge gateway obtained in real time.

[0090] In specific implementations, the edge gateway cluster formed by multiple edge gateways at the protocol layer can be deployed centrally or distributed. As an optional example, each edge gateway can be distributed and deployed close to its client area to achieve low latency in information exchange with the client and improve the user experience. In addition, to further enhance service reliability, multiple edge gateways can be set up in each area, or multiple edge gateways can be distributed for multiple clients in a certain area.

[0091] S14: Push the message to be pushed to the target edge gateway.

[0092] After the target edge gateway is selected in the synchronization step S13, the message to be pushed can be pushed to the target edge gateway, and the target edge gateway transmits it to the client device with which a long connection is established, and finally pushes the message to the client.

[0093] By adopting the above embodiment, by selecting the target edge gateway based on health detection data, the TCP connection congestion problem can be alleviated and the stability of the message push service can be improved, thereby ensuring high service availability during message transmission and improving the success rate of message push; and since the entire process only requires each edge gateway to report health detection data without the need for complex decision-making, it can take into account the lightweight requirements of the edge gateway and facilitate edge deployment and implementation.

[0094] By acquiring multiple types of detection data, including heartbeat data from each edge gateway, the corresponding number of user connections, and traffic status data from each edge gateway, and then based on each type of detection data corresponding to each edge gateway and the preset health weight factor of the corresponding type, we can more comprehensively and accurately obtain the health detection data of each edge gateway, thereby selecting the healthier target edge gateway, thereby improving the stability of the message push service. Specifically, by adopting different push strategies for edge gateways with different numbers of user connections, we can avoid putting pressure on the services of the corresponding edge gateways.

[0095] In addition, the health detection data of each edge gateway is obtained according to the preset time interval, so that the current health status of the corresponding edge gateway can be more realistically reflected. Therefore, the target edge gateway selected based on the health detection data of each edge gateway dynamically obtained according to the preset time interval has better reliability and stability, thereby further improving the reliability of message push.

[0096] In specific implementation, the above embodiment can be further expanded and optimized. The following is a detailed description using some specific examples and with reference to the accompanying drawings.

[0097] Reference Figure 5 The flowchart of the message push method shown in FIG. Figure 4 The difference of the push method shown is that, before step S14, it may further include step S15: filtering the messages to be pushed according to the preset scheduling screening conditions; and using the filtered messages that meet the preset scheduling screening conditions as the current messages to be pushed.

[0098] Before pushing the pending messages to the target edge gateway, the pending messages are screened according to preset scheduling screening conditions, and the selected messages that meet the preset scheduling screening conditions are used as the current pending messages. This ensures the orderly push of messages in the event of a traffic surge. In addition, scheduling screening can avoid storing all pending push messages that have not been pushed, thereby saving storage resources.

[0099] As an alternative example, see Figure 6 The flowchart of the scheduling screening method shown in the figure can be used to perform scheduling screening in the following ways:

[0100] S151: Acquire attribute information of multiple types of messages to be pushed.

[0101] As an optional example, the receiving time information, type information and corresponding user priority information of the message to be pushed may be obtained.

[0102] Among them, based on the receiving time information, the messages to be pushed can be sorted according to the receiving time, which can reflect the receiving sequence of the push messages. In the absence of other scheduling priority differences, the messages to be pushed can be scheduled entirely based on the sequence determined by the receiving time information. However, in actual applications, the inventors found that the messages to be pushed may be very different. In order to more effectively utilize processing resources and meet the SLA requirements of various messages as much as possible, different scheduling priorities can be set. For example, the type of the message itself may be different. It may be a verification code, a notification, or a display and promotion message that is strongly related to the service. Among them, the verification code has the highest timeliness requirement, the notification is second, and the display and promotion message has the lowest. Therefore, the corresponding priority can be set based on its timeliness requirement, for example: level 1, level 2, and level 3. For example, different users may also have different requirements for service reliability and timeliness. For example, the priority of corporate users is higher than that of ordinary users, and the priority of member users is higher than that of visitor users.

[0103] S152: Based on the attribute information of the multiple types of messages to be pushed and the priority weight factors corresponding to the attribute information of the corresponding types, the priorities of the messages to be pushed are obtained, and the messages are sorted in order of priority.

[0104] In a specific implementation, the priority weight factors of each attribute information may be the same or different, and may be determined based on the importance of each attribute information and in combination with experience and experimental data. The specific values ​​of each priority weight factor and the ratio between each weight factor are not limited in the embodiments of this specification.

[0105] S153: Counting the preset number of to-be-pushed messages that meet the preset priority level as current to-be-pushed messages.

[0106] Through the above solution, more important messages can be screened out from a large number of messages to be pushed and pushed to the target edge gateway as the current messages to be pushed, thereby improving the push efficiency of important messages and improving the overall user experience.

[0107] For example, there are currently 10,000 messages to be pushed. Through the above solution, the 1,000 messages with the highest priority can be screened out and pushed first, which can improve the push efficiency of important messages.

[0108] In the specific implementation, in order to further improve the reliability of the message push service, continue to refer to Figure 5 , step S16 may also be executed: when a push exception occurs, the message to be pushed is processed according to a corresponding exception handling strategy.

[0109] In practice, different handling strategies may be employed due to different reasons for push exceptions. For example, it may be due to a service exception or a user exception, where the user may be a client user or an edge gateway, i.e., the target edge gateway for the push message.

[0110] As an optional example, when an abnormality is detected in the service corresponding to the message to be pushed, a connection is re-established with the service, the message to be pushed corresponding to the service is obtained and pushed to the corresponding target edge gateway.

[0111] As another optional example, when a user exception corresponding to the message to be pushed is detected, the message to be pushed may be processed accordingly based on a preset user exception processing strategy.

[0112] In the implementation, considering that service anomalies may affect a large number of users, when a service anomaly is discovered, an immediate retransmission processing strategy can be adopted to ensure the SLA capability of the message.

[0113] For users, different exception handling strategies can be adopted based on, for example, message type, user priority corresponding to the message, user response speed, etc. Optionally, for users with higher user priority levels, or for receipt messages with high timeliness requirements, such as verification code messages, an immediate resend strategy can be adopted; while for users with lower user priority levels, or for notification messages with less timeliness requirements, the message can be pushed with a delay.

[0114] In order to enable those skilled in the art to better understand and implement, the following is an explanation in conjunction with a specific application scenario. Figure 7 In the scenario example diagram shown, after the client CL0 establishes a long connection with the edge gateway in the edge gateway cluster E0, such as the edge gateway GW0, through the handshake protocol, the request can be sent to the edge gateway GW0 of the protocol layer through the long connection, and the edge gateway GW0 performs protocol parsing and protocol re-encapsulation, and transmits it to the service gateway SV0. After the service gateway SV0 processes the data, it obtains the processing result, and obtains the message to be pushed through data encapsulation.

[0115] Because in a specific implementation, first, the service gateway SV0 can determine the edge gateway with the best health as the target edge gateway based on the acquired health detection data through the target edge gateway determination module D0, or determine multiple edge gateways whose health meets the preset requirements, and select one from them as the target edge gateway, and then filter the multiple acquired messages to be pushed according to the preset scheduling screening conditions through the scheduling screening module S0, select the message that meets the scheduling screening requirements as the current message to be pushed, and push it through the push module. As an optional example, in the service gateway SV0, the target edge gateway determination module D0 can preset a health detection model according to demand for determining the edge gateway, and the scheduling screening module S0 can preset a scheduling screening model according to demand for determining the priority of the message to be pushed.

[0116] It can be understood that in a specific implementation, the messages to be pushed can be selected first according to the preset scheduling screening conditions, and then the target edge gateway to which the messages to be pushed are sent can be determined based on the obtained health detection data. This specification does not impose any restrictions on the order of determining the priority of the above-mentioned target edge gateways and messages to be pushed.

[0117] It should be noted that the message push methods described in the embodiments of this specification are applicable to a variety of application scenarios, such as push receipt messages, reply messages, and response messages to requests with high real-time requirements, such as voice and video conversations. The embodiments of this specification do not limit the type and form of client requests; any request requiring message push can be used. To improve the SLA capabilities of messaging services, the solutions described in this specification can be used in any application.

[0118] In order to improve the high service availability during message transmission and the success rate of message push while ensuring the lightweight edge, the embodiment of this specification also provides a corresponding message push system, such as Figure 8 The structural diagram of the message push system shown in FIG. 8 shows that the message push system 80 may include: a receiving unit 81, a target edge gateway determination unit 82, and a push unit 83, wherein:

[0119] The receiving unit 81 is adapted to receive messages to be pushed;

[0120] The target edge gateway determining unit 82 is adapted to obtain health detection data of each edge gateway and select an edge gateway whose health meets preset requirements as the target edge gateway based on the health detection data;

[0121] The pushing unit 83 is adapted to push the message to be pushed to the target edge gateway.

[0122] As an optional example, continue to refer to Figure 8The message push system 80 may further include: a scheduling screening unit 84, adapted to screen the messages to be pushed according to preset scheduling screening conditions, and use the screened messages that meet the preset scheduling screening conditions as the current messages to be pushed.

[0123] As another alternative example, continue to refer to Figure 8 The message push system 80 may further include: an exception push processing unit 85, adapted to process the message to be pushed according to a corresponding exception handling strategy when a push exception occurs.

[0124] The specific implementation of the message push system can be implemented with reference to the principles, specific examples, and application scenarios of the aforementioned message push method embodiment, and will not be described in detail here.

[0125] Accordingly, this specification also provides a service gateway, referring to Figure 9 The structural diagram of the service gateway shown in the figure shows that the service gateway 90 may include a memory 91 and a processor 92, and the memory 91 stores a computer program that can be run on the processor 92, wherein the processor executes the steps of the message push method described in any of the aforementioned embodiments when running the computer program.

[0126] In a specific implementation, the service gateway 90 may be a service gateway or a cluster of service gateways deployed in a clustered manner, and the memory 91 may be a distributed storage device.

[0127] The processor 92 can be a single-core processor or a multi-core processor, a general-purpose processor, or a dedicated processor capable of processing large amounts of data. The specific structure and implementation of the processor are not limited here.

[0128] Accordingly, an embodiment of this specification further provides a computer-readable storage medium on which a computer program is stored, wherein the computer program executes the steps of the message push method described in any of the aforementioned embodiments when running.

[0129] In a specific implementation, the computer-readable storage medium may be any appropriate readable storage medium such as an optical disc, a mechanical hard disk, or a solid-state drive.

[0130] Although the embodiments of this specification are disclosed above, the present invention is not limited thereto. Any person skilled in the art can make various changes and modifications without departing from the spirit and scope of the present invention. Therefore, the scope of protection of the present invention should be based on the scope defined by the claims.

Claims

1. A message push method is applied to a service gateway in a decoupled architecture between the protocol layer and the service layer, wherein: The edge gateway corresponding to the protocol layer establishes a persistent connection with the client, and the client sends a request to the edge gateway through the persistent connection. The edge gateway performs protocol parsing and protocol repackaging, and transmits the request to the service gateway corresponding to the service layer. The service gateway performs data processing and data conversion. The method includes: Receive messages to be pushed; Obtain health detection data of each edge gateway; Based on the health detection data, select an edge gateway whose health meets preset requirements as a target edge gateway; Acquire attribute information of multiple types of the message to be pushed, the attribute information including: acquiring reception time information, type information and corresponding user priority information of the message to be pushed; Based on the attribute information of the multiple types of messages to be pushed and the priority weight factors corresponding to the attribute information of the corresponding types, the priorities of the messages to be pushed are obtained, and the messages are sorted in order of priority; A preset number of pending push messages meeting a preset priority level are used as current pending push messages; The current message to be pushed is pushed to the target edge gateway, so that the target edge gateway transmits the current message to be pushed to the client with which a long connection is established.

2. The method according to claim 1, wherein The obtaining of health detection data of each edge gateway includes obtaining at least one type of detection data of each edge gateway: Heartbeat data of each edge gateway; Data on the number of user connections corresponding to each edge gateway; Traffic status data of each edge gateway.

3. The method according to claim 2, wherein: Obtain at least two types of detection data from each edge gateway; The selecting, based on the health detection data, an edge gateway whose health meets preset requirements as a target edge gateway includes: Based on the detection data of each type corresponding to each edge gateway and the preset health weight factor of the corresponding type, the health detection data of each edge gateway is obtained; Select the edge gateway with the best health detection data as the target edge gateway.

4. The method according to claim 3, wherein: Obtain health check data of each edge gateway at preset time intervals.

5. The method according to claim 1, wherein After pushing the message to be pushed to the target edge gateway, the method further includes: When a push exception occurs, the message to be pushed is processed according to the corresponding exception handling strategy.

6. The method according to claim 5, wherein: When a push exception occurs, the message to be pushed is processed according to a corresponding exception handling strategy, including at least one of the following: When an abnormality is detected in the service corresponding to the message to be pushed, reconnect with the service, obtain the message to be pushed corresponding to the service, and push it to the corresponding target edge gateway; When a user exception corresponding to the message to be pushed is detected, the message to be pushed is processed accordingly based on a preset user exception processing strategy.

7. A message push system is applied to a service gateway in a decoupled architecture between the protocol layer and the service layer, wherein: The edge gateway corresponding to the protocol layer establishes a persistent connection with the client, and the client sends a request to the edge gateway through the persistent connection. The edge gateway performs protocol parsing and protocol repackaging, and transmits the request to the service gateway corresponding to the service layer. The service gateway performs data processing and data conversion. The system includes: A receiving unit, adapted to receive messages to be pushed; a target edge gateway determining unit adapted to obtain health detection data of each edge gateway and, based on the health detection data, select an edge gateway whose health meets preset requirements as the target edge gateway; The scheduling and screening unit is adapted to obtain attribute information of multiple types of messages to be pushed, the attribute information including: obtaining reception time information, type information, and corresponding user priority information of the messages to be pushed; obtaining priorities of the messages to be pushed based on the attribute information of the multiple types of messages to be pushed and priority weight factors corresponding to the attribute information of the corresponding types, and sorting the messages in order of priority; and treating a preset number of messages to be pushed that meet a preset priority level as current messages to be pushed; The pushing unit is adapted to push the current message to be pushed to the target edge gateway, so that the target edge gateway transmits the current message to be pushed to the client with which a long connection is established.

8. The system according to claim 7, wherein: Also includes: The exception push processing unit is adapted to process the message to be pushed according to a corresponding exception handling strategy when a push exception occurs.

9. A service gateway comprising a memory and a processor, wherein the memory stores a computer program that can be run on the processor, wherein: When the processor runs the computer program, the steps of the method according to any one of claims 1 to 6 are performed.

10. A computer-readable storage medium having a computer program stored thereon, wherein: When the computer program is executed, the steps of the method according to any one of claims 1 to 6 are executed.

Images