CN115865874A

CN115865874A - Conference message pushing method, conference server and electronic equipment

Info

Publication number: CN115865874A
Application number: CN202111111824.2A
Authority: CN
Inventors: 朱捷
Original assignee: ZTE Corp
Current assignee: ZTE Corp
Priority date: 2021-09-23
Filing date: 2021-09-23
Publication date: 2023-03-28
Also published as: WO2023045363A1

Abstract

The embodiment of the invention discloses a conference message pushing method, a conference server and electronic equipment, wherein the method comprises the following steps: respectively establishing long connections with a plurality of socket io clients through a plurality of service instances bearing socket io micro services; receiving a conference service event from a socket io client through a service instance; processing the conference service event through a producer based on a preset remote dictionary service Red i s template to obtain a conference message corresponding to the conference service event, and adding the conference message to a Red i s message queue; and continuously consuming the conference messages in the Red i s message queue by the consumer, and sending the conference messages to each service instance so that the service instance pushes the conference messages to the corresponding socket io client. Sharing conference messages among service instances through a lightweight Red is message queue, and realizing load balance of a client connected with a service end; the characteristics that the Red is queues are generated and consumed instantly are utilized, and the server side and the client side are connected through the socket io frame, so that timeliness of conference message pushing is improved.

Description

Conference message pushing method, conference server and electronic equipment

Technical Field

The present invention relates to the field of communications technologies, and in particular, to a conference message pushing method, a conference server, and an electronic device.

Background

As container technologies represented by docker (an open source application container engine) and k8s (a portable container arrangement management tool) become mainstream, transmission services such as digital conferences are also becoming cloudy. The elastic expansion of the k8s container well replaces the traditional service clustering mode, and can more flexibly deal with the service pressure, but the prior art has some defects: under a cloudization scene, a server based on a socket (a two-way communication data exchange technology established between a client and a server) communicates with the client, messages of different clients can only interact with a same server copy example, a communication forwarding problem exists among multiple copies of the example, and the advantage of copy shrinkage cannot be played. The existing solutions include two solutions, one is that through service restriction, if all clients are connected to the same server instance under one conference, server load balancing cannot be conveniently realized, and a high-performance hypertext transfer protocol (Nginx) and a reverse proxy network server (reverse proxy network server) need to be customized according to a service for forwarding; the other scheme is that communication between the server copies is realized through kafka (a high-throughput distributed publish-subscribe message system) and the like, and the scheme is not light and convenient, and performance in real-time is difficult to guarantee.

Disclosure of Invention

The following is a summary of the subject matter described in detail herein. This summary is not intended to limit the scope of the claims.

The embodiment of the invention provides a conference message pushing method, a conference server and electronic equipment, which can realize load balance of a client connected with the server; meanwhile, the characteristic that a Remote Dictionary service (Redis) queue is generated and consumed is fully utilized, and the Server and the client are connected through a socket framework, so that the timeliness of conference message pushing is improved.

In a first aspect, an embodiment of the present invention provides a conference message pushing method, which is applied to a socket server, and the method includes:

respectively establishing long connections with a plurality of socket clients through a plurality of service instances bearing socket micro services;

receiving a conference business event from the socket client through the service instance;

processing the conference service event through a producer based on a preset remote dictionary service Redis template to obtain a conference message corresponding to the conference service event, and adding the conference message to a Redis message queue;

and continuously consuming the conference messages in the Redis message queue through a consumer, and sending the conference messages to each service instance so that the service instances push the conference messages to the corresponding socket client.

In a second aspect, an embodiment of the present invention provides a conference server, including:

the system comprises a connection module, a service instance and a plurality of socket clients, wherein the connection module is used for respectively establishing long connection with the plurality of socket clients through a plurality of service instances bearing socket micro services, and each socket client correspondingly establishes long connection with one service instance;

the receiving module is used for receiving the conference service event from the socket client through a service instance;

