CN115022110A - 消息分发方法、可读介质以及电子设备 - Google Patents

Abstract

本申请提供一种消息分发方法、可读介质以及电子设备，该方法包括：服务端接收第一用户端发送的第一消息；服务端对所述第一消息进行处理，得到第二消息；进而服务端的每一个哈希桶，均根据所述第二消息的消息类型，查询出自身存储的所有目标用户端对应的连接通道，其中，所述第二消息的消息类型用于说明所述第二消息需发送的群组；所述目标用户端为属于所述第二消息需发送的群组中的用户端；由于查询任务分担至多个桶并行执行，查询效率提升，进而服务端能够快速将第二消息发送至每一个目标用户端，不会出现消息延迟的情况。

Description

消息分发方法、可读介质以及电子设备

技术领域

本发明涉及计算机技术领域，尤其涉及一种消息分发方法、可读介质以及电子设备。

背景技术

随着直播业务的迅速发展，许多互联网平台都配置了直播功能。在直播过程中，用户和主播之间会产生许多互动消息，例如用户评论、刷礼物、进场等等。这些直播间的互动消息主要通过服务端进行处理，再由服务端将处理后的消息分发至该直播间的各个用户端，实现让直播间的用户能够在各自的用户端上查看到最新的直播间互动。

然而，当直播间用户较多时，服务端需要分发的消息量就会非常大，进而会出现服务端分发消息耗时过长的情况，导致直播间的一些用户接收消息延时，甚至无法接收到消息，给直播间用户带来了不好的用户体验。

发明内容

有鉴于此，本发明实施例提供一种消息分发方法、可读介质以及电子设备，以解决消息接收延迟的问题。

为实现上述目的，本发明实施例提供如下技术方案：

本申请第一方面公开了一种消息分发方法，应用于服务端，所述服务端分别与多个用户端之间建立了连接通道；所述服务端包括：多个哈希桶；每一个所述用户端对应的连接通道均存储于所述用户端对应的哈希桶中；所述消息分发方法包括：

所述服务端接收第一用户端发送的第一消息；其中，所述第一用户端为与所述服务端之间建立了连接通道的任一用户端；

所述服务端对所述第一消息进行处理，得到第二消息；

所述服务端的每一个哈希桶，均根据所述第二消息的消息类型，查询出自身存储的所有目标用户端对应的连接通道；其中，所述第二消息的消息类型用于说明所述第二消息需发送的群组；所述目标用户端为属于所述第二消息需发送的群组中的用户端；

所述服务端针对每一个所述目标用户端，通过所述目标用户端对应的连接通道将所述第二消息发送至所述目标用户端。

可选地，在上述消息分发方法中，所述用户端对应的连接通道的建立过程，包括：

所述服务端接收所述用户端发送的连接请求；

所述服务端响应于所述连接请求，与所述用户端建立所述用户端对应的连接通道。

可选地，在上述消息分发方法中，所述用户端对应的连接通道的存储过程，包括：

所述服务端根据所述用户端的特定信息，生成所述用户端的唯一键；

所述服务端使用所述唯一键的哈希值对哈希桶总数量进行取余运算，确定出所述用户端对应的哈希桶；

所述服务端将所述用户端对应的连接通道存储于所述用户端对应的哈希桶中；其中，所述服务端的每一个所述哈希桶均按照用户端对应用户的群组标识，对自身存储的所有用户端对应的连接通道进行分组。

可选地，在上述消息分发方法中，所述服务端对所述第一消息进行处理，得到第二消息之后，还包括：

所述服务端将所述第二消息缓存至Kafka系统；

所述服务端针对每一个所述目标用户端，通过所述目标用户端对应的连接通道将所述第二消息发送至所述目标用户端之前，还包括：

所述服务端从所述Kafka系统中获取所述第二消息。

可选地，在上述消息分发方法中，所述服务端的每一个哈希桶，均根据所述第二消息的消息类型，查询出自身存储的所有目标用户端对应的连接通道，包括：

所述服务端的每一个哈希桶，均在监听到需发送所述第二消息时，根据所述第二消息的消息类型，查询出自身存储的所有目标用户端对应的连接通道。

本申请第二方面公开了一种消息分发方法，应用于服务端，所述服务端分别与多个用户端之间建立了连接通道；所述服务端包括：连接服务和消息处理服务；所述连接服务包括：多个哈希桶；每一个所述用户端对应的连接通道均存储于所述用户端对应的哈希桶中；所述消息分发方法包括：

所述连接服务接收第一用户端发送的第一消息；其中，所述第一用户端为与所述服务端之间建立了连接通道的任一用户端；

所述连接服务或所述消息处理服务对所述第一消息进行处理，得到第二消息；

所述连接服务的每一个哈希桶，均根据所述第二消息的消息类型，查询出自身存储的所有目标用户端对应的连接通道；其中，所述第二消息的消息类型用于说明所述第二消息需发送的群组；所述目标用户端为属于所述第二消息需发送的群组中的用户端；

所述连接服务针对每一个所述目标用户端，通过所述目标用户端对应的连接通道将所述第二消息发送至所述目标用户端。

可选地，在上述消息分发方法中，若所述消息处理服务对所述第一消息进行处理，得到第二消息，则所述连接服务接收第一用户端发送的第一消息之后，还包括：

所述连接服务将所述第一消息发送至所述消息处理服务。

可选地，在上述消息分发方法中，所述服务端还包括：Kafka系统；所述连接服务或所述消息处理服务对所述第一消息进行处理，得到第二消息之后，还包括：

所述Kafka系统接收并缓存所述第二消息；

所述连接服务的每一个哈希桶，均根据所述第二消息的消息类型，查询出自身存储的所有目标用户端对应的连接通道之前，还包括：

所述连接服务从所述Kafka系统中获取所述第二消息。

本申请第三方面公开了一种计算机可读介质，其上存储有计算机程序，其中，所述程序被处理器执行时实现如上述第一方面中任一所述的方法，或者，执行实现如上述第二方面中任一所述的方法。

本申请第四方面公开了一种电子设备，包括：

