A long connection message pushing method, device and system in a double-site environment

Abstract

The application relates to the technical field of Internet, in particular to a long-connection message pushing method, device and system under a double-station environment. In the application, the long-connection instance responsible for the message for the first time is responsible for the message, the long-connection pushing service is regarded as a unified whole, the message middleware is decoupled and combined with a message re-delivery mechanism, the problem of invalid double-station load balancing under high concurrency is effectively solved through the re-delivery mode of the message. Under the cooperation of the message middleware and the message re-delivery double measures, the consistency of the user connection service and the message pushing service can be ensured, so that efficient long-connection pushing under the double-station environment is realized, and the message pushing accuracy under the double-station environment is ensured. The application solves the problem of lacking effective long-connection message pushing scheme under the double-station environment.

Description

Technical Field

[0001] This invention relates to the field of Internet technology, and in particular to a method, apparatus and system for long-connection message push in a dual-site environment. Background Technology

[0002] With the development of internet technology, especially the rise of mobile internet and real-time applications, users' demands for the real-time nature and interactivity of information are increasing. Traditional client-side polling methods have poor real-time performance and can no longer meet the needs of modern applications; moreover, frequent requests lead to unnecessary resource consumption. Especially in multi-environment deployment scenarios—where there are two or more independent but collaborative environments (such as development, testing, and production environments)—ensuring the consistency and accuracy of cross-environment message pushes becomes a major challenge. Particularly in long-connection push services, because message generation and consumption may occur in different environments, routing and client-side misidentification can easily lead to missed or incorrect message delivery.

[0003] To address the above problems, many solutions have been proposed, such as:

[0004] WebSocket Protocol: As the foundation of real-time communication, WebSocket provides a low-latency data transmission channel and is a key technology for realizing long-connection message push.

[0005] Message queues, such as RabbitMQ and Kafka, are used to asynchronously transmit messages between producers and consumers, enabling message storage and distribution.

[0006] Event-driven architecture: Through an event-triggered mechanism, system components can respond to specific events without continuous querying or polling, thus improving the system's response speed and efficiency;

[0007] Load balancing technology: Distributes client requests through load balancers (such as Nginx and HAProxy) to ensure high availability and stability of the service;

[0008] Distributed systems and microservice architecture: Decompose the system into multiple independent services, each responsible for a part of the functions, and communicate with each other through APIs, which enhances the scalability and flexibility of the system;

[0009] Security mechanisms include, but are not limited to, TLS / SSL encryption, OAuth authentication, and JWT (JSON Web Tokens) to ensure secure data transmission and user authentication.

[0010] The long-connection service employs a dual-site maintenance strategy. However, in a dual-site environment, the long-connection service cannot intelligently detect the user's geographical location, leading to unnecessary duplicate message pushes, which consumes resources and impacts efficiency. While the above solutions can improve message sending success rate and efficiency in specific environments, they are unlikely to achieve the desired results in a dual-site environment and are more suitable for short-connection message push methods.

[0011] In summary, current dual-site environments struggle to guarantee the success rate and timeliness of long-connection message push, and existing technologies lack solutions. Summary of the Invention

[0012] To overcome the shortcomings of existing technologies that lack an effective solution for long-connection message push in a dual-site environment, this invention proposes a long-connection message push method for a dual-site environment. This method is scalable and robust, ensuring that messages can be correctly identified and pushed, thus guaranteeing the timeliness and accuracy of long-connection message push in a dual-site environment.

[0013] This invention proposes a long-connection message push method in a dual-site environment:

[0014] When a user comes online, they are added to any long-lived connection instance, and the user's connection information is recorded by Redis.

[0015] When a message producer sends a message associated with that user, it defines the long-lived connection instance that consumes the message as the party involved.

[0016] Determine whether the party in question is a long-lived connection instance associated with the user;

[0017] If so, the party concerned will send the message to the user;

[0018] If not, the party concerned queries Redis to obtain the long connection instance information of the user's connection and sends the message to the long connection instance associated with the user through the message middleware; the long connection instance associated with the user then sends the message to the user.