the producer module is used for processing the conference service event according to a preset remote dictionary service Redis template to obtain a conference message corresponding to the conference service event and adding the conference message into a Redis message queue;

and the consumer module is used for continuously consuming the conference messages in the Redis message queue and sending the conference messages to each service instance so that the service instances push the conference messages to the corresponding socket client.

In a third aspect, an embodiment of the present invention provides an electronic device, including: the conference message pushing system comprises a memory, a processor and a computer program stored on the memory and capable of running on the processor, wherein the processor executes the computer program to realize the conference message pushing method.

In a fourth aspect, an embodiment of the present invention provides a computer-readable storage medium, which stores a computer program, and when the computer program is executed by a processor, the computer program implements the conference message pushing method as described above.

The scheme of the embodiment of the invention can realize the load balance of the client connected with the server; meanwhile, the characteristics that the Redis queue is produced and consumed are fully utilized, and the service end and the client end are connected through the socket framework, so that the timeliness of conference message pushing is improved.

Additional features and advantages of the invention will be set forth in the description which follows, and in part will be obvious from the description, or may be learned by practice of the invention. The objectives and other advantages of the invention will be realized and attained by the structure particularly pointed out in the written description and claims hereof as well as the appended drawings.

Drawings

The accompanying drawings are included to provide a further understanding of the invention and are incorporated in and constitute a part of this specification, illustrate embodiments of the invention and together with the example serve to explain the principles of the invention and not to limit the invention.

Fig. 1 is a flowchart illustrating a conference message pushing method;

FIG. 2 is a schematic diagram of an implementation of step S1000 in FIG. 1;

FIG. 3 is a schematic diagram of an implementation of step S3000 in FIG. 1;

FIG. 4 is a schematic diagram of a specific implementation process of step S3300 in FIG. 3;

FIG. 5 is a schematic diagram of an implementation of step S4000 in FIG. 1;

fig. 6 is a structural diagram of a conference server according to another embodiment of the present invention;

fig. 7 is a schematic structural diagram of an electronic device according to another embodiment of the present invention.

Detailed Description

In order to make the objects, technical solutions and advantages of the present invention more apparent, the present invention is described in further detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative of the invention and do not limit the invention.

It should be understood that in the description of the embodiments of the present invention, if there is any description of "first", "second", etc., it is only for the purpose of distinguishing technical features, and it is not to be understood as indicating or implying relative importance or implicitly indicating the number of indicated technical features or implicitly indicating the precedence of the indicated technical features. "at least one" means one or more, "a plurality" means two or more. "and/or" describes the association relationship of the associated objects, and means that there may be three relationships, for example, a and/or B, and may mean that a exists alone, a and B exist simultaneously, and B exists alone. Wherein A and B can be singular or plural. The character "/" generally indicates that the former and latter associated objects are in an "or" relationship. "at least one of the following" and the like, refer to any combination of these items, including any combination of singular or plural items. For example, at least one of a, b, and c may represent: a, b, c, a and b, a and c, b and c or a and b and c, wherein a, b and c can be single or multiple.

In addition, the technical features involved in the embodiments of the present invention described below may be combined with each other as long as they do not conflict with each other.

The conference message pushing method based on the socket framework, which is provided by the embodiment of the invention, is used as an efficient message transmission means between the server and the client, can effectively ensure the timeliness of conference message pushing, and is widely applied to the existing digital conference. In the practical application environment of the conference system, the problem of communication forwarding exists by using the traditional conference message pushing method, especially under the condition of multi-client access, the connection between the client and the server is difficult to realize load balancing, and the transmission real-time performance of the conference information cannot be ensured.

In the related art, there are two ways for implementing rapid conference information transmission in a conference system based on a socket framework, one is that through service restriction, if all clients are connected to the same server instance in a conference, at this time, the conference information needs to be forwarded according to service customization Nginx, and server load balancing cannot be implemented conveniently; another solution is that the communication between the server copies is implemented by a Message Queue (Message Queue) such as kafka, which makes the service instance of the conference server not light and convenient enough, and difficult to meet the requirement of real-time performance.

