一种会议消息推送方法、会议服务端及电子设备

摘要

本发明实施例公开了一种会议消息推送方法、会议服务端及电子设备，所述方法包括：通过多个承载socket io微服务的服务实例与多个socket io客户端分别建立长连接；通过服务实例接收来自socket io客户端的会议业务事件；通过生产者基于预置的远程字典服务Red i s模板对会议业务事件进行处理，得到与会议业务事件对应的会议消息，并将会议消息添加至Red i s消息队列中；通过消费者持续消费Red i s消息队列中的会议消息，并将会议消息发送给各个服务实例，以由服务实例将会议消息推送给对应的socket io客户端。通过轻量级的Red i s消息队列共享各服务实例间的会议消息，实现客户端连接服务端的负载均衡；利用Red i s队列即产即消的特点，并通过socket io框架连接服务端和客户端，提高了会议消息推送的时效性。

说明书

技术领域

本发明涉及通讯技术领域，特别是涉及一种会议消息推送方法、会议服务端及电子设备。

背景技术

随着docker(一种开源的应用容器引擎)、k8s(kubernetes，一种可移植容器的编排管理工具)为代表的容器技术日趋主流，数字会议等传输业务也逐渐云化。其中，k8s的容器弹性伸缩很好地取代了传统的服务集群方式,可以更灵活地应对业务压力，但是现有的技术存在一些缺陷：云化场景下，基于socketio(一种在客户端和服务端之间建立的双向通信数据交换技术)的服务端与客户端通信，不同客户端的消息只能与同一个服务端副本实例交互,多副本实例之间存在通讯转发问题，无法发挥副本弹缩的优势。现有的解决方案包括两种，一是通过业务限制，如一个会议下所有客户端连接至同一服务端实例，此时无法便捷地实现服务端负载均衡，需要根据业务定制Nginx(engine x，一种高性能的超文本传输协议和反向代理网络服务器)进行转发；另一种方案则是服务端副本间的通信通过kafka(一种高吞吐量的分布式发布订阅消息系统)等实现，这种方案不够轻量、便捷，且在实时性方面的性能难以保证。

发明内容

以下是对本文详细描述的主题的概述。本概述并非是为了限制权利要求的保护范围。

本发明实施例提供一种会议消息推送方法、会议服务端及电子设备，能够实现客户端连接服务端的负载均衡；同时，充分利用远程字典服务(Remote Dictionary Server，Redis)队列即产即消的特点，并通过socketio框架连接服务端和客户端，提高了会议消息推送的时效性。

第一方面，本发明实施例提供一种会议消息推送方法，应用于socketio服务端，所述方法包括：

通过多个承载socketio微服务的服务实例与多个socketio客户端分别建立长连接；

通过所述服务实例接收来自所述socketio客户端的会议业务事件；

通过生产者基于预置的远程字典服务Redis模板对所述会议业务事件进行处理，得到与所述会议业务事件对应的会议消息，并将所述会议消息添加至Redis消息队列中；

通过消费者持续消费所述Redis消息队列中的所述会议消息，并将所述会议消息发送给各个所述服务实例，以由所述服务实例将所述会议消息推送给对应的所述socketio客户端。

第二方面，本发明实施例提供一种会议服务端，包括:

连接模块，用于通过多个承载socketio微服务的服务实例与多个socketio客户端分别建立长连接，其中，每个所述socketio客户端对应与一个所述服务实例建立长连接；

接收模块，用于通过服务实例接收来自所述socketio客户端的会议业务事件；

生产者模块，用于根据预置的远程字典服务Redis模板对所述会议业务事件进行处理，得到与所述会议业务事件对应的会议消息，并将所述会议消息添加至Redis消息队列中；

消费者模块，用于持续消费所述Redis消息队列中的会议消息，并将所述会议消息发送给各个所述服务实例，以由所述服务实例将所述会议消息推送给对应的所述socketio客户端。

第三方面，本发明实施例提供一种电子设备，包括：存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，所述处理器执行所述计算机程序时，实现如上所述的会议消息推送方法。