一个或多个处理器；

存储装置，其上存储有一个或多个程序；

当所述一个或多个程序被所述一个或多个处理器执行时，使得所述一个或多个处理器实现如上述第一方面中任一所述的方法，或者，实现如上述第二方面中任一所述的方法。

基于上述本发明实施例提供的消息分发方法，由于服务端包括：多个哈希桶，且每一个用户端对应的连接通道均存储于用户端对应的哈希桶中。因此当服务端接收第一用户端发送的第一消息时，服务端对第一消息进行处理，得到第二消息之后，服务端的每一个哈希桶均能够根据第二消息的消息类型，查询出自身存储的所有目标用户端对应的连接通道。其中，目标用户端为第二消息需发送的群组中的用户端。由于多个哈希桶各自查询了自身存储的所有目标用户端对应的连接通道，即查询任务分担至多个桶并行执行，查询效率提高，能够快速找出所有的目标用户端对应的连接通道，进而可以实现服务端针对每一个目标用户端，通过目标用户端对应的连接通道将所述第二消息发送至目标用户端，解决了用户端接收消息延迟的问题。

附图说明

为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据提供的附图获得其他的附图。

图1为一种消息分发系统的结构示意图；

图2为本申请实施例公开的消息分发方法的流程示意图一；

图3为本申请实施例公开的一种连接通道的存储过程的示意图；

图4为本申请实施例公开的一种连接通道的建立过程的流程示意图；

图5为本申请实施例公开的连接通道的存储过程的流程示意图；

图6为本申请实施例公开的消息分发方法的流程示意图二；

图7为本申请实施例公开的消息分发方法的流程示意图三；

图8为本申请实施例公开的消息分发系统的流程示意图。

具体实施方式

下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

在本申请中，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。

在介绍本申请实施例之前，首先对本申请实施例涉及的一些专业术语或概念进行解释。应理解，本申请对以下术语的命名不作具体限定。以下术语可以有其他命名。

（1）Kafka：Kafka是一种高吞吐量的分布式发布订阅消息系统，提供低延时的、高可靠的消息发布与订阅服务。

（2）哈希桶：用于盛放不同键（key）链表的容器。

（3）分桶：分桶是对数据更细粒度的管理的一种方式，使用数据的唯一键（key）的哈希（hash）值对哈希桶的数量进行取模(取余)，之后确定数据放入哪个哈希桶。分桶能够获得更高的查询处理数据的效率。

（4）Go（又称Golang）:是一种静态强类型、编译型、并发型，并具有垃圾回收功能的编程语言。Go支持高并发处理，Go的协程（goroutine）具有以下优点：1、内存消耗小：每个goroutine只占用2kb内存，可以轻松创建大量的goroutine。2、启动时间快于线程。3、原生支持通过通道（channel）进行通信。Go推荐使用通信来并发而不是内存共享，不用操心锁和同步的问题。

为了下述各实施例的描述清楚简洁，首先给出一种直播消息的处理方案的简要介绍：

参阅图1，在一种直播消息的处理系统100中，包括有服务端101和多个直播间用户对应的用户端102。服务端101分别与每一个用户端102相连。服务端101包括：连接服务1011和消息处理服务1012。其中，本申请实施例中提及的直播间用户可以理解为是直播间的主播、管理员、观众等所有加入直播间的用户的统称。

具体的，直播消息的处理系统100的消息处理过程为：当用户进入直播间时，用户对应的用户端102向服务端101发起连接请求，服务端101的连接服务1011收到连接请求后，响应该连接请求，与用户端102建立长连接，并将长连接的相关信息（可以理解为是路由信息）缓存到一张哈希表上。当用户端102产生互动消息之后，用户端102会将消息发送至服务端101的连接服务1011。连接服务1011将消息流转至消息处理服务1012进行内容上的过滤处理，然后将处理后的消息发送给连接服务1011，连接服务1011从哈希表中依次查询直播间内的每一个用户的长连接的相关信息，并利用查询到的长连接的相关信息，通过长连接通道发送处理后的消息至用户端102。当用户退出直播间时，连接服务1011会将缓存在哈希表上的长连接的相关信息删除，释放缓存。

由上述直播消息的处理方案可以看出，当有大量消息需要分别发送给直播间的大量用户时，即服务端101有大量消息需要分发处理时，直播消息的处理过程中存在有以下两个问题：

（1）连接服务1011会同时收到消息处理服务1012发来的大量处理后的消息，造成服务端101并发量飙升，内存占用升高，容易出现发送消息阻塞。

（2）由于直播间有大量的用户，造成连接服务1011缓存在哈希表的长连接过多，查询处理效率很慢，进一步造成服务端101处理速度变慢，用户等待较长时间才会收到直播间消息，甚至无法收到直播间消息。

综上所述，上述直播消息的处理方案中，在服务端101有大量消息需要分发处理的情况下，容易出现直播间用户延迟接收到消息、甚至无法接收到消息的问题。而直播场景下往往需要进行大量的互动，例如用户进场、发言、送礼，以及管理员禁言、踢出用户等交互操作，均需要在直播间实时显示相应的消息，消息的延迟到达会造成很差的用户体验。同样的，在聊天室场景、大型群聊场景等可能需要服务端分发处理大量消息的场景下，也存在上述提及的问题。

实施例一

参阅图2，基于上述问题，本申请实施例提出了一种消息分发方法，能够解决消息延迟接收的问题。图2示出的消息分发方法由服务端和第一用户端之间交互执行。其中，服务端分别与多个用户端之间建立了连接通道。第一用户端可以理解为是任意一个与服务端之间建立了连接通道的用户端。服务端包括：多个哈希桶。每一个用户端对应的连接通道均存储于该用户端对应的哈希桶中。

示例性的，如图3所示，每一个用户端对应的连接通道可以为长连接通道，由图3可以看出，不同通道各自存储到自身对应的哈希桶301中，即每一个哈希桶中都存储了部分已建立好的连接通道。

