A conference message pushing method, a conference server, an electronic device and a storage medium

Abstract

Embodiments of the present application disclose a conference message pushing method, a conference server and electronic equipment. The method comprises: establishing a long connection between a plurality of service instances carrying socket io microservices and a plurality of socket io clients respectively; receiving a conference service event from the socket io client by the service instance; processing the conference service event based on a preset remote dictionary service (Red i s) template by a producer to obtain a conference message corresponding to the conference service event, and adding the conference message to a Red i s message queue; continuously consuming the conference message in the Red i s message queue by a consumer, and sending the conference message to each service instance, so that the service instance pushes the conference message to the corresponding socket io client. The conference message between the service instances is shared through the lightweight Red i s message queue, load balancing of the client connecting the server is achieved, the Red i s queue is used to realize production and consumption, and the socket io framework is used to connect the server and the client, thereby improving the timeliness of the conference message pushing.

Description

Technical Field

[0001] This invention relates to the field of communication technology, and in particular to a method for pushing conference messages, a conference server, and an electronic device. Background Technology

[0002] With container technologies such as Docker (an open-source application container engine) and Kubernetes (a portable container orchestration and management tool) becoming increasingly mainstream, transmission services such as digital conferencing are gradually moving to the cloud. Kubernetes' elastic scaling of containers has effectively replaced traditional service clusters, providing more flexible support for business demands. However, existing technologies have some drawbacks: in cloud scenarios, communication between the server and clients based on Socket.io (a bidirectional communication and data exchange technology between clients and servers) means that messages from different clients can only interact with the same server replica instance. Communication forwarding issues exist between multiple replica instances, preventing the full utilization of replica scaling advantages. Existing solutions include two approaches: one is through business constraints, such as all clients connecting to the same server instance in a conference. In this case, server load balancing cannot be easily achieved, requiring customized Nginx (engine x, a high-performance hypertext transfer protocol and reverse proxy web server) for forwarding; the other approach uses Kafka (a high-throughput distributed publish-subscribe messaging system) for communication between server replicas. This approach is not lightweight or convenient enough, and its real-time performance is difficult to guarantee. Summary of the Invention

[0003] The following is an overview of the subject matter described in detail herein. This overview is not intended to limit the scope of the claims.

[0004] This invention provides a meeting message push method, a meeting server, and an electronic device, which can achieve load balancing between client and server connections. At the same time, it fully utilizes the instant queue creation and destruction characteristics of the Remote Dictionary Server (Redis) and connects the server and client through the Socket.io framework, thereby improving the timeliness of meeting message push.

[0005] In a first aspect, embodiments of the present invention provide a meeting message push method, applied to a socketio server, the method comprising:

[0006] Long connections are established between multiple service instances that host socketio microservices and multiple socketio clients.

[0007] The service instance receives conference service events from the socketio client;

[0008] The producer processes the meeting business events based on a pre-configured remote dictionary service Redis template to obtain the meeting message corresponding to the meeting business event, and adds the meeting message to the Redis message queue.

[0009] The consumer continuously consumes the meeting messages in the Redis message queue and sends the meeting messages to each of the service instances, so that the service instances can push the meeting messages to the corresponding socketio clients.

[0010] Secondly, embodiments of the present invention provide a conference server, including:

[0011] The connection module is used to establish long connections with multiple socketio clients through multiple service instances carrying socketio microservices, wherein each socketio client establishes a long connection with one of the service instances.

[0012] The receiving module is used to receive conference service events from the socketio client through the service instance;

[0013] The producer module is used to process the meeting business events according to the preset remote dictionary service Redis template, obtain the meeting message corresponding to the meeting business event, and add the meeting message to the Redis message queue;

[0014] The consumer module is used to continuously consume conference messages in the Redis message queue and send the conference messages to each of the service instances, so that the service instances can push the conference messages to the corresponding socketio clients.

[0015] Thirdly, embodiments of the present invention provide an electronic device, including: a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, it implements the meeting message push method described above.

