CN113747192A - 一种直播控制方法、装置、电子设备和存储介质 - Google Patents

Abstract

本申请涉及计算机技术领域，尤其涉及一种直播控制方法、装置、电子设备和存储介质，可应用于云技术、人工智能、智慧交通、辅助驾驶等场景，用以提高直播消息的实时性和直播系统的高可用性。其中，方法包括：获取业务发送方需要推送的多个直播业务消息，并确定各直播业务消息的业务类型和消息类型；分别根据确定的业务类型和消息类型，将各直播业务消息保存至对应的消息集群；在接收到目标业务接收方发送的获取请求后，确定目标直播业务消息的目标业务类型和目标消息类型；基于目标业务类型和目标消息类型，从对应的消息集群中获取目标直播业务消息，并分发给目标业务接收方。通过业务隔离，可有效提高直播消息的实时性和直播系统的高可用性。

Description

一种直播控制方法、装置、电子设备和存储介质

技术领域

本申请涉及计算机技术领域，尤其涉及一种直播控制方法、装置、电子设备和存储介质。

背景技术

随着通信技术的飞速发展以及移动终端的功能日益增强，移动终端的应用范围已经从传统的通信领域扩展到人们日常生活的个人领域。目前，移动终端已普遍配置高像素的摄像头，并具备较强的通信能力，被广泛应用在远程视频通信场景中，直播也因此应运而生。

直播是互联网中信息传播的重要途径。随着直播业务的增长迅速，几乎所有的视频、社交、新闻类产品都标配了直播功能，以通过直播能提升业务粘性和业务活跃度。

在直播中，观众端进入主播直播间，主播端与观众端进行互动等是必不可少的环节，当直播在线人数很多，消息量很大时，会产生海量请求。因而，如何在海量请求的情况下保证系统可用，保证消息的实时性时亟待解决的。

发明内容

本申请实施例提供一种直播控制方法、装置、电子设备和存储介质，用以提高直播消息的实时性和直播系统的高可用性。

本申请实施例提供的一种直播控制方法，包括：

获取业务发送方需要推送的多个直播业务消息，并确定各个直播业务消息的业务类型和消息类型；

分别根据所述各个直播业务消息的业务类型和消息类型，将所述各个直播业务消息保存至对应的消息集群；

在接收到目标业务接收方发送的针对目标直播业务消息的获取请求后，确定所述目标直播业务消息的目标业务类型和目标消息类型；

基于所述目标业务类型和目标消息类型，从对应的消息集群中获取所述目标直播业务消息，并将所述目标直播业务消息分发给所述目标业务接收方。

本申请实施例提供的一种直播控制装置，包括：

获取单元，用于获取业务发送方需要推送的多个直播业务消息，并确定各个直播业务消息的业务类型和消息类型；

存储单元，用于分别根据所述各个直播业务消息的业务类型和消息类型，将所述各个直播业务消息保存至对应的消息集群；

确定单元，用于在接收到目标业务接收方发送的针对目标直播业务消息的获取请求后，确定所述目标直播业务消息的目标业务类型和目标消息类型；

第一分发单元，用于基于所述目标业务类型和目标消息类型，从对应的消息集群中获取所述目标直播业务消息，并将所述目标直播业务消息分发给所述目标业务接收方。

可选的，所述存储单元具体用于：

对于每个直播业务消息分别执行以下操作：

确定存在与一个直播业务消息的业务类型以及消息类型相匹配的消息集群时，将所述一个直播业务消息保存至确定的消息集群；

确定不存在与一个直播业务消息的业务类型以及消息类型相匹配的消息集群时，将所述一个直播业务消息保存至与所述一个直播业务消息的业务类型相匹配的消息集群。

可选的，不同级别的直播业务消息对应的消息集群的性能参数不同，消息集群的性能参数与直播业务消息的级别呈正相关，其中，每个直播业务消息的级别是根据所述直播业务消息的业务类型与消息类型中的至少一种确定的，每个消息集群的性能参数用于表示消息集群的数据写入能力。

可选的，所述装置还包括：

第一比对单元，用于分别确定各个直播业务消息各自对应的当前时间戳与发送时间戳之间的时间差，其中，每个直播业务消息的发送时间戳用于标识业务发送方推送所述直播业务消息的时间；

若对应的时间差大于第一预设时长的直播业务消息的数量高于预设阈值，则进行告警。

可选的，所述存储单元还用于：

在所述分别根据所述各个直播业务消息的业务类型和消息类型，将直播业务消息保存至对应的消息集群之前，分别获取所述各个直播业务消息对应的消息标识；

对于每个直播业务消息分别执行以下操作：

基于一个直播业务消息的消息标识，确定所述一个直播业务消息是否被分发；

在基于所述消息标识确定所述一个直播业务消息未被分发时，确认所述一个直播业务消息能够写入对应的消息集群。

可选的，所述装置还包括：

第二比对单元，用于在所述第一分发单元将所述目标直播业务消息分发给所述目标业务接收方之后，将各个业务接收方需要从对应的消息集群中获取的目标直播业务消息，与所述各个业务接收方接收到的目标直播业务消息进行比对；

确定需要获取的目标直播业务消息，与接收到的目标直播业务消息不一致时，对当前时间之前的第二预设时长内的直播业务消息重新进行比对。

可选的，所述装置还包括：

第二分发单元，用于按照业务类型和消息类型，分别将各个直播业务消息分发至对应的业务接收方；或者

按照直播对象的身份信息，分别将各个直播业务消息分发至对应的业务接收方。

可选的，所述第二分发单元具体用于：

对于每个直播业务消息分别执行以下操作：

确定一个直播业务消息对应的两级索引，所述两级索引包括用于表示路由信息的一级索引信息，以及用于表示分发信息的二级索引信息；

按照所述一级索引信息，从对应的消息集群中获取所述一个直播业务消息；

按照所述二级索引信息，将所述一个直播业务消息分发给对应的业务接收方。

可选的，所述存储单元具体用于：

根据所述各个直播业务消息的业务类型和消息类型，确定所述直播业务消息包括直播开播消息与直播停播消息时，将同一业务发送方对应的直播开播消息和直播停播消息保存至同一消息集群。

可选的，所述装置还包括：

变更单元，用于在一个直播业务消息发生变更时，获取所述一个直播业务消息对应的变更信息；

按照预设协议，将所述变更信息封装为序列化字段；

根据所述序列化字段，对对应的消息集群中的所述一个直播业务消息进行变更。

可选的，所述第一分发单元还用于：

在所述将所述目标直播业务消息分发给所述目标业务接收方之前，在接收到所述目标业务接收方发送的针对目标直播业务消息的获取请求后，确定所述目标业务接收方是否具有针对所述目标直播业务消息的获取权限；

所述第一分发单元具体用于：

在确定所述目标业务接收方具有获取权限时，将所述目标直播业务消息分发给所述目标业务接收方。

可选的，所述存储单元还用于：

在分别将所述各个直播业务消息保存至对应的消息集群之前，分别对所述各个直播业务消息中指定的直播业务消息进行加密，获取指定的直播业务消息各自对应的秘钥；

所述第一分发单元具体用于：

若所述目标业务消息属于指定的直播业务消息，则将所述目标直播业务消息，以及所述目标直播业务消息对应的秘钥分发给所述目标业务接收方，以使所述目标业务接收方根据接收到的秘钥对所述目标直播业务消息进行解密。

可选的，所述装置还包括：

第三比对单元，用于每隔第三预设时长，将各个业务发送方在所述第三预设时长内推送的直播业务消息，与各个业务接收方在所述第三预设时长内接收的直播业务消息进行比对；

确定业务发送方推送的直播业务消息的数量，与业务接收方接收的直播业务消息的数量不一致时，则进行告警。

本申请实施例提供的一种电子设备，包括处理器和存储器，其中，所述存储器存储有程序代码，当所述程序代码被所述处理器执行时，使得所述处理器执行上述一种直播控制方法的步骤。

本申请实施例提供一种计算机程序产品或计算机程序，该计算机程序产品或计算机程序包括计算机指令，该计算机指令存储在计算机可读存储介质中。计算机设备的处理器从计算机可读存储介质读取该计算机指令，处理器执行该计算机指令，使得该计算机设备执行上述任意一种直播控制方法的步骤。

本申请实施例提供一种计算机可读存储介质，其包括程序代码，当所述程序产品在电子设备上运行时，所述程序代码用于使所述电子设备执行上述一种直播控制方法的步骤。

本申请有益效果如下：