需要说明的是，图2示出的方法可以应用于直播间、聊天室等多人交互的场景。还需要说明的是，本申请实施例中的服务端和用户端均可以理解为是手机、笔记本电脑、电脑等一个或多个电子设备的集群。图2示出的方法可以采用Go编程语言开发的程序实现，基于前述对Go的介绍可知，采用Go语言编写图2示出的方法流程，可实现消息的快速分发，支持动态扩容，提升了消息发送能力。具体的，图2示出的消息分发方法具体包括以下步骤:

S201、第一用户端发送第一消息至服务端。

其中，第一消息可以理解为是第一用户端对应的用户执行交互操作触发生成的消息。例如，若图2示出的方法应用于直播场景下，第一消息可以是用于说明直播间用户进入直播间的进场消息、也可以是用于说明直播间用户向主播送的礼物的消息、也可以是用于说明直播间用户发言内容的消息，也可以是用于说明直播间的管理员在直播间进行用户禁言、踢出用户、发布系统消息等类型的消息。又例如，若图2示出的方法应用于聊天室场景，第一消息可以是用户的发言消息、管理员允许用户加入群聊的提示消息等等。第一消息具体携带的消息内容、消息类型以及消息的格式等，本申请实施例对此不作限制。

可选地，第一消息除了携带有第一用户端对应用户具体需分发至其他用户端的消息内容之外，还可以携带有第一用户端对应用户的标识、第一用户端对应用户所在的群组标识、第一消息的消息类型、第一用户端对应的连接通道的时间戳等一项或多项信息。其中，第一用户端对应用户所在的群组标识可以理解为是用于说明第一消息需发送的群组的标识，例如可以是第一用户端对应用户所在的直播间房间号、或者第一用户端对应用户当前加入的聊天室号等等。第一用户端对应的连接通道的时间戳可以理解为是建立第一用户端对应的连接通道时的时间。本申请实施例对于第一消息中具体携带的信息不作限制。

可选地，在本申请一具体实施例中，执行步骤S201的一种实施方式为：第一用户端通过第一用户端对应的连接通道，向服务端发送第一消息。

具体的，第一用户端对应的连接通道用于实现第一用户端与服务端之间的交互通信。第一用户端和服务端之间预先建立好连接通道之后，第一用户端即可使用构建好的连接通道的路由信息，与服务端通信。因此，当第一用户端需要向服务端发送第一消息时，则可以使用第一用户端对应的连接通道传输第一消息至服务端。

可选地，参阅图4，每一个用户端对应的连接通道的建立过程，均可以通过以下步骤建立：

S401、用户端向服务端发送连接请求。

其中，连接请求用于请求建立连接通道。连接请求中可以携带有用户端对应用户的标识信息（例如用户的ID），还可以携带有用户端对应用户的群组标识，发送连接请求的时间戳等信息。连接请求中所携带的信息、具体的请求格式等本申请实施例不作限制。

可选地，用户端发送的连接请求可以是长连接请求，长连接请求用于请求建立长连接通道，以实现用户端与服务端之间保持长连接状态。长连接状态下用户端与服务端之间可随时通信。示例性的，长连接请求可以为WebSocket长连接请求。有关WebSocket的相关内容可以参考现有技术中对WebSocket的技术描述，此处不再赘述。还需要说明的是，本申请实施例对于连接请求所具体采用的请求协议方式不作限制。

在一些实施例中，步骤S401可以由用户进入群组的操作触发执行。例如，当用户点击进入某直播间时，用户端响应于用户进入直播间的操作，向服务端发送连接请求。其中，本申请实施例所提及的群组均可以理解为是直播间、聊天室等具有多人交互功能的小组。

S402、服务端响应于连接请求，与用户端建立用户端对应的连接通道。

其中，本申请实施例所提及的用户端对应的连接通道，均可以理解为是用户端与服务端之间的连接通道。

示例性的，执行步骤S402的一种实施方式可以是：服务端响应于WebSocket长连接请求，与用户端建立用户端对应的WebSocket长连接通道。

可选地，执行完步骤S402之后，服务端可以返回连接成功消息至该用户端。该连接成功消息用于说明用户端对应的连接通道成功建立。可选地，连接成功消息中可以携带有连接通道的连接信息。该服务端和该用户端可通过该连接信息实现交互通信。具体的，该连接信息可以理解为是一种路由信息。

其中，服务端响应于连接请求，与用户端建立用户端对应的连接通道的过程，可以参考现有技术中的通信相关的连接建立过程，此处不再赘述。

可选地，服务端可以在执行步骤S402之后，将该连接通道（即连接通道对应的连接信息）存储于用户端对应的哈希桶中。示例性的，参阅图5，每一个连接通道的存储过程，均可以通过以下步骤实现存储：

S501、服务端根据用户端的特定信息，生成用户端的唯一键。

其中，用户端的唯一键可以理解为是用户端所特有的、唯一的键（key）。用户端的特定信息也可以理解为是用户端所特有的信息。示例性的，用户端的特定信息可以包括：用户端对应的用户标识和用户端对应的连接通道的时间戳。用户端对应的用户标识以及用户端对应的连接通道的时间戳，组成了用户端的特定信息，不会与其他用户端的特定信息相同。

在另一些实施例中，也可以使用其他类型的信息，例如用户端的地址信息等作为用户端的特定信息，只需为用户端特有的信息即可，本申请实施例对此不作限制。

S502、服务端使用唯一键的哈希值对哈希桶总数量进行取余运算，确定出用户端对应的哈希桶。

其中，哈希桶总数量指的是图2提及的方法中，服务端所包括的哈希桶的总数。唯一键的哈希值指的是对步骤S501中得到的唯一键进行哈希运算之后所得到的哈希值。用户端对应的哈希桶可以理解为是用于存储用户端对应的连接通道的哈希桶。取余运算也可以称为取模运算。服务端使用唯一键的哈希值对哈希桶总数量进行取余运算之后所得到的数值，可以理解为是哈希桶的序号。

