CN110401840A - 消息推送方法、装置、系统、电子设备及计算机可读介质 - Google Patents

Abstract

本公开涉及一种消息推送方法、装置、系统、电子设备及计算机可读介质。可用于视频直播间中，该直播间包括消息产生端与多个消息接收端，该方法包括：将多个消息接收端进行分组处理，得到多个接收组；为多个接收组中的每一个接收组分别确定与其对应的推送服务器；以及将目标消息通过与接收组对应的推送服务器推送至所述接收组内的消息接收端。本公开涉及的消息推送方法、装置、系统、电子设备及计算机可读介质，能够将海量消息实时分发至用户。

Description

消息推送方法、装置、系统、电子设备及计算机可读介质

技术领域

本公开涉及计算机信息处理领域，具体而言，涉及一种消息推送方法、装置、系统、电子设备及计算机可读介质。

背景技术

目前，随着视频直播行业的快速发展，各种各样的直播平台层出不穷，为人们的日常办公以及社交娱乐等方面提供了诸多方便。对于实时流媒体直播平台，互动性是网络互动直播关注的重点。对于视频直播类应用来说，用户对视频的点赞、评论、用户私信、主播作品发布后实时推送给自己的粉丝以及全网用户的实时推送等互动类的消息的时效性是保证视频直播流畅性的关键。

目前，在现有技术中的互动类的消息推送的方案中，要么存在时延性较高的问题，要么对直播间或者直播间的用户数量有限制。

发明内容

有鉴于此，本公开提供一种消息推送方法、装置、系统、电子设备及计算机可读介质，能够将海量消息实时分发至用户。

根据本公开的一方面，提出一种消息推送方法，可用于视频直播间中，该直播间包括消息产生端与多个消息接收端，该方法包括：将多个消息接收端进行分组处理，得到多个接收组；为多个接收组中的每一个接收组分别确定与其对应的推送服务器；以及将目标消息通过与每一个接收组对应的推送服务器推送至所述接收组内的消息接收端。

在本公开的一种示例性实施例中，将多个消息接收端进行分组处理，得到多个接收组包括：按照所述多个消息接收端的用户信息进行分组处理，以生成所述多个接收组。

在本公开的一种示例性实施例中，按照所述多个消息接收端的用户信息进行分组处理，以生成所述多个接收组包括：确定接收组数量；计算用户信息中用户名的哈希值；以及通过接收组的数量以及所述哈希值将多个消息接收端进行分组处理生成多个接收组。

在本公开的一种示例性实施例中，将多个消息接收端进行分组处理，以生成多个接收组还包括：通过心跳服务获取用户信息。

在本公开的一种示例性实施例中，将目标消息通过与每一个接收组对应的推送服务器推送至所述接收组内的消息接收端包括：所述推送服务器利用多进程方式分别将所述目标消息推送至所述消息接收端。

在本公开的一种示例性实施例中，还包括：消息接收端判断目标消息是否缺失；以及在目标消息缺失时，消息接收端采用主动拉取的方式获取缺失的目标消息。

在本公开的一种示例性实施例中，消息接收端判断目标消息是否缺失包括：消息接收端根据目标消息的序列号判断目标消息是否缺失。

在本公开的一种示例性实施例中，消息接收端采用主动拉取的方式获取缺失的目标消息包括：基于时间戳与目标消息的序列号消息接收端采用主动拉取的方式获取缺失的目标消息。

在本公开的一种示例性实施例中，所述推送服务器为分布式应用程序协调服务集群中的节点；所述推送服务器的数量根据所述接收组的数量进行自动增减。

在本公开的一种示例性实施例中，所述推送服务器的数量根据所述接收组的数量进行自动增减包括：在推送服务器的数量增加时，根据一致性哈希技术将多个消息接收端中的部分分配至增加的推送服务器中；以及在推送服务器的数量减少时，根据一致性哈希技术将变动的推送服务中的多个消息接收端分配至其他的推送服务器中。

根据本公开的一方面，提出一种消息推送装置，可用于视频直播间中，该直播间包括消息产生端与多个消息接收端，该装置包括：分组模块，用于将多个消息接收端进行分组处理生成多个接收组；定义模块，用于为多个接收组中的每一个接收组分别确定与其对应的推送服务器；以及推动模块，用于将目标消息通过与每一个接收组对应的推送服务器推送至所述接收组内的消息接收端。

根据本公开的一方面，提出一种消息推送系统，可用于视频直播间中，该直播间包括消息产生端与多个消息接收端，该系统包括：消息推送服务器集群，包括多个推送服务器，用于将多个消息接收端进行分组处理生成多个接收组；为多个接收组中的每一个接收组分别确定与其对应的推送服务器；以及将目标消息通过与每一个接收组对应的推送服务器推送至所述接收组内的消息接收端；以及多个消息接收端，用于接收来自于推送服务器的所述目标消息，并将其展示。

根据本公开的一方面，提出一种电子设备，该电子设备包括：一个或多个处理器；存储装置，用于存储一个或多个程序；当一个或多个程序被一个或多个处理器执行，使得一个或多个处理器实现如上文的方法。

根据本公开的一方面，提出一种计算机可读介质，其上存储有计算机程序，该程序被处理器执行时实现如上文中的方法。