本申请实施例提供了一种直播控制方法、装置、电子设备和存储介质。由于本申请通过业务隔离，将直播业务消息按照业务类型和消息类型进行保存，具有不同业务类型或消息类型的直播业务消息，可以保存至不同的消息集群。当接收到目标业务接收方发送的针对目标直播业务消息的获取请求时，可基于该目标直播业务消息的目标业务类型和目标消息类型，从对应的目标消息集群中拉取消息，推送给该目标业务接收方。这样，在直播间中有百万人同时在线，产生百万请求的情况下，可通过上述业务隔离的方式，减小直播系统的压力，及时进行消息的推送，有效提高直播消息的实时性和直播系统的高可用性。

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

附图说明

此处所说明的附图用来提供对本申请的进一步理解，构成本申请的一部分，本申请的示意性实施例及其说明用于解释本申请，并不构成对本申请的不当限定。在附图中：

图1为本申请实施例中的一种应用场景的一个可选的示意图；

图2为本申请实施例中的一种直播控制方法的流程示意图；

图3A为本申请实施例中的一种直播界面的示意图；

图3B为本申请实施例中的又一种直播界面的示意图；

图4为本申请实施例中的一种业务set化部署方法的示意图；

图5为本申请实施例中的一种直播业务消息的路由过程示意图；

图6为本申请实施例中的一种直播系统的架构图；

图7为本申请实施例中的一种消息分级存储方法的示意图；

图8为本申请实施例中的一种对账重放机制的流程示意图；

图9为本申请实施例中的一种关联关系的示意图；

图10为本申请实施例中的一种直播控制方法的时序图；

图11为本申请实施例中的一种直播控制装置的组成结构示意图；

图12为本申请实施例中的一种电子设备的一个硬件组成结构示意图；

图13为本申请实施例中的又一种电子设备的一个硬件组成结构示意图。

具体实施方式

为使本申请实施例的目的、技术方案和优点更加清楚，下面将结合本申请实施例中的附图，对本申请的技术方案进行清楚、完整地描述，显然，所描述的实施例是本申请技术方案的一部分实施例，而不是全部的实施例。基于本申请文件中记载的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本申请技术方案保护的范围。

本申请的说明书和权利要求书及上述附图中的术语“第一”、“第二”、“第三”等（如果存在）是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本申请的实施例能够以除了在这里图示或描述的那些以外的顺序实施。此外，术语“包括”和“对应的”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。

下面对本申请实施例中涉及的部分概念进行介绍。

业务方：指参与直播业务的各个用户，用户账户等。本申请中的业务方包括推送消息到消息集群的业务发送方，以及从消息集群中获取消息的业务接收方。在本申请实施例中，业务发送方和业务接收方可以相同，也可以不同，本文不做具体限定。

直播业务消息：指在直播场景下的各种直播消息，具体可根据该消息所属的业务，该消息的类型进行消息的划分。在本申请实施例中，一个直播业务消息可以有对应的业务类型，表征该消息所属的业务，比如游戏业务、带货业务、在线教育业务等；进一步地，还可将消息划分为不同的类型，包括但不限于下列：聊天消息、直播开播消息、直播停播消息、送礼消息、进房消息、退房消息、登录消息、注册消息、抽奖消息等。

SDK（Software Development Kit，软件开发工具包）：一般都是一些软件工程师为特定的软件包、软件框架、硬件平台、操作系统等建立应用软件时的开发工具的集合。软件开发工具包括广义上指辅助开发某一类软件的相关文档、范例和工具的集合。

Kafka和Ckafka：Kafka是一种高吞吐量的分布式发布订阅消息系统，它可以处理消费者在网站中的所有动作流数据。Ckafka是基础架构部开发的高性能、高可用消息队列，其主要用于消息传输、网站活动追踪、运营监控、日志聚合、流式处理、事件追踪、提交日志等等需要高性能的场景。Ckafka完全兼容Kafka协议，使Kafka用户可以零成本迁入Ckafka。Ckafka基于Kafka进行了扩展开发和优化。

云技术是指在广域网或局域网内将硬件、软件、网络等系列资源统一起来，实现数据的计算、储存、处理和共享的一种托管技术。

云技术基于云计算商业模式应用的网络技术、信息技术、整合技术、管理平台技术、应用技术等的总称，可以组成资源池，按需所用，灵活便利。云计算技术将变成重要支撑。技术网络系统的后台服务需要大量的计算、存储资源，如视频网站、图片类网站和更多的门户网站。伴随着互联网行业的高度发展和应用，将来每个物品都有可能存在自己的识别标志，都需要传输到后台系统进行逻辑处理，不同程度级别的数据将会分开处理，各类行业数据皆需要强大的系统后盾支撑，只能通过云计算来实现。

本申请主要涉及云技术中的云存储和数据库这两个方向。云存储是在云计算概念上延伸和发展出来的一个新的概念，分布式云存储系统（以下简称存储系统）是指通过集群应用、网格技术以及分布存储文件系统等功能，将网络中大量各种不同类型的存储设备（存储设备也称之为存储节点）通过应用软件或应用接口集合起来协同工作，共同对外提供数据存储和业务访问功能的一个存储系统。

数据库，简而言之可视为电子化的文件柜，存储电子文件的处所，用户可以对文件中的数据进行新增、查询、更新、删除等操作。所谓“数据库”是以一定方式储存在一起、能与多个用户共享、具有尽可能小的冗余度、与应用程序彼此独立的数据集合。DBMS（DatabaseManagement System，数据库管理系统）是为管理数据库而设计的电脑软件系统，一般具有存储、截取、安全保障、备份等基础功能。

本申请实施例中提出的用于存储对象数据的系统即分布式对象云存储系统，其包含多个数据库，用于对对象数据、业务事件等分类存储，实现基础数据、特征数据、采样数据、业务事件等元数据的存储。

下面对本申请实施例的设计思想进行简要介绍：

随着移动终端和网络交互平台的快速发展，越来越多的用户通过登录网络交互平台进行交流。其中，网络直播是非常受广大用户欢迎的应用，很多用户喜欢通过移动终端设备来观看直播。网络直播利用互联网的快速、表现形式好、内容丰富、互动性强以及地域不受限制等特点，深受人们的喜爱。

目前，个人直播间有聊天、进房（指进入直播间）、送礼等各种消息，业务方需要通过这些消息来定制自己的运营策略，如何设计一个扩展性好系统成为了关键。此外，直播间的送礼消息是直播活动的一种重要的依赖，如何保证消息的稳定传输成为了关键。另外，送礼消息的延时会导致加分的丢失，如何保证消息的及时性成为了系统的关键。并且，多个业务如何保证消息安全性也是要考虑的重要方面。一个业务也可能需要另外一个业务的消息，因而还需要考虑消息如何高效的共享。

有鉴于此，本申请实施例提出了一种直播控制方法、装置、电子设备和存储介质。本申请中的直播控制方法是一种高可用、实时性好、扩展性强、安全性好、方便消息共享的事件分发的解决方法。具体地，本申请在海量请求的情况下通过业务的set化（单元化）部署、消息分级机制以及多维度的告警，对账等，保证系统高可用；通过协议的设计、转发方式的抽象和配置的管理等方式保证系统良好的扩展性，可以满足业务快速接入的需求；通过事前、事中、事后三种策略保证了消息的安全性。

以下结合说明书附图对本申请的优选实施例进行说明，应当理解，此处所描述的优选实施例仅用于说明和解释本申请，并不用于限定本申请，并且在不冲突的情况下，本申请中的实施例及实施例中的特征可以相互组合。

如图1所示，其为本申请实施例的应用场景示意图。该应用场景图中包括两个终端设备110和一个服务器120。本申请实施例中的终端设备110上可以安装有直播客户端，直播客户端用于进行直播或者观看直播等。该直播客户端可以是软件（例如浏览器），也可以是网页、小程序等，服务器120则是与软件或是网页、小程序等相对应的后台服务器，或者是专门用于进行直播控制的直播服务器，本申请不做具体限定。

在本申请实施例中，用户可通过终端设备110登录直播客户端，通过直播客户端观看直播，或者是进行直播。直播业务消息（简称消息）则是指直播业务相关的消息，例如登录、注册、开播、停播、聊天、送礼等等。

在一种可选的实施方式中，终端设备110与服务器120之间可以通过通信网络进行通信。

在一种可选的实施方式中，通信网络是有线网络或无线网络。