第四方面，本发明实施例提供一种计算机可读存储介质，存储有计算机程序，所述计算机程序被处理器执行时，实现如上所述的会议消息推送方法。

本发明实施例的方案能够实现客户端连接服务端的负载均衡；同时，充分利用Redis队列即产即消的特点，并通过socketio框架连接服务端和客户端，提高了会议消息推送的时效性。

本发明的其它特征和优点将在随后的说明书中阐述，并且，部分地从说明书中变得显而易见，或者通过实施本发明而了解。本发明的目的和其他优点可通过在说明书、权利要求书以及附图中所特别指出的结构来实现和得到。

附图说明

附图用来提供对本发明技术方案的进一步理解，并且构成说明书的一部分，与本发明的实施例一起用于解释本发明的技术方案，并不构成对本发明技术方案的限制。

图1是一种会议消息推送方法的流程示意图；

图2是图1中步骤S1000的一种具体实现过程示意图；

图3是图1中步骤S3000的一种具体实现过程示意图；

图4是图3中步骤S3300的一种具体实现过程示意图；

图5是图1中步骤S4000的一种具体实现过程示意图；

图6是本发明另一实施例提供的一种会议服务端的结构图；

图7是本发明另一实施例提供的一种电子设备的结构示意图。

具体实施方式

为了使本发明的目的、技术方案及优点更加清楚明白，以下结合附图及实施例，对本发明进行进一步详细说明。应当理解，此处所描述的具体实施例仅用以解释本发明，并不用于限定本发明。

应了解，在本发明实施例的描述中，如果有描述到“第一”、“第二”等只是用于区分技术特征为目的，而不能理解为指示或暗示相对重要性或者隐含指明所指示的技术特征的数量或者隐含指明所指示的技术特征的先后关系。“至少一个”是指一个或者多个，“多个”是指两个或两个以上。“和/或”，描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或B，可以表示单独存在A、同时存在A和B、单独存在B的情况。其中A，B可以是单数或者复数。字符“/”一般表示前后关联对象是一种“或”的关系。“以下至少一项”及其类似表达，是指的这些项中的任意组合，包括单项或复数项的任意组合。例如，a，b和c中的至少一项可以表示：a，b，c，a和b，a和c，b和c或a和b和c，其中a，b，c可以是单个，也可以是多个。

此外，下面所描述的本发明各个实施方式中所涉及到的技术特征只要彼此之间未构成冲突就可以相互组合。

本发明实施例涉及的基于socketio框架的会议消息推送方法，其作为一种高效的服务端与客户端之间的消息传送手段，能有效保证会议消息推送的时效性，在现有的数字会议中得到广泛的应用。在会议系统的实际应用环境中，使用传统的会议消息推送方法存在通信转发的问题,尤其是在多客户端接入的情况下，客户端与服务端之间的连接难以实现负载均衡，会议信息的传送实时性也无法保证。

相关技术中，基于socketio框架的会议系统实现会议信息快速传送的方式有两种，一是通过业务限制，如一个会议下所有客户端连接至同一服务端实例，此时会议信息需要根据业务定制Nginx转发，无法便捷地实现服务端负载均衡；另一方案则是服务端副本间的通信通过kafka等消息队列(Message Queue)实现，这样会使会议服务端的服务实例不够轻量、便捷，且难以满足实时性方面的要求。

在本申请实施例中，会议业务包括生产者和消费者两种角色，生产者用于生产会议业务消息，消费者用于对会议业务消息进行相关处理从而实现特定功能，生产者与消费者之间通过消息队列进行通信。其中，本申请对生产者的数量和消费者的数量不做限定，可以根据实际的会议场景需要进行具体设定。

基于以上，本发明实施例提供一种会议消息推送方法、会议服务端及电子设备，能够实现客户端连接服务端的负载均衡；同时，充分利用Redis队列即产即消的特点，并通过socketio框架连接服务端和客户端，提高了会议消息推送的时效性。

请参见图1，图1示出了本发明实施例提供的一种会议消息推送方法的流程示意图。如图1所示，本发明实施例的会议消息推送方法包括以下步骤：