根据本公开的消息推送方法、装置、系统、电子设备及计算机可读介质，能够将海量消息实时分发至用户。

应当理解的是，以上的一般描述和后文的细节描述仅是示例性的，并不能限制本公开。

附图说明

通过参照附图详细描述其示例实施例，本公开的上述和其它目标、特征及优点将变得更加显而易见。下面描述的附图仅仅是本公开的一些实施例，对于本领域的普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1是现有技术中消息推送方法的示意图。

图2是现有技术中消息推送方法的示意图。

图3是根据一示例性实施例示出的一种消息推送方法的系统框图。

图4是根据一示例性实施例示出的一种消息推送方法的系统框图。

图5是根据一示例性实施例示出的一种消息推送方法的流程图。

图6是根据另一示例性实施例示出的一种消息推送方法的流程图。

图7是根据另一示例性实施例示出的一种消息推送方法的示意图。

图8是根据另一示例性实施例示出的一种消息推送方法的示意图。

图9是根据一示例性实施例示出的一种消息推送装置的框图。

图10是根据另一示例性实施例示出的一种消息推送系统的框图。

图11是根据一示例性实施例示出的一种电子设备的框图。

图12是根据一示例性实施例示出一种计算机可读存储介质示意图。

具体实施方式

现在将参考附图更全面地描述示例实施例。然而，示例实施例能够以多种形式实施，且不应被理解为限于在此阐述的实施例；相反，提供这些实施例使得本公开将全面和完整，并将示例实施例的构思全面地传达给本领域的技术人员。在图中相同的附图标记表示相同或类似的部分，因而将省略对它们的重复描述。

此外，所描述的特征、结构或特性可以以任何合适的方式结合在一个或更多实施例中。在下面的描述中，提供许多具体细节从而给出对本公开的实施例的充分理解。然而，本领域技术人员将意识到，可以实践本公开的技术方案而没有特定细节中的一个或更多，或者可以采用其它的方法、组元、装置、步骤等。在其它情况下，不详细示出或描述公知方法、装置、实现或者操作以避免模糊本公开的各方面。

附图中所示的方框图仅仅是功能实体，不一定必须与物理上独立的实体相对应。即，可以采用软件形式来实现这些功能实体，或在一个或多个硬件模块或集成电路中实现这些功能实体，或在不同网络和/或处理器装置和/或微控制器装置中实现这些功能实体。

附图中所示的流程图仅是示例性说明，不是必须包括所有的内容和操作/步骤，也不是必须按所描述的顺序执行。例如，有的操作/步骤还可以分解，而有的操作/步骤可以合并或部分合并，因此实际执行的顺序有可能根据实际情况改变。

应理解，虽然本文中可能使用术语第一、第二、第三等来描述各种组件，但这些组件不应受这些术语限制。这些术语乃用以区分一组件与另一组件。因此，下文论述的第一组件可称为第二组件而不偏离本公开概念的教示。如本文中所使用，术语“及/或”包括相关联的列出项目中的任一个及一或多者的所有组合。

本领域技术人员可以理解，附图只是示例实施例的示意图，附图中的模块或流程并不一定是实施本公开所必须的，因此不能用于限制本公开的保护范围。

本申请的发明人发现，目前的互动类的消息推送的方案中，一种是采用前端定期拉的模式，该方案消息触达用户依赖前端的轮训时间间隔，前端设置的时间过短会导致手机耗电量高，设置轮训时间长会使得消息触达到用户时延高，时延高容易导致互动不连续，互动易被打断；具体如图1所示，前端定期拉模式的情况下，用户产生的消息首先到达后台，后台对消息进行存储，用户定期向后台请求，后台将数据返回给用户。该方案适合对消息延迟敏感度不高的业务场景，比如点播的弹幕。但对于实时性要求比较高的系统，比如需要在短时间内将消息推送给全网用户，无法满足业务对低延迟的需求。

本申请的发明人发现，目前的互动类的消息推送的方案中，另一种是方案按照直播间维度进行推送，当单直播间人数占比较高时，推送效率会相对较低。如图2所示，在服务端推模式情况下，可例如按照直播间维度进行消息推送。用户产生的消息到达后台后，后台根据用户所处的直播间查找该直播间中所有用户，然后将消息统一推送给直播间中所有用户。该方案适合直播间人数不多，对直播间人数上限有限制的场景。对于直播场景中直播间人数不限的场景，当直播间人数高时，推送效率低，部分用户收到消息延迟高。

客户端拉模式。主要存在的问题是时延高，无法满足业务需要低延迟的场景。在服务端推模式情况下，由于是按照直播间维度进行消息推送。适合直播间人数不多或者对人数有上限有限制的场景。对于直播场景来说，直播间人数是不设置上限的，当直播间人数多时，改方案会导致部分用户收到消息延迟高，每个用户收到的消息时间不一致，影响互动。

本申请的消息推送方法，提出一种通用的解决方案，满足稳定、可靠、低延迟的分发方案，为互动类消息系统设计一种基于用户分组策略的海量消息实时分发系统设计方案。

图3是根据一示例性实施例示出的一种消息推送方法的系统框图。图3示例性的说明了本申请的消息推送方法的系统框架。