在本申请实施例中，终端设备110为用户使用的计算机设备，该计算机设备可以是个人计算机、手机、平板电脑、笔记本、电子书阅读器、智能语音交互设备、智能家电、车载终端等具有一定计算能力并且运行有即时通讯类软件及网站或者社交类软件及网站的计算机设备。各终端设备110通过无线网络与服务器120连接，服务器120是一台服务器或若干台服务器组成的服务器集群或云计算中心，或者是一个虚拟化平台。

需要说明的是，图1所示只是举例说明，实际上终端设备和服务器的数量不受限制，在本申请实施例中不做具体限定。

另外，需要说明的是，本申请实施例中的直播控制方法可以由服务器或终端设备单独执行，也可以由服务器和终端设备共同执行。可以应用于各种包含有直播业务消息推送、分发等的应用场景下，包括但不限于云技术、人工智能、智慧交通、辅助驾驶等，在此不做一一列举。

下面结合上述描述的应用场景，参考附图来描述本申请示例性实施方式提供的直播控制方法，需要注意的是，上述应用场景仅是为了便于理解本申请的精神和原理而示出，本申请的实施方式在此方面不受任何限制。

参阅图2所示，为本申请实施例提供的一种直播控制方法的实施流程图，本文是以服务器为执行主体为例进行举例说明的，该方法的具体实施流程如下：

S21：服务器获取业务发送方需要推送的多个直播业务消息，并确定各个直播业务消息的业务类型和消息类型；

S22：服务器分别根据各个直播业务消息的业务类型和消息类型，将各个直播业务消息保存至对应的消息集群；

其中，直播业务消息主要是指在直播场景下的各种直播消息，具体可根据该消息所属的业务，该消息的类型进行消息的划分。

具体地，业务类型具体是根据业务划分的，比如：游戏业务、带货业务、在线教育业务等；消息类型包括但不限于下列的部分或全部：聊天消息、直播开播消息、直播停播消息、送礼消息、进房消息、退房消息、登录消息、注册消息、抽奖消息。

在步骤S21中，业务发送方可以是一个，也可以是多个，可以是主播，也可以是观众等等，比如用户A观看用户B直播时，用户A向用户B送礼，则业务发送方即用户A（或用户A登录的账户），业务接收方为用户B（或用户B登录的账户）等，在此不做具体限定。

下面结合图3A和图3B，对上文所列举的直播业务消息进行简单举例说明。

如图3A，其为本申请实施例中示出的一种直播界面的示意图，其中的S30为进房消息，即观众进入主播的直播间时的提示消息，图3A表示用户“深夜”进入主播“冰冰棒”的直播间时的进房消息，S31部分表示的是直播间的在线人数。再比如图3B所示，其为本申请实施例中示出的又一种直播界面的示意图，展示的是两个主播连线PK时的直播界面，其中，S32部分为一种送礼消息，其中，送礼方为观众“浅笑回忆”，收礼方为主播“棒棒冰”。

在本申请实施例中，为了满足业务的需求，为了满足直播中台的要求，不同的业务接入直播中台需要做到业务的隔离，本申请对业务进行了set化部署。

具体地，本申请通过为不同的业务分配了不同的appid，表示不同的业务类型，并根据appid进行分发，实现了对外界透明的效果；此外，本申请还可以通过不同的消息id（也称msq_type），表示不同的消息类型，基于业务类型，消息类型等，将直播业务消息路由到不同的事件中心set，进行通过事件中心set，将相应的直播业务消息保存至对应的消息集群，因而，事件中心set和消息集群也可以统一理解为用于保存直播业务消息的消息集群，其中事件中心set就是为了将相应类型的直播业务消息推送到相应的消息集群中进行保存。

也就是说，本申请中的事件中心set和消息集群可以是基于业务类型与消息类型综合划分得到的，比如消息集群1用于存储业务类型为A业务，消息类型为type2的直播业务消息，消息集群2用于存储业务类型为A业务，消息类型为type1的直播业务消息等；也可以仅基于业务类型划分得到，比如消息集群3用于存储业务类型为B业务的直播业务消息，消息集群4用于存储业务类型为D业务的直播业务消息等，本文不做具体限定。

如图4所示，其为本申请实施例中的一种业务set化部署方法的示意图。其中，图4中所示的事件中心set1、事件中心set2、事件中心set3、…，分别用于分发不同类型的直播业务消息。比如，事件中心set1用于分发A业务-type1消息类型的直播业务消息，事件中心set2用于分发A业务-type3消息类型的直播业务消息，事件中心set3用于分发B业务类型的直播业务消息等等。假设，消息A1为A业务-type1消息类型，即可分发在事件中心set1中；消息A3为A业务-type3消息类型，即可分发在事件中心set2中；消息B1，消息B2，消息B3为B业务类型，即可分发在事件中心set3中，等等。

在将直播业务消息通过事件中心set分发并保存至消息集群后，即可等待业务接收方拉取，或者是按照下文所列举的两种不同的维度，推送给业务接收方。其中，在将直播业务消息保存至对应的消息集群时，一种可选的实施方式为，对于每个直播业务消息，具体分为以下两种情况：

情况一、对于任意一个直播业务消息，当确定存在与该直播业务消息的业务类型以及消息类型相匹配的消息集群时，则将该直播业务消息保存至确定的消息集群。

例如，直播业务消息1的业务类型为：A业务，消息类型为：type2，当存在与A业务-type2消息类型相匹配的消息集群时，假设该消息集群为：消息集群1，专门用于存储业务类型为A业务，消息类型为type2的直播业务消息，即可将该直播业务消息1保存至对应的消息集群1。

情况二、对于任意一个直播业务消息，当确定不存在与该直播业务消息的业务类型以及消息类型相匹配的消息集群时，将该直播业务消息保存至与该直播业务消息的业务类型相匹配的消息集群。

例如，直播业务消息2的业务类型为：B业务，消息类型为：type3，当不存在与B业务-type3消息类型相匹配的消息集群时，即可将该直播业务消息保存至与B业务相匹配的消息集群，假设该消息集群为：消息集群3，专门用于存储业务类型为B业务的直播业务消息，无需区分消息类型，即可将该直播业务消息2保存至对应的消息集群3。

如图5所示，其为本申请实施例中的一种直播业务消息的路由过程示意图。首先，判断是否可以通过appid和msq_type找到路由信息，如果是，则返回路由信息，即上述情况一所示，存在与该直播业务消息的业务类型以及消息类型相匹配的消息集群。

否则，则继续判断通过是否可以通过appid找到路由信息，如果是，则返回路由信息，即上述情况二所示，不存在与该直播业务消息的业务类型以及消息类型相匹配的消息集群，但是存在与该直播业务消息的业务类型相匹配的消息集群。

具体的，路由信息的数据结构如下：

type route struct{

appid int64 // 业务类型

msg_type int64 // 消息类型

set_info string // set的信息

}

其中，appid表示业务类型，为int（整型）数据，64位；msg_type表示消息类型，同样为int数据，64位；set_info则表示set的信息，即相匹配的消息集群的信息，为string（字符串）数据。

需要说明的是，上述所列举的路由信息的数据结构仅是举例说明，本文不做具体限定。

可选的，当既不存在与该直播业务消息的业务类型以及消息类型相匹配的消息集群时，也不存在与该直播业务消息的业务类型相匹配的消息集群时，则刻之间结束本流程。该情况下，表示不存在与该直播业务消息相匹配的消息集群，为了保证这一类直播业务消息的推送，可将这一类直播业务消息保存至专门用于存储这些无法匹配的直播业务消息，也可新建与该直播业务消息的业务类型和消息类型相匹配的新的消息集群并保存，或者，也可新建仅与该直播业务消息的业务类型相匹配的信的消息集群并保存等，在此不做具体限定。

S23：服务器在接收到目标业务接收方发送的针对目标直播业务消息的获取请求后，确定目标直播业务消息的目标业务类型和目标消息类型；

S24：服务器基于目标业务类型和目标消息类型，从对应的消息集群中获取目标直播业务消息，并将目标直播业务消息分发给目标业务接收方。

其中，业务接收方同业务发送方类似，可以是主播，也可以是观众等等，在此不做具体限定。

例如，目标业务接收方发送了针对目标直播业务消息（直播业务消息1）的获取请求后，服务器确定出该目标直播业务消息的目标业务类型为：业务A，目标消息类型为：type2消息，基于此确定出，对应的消息集群为：消息集群1，因而，即可从消息集群1中获取该目标直播业务消息，进而发送给目标业务接收方。