[0016] Fourthly, embodiments of the present invention provide a computer-readable storage medium storing a computer program, which, when executed by a processor, implements the meeting message push method described above.

[0017] The solution of this invention can achieve load balancing between client and server connections; at the same time, it makes full use of the instantaneous production and consumption characteristics of Redis queues and connects the server and client through the socketio framework, thereby improving the timeliness of meeting message push.

[0018] Other features and advantages of the invention will be set forth in the description which follows, and will be apparent in part from the description, or may be learned by practicing the invention. The objects and other advantages of the invention may be realized and obtained by means of the structures particularly pointed out in the description, claims and drawings. Attached Figure Description

[0019] The accompanying drawings are provided to further understand the technical solutions of the present invention and constitute a part of the specification. They are used together with the embodiments of the present invention to explain the technical solutions of the present invention, and do not constitute a limitation on the technical solutions of the present invention.

[0020] Figure 1 This is a flowchart illustrating a meeting message push method;

[0021] Figure 2 yes Figure 1 A schematic diagram illustrating a specific implementation process of step S1000;

[0022] Figure 3 yes Figure 1 A schematic diagram illustrating a specific implementation process of step S3000 in the middle section;

[0023] Figure 4 yes Figure 3 A schematic diagram of a specific implementation process of step S3300;

[0024] Figure 5 yes Figure 1 A schematic diagram illustrating a specific implementation process of step S4000 in the middle section;

[0025] Figure 6 This is a structural diagram of a conference server provided in another embodiment of the present invention;

[0026] Figure 7 This is a schematic diagram of the structure of an electronic device provided in another embodiment of the present invention. Detailed Implementation

[0027] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the invention.

[0028] It should be understood that in the description of the embodiments of the present invention, the use of terms such as "first" and "second" is only for the purpose of distinguishing technical features and should not be construed as indicating or implying relative importance, or implicitly indicating the number of technical features indicated, or implicitly indicating the sequential relationship of the technical features indicated. "At least one" refers to one or more, and "more" refers to two or more. "And / or" describes the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent the existence of A alone, the simultaneous existence of A and B, or the existence of B alone. A and B can be singular or plural. The character " / " generally indicates that the preceding and following related objects are in an "or" relationship. "At least one of the following" and similar expressions refer to any combination of these items, including any combination of single or plural items. For example, at least one of a, b, and c can represent: a, b, c, a and b, a and c, b and c, or a and b and c, where a, b, and c can be single or multiple.

[0029] Furthermore, the technical features involved in the various embodiments of the present invention described below can be combined with each other as long as they do not conflict with each other.

[0030] The conference message push method based on the Socket.io framework disclosed in this invention is an efficient means of message transmission between the server and the client, effectively ensuring the timeliness of conference message push and is widely used in existing digital conferencing systems. In practical application environments of conferencing systems, traditional conference message push methods suffer from communication forwarding problems, especially when multiple clients are connected. Load balancing between the client and server is difficult to achieve, and the real-time transmission of conference information cannot be guaranteed.

[0031] In related technologies, there are two ways to achieve fast transmission of meeting information in a conference system based on the Socket.io framework. One is through business constraints, such as all clients in a conference connecting to the same server instance. In this case, the conference information needs to be forwarded by Nginx according to the business, which cannot easily achieve server load balancing. The other solution is to achieve communication between server replicas through message queues such as Kafka. This makes the service instance of the conference server less lightweight and convenient, and it is difficult to meet the requirements of real-time performance.

[0032] In this embodiment, the meeting service includes two roles: producers and consumers. Producers generate meeting service messages, while consumers process these messages to achieve specific functions. Producers and consumers communicate via message queues. This application does not limit the number of producers or consumers; these numbers can be set according to the specific needs of the meeting scenario.

[0033] Based on the above, embodiments of the present invention provide a meeting message push method, a meeting server, and an electronic device, which can achieve load balancing between client and server connections; at the same time, by making full use of the instant-deletion feature of Redis queues and connecting the server and client through the socketio framework, the timeliness of meeting message push is improved.