S1000，通过多个承载socketio微服务的服务实例与多个socketio客户端分别建立长连接。

应该理解的是，socketio是基于websocket协议(一种在单个传输控制协议连接上进行全双工通信的协议)的一套成熟的解决方案，是在客户端和服务端之间建立的双向通信数据交换技术，具有传输性能好、支持多个平台的优点。客户端和服务端之间采用基于socketio框架建立长连接，能有效地保证会议信息的传送实时性，也提高客户端与服务端之间的连接稳定性。

示例性的，客户端能通过socketio-client(基于socketio的客户端库)访问云服务器的socketio-server(基于socketio的服务端)，完成socket(套接字)建链及账户验证登录，进而建立客户端与服务端之间的长连接。

应该理解的是，微服务是一种软件开发技术面向服务的体系结构(Service-Oriented Architecture,SOA)架构样式的一种变体，是将应用程序构造为一组松散耦合的服务。因此微服务是一种开发软件的架构和组织方法，其中软件由通过明确定义的应用程序接口(Application Programming Interface,API)进行通信的小型独立服务组成。可见，微服务架构使应用程序更易于扩展和更快地开发，从而加速创新并缩短新功能的开发时间，有效提高会议系统的开发效率。

应该理解的是，微服务具有职责单一、服务自治、轻量级通信、接口明确的特点，通过在服务实例中配置socketio微服务，能在socketio框架下建立起服务实例与客户端之间的能实现即时通信的长连接。

应该理解的是，为保证socketio客户端与socketio服务端的连通性，每个socketio客户端均通过socketio微服务与一个服务实例建立长连接；同时，为了提高服务实例的资源利用率，同一个服务实例能通过socketio微服务同时与多个socketio客户端建立长连接；尤其在对会议信息进行广播时，服务实例能同时处理面向多个socketio客户端的会议信息，进一步提高会议信息传送的时效性。

具体实现过程中，请参见图2，图2示出了上述步骤S1000的一种具体实现过程示意图。如图2所示，步骤S1000至少包括以下步骤：

S1100，在socketio服务端构建承载socketio微服务的多个服务实例。

应该理解的是，通过构建多个服务实例，便于socketio服务端与多个socketio客户端进行连接。其中，通过更改服务实例的数量可以直接扩展和缩小会议服务，便于对会议系统的规模进行规划和调控。此外，每个服务实例都是隔离的容器，对服务实例消耗的CPU和内存施加限制容器的构建和启动速度非常快，保证服务实例与socketio客户端之间信息交互的时效性。

应该理解的是，服务实例承载socketio微服务，能快速地建立起服务实例与客户端之间的基于socketio框架的长连接，实现服务实例与socketio客户端之间的即时通信。

S1200，根据预设的连接规则，确定服务实例与socketio客户端之间的对应关系。

应该理解的是，为了应对不同的会议环境需求，对服务实例与socketio客户端之间的连接规则进行预设。示例性的，为了保证服务实例与各个socketio客户端的连通性和服务端的性能资源能有效利用，预设的连接规则采用负载均衡(Load Balance)。负载均衡就是将负载(工作任务)进行平衡、分摊到多个操作单元上进行运行，应用到会议系统中，就是通过优化多个服务实例与socketio客户端的连接，避免服务实例存在负载超限的情况，从而在节省服务端的运行资源的前提下，实现会议业务事件的快速、高效的传送。

应该理解的是，根据负载均衡的连接规则，确定每个socketio客户端与之相连的服务实例时，保证服务实例的占用率能达到均衡，避免服务实例的使用率出现差异较大的情况。应理解，socketio客户端与服务实例之间的对应关系随着服务端的运行情况会发生改变。示例性的，随着服务实例所连接的socketio客户端增多，为了合理分配服务实例的使用资源，socketio客户端会对应到其他的服务实例上，以保证服务实例与socketio客户端按照连接规则进行匹对连接，提高会议系统的运行效率。

应该理解的是，通过对服务实例进行弹性伸缩(AutoScaling)操作，能根据会议业务需求和策略设置伸缩规则，在会议业务需求增长时自动为服务端增加服务实例以保证会议信息接收和处理能力，在会议业务需求下降时自动减少服务实例以节约成本。因此，弹性伸缩不仅适合业务量不断波动的会议系统，同时也适合业务量稳定的会议系统。

