A socket.io-based message pushing method and device and related components

Abstract

The application discloses a socket.io-based message pushing method and device and related components. The message pushing method comprises deploying a load balancer and multiple socket.io server nodes, establishing a connection between a terminal device and any of the socket.io server nodes through the load balancer, integrating a Kafka message queue into each socket.io server node, and using the Kafka message queue execution platform to perform a message pushing process to the terminal device. The application uses the load balancer to distribute the connection requests of a large number of terminal devices to different socket.io server nodes, disperses the connection pressure of a single server, and improves the connection stability of each socket.io server node and the terminal device. Moreover, the integration of the Kafka message queue can timely locate the socket.io server node connected to the target terminal device, and then accurately push the message to the target terminal device through the socket.io server node, thereby improving the pushing efficiency and accuracy in the scenario of a large number of devices.

Description

Technical Field

[0001] This application belongs to the field of communication technology, and in particular relates to a message push method, device and related components based on socket.io. Background Technology

[0002] In today's mobile internet era, pushing messages from platforms to mobile devices has become a key technical means to meet users' real-time interaction needs. Among them, implementing bidirectional push between the client and server based on socket.io technology is a common solution. This solution can quickly build message push functions by directly integrating the built-in capabilities of socket.io into the front-end and back-end, simplifying the development process.

[0003] However, existing message push technologies based on socket.io have significant limitations when dealing with massive numbers of mobile devices, making it difficult to meet the needs of large-scale application scenarios. Specifically, the native architecture of socket.io is designed for a single server, and its connection management mechanism relies on storing connection objects in a single machine's memory. The hardware resources of a single server (such as the number of file descriptors and memory capacity) have physical limits, severely restricting the number of terminal device connections a single server can support. Furthermore, socket.io connection objects cannot be serialized, stored, and shared using distributed caches like Redis, preventing global synchronization of connection states across the server cluster. These limitations prevent the server resources from being distributed horizontally to distribute the load, placing extremely high demands on the memory configuration of a single server. Moreover, existing solutions cannot achieve stable and efficient connection management and message push when dealing with hundreds of thousands, millions, or even more terminal devices, severely restricting the application scope of socket.io-based message push technology in large-scale mobile internet applications. Summary of the Invention

[0004] This application provides a message push method, apparatus, and related components based on socket.io, which can achieve stable connection and efficient message push for a large number of devices.

[0005] In a first aspect, embodiments of this application provide a message push method based on socket.io, including:

[0006] Deploy a load balancer and multiple socket.io server nodes, and establish a connection between the terminal device and any of the socket.io server nodes through the load balancer;

[0007] The Kafka message queue is integrated into each socket.io server node, and the Kafka message queue is used to execute the message push process from the platform to the terminal device.

[0008] Secondly, embodiments of this application provide a message push device based on socket.io, comprising:

[0009] A connection establishment unit is used to deploy a load balancer and multiple socket.io server nodes, and to establish a connection between the terminal device and any of the socket.io server nodes through the load balancer;

[0010] The message push unit is used to integrate the Kafka message queue into each socket.io server node and use the Kafka message queue to execute the message push process from the platform to the terminal device.

[0011] Thirdly, embodiments of this application provide a computer device, including a processor and a memory, wherein the memory stores a computer program, and the processor executes the program to implement the message push method provided in embodiments of this application.

[0012] Fourthly, embodiments of this application also provide a computer-readable storage medium storing a computer program, which, when executed, implements the message push method provided in embodiments of this application.

[0013] In this embodiment, by deploying a load balancer and multiple socket.io server nodes, and establishing connections between terminal devices and any of the socket.io server nodes through the load balancer, the load balancer can distribute connection requests from a massive number of terminal devices to different socket.io server nodes. This disperses the connection pressure on a single server, achieving horizontal scaling of server resources and improving the connection stability between each socket.io server node and the terminal device. Furthermore, by integrating a Kafka message queue into each socket.io server node, the message push process is optimized. This allows the Kafka message queue to promptly locate the socket.io server node connected to the target terminal device, and then accurately push messages to the target terminal device through the socket.io server node. This effectively solves the problems of push efficiency and reliability in traditional socket.io solutions under massive device scenarios. Attached Figure Description

[0014] The technical solution and its beneficial effects will become apparent from the following detailed description of specific embodiments of this application, in conjunction with the accompanying drawings.

[0015] Figure 1 This is a flowchart illustrating a message push method based on socket.io provided in an embodiment of this application.

[0016] Figure 2 This is a logical diagram of a message push method based on socket.io provided in an embodiment of this application.

[0017] Figure 3 This is a schematic diagram of the structure of a message push device based on socket.io provided in an embodiment of this application.

[0018] Figure 4 This is a schematic block diagram of a computer device provided in an embodiment of this application. Detailed Implementation