In the embodiment of the application, the conference service comprises two roles of a producer and a consumer, wherein the producer is used for producing the conference service message, the consumer is used for carrying out related processing on the conference service message so as to realize a specific function, and the producer and the consumer communicate through a message queue. The number of producers and the number of consumers are not limited, and specific setting can be carried out according to actual meeting scene requirements.

Based on the above, the embodiment of the invention provides a conference message pushing method, a conference server and electronic equipment, which can realize load balance of a client connected with the server; meanwhile, the characteristics that the Redis queue is produced and consumed are fully utilized, and the service end and the client end are connected through the socket framework, so that the timeliness of conference message pushing is improved.

Referring to fig. 1, fig. 1 is a flowchart illustrating a conference message pushing method according to an embodiment of the present invention. As shown in fig. 1, a conference message pushing method according to an embodiment of the present invention includes the following steps:

s1000, long connections are respectively established with a plurality of socket clients through a plurality of service instances bearing socket micro services.

It should be understood that the socket is a mature solution based on the websocket protocol (a protocol for performing full-duplex communication over a single transmission control protocol connection), and is a bidirectional communication data exchange technology established between the client and the server, and has the advantages of good transmission performance and support of multiple platforms. The long connection is established between the client and the server by adopting a socket-based framework, so that the real-time transmission of the conference information can be effectively ensured, and the connection stability between the client and the server is also improved.

Illustratively, a client can access a socket-server (a service end based on the socket) of the cloud server through the socket-client (a socket-based client library), complete socket link establishment and account verification login, and further establish long connection between the client and the service end.

It should be appreciated that microservices are a variant of the Service-Oriented Architecture (SOA) style of software development technology, and are applications built as a set of loosely coupled services. Microservices are therefore an architecture and organizational approach to developing software consisting of small, independent services that communicate through well-defined Application Programming Interfaces (APIs). Therefore, the micro-service architecture enables the application program to be easier to expand and faster to develop, innovation is accelerated, development time of new functions is shortened, and development efficiency of the conference system is effectively improved.

It should be understood that the micro-service has the characteristics of single responsibility, autonomous service, lightweight communication and clear interface, and by configuring the socket micro-service in the service instance, a long connection between the service instance and the client capable of realizing instant communication can be established under the socket framework.

It should be understood that, in order to ensure connectivity between the socket client and the socket server, each socket client establishes a long connection with one service instance through a socket microservice; meanwhile, in order to improve the resource utilization rate of the service instance, the same service instance can establish long connection with a plurality of socket clients through the socket micro service; particularly, when the conference information is broadcasted, the service instance can process the conference information facing to a plurality of socket clients at the same time, and the timeliness of conference information transmission is further improved.

In the specific implementation process, please refer to fig. 2, and fig. 2 shows a schematic diagram of a specific implementation process of the step S1000. As shown in fig. 2, step S1000 includes at least the following steps:

s1100, constructing a plurality of service instances bearing the socket micro-service at the socket service end.

It should be appreciated that by building multiple service instances, a socket server is facilitated to interface with multiple socket clients. The conference service can be directly expanded and reduced by changing the number of the service instances, and the scale of the conference system is conveniently planned and regulated. In addition, each service instance is an isolated container, the construction and starting speed of the container is very high by applying limitation to a CPU and a memory consumed by the service instance, and the timeliness of information interaction between the service instance and the socket client is guaranteed.

It should be understood that the service instance bears the socket micro-service, and can quickly establish a long connection between the service instance and the client based on the socket framework, so as to realize instant communication between the service instance and the socket client.

S1200, according to a preset connection rule, determining a corresponding relation between the service instance and the socket client.