如图3所示，系统架构100可以包括终端设备101网络104和服务器105。网络104用以在终端设备101和服务器105之间提供通信链路的介质。网络104可以包括各种连接类型，例如有线、无线通信链路或者光纤电缆等等。

用户可以使用终端设备101通过网络104与服务器105交互，以接收或发送消息等。终端设备101上可以安装有各种通讯客户端应用，例如网页浏览器应用、即时通信工具、社交平台软件等。

终端设备101可以是具有显示屏并且支持网页浏览的各种电子设备，包括但不限于智能手机、平板电脑、膝上型便携计算机和台式计算机等等。

服务器105可以是提供各种服务的服务器，例如对用户利用终端设备101所浏览的视频直播网站提供支持的服务器。服务器105可以对用户利用终端设备101产生的消息进行处理，服务器105可例如接收用户利用终端设备101产生的目标消息，服务器105可例如对接收到的推送信息等数据进行处理，服务器105还可例如将推送信息转发给其他的终端设备101。

服务器105可以是一个实体的服务器，还可例如为多个服务器组成的集群，服务器105中的一部分可例如作为本申请中的目标消息接收服务器，用于接收用户利用终端设备101产生的目标消息；服务器105中的一部分还可例如作为本申请中的推送服务器，用于将目标消息通过与接收组对应的推送服务器推送至所述接收组内的消息接收端。服务器105可例如通过zookeeper架构实现，服务器105的数量可例如根据所述接收组的数量进行自动增减。

如图4所示，在直播间场景中，直播间的主播(利用终端设备101，图中未示出终端设备101)产生目标消息，其他的在直播间中观看直播的用户(利用其他终端设备101，图中未示出其他终端设备101)等待接收来主播的目标消息。服务器105构成的服务器集群系统可用于在主播与用户之间进行目标消息的推送，在服务器105为服务器集群时，服务器105中的部分服务器可作为分配服务器1051，分配服务器1051用于为消息接收端分配推送服务器，服务器105中的另一部分服务器可作为推送服务器1052，推送服务器1052用于为消息接收端推送消息。

服务器105集群中分配服务器1051通过消息接收/推送接口层接收主播产生的目标消息，然后分配服务器1051可例如根据本申请的消息推送方法，将多个消息接收端进行分组处理生成多个接收组，多个接收组可为第一接收组至第N分组；分配服务器1051可例如为多个接收组中的每一个接收组分别确定与其对应的推送服务器1052，推送服务器1052可为第一推送服务器1052至第N推送服务器1052；分配服务器1051可例如将目标消息通过与接收组对应的推送服务器1052推送至所述接收组内对应的的消息接收端。

具体可例如，分配服务器1051为第一接收组指定推送服务器为第一推送服务器1052，以此类推，分配服务器1051为第N接收组指定推送服务器为第N推送服务器1052。分配服务器1051通过第一推送服务器1052将目标消息推送至第一接收组中用户对应的接收端中，分配服务器1051通过第N推送服务器1052将目标消息推送至第N接收组中用户对应的接收端中。

服务器105集群中还可例如包括心跳服务器1053，心跳服务器1053用于收集并维护当前在线的消息接收端的信息，并将其储存在分组信息和配置信息中。

其中，本公开实施例所提供的消息推送方法中，终端设备101可用于对拉取缺失的目标消息，终端设备101还可例如判断目标消息是否缺失；以及在目标消息缺失时，终端设备101可例如采用主动拉取的方式获取缺失的目标消息。

需要说明的是，本公开实施例所提供的消息推送方法可以由服务器105和终端设备101执行，相应地，消息推送装置可以设置于服务器105和终端设备101中。而提供给用户目标消息查看应用软件一般位于终端设备101中。

本申请的消息推送方法，在实时性上，通过采用用户多维度分桶策略实现消息秒级触达用户；可靠性上，采用推拉相结合的模式实现消息的100％可靠触达；容灾及服务发现上，基于zookeeper实现服务的自动伸缩容；通用性上，为消息类的实时分发提供了一套通用解决方案。

下面将以视频直播间为例，对本申请的消息推送方法的详细描述，值得一提的是，本申请的消息推送方法不仅限于直播间的应用环境，还可用于聊天室，或者微博、论坛、视频发布网站等其他涉及到消息推送与接收的场景。

图5是根据一示例性实施例示出的一种消息推送方法的流程图。消息推送方法50的执行主体可为图3所示的服务器105，该方法可用于视频直播间中，该直播间包括消息产生端(可例如为图3中的终端设备101)与多个消息接收端(可例如为图3中的其他终端设备101)，消息推送方法50至少包括如下步骤：

在S502中，将多个消息接收端进行分组处理，得到多个接收组。消息接收端可例如为直播间中正在观看视频直播的用户处的终端设备，还可例如为视频平台中所有的用户处的终端设备。

在一个实施例中，将多个消息接收端进行分组处理，以生成多个接收组包括：按照所述多个消息接收端的用户信息进行分组处理，以生成所述多个接收组。具体可例如：确定接收组数量；计算用户信息中用户名的哈希值；以及通过接收组的数量以及所述哈希值将多个消息接收端进行分组处理生成多个接收组。