[0019] Preferably, it includes the following steps:

[0020] S1. Configure the message middleware and long-connection instance in the service registry, and configure the binding relationship between the message middleware and the long-connection instance;

[0021] S2: The message middleware listens to the message producer and receives messages; long-connection instances randomly consume messages from the message middleware and extract specified users from the messages.

[0022] S3. Long-connection instances determine whether a specified user exists in the user set bound to them;

[0023] If yes, the long-connection instance will send the message to the specified user;

[0024] No, proceed to step S4;

[0025] S4. The long-connection instance queries the long-connection instance bound to the specified user, and then sends the message and the long-connection instance bound to the specified user to the message middleware.

[0026] S5. The message middleware sends the message to the long-connection instance bound to the specified user, and the long-connection instance bound to the specified user sends the message to the specified user.

[0027] Preferably, the service registry is Nacos, Zookeeper, or Consul.

[0028] Preferably, RabbitMQ, RocketMQ, or Kafka are used as the message middleware.

[0029] Ideally, Redis should be configured for active-active synchronization.

[0030] Preferably, the user connection information includes user identity information (session).

[0031] Preferably, the message producer steals the SDK interface box message middleware to send messages.

[0032] The present invention also proposes a long-connection message push device in a dual-site environment, which is applied to a load balancing module and includes: a request listening unit, a user listening unit and a message distribution unit;

[0033] The request listening unit is used to listen for message push requests from message producers and notify the message distribution unit; it is also used to listen for user connection requests; message push requests contain the identity information of the specified user, and user connection requests contain the user's identity information.

[0034] The user listening unit is used to obtain user connection requests and user online status. When a user connection request is obtained, a long connection instance is assigned to the user for binding.

[0035] The message distribution unit is used to send messages and message push requests to the message middleware and notify long-connection instances to consume them.

[0036] This invention also proposes a long-connection message push system in a dual-site environment, comprising: a message push device, a message consumption module, a message sending module, and a database module;

[0037] The message push device, as described above, includes a request listening unit, a user listening unit, and a message sending unit;

[0038] The database module is used to obtain the binding information between users and long-connection instances generated by the user monitoring unit, and to store the user identity information and binding information. When the user monitoring unit learns that a user has gone offline, it notifies the database module to delete the user identity information and binding information to ensure that the database module only records online users.

[0039] The message consumption module is used to manage the consumption of information from the message middleware by long-connection instances; for each message, only one long-connection instance consumes it, avoiding congestion caused by multiple long-connection instances consuming at the same time;

[0040] The message sending module is used to send messages consumed by long-connection instances to the user specified in the message.

[0041] Preferably, it also includes a log monitoring and management platform for recording log information.

[0042] The advantages of this invention are:

[0043] (1) The long-connection message push method proposed in this invention treats the long-connection push service as a unified whole, combining message middleware decoupling with a message re-delivery mechanism. Through message re-delivery, it effectively solves the problem of load balancing failure in high-concurrency scenarios. With the combined measures of message middleware and message re-delivery, the consistency between the user connection establishment service and the message push service can be ensured, thereby achieving efficient long-connection push in a dual-site environment and ensuring the accuracy of message push in the dual-site environment.

[0044] (2) In this invention, by redirecting messages through the message middleware, the long-connection instance is treated as a whole. The message producer only needs to send messages, and the message transmission is completed by the long-connection instance, which simplifies the process of message push producers and consumers and provides convenience for subsequent troubleshooting. The message producer normally pushes messages to the message middleware, and in subsequent troubleshooting, it can directly troubleshoot in the long-connection service.

[0045] (3) In long-connection services, logs are collected and managed through a monitoring platform at key points in the message consumption process. Through log monitoring and management, the entire message consumption process is displayed on the monitoring platform, effectively improving the efficiency of troubleshooting message push anomalies.