[0034] Please see Figure 1 , Figure 1 This diagram illustrates a flowchart of a meeting message push method provided by an embodiment of the present invention. Figure 1 As shown, the meeting message push method of this embodiment includes the following steps:

[0035] The S1000 establishes long-lived connections with multiple socketio clients through multiple service instances that carry socketio microservices.

[0036] It should be understood that Socket.io is a mature solution based on the WebSocket protocol (a protocol for full-duplex communication over a single Transmission Control Protocol connection). It's a bidirectional communication and data exchange technology established between the client and server, offering advantages such as high transmission performance and support for multiple platforms. Using a persistent connection based on the Socket.io framework between the client and server effectively ensures the real-time transmission of conference information and improves the connection stability between the client and server.

[0037] For example, a client can access a cloud server's socketio-server (a socketio-based server) through socketio-client (a socketio-based client library) to complete socket connection establishment and account verification login, thereby establishing a long connection between the client and the server.

[0038] It should be understood that microservices are a variation of Service-Oriented Architecture (SOA) in software development, where applications are structured as a set of loosely coupled services. Therefore, microservices are an architectural and organizational approach to developing software where it consists of small, independent services that communicate through well-defined Application Programming Interfaces (APIs). As can be seen, microservice architecture makes applications easier to scale and faster to develop, thereby accelerating innovation, shortening the development time for new features, and effectively improving the development efficiency of conferencing systems.

[0039] It should be understood that microservices are characterized by single responsibility, service autonomy, lightweight communication, and clear interfaces. By configuring the socketio microservice in the service instance, a long-lived connection that enables real-time communication can be established between the service instance and the client under the socketio framework.

[0040] It should be understood that, to ensure connectivity between the Socket.io client and the Socket.io server, each Socket.io client establishes a long-lived connection with a service instance through the Socket.io microservice. At the same time, to improve the resource utilization of the service instance, the same service instance can establish long-lived connections with multiple Socket.io clients simultaneously through the Socket.io microservice. Especially when broadcasting conference information, the service instance can process conference information for multiple Socket.io clients simultaneously, further improving the timeliness of conference information transmission.

[0041] For details on the implementation process, please refer to Figure 2 , Figure 2 A schematic diagram illustrating a specific implementation process of step S1000 above is shown. For example... Figure 2 As shown, step S1000 includes at least the following steps:

[0042] S1100 builds multiple service instances on the socketio server to host socketio microservices.

[0043] It should be understood that building multiple service instances facilitates connections between the Socket.io server and multiple Socket.io clients. Specifically, changing the number of service instances allows for direct scaling of the conferencing service, enabling planning and control over the scale of the conferencing system. Furthermore, each service instance is an isolated container, limiting its CPU and memory consumption. The containers are built and started very quickly, ensuring timely information exchange between the service instances and Socket.io clients.

[0044] It should be understood that the service instance hosts the socketio microservice, which can quickly establish a long-lived connection based on the socketio framework between the service instance and the client, enabling real-time communication between the service instance and the socketio client.

[0045] S1200 determines the correspondence between service instances and socketio clients based on preset connection rules.

[0046] It should be understood that, to address the needs of different meeting environments, connection rules between service instances and socketio clients are preset. For example, to ensure connectivity between service instances and various socketio clients and to effectively utilize server-side performance resources, the preset connection rules employ load balancing. Load balancing distributes the workload across multiple operating units. In a meeting system, this means optimizing the connections between multiple service instances and socketio clients to prevent service instances from exceeding their load limits, thereby achieving fast and efficient transmission of meeting events while conserving server-side resources.

[0047] It should be understood that, according to the load balancing connection rules, when determining the service instance to which each socketio client is connected, the utilization rate of the service instances is ensured to be balanced, avoiding large differences in the utilization rates of service instances. It should also be understood that the mapping between socketio clients and service instances will change as the server operates. For example, as the number of socketio clients connected to a service instance increases, in order to rationally allocate the resources used by the service instance, socketio clients will be mapped to other service instances to ensure that service instances and socketio clients are matched and connected according to the connection rules, thereby improving the operating efficiency of the conferencing system.