示例性的，可以参阅图3，图3示出的连接通道根据哈希值（Hash）对哈希桶总数量N进行求余运算，其中图3示出的“%”为求余运算符号，“+”为求和符号，“Hash”为哈希运算符号。进而确定出该连接通道需存储到哪一个哈希桶。其中，Hash值是通过用户ID和时间戳（即建立连接通道的时间戳）进行哈希运算得到的。

需要说明的是，步骤S502仅为服务端为用户端对应的连接通道进行分桶的一种方式，还有其他方式可以确定出用户端对应的哈希桶，例如可以对多个哈希桶进行排序，按照建立连接通道的顺序依次存放至多个哈希桶中。本申请实施例对于确定出用户端对应的哈希桶的方式不作限制。

S503、服务端将用户端对应的连接通道存储于用户端对应的哈希桶中。

其中，存储用户端对应的连接通道也可以理解为是存储用户端对应的连接通道的连接信息（也可以理解为是路由信息）。服务端的每一个哈希桶均按照用户端对应用户的群组标识，对自身存储的所有用户端对应的连接通道进行分组。

用户端对应用户的群组标识用于说明用户端对应用户当前加入的群组。该用户端对应用户的群组标识可以携带在用户端发送的连接请求中。具体的，执行步骤S503的过程可以是，服务端按照用户端对应用户的群组标识，将用户端对应的连接通道关联存储至用户端对应的哈希桶中的该群组标识下。例如，在直播场景下，总共有1000个直播间。在经过步骤S501至步骤S502后，服务端确定出某个用户端对应的哈希桶为第3号哈希桶，且通过该用户端的连接请求中携带的信息，确定出该用户端对应用户的群组标识为第20号直播间，因此，服务端就将该用户端对应的连接通道存储在第3号哈希桶中的第20号直播间的分组中。

通过步骤S501至步骤S503，多个用户端对应的连接通道均被存储到了各自对应的哈希桶中，区别于现有技术中在同一张哈希表中存储了所有连接通道的方式，本申请中不同哈希桶中所存储的连接通道互不相同，进而后续查询哈希桶查询连接通道时，多个哈希桶可以分工查询连接通道，提高了查询效率。

需要说明的是，图4示出的每一个用户端对应的连接通道的建立过程以及每一个连接通道的存储过程可以理解为是发生在用户端与服务端进行通信交互之前的预处理过程。即用户端与服务端进行通信交流之前，可以预先通过图4示出的步骤与服务端建立连接通道，进而后续可通过建立好的连接通道进行通信交互。而图5示出的连接通道的存储过程，可以理解为是包括在建立连接通道过程中的其中一个过程。

可以理解的是，本申请实施例中图2示出的第一用户端和服务端之间的交互过程，执行于第一用户端和服务端之间预先建立了连接通道以及服务端对第一用户端对应的连接通道进行存储之后。第一用户端和服务端之间建立连接通道的过程可以如图4所示。第一用户端对应的连接通道的存储过程可以如图5所示，此处不再赘述。本申请实施例提及的第一用户端在执行步骤S201之前可以通过执行图4以及图5的流程，与服务端建立连接通道，并使得服务端将第一用户端对应的连接通道进行存储。继而后续第一用户端和服务端之间，再基于预先建立好的连接通道以及服务端中预先存储好的连接通道，执行图2示出的交互过程。

S202、服务端对第一消息进行处理，得到第二消息。

其中，第二消息中至少包括部分第一消息的部分消息内容。例如，第一消息为用户评论的“主播加油”，那么第二消息中也携带有该用户评论“主播加油”的消息内容。第二消息可以理解为是经过处理之后的第一消息。对第一消息进行的处理操作的方式，具体可依据第一消息的类型而定。示例性的，若第一消息属于用户评论类消息，则进行过滤处理操作。若第一消息为该用户对某用户禁言、该用户向主播送礼物、该用户进场等一系列具有固定格式的系统类消息，则按照具体的消息类型，处理生成对应的系统类消息（即第二消息）。

具体的，举例说明，若第一消息属于是直播间评论类消息，则可以对第一消息进行消息内容过滤，进而得到第二消息。示例性的，可以根据发送第一消息的用户是否是黑名单用户、发送内容是否包含违禁词等做第一消息内容上的过滤，进而使得经过内容过滤后得到的第二消息能够符合直播间的评论管理规范。又例如，若第一消息属于是用户送礼物的系统提醒类消息，则服务端可通过预配置的系统提醒内容，生成对应的第二消息，第二消息用于提示直播间该用户为主播进行了送礼。

需要说明的是，服务端执行步骤S202时，可以通过一个或多个预先开发好的服务配合执行，本申请实施例对于具体执行步骤S202的服务，和/或单元的类型、数量，以及执行过程，不做限制。

S203、服务端的每一个哈希桶，均根据第二消息的消息类型，查询出自身存储的所有目标用户端对应的连接通道。

其中，第二消息的消息类型用于说明第二消息需发送的群组。目标用户端为属于第二消息需发送的群组中的用户端，即需要接收第二消息的用户端。需要说明的是，本申请实施例所提及的群组均可以理解为是可供多人进行交互的小组，后续不再赘述。第二消息的消息类型可以包括发言、送礼、进场等等。服务端根据第二消息的消息类型，可以确定出第二消息需分发到哪些群组中。例如，若第二消息为发言，则只需发送到第一用户端对应用户所在的群组即可。若第二消息为提示第一用户端对应用户送了最高级别的礼物，则发送到所有的群组中进行系统提示。

可选地，第二消息的消息类型中可以包括有需发送第二消息的群组标识，进而每一个哈希桶均可以根据需发送第二消息的群组标识，查询出自身存储的所有属于需发送第二消息的群组中的用户端（即目标客户端）对应的连接通道。可选地，还可以是服务端中预先存储不同消息类型所对应的分发群组的规则。进而每一个哈希桶均根据该消息类型对应的分发群组规则，确定出需分发第二消息的群组有哪些，进一步根据需分发第二消息的群组，查询出自身存储的所有目标用户端对应的连接通道。