[0046] (4) By using long-connection services in a dual-site environment, the real-time performance and accuracy of user message pushes can be effectively improved. Long-connection services in a dual-site environment do not affect each other, effectively improving the availability and stability of the entire system. In the online production environment, the geographically distributed active-active service can protect the overall system service. Geographically distributed active-active can ensure that if the service in one area is abnormal, the service in the other area will continue to operate normally, achieving high availability of the system.

[0047] (5) By adding message redelivery to the long-connection server, the service instance where the user establishes a connection can be accurately located, saving the overall system maintenance cost. If you want to accurately locate the service instance where the user establishes a connection through system load balancing, you need to improve it in two ways. On the one hand, you can improve it through hardware, that is, by using routing. On the other hand, you can improve it at the software level, that is, by improving the load balancing capability of the server. At present, the most common way to improve the system load balancing capability of long-connection push messages is through software, mainly by using nginx's ip-hash method to ensure that the long-connection instance for each user connection is fixed. This method can achieve accurate message push to a certain extent. However, if the current service instance is abnormal, message push failure is likely to occur. This invention uses message middleware decoupling message redelivery to optimize message consumption logic, avoid repeated cache or database operations as much as possible, and use the service container IP and environment variables as the routing key of the message queue for message redelivery. This perfectly avoids the service instance abnormality problem when using nginx + ip-hash method, so that the overall long-connection instance can push messages efficiently.

[0048] (6) The entire message consumption process is displayed on the monitoring and management platform through the log monitoring and management platform, which effectively improves the efficiency of troubleshooting abnormal message push issues. Attached Figure Description

[0049] Figure 1 A flowchart of a long-connection message push method in a dual-site environment;

[0050] Figure 2 This is a flowchart of the long-connection message push method in a dual-site environment as described in the embodiment. Detailed Implementation

[0051] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of the present invention.

[0052] Reference Figure 1 This invention proposes a long-connection message push method in a dual-site environment. When a user comes online, they are added to any long-connection instance, and the user's connection information session is recorded in a dual-active synchronized Redis. When the message producer sends a message associated with the user, the long-connection instance that consumes the message is defined as the party. It is then determined whether the party is the long-connection instance associated with the user.

[0053] If so, the party concerned will send the message to the user;

[0054] If not, the party concerned queries Redis to obtain the long connection instance information of the user's connection and sends the message to the long connection instance associated with the user through the message middleware; the long connection instance associated with the user then sends the message to the user.

[0055] Compared to existing technologies that require all long-connection instances to consume information before sending it to a designated user, this invention assigns the responsibility to the long-connection instance that first consumes the message. In this way, a message can be pushed to a designated user by a maximum of only two long-connection instances, which greatly saves communication resources, reduces the use of middleware and long-connection instances, and improves message push efficiency.

[0056] like Figure 2 As shown in the specific embodiment, the method includes the following steps:

[0057] S1. The service registry Nacos is configured with the message middleware RabbitMQ and long-connection instances, with multiple long-connection instances configured. When a user comes online, connection requests obtain service allocation information through the load balancer Nginx, which is used to bind to the long-connection instance specified in the service allocation information. The bound long-connection instance stores the user's identity information session in its own user set, and the information of the user bound to the long-connection instance is stored in a dual-active synchronized Redis. When a user goes offline, the user's identity information is deleted from the user set of the corresponding long-connection instance, and the binding information corresponding to that user is deleted from Redis.

[0058] In practice, the service registry can be Zookeeper (ZK) or Consul; the message middleware can be RocketMQ or Kafka.

[0059] S2. The message middleware listens to the message producer and receives messages; the long-connection instance randomly consumes messages from the message middleware and extracts the specified user from the messages, that is, it identifies the specified user based on the session.

[0060] S3. The long-connection instance determines whether the specified user exists in its bound user set. Since the user information is recorded by the long-connection instance when the user comes online, the long-connection instance only needs to perform identity comparison to determine whether the specified user is bound to the long-connection instance.

[0061] If yes, the long-connection instance will send the message to the specified user;

[0062] No, proceed to step S4;