[0048] It should be understood that by performing autoscaling on service instances, scaling rules can be set according to meeting business needs and strategies. When meeting business needs increase, service instances are automatically added to the server to ensure meeting information reception and processing capacity; when meeting business needs decrease, service instances are automatically reduced to save costs. Therefore, autoscaling is suitable not only for meeting systems with fluctuating business volume but also for meeting systems with stable business volume.

[0049] For example, a socketio client can connect to any service instance via IP-hash (mapping the IP address of a user request into a hash value and then assigning it to a specific server) or round-robin. This allows the server to easily achieve load balancing without intruding on business logic, and the connection stability and reliability between the service instance and the socketio client are higher. The impact on the transmission of conference business events is also smaller when one service instance goes down.

[0050] S1300: Based on the correspondence between service instances and socketio clients, the service instance establishes a long connection with the corresponding socketio client through the socketio client connection pool.

[0051] It should be understood that configuring a socketio client connection pool facilitates the creation and management of a buffer pool of long-lived connections between service instances and socketio clients. These connections are ready to be used by any socketio microservice that needs them. Therefore, connection pooling can effectively reduce the connection creation time between service instances and socketio clients, simplify the system's programming model, and save system resources.

[0052] In practice, multiple Socket.io clients can connect to the same service instance, which not only improves the resource utilization of the service instance but also ensures that each Socket.io client establishes a long connection with the corresponding service instance. Furthermore, it enhances the business connectivity between multiple Socket.io clients connected to the same service instance, ensuring the stability and timeliness of conference service transmission.

[0053] The S2000 receives conference service events from the socketio client through the service instance.

[0054] It should be understood that by receiving conference events through a long connection with the socketio client, the service instance can ensure that the conference events from the socketio client can be transmitted to the server quickly and stably, avoiding delays or loss in the transmission of conference events and ensuring the timeliness and continuity of conference message push.

[0055] The S3000 processes meeting business events through the producer based on a pre-configured remote dictionary service Redis template, obtains the meeting messages corresponding to the meeting business events, and adds the meeting messages to the Redis message queue.

[0056] Please see Figure 3 , Figure 3 A schematic diagram illustrating a specific implementation process of step S3000 above is shown. For example... Figure 3 As shown, step S3000 includes at least the following steps:

[0057] Configure the remote dictionary service Redis template in the service instance of S3100.

[0058] It should be understood that by configuring the remote dictionary service Redis template, producers can quickly and accurately call relevant commands and cached data in the Redis message queue, thereby improving the efficiency and convenience of system development.

[0059] The S3200 obtains meeting service events from the service instance through the socketio client connection pool.

[0060] It should be understood that configuring a socketio client connection pool allows for the rapid acquisition of meeting service events from a service instance. In practical application development, especially in World Wide Web (WEB) application systems, directly accessing data in a database requires each data access request to go through steps such as establishing a database connection, opening the database, storing and retrieving data, and closing the database connection. Connecting to and opening a database is a resource-intensive and time-consuming task. If such database operations occur frequently, system performance will inevitably degrade sharply, and may even lead to system crashes. Therefore, connection pooling technology is the most common method to solve this problem, and it is widely used in many application servers.

[0061] It should be understood that the idea behind connection pooling technology is to store service instances and socketio client connections as objects in a single object. Once a connection is established, access requests for remote dictionary service Redis templates can share these connections. In this way, by reusing these established connections, the aforementioned drawbacks of consuming resources and time can be overcome, greatly saving resources and time for the conferencing system.

[0062] It should be understood that meeting service events are mainly divided into broadcast events and non-broadcast events based on the flow and scope of the meeting service. Broadcast events include clients sending group messages to other clients within the meeting, clients needing to configure permissions for other clients, etc.; non-broadcast events include point-to-point message exchanges between a service instance and connected clients, communication between two or more clients, client login and logout operations, etc. Therefore, after obtaining the meeting service events in the service instance, the meeting service events are judged and analyzed. If the meeting service event is a broadcast event, step S3300 is executed; if the meeting service event is a non-broadcast event, step S3400 is executed.