示例性的，socketio客户端可以通过ip-hash(根据用户请求过来的ip映射成hash值，然后分配到一个特定的服务器里面)或者轮询的方式连接任一服务实例。这样服务端可以在无业务逻辑侵入的情况下简易地实现负载均衡，且服务实例与socketio客户端之间的连接稳定性、可靠性更高，当其中一个服务实例挂掉后对于会议业务事件的传送影响更小。

S1300，根据服务实例与socketio客户端之间的对应关系，使服务实例经由socketio客户端连接池与对应的socketio客户端建立长连接。

应该理解的是，通过配置socketio客户端连接池，便于创建和管理服务实例与socketio客户端的之间长连接的缓冲池，这些连接池准备好被任何需要它们的socketio微服务使用。因此，连接池能有效减小服务实例与socketio客户端连接创建时间，简化系统的编程模式，还能节省系统运行的资源。

在具体实施过程中，多个socketio客户端能连接同一个服务实例，不仅能提高服务实例的资源利用率，也确保了各个socketio客户端均与对应的服务实例建立长连接，还能提高与同一服务实例连接的多个socketio客户端之间的业务连通性，保证会议业务的传送稳定性和时效性。

S2000，通过服务实例接收来自socketio客户端的会议业务事件。

应该理解的是，服务实例通过与socketio客户端的长连接进行会议业务事件的接收，能保证socketio客户端的会议业务事件能快速、稳定地传送到服务端，避免发生会议业务事件传送延时、丢失的情况，保证会议消息推送的时效性和连续性。

S3000，通过生产者基于预置的远程字典服务Redis模板对会议业务事件进行处理，得到与会议业务事件对应的会议消息，并将会议消息添加至Redis消息队列中。

请参见图3，图3示出了上述步骤S3000的一种具体实现过程示意图。如图3所示，步骤S3000至少包括以下步骤：

S3100，在服务实例中配置远程字典服务Redis模板。

应该理解的是，通过配置远程字典服务Redis模板(RedisTemplate)，便于生产者快速、准确地调用Redis消息队列中的相关的指令和缓存数据，提高系统开发的效率和便利性。

S3200，通过socketio客户端连接池获取服务实例中的会议业务事件。

应该理解的是，通过配置socketio客户端连接池，能快速地获取服务实例中的会议业务事件。在实际应用开发中，特别是在全球广域网(World Wide Web，WEB)应用系统中，如果直接访问数据库中的数据，每一次数据访问请求都必须经历建立数据库连接、打开数据库、存取数据和关闭数据库连接等步骤，而连接并打开数据库是一件既消耗资源又费时的工作，如果频繁发生这种数据库操作，系统的性能必然会急剧下降，甚至会导致系统崩溃。因此，连接池技术是解决这个问题最常用的方法，在许多应用程序服务器中，基本都使用连接池技术。

应该理解的是，连接池技术的思想就是将服务实例与socketio客户端连接作为对象存储在一个对象中，一旦连接建立后，远程字典服务Redis模板的访问请求就可以共享这些连接，这样，通过复用这些已经建立的连接，可以克服上述消耗资源和费时缺点，极大地节省会议系统的资源和时间。

应该理解的是，会议业务事件根据会议业务的流向和影响范围，主要分为广播事件和非广播事件。广播事件包括会议内客户端群发信息到其他的客户端、客户端需要配置其他客户端权限等；非广播事件包括某服务实例与相连的客户端之间的点对点消息交互、两个或者多个客户端之间相互通信、客户端登入登出等操作。因此，在获取服务实例中的会议业务事件后，对会议业务事件进行判断分析。当会议业务事件为广播事件，则执行步骤S3300；当会议业务事件为非广播事件，则执行步骤S3400。

S3300，在会议业务事件为广播事件的情况下，通过远程字典服务Redis模板把会议业务事件进行转换以形成会议消息，并将会议消息添加至Redis消息队列中。