在一个实施例中，可例如根据推送服务器的性能以及目标消息的历史经验值，确定接收组内的用户数量最优为100个，那么可根据当前在线的用户数量确定直播间的接收组的数量。

在一个实施例中，可例如根据在当前直播间的用户数量确定接收组数量为100个，计算当前在线的用户的用户名的哈希值。可例如通过哈希方法确定用户名的哈希值，其中，哈希方法(Hash)又称散列方法，是一种从任何一种数据中创建小的数字“指纹”的方法。哈希方法把消息或数据压缩成摘要，使得数据量变小，将数据的格式固定下来。该函数将数据打乱混合，重新创建一个叫做哈希值(hash values，hash codes，hash sums，或hashes)的指纹。哈希值通常用一个短的随机字母和数字组成的字符串来代表。好的散列函数在输入域中很少出现散列冲突。HASH是根据用户名的数据通过逻辑运算得到的数值,不同的用户名得到的HASH值是不同的,所以HASH值就成了每一个文件在目标消息服务器中的唯一认证。在计算完用户名的哈希值之后，可例如通过用户名的哈希值与接收组数量相除进行取模的方式，按照余数将用户分入不同的接收组。

在一个实施例中，还可例如通过用户IP地址将用户进行打散尽量平均分配到不同的接收组中；还可例如通过用户加入视频直播间的先后顺序将用户进行分组，还可例如通过用户名字母排序的方法将用户分入不同的接收组等等方式，只要是能将用户尽量平均分配到不同的接收组中的方式均可，本申请不以此为限。

在一个实施例中，将多个消息接收端进行分组处理，以生成多个接收组还包括：通过心跳服务获取用户信息。通过心跳服务(live_poll)收集并维护当前在线用户信息。其中，心跳服务可例如通过心跳服务器实现，心跳服务器用于处理来自多个客户端的连接数据，心跳服务器可例如将所有数据汇总后通过一个数据通信连接将数据发送到后方的其他服务器中。心跳服务器作用是按心跳(按照设定的频率可例如10Hz)从连接服务器上拿到数据，再转发给后台服务器。

如图5所示，在S504中，为多个接收组中的每一个接收组分别确定与其对应的推送服务器。可例如，根据推送服务器的自身容量与处理特点，为接收组指定推送服务器。可例如每个接收组单独指派一个推送服务器，还可例如多个接收组指派同一个推送服务器，本申请不以此为限。在服务器指派时，可例如通过接收组内用户的数量与消息特征对现有的推送服务器进行排序，按序指派推送服务器。还可例如，对用户的信息进行排序，可例如，为不同地区的用户指派不同的服务器，本申请不以此为限。

如图5所示，在S506中，将目标消息通过与每一个接收组对应的推送服务器推送至所述接收组内的消息接收端。可例如，所述推送服务器利用多进程方式分别将所述目标消息推送至所述消息接收端。每台服务器负责指定分组的用户的消息推送；通过服务多进程的方式对分组数据进行二次分配增加推送效率。

其中，进程，子进程是父进程的复制品。子进程获得父进程数据空间、堆和栈的复制品。多进程是指，每个进程有独立的地址空间，进程之间不共享内存和变量，但可以通过共享内存实现，每个进程只有一个线程。

根据本公开的消息推送方法，通过将多个消息接收端进行分组处理；为每一个接收组确定与其对应的推送服务器；以及将目标消息通过与接收组对应的推送服务器推送至用户的方式，能够将海量消息秒级触达用户。

应清楚地理解，本公开描述了如何形成和使用特定示例，但本公开的原理不限于这些示例的任何细节。相反，基于本公开公开的内容的教导，这些原理能够应用于许多其它实施例。

图6是根据另一示例性实施例示出的一种消息推送方法的流程图。消息推送方法60示例性的描述了本申请的消息推送方法中消息接收端的工作流程。图7是根据另一示例性实施例示出的一种消息推送方法的示意图。下面借助于图6与图7对消息推送方法中消息接收端的工作流程进行详细描述。

如图6所示，在S602中，消息接收端接收消息。

在S604中，消息接收端根据目标消息的序列号判断目标消息是否缺失。其中，序列号(Sequence)是消息的传输通道为每一条消息的传送分配的一个序列号，它会自动累计增值。消息序列号由发送通道分配，是通道的一个永久属性，每当发送一条消息，消息序列号就加一。通道的相关属性SEQWRAP表示序号的最大值，缺省为999,999,999。序列号越界后自动归零，从头开始。消息序列号是保证消息传输不丢失、不复传的一个重要机制，通道利用消息序号来标识传送和确认的消息。

正常情况下，通道两端的消息序列号或者相等或者相差为1，而且在正常情况下，消息接收端接收到的消息序列号是连续的号码，当消息接收端接收的消息序列号不连续时，即可判断目标消息缺失。

在S606中，在目标消息缺失时，消息接收端采用主动拉取的方式获取缺失的目标消息。

在一个实施例中，消息接收端采用主动拉取的方式获取缺失的目标消息包括：基于时间戳与目标消息的序列号消息接收端采用主动拉取的方式获取缺失的目标消息。