[0063] S4. The long-connection instance queries the long-connection instance bound to the specified user in Redis, and then sends the message and the long-connection instance bound to the specified user to the message middleware.

[0064] S5. The message middleware sends the message to the long-connection instance bound to the specified user, and the long-connection instance bound to the specified user sends the message to the specified user.

[0065] In this embodiment, only one long-connection instance consumes messages at a time, avoiding the redundant pressure caused by multiple long-connection instances consuming messages simultaneously. At the same time, the long-connection instance is fully responsible for the messages. For messages that are not its responsibility, it queries the binding relationship of a specified user and pushes them to the message middleware together with the messages, which facilitates the message middleware to redeliver messages in a targeted manner and improves message transmission efficiency.

[0066] The data statistics after the method of this embodiment was applied in practice are shown in Table 1.

[0067] Table 1: Message Transmission Details in This Embodiment

[0068]

[0069] In the current message push system, all long-connection instances consume messages, then each determines whether a specific user is bound to it. The long-connection instance bound to the specified user pushes the message to that user, while other long-connection instances abandon message push. The current message push effect is shown in Table 2.

[0070] Table 2: Traditional Message Push Situation

[0071]

[0072]

[0073] The data in Tables 1 and 2 above were obtained through log processing. Comparing Tables 1 and 2, it can be seen that the method of the present invention significantly reduces the omission of message pushes and improves the message sending success rate by about 10%.

[0074] This embodiment also proposes a long-connection message push system in a dual-site environment, which includes: a message push device, a message consumption module, a message sending module, and a database module.

[0075] The message push mechanism is used to listen for messages generated by message producers and send them to long-connection instances. Specifically, the message push mechanism is applied to the load balancing module and includes a request listening unit, a user listening unit, and a message distribution unit.

[0076] The request listening unit is used to listen for message push requests from message producers and notify the message distribution unit; the message push request contains the identity information of the specified user.

[0077] The user listening unit is used to acquire user connection requests and user online status. When a user connection request is acquired, a long-lived connection instance is assigned to the user for binding. The user connection request contains user identity information. Specifically, after the user listening unit detects a user connection request, it assigns a long-lived connection instance to the user, and then the database module records the user and the binding status of the user with the long-lived connection instance. The database module deletes the records related to the user when the user goes offline.

[0078] The message distribution unit is used to send messages and message push requests to the message middleware and notify long-connection instances to consume them.

[0079] The database module is used to obtain the binding information between users and long-connection instances generated by the user monitoring unit, and to store the user identity information and binding information. When the user monitoring unit learns that a user has gone offline, it notifies the database module to delete the user identity information and binding information to ensure that the database module only records online users.

[0080] The message consumption module is used to manage the consumption of information from the message middleware by long-connection instances. For each message, only one long-connection instance consumes it, avoiding congestion caused by multiple long-connection instances consuming at the same time.

[0081] The message sending module is used to send messages consumed by long-connection instances to the user specified in the message.

[0082] Specifically, when the message middleware receives a message sent by the message producer, the message consumption module randomly notifies a long-connection instance to consume the message.

[0083] If the long-connection instance corresponds to the specified user of the message, then the long-connection instance will push the message to the specified user through the message sending module.

[0084] If the long-connection instance subsequently discovers that the specified user for the message is not under its management, the long-connection instance executes a database query module to obtain the binding information of the specified user. Then, the long-connection instance sends the message and the binding information of the specified user to the message middleware. The message middleware retrieves the long-connection instance bound to the specified user from the binding information of the specified user and pushes the message to the long-connection instance bound to the specified user. The long-connection instance then pushes the message to the specified user through the message sending module, realizing secondary targeted push of the message.

[0085] Of course, those skilled in the art will recognize that the present invention is not limited to the details of the exemplary embodiments described above, but also includes the same or similar structures that can be implemented in other specific forms without departing from the spirit or essential characteristics of the invention. Therefore, the embodiments should be considered illustrative and non-limiting in all respects, and the scope of the invention is defined by the appended claims rather than the foregoing description. Thus, all variations falling within the meaning and scope of equivalents of the claims are intended to be included within the present invention. No reference numerals in the claims should be construed as limiting the scope of the claims.