在上述实施方式中，由于本申请通过业务隔离，将直播业务消息按照业务类型和消息类型进行保存，具有不同业务类型或消息类型的直播业务消息，可以保存至不同的消息集群。当接收到目标业务接收方发送的针对目标直播业务消息的获取请求时，可基于该目标直播业务消息的目标业务类型和目标消息类型，从对应的目标消息集群中拉取消息，推送给该目标业务接收方。这样，在直播间中有百万人同时在线，产生百万请求的情况下，可通过上述业务隔离的方式，减小直播系统的压力，及时进行消息的推送，有效提高直播消息的实时性和直播系统的高可用性。

下面对本申请实施例中给出的直播控制方法进行详细介绍：

在实际应用中，直播间可能会有百万人同时在线，如果每个人进房都会有一条进房的消息，就会产生一百万的消息量。这样会有100万的消息量，导致事件中心的压力会非常大，系统可能被压垮，导致系统不可用。下面结合图6所示的直播系统的架构图，来详细描述本申请实施例如何来保证系统的高可用性、安全性、扩展性等。

参阅图6所示，其为本申请实施例中的一种直播系统架构图，主要分为3个模块：管理后台、事件服务、kafka消息队列（消息集群）。

其中，业务SDK是指嵌入到app（Application，应用程序）里面的SDK，在本申请实施例中，业务A SDK、业务B SDK等则是指嵌入到直播客户端中的SDK。中台后台用于管理中台后台的服务，包括送礼服务、聊天服务等。事件中心则包括admin（管理）和事件服务两部分。其中，admin是管理后台，事件服务则主要负责事件的分发，如图4所示，本申请实施例中的事件中心可划分为多个set，这里set的划分主要是指对事件服务进行set的划分，不同的事件中心set可对应有不同的kafka消息队列，经过事件中心，即可将业务发送方推送的直播业务消息保存至kafka消息队列。kafka消息队列即消息集群，用于保存业务发送方推送的直播业务消息。如图6所示，不同业务类型，不同消息类型的直播业务消息可保存至不同的Ckafka消息队列。

具体地，本申请实施例中可以根据业务和消息类型，将消息发送到指定的Ckafka消息队列；进而，配置业务类型+消息类型转发的Ckafka信息，业务接收方，如图6所示的业务方A、业务方B、业务方C等，根据admin配置的topic申请消息。其中，topic指业务订阅的kafka消息的标识，比如，业务方A用于订阅A业务消息A2类的消息，则该topic可表示为图6所示的Ckafka消息队列中的第一个消息队列中消息的标识，或者是该消息队列的标识等。

为了进一步提高直播系统的高可用性，本申请还可进一步根据消息级别来进行划分。

在另一种可选的实施方式中，不同级别的直播业务消息对应的消息集群的性能参数不同，消息集群的性能参数与直播业务消息的级别呈正相关，也即，消息集群的性能参数越大，表明该消息集群的性能越高，数据写入能力越强，对应存储的直播业务消息的级别也就越高。

其中，每个直播业务消息的级别是根据直播业务消息的业务类型与消息类型中的至少一种确定的，每个消息集群的性能参数用于表示消息集群的数据写入能力。

比如，聊天消息属于非重要的消息，丢失了对用户的体验不会有太多的影响，可设置这些直播业务消息对应的级别较低，比如将消息划分为四个级别，聊天消息级别为一。对于这种级别较低的消息，本申请可以通过限制发送的频率，来保证系统的问题，可以采用性能一般的kafka集群来保存。对于送礼这些重要的消息，可设置这些直播业务消息对应的级别较高，比如级别为四，采用高性能的kafka集群来保存。

如图7所示，其为本申请实施例中的一种消息分级存储方法的示意图。在本申请实施例中，中台后台可以通过消息分级策略，将不同级别的直播业务消息保存至具有不同性能参数的消息集群。

例如，图7中所示的集群1、集群2、集群3、…，分别用于保存不同级别的直播业务消息。比如，集群1用于保存级别一的直播业务消息，集群2用于保存级别二的直播业务消息，集群3用于保存级别三的直播业务消息等等。假设，消息A1级别为一，即可保存在集群1中；消息B1级别为二，即可保存在集群2中，等等。

另外，本申请实施例中，还可在图4所示的基础上，进一步进行集群的划分，将事件中心set再按照消息级别进行划分，每个事件中心set都可进一步划分为若干消息集群等等。

在上述实施方式中，通过分级策略，不仅保证了系统的问题，同时进一步减少了运营成本。

在一种可选的实施方式中，为了监控消息的实时性，还可为消息设置时间戳，基于时间戳来对消息进行监控。

具体地，分别确定各个直播业务消息各自对应的当前时间戳与发送时间戳之间的时间差，若对应的时间差大于第一预设时长的直播业务消息的数量高于预设阈值，则进行告警。

其中，每个直播业务消息的发送时间戳用于标识业务发送方推送直播业务消息的时间。

比如，对于直播业务消息1，当前时间戳为t1，对应的发送时间戳为t2，时间差t=t1-t2。通过将t与第一预设时长T1进行比较，来区分直播业务消息是否发生堆积。当t不小于T1时，即可确定该直播业务消息1发生消息堆积。

若发生消息堆积的直播业务消息的数量达到预设阈值时，即可触发告警机制，进行告警，告警消息可以包括直播业务消息堆积的条数，各条直播业务消息的延时等信息，通过实时告警以触发扩容。

在上述实施方式中，通过在消息里面加上时间戳，用当前的时间减去消息发送的时候的时间戳，可以有效监控消息的实时性；并且，通过监控消息的堆积，设置实时的告警，进一步保证了系统的稳定。

另外，本申请考虑到：对于重要的消息，比如用户送礼的消息如果丢失了，会引起用户的投诉，因而，本申请提供了统一的对账重放机制。具体流程如下：

为了保证不丢失消息，接入kafka消息队列，异步解耦削峰，虽然，消息队列不会丢消息，但是会有重复消息出现的情况。本申请为了保证从kafka拉取消息时，不重复处理消息，提出了如下方法：

在本申请实施例中，可对消息的状态进行检验，每一条消息都有唯一订单号（也即流水号），在接收消息之前，可以检验这个消息有没有被消费过，基于此检验结果，加上kafka的确认消费机制来确认是否将消息写入消息集群，并在消息写入成功后再confirm（确认）。

如图8所示，其为本申请实施例中的一种对账重放机制的流程示意图。中台后台发送到kafka的消息在写入kafka之前，需要先经过协议适配层，将消息对应的流水记录到CDB（Cloud DataBase，云数据库）中，进一步检查消息状态，即图8所示的消息校验步骤，校验这个消息有没有被消费过。基于此检验结果，加上kafka的确认消费机制来确认是否将消息写入消息集群，并在消息写入成功后再确认。

在本申请实施例中，假如执行一半进程挂掉，或者是机器宕机，也可以被其他机器消费到之前的消费，并且接着执行业务侧的流水。但是，发送kafka可能存在失败及超时，此时就会有流水丢失。

因此，本申请在活动服务器（svr）里增加了一个对账修复模块（也即图8所示的对账模块），与业务侧旁路的流水进行比对，能够感知到缺失的流水，然后对当前时间偏移5秒以前的流水进行消息的重放对比。

一种可选的实施方式为，在步骤S22之前，还需要分别获取各个直播业务消息对应的消息标识；进而，对于每个直播业务消息分别执行以下操作：

基于直播业务消息的消息标识，确定该直播业务消息是否被分发。

具体地，当确定该直播业务消息未被分发时，即未被消费时，可确认该直播业务消息能够写入对应的消息集群；当确定该直播业务消息已被分发时，即已被消费时，可确认该直播业务消息不能够写入对应的消息集群。

在上述实施方式中，通过消息写入前的校验，可有效保证不重复处理消息。

在另一种可选的实施方式中，在步骤S24之后，还可将各个业务接收方需要从对应的消息集群中获取的目标直播业务消息，与各个业务接收方接收到的目标直播业务消息进行比对。

具体地，当确定需要获取的目标直播业务消息，与接收到的目标直播业务消息不一致时，即表示存在流水缺失的情况，需要对当前时间之前的第二预设时长内的直播业务消息重新进行比对。当确定需要获取的目标直播业务消息，与接收到的目标直播业务消息一致时，即表示不存在流水缺失的情况。

例如，第二预设时长可以为5秒时，即刻重放对比当前时间偏移5秒以前的流水，通过重放对比以查找出缺失的流水，进而进行重发，保证消息可以成功发送和接收。

在本申请实施例中，作为一个中台业务，一定要满足业务快速接入的需求，对扩展性要求提出了很高的要求。