It should be understood that the connection rules between the service instance and the socket client are preset to cope with different meeting environment requirements. Illustratively, in order to ensure connectivity between the service instance and each socket client and effective utilization of performance resources of the service end, a Load Balance (Load Balance) is adopted in the preset connection rule. The load balancing is to balance and distribute the load (work task) to a plurality of operation units for operation, and the load balancing is applied to the conference system, namely, the connection between a plurality of service instances and a socket client is optimized, so that the situation that the load of the service instances exceeds the limit is avoided, and the conference service event is quickly and efficiently transmitted on the premise of saving the operation resources of the service end.

It should be understood that, when the service instances to which each socket client is connected are determined according to the connection rule of load balancing, the occupancy rates of the service instances can be guaranteed to be balanced, and the situation that the usage rates of the service instances are different greatly is avoided. It should be understood that the correspondence between the socket client and the service instance may change with the operation of the service. Illustratively, as the number of the socket clients connected to the service instances increases, in order to reasonably allocate the use resources of the service instances, the socket clients correspond to other service instances, so as to ensure that the service instances and the socket clients are connected in a matching manner according to the connection rules, thereby improving the operating efficiency of the conference system.

It should be understood that by performing flexible scaling (AutoScaling) operation on the service instances, scaling rules can be set according to conference service requirements and policies, the service instances are automatically added to the service end to ensure conference information receiving and processing capabilities when the conference service requirements increase, and the service instances are automatically reduced to save cost when the conference service requirements decrease. Therefore, the elastic expansion and contraction is not only suitable for the conference system with continuously fluctuating traffic, but also suitable for the conference system with stable traffic.

Illustratively, the socket client can connect any service instance by ip-hash (mapping ip requested by a user into a hash value and then distributing the hash value to a specific server) or polling. Therefore, the server can easily realize load balance under the condition of no service logic invasion, the connection stability and reliability between the service instance and the socket client are higher, and the transmission influence on the conference service event is smaller after one of the service instances is hung.

S1300, according to the corresponding relation between the service instance and the socket client, the service instance establishes long connection with the corresponding socket client through the socket client connection pool.

It should be appreciated that by configuring the socket client connection pool, it is convenient to create and manage buffer pools of long connections between service instances and socket clients, which are ready for use by any socket microservice that needs them. Therefore, the connection pool can effectively reduce the connection establishing time of the service instance and the socket client, simplify the programming mode of the system and save the running resources of the system.

In the specific implementation process, a plurality of socket clients can be connected with the same service instance, so that the resource utilization rate of the service instance can be improved, long connection between each socket client and the corresponding service instance is ensured, the service connectivity between the plurality of socket clients connected with the same service instance can be improved, and the transmission stability and timeliness of the conference service are ensured.

S2000, receiving the conference service event from the socket client through the service instance.

It should be understood that, the service instance receives the conference service event through the long connection with the socket client, which can ensure that the conference service event of the socket client can be quickly and stably transmitted to the server, avoid the situations of transmission delay and loss of the conference service event, and ensure the timeliness and continuity of the conference message push.

S3000, processing the conference service event through a producer based on a preset remote dictionary service Redis template to obtain a conference message corresponding to the conference service event, and adding the conference message to a Redis message queue.

Referring to fig. 3, fig. 3 is a schematic diagram illustrating a specific implementation process of the step S3000. As shown in fig. 3, step S3000 includes at least the following steps:

s3100, configuring a remote dictionary service Redis template in a service instance.

It should be understood that by configuring a remote dictionary service Redis template (Redistemperlate), a producer can call related instructions and cache data in a Redis message queue quickly and accurately, and the efficiency and convenience of system development are improved.

S3200, obtaining the conference business event in the service instance through the socket client connection pool.

It should be appreciated that by configuring the socket client connection pool, conference business events in a service instance can be quickly obtained. In practical application development, particularly in a World Wide Web (Web) application system, if data in a database is directly accessed, each data access request must go through steps of establishing a database connection, opening the database, accessing the data, closing the database connection and the like, and connecting and opening the database is a work which consumes resources and is time-consuming, and if such database operation frequently occurs, the performance of the system inevitably drops sharply, and even the system crashes. Therefore, the connection pool technique is the most common method for solving this problem, and is basically used in many application servers.