应该理解的是，广播事件需要对当前服务实例相连的客户端进行会议消息的转发，通过Redis消息队列进行处理，共享个服务实例间的会议消息，利用Redis消息队列即产即消的特点，实现多个服务实例的转发功能，能有效提高会议消息的传送效率和传达准确性。

请参见图4，图4示出了上述步骤S3300的一种具体实现过程示意图。如图4所示，步骤S3300至少包括以下步骤：

S3310，配置远程字典服务Redis模板，对会议业务事件进行序列化处理，生成会议消息；

应该理解的是，序列化(Serialization)是将会议业务事件的状态信息转换为可以存储或传输的形式的过程，即转化为会议消息的过程。在序列化期间，会议业务事件将其当前状态写入到临时或持久性存储区。以后，可以通过从存储区中读取或反序列化会议消息的状态，重新创建该对象。

S3320，通过远程字典服务Redis模板把会议消息按序写入Redis消息队列中。

应该理解的是，Redis消息队列具有非持久化、快产快消的特点。如果队列为空，消费者在拉取消息时就处于阻塞等待的状态，一旦有新的会议消息过来，就通知消费者立即处理新的会议消息。因此会议消息按序写入Redis消息队列能有效地保证会议消息传送的实时性，避免发生会议消息丢失和阻塞的情况。

S3400，在会议业务事件为非广播事件的情况下，会议业务事件通过服务实例传送到目标socketio客户端。

应该理解的是，当会议业务事件为非广播事件，则直接使用socketio框架即能实现会议业务事件的精准传送，无需经过远程字典服务Redis模板发布订阅，提高会议业务事件的传送效率，也节省了系统的运行资源。

S4000，通过消费者持续消费Redis消息队列中的会议消息，并将会议消息发送给各个服务实例，以由服务实例将会议消息推送给对应的socketio客户端。

请参见图5，图5示出了上述步骤S4000的一种具体实现过程示意图。如图5所示，步骤S4000至少包括以下步骤：

S4100，启动消息监听线程，对Redis消息队列中的会议消息进行监听；

应该理解的是，通过多个消费者对Redis消息队列中的会议消息进行监听，是实现Redis消息队列中的会议消息快速消费的基础，多个服务实例能收集、获取Redis消息队列中的会议消息，避免会议消息发生阻塞和丢失的情况。

具体实现过程中，socketio微服务通过调用MessageListener(消息侦听指令)对Redis消息队列中的会议消息进行分析，能监听会议消息的属性和重要性，进而对会议消息进行快速、准确的传送。

其中，socketio微服务的相关功能作用跟步骤S1100中的一致，在此不再赘述。

S4200，持续消费Redis消息队列中的会议消息；

应该理解的是，持续消费Redis消息队列中的会议消息，能保证Redis消息队列中的会议消息有序、高效地传送到目标客户端，避免会议消息因多度积累发生阻塞甚至丢失的情况，影响会议信息传送的完整性。

S4300，对Redis消息队列中的会议信息进行反序列化，形成推送信息；

应该理解的是，当服务端处理会议信息，需要对转换为可以存储或传输的形式的会议信息进行反序列化(deserialization)，进而转化为推送信息。从步骤S3310得到的会议信息的系列字节提取数据结构的反向操作，形成socketio客户端能直接读取的推送信息。

S4400，通过服务实例和长连接，把推送信息推送到指定的socketio客户端。

应该理解的是，推送信息通过服务实例和长连接传送到目标客户端，既能提高推送信息的，也充分利用了客户端和服务端之间建立的基于socketio的双向通信数据交换连接，提高系统的资源利用率。

请参见图6，图6示出了一种会议服务端的结构图。如图6所示，会议服务端包括:

连接模块100，用于通过多个承载socketio微服务的服务实例与多个socketio客户端分别建立长连接。

接收模块200，用于通过服务实例接收来自socketio客户端的会议业务事件。

生产者模块300，用于根据预置的远程字典服务Redis模板对会议业务事件进行处理，得到与会议业务事件对应的会议消息，并将会议消息添加至Redis消息队列中。