为了满足业务的需求，通过分析他们的特性，本申请抽象出了两种分发策略，第一种为：按照业务和消息类型维度的转发，即按照业务类型和消息类型，分别将各个直播业务消息分发至对应的业务接收方。

例如，将A业务-type2消息类型的直播业务消息分发给业务接收方1，将B业务-type3消息类型的直播业务消息分发给业务接收方2等等。

第二种为：按照主播维度的转发，按照直播对象的身份信息，分别将各个直播业务消息分发至对应的业务接收方。

其中，直播对象的身份信息可以指主播的房间ID，主播的账号ID等。例如，将主播1的直播业务消息分发给关注该主播的观众，例如业务接收方1、业务接收方2、业务接收方3、…，将主播2的直播业务消息分发给关注该主播的观众，例如业务接收方5、业务接收方7、业务接收方9、…。

基于上述实施方式，可以满足不同业务消息之间的转发。

但是，随着业务的增加，配置key的增加会无限的扩展，这样会导致拉取的速度越来越慢。因而，本申请采用两级索引的方式解决这个问题。

具体地，在将各个直播业务消息发送至对应的业务接收方时，对于每个直播业务消息分别执行以下操作：

首先，确定直播业务消息对应的两级索引，本申请中的两级索引包括：用于表示路由信息的一级索引信息，以及，用于表示分发信息的二级索引信息；进而，按照一级索引信息，从对应的消息集群中获取该直播业务消息；最后，按照二级索引信息，将该直播业务消息分发给对应的业务接收方。

例如，一级索引信息可表示为：key：route（路由）数据：数组

二级索引信息可表示为：key：route_[appid]数据：分发信息列表。

其中，分发信息列表的数据结构如表1所示：

表1

由上述列表可知，分发信息列表主要包括三个字段，字段名分别为：Name（名称）、Target（目标）、msg_type（消息类型）。这三个字段表示的含义分别为：

Name是指对分发信息进行说明，例如该分发信息的作用用于分发某直播业务消息等；Target是指目标集群的信息，即将该直播业务消息分发至哪一消息集群，msg_type指消息类型。

其中，Name和Target这一字段的类型为string，msg_type这一字段的类型为int。

另外，考虑到如果每个业务自身对应的消息，都会基于中台来申请消费数据，这样会导致中台业务集群的扩展性变弱。因而，本申请实施例中，只将消息转发到每个业务的集群，每个业务的消息消费将会由业务来控制消费情况，这样也进一步方便成本的核算。

如图9所示，其为本申请实施例中的一种关联关系的示意图，该图表示直播业务消息和消息集群之间的关联关系。在本申请实施例中，至少可以根据消息所属的业务，将消息集群进行划分。例如图9中，业务1对应一个消息集群，业务2对应一个消息集群，业务3对应一个消息集群。

对于某一直播业务消息A1，若该消息所属的业务类型为：业务1，即可将该消息保存至图9中业务1所对应的消息集群，又比如某一直播业务消息B1，若该消息所属的业务类型为：业务2，即可将该消息保存至图9中业务2所对应的消息集群。

需要说明的是，上述所列举的是一个业务对应一个消息集群，实际上，一个业务也可以对应多个消息集群，并且，可以根据消息类型，消息级别等，对某一业务对应的多个消息集群进一步划分。

在本申请实施例中，需要保证消息的有序性，对于开停播消息，直播停播消息不能比直播开播消息先到。因而，为了保证同一个用户的消息有序性，可通过一致性hash将直播业务消息保存到消息集群。

一种可选的实施方式为：当根据各个直播业务消息的业务类型和消息类型，确定直播业务消息包括直播开播消息与直播停播消息时，将同一业务发送方对应的直播开播消息和直播停播消息保存至同一消息集群。

例如，同一业务发送方发送的直播开播消息和直播停播消息具有相同的hash值，可保存至同一消息集群中，同一消息集群中的直播业务消息是以消息队列的形式存储的，因而消息之间具有有序性，可有效保证直播停播消息比直播开播消息后到。

另外，在本申请实施例中，通过提供统一的协议，提炼出转发需要的变更信息，将聊天等消息封装成序列化的字段。保证了消息内容有变更，业务集群不需要变更。协议如下：

//原始数据输入：

message OriginalMsgReq //信息 原始信息序列

{

int64 appid=1； //appid分配文档：

http://tapd.oa.com/individual_broadcast/markdown_wikis/#1010126711010456035；

int64 msg_type=2； //消息类型=2，如登录、注册、抽奖等；

uint64 send_uid=3； //操作者uid=3，如送礼者；

int64 client_type=4； //客户端类型=4，如安卓，IOS；

uint64 recv_uid=5； //被操作者uid=5，如关注者，收礼者；

bytes msg_body=10； //透传业务消息pt序列化消息，根据业务方提供的go mod解析结构体

}

上述协议的信息包包括：直播业务消息的业务类型，即appid；消息类型，即msg_type；操作者uid，即send_uid，也称业务发送方uid；客户端类型，即client_type；被操作者uid，即recv_uid，也称业务接收方uid；直播业务消息主体，即msg_body。

在本申请实施例中，msg_body这部分内容主要是指直播业务消息中的变更信息，可通过pt协议将变更的信息转化为序列化字段，根据业务方提供的go mod协议解析结构体。

在一种可选的实施方式中，当某一直播业务消息发生变更时，即可获取该直播业务消息对应的变更信息，按照上述所列举的预设协议，将变更信息封装为序列化字段；进而，根据序列化字段，对对应的消息集群中的一个直播业务消息进行变更即可。

在上述实施方式中，通过提供统一的协议，提炼出转发需要的变更信息，将聊天等消息封装成序列化的字段。保证了消息内容有变更，业务集群不需要变更。

在本申请实施例中，业务发送方和业务接收方可以为同一业务方，如图6所示，是以业务发送方和业务接收方都可以为业务方A，业务方B等。

另外，业务发送方和业务接收方也可以为不同的业务方。考虑到如果一个业务的消息被另外一个业务获取了，会导致业务数据可能被窃取。因而，本申请为了在方便消息共享的同时，保证消息的安全性，通过事前，事中，事后三种策略来保证安全性。

具体地，在事前，需要进行获取权限的校验。也即，本申请中，业务按需申请其他业务的消费，必须相关业务的负责人审批通过后，才会将消息转发给申请方的集群。

在一种可选的实施方式中，在接收到目标业务接收方发送的针对目标直播业务消息的获取请求之后，将目标直播业务消息分发给目标业务接收方之前，首先需要判断目标业务接收方是否具有针对目标直播业务消息的获取权限；在确定目标业务接收方具有针对目标直播业务消息的获取权限的情况下，才会将目标直播业务消息分发给目标业务接收方；若确定目标业务接收方不具有针对目标直播业务消息的获取权限的情况下，则不会将目标直播业务消息分发给目标业务接收方。

具体地，在本申请实施例中可预先建立不同的业务接收方与各自对应的直播业务消息的获取权限之间的关系表，该关系表具体包括各个业务接收方所支持获取的直播业务消息的业务类型，消息类型等等，比如表2所示：

表2

由上表可知，业务接收方1具有获取权限的直播业务消息的业务类型有：A业务，B业务，消息类型有：type1，type2，即表示业务接收方1针对A业务type2类，A业务type2类的直播业务消息，B业务类的直播业务消息具有获取权限；业务接收方2具有获取权限的直播业务消息的业务类型有：B业务，C业务，消息类型为“空”，表示消息类型不做具体限定，即表示业务接收方2针对B业务，C业务类的直播业务消息具有获取权限；…，以此类推即可，业务接收方N针对D业务type4类的直播业务消息具有获取权限。

其中，判断目标业务接收方是否具有针对目标直播业务消息的获取权限的过程，即可通过查询上述构建的关系表来分析，当确定目标业务接收方是否具有针对目标直播业务消息的获取权限时，才可进一步进行消息的分发。

另外，除了上述所列举的建立关系表的方式之外，还可直接由相关业务负责人介入进行审批，例如，在接收到针对某一直播业务消息的获取请求后，即可向相关业务的负责人发送审批提醒，在接收到审批通过的通知后，即可确定目标业务接收方是否具有针对目标直播业务消息的获取权限，等等。

需要说明的是，上述所列举的几种判断某一业务接收方是否具有针对某一直播业务消息的获取权限的方式只是举例说明，实际上，任何一种判断方式都适用于本申请实施例，在此不做具体限定。

可选的，在事中，业务方可以选择对重要的数据进行加密，即使其他业务拿到消息，没有秘钥也不能获取到相关的消息，依此来提高消息的安全性。