在一些实施例中，由于每一个哈希桶都对自身存储的每一个连接通道按照群组进行了分组，因此能够通过第二消息的消息类型所说明的第二消息需发送的群组，查找到自身存储的、第二消息需发送的群组下的每一个连接通道（即目标用户端对应的连接通道）。

在另一些实施例中，还可以是每一个哈希桶预先将每一个用户端对应的连接通道与该用户端对应用户的群组进行对应存储，进而可以通过查询第二消息需发送的群组的方式，查找到所有目标用户端对应的连接通道。

可选地，步骤S203可以通过步骤S202得到第二消息之后触发执行。当第一消息完成处理得到了第二消息之后，则说明服务端可以进入到分发第二消息的环节，进而触发服务端的每一个哈希桶执行步骤S203。

示例性的，执行步骤S203的过程可以是：服务端的每一个哈希桶，均在监听到需发送第二消息时，根据第二消息的消息类型，查询出自身存储的所有目标用户端对应的连接通道。

其中，哈希桶监听到需发送第二消息的具体方式有很多，例如，可以是哈希桶在监听到服务端得到第二消息时，认为已监听到需发送第二消息，进而触发执行步骤S203。又例如，可以是哈希桶在监听到第二消息已生成的提示消息之后，认为监听到需发送第二消息，触发执行步骤S203。

需要说明的是，哈希桶实现监听、查询功能的方式有很多，例如若图2示出的方法采用Go语言进行开发实现，则哈希桶可以通过维护一个协程的方式实现监听、查询等功能，以执行步骤S203。即每一个哈希桶均维护一个协程，该协程用于监听第二消息，到监听到第二消息时，该协程自动触发根据第二消息的消息类型，查询出自身存储的所有目标用户端对应的连接通道。不同哈希桶之间均是独立、并发运行的，彼此互不干扰，分工查询出所有目标用户端对应的连接通道。

个别情况下，服务端会同时接收到多个第一用户端发送的第一消息，进而产生大量的第二消息需要分发。为了避免服务端因需要处理的第二消息的数量过大，而导致服务端服务压力过大、负载严重、消息分发堵塞的情况，服务端在执行步骤S203之前，还可以包括：

服务端将第二消息缓存至Kafka系统。其中，服务端将第二消息分别发送至每一个目标用户端之前，还包括：服务端从Kafka系统中获取第二消息。

其中，Kafka系统（也可以称为Kafka集群）可以包含在服务端中，也可以是位于第三方平台，本申请实施例对于Kafka系统所设置的位置不作限制。当服务端将第二消息缓存至Kafka系统之后，Kafka系统按照消息队列顺序缓存第二消息。服务端在处理完之前的消息分发的任务，或者负载不高的情况下，再主动从Kafka系统中获取第二消息。即服务端可通过将第二消息缓存到Kafka系统的方式，避免需同时分发大量的第二消息，达到流量削峰的作用，防止短时间内的高流量压垮服务，缓解服务压力。直至服务端能够有空闲处理更多的第二消息时，再从Kafka系统主动消费（即获取）第二消息。

可选地，服务端将第二消息缓存至Kafka系统的方式为，服务端将第二消息缓存至Kafka系统的消息队列。Kafka系统的消息队列中按照服务端的发送顺序排列缓存着至少一个第二消息。可选地，Kafka系统的消息队列接收到新的第二消息后，会提醒服务端有新缓存的第二消息。进而服务端可以在空闲的时候主动从Kafka系统中消费新缓存的第二消息。

由前述对哈希桶存储连接通道的过程的描述可知，不同哈希桶中所维护的连接通道都不同，因此当服务端需要发送第二消息时，多个哈希桶都各自查询自身所存储的连接通道即可，多个哈希桶的查询过程相互独立，互不干扰，即查询任务分担至多个桶并行执行，查询效率提高，能够快速找出所有的目标用户端对应的连接通道，进而可以实现服务端快速将第二消息分别发送至每一个目标用户端，解决了用户端接收消息延迟的问题。相较于现有技术中在一个哈希表中查询出所有的用户端的方式，效率更高。

S204、服务端针对每一个目标用户端，通过目标用户端对应的连接通道将第二消息发送至目标用户端。

由于步骤S203中通过多个哈希桶共同查找出了所有目标用户端的连接通道，因此服务端可以将第二消息分别通过每一个目标用户端对应的连接通道发送至该目标用户端，以使得所有目标用户端接收到第二消息。目标用户端在接收到第二消息之后，在目标用户端的显示界面上显示该第二消息，完成了第二消息的分发。

举例说明，若第二消息为评论类型的消息，那么目标用户端就对第一用户端对应用户所在的群组中的所有用户端（包括第一用户端在内），执行步骤S204的过程为服务端将第二消息分发到第一用户端对应用户所在的群组中的所有用户端。

需要说明的是，所有目标用户端与服务端之间均处于连接状态，进而服务端才能够成功通过连接通道发送第二消息至该目标用户端。

可选地，当用户端对应的用户退出群组时（例如退出直播间、退出聊天室等情况），用户端可以向服务端发送退出群组请求，服务端接收到退出群组请求后，响应于该退出群组请求，断开与该用户端之间的连接通道，并从哈希桶中删除掉该用户对应的连接通道。后续当第一用户端和服务端再次执行图2示出的流程时，已退出群组的用户端不会再被哈希桶查询到对应的连接通道，进而服务端也不会向该用户端发送第二消息。服务端通过及时删除哈希桶中的连接通道的管理方式，可以减少不必要的查询工作量。

本申请实施例中，由于服务端包括：多个哈希桶，且每一个用户端对应的连接通道均存储于用户端对应的哈希桶中。因此当服务端接收第一用户端发送的第一消息时，服务端对第一消息进行处理，得到第二消息之后，服务端的每一个哈希桶均能够根据第二消息的消息类型，查询出自身存储的所有目标用户端对应的连接通道。其中，目标用户端为第二消息需发送的群组中的用户端。由于多个哈希桶各自查询了自身存储的所有目标用户端对应的连接通道，即查询任务分担至多个桶并行执行，查询效率提高，能够快速找出所有的目标用户端对应的连接通道，进而可以实现服务端针对每一个目标用户端，通过目标用户端对应的连接通道将所述第二消息发送至目标用户端，解决了用户端接收消息延迟的问题。