[0019] It should be noted that the terms "first," "second," and "third," etc., used in this application are used to distinguish different objects, not to describe a specific order. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion. For example, a process, method, system, product, or device that includes a series of steps or modules is not limited to the listed steps or modules, but some embodiments also include steps or modules not listed, or some embodiments also include other steps or modules inherent to these processes, methods, products, or devices.

[0020] In this document, the term "embodiment" means that a particular feature, structure, or characteristic described in connection with an embodiment may be included in at least one embodiment of this application. The appearance of this phrase in various places throughout the specification does not necessarily refer to the same embodiment, nor is it a separate or alternative embodiment mutually exclusive with other embodiments. It will be explicitly and implicitly understood by those skilled in the art that the embodiments described herein can be combined with other embodiments.

[0021] This application provides a message push method, apparatus, and related components based on socket.io. The executing entity of a message push method based on socket.io can be a message push apparatus based on socket.io provided in this application, wherein the message push apparatus based on socket.io can be implemented in hardware or software.

[0022] Please see Figure 1 , Figure 1 This is a flowchart illustrating a message push method based on socket.io provided in an embodiment of this application. The process may include:

[0023] In 101, a load balancer and multiple socket.io server nodes are deployed, and the connection between the terminal device and any of the socket.io server nodes is established through the load balancer.

[0024] In this embodiment, a load balancer is first set up, and at least two (or more) socket.io server nodes are deployed. All socket.io server nodes are connected to the management scope of the load balancer, forming a horizontally scalable socket.io service cluster. The load balancer serves as the unified connection entry point between terminal devices and socket.io server nodes, responsible for receiving socket.io connection requests initiated by all terminal devices. Multiple socket.io server nodes jointly undertake the connection support and subsequent message exchange tasks for the terminal devices.

[0025] When a terminal device needs to establish a socket.io connection with a server, the terminal device does not need to specify a specific socket.io server node. It only needs to send a connection request to the load balancer. The load balancer automatically assigns any socket.io server node to complete the socket.io connection handshake and establishment process with the terminal device, ultimately achieving a stable connection between the terminal device and any socket.io server node.

[0026] In this way, connection requests from a massive number of terminal devices can be easily distributed across multiple socket.io server nodes, avoiding performance bottlenecks caused by overload on a single server due to excessive connection counts. Furthermore, if it is necessary to further increase the connection capacity of the socket.io service cluster, it is only necessary to increase the number of socket.io server nodes and connect a load balancer, achieving flexible horizontal scaling of server resources and effectively solving the problem that a traditional single socket.io server cannot support a massive number of device connections.

[0027] In an optional embodiment, the deployment of a load balancer and multiple socket.io server nodes, and the establishment of a connection between the terminal device and any of the socket.io server nodes through the load balancer, includes:

[0028] Pre-install Nginx as a load balancer and configure load balancing strategies and WebSocket proxy;

[0029] Multiple socket.io server nodes were built using the Express framework based on Node.js;

[0030] When a connection request is received from a terminal device, it is forwarded to one of the socket.io server nodes through the load balancer, and authentication is performed.

[0031] Register the authenticated terminal device and establish a connection with the current socket.io server node, and save the connection relationship between the terminal device and the current socket.io server node to the local routing table.

[0032] In this embodiment, Nginx is pre-installed and used as a load balancer. The load balancer is configured, primarily with load balancing strategies and a WebSocket proxy. Load balancing strategies include round-robin, weighted round-robin, and least connections first. Round-robin distributes client requests sequentially to backend servers. For example, with three servers (A, B, and C), the first request goes to server A, the second to server B, the third to server C, and the fourth back to server A, and so on. Weighted round-robin assigns a weight to each server based on the round-robin algorithm (e.g., A: 5, B: 3, C: 2), distributing requests proportionally. For example, with a total weight of 10, server A handles 5 requests, server B handles 3, and server C handles 2 out of every 10 requests. The least connections first strategy dynamically calculates the current number of active connections for each server and assigns new requests to the server with the fewest connections. For example, if server A has 3 connection objects, server B has 5 connection objects, and server C has 1 connection object, then new requests will be preferentially assigned to server C, which has the fewest connection objects.

[0033] In practice, appropriate strategies can be selected and configured based on the differences in server hardware performance. That is, a round-robin strategy, a weighted round-robin strategy, or a minimum number of connections priority strategy can be set as the load balancing strategy. Alternatively, a strategy weight can be set for each strategy, and the strategy weight can be dynamically adjusted to ensure that the number of connections on each server is not overloaded.

[0034] Furthermore, configuring a WebSocket proxy for Nginx enables Nginx to utilize WebSocket proxy capabilities to configure TCP persistent connection parameters (such as setting connection timeout and disabling unnecessary connection termination mechanisms), ensuring that the WebSocket protocol, on which socket.io depends, can stably connect to the load balancer and avoid mid-connection interruptions.

[0035] Multiple independent socket.io server nodes were built using the Express framework based on Node.js to ensure that all socket.io server nodes maintained consistent business logic processing capabilities (such as identical authentication rules and message exchange protocols). After setup, the IP addresses and service ports of all socket.io server nodes were entered into the Nginx load balancing configuration list, enabling Nginx to recognize and manage the entire socket.io service cluster.