其中，时间戳(timestamp)，一个能表示一份数据在某个特定时间之前已经存在的、完整的、可验证的数据,通常是一个字符序列，唯一地标识某一刻的时间。它的提出主要是为用户提供一份电子证据，以证明用户的某些数据的产生时间。一般来说，时间戳产生的过程为：用户首先将需要加时间戳的文件用Hash编码加密形成摘要，然后将该摘要发送到接收方，接收方在加入了收到文件摘要的日期和时间信息后再对该文件加密(数字签名)，然后送回用户。

如图7所示，在正常的处理流程中，消息接收端主要通过推送服务获取目标消息，但是在当消息接收端接收的消息序列号不连续时，或者其他异常情况发生时，消息接收端可以通过消息拉回服务的方式获取目标消息。具体可例如根据时间戳与消息的序列号，定位缺失的消息，以便消息接收端将缺失的消息找回。其中时间戳可例如储存在高速缓冲存储器(cache)中，cache是一种特殊的存储器子系统，其中复制了频繁使用的数据以利于快速访问。存储器的高速缓冲存储器存储了频繁访问的RAM位置的内容及这些数据项的存储地址。当处理器引用存储器中的某地址时，高速缓冲存储器便检查是否存有该地址。如果存有该地址，则将数据返回处理器；如果没有保存该地址，则进行常规的存储器访问。因为高速缓冲存储器总是比主RAM存储器速度快，所以当RAM的访问速度低于微处理器的速度时，常使用高速缓冲存储器。

根据本公开的消息推送方法，通过推拉相结合的方式保证消息的100％可靠触达。比如私信类的消息需要高可靠，不能容忍数据的丢失。根据本公开的消息推送方法，通过推模式保证数据高效到达，对于部分消息由于网络等原因少量数据丢失的问题，基于时间戳(timestamp)+序列号(seq)采用前端主动感知然后主动拉取的方式将丢失数据进行重新拉取，保证可消息的可靠性。

在一个实施例中，所述推送服务器为分布式应用程序协调服务(zookeeper)集群中的节点；在所述推送服务器的数量变更时，再次确定接收组对应的推送服务器。具体包括：在推送服务器的数量增加时，根据一致性哈希技术将多个接收组中的部分接收组指定至增加的推送服务器中；以及在推送服务器的数量减少时，根据一致性哈希技术将变动的推送服务对应的接收组指定至其他的推送服务器中。

图8是根据另一示例性实施例示出的一种消息推送方法的示意图。图8示例性的说明了基于zookeeper服务可通过自动伸缩来实现服务的平行扩缩容的过程。

在直播间用户增加，需要增加或者减少推送服务器的时候，通过一致性哈希方法实现节点的自动剔除和添加。

其中，一致性哈希算法设计目标是为了解决因特网中的热点问题，一致性hash算法在分布式系统中也得到了广泛应用，考虑到分布式系统每个节点都有可能失效，并且新的节点很可能动态的增加进来，一致性hash算法能够保证当系统的节点数目发生变化时仍然能够对外提供良好的服务。由于系统节点数目变少，客户端在请求某一对象时需要重新计算其hash值(通常与系统中的节点数目有关)，因此在重新进行服务器节点分配时一致性hash就显得至关重要，具体在计算一致性hash时采用如下步骤：

首先求出服务器(节点)的哈希值，并将其配置到0～2³²的圆(continuum)上。然后采用同样的方法求出存储数据的键的哈希值，并映射到相同的圆上。然后从数据映射到的位置开始顺时针查找，将数据保存到找到的第一个服务器上。如果超过2³²仍然找不到服务器，就会保存到第一台服务器上。

根据以上的介绍，在直播间用户增加时，可例如先将现有的服务器中的接收组进行一致性hash计算，将分组信息映射到hash空间：

Key_A＝Hash(IP_A)；

Key_B＝Hash(IP_B)；

Key_C＝Hash(IP_N)；

再将具体的增加或者减小的推送服务器节点中的用户映射到hash空间：(vuid代表用户id)

Key_1＝Hash(VUID_1)；

Key_2＝Hash(VUID_2)；

Key_N＝Hash(VUID_N)。假设Key_A<Key_B<Key_C，服务器IP_B负责推送hash(VUID_X)分桶[Key_A,Key_B)之间的用户。通过zookeeper服务获取当前可用节点从而将其他节点中的分组用户尽量平均的分到其他的推送服务器中，以实现节点的自动剔除和添加。当某个服务器节点上下线时，可通过自动计算hash值将分组用户推送任务进行自动切换。

根据本公开的消息推送方法，能够基于zookeeper服务可通过自动伸缩来实现服务的平行扩缩容。基于zookeeper结合一致性hash实现节点的自动剔除和添加，提升服务的可用性和稳定性。

综上，根据本公开的消息推送方法能够带来的技术效果如下：

1)实时性上：通过用户分桶采用服务器端推模式，可实现消息秒级触达用户；

2)可靠性上：通过推拉相结合可实现100％可靠触达；

3)容灾上：基于zookeeper实现服务的自动扩缩容；

4)通用性上：为消息类的实时分发提供了一套通用解决方案。

本领域技术人员可以理解实现上述实施例的全部或部分步骤被实现为由CPU执行的计算机程序。在该计算机程序被CPU执行时，执行本公开提供的上述方法所限定的上述功能。所述的程序可以存储于一种计算机可读存储介质中，该存储介质可以是只读存储器，磁盘或光盘等。