消费者模块400，用于持续消费Redis消息队列中的会议消息，并将会议消息发送给各个服务实例，以由服务实例将会议消息推送给对应的socketio客户端。

需要说明的是，会议服务端各个模块的信息交互、执行过程等内容，由于与本发明实施例提供的会议消息推送方法基于同一构思，其具体功能及带来的技术效果，具体可参见其实施例部分，此处不再赘述。

应理解，本发明施例提供的会议消息推送方法和会议服务端能应用于业务使用量偏高的云化数字会议场景下，包括但不限于融合视频会议、检察院远程办案、运营商远程应用等场景。

请参见图7，图7示出了本发明实施例提供的电子设备500。该电子设备500包括但不限于：

存储器520，用于存储程序；

处理器510，用于执行存储器520存储的程序，当处理器510执行存储器520存储的程序时，处理器510用于执行上述的会议消息推送方法。

处理器510和存储器520可以通过总线或者其他方式连接。

存储器520作为一种非暂态计算机可读存储介质，可用于存储非暂态软件程序以及非暂态性计算机可执行程序，如本发明任意实施例描述的会议消息推送方法。处理器510通过运行存储在存储器520中的非暂态软件程序以及指令，从而实现上述的会议消息推送方法。

存储器520可以包括存储程序区和存储数据区，其中，存储程序区可存储操作系统、至少一个功能所需要的应用程序；存储数据区可存储执行上述的会议消息推送方法。此外，存储器520可以包括高速随机存取存储器，还可以包括非暂态存储器，比如至少一个磁盘存储器件、闪存器件、或其他非暂态固态存储器件。在一些实施方式中，存储器520可选包括相对于处理器510远程设置的存储器，这些远程存储器可以通过网络连接至该处理器510。上述网络的实例包括但不限于互联网、企业内部网、局域网、移动通信网及其组合。

实现上述的会议消息推送方法所需的非暂态软件程序以及指令存储在存储器520中，当被一个或者多个处理器510执行时，执行本发明任意实施例提供的会议消息推送方法。

本发明实施例还提供了一种存储介质，存储有计算机可执行指令，计算机可执行指令用于执行上述的会议消息推送方法。

在一实施例中，该存储介质存储有计算机可执行指令，该计算机可执行指令被一个或多个控制处理器510执行，比如，被上述电子设备500中的一个处理器510执行，可使得上述一个或多个处理器510执行本发明任意实施例提供的会议消息推送方法。

以上所描述的实施例仅仅是示意性的，其中作为分离部件说明的单元可以是或者也可以不是物理上分开的，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。

本领域普通技术人员可以理解，上文中所公开方法中的全部或某些步骤、系统可以被实施为软件、固件、硬件及其适当的组合。某些物理组件或所有物理组件可以被实施为由处理器，如中央处理器、数字信号处理器或微处理器执行的软件，或者被实施为硬件，或者被实施为集成电路，如专用集成电路。这样的软件可以分布在计算机可读介质上，计算机可读介质可以包括计算机存储介质(或非暂时性介质)和通信介质(或暂时性介质)。如本领域普通技术人员公知的，术语计算机存储介质包括在用于存储信息(诸如计算机可读指令、数据结构、程序模块或其他数据)的任何方法或技术中实施的易失性和非易失性、可移除和不可移除介质。计算机存储介质包括但不限于RAM、ROM、EEPROM、闪存或其他存储器技术、CD-ROM、数字多功能盘(DVD)或其他光盘存储、磁盒、磁带、磁盘存储或其他磁存储装置、或者可以用于存储期望的信息并且可以被计算机访问的任何其他的介质。此外，本领域普通技术人员公知的是，通信介质通常包括计算机可读指令、数据结构、程序模块或者诸如载波或其他传输机制之类的调制数据信号中的其他数据，并且可包括任何信息递送介质。

以上是对本发明的较佳实施进行了具体说明，但本发明并不局限于上述实施方式，熟悉本领域的技术人员在不违背本发明精神的。共享条件下还可作出种种等同的变形或替换，这些等同的变形或替换均包括在本发明权利要求所限定的范围内。