[0036] When a terminal device (such as a mobile phone, tablet, or other mobile device) needs to establish a socket.io connection with the server, the terminal device does not need to specify a specific socket.io server node. It only needs to send a connection request to the preset unified entry point of the Nginx load balancer. After receiving the connection request from the terminal device, Nginx analyzes the current load status of each socket.io server node in real time (such as the number of established connections, CPU utilization, memory usage, etc.) according to the pre-configured load balancing strategy (this embodiment adopts the least connections first strategy). It automatically forwards the connection request to a socket.io server node with lower load and less resource consumption, avoiding overload problems caused by concentrated requests on a single node.

[0037] Upon receiving a connection request, the socket.io server node that receives the forwarded request first performs authentication. It verifies the device's legitimacy and access permissions using the device's identity information (such as a user token or unique device ID). This verification process checks the token's validity and whether the device is on a whitelist of allowed access. Only authenticated devices continue the connection process; unauthorized requests are rejected to ensure service security. After successful authentication, the socket.io server node and the device establish a bidirectional communication connection. Simultaneously, to ensure accurate message pushes by locating the terminal device's socket.io server node, it stores the mapping between the terminal device's unique identifier (e.g., device ID) and the current server node's identifier (e.g., node IP + port) in a local routing table (this local routing table can be implemented using memory caching or a lightweight local database to ensure fast query speeds). This creates a clear connection mapping, providing node location information for targeted message pushes.

[0038] This embodiment, through the above connection process, not only achieves distributed load balancing of connection requests from a massive number of terminal devices, breaking through the connection limit of a single server, but also balances service security and the accuracy of subsequent message interactions through authentication and connection relationship management, providing support for stable connections of a large number of terminal devices.

[0039] In step 102, the Kafka message queue is integrated into each socket.io server node, and the Kafka message queue is used to execute the message push process from the platform to the terminal device.

[0040] In this embodiment, to address the efficiency and stability issues of message push in scenarios with a large number of devices, a Kafka message queue is integrated into each socket.io server node to construct a distributed message forwarding mechanism. This allows the platform to promptly locate the socket.io server node connected to the target terminal device when pushing messages to the terminal device via the Kafka message queue, and then accurately push the message to the target terminal device through the socket.io server node. This effectively solves the efficiency and reliability problems of traditional socket.io solutions in scenarios with a large number of devices.

[0041] In other implementation scenarios, the Kafka message queue can be replaced with a Redis message queue or a RocketMQ message queue, depending on the application scenario.

[0042] In an optional embodiment, integrating the Kafka message queue into each socket.io server node includes:

[0043] Install a Kafka cluster on the server and configure message topics for the Kafka cluster;

[0044] Integrate the Kafka client library into each socket.io server node, and connect to the Kafka cluster through the Kafka client library to integrate the Kafka message queue.

[0045] In this embodiment, a Kafka cluster is deployed on the server side. This Kafka cluster consists of multiple Kafka broker nodes to achieve high availability and high throughput for message storage and distribution. Based on the business scenario requirements of message push, corresponding message topics are pre-configured in the Kafka cluster. For example, topics can be divided according to message type, target terminal device groups, or business modules, enabling different types of push messages to be stored and circulated by topic, providing a foundation for accurate message subscription later. Next, a Kafka client library is integrated into each socket.io server node. Through the Kafka client library, each socket.io server node can establish a stable connection with the Kafka cluster, including configuring parameters such as the Kafka cluster broker node address, connection port, and communication protocol, ensuring that each socket.io server node can normally access the Kafka cluster, thereby achieving the integration of the Kafka message queue.

[0046] Through the above deployment and configuration, each socket.io server node has the ability to interact with the Kafka cluster. It can act as a message producer to send messages to be pushed to a specified topic, and it can also act as a message consumer to subscribe to and obtain push tasks that need to be processed from the corresponding topic. This builds an efficient message passing channel between the socket.io server cluster and the Kafka message queue, and completes the integration of the Kafka message queue with each socket.io server node.

[0047] In an optional embodiment, the message push process using the Kafka message queue execution platform to the terminal device includes:

[0048] The receiving platform sends a message push request to the terminal device, sends the message push request to the load balancer via the HTTP protocol, and forwards the message push request to any socket.io server node through the load balancer;

[0049] Query the local routing table of the socket.io server node that received the message push request. If the target terminal device is found in the local routing table, push the message directly.

[0050] If the target terminal device is not found in the local routing table, the push message request is published to the Kafka cluster through the Kafka client library;

[0051] The Kafka cluster notifies other socket.io server nodes to subscribe and queries the local routing tables of each socket.io server node until the target terminal device is found in one of the local routing tables, and then pushes the message.