此外，需要注意的是，上述附图仅是根据本公开示例性实施例的方法所包括的处理的示意性说明，而不是限制目的。易于理解，上述附图所示的处理并不表明或限制这些处理的时间顺序。另外，也易于理解，这些处理可以是例如在多个模块中同步或异步执行的。

下述为本公开装置实施例，可以用于执行本公开方法实施例。对于本公开装置实施例中未披露的细节，请参照本公开方法实施例。

图9是根据一示例性实施例示出的一种消息推送装置的框图。消息推送装置90可用于视频直播间中，该直播间包括消息产生端与多个消息接收端，包括：分组模块902，定义模块904，以及推送模块906。

分组模块902用于将多个消息接收端进行分组处理生成多个接收组；消息接收端可例如为直播间中正在观看视频直播的用户，还可例如为视频平台中所有的用户。分组模块902用于按照所述多个消息接收端的用户信息进行分组处理，以生成所述多个接收组。具体可例如：确定接收组数量；计算用户信息中用户名的哈希值；以及通过接收组的数量以及所述哈希值将多个消息接收端进行分组处理生成多个接收组。

定义模块904用于为多个接收组中的每一个接收组分别确定与其对应的推送服务器；可例如，根据推送服务器的自身容量与处理特点，为接收组指定推送服务器。可例如每个接收组单独指派一个推送服务器，还可例如多个接收组指派同一个推送服务器，本申请不以此为限。在服务器指派时，可例如通过接收组内用户的数量与消息特征对现有的推送服务器进行排序，按序指派推送服务器。还可例如，对用户的信息进行排序，可例如，为不同地区的用户指派不同的服务器，本申请不以此为限。

推送模块906用于将目标消息通过与每一个接收组对应的推送服务器推送至所述接收组内的消息接收端。可例如，所述推送服务器利用多进程方式分别将所述目标消息推送至所述消息接收端。每台服务器负责指定分组的用户的消息推送；通过服务多进程的方式对分组数据进行二次分配增加推送效率。

根据本公开的消息推送装置，通过将多个消息接收端进行分组处理；为每一个接收组确定与其对应的推送服务器；以及将目标消息通过与接收组对应的推送服务器推送至用户的方式，能够将海量消息秒级触达用户。

图10是根据另一示例性实施例示出的一种消息推送系统的框图。消息推送系统1000可用于视频直播间中，该直播间包括消息产生端与多个消息接收端，包括：消息推送服务器集群1002，消息接收端1004。

消息推送服务器集群1002，包括多个推送服务器用于将多个消息接收端进行分组处理生成多个接收组；为多个接收组中的每一个接收组分别确定与其对应的推送服务器；以及将目标消息通过与每一个接收组对应的推送服务器推送至所述接收组内的消息接收端。

具体可例如：确定接收组数量；计算用户信息中用户名的哈希值；以及通过接收组的数量以及所述哈希值将多个消息接收端进行分组处理生成多个接收组。

其中，所述推送服务器1002为分布式应用程序协调服务(zookeeper)集群中的节点；所述推送服务器1002的数量根据所述接收组的数量进行自动增减。包括：在推送服务器1002的数量增加时，根据一致性哈希技术将多个消息接收端1004中的部分分配至增加的推送服务器中；以及在推送服务器1002的数量减少时，根据一致性哈希技术将变动的推送服务中的多个消息接收端1004分配至其他的推送服务器中。

多个消息接收端1004用于接收来自于推送服务器的所述目标消息，并将其展示。其中，消息接收端1004还可例如判断目标消息是否缺失；以及在目标消息缺失时，消息接收端1004采用主动拉取的方式获取缺失的目标消息。具体可例如：基于时间戳与目标消息的序列号消息接收端采用主动拉取的方式获取缺失的目标消息。

根据本公开的消息推送系统，在推送服务器端，通过将多个消息接收端进行分组处理；为每一个接收组确定与其对应的推送服务器；以及将目标消息通过与接收组对应的推送服务器推送至用户的方式，能够将海量消息秒级触达用户。

根据本公开的消息推送系统，在消息接收端，通过推拉相结合的方式保证消息的100％可靠触达。基于时间戳(timestamp)+序列号(seq)采用前端主动感知然后主动拉取的方式将丢失数据进行重新拉取，保证可消息的可靠性。

本申请的消息推送系统，在实时性上，通过采用用户多维度分桶策略实现消息秒级触达用户；可靠性上，采用推拉相结合的模式实现消息的100％可靠触达；容灾及服务发现上，基于zookeeper实现服务的自动伸缩容；通用性上，为消息类的实时分发提供了一套通用解决方案。

图11是根据一示例性实施例示出的一种电子设备的框图。

下面参照图11来描述根据本公开的这种实施方式的电子设备1100。图11显示的电子设备1100仅仅是一个示例，不应对本公开实施例的功能和使用范围带来任何限制。

如图11所示，电子设备1100以通用计算设备的形式表现。电子设备1100的组件可以包括但不限于：至少一个处理单元1110、至少一个存储单元1120、连接不同系统组件(包括存储单元1120和处理单元1110)的总线1130、显示单元1140等。