一种可选的实施方式为，在分别将各个直播业务消息保存至对应的消息集群之前，分别对各个直播业务消息中指定的直播业务消息进行加密，获取各个指定的直播业务消息各自对应的秘钥；在此基础上，若目标直播业务消息属于指定的直播业务消息时，即可将目标直播业务消息分发给目标业务接收方时，则需要将目标直播业务消息，以及目标直播业务消息对应的秘钥都分发给目标业务接收方，以使目标业务接收方根据接收到的秘钥对目标直播业务消息进行解密。

其中，指定的直播业务消息可以是指相对比较重要的直播业务消息，比如某一业务类型的，某一消息类型的，或者某一消息级别的直播业务消息。当然，在不具体细分的情况下，也可对所有的直播业务消息都进行加密。

同样地，在向各个业务接收方分发直播业务消息时，也可将相应的直播业务消息以及秘钥分发给相应的业务接收方。

可选的，事后，会对每天业务的消息进行对账，如果发送方的消息和消费的总消息数量不一致，就会找到不一致的业务进行告警。

一种可选的实施方式为，每隔第三预设时长，将各个业务发送方在第三预设时长内推送的直播业务消息，与各个业务接收方在第三预设时长内接收的直播业务消息进行比对；确定业务发送方推送的直播业务消息的数量，与业务接收方接收的直播业务消息的数量不一致时，则进行告警。

例如，第三预设时长为24小时，在每天将各个业务发送方推送过来的直播业务消息，与各个业务接收方接收到的直播业务消息进行比对，比如所有业务发送方一共推送了100条消息，而业务接收方一共接收到了99条消息，即可确定业务发送方推送的直播业务消息的数量，与业务接收方接收的直播业务消息的数量不一致，进行实时告警。此外，还可通过将业务发送方推送的直播业务消息，与业务接收方接收的直播业务消息进行比对，查找到不一致的业务。

综上，本申请实施例主要从直播系统的高可用性、扩展性和安全性三个方面进行详细介绍，提出了一个高可用、实时性好、扩展性强、安全性好、方便消息共享的事件分发的解决方案。在海量请求的情况下通过业务的set化部署、消息分级机制以及多维度的告警，对账，保证系统高可用。通过协议的设计、转发方式的抽象和配置的管理等方式保证系统良好的扩展性，可以满足业务快速接入的需求。通过事前、事中、事后三种策略保证了消息的安全性。

参阅图10所示，其为本申请实施例中一种直播控制方法的时序图。该方法的具体实施流程如下：

步骤S1001：服务器获取业务发送方需要推送的多个直播业务消息；

步骤S1002：服务器分别获取各个直播业务消息对应的消息标识，基于各个直播业务消息的消息标识，确定各个直播业务消息是否被分发；

步骤S1003：服务器在基于消息标识确定各个直播业务消息未被分发时，确认各个直播业务消息能够写入对应的消息集群；

步骤S1004：服务器确定各个直播业务消息的业务类型和消息类型，根据各个直播业务消息的业务类型和消息类型，将各个直播业务消息保存至对应的消息集群；

步骤S1005：服务器在接收到目标业务接收方发送的针对目标直播业务消息的获取请求后，判断目标业务接收方是否具有针对目标直播业务消息的获取权限；

步骤S1006：服务器在确定目标业务接收方具有获取权限时，确定目标直播业务消息的目标业务类型和目标消息类型；

步骤S1007：服务器基于目标业务类型和目标消息类型，从对应的消息集群中获取目标直播业务消息，并将目标直播业务消息分发给目标业务接收方；

步骤S1008：服务器每隔第三预设时长，将各个业务发送方在第三预设时长内推送的直播业务消息，与各个业务接收方在第三预设时长内接收的直播业务消息进行比对；

步骤S1009：服务器确定业务发送方推送的直播业务消息的数量，与业务接收方接收的直播业务消息的数量不一致时，则进行告警。

需要说明的是，图10所示的直播控制方法中，步骤S1001-步骤S1004主要是为了提高系统的高可用性，消息的实时性，另外，通过步骤S1005-S1009中给出的方法，以提高系统的安全性，另外，基于上文所列举的方法，也可进一步提高系统的扩展性，图10仅仅是本申请实施例中所列举的一种直播控制方法，并未对如何提高系统扩展性进行举例说明，实际上，还可在图10所示的基础上，增加更多的步骤，以优化直播系统的性能，在此不做具体限定。

基于相同的发明构思，本申请实施例还提供一种直播控制装置。如图11所示，其为直播控制装置1100的结构示意图，可以包括：

获取单元1101，用于获取业务发送方需要推送的多个直播业务消息，并确定各个直播业务消息的业务类型和消息类型；

存储单元1102，用于分别根据各个直播业务消息的业务类型和消息类型，将各个直播业务消息保存至对应的消息集群；

确定单元1103，用于在接收到目标业务接收方发送的针对目标直播业务消息的获取请求后，确定目标直播业务消息的目标业务类型和目标消息类型；

第一分发单元1104，用于基于目标业务类型和目标消息类型，从对应的消息集群中获取目标直播业务消息，并将目标直播业务消息分发给目标业务接收方。

可选的，存储单元1102具体用于：

对于每个直播业务消息分别执行以下操作：

确定存在与一个直播业务消息的业务类型以及消息类型相匹配的消息集群时，将一个直播业务消息保存至确定的消息集群；

确定不存在与一个直播业务消息的业务类型以及消息类型相匹配的消息集群时，将一个直播业务消息保存至与一个直播业务消息的业务类型相匹配的消息集群。

可选的，不同级别的直播业务消息对应的消息集群的性能参数不同，消息集群的性能参数与直播业务消息的级别呈正相关，其中，每个直播业务消息的级别是根据直播业务消息的业务类型与消息类型中的至少一种确定的，每个消息集群的性能参数用于表示消息集群的数据写入能力。

可选的，装置还包括：

第一比对单元1105，用于分别确定各个直播业务消息各自对应的当前时间戳与发送时间戳之间的时间差，其中，每个直播业务消息的发送时间戳用于标识业务发送方推送直播业务消息的时间；

若对应的时间差大于第一预设时长的直播业务消息的数量高于预设阈值，则进行告警。

可选的，存储单元1102还用于：

在分别根据各个直播业务消息的业务类型和消息类型，将直播业务消息保存至对应的消息集群之前，分别获取各个直播业务消息对应的消息标识；

对于每个直播业务消息分别执行以下操作：

基于一个直播业务消息的消息标识，确定一个直播业务消息是否被分发；

在基于消息标识确定一个直播业务消息未被分发时，确认一个直播业务消息能够写入对应的消息集群。

可选的，装置还包括：

第二比对单元1106，用于在第一分发单元1104将目标直播业务消息分发给目标业务接收方之后，将各个业务接收方需要从对应的消息集群中获取的目标直播业务消息，与各个业务接收方接收到的目标直播业务消息进行比对；

确定需要获取的目标直播业务消息，与接收到的目标直播业务消息不一致时，对当前时间之前的第二预设时长内的直播业务消息重新进行比对。

可选的，装置还包括：

第二分发单元1107，用于按照业务类型和消息类型，分别将各个直播业务消息分发至对应的业务接收方；或者

按照直播对象的身份信息，分别将各个直播业务消息分发至对应的业务接收方。

可选的，第二分发单元1107具体用于：

对于每个直播业务消息分别执行以下操作：

确定一个直播业务消息对应的两级索引，两级索引包括用于表示路由信息的一级索引信息，以及用于表示分发信息的二级索引信息；

按照一级索引信息，从对应的消息集群中获取一个直播业务消息；

按照二级索引信息，将一个直播业务消息分发给对应的业务接收方。

可选的，存储单元1102具体用于：

根据各个直播业务消息的业务类型和消息类型，确定直播业务消息包括直播开播消息与直播停播消息时，将同一业务发送方对应的直播开播消息和直播停播消息保存至同一消息集群。

可选的，装置还包括：

变更单元1108，用于在一个直播业务消息发生变更时，获取一个直播业务消息对应的变更信息；

按照预设协议，将变更信息封装为序列化字段；

根据序列化字段，对对应的消息集群中的一个直播业务消息进行变更。

可选的，第一分发单元1104还用于：

在将目标直播业务消息分发给目标业务接收方之前，在接收到目标业务接收方发送的针对目标直播业务消息的获取请求后，确定目标业务接收方是否具有针对目标直播业务消息的获取权限；

第一分发单元1104具体用于：