It should be understood that the idea of the connection pool technique is to store the service instance and the socket client connection as objects in one object, and once the connection is established, the access requests of the remote dictionary service Redis template can share the connection, so that by multiplexing the established connections, the above-mentioned disadvantages of resource consumption and time consumption can be overcome, and the resources and time of the conference system can be greatly saved.

It should be understood that the conference service events are mainly divided into broadcast events and non-broadcast events according to the flow direction and the scope of influence of the conference service. The broadcast event comprises the group sending of information to other clients by the clients in the conference, the configuration of other client permissions by the clients and the like; non-broadcast events include point-to-point message interactions between a service instance and connected clients, intercommunication between two or more clients, client log-in and log-out, etc. Therefore, after the conference service event in the service instance is obtained, the conference service event is judged and analyzed. When the conference service event is a broadcast event, executing step S3300; when the conference service event is a non-broadcast event, step S3400 is performed.

And S3300, in case that the conference service event is a broadcast event, converting the conference service event through a remote dictionary service Redis template to form a conference message, and adding the conference message to a Redis message queue.

It should be understood that the broadcast event needs to forward the conference message to the client connected to the current service instance, and the conference message is processed through the Redis message queue, so that the conference message between the service instances is shared, and the forwarding function of multiple service instances is realized by using the characteristic that the Redis message queue is generated and consumed immediately, so that the transmission efficiency and the transmission accuracy of the conference message can be effectively improved.

Referring to fig. 4, fig. 4 is a schematic diagram illustrating a specific implementation process of step S3300. As shown in fig. 4, step S3300 includes at least the following steps:

s3310, configure the Redis template of the remote dictionary service, carry on the serialization to the business event of the meeting, produce the meeting message;

it should be understood that Serialization (Serialization) is the process of converting state information of a conference service event into a form that can be stored or transmitted, i.e., into a conference message. During serialization, conference traffic events write their current state to a temporary or persistent store. The object may later be recreated by reading or deserializing the state of the conference message from the storage area.

S3320, the conference messages are written into the Redis message queue in sequence through the Redis template of the remote dictionary service.

It should be appreciated that the Redis message queue has the characteristics of non-persistence, fast production and fast consumption. If the queue is empty, the consumer is in a blocking wait state when pulling the message, and once a new conference message comes, the consumer is informed to immediately process the new conference message. Therefore, the conference messages are written into the Redis message queue in sequence, the real-time property of the transmission of the conference messages can be effectively ensured, and the situations of conference message loss and conference message blocking are avoided.

S3400, under the condition that the conference service event is a non-broadcast event, transmitting the conference service event to a target socket client through a service instance.

It should be understood that when the conference service event is a non-broadcast event, the conference service event can be accurately transmitted by directly using the socket frame without issuing a subscription through a remote dictionary service Redis template, so that the transmission efficiency of the conference service event is improved, and the operating resources of the system are also saved.

And S4000, continuously consuming the conference messages in the Redis message queue by the consumer, and sending the conference messages to each service instance so that the service instances push the conference messages to corresponding socket clients.

Referring to fig. 5, fig. 5 is a schematic diagram illustrating a specific implementation process of the step S4000. As shown in fig. 5, step S4000 includes at least the following steps:

s4100, starting a message monitoring thread, and monitoring the conference messages in the Redis message queue;

it should be understood that monitoring the conference messages in the Redis message queue by multiple consumers is a basis for realizing fast consumption of the conference messages in the Redis message queue, and multiple service instances can collect and acquire the conference messages in the Redis message queue, thereby avoiding the situations of blocking and losing the conference messages.