其中，所述存储单元存储有程序代码，所述程序代码可以被所述处理单元1110执行，使得所述处理单元210执行本说明书上述电子处方流转处理方法部分中描述的根据本公开各种示例性实施方式的步骤。例如，所述处理单元1110可以执行如图5，图6中所示的步骤。

所述存储单元1120可以包括易失性存储单元形式的可读介质，例如随机存取存储单元(RAM)11201和/或高速缓存存储单元11202，还可以进一步包括只读存储单元(ROM)11203。

所述存储单元1120还可以包括具有一组(至少一个)程序模块11205的程序/实用工具11204，这样的程序模块11205包括但不限于：操作系统、一个或者多个应用程序、其它程序模块以及程序数据，这些示例中的每一个或某种组合中可能包括网络环境的实现。

总线1130可以为表示几类总线结构中的一种或多种，包括存储单元总线或者存储单元控制器、外围总线、图形加速端口、处理单元或者使用多种总线结构中的任意总线结构的局域总线。

电子设备1100也可以与一个或多个外部设备1200(例如键盘、指向设备、蓝牙设备等)通信，还可与一个或者多个使得用户能与该电子设备1100交互的设备通信，和/或与使得该电子设备1100能与一个或多个其它计算设备进行通信的任何设备(例如路由器、调制解调器等等)通信。这种通信可以通过输入/输出(I/O)接口1150进行。并且，电子设备1100还可以通过网络适配器1160与一个或者多个网络(例如局域网(LAN)，广域网(WAN)和/或公共网络，例如因特网)通信。网络适配器1160可以通过总线1130与电子设备1100的其它模块通信。应当明白，尽管图中未示出，可以结合电子设备1100使用其它硬件和/或软件模块，包括但不限于：微代码、设备驱动器、冗余处理单元、外部磁盘驱动阵列、RAID系统、磁带驱动器以及数据备份存储系统等。

通过以上的实施方式的描述，本领域的技术人员易于理解，这里描述的示例实施方式可以通过软件实现，也可以通过软件结合必要的硬件的方式来实现。因此，根据本公开实施方式的技术方案可以以软件产品的形式体现出来，该软件产品可以存储在一个非易失性存储介质(可以是CD-ROM，U盘，移动硬盘等)中或网络上，包括若干指令以使得一台计算设备(可以是个人计算机、服务器、或者网络设备等)执行根据本公开实施方式的上述方法。

图12示意性示出本公开示例性实施例中一种计算机可读存储介质示意图。

参考图12所示，描述了根据本公开的实施方式的用于实现上述方法的程序产品1200，其可以采用便携式紧凑盘只读存储器(CD-ROM)并包括程序代码，并可以在终端设备，例如个人电脑上运行。然而，本公开的程序产品不限于此，在本文件中，可读存储介质可以是任何包含或存储程序的有形介质，该程序可以被指令执行系统、装置或者器件使用或者与其结合使用。

所述程序产品可以采用一个或多个可读介质的任意组合。可读介质可以是可读信号介质或者可读存储介质。可读存储介质例如可以为但不限于电、磁、光、电磁、红外线、或半导体的系统、装置或器件，或者任意以上的组合。可读存储介质的更具体的例子(非穷举的列表)包括：具有一个或多个导线的电连接、便携式盘、硬盘、随机存取存储器(RAM)、只读存储器(ROM)、可擦式可编程只读存储器(EPROM或闪存)、光纤、便携式紧凑盘只读存储器(CD-ROM)、光存储器件、磁存储器件、或者上述的任意合适的组合。

所述计算机可读存储介质可以包括在基带中或者作为载波一部分传播的数据信号，其中承载了可读程序代码。这种传播的数据信号可以采用多种形式，包括但不限于电磁信号、光信号或上述的任意合适的组合。可读存储介质还可以是可读存储介质以外的任何可读介质，该可读介质可以发送、传播或者传输用于由指令执行系统、装置或者器件使用或者与其结合使用的程序。可读存储介质上包含的程序代码可以用任何适当的介质传输，包括但不限于无线、有线、光缆、RF等等，或者上述的任意合适的组合。

可以以一种或多种程序设计语言的任意组合来编写用于执行本公开操作的程序代码，所述程序设计语言包括面向对象的程序设计语言—诸如Java、C++等，还包括常规的过程式程序设计语言—诸如“C”语言或类似的程序设计语言。程序代码可以完全地在用户计算设备上执行、部分地在用户设备上执行、作为一个独立的软件包执行、部分在用户计算设备上部分在远程计算设备上执行、或者完全在远程计算设备或服务器上执行。在涉及远程计算设备的情形中，远程计算设备可以通过任意种类的网络，包括局域网(LAN)或广域网(WAN)，连接到用户计算设备，或者，可以连接到外部计算设备(例如利用因特网服务提供商来通过因特网连接)。

上述计算机可读介质承载有一个或者多个程序，当上述一个或者多个程序被一个该设备执行时，使得该计算机可读介质实现如下功能：将多个消息接收端进行分组处理，得到多个接收组；为多个接收组中的每一个接收组分别确定与其对应的推送服务器；以及将目标消息通过与每一个接收组对应的推送服务器推送至所述接收组内的消息接收端。