基于图2示出的方法，本申请实施例还提出了另一种消息分发系统，该消息分发系统，包括服务端和多个用户端。其中，服务端分别与多个用户端之间建立了连接通道。服务端包括：多个哈希桶。每一个用户端对应的连接通道均存储于该用户端对应的哈希桶中。其中，系统中的服务端用于执行图2示出的服务端所执行的步骤，第一用户端用于执行图2示出第一用户端所执行的步骤。第一用户端可以理解为是任意一个与服务端之间建立了连接通道的用户端。

实施例二

为了解决接收消息延迟的问题，本申请实施例还对服务端开发了多个服务，以支持服务端实现图2示出的方法中的流程。具体的，参阅图6，本申请实施例提出了另一种消息分发方法，该消息分发方法同样通过服务端与第一用户端交互实现，其中服务端包括连接服务和消息处理服务。服务端分别与多个用户端之间建立了连接通道。该连接服务包括：多个哈希桶；每一个用户端对应的连接通道均存储于用户端对应的哈希桶中。具体的，图6示出的消息分发方法包括以下步骤：

S601、第一用户端发送第一消息至连接服务。

其中，第一用户端为与服务端之间建立了连接通道的任一用户端。连接服务主要用于建立或断开连接通道以及收发消息。

具体的，第一用户端执行步骤S601的执行过程和原理，可以参考前述图2示出的步骤S201，此处不再赘述。

可选地，每一个用户端对应的连接通道的建立过程，包括：用户端向连接服务发送连接请求，连接服务响应于连接请求，与用户端建立第一用户端对应的连接通道。具体的执行过程和原理可以参考图4示出的每一个用户端对应的连接通道的建立过程的相关内容，此处不再赘述。

可选地，每一个连接通道的存储过程，包括：连接服务根据用户端的特定信息，生成用户端的唯一键。连接服务使用唯一键的哈希值对哈希桶总数量进行取余运算，确定出用户端对应的哈希桶。具体的执行过程和原理可以参考图5示出的每一个连接通道的存储过程的相关内容，此处不再赘述。

S602、连接服务将第一消息发送至消息处理服务。

本申请实施例中，服务端中的消息处理服务主要用于对消息执行处理操作。因此，当连接服务接收到第一消息后，则可以将第一消息流转至消息处理服务中，由消息处理服务进行处理。

在一些实施例中，消息处理服务可以预构建消息队列，用于按照接收顺序将第一消息缓存在消息队列中。

S603、消息处理服务对第一消息进行处理，得到第二消息。

在一些实施例中，连接服务也可以具备消息处理功能。当第一消息可以使用连接服务进行处理时，则不需要执行步骤S602和S603，直接由连接服务对第一消息进行处理，得到第二消息。

在另一些实施例中，可以根据第一消息的类型，确定采用连接服务处理还是采用消息处理服务处理。例如，若第一消息的类型属于系统提示类的消息（比如进场、禁言等），则确定采用连接服务进行处理，连接服务根据第一消息，处理生成第一消息对应的系统提示消息（即第二消息）。若第一消息属于评论类消息，则确定采用消息处理服务进行处理，消息处理服务对第一消息进行内容过滤处理，得到第二消息。即对第一消息进行处理，得到第二消息的过程可以由连接服务，和/或，消息处理服务共同配合执行，具体执行过程和原理可以参考前述步骤S202，此处不再赘述。

S604、消息处理服务将第二消息发送至连接服务。

消息处理服务处理得到第二消息后，将第二消息流转到连接服务，由连接服务负责第二消息的分发操作。

在另一些实施例中，消息处理服务也可以不直接将第二消息发送至连接服务，而是先将第二消息进行缓存（例如发送到Kafka系统进行缓存），然后连接服务再从缓存中获取第二消息，即消息处理服务将第二消息流转到连接服务的方式有很多，包括但不限于本申请实施例所提出的内容。

S605、连接服务的每一个哈希桶，均根据第二消息的消息类型，查询出自身存储的所有目标用户端对应的连接通道。

其中，第二消息的消息类型用于说明第二消息需发送的群组，目标用户端为属于第二消息需发送的群组中的用户端。

步骤S605的执行过程和原理，可以参考前述步骤S203，此处不再赘述。

S606、连接服务针对每一个目标用户端，通过目标用户端对应的连接通道将第二消息发送至目标用户端。

其中，步骤S606的执行过程和原理，可以参考前述步骤S204，此处不再赘述。

本申请实施例中，由于服务端包括：多个哈希桶，且每一个用户端对应的连接通道均存储于用户端对应的哈希桶中。因此当连接服务接收第一用户端发送的第一消息时，连接服务或者消息处理服务对第一消息进行处理，得到第二消息之后，连接服务的每一个哈希桶均能够根据第二消息的消息类型，查询出自身存储的所有目标用户端对应的连接通道。其中，目标用户端为第二消息需发送的群组中的用户端。由于多个哈希桶各自查询了自身存储的所有目标用户端对应的连接通道，即查询任务分担至多个桶并行执行，查询效率提高，能够快速找出所有的目标用户端对应的连接通道，进而可以实现服务端针对每一个目标用户端，通过目标用户端对应的连接通道将所述第二消息发送至目标用户端，解决了用户端接收消息延迟的问题。

基于图6示出的方法，本申请实施例还提出了对应的一种消息分发系统，该消息分发系统，包括服务端和多个用户端。服务端包括：连接服务和消息处理服务。其中，服务端分别与多个用户端之间建立了连接通道。连接服务包括：多个哈希桶。每一个用户端对应的连接通道均存储于该用户端对应的哈希桶中。其中，系统中的连接服务用于执行图6示出的连接服务所执行的步骤，系统中的消息处理服务用于执行图6示出的消息处理服务所执行的步骤，第一用户端用于执行图6示出第一用户端所执行的步骤。第一用户端可以理解为是任意一个与服务端之间建立了连接通道的用户端。