In the specific implementation process, the socket micro-service analyzes the conference messages in the Redis message queue by calling a MessageListener (message interception instruction), and can monitor the attributes and importance of the conference messages, so as to quickly and accurately transmit the conference messages.

The functions of the related functions of the socket microservice are the same as those in step S1100, and are not described herein again.

S4200, continuously consuming the conference messages in the Redis message queue;

it should be understood that, by continuously consuming the conference messages in the Redis message queue, the conference messages in the Redis message queue can be ensured to be transmitted to the target client orderly and efficiently, and the condition that the conference messages are blocked or even lost due to multi-degree accumulation is avoided, so that the integrity of the conference information transmission is influenced.

S4300, deserializing the conference information in the Redis message queue to form push information;

it should be understood that when the service end processes the conference information, the conference information converted into a form that can be stored or transmitted needs to be deserialized (deserialization) and then converted into the push information. The reverse operation of the data structure is extracted from the series of bytes of the conference information obtained in step S3310, forming push information that the socket client can directly read.

S4400, push the push information to the specified socket client through the service instance and the long connection.

It should be understood that the push information is transmitted to the target client through the service instance and the long connection, which not only improves the push information, but also makes full use of the two-way communication data exchange connection based on the socket established between the client and the server, and improves the resource utilization rate of the system.

Referring to fig. 6, fig. 6 shows a structure diagram of a conference server. As shown in fig. 6, the conference server includes:

the connection module 100 is configured to establish long connections with multiple socket clients through multiple service instances bearing socket microservices.

A receiving module 200, configured to receive, through a service instance, a conference service event from a socket client.

The producer module 300 is configured to process the conference service event according to a preset remote dictionary service Redis template, obtain a conference message corresponding to the conference service event, and add the conference message to a Redis message queue.

And the consumer module 400 is configured to continuously consume the conference messages in the Redis message queue, and send the conference messages to each service instance, so that the service instance pushes the conference messages to a corresponding socket client.

It should be noted that, because the contents of information interaction, execution process, and the like of each module of the conference server are based on the same concept as the conference message pushing method provided in the embodiment of the present invention, specific functions and technical effects thereof may be specifically referred to in the embodiment section, and details are not described here.

It should be understood that the conference message pushing method and the conference server provided by the embodiment of the invention can be applied to a cloud digital conference scene with a high service usage amount, including but not limited to a scene of integrating a video conference, remote case handling in a detection department, remote application of an operator, and the like.

Referring to fig. 7, fig. 7 illustrates an electronic device 500 according to an embodiment of the invention. The electronic device 500 includes, but is not limited to:

a memory 520 for storing a program;

a processor 510 for executing the program stored in the memory 520, wherein when the processor 510 executes the program stored in the memory 520, the processor 510 is configured to execute the conference message pushing method.

The processor 510 and the memory 520 may be connected by a bus or other means.

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

The memory 520 may include a storage program area and a storage data area, wherein the storage program area may store an operating system, an application program required for at least one function; the storage data area may store a conference message push method that is performed as described above. Further, the memory 520 may include high speed random access memory, and may also include non-transitory memory, such as at least one magnetic disk storage device, flash memory device, or other non-transitory solid state storage device. In some embodiments, the memory 520 may optionally include memory located remotely from the processor 510, which 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.

The non-transitory software programs and instructions required to implement the conference message pushing method described above are stored in the memory 520 and, when executed by the one or more processors 510, perform the conference message pushing method provided by any of the embodiments of the present invention.

The embodiment of the invention also provides a storage medium, which stores computer-executable instructions, and the computer-executable instructions are used for executing the conference message pushing method.

In an embodiment, the storage medium stores computer-executable instructions, which are executed by one or more control processors 510, for example, by one processor 510 in the electronic device 500, and can cause the one or more processors 510 to execute the conference message pushing method provided in any embodiment of the present invention.