本领域技术人员可以理解上述各模块可以按照实施例的描述分布于装置中，也可以进行相应变化唯一不同于本实施例的一个或多个装置中。上述实施例的模块可以合并为一个模块，也可以进一步拆分成多个子模块。

通过以上的实施例的描述，本领域的技术人员易于理解，这里描述的示例实施例可以通过软件实现，也可以通过软件结合必要的硬件的方式来实现。因此，根据本公开实施例的技术方案可以以软件产品的形式体现出来，该软件产品可以存储在一个非易失性存储介质(可以是CD-ROM，U盘，移动硬盘等)中或网络上，包括若干指令以使得一台计算设备(可以是个人计算机、服务器、移动终端、或者网络设备等)执行根据本公开实施例的方法。

以上具体地示出和描述了本公开的示例性实施例。应可理解的是，本公开不限于这里描述的详细结构、设置方式或实现方法；相反，本公开意图涵盖包含在所附权利要求的精神和范围内的各种修改和等效设置。

此外，本说明书说明书附图所示出的结构、比例、大小等，均仅用以配合说明书所公开的内容，以供本领域技术人员了解与阅读，并非用以限定本公开可实施的限定条件，故不具技术上的实质意义，任何结构的修饰、比例关系的改变或大小的调整，在不影响本公开所能产生的技术效果及所能实现的目的下，均应仍落在本公开所公开的技术内容得能涵盖的范围内。同时，本说明书中所引用的如“上”、“第一”、“第二”及“一”等的用语，也仅为便于叙述的明了，而非用以限定本公开可实施的范围，其相对关系的改变或调整，在无实质变更技术内容下，当也视为本公开可实施的范畴。

Claims (14)

1.一种消息推送方法，可用于视频直播间中，该直播间包括消息产生端与多个消息接收端，其特征在于，包括：

将多个消息接收端进行分组处理，得到多个接收组；

为多个接收组中的每一个接收组分别确定与其对应的推送服务器；以及

将目标消息通过与接收组对应的推送服务器推送至所述接收组内的消息接收端。

2.如权利要求1所述的方法，其特征在于，将多个消息接收端进行分组处理，得到多个接收组包括：

按照所述多个消息接收端的用户信息进行分组处理，以生成所述多个接收组。

3.如权利要求2所述的方法，其特征在于，按照所述多个消息接收端的用户信息进行分组处理，以生成所述多个接收组包括：

确定接收组数量；

计算用户信息中用户名的哈希值；以及

通过接收组的数量以及所述哈希值将多个消息接收端进行分组处理生成多个接收组。

4.如权利要求2所述的方法，其特征在于，将多个消息接收端进行分组处理，以生成多个接收组还包括：

通过心跳服务获取用户信息。

5.如权利要求1所述的方法，其特征在于，将目标消息通过与接收组对应的推送服务器推送至所述接收组内的消息接收端包括：

所述推送服务器利用多进程方式分别将所述目标消息推送至所述消息接收端。

6.如权利要求1所述的方法，其特征在于，还包括：

消息接收端判断目标消息是否缺失；以及

在目标消息缺失时，消息接收端采用主动拉取的方式获取缺失的目标消息。

7.如权利要求6所述的方法，其特征在于，消息接收端判断目标消息是否缺失包括：

消息接收端根据目标消息的序列号判断目标消息是否缺失。

8.如权利要求7所述的方法，其特征在于，消息接收端采用主动拉取的方式获取缺失的目标消息包括：

基于时间戳与目标消息的序列号，消息接收端采用主动拉取的方式获取缺失的目标消息。

9.如权利要求1所述的方法，其特征在于，所述推送服务器为分布式应用程序协调服务集群中的节点；在所述推送服务器的数量变更时，再次确定接收组对应的推送服务器。

10.如权利要求9所述的方法，其特征在于，在所述推送服务器的数量变更时，再次确定接收组对应的推送服务器包括：

在推送服务器的数量增加时，根据一致性哈希技术将多个接收组中的部分接收组指定至增加的推送服务器中；以及

在推送服务器的数量减少时，根据一致性哈希技术将变动的推送服务对应的接收组指定至其他的推送服务器中。

11.一种消息推送装置，可用于视频直播间中，该直播间包括消息产生端与多个消息接收端，其特征在于，包括：

分组模块，用于将多个消息接收端进行分组处理生成多个接收组；

定义模块，用于为多个接收组中的每一个接收组分别确定与其对应的推送服务器；以及

推送模块，用于将目标消息通过与每一个接收组对应的推送服务器推送至所述接收组内的消息接收端。

12.一种消息推送系统，可用于视频直播间中，该直播间包括消息产生端与多个消息接收端，其特征在于，包括：

消息推送服务器集群，包括多个推送服务器，用于将多个消息接收端进行分组处理生成多个接收组；为多个接收组中的每一个接收组分别确定与其对应的推送服务器；以及将目标消息通过与每一个接收组对应的推送服务器推送至所述接收组内的消息接收端；以及

多个消息接收端，用于接收来自于推送服务器的所述目标消息，并将其展示。

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

一个或多个处理器；

存储装置，用于存储一个或多个程序；

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

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