在确定目标业务接收方具有获取权限时，将目标直播业务消息分发给目标业务接收方。

可选的，存储单元1102还用于：

在分别将各个直播业务消息保存至对应的消息集群之前，分别对各个直播业务消息中指定的直播业务消息进行加密，获取指定的直播业务消息各自对应的秘钥；

第一分发单元1104具体用于：

若目标直播业务消息属于指定的直播业务消息，则将目标直播业务消息，以及目标直播业务消息对应的秘钥分发给目标业务接收方，以使目标业务接收方根据接收到的秘钥对目标直播业务消息进行解密。

可选的，装置还包括：

第三比对单元1109，用于每隔第三预设时长，将各个业务发送方在第三预设时长内推送的直播业务消息，与各个业务接收方在第三预设时长内接收的直播业务消息进行比对；

确定业务发送方推送的直播业务消息的数量，与业务接收方接收的直播业务消息的数量不一致时，则进行告警。

由于本申请通过业务隔离，将直播业务消息按照业务类型和消息类型进行保存，具有不同业务类型或消息类型的直播业务消息，可以保存至不同的消息集群。当接收到目标业务接收方发送的针对目标直播业务消息的获取请求时，可基于该目标直播业务消息的目标业务类型和目标消息类型，从对应的目标消息集群中拉取消息，推送给该目标业务接收方。这样，在直播间中有百万人同时在线，产生百万请求的情况下，可通过上述业务隔离的方式，减小直播系统的压力，及时进行消息的推送，有效提高直播消息的实时性和直播系统的高可用性。

为了描述的方便，以上各部分按照功能划分为各模块（或单元）分别描述。当然，在实施本申请时可以把各模块（或单元）的功能在同一个或多个软件或硬件中实现。

在介绍了本申请示例性实施方式的直播控制方法和装置之后，接下来，介绍根据本申请的另一示例性实施方式的电子设备。

所属技术领域的技术人员能够理解，本申请的各个方面可以实现为系统、方法或程序产品。因此，本申请的各个方面可以具体实现为以下形式，即：完全的硬件实施方式、完全的软件实施方式（包括固件、微代码等），或硬件和软件方面结合的实施方式，这里可以统称为“电路”、“模块”或“系统”。

与上述方法实施例基于同一发明构思，本申请实施例中还提供了一种电子设备。在一种实施例中，该电子设备可以是服务器，如图1所示的服务器120。在该实施例中，电子设备的结构可以如图12所示，包括存储器1201，通讯模块1203以及一个或多个处理器1202。

存储器1201，用于存储处理器1202执行的计算机程序。存储器1201可主要包括存储程序区和存储数据区，其中，存储程序区可存储操作系统，以及运行即时通讯功能所需的程序等；存储数据区可存储各种即时通讯信息和操作指令集等。

存储器1201可以是易失性存储器，例如RAM（random-access memory，随机存取存储器）；存储器1201也可以是非易失性存储器，例如只读存储器，快闪存储器，HDD（harddisk drive，硬盘）或SSD（solid-state drive，固态硬盘）；或者存储器1201是能够用于携带或存储具有指令或数据结构形式的期望的程序代码并能够由计算机存取的任何其他介质，但不限于此。存储器1201可以是上述存储器的组合。

处理器1202，可以包括一个或多个CPU（central processing unit，中央处理单元）或者为数字处理单元等等。处理器1202，用于调用存储器1201中存储的计算机程序时实现上述直播控制方法。

通讯模块1203用于与终端设备和其他服务器进行通信。

本申请实施例中不限定上述存储器1201、通讯模块1203和处理器1202之间的具体连接介质。本申请实施例在图12中以存储器1201和处理器1202之间通过总线1204连接，总线1204在图12中以粗线描述，其它部件之间的连接方式，仅是进行示意性说明，并不引以为限。总线1204可以分为地址总线、数据总线、控制总线等。为便于描述，图12中仅用一条粗线描述，但并不描述仅有一根总线或一种类型的总线。

存储器1201中存储有计算机存储介质，计算机存储介质中存储有计算机可执行指令，计算机可执行指令用于实现本申请实施例的直播控制方法。处理器1202用于执行上述的直播控制方法，如图2所示。

在另一种实施例中，电子设备也可以是其他电子设备，如图1所示的终端设备110。在该实施例中，电子设备的结构可以如图13所示，包括：通信组件1310、存储器1320、显示单元1330、摄像头1340、传感器1350、音频电路1360、蓝牙模块1370、处理器1380等部件。

通信组件1310用于与服务器进行通信。在一些实施例中，可以包括电路WiFi（Wireless Fidelity，无线保真）模块，WiFi模块属于短距离无线传输技术，电子设备通过WiFi模块可以帮助用户收发信息。

存储器1320可用于存储软件程序及数据。处理器1380通过运行存储在存储器1320的软件程序或数据，从而执行终端设备110的各种功能以及数据处理。存储器1320可以包括高速随机存取存储器，还可以包括非易失性存储器，例如至少一个磁盘存储器件、闪存器件、或其他易失性固态存储器件。存储器1320存储有使得终端设备110能运行的操作系统。本申请中存储器1320可以存储操作系统及各种应用程序，还可以存储执行本申请实施例直播控制方法的代码。

显示单元1330还可用于显示由用户输入的信息或提供给用户的信息以及终端设备110的各种菜单的GUI（graphical user interface，图形用户界面）。具体地，显示单元1330可以包括设置在终端设备110正面的显示屏1332。其中，显示屏1332可以采用液晶显示器、发光二极管等形式来配置。显示单元1330可以用于显示本申请实施例中的直播界面等。

显示单元1330还可用于接收输入的数字或字符信息，产生与终端设备110的用户设置以及功能控制有关的信号输入，具体地，显示单元1330可以包括设置在终端设备110正面的触摸屏1331，可收集用户在其上或附近的触摸操作，例如点击按钮，拖动滚动框等。

其中，触摸屏1331可以覆盖在显示屏1332之上，也可以将触摸屏1331与显示屏1332集成而实现终端设备110的输入和输出功能，集成后可以简称触摸显示屏。本申请中显示单元1330可以显示应用程序以及对应的操作步骤。

摄像头1340可用于捕获静态图像，用户可以将摄像头1340拍摄的图像通过应用发布评论。摄像头1340可以是一个，也可以是多个。物体通过镜头生成光学图像投射到感光元件。感光元件可以是CCD（charge coupled device，电荷耦合器件）或CMOS（complementarymetal-oxide-semiconductor，互补金属氧化物半导体）光电晶体管。感光元件把光信号转换成电信号，之后将电信号传递给处理器1380转换成数字图像信号。

终端设备还可以包括至少一种传感器1350，比如加速度传感器1351、距离传感器1352、指纹传感器1353、温度传感器1354。终端设备还可配置有陀螺仪、气压计、湿度计、温度计、红外线传感器、光传感器、运动传感器等其他传感器。

音频电路1360、扬声器1361、传声器1362可提供用户与终端设备110之间的音频接口。音频电路1360可将接收到的音频数据转换后的电信号，传输到扬声器1361，由扬声器1361转换为声音信号输出。终端设备110还可配置音量按钮，用于调节声音信号的音量。另一方面，传声器1362将收集的声音信号转换为电信号，由音频电路1360接收后转换为音频数据，再将音频数据输出至通信组件1310以发送给比如另一终端设备110，或者将音频数据输出至存储器1320以便进一步处理。

蓝牙模块1370用于通过蓝牙协议来与其他具有蓝牙模块的蓝牙设备进行信息交互。例如，终端设备可以通过蓝牙模块1370与同样具备蓝牙模块的可穿戴电子设备（例如智能手表）建立蓝牙连接，从而进行数据交互。

处理器1380是终端设备的控制中心，利用各种接口和线路连接整个终端的各个部分，通过运行或执行存储在存储器1320内的软件程序，以及调用存储在存储器1320内的数据，执行终端设备的各种功能和处理数据。在一些实施例中，处理器1380可包括一个或多个处理单元；处理器1380还可以集成应用处理器和基带处理器，其中，应用处理器主要处理操作系统、用户界面和应用程序等，基带处理器主要处理无线通信。可以理解的是，上述基带处理器也可以不集成到处理器1380中。本申请中处理器1380可以运行操作系统、应用程序、用户界面显示及触控响应，以及本申请实施例的直播控制方法。另外，处理器1380与显示单元1330耦接。