The embodiments described above are merely illustrative, where elements described as separate components may or may not be physically separate, may be located in one place, or may be distributed over a plurality of network elements. Some or all of the modules may be selected according to actual needs to achieve the purpose of the solution of the present embodiment.

One of ordinary skill in the art will appreciate that all or some of the steps, systems, and methods disclosed above may be implemented as software, firmware, hardware, and suitable combinations thereof. Some or all of the physical components may 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 may be distributed on computer readable media, which may include computer storage media (or non-transitory media) and communication media (or transitory media). The term computer storage media includes volatile and nonvolatile, removable and non-removable media implemented in any method or technology for storage of information such as computer readable instructions, data structures, program modules or other data, as is well known to those of ordinary skill in the art. Computer storage media includes, but is not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital Versatile Disks (DVD) or other optical disk storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to store the desired information and which can accessed by a computer. In addition, communication media typically embodies computer readable instructions, data structures, program modules or other data in a modulated data signal such as a carrier wave or other transport mechanism and includes any information delivery media as known to those skilled in the art.

While the preferred embodiments of the present invention have been described in detail, it is to be understood that the present invention is not limited to the above-described embodiments, and that those skilled in the art can easily modify the present invention without departing from the spirit thereof. Under the shared conditions, various equivalent modifications or substitutions can be made, and all the equivalent modifications or substitutions are included in the scope of the invention defined by the claims.

Claims

1. A conference message pushing method is applied to a socket server side, and comprises the following steps:

processing the conference service event through a producer based on a preset remote dictionary service Redis template to obtain a conference message corresponding to the conference service event, and adding the conference message into a Redis message queue;

2. The method of claim 1, wherein before the establishing long connections with a plurality of socket clients respectively through a plurality of service instances bearing socket microservices, the method further comprises:

constructing a plurality of service instances bearing socket micro-service at the socket server;

and determining the corresponding relation between the service instance and the socket client according to a preset connection rule.

3. The method of claim 2, wherein the establishing long connections with a plurality of socket clients through a plurality of service instances bearing socket microservices, respectively, comprises:

and according to the corresponding relation between the service instance and the socket client, enabling the service instance to establish long connection with the corresponding socket client through a socket client connection pool.

4. The method according to claim 3, wherein the processing, by the producer, the conference service event based on a preset remote dictionary service Redis template to obtain a conference message corresponding to the conference service event, and adding the conference message to a Redis message queue comprises:

configuring a remote dictionary service Redis template in the service instance;

acquiring the conference service event in the service instance through the socket client connection pool;

and under the condition that the conference service event is a broadcast event, converting the conference service event through the Redis template to form the conference message, and adding the conference message to the Redis message queue.

5. The method of claim 4, after the obtaining the conference service event in the service instance through the socket client connection pool, further comprising:

and under the condition that the conference service event is a non-broadcast event, transmitting the conference service event to a target socket client through the service instance.

6. The method of claim 4, wherein the converting the conference service event to form the conference message through the remote dictionary service Redis template and adding the conference message to the Redis message queue comprises:

configuring the Redis template, and performing serialization processing on the conference service event to generate the conference message;

and writing the conference messages into the Redis message queue in sequence.

7. The method according to claim 1, wherein the continuously consuming, by the consumer, the conference messages in the Redis message queue and sending the conference messages to each of the service instances, so that the service instances push the conference messages to the corresponding socket clients, comprises:

starting a message monitoring thread, and monitoring the conference messages in the Redis message queue;

continuously consuming the conference messages in the Redis message queue;

deserializing the conference information in the Redis message queue to form push information;

and pushing the pushing information to the specified socket client through the service instance and the long connection.

8. A conference server, comprising:

9. An electronic device, comprising: a memory, a processor and a computer program stored on the memory and executable on the processor, the processor implementing the conference message pushing method according to any one of claims 1 to 7 when executing the computer program.

10. A computer-readable storage medium, in which a computer program is stored, which, when executed by a processor, implements the conference message pushing method according to any one of claims 1 to 7.