[0052] In this embodiment, after the platform generates a message push request to a specific terminal device, it sends the request to the load balancer via the HTTP protocol. Upon receiving the request, the load balancer forwards the message push request to any socket.io server node (the initial processing node) according to a preset load distribution strategy. The socket.io server node receiving the message push request first parses the target terminal device identifier (such as device ID) in the message push request and then queries its own local routing table (which stores information about terminal devices already connected to the node). If a connection record for the target terminal device is found in the local routing table (i.e., the terminal device is currently connected to the node), the message is directly pushed to the terminal device through the established socket.io server node, completing the push process.

[0053] If the target device is not found in the local routing table of the current socket.io server node (i.e., the device is not connected to this node), the message push request is published to a specified topic in the Kafka cluster according to a preset format (including the target device identifier, message content, etc.) through the integrated Kafka client library. Upon receiving the message push request, the Kafka cluster automatically notifies other socket.io server nodes in the cluster to subscribe to the topic based on the topic subscription mechanism. After subscribing, each socket.io server node receives the message and queries its own local routing table to determine if the target device is connected to it. When one of the socket.io server nodes finds a connection record for the target device in its local routing table, it immediately completes the message push through the socket.io connection between that node and the device, thus achieving precise message delivery across nodes.

[0054] By combining Kafka's distributed message subscription capabilities with local routing table lookups on each socket.io server node through the above process, intelligent message routing within the Kafka cluster can be achieved without relying on global connection state storage. This ensures that the target terminal device can be accurately located and receive messages regardless of which socket.io server node it connects to, effectively solving the problem of messages not being able to be pushed across machines in the traditional single-node architecture.

[0055] In an optional embodiment, the message push method further includes:

[0056] The connection status between the terminal device and the current socket.io server node is monitored in real time. When the connection status is offline, the connection relationship between the terminal device and the current socket.io server node in the local routing table is cleared.