在一些可能的实施方式中，本申请提供的直播控制方法的各个方面还可以实现为一种程序产品的形式，其包括程序代码，当程序产品在计算机设备上运行时，程序代码用于使计算机设备执行本说明书上述描述的根据本申请各种示例性实施方式的直播控制方法中的步骤，例如，计算机设备可以执行如图2中所示的步骤。

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

本申请的实施方式的程序产品可以采用便携式紧凑盘只读存储器并包括程序代码，并可以在计算装置上运行。然而，本申请的程序产品不限于此，在本文件中，可读存储介质可以是任何包含或存储程序的有形介质，该程序可以被命令执行系统、装置或者器件使用或者与其结合使用。

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

可读介质上包含的程序代码可以用任何适当的介质传输，包括但不限于无线、有线、光缆、RF等等，或者上述的任意合适的组合。

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

本领域内的技术人员应明白，本申请的实施例可提供为方法、系统、或计算机程序产品。因此，本申请可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质（包括但不限于磁盘存储器、CD-ROM、光学存储器等）上实施的计算机程序产品的形式。

尽管已描述了本申请的优选实施例，但本领域内的技术人员一旦得知了基本创造性概念，则可对这些实施例做出另外的变更和修改。所以，所附权利要求意欲解释为包括优选实施例以及落入本申请范围的所有变更和修改。

显然，本领域的技术人员可以对本申请进行各种改动和变型而不脱离本申请的精神和范围。这样，倘若本申请的这些修改和变型属于本申请权利要求及其等同技术的范围之内，则本申请也意图包含这些改动和变型在内。

Claims (17)

1.一种直播控制方法，其特征在于，该方法包括：

获取业务发送方需要推送的多个直播业务消息，并确定各个直播业务消息的业务类型和消息类型；

分别根据所述各个直播业务消息的业务类型和消息类型，将所述各个直播业务消息保存至对应的消息集群；

在接收到目标业务接收方发送的针对目标直播业务消息的获取请求后，确定所述目标直播业务消息的目标业务类型和目标消息类型；

基于所述目标业务类型和目标消息类型，从对应的消息集群中获取所述目标直播业务消息，并将所述目标直播业务消息分发给所述目标业务接收方。

2.如权利要求1所述的方法，其特征在于，所述分别根据所述各个直播业务消息的业务类型和消息类型，将所述各个直播业务消息保存至对应的消息集群，包括：

对于每个直播业务消息分别执行以下操作：

确定存在与一个直播业务消息的业务类型以及消息类型相匹配的消息集群时，将所述一个直播业务消息保存至确定的消息集群；

确定不存在与一个直播业务消息的业务类型以及消息类型相匹配的消息集群时，将所述一个直播业务消息保存至与所述一个直播业务消息的业务类型相匹配的消息集群。

3.如权利要求1所述的方法，其特征在于，不同级别的直播业务消息对应的消息集群的性能参数不同，消息集群的性能参数与直播业务消息的级别呈正相关，其中，每个直播业务消息的级别是根据所述直播业务消息的业务类型与消息类型中的至少一种确定的，每个消息集群的性能参数用于表示消息集群的数据写入能力。

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

分别确定各个直播业务消息各自对应的当前时间戳与发送时间戳之间的时间差，其中，每个直播业务消息的发送时间戳用于标识业务发送方推送所述直播业务消息的时间；

若对应的时间差大于第一预设时长的直播业务消息的数量高于预设阈值，则进行告警。

5.如权利要求1所述的方法，其特征在于，在所述分别根据所述各个直播业务消息的业务类型和消息类型，将直播业务消息保存至对应的消息集群之前，还包括：

分别获取所述各个直播业务消息对应的消息标识；

对于每个直播业务消息分别执行以下操作：

基于一个直播业务消息的消息标识，确定所述一个直播业务消息是否被分发；

在基于所述消息标识确定所述一个直播业务消息未被分发时，确认所述一个直播业务消息能够写入对应的消息集群。

6.如权利要求1所述的方法，其特征在于，在所述将所述目标直播业务消息分发给所述目标业务接收方之后，还包括：

将各个业务接收方需要从对应的消息集群中获取的目标直播业务消息，与所述各个业务接收方接收到的目标直播业务消息进行比对；

确定需要获取的目标直播业务消息，与接收到的目标直播业务消息不一致时，对当前时间之前的第二预设时长内的直播业务消息重新进行比对。

7.如权利要求1~6中任一项所述的方法，其特征在于，所述方法还包括：

按照业务类型和消息类型，分别将各个直播业务消息分发至对应的业务接收方；或者

按照直播对象的身份信息，分别将各个直播业务消息分发至对应的业务接收方。

8.如权利要求7所述的方法，其特征在于，所述分别将各个直播业务消息发送至对应的业务接收方，包括：

对于每个直播业务消息分别执行以下操作：

确定一个直播业务消息对应的两级索引，所述两级索引包括用于表示路由信息的一级索引信息，以及用于表示分发信息的二级索引信息；

按照所述一级索引信息，从对应的消息集群中获取所述一个直播业务消息；

按照所述二级索引信息，将所述一个直播业务消息分发给对应的业务接收方。

9.如权利要求1~6中任一项所述的方法，其特征在于，所述根据所述各个直播业务消息的业务类型和消息类型，分别将所述各个直播业务消息保存至对应的消息集群，包括：

根据所述各个直播业务消息的业务类型和消息类型，确定所述直播业务消息包括直播开播消息与直播停播消息时，将同一业务发送方对应的直播开播消息和直播停播消息保存至同一消息集群。

10.如权利要求1~6中任一项所述的方法，其特征在于，所述方法还包括：

在一个直播业务消息发生变更时，获取所述一个直播业务消息对应的变更信息；

按照预设协议，将所述变更信息封装为序列化字段；

根据所述序列化字段，对对应的消息集群中的所述一个直播业务消息进行变更。

11.如权利要求1~6中任一项所述的方法，其特征在于，在所述将所述目标直播业务消息分发给所述目标业务接收方之前，还包括：

在接收到所述目标业务接收方发送的针对目标直播业务消息的获取请求后，确定所述目标业务接收方是否具有针对所述目标直播业务消息的获取权限；

所述将所述目标直播业务消息分发给所述目标业务接收方，包括：

在确定所述目标业务接收方具有获取权限时，将所述目标直播业务消息分发给所述目标业务接收方。

12.如权利要求1~6中任一项所述的方法，其特征在于，在所述分别根据所述各个直播业务消息的业务类型和消息类型，将直播业务消息保存至对应的消息集群之前，还包括：

分别对所述各个直播业务消息中的指定的直播业务消息进行加密，获取指定的直播业务消息各自对应的秘钥；

所述将所述目标直播业务消息分发给所述目标业务接收方，包括：

若所述目标直播业务消息属于指定的直播业务消息，则将所述目标直播业务消息，以及所述目标直播业务消息对应的秘钥分发给所述目标业务接收方，以使所述目标业务接收方根据接收到的秘钥对所述目标直播业务消息进行解密。

13.如权利要求1~6中任一项所述的方法，其特征在于，所述方法还包括：

每隔第三预设时长，将各个业务发送方在所述第三预设时长内推送的直播业务消息，与各个业务接收方在所述第三预设时长内接收的直播业务消息进行比对；

确定业务发送方推送的直播业务消息的数量，与业务接收方接收的直播业务消息的数量不一致时，则进行告警。

14.一种直播控制装置，其特征在于，包括：

获取单元，用于获取业务发送方需要推送的多个直播业务消息，并确定各个直播业务消息的业务类型和消息类型；

存储单元，用于分别根据所述各个直播业务消息的业务类型和消息类型，将所述各个直播业务消息保存至对应的消息集群；

确定单元，用于在接收到目标业务接收方发送的针对目标直播业务消息的获取请求后，确定所述目标直播业务消息的目标业务类型和目标消息类型；

第一分发单元，用于基于所述目标业务类型和目标消息类型，从对应的消息集群中获取所述目标直播业务消息，并将所述目标直播业务消息分发给所述目标业务接收方。

15.一种电子设备，其特征在于，其包括处理器和存储器，其中，所述存储器存储有程序代码，当所述程序代码被所述处理器执行时，使得所述处理器执行权利要求1~13中任一所述方法的步骤。

16.一种计算机可读存储介质，其特征在于，其包括程序代码，当所述存储介质在电子设备上运行时，所述程序代码用于使所述电子设备执行权利要求1~13中任一所述方法的步骤。

17.一种计算机程序产品，其特征在于，包括计算机指令，其特征在于，该计算机指令被处理器执行时实现权利要求1~13中任一所述方法的步骤。

Images