[0063] In the case of a broadcast event, the S3300 uses a remote dictionary service (Redis template) to transform the conference event into a conference message and adds the conference message to the Redis message queue.

[0064] It should be understood that broadcast events require the forwarding of conference messages to clients connected to the current service instance. This is handled through Redis message queues, which share conference messages between service instances. By leveraging the instant-delete characteristic of Redis message queues, the forwarding function of multiple service instances can be implemented, effectively improving the transmission efficiency and accuracy of conference messages.

[0065] Please see Figure 4 , Figure 4 A schematic diagram illustrating a specific implementation process of step S3300 above is shown. For example...Figure 4 As shown, step S3300 includes at least the following steps:

[0066] S3310, configures a remote dictionary service Redis template, serializes meeting business events, and generates meeting messages;

[0067] It should be understood that serialization is the process of converting the state information of a conference event into a form that can be stored or transmitted—that is, transforming it into a conference message. During serialization, the conference event writes its current state to temporary or persistent storage. Later, the object can be recreated by reading or deserializing the state of the conference message from storage.

[0068] The S3320 uses a remote dictionary service Redis template to write meeting messages sequentially into a Redis message queue.

[0069] It should be understood that Redis message queues are non-persistent and characterized by rapid production and consumption. If the queue is empty, consumers are blocked and waiting when pulling messages. Once a new meeting message arrives, the consumer is notified to process the new meeting message immediately. Therefore, writing meeting messages into the Redis message queue in order effectively ensures the real-time delivery of meeting messages and avoids message loss and blocking.

[0070] In the case of S3400, when the conference service event is a non-broadcast event, the conference service event is transmitted to the target socketio client through the service instance.

[0071] It should be understood that when the conference business events are non-broadcast events, the socketio framework can be used directly to achieve accurate transmission of conference business events without going through the remote dictionary service Redis template publish-subscribe, which improves the transmission efficiency of conference business events and saves system operating resources.

[0072] The S4000 continuously consumes meeting messages from the Redis message queue through consumers and sends the meeting messages to various service instances, which then push the meeting messages to the corresponding socketio clients.

[0073] Please see Figure 5 , Figure 5 A schematic diagram illustrating a specific implementation process of step S4000 described above is shown. For example... Figure 5 As shown, step S4000 includes at least the following steps:

[0074] S4100 starts a message listening thread to listen for meeting messages in the Redis message queue;

[0075] It should be understood that listening to meeting messages in the Redis message queue through multiple consumers is the foundation for achieving fast consumption of meeting messages in the Redis message queue. Multiple service instances can collect and obtain meeting messages in the Redis message queue, avoiding blocking and loss of meeting messages.

[0076] In its implementation, the socketio microservice analyzes meeting messages in the Redis message queue by calling MessageListener (message listening instruction), which can listen to the attributes and importance of meeting messages, and then transmit the meeting messages quickly and accurately.

[0077] The functions of the socketio microservice are the same as those in step S1100, and will not be repeated here.

[0078] S4200 continuously consumes meeting messages from the Redis message queue;

[0079] It should be understood that continuously consuming meeting messages in the Redis message queue ensures that the meeting messages in the Redis message queue are delivered to the target client in an orderly and efficient manner, avoiding the situation where meeting messages are blocked or even lost due to excessive accumulation, which would affect the integrity of the meeting information transmission.

[0080] S4300 deserializes meeting information in the Redis message queue to generate push information;

[0081] It should be understood that when the server processes meeting information, it needs to deserialize the meeting information into a format that can be stored or transmitted, and then transform it into push information. The reverse operation of the data structure extracted from the series of bytes of the meeting information obtained in step S3310 forms the push information that the socketio client can directly read.

[0082] The S4400 pushes information to a specified socketio client via a service instance and a long connection.

[0083] It should be understood that pushing information to the target client through service instances and long connections not only improves the efficiency of pushing information, but also makes full use of the bidirectional communication data exchange connection based on Socket.io established between the client and the server, thereby improving the system's resource utilization.