[0086] Furthermore, it should be understood that although this specification describes embodiments, not every embodiment contains only one independent technical solution. This narrative style is merely for clarity. Those skilled in the art should consider the specification as a whole, and the technical solutions in each embodiment can also be appropriately combined to form other embodiments that can be understood by those skilled in the art.

[0087] The technologies, shapes, and structures not described in detail in this invention are all known technologies.

Claims

1. A method for long-connection message push in a dual-site environment, characterized in that: When a user comes online, they are added to any long-lived connection instance, and the user's connection information is recorded by Redis. When a message producer sends a message associated with that user, it defines the long-lived connection instance that consumes the message as the party involved. Determine whether the party in question is a long-lived connection instance associated with the user; If so, the party concerned will send the message to the user; No, the party concerned queries Redis to obtain the long connection instance information of the user's connection, and sends the message to the long connection instance associated with the user through the message middleware; The long-lived connection instance associated with the user sends the message to the user; Includes the following steps: S1. Configure the message middleware and long-connection instance in the service registry, and configure the binding relationship between the message middleware and the long-connection instance; S2: The message middleware listens to the message producer and receives messages; long-connection instances randomly consume messages from the message middleware and extract specified users from the messages. S3. Long-connection instances determine whether a specified user exists in the user set bound to them; If yes, the long-connection instance will send the message to the specified user; No, proceed to step S4; S4. The long-connection instance queries the long-connection instance bound to the specified user, and then sends the message and the long-connection instance bound to the specified user to the message middleware. S5. The message middleware sends the message to the long-connection instance bound to the specified user, and the long-connection instance bound to the specified user sends the message to the specified user.

2. The long-connection message push method in a dual-site environment as described in claim 1, characterized in that, The service registry can be Nacos, Zookeeper, or Consul.

3. The long-connection message push method in a dual-site environment as described in claim 1, characterized in that, The message middleware used is RabbitMQ, RocketMQ, or Kafka.

4. The long-connection message push method in a dual-site environment as described in claim 1, characterized in that, Configure Redis to be active-active and synchronized.

5. The long-connection message push method in a dual-site environment as described in claim 1, characterized in that, User connection information includes user identity information and session.

6. The long-connection message push method in a dual-site environment as described in any one of claims 1-5, characterized in that, The message producer is stealing the SDK interface box message middleware to send messages.

7. A long-connection message push device for a dual-site environment, employing the long-connection message push method as described in any one of claims 1-6, applied to a load balancing module, characterized in that, include: Request listening unit, user listening unit, and message dispatch unit; The request listening unit is used to listen for message push requests from message producers and notify the message distribution unit. It is also used to listen for user connection requests; message push requests contain the identity information of a specified user, and user connection requests contain the user's identity information. The user listening unit is used to obtain user connection requests and user online status. When a user connection request is obtained, a long connection instance is assigned to the user for binding. The message distribution unit is used to send messages and message push requests to the message middleware and notify long-connection instances to consume them.

8. A long-connection message push system in a dual-site environment, characterized in that, include: The system includes a message push device, a message consumption module, a message sending module, and a database module. The message push device adopts the long connection message push device in a dual-site environment as described in claim 7, which includes a request listening unit, a user listening unit, and a message sending unit; The database module is used to obtain the binding information between users and long-connection instances generated by the user listening unit, and to store the user identity information and binding information. When the user monitoring unit detects that a user has gone offline, it notifies the database module to delete the user's identity information and binding information. This ensures that the database module only records online users; The message consumption module is used to manage the consumption of information from the message middleware by long-connection instances; for each message, only one long-connection instance consumes it, avoiding congestion caused by multiple long-connection instances consuming at the same time; The message sending module is used to send messages consumed by long-connection instances to the user specified in the message.

9. The long-connection message push system in a dual-site environment as described in claim 8, characterized in that, It also includes a log monitoring and management platform for recording log information.

Images