需要说明的是，在另一些实施例中，上述消息分发系统中也可以不包括消息处理服务。例如当第一消息均由连接服务处理，或者由第三方平台处理时，则系统中可以不包括消息处理服务。

实施例三

参阅图7，为了避免服务端因需要处理的第二消息的数量过大，而导致服务端服务压力过大、负载严重、消息分发堵塞的情况，本申请实施例还提出了另一种消息分发方法，该消息分发方法同样通过服务端与第一用户端交互实现，其中服务端包括连接服务、消息处理服务、以及Kafka系统。服务端分别与多个用户端之间建立了连接通道。该连接服务包括：多个哈希桶；每一个用户端对应的连接通道均存储于用户端对应的哈希桶中。具体的，图7示出的消息分发方法包括以下步骤：

S701、第一用户端发送第一消息至连接服务。

其中，第一用户端为与服务端之间建立了连接通道的任一用户端。连接服务主要用于建立或断开连接通道以及收发消息。

具体的，第一用户端执行步骤S701的执行过程和原理，可以参考前述图6示出的步骤S601，此处不再赘述。

S702、连接服务将第一消息发送至消息处理服务。

具体的，连接服务执行步骤S702的执行过程和原理，可以参考前述图6示出的步骤S602，此处不再赘述。

S703、消息处理服务对第一消息进行处理，得到第二消息。

在一些实施例中，连接服务也可以具备消息处理功能。当第一消息可以使用连接服务进行处理时，则不需要执行步骤S702和S703，直接由连接服务对第一消息进行处理，得到第二消息。

在另一些实施例中，可以根据第一消息的类型，确定采用连接服务处理还是采用消息处理服务处理。

具体的，消息处理服务行步骤S703的执行过程和原理，可以参考前述图6示出的步骤S603，此处不再赘述。

S704、消息处理服务将第二消息发送至Kafka系统。

S705、Kafka系统缓存第二消息。

其中，步骤S704至步骤S705的执行过程和原理，可以参考实施例一中“服务端将第二消息缓存至Kafka系统”的执行过程和原理，此处不再赘述。

S706、连接服务从Kafka系统中获取第二消息。

其中，步骤S706的执行过程和原理，可以参考实施例一中“服务端从Kafka系统中获取第二消息”的执行过程和原理，此处不再赘述。

连接服务在处理完之前的消息分发的任务，或者负载不高的情况下，再主动从Kafka系统中获取第二消息。即消息处理服务将第二消息缓存到Kafka系统的方式，避免出现连接服务同时接收并分发大量的第二消息的情况，达到流量削峰的作用，防止短时间内的高流量压垮服务，缓解服务压力。直至连接服务能够有空闲处理更多的第二消息时，再从Kafka系统主动消费（即获取）第二消息。

需要说明的是，在另一些实施例中，在步骤S701之后，也可以不执行步骤S702至步骤S704，而是直接由连接服务执行对第一消息进行处理，得到第二消息，然后连接服务将第二消息发送至Kafka系统，Kafka系统缓存第二消息，再等到连接服务具备处理第二消息的条件时，主动从Kafka系统中获取第二消息。即第二消息不一定是通过消息处理服务缓存至Kafka系统中，也可以不经过消息处理服务，直接由连接服务缓存到Kafka系统中。第二消息缓存到Kafka系统中的具体方式有很多，本申请实施例对此不作限制。

S707、连接服务的每一个哈希桶，均根据第二消息的消息类型，查询出自身存储的所有目标用户端对应的连接通道。

其中，步骤S707的执行过程和原理，可以参考图6的步骤S605的执行过程和原理，此处不再赘述。

S708、连接服务针对每一个目标用户端，通过目标用户端对应的连接通道将第二消息发送至目标用户端。

其中，步骤S708的执行过程和原理，可以参考图6的步骤S606的执行过程和原理，此处不再赘述。

举例说明，图7示出的方法的具体流程可以如图8所示：步骤1、用户（即前述提及的第一用户端）向连接服务发送建立长连接的请求（也可以理解为建立长连接通道的请求）。步骤2、连接服务响应于连接长连接的请求，创建长连接通道，并将长连接通道的信息存储在对应的哈希桶中。步骤3、用户向连接服务发送消息（即前述提及的第一消息）。步骤4、连接服务将第一消息流转至消息处理服务进行处理，得到第二消息。步骤5、消息处理服务将第二消息发送至Kafka系统的消息队列，由Kafka系统对第二消息进行缓存。步骤6、连接服务从Kafka系统中消费第二消息。步骤7、连接服务分发第二消息。具体的，连接服务的每一个哈希桶，均根据第二消息的消息类型，查询出自身存储的所有目标用户端对应的连接通道。然后针对每一个目标用户端，通过目标用户端对应的连接通道将第二消息发送至目标用户端。

基于图7示出的方法，本申请实施例还提出了对应的一种消息分发系统，该消息分发系统，包括服务端和多个用户端。服务端包括：连接服务、消息处理服务以及Kafka系统。其中，服务端分别与多个用户端之间建立了连接通道。连接服务包括：多个哈希桶。每一个用户端对应的连接通道均存储于该用户端对应的哈希桶中。其中，系统中的连接服务用于执行图7示出的连接服务所执行的步骤，系统中的消息处理服务用于执行图7示出的消息处理服务所执行的步骤。Kafka系统用于执行图7示出的Kafka系统所执行的步骤。第一用户端用于执行图7示出第一用户端所执行的步骤。第一用户端可以理解为是任意一个与服务端之间建立了连接通道的用户端。

需要说明的是，在另一些实施例中，上述消息分发系统中也可以不包括消息处理服务。例如当第一消息均由连接服务处理，或者由第三方平台处理时，则系统中可以不包括消息处理服务。

本申请实施例还公开了一种计算机可读介质，其上存储有计算机程序，其中，所述程序被处理器执行时实现如上述提及的服务端所执行的任一所述的方法，或者，执行实现第一用户端在上述所执行的任一所述的方法。