[0057] In this embodiment, each socket.io server node monitors the online status of connected terminal devices in real time through a preset connection status monitoring mechanism. When the connection status of a terminal device with the current socket.io server node changes to offline (including but not limited to: the terminal device actively disconnecting, network anomalies causing connection interruption, heartbeat timeout failure, etc.), the current socket.io server node immediately triggers a local routing table cleanup mechanism. The cleanup mechanism specifically operates by accurately locating and deleting the connection relationship record corresponding to the terminal device (i.e., the mapping information between the terminal device's unique identifier and the current server node) from the local routing table, ensuring that the connection relationships stored in the local routing table always remain consistent with the actual connection status.

[0058] The above real-time monitoring and cleanup process can avoid message push errors caused by the failure to update the local routing table information in a timely manner after the terminal device goes offline (such as repeatedly pushing messages to the node where the offline device is located). At the same time, it reduces invalid storage occupation, improves the accuracy and efficiency of routing lookup when pushing messages in the future, and provides a basic guarantee for the accuracy of cross-node message push.

[0059] In practical implementation, the preset connection state detection mechanism can be based on the native ping / pong heartbeat interaction mechanism of socket.io. This is a built-in connection state detection mechanism of the socket.io framework, implemented based on the application layer protocol, used to maintain the long-term connection activity between the client and the server. The specific process is as follows: the socket.io server node sends special ping control frames to the connected terminal device at preset intervals (default 25 seconds, configurable). After receiving the ping frame, the socket.io client of the terminal device will immediately and automatically return a pong response frame without the need for business layer intervention. If the socket.io server node does not receive a pong response from the client within the preset timeout period (default 60 seconds, configurable), it determines that the connection between the terminal device and the current server node has been interrupted (e.g., network failure, client crash, etc.), thereby triggering offline processing logic (i.e., cleaning up the local routing table).

[0060] The preset connection state detection mechanism can also be a TCP connection state monitoring mechanism. This is a connection state detection mechanism based on the underlying TCP protocol of the operating system. It determines whether the physical connection is valid by monitoring the kernel state of the TCP connection. Specifically, the socket.io server node obtains the kernel state of the TCP connection established with the terminal device in real time (such as ESTABLISHED, CLOSED, TIME_WAIT, etc.) through network interfaces provided by the operating system (such as netstat, ss commands, or system calls). When the TCP connection state changes to CLOSED (actively closed), RST (reset), or remains in an inactive state such as SYN_SENT (connection not established) for a long time, it is determined that the underlying physical connection has been interrupted.

[0061] In practical applications, socket.io server nodes typically enable two detection mechanisms simultaneously: TCP monitoring to ensure the validity of the underlying connection, and socket.io's native ping / pong heartbeat interaction mechanism to ensure normal application layer communication. This allows for simultaneous monitoring of both the underlying and application layers, improving the accuracy and timeliness of connection status detection.

[0062] In an optional embodiment, the message push method further includes:

[0063] Deploy a keep-alive mechanism to the terminal device to maintain its online status.

[0064] In this embodiment, a keep-alive mechanism is integrated into the client program of the terminal device. This keep-alive mechanism maintains regular interaction with the currently connected socket.io server node by periodically sending keep-alive signals in a specific format. The sending period of the keep-alive signal can be configured according to business needs (e.g., once every 30 seconds to 5 minutes), ensuring that even when the terminal device is in sleep mode or experiencing network fluctuations, it can still prove its online status to the server so that it can receive messages from the server in real time.

[0065] Meanwhile, the terminal device must have the ability to reconnect after a disconnection. When a connection interruption is detected with the socket.io server node (such as not receiving a response to the server's keep-alive signal, network error messages, etc.), the client program automatically triggers the reconnection logic, re-initiating a connection request to the socket.io service cluster through the load balancer until the connection is re-established and communication is restored. During the reconnection process, the terminal device will carry its own unique identification information so that the newly connected socket.io server node can update its local routing table to ensure that subsequent messages can be delivered normally.

[0066] By deploying this keep-alive mechanism, connection misjudgments caused by non-active offline scenarios such as network interruptions and brief device hibernation can be effectively reduced, the abnormal offline rate of terminal devices can be lowered, and a long-term stable connection between terminal devices and the server can be maintained, providing underlying support for the real-time performance and reliability of message push.

[0067] In practical implementation, the keep-alive mechanism involves periodically sending heartbeat packets. Deploying the keep-alive mechanism to the terminal device to maintain its online status includes:

[0068] Configure keep-alive logic on the terminal device to periodically send heartbeat packets;

[0069] After each socket.io server node connected to the terminal device receives the heartbeat packet sent by the corresponding terminal device, it updates the connection status with the corresponding terminal device in each local routing table.

[0070] If one of the socket.io server nodes does not receive a heartbeat packet from the corresponding terminal device within a predetermined period of time, the terminal device is determined to be offline, and a cleanup operation is performed.

[0071] The terminal device is initiated to automatically reconnect, and the connection with any socket.io server node is re-established through the load balancer.

[0072] In this embodiment, a keep-alive logic for periodically sending heartbeat packets is preset in the client program of the terminal device. This includes setting the heartbeat packet sending cycle (e.g., once every 60 seconds) and the heartbeat packet content format (including the terminal device's unique identifier, current timestamp, and other key information). The terminal device automatically sends heartbeat packets to the currently connected socket.io server nodes according to the configured cycle, actively proving its online status. Each socket.io server node maintaining a connection with the terminal device, upon receiving the heartbeat packet corresponding to that terminal device, immediately parses the key information in the packet to confirm the terminal device's identity and updates the connection status of the corresponding terminal device in its local routing table in real time (e.g., refreshing the last active timestamp), ensuring that the terminal device's online status recorded in its local routing table is consistent with the actual online status.

[0073] If a socket.io server node does not receive a heartbeat packet from its connected terminal device within a predetermined period (e.g., no heartbeat packet received for three consecutive heartbeat cycles, which can be set according to business needs), the terminal device is determined to be offline (possibly due to network interruption, device shutdown, etc.). At this time, the socket.io server node triggers a cleanup mechanism, deleting the connection record of the terminal device from the local routing table to avoid invalid message push attempts.

[0074] The client program on the terminal device monitors the heartbeat interaction status in real time. When it detects an interruption in the heartbeat response with the server node (such as not receiving confirmation of the heartbeat packet from the server, abnormal connection termination, etc.), it immediately initiates automatic reconnection logic. That is, the terminal device re-initiates a connection request to the socket.io server cluster through the load balancer. The load balancer forwards the request to the appropriate socket.io server node based on the current load status of each socket.io server node in the cluster. After the new connection is established, the terminal device re-registers its identity information, and the newly connected socket.io server node updates its local routing table, restoring normal communication with the terminal device and ensuring its continued online presence to receive push notifications.

[0075] Through the closed-loop mechanism of heartbeat interaction, status update, offline detection and automatic reconnection, the online status of terminal devices can be accurately maintained, reducing connection instability caused by network fluctuations and ensuring the continuity of message push channels.

[0076] It's important to note that "a keep-alive mechanism that involves periodically sending heartbeat packets" and "socket.io's native ping / pong heartbeat interaction mechanism" are not entirely the same concept. Periodically sending heartbeat packets is a broad functional definition; its core objective is to demonstrate a valid connection and online status by periodically exchanging small signals (heartbeat packets) between the terminal device and the server, without specifying a particular technical framework or implementation method. In contrast, socket.io's native ping / pong heartbeat interaction mechanism is a specific technical solution built into the socket.io framework to implement the "keep-alive" function. Essentially, it's a standardized implementation of the "periodic heartbeat packet sending" function, adhering to the socket.io protocol specification. It completes the periodic heartbeat interaction through preset ping (server-sent) and pong (client-return) control frames, representing a specific form of the "periodic heartbeat packet sending" keep-alive mechanism. In other words, in this embodiment of the invention, the socket.io native ping / pong heartbeat interaction mechanism can be used to detect the online status of the terminal device and also to implement the keep-alive function.

[0077] Refer to the logical diagram of the entire message push method based on socket.io. Figure 2 As shown, the server node is the socket.io server node.

[0078] Please see Figure 3 , Figure 3 This is a schematic diagram of a message push device based on socket.io provided in an embodiment of this application. A message push device 200 based on socket.io includes: a connection establishment unit 201 and a message push unit 202.

[0079] The connection establishment unit 201 is used to deploy a load balancer and multiple socket.io server nodes, and to establish a connection between the terminal device and any of the socket.io server nodes through the load balancer;

[0080] The message push unit 202 is used to integrate the Kafka message queue into each socket.io server node and use the Kafka message queue to execute the message push process from the platform to the terminal device.

[0081] In an optional embodiment, the connection establishment unit 201 can be used to: pre-install Nginx as a load balancer and configure load balancing strategies and WebSocket proxies; build multiple socket.io server nodes using the Node.js-based Express framework; when a connection request from a terminal device is received, forward it to one of the socket.io server nodes through the load balancer and perform authentication processing; register the authenticated terminal device and establish a connection with the current socket.io server node, and save the connection relationship between the terminal device and the current socket.io server node to the local routing table.

[0082] In an optional embodiment, the message push unit 202 can be used to: install a Kafka cluster on the server side and configure message topics for the Kafka cluster; integrate a Kafka client library in each socket.io server node, and connect to the Kafka cluster through the Kafka client library to integrate a Kafka message queue.

[0083] In an optional embodiment, the message push unit 202 can be used to: receive a message push request from the platform to the terminal device; send the message push request to the load balancer via the HTTP protocol; and forward the message push request to any socket.io server node via the load balancer; query the local routing table of the socket.io server node that received the message push request; if the target terminal device is found in the local routing table, push the message directly; if the target terminal device is not found in the local routing table, publish the push message request to the Kafka cluster via the Kafka client library; notify other socket.io server nodes to subscribe via the Kafka cluster, and query the local routing tables of other socket.io server nodes respectively until the target terminal device is found in one of the local routing tables, and push the message.

[0084] In an optional embodiment, the message push device based on socket.io further includes: a detection unit, used to monitor the connection status between the terminal device and the current socket.io server node in real time, and when the connection status is offline, to clear the connection relationship between the terminal device and the current socket.io server node in the local routing table.

[0085] In an optional embodiment, the socket.io-based message push device further includes a deployment unit for deploying a keep-alive mechanism to the terminal device to maintain the online status of the terminal device.

[0086] In an optional embodiment, the deployment unit can be used to: configure keep-alive logic for periodically sending heartbeat packets on the terminal device; after each socket.io server node connected to the terminal device receives the heartbeat packet sent by the corresponding terminal device, it updates the connection status with the corresponding terminal device in each local routing table; if one of the socket.io server nodes does not receive the heartbeat packet from the corresponding terminal device within a predetermined period of time, it determines that the terminal device is offline and performs a cleanup operation; and initiates the automatic reconnection operation of the terminal device to re-establish the connection with any socket.io server node through the load balancer.

[0087] Please see Figure 4 This application provides a computer device 300, including a processor 320 and a memory, wherein the memory stores a computer program 332, and when the processor executes the program, it calls the computer program 332 stored in the memory to execute a message push method based on socket.io provided in this embodiment.

[0088] In this embodiment, the computer device 300 includes a processor 320, a memory, and a network interface 350 connected via a system bus 310. The memory may include a non-volatile storage medium 330 and internal memory 340. The non-volatile storage medium 330 stores an operating system 331 and a computer program 332. The computer program 332 includes program instructions that, when executed, cause the processor 320 to execute a message push method based on socket.io. The processor 320 provides computing and control capabilities to support the operation of the entire computer device 300. The internal memory 340 provides an environment for the execution of the computer program 332 in the non-volatile storage medium 330. When the processor 320 executes the computer program 332, it causes the processor 320 to execute a message push method based on socket.io.

[0089] This network interface 350 is used for network communication with other devices. Those skilled in the art will understand that... Figure 4 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device 300 to which the present application is applied. The specific computer device 300 may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0090] It will be understood by those skilled in the art that all or part of the processes in the methods of the above embodiments can be implemented by a computer program 332 instructing related hardware. The computer program includes program instructions, and the computer program 332 can be stored in a storage medium, which is a computer-readable storage medium. The program instructions are executed by at least one processor in the computer system to implement the process steps of the embodiments of the above methods.

[0091] Therefore, this application also provides a computer-readable storage medium storing a computer program thereon, which, when executed on a computer, causes the computer to execute a message push method based on socket.io as provided in this embodiment.

[0092] In this embodiment, the processor 320 in the computer device loads the executable code corresponding to the processes of one or more applications into the memory according to the following instructions, and the processor 320 runs the applications stored in the memory, thereby achieving:

[0093] Deploy a load balancer and multiple socket.io server nodes, and establish a connection between the terminal device and any of the socket.io server nodes through the load balancer;

[0094] The Kafka message queue is integrated into each socket.io server node, and the Kafka message queue is used to execute the message push process from the platform to the terminal device.

[0095] In an optional embodiment, the processor 320 executes the deployment of the load balancer and multiple socket.io server nodes. When establishing a connection between a terminal device and any of the socket.io server nodes through the load balancer, it may perform the following: pre-install Nginx as a load balancer and configure the load balancing strategy and WebSocket proxy; build multiple socket.io server nodes using the Node.js-based Express framework; when a connection request from a terminal device is received, forward it to one of the socket.io server nodes through the load balancer and perform authentication processing; register the authenticated terminal device and establish a connection with the current socket.io server node, and save the connection relationship between the terminal device and the current socket.io server node to the local routing table.

[0096] In an optional embodiment, when processor 320 performs the step of integrating the Kafka message queue into each socket.io server node, it may perform the following: install a Kafka cluster on the server side and configure message topics for the Kafka cluster; integrate a Kafka client library into each socket.io server node and connect to the Kafka cluster through the Kafka client library to integrate the Kafka message queue.

[0097] In an optional embodiment, when the processor 320 executes the message push process from the platform to the terminal device using the Kafka message queue, it may perform the following: receive a message push request from the platform to the terminal device; send the message push request to the load balancer via the HTTP protocol; and forward the message push request to any socket.io server node via the load balancer; query the local routing table of the socket.io server node that received the message push request; if the target terminal device is found in the local routing table, push the message directly; if the target terminal device is not found in the local routing table, publish the push message request to the Kafka cluster via the Kafka client library; notify other socket.io server nodes to subscribe via the Kafka cluster, and query the local routing tables of other socket.io server nodes respectively until the target terminal device is found in one of the local routing tables, and push the message.

[0098] In an optional embodiment, the processor 320 may also perform the following: real-time monitoring of the connection status between the terminal device and the current socket.io server node, and when the connection status is offline, clearing the connection relationship between the terminal device and the current socket.io server node in the local routing table.

[0099] In an alternative embodiment, the processor 320 may also perform: deploying a keep-alive mechanism to the terminal device to maintain the online status of the terminal device.

[0100] In an optional embodiment, the processor 320 executes the keep-alive mechanism by periodically sending heartbeat packets. When deploying the keep-alive mechanism to the terminal device to maintain the online status of the terminal device, the following steps can be performed: configuring keep-alive logic for periodically sending heartbeat packets on the terminal device; after each socket.io server node connected to the terminal device receives the heartbeat packet sent by the corresponding terminal device, updating the connection status with the corresponding terminal device in each local routing table; if one of the socket.io server nodes does not receive the heartbeat packet from the corresponding terminal device within a predetermined period of time, it is determined that the terminal device is offline and a cleanup operation is performed; the automatic reconnection operation of the terminal device is initiated, and the connection with any socket.io server node is re-established through the load balancer.

[0101] In the above embodiments, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the detailed description of a message push method based on socket.io above, which will not be repeated here.

[0102] The message push device based on socket.io provided in this application embodiment belongs to the same concept as the message push method based on socket.io in the above embodiment. Any method provided in the message push method embodiment based on socket.io can be run on the message push device based on socket.io. For details of its implementation process, please refer to the message push method embodiment based on socket.io, which will not be repeated here.

[0103] It should be noted that, regarding the message push method based on socket.io in this application embodiment, those skilled in the art will understand that all or part of the process of implementing the message push method based on socket.io in this application embodiment can be accomplished by a computer program controlling related hardware. The computer program can be stored in a computer-readable storage medium, such as a memory, and executed by at least one processor. During execution, it can include the process of an embodiment of the message push method based on socket.io. The computer-readable storage medium can be a magnetic disk, optical disk, read-only memory (ROM), random access memory (RAM), etc.

[0104] It is understood that in the specific implementation of this application, user information, such as application usage behavior data, logs and other related data, is involved. When the above embodiments of this application are applied to specific products or technologies, user permission or consent is required, and the collection, use and processing of related data must comply with the relevant laws, regulations and standards of the relevant countries and regions.

[0105] For a message push device based on socket.io according to an embodiment of this application, its functional modules can be integrated into a processing chip, or each module can exist physically separately, or two or more modules can be integrated into one module. The integrated module can be implemented in hardware or as a software functional module. If the integrated module is implemented as a software functional module and sold or used as an independent product, it can be stored in a computer device, such as a processor or memory, or in a computer-readable storage medium, such as a read-only memory, a disk, or an optical disk.

[0106] The above provides a detailed description of a message push method, apparatus, and related components based on socket.io provided in the embodiments of this application. Specific examples have been used to illustrate the principles and implementation methods of this application. The description of the above embodiments is only for the purpose of helping to understand the method and core ideas of this application. At the same time, for those skilled in the art, there will be changes in the specific implementation methods and application scope based on the ideas of this application. Therefore, the content of this specification should not be construed as a limitation of this application.

Claims

1. A message push method based on socket.io, characterized in that, include: Deploy a load balancer and multiple socket.io server nodes, and establish a connection between the terminal device and any of the socket.io server nodes through the load balancer; The Kafka message queue is integrated into each socket.io server node, and the Kafka message queue is used to execute the message push process from the platform to the terminal device; The deployment of a load balancer and multiple socket.io server nodes, and the establishment of a connection between the terminal device and any of the socket.io server nodes through the load balancer, includes: Nginx is pre-installed as a load balancer, and load balancing strategies and WebSocket proxy are configured. The load balancing strategies include round-robin, weighted round-robin, and least connections first strategies. Multiple socket.io server nodes were built using the Express framework based on Node.js; When a connection request is received from a terminal device, it is forwarded to one of the socket.io server nodes through the load balancer, and authentication is performed. Register the authenticated terminal devices and establish a connection with the current socket.io server node, and save the connection relationship between the terminal devices and the current socket.io server node to the local routing table; The integration of the Kafka message queue into each socket.io server node includes: Install a Kafka cluster on the server and configure message topics for the Kafka cluster; Integrate the Kafka client library into each socket.io server node, and connect to the Kafka cluster through the Kafka client library to integrate the Kafka message queue; The process of pushing messages from the Kafka message queue execution platform to the terminal device includes: The receiving platform sends a message push request to the terminal device, sends the message push request to the load balancer via the HTTP protocol, and forwards the message push request to any socket.io server node through the load balancer; Query the local routing table of the socket.io server node that received the message push request. If the target terminal device is found in the local routing table, push the message directly. If the target terminal device is not found in the local routing table, the push message request is published to the Kafka cluster through the Kafka client library; The Kafka cluster notifies other socket.io server nodes to subscribe and queries the local routing tables of each socket.io server node until the target terminal device is found in one of the local routing tables, and then pushes the message.

2. The message push method according to claim 1, characterized in that, Also includes: The connection status between the terminal device and the current socket.io server node is monitored in real time. When the connection status is offline, the connection relationship between the terminal device and the current socket.io server node in the local routing table is cleared.

3. The message push method according to claim 1, characterized in that, Also includes: Deploy a keep-alive mechanism to the terminal device to maintain its online status.

4. The message push method according to claim 3, characterized in that, The keep-alive mechanism involves periodically sending heartbeat packets. Deploying the keep-alive mechanism to the terminal device to maintain its online status includes: Configure keep-alive logic on the terminal device to periodically send heartbeat packets; After each socket.io server node connected to the terminal device receives the heartbeat packet sent by the corresponding terminal device, it updates the connection status with the corresponding terminal device in each local routing table. If one of the socket.io server nodes does not receive a heartbeat packet from the corresponding terminal device within a predetermined period of time, the terminal device is determined to be offline, and a cleanup operation is performed. The terminal device is initiated to automatically reconnect, and the connection with any socket.io server node is re-established through the load balancer.

5. A message push device based on socket.io, characterized in that, include: A connection establishment unit is used to deploy a load balancer and multiple socket.io server nodes, and to establish a connection between the terminal device and any of the socket.io server nodes through the load balancer; The message push unit is used to integrate the Kafka message queue into each socket.io server node and use the Kafka message queue to execute the message push process from the platform to the terminal device. The deployment of a load balancer and multiple socket.io server nodes, and the establishment of a connection between the terminal device and any of the socket.io server nodes through the load balancer, includes: Nginx is pre-installed as a load balancer, and load balancing strategies and WebSocket proxy are configured. The load balancing strategies include round-robin, weighted round-robin, and least connections first strategies. Multiple socket.io server nodes were built using the Express framework based on Node.js; When a connection request is received from a terminal device, it is forwarded to one of the socket.io server nodes through the load balancer, and authentication is performed. Register the authenticated terminal devices and establish a connection with the current socket.io server node, and save the connection relationship between the terminal devices and the current socket.io server node to the local routing table; The integration of the Kafka message queue into each socket.io server node includes: Install a Kafka cluster on the server and configure message topics for the Kafka cluster; Integrate the Kafka client library into each socket.io server node, and connect to the Kafka cluster through the Kafka client library to integrate the Kafka message queue; The process of pushing messages from the Kafka message queue execution platform to the terminal device includes: The receiving platform sends a message push request to the terminal device, sends the message push request to the load balancer via the HTTP protocol, and forwards the message push request to any socket.io server node through the load balancer; Query the local routing table of the socket.io server node that received the message push request. If the target terminal device is found in the local routing table, push the message directly. If the target terminal device is not found in the local routing table, the push message request is published to the Kafka cluster through the Kafka client library; The Kafka cluster notifies other socket.io server nodes to subscribe and queries the local routing tables of each socket.io server node until the target terminal device is found in one of the local routing tables, and then pushes the message.

6. A computer device, characterized in that, It includes a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the message push method as described in any one of claims 1 to 4.

7. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, implements the message push method as described in any one of claims 1 to 4.

Images