[0084] Please see Figure 6 , Figure 6 A structural diagram of a conference server is shown. For example... Figure 6 As shown, the conference server includes:

[0085] The connection module 100 is used to establish long connections with multiple socketio clients through multiple service instances that carry socketio microservices.

[0086] The receiving module 200 is used to receive conference service events from the socketio client through the service instance.

[0087] The producer module 300 is used to process meeting business events according to the pre-set remote dictionary service Redis template, obtain the meeting message corresponding to the meeting business event, and add the meeting message to the Redis message queue.

[0088] Consumer module 400 is used to continuously consume conference messages in the Redis message queue and send the conference messages to various service instances, so that the service instances can push the conference messages to the corresponding socketio clients.

[0089] It should be noted that the information interaction and execution process of each module of the conference server are based on the same concept as the conference message push method provided in the embodiments of this invention. For details on its specific functions and technical effects, please refer to the embodiments section, which will not be repeated here.

[0090] It should be understood that the meeting message push method and meeting server provided in the embodiments of the present invention can be applied to cloud-based digital meeting scenarios with high business usage, including but not limited to scenarios such as converged video conferencing, remote case handling by procuratorates, and remote applications by telecom operators.

[0091] Please see Figure 7 , Figure 7 An electronic device 500 according to an embodiment of the present invention is shown. The electronic device 500 includes, but is not limited to:

[0092] Memory 520 is used to store programs;

[0093] The processor 510 is used to execute the program stored in the memory 520. When the processor 510 executes the program stored in the memory 520, the processor 510 is used to execute the above-mentioned conference message push method.

[0094] The processor 510 and memory 520 can be connected via a bus or other means.

[0095] The memory 520, as a non-transitory computer-readable storage medium, can be used to store non-transitory software programs and non-transitory computer-executable programs, such as the conference message push method described in any embodiment of the present invention. The processor 510 implements the above-described conference message push method by running the non-transitory software program and instructions stored in the memory 520.

[0096] The memory 520 may include a program storage area and a data storage area. The program storage area may store the operating system and applications required for at least one function; the data storage area may store the conference message push method described above. Furthermore, the memory 520 may include high-speed random access memory and may also include non-transitory memory, such as at least one disk storage device, flash memory device, or other non-transitory solid-state storage device. In some embodiments, the memory 520 may optionally include memory remotely located relative to the processor 510, and these remote memories may be connected to the processor 510 via a network. Examples of such networks include, but are not limited to, the Internet, intranets, local area networks, mobile communication networks, and combinations thereof.

[0097] The non-transient software program and instructions required to implement the above-described meeting message push method are stored in the memory 520. When executed by one or more processors 510, the meeting message push method provided in any embodiment of the present invention is executed.

[0098] This invention also provides a storage medium storing computer-executable instructions for executing the above-described meeting message push method.

[0099] In one embodiment, the storage medium stores computer-executable instructions that are executed by one or more control processors 510, such as one processor 510 in the electronic device 500, which can cause the one or more processors 510 to execute the meeting message push method provided in any embodiment of the present invention.

[0100] The embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs.

[0101] It will be understood by those skilled in the art that all or some of the steps and systems in the methods disclosed above can be implemented as software, firmware, hardware, and suitable combinations thereof. Some or all of the physical components can be implemented as software executed by a processor, such as a central processing unit, digital signal processor, or microprocessor, or as hardware, or as an integrated circuit, such as an application-specific integrated circuit. Such software can be distributed on a computer-readable medium, which can include computer storage media (or non-transitory media) and communication media (or transient media). As is known to those skilled in the art, the term computer storage media includes volatile and non-volatile, removable and non-removable media implemented in any method or technology for storing information (such as computer-readable instructions, data structures, program modules, or other data). Computer storage media includes, but is not limited to, RAM, ROM, EEPROM, flash memory or other memory technologies, CD-ROM, digital versatile disc (DVD) or other optical disc storage, magnetic cartridges, magnetic tape, disk storage or other magnetic storage devices, or any other medium that can be used to store desired information and is accessible to a computer. Furthermore, as is known to those skilled in the art, communication media typically include computer-readable instructions, data structures, program modules, or other data in modulated data signals such as carrier waves or other transmission mechanisms, and may include any information delivery medium.