本申请实施例还公开了一种电子设备，包括：一个或多个处理器；存储装置，其上存储有一个或多个程序。当一个或多个程序被一个或多个处理器执行时，使得一个或多个处理器实现如上述任一实施例中服务端执行的步骤，或者，实现如上述任一实施例中第一用户端执行的步骤。

本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于系统或系统实施例而言，由于其基本相似于方法实施例，所以描述得比较简单，相关之处参见方法实施例的部分说明即可。以上所描述的系统及系统实施例仅仅是示意性的，其中所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。本领域普通技术人员在不付出创造性劳动的情况下，即可以理解并实施。

专业人员还可以进一步意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件、计算机软件或者二者的结合来实现，为了清楚地说明硬件和软件的可互换性，在上述说明中已经按照功能一般性地描述了各示例的组成及步骤。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本发明的范围。

对所公开的实施例的上述说明，使本领域专业技术人员能够实现或使用本发明。对这些实施例的多种修改对本领域的专业技术人员来说将是显而易见的，本文中所定义的一般原理可以在不脱离本发明的精神或范围的情况下，在其它实施例中实现。因此，本发明将不会被限制于本文所示的这些实施例，而是要符合与本文所公开的原理和新颖特点相一致的最宽的范围。

Claims (10)

1.一种消息分发方法，其特征在于，应用于服务端，所述服务端分别与多个用户端之间建立了连接通道；所述服务端包括：多个哈希桶；每一个所述用户端对应的连接通道均存储于所述用户端对应的哈希桶中；所述消息分发方法包括：

所述服务端接收第一用户端发送的第一消息；其中，所述第一用户端为与所述服务端之间建立了连接通道的任一用户端；

所述服务端对所述第一消息进行处理，得到第二消息；

所述服务端的每一个哈希桶，均根据所述第二消息的消息类型，查询出自身存储的所有目标用户端对应的连接通道；其中，所述第二消息的消息类型用于说明所述第二消息需发送的群组；所述目标用户端为属于所述第二消息需发送的群组中的用户端；

所述服务端针对每一个所述目标用户端，通过所述目标用户端对应的连接通道将所述第二消息发送至所述目标用户端。

2.根据权利要求1所述的消息分发方法，其特征在于，所述用户端对应的连接通道的建立过程，包括：

所述服务端接收所述用户端发送的连接请求；

所述服务端响应于所述连接请求，与所述用户端建立所述用户端对应的连接通道。

3.根据权利要求1所述的消息分发方法，其特征在于，所述用户端对应的连接通道的存储过程，包括：

所述服务端根据所述用户端的特定信息，生成所述用户端的唯一键；

所述服务端使用所述唯一键的哈希值对哈希桶总数量进行取余运算，确定出所述用户端对应的哈希桶；

所述服务端将所述用户端对应的连接通道存储于所述用户端对应的哈希桶中；其中，所述服务端的每一个所述哈希桶均按照用户端对应用户的群组标识，对自身存储的所有用户端对应的连接通道进行分组。

4.根据权利要求1所述的消息分发方法，其特征在于，所述服务端对所述第一消息进行处理，得到第二消息之后，还包括：

所述服务端将所述第二消息缓存至Kafka系统；

所述服务端针对每一个所述目标用户端，通过所述目标用户端对应的连接通道将所述第二消息发送至所述目标用户端之前，还包括：

所述服务端从所述Kafka系统中获取所述第二消息。

5.根据权利要求1所述的消息分发方法，其特征在于，所述服务端的每一个哈希桶，均根据所述第二消息的消息类型，查询出自身存储的所有目标用户端对应的连接通道，包括：

所述服务端的每一个哈希桶，均在监听到需发送所述第二消息时，根据所述第二消息的消息类型，查询出自身存储的所有目标用户端对应的连接通道。

6.一种消息分发方法，其特征在于，应用于服务端，所述服务端分别与多个用户端之间建立了连接通道；所述服务端包括：连接服务和消息处理服务；所述连接服务包括：多个哈希桶；每一个所述用户端对应的连接通道均存储于所述用户端对应的哈希桶中；所述消息分发方法包括：

所述连接服务接收第一用户端发送的第一消息；其中，所述第一用户端为与所述服务端之间建立了连接通道的任一用户端；

所述连接服务或所述消息处理服务对所述第一消息进行处理，得到第二消息；

所述连接服务的每一个哈希桶，均根据所述第二消息的消息类型，查询出自身存储的所有目标用户端对应的连接通道；其中，所述第二消息的消息类型用于说明所述第二消息需发送的群组；所述目标用户端为属于所述第二消息需发送的群组中的用户端；

所述连接服务针对每一个所述目标用户端，通过所述目标用户端对应的连接通道将所述第二消息发送至所述目标用户端。

7.根据权利要求6所述的消息分发方法，其特征在于，若所述消息处理服务对所述第一消息进行处理，得到第二消息，则所述连接服务接收第一用户端发送的第一消息之后，还包括：

所述连接服务将所述第一消息发送至所述消息处理服务。

8.根据权利要求6所述的消息分发方法，其特征在于，所述服务端还包括：Kafka系统；所述连接服务或所述消息处理服务对所述第一消息进行处理，得到第二消息之后，还包括：

所述Kafka系统接收并缓存所述第二消息；

所述连接服务的每一个哈希桶，均根据所述第二消息的消息类型，查询出自身存储的所有目标用户端对应的连接通道之前，还包括：

所述连接服务从所述Kafka系统中获取所述第二消息。

9.一种计算机可读介质，其特征在于，其上存储有计算机程序，其中，所述程序被处理器执行时实现如权利要求1至5中任一所述的方法，或者，执行实现如权利要求6至8中任一所述的方法。

10.一种电子设备，其特征在于，包括：

一个或多个处理器；

存储装置，其上存储有一个或多个程序；

当所述一个或多个程序被所述一个或多个处理器执行时，使得所述一个或多个处理器实现如权利要求1至5中任一所述的方法，或者，实现如权利要求6至8中任一所述的方法。

Images