[0102] The foregoing detailed description of preferred embodiments of the present invention is not limited to the above-described embodiments. Those skilled in the art can make various equivalent modifications or substitutions without departing from the spirit of the invention. All such equivalent modifications or substitutions are included within the scope defined by the claims of the present invention.

Claims

1. A method for pushing conference messages, applied to a socketio server, the method comprising: Long connections are established between multiple service instances that host socketio microservices and multiple socketio clients. The service instance receives conference service events from the socketio client; In the case that the meeting business event is a broadcast event, the producer processes the meeting business event based on a pre-configured remote dictionary service Redis template to obtain the meeting message corresponding to the meeting business event, and adds the meeting message to the Redis message queue; The consumer continuously consumes the meeting messages in the Redis message queue and sends the meeting messages to each of the service instances, so that the service instances can push the meeting messages to the corresponding socketio clients; If the conference service event is a non-broadcast event, the conference service event is transmitted to the target socketio client through the service instance.

2. The method according to claim 1, characterized in that, Before establishing long connections between multiple service instances carrying socketio microservices and multiple socketio clients respectively, the following steps are also included: On the socketio server, construct multiple service instances that host socketio microservices; The correspondence between the service instance and the socketio client is determined according to the preset connection rules.

3. The method according to claim 2, characterized in that, The process of establishing long connections between multiple service instances carrying socketio microservices and multiple socketio clients includes: Based on the correspondence between the service instance and the socketio client, the service instance establishes a long connection with the corresponding socketio client via the socketio client connection pool.

4. The method according to claim 3, characterized in that, The process of processing the meeting business event by the producer based on a pre-configured remote dictionary service Redis template to obtain the meeting message corresponding to the meeting business event, and adding the meeting message to the Redis message queue includes: Configure a remote dictionary service Redis template in the service instance; The conference service events in the service instance are obtained through the socketio client connection pool. In the case that the meeting business event is a broadcast event, the meeting business event is transformed into the meeting message through the remote dictionary service Redis template, and the meeting message is added to the Redis message queue.

5. The method according to claim 4, characterized in that, The step of transforming the meeting business events into meeting messages using the remote dictionary service Redis template and adding the meeting messages to the Redis message queue includes: Configure the remote dictionary service Redis template, serialize the meeting business events, and generate the meeting messages; The meeting messages are written into the Redis message queue in sequence.

6. The method according to claim 1, characterized in that, The step of continuously consuming the conference messages in the Redis message queue through a consumer and sending the conference messages to each of the service instances, so that the service instances can push the conference messages to the corresponding socketio clients, includes: Start a message listening thread to listen for meeting messages in the Redis message queue; Continuously consume the conference messages in the Redis message queue; The meeting messages in the Redis message queue are deserialized to form push information; The push information is sent to the specified socketio client via the service instance and the long connection.

7. A conference server, characterized in that, include: The connection module is used to establish long connections with multiple socketio clients through multiple service instances carrying socketio microservices, wherein each socketio client establishes a long connection with one of the service instances. The receiving module is configured to receive conference service events from the socketio client through the service instance; and, if the conference service event is a non-broadcast event, transmit the conference service event to the target socketio client through the service instance. The producer module is used to process the meeting business event according to the preset remote dictionary service Redis template when the meeting business event is a broadcast event, obtain the meeting message corresponding to the meeting business event, and add the meeting message to the Redis message queue. The consumer module is used to continuously consume conference messages in the Redis message queue and send the conference messages to each of the service instances, so that the service instances can push the conference messages to the corresponding socketio clients.

8. An electronic device, characterized in that, include: The device includes a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor, when executing the computer program, implements the conference message push method as described in any one of claims 1 to 6.

9. A computer-readable storage medium, characterized in that, The device contains a computer program that, when executed by a processor, implements the conference message push method as described in any one of claims 1 to 6.

Images