CN114928758A - 直播异常检测处理方法及装置 - Google Patents

Abstract

本申请实施例公开了一种直播异常检测处理方法及装置，其中，直播异常检测处理方法包括：接收流数据获取请求，流数据获取请求用于从直播间获取直播流数据；获取直播流数据的流相关信息；若检测出流相关信息存在异常，则生成流异常信息，并根据流异常信息进行异常修复处理。本申请根据流数据获取请求触发直播异常检测，一旦观看用户请求到异常的直播流数据就能够触发异常修复机制，实现了对异常的直播流数据的及时发现与修复，有效地提高了异常修复的实时性，减少了异常的直播流数据对用户观看体验的不良影响，并且有效地减少了资源消耗，优化了直播异常检测处理方式。

Description

直播异常检测处理方法及装置

技术领域

本申请实施例涉及互联网视频技术领域，具体涉及一种直播异常检测处理方法及装置。

背景技术

随着互联网技术的不断发展，直播得到了越来越广泛的发展和应用。在直播领域中，直播流数据可能会由于直播架构迭代、服务器异常等各种原因而出现异常，例如出现转码失败、状态异常等异常情况。为了使观看用户能够正常观看直播流数据，需要对这些存在异常的直播流数据进行修复。在现有技术中，通常是定时对直播平台中当前处于直播中的直播流数据进行全量扫描，请求获取这些直播流数据的状态信息，也就是在直播上行过程中进行全量扫描，根据状态信息检测是否存在异常，然后对存在异常的直播流数据进行修复。然而，这种通过定期全量扫描的直播异常检测处理方式不仅需要耗费大量的资源，而且异常修复的实时性较差，如果用户正在观看的直播流数据存在异常，则需要等到下一次全量扫描任务启动后才能够发现其存在异常，而后进行修复，从而会严重影响用户观看体验。

发明内容

鉴于上述问题，本申请提出了一种直播异常检测处理方法、装置、计算设备及计算机存储介质，以解决现有的直播异常检测处理方式存在的资源耗费大、异常修复实时性差等问题。

根据本申请实施例的一个方面，提供了一种直播异常检测处理方法，包括：

接收流数据获取请求，流数据获取请求用于从直播间获取直播流数据；

获取直播流数据的流相关信息；

若检测出流相关信息存在异常，则生成流异常信息，并根据流异常信息进行异常修复处理。

进一步地，流相关信息包括以下信息中的一项或多项：

拉流地址、内容分发服务端标识、清晰度集合、直播流码率、观看人数和传输协议信息。

进一步地，该方法还包括：

若拉流地址与预先设置的地址黑名单中的地址相匹配，则判定流相关信息存在异常；和/或，

若观看人数超过第一人数阈值且内容分发服务端标识的数量小于标识数量阈值，则判定流相关信息存在异常；和/或，

若观看人数超过第二人数阈值且清晰度集合中所包含的清晰度的种类的数量小于第一种类数量阈值，则判定流相关信息存在异常；和/或，

若直播流码率超过码率阈值且清晰度集合中所包含的清晰度的种类的数量小于第二种类数量阈值，则判定流相关信息存在异常；和/或，

若传输协议信息中的HLS协议信息与SLA协议信息不相对齐，则判定流相关信息存在异常。

进一步地，生成流异常信息进一步包括：

确定流相关信息所存在的异常情况信息，根据直播流数据的标识以及异常情况信息，生成流异常信息。

进一步地，根据流异常信息进行异常修复处理进一步包括：

将流异常信息添加至消息队列中；

若监听到消息队列中包含有流异常信息，则从消息队列中提取流异常信息，根据流异常信息触发对应的服务模块进行异常修复处理。

进一步地，该方法还包括：对流异常信息进行去重处理。

进一步地，对流异常信息进行去重处理进一步包括：

为流异常信息设置对应的数据键；

若数据库中未包含有数据键，则将数据键存储至数据库中，并将流异常信息作为去重后的流异常信息。

进一步地，数据键具有过期时间；该方法还包括：

在到达过期时间时，从数据库中删除数据键。

进一步地，数据键是根据直播流数据的标识以及异常情况信息设置的。

根据本申请实施例的另一方面，提供了一种直播异常检测处理装置，包括：

接收模块，适于接收流数据获取请求，流数据获取请求用于从直播间获取直播流数据；

获取模块，适于获取直播流数据的流相关信息；

处理模块，适于若检测出流相关信息存在异常，则生成流异常信息，并根据流异常信息进行异常修复处理。

根据本申请实施例的又一方面，提供了一种计算设备，包括：处理器、存储器、通信接口和通信总线，处理器、存储器和通信接口通过通信总线完成相互间的通信；

存储器用于存放至少一可执行指令，可执行指令使处理器执行上述直播异常检测处理方法对应的操作。

根据本申请实施例的再一方面，提供了一种计算机存储介质，存储介质中存储有至少一可执行指令，可执行指令使处理器执行如上述直播异常检测处理方法对应的操作。

根据本申请实施例提供的直播异常检测处理方法、装置、计算设备及计算机存储介质，在直播下行过程中增加了直播异常检测功能，根据客户端的流数据获取请求触发直播异常检测，一旦观看用户请求到异常的直播流数据就能够触发异常修复机制，实现了对异常的直播流数据的及时发现与修复；并且该方案无需定时对直播平台中当前处于直播中的直播流数据进行全量扫描，从而有效地减少了资源消耗，优化了直播异常检测处理方式；并且，当观看用户请求到异常的直播流数据时就能够生成流异常信息并添加至消息队列中；使用信号机制异步触发异常处理服务，异常处理服务在监听到消息队列中包含有流异常信息的情况下，自动触发对应的服务模块进行异常修复处理，有效地提高了异常修复的实时性，减少了异常的直播流数据对用户观看体验的不良影响。

上述说明仅是本申请实施例技术方案的概述，为了能够更清楚了解本申请实施例的技术手段，而可依照说明书的内容予以实施，并且为了让本申请实施例的上述和其它目的、特征和优点能够更明显易懂，以下特举本申请实施例的具体实施方式。

附图说明

通过阅读下文优选实施方式的详细描述，各种其他的优点和益处对于本领域普通技术人员将变得清楚明了。附图仅用于示出优选实施方式的目的，而并不认为是对本申请实施例的限制。而且在整个附图中，用相同的参考符号表示相同的部件。在附图中：

图1示出了根据本申请一个实施例的直播异常检测处理方法的流程示意图；

图2示出了根据本申请另一个实施例的直播异常检测处理方法的流程示意图；

图3示出了根据本申请另一个实施例的直播异常检测处理方法的流程示意图；

图4示出了根据本申请一个实施例的直播异常检测处理装置的结构框图；

图5示出了根据本申请一个实施例的一种计算设备的结构示意图。

具体实施方式

下面将参照附图更详细地描述本公开的示例性实施例。虽然附图中显示了本公开的示例性实施例，然而应当理解，可以以各种形式实现本公开而不应被这里阐述的实施例所限制。相反，提供这些实施例是为了能够更透彻地理解本公开，并且能够将本公开的范围完整的传达给本领域的技术人员。

首先，对本申请一个或多个实施例涉及的名词术语进行解释。

直播上行：主播用户在直播中将直播流数据推送到云服务的整个过程。

直播下行：观看用户在观看直播中从云服务拉取直播流数据的整个过程。

拉流：观看用户从云服务拉取直播流数据的动作。

流相关信息：与直播流数据相关的信息。

流状态服务：用于存储直播流数据的实时状态的功能模块。

直播下行调度服务：用于处理观看用户的流数据获取请求(即观看请求)的功能模块。

异常处理服务：用于对存在异常的直播流数据进行异常修复的功能模块。

转码服务：用于对直播流数据进行转码处理的功能模块。

图1示出了根据本申请一个实施例的直播异常检测处理方法的流程示意图，如图1所示，该方法包括如下步骤：

步骤S101，接收流数据获取请求。

该方法可由服务端进行执行，具体地，可在直播下行过程中执行。在通常情况下，服务端管理有多个直播间，具体地，服务端中可设置有直播下行调度服务，直播下行调度服务具体可为直播流调度服务，用于根据客户端的流数据获取请求确定对应的直播流数据的拉流地址等流相关信息，以供客户端依据流相关信息获得直播流数据进行播放。在本实施例中，直播下行调度服务还具有直播异常检测功能，具体地，可根据客户端的流数据获取请求触发直播异常检测机制，以便及时发现直播流数据是否异常。

其中，流数据获取请求用于从直播间获取直播流数据。当观看用户想要观看直播流数据时，可启动直播对应的客户端，在客户端启动后，在客户端页面中展示有多个直播间，观看用户可从多个直播间中选定一个直播间进入，在观看用户选定了一个直播间时，客户端会向服务端发送针对该直播间的流数据获取请求，用于请求获取该直播间的直播流数据。服务端接收该流数据获取请求，触发直播下行调度服务。其中，直播流数据具体可包括直播音视频等。

步骤S102，获取直播流数据的流相关信息。

在接收到流数据获取请求之后，服务端获取流数据获取请求所对应的直播流数据的流相关信息。具体地，服务端中还包含有流状态服务、异常处理服务等功能模块。直播下行调度服务接收流数据获取请求，在接收到流数据获取请求之后，直播下行调度服务向流状态服务请求直播流数据的流相关信息，流状态服务为存储有各个直播流数据的实时状态的功能模块，流状态服务响应于直播下行调度服务的请求，向直播下行调度服务返回直播流数据的流相关信息。其中，流相关信息可包括拉流地址、内容分发服务端标识、清晰度集合、直播流码率、观看人数和传输协议信息等。本领域技术人员还可根据实际需要设置流相关信息包括其他与直播流数据相关的信息，此处不做限定。

步骤S103，若检测出流相关信息存在异常，则生成流异常信息，并根据流异常信息进行异常修复处理。

在获取了直播流数据的流相关信息之后，可按照预设检测逻辑，检测流相关信息中的各项信息是否存在异常。如果检测出流相关信息存在异常，则说明该直播流数据存在异常，需要进行异常修复，那么可根据异常情况等生成流异常信息，流异常信息是用于表示直播流数据所存在的具体异常情况的信息。可根据流异常信息自动触发异常处理服务，由异常处理服务根据流异常信息对直播流数据进行相应的异常修复处理，从而解决直播流数据所存在的异常问题。如果经过检测发现流相关信息的各个信息都未存在异常，即流相关信息是正常的，则可向客户端返回流相关信息，以供客户端根据流相关信息获取对应的直播流数据进行播放。

根据本申请实施例提供的直播异常检测处理方法，在直播下行过程中增加了直播异常检测功能，根据客户端的流数据获取请求触发直播异常检测，一旦观看用户请求到异常的直播流数据就能够触发异常修复机制，实现了对异常的直播流数据的及时发现与修复，有效地提高了异常修复的实时性，减少了异常的直播流数据对用户观看体验的不良影响；并且该方案无需定时对直播平台中当前处于直播中的直播流数据进行全量扫描，从而有效地减少了资源消耗，优化了直播异常检测处理方式。

图2示出了根据本申请另一个实施例的直播异常检测处理方法的流程示意图，如图2所示，该方法包括如下步骤：

步骤S201，接收流数据获取请求。

该方法可由服务端在直播下行过程中执行，具体地，该方法可通过服务端中的直播下行调度服务、流状态服务以及异常处理服务等之间的相互协作来实现。当观看用户想要通过客户端观看直播流数据时，可在客户端页面所展示的多个直播间中选定一个直播间进入。在用户选定了一个直播间时，客户端会向服务端发送针对该直播间的流数据获取请求，用于请求从该直播间获取直播流数据。服务端接收该流数据获取请求，触发直播下行调度服务。流数据获取请求中至少包含观看用户ID、直播间ID、请求发送时刻等信息。具体地，观看用户ID为用于标识用户身份的标识信息，可为观看用户在直播平台中的账号，例如手机号、用户名、邮箱、微信号等第三方平台账号；直播间ID为用于标识直播间的标识信息，例如房间号等。本领域技术人员还可根据实际需要设置流数据获取请求包括其他信息，此处不做限定。

步骤S202，获取直播流数据的流相关信息。

根据流数据获取请求确定所要请求的直播流数据，获取该直播流数据的流相关信息。具体地，在直播下行调度服务接收到流数据获取请求之后，向流状态服务请求该直播流数据的流相关信息，由流状态服务返回直播流数据的流相关信息。其中，流相关信息可包括以下信息中的一项或多项：拉流地址、内容分发服务端标识、清晰度集合、直播流码率、观看人数和传输协议信息。本领域技术人员还可根据实际需要设置流相关信息包括其他与直播流数据相关的信息，此处不做限定。

其中，拉流地址具体是指云服务中用于拉取直播流数据的内网地址，拉流地址可包括内容分发服务端(即CDN)域名、约定路径、直播流数据的标识信息以及直播拉流源地址等。内容分发服务端标识为用于标识CDN的标识信息，不同的CDN具有不同的内容分发服务端标识。清晰度集合是指通过转码服务对直播流数据进行转码处理所得到的清晰度的集合，一般情况下，清晰度可分为多个种类，例如分别为流畅、标清、高清、超清、蓝光、4K等。直播流码率是在直播流数据传输时单位时间内传送的数据位数。观看人数是指在预设时段内观看该直播流数据的观看用户的总数量。传输协议信息是指与直播流数据的传输协议相关的信息，例如，可包括HLS(HTTP Live Streaming，超文本直播流)协议信息、SLA(ServiceLevel Agreement，服务等级)协议信息等。

步骤S203，若检测出流相关信息存在异常，则确定流相关信息所存在的异常情况信息，根据直播流数据的标识以及异常情况信息，生成流异常信息。

在本实施例中，在直播下行调度服务中增加了直播异常检测功能。考虑到不同的业务(例如转码业务、CDN业务、传输协议业务等)对于流相关信息具有不同的检测需求，例如，对于传输协议业务需保证HLS协议信息与SLA协议信息相对齐，那么为了便于进行异常检测，针对所有需要检测的业务，可预先向直播下行调度服务注册其对应的预设检测逻辑，预设检测逻辑具体可为符合其对应业务的检测需求的检测代码。那么在获取到流相关信息之后，即可按照所注册的预设检测逻辑，检测流相关信息中的各项信息是否存在异常。在具体检测过程中，针对单个业务的检测，可以依据流相关信息中的单个信息进行检测，也可结合流相关信息中的多个信息进行检测，此处不做限定。

例如，对于拉流地址的检测，可将拉流地址与预先设置的地址黑名单进行比对，其中，地址黑名单中记录有需要屏蔽的边缘节点地址以及近期(例如1秒内)上报或者检测出的存在异常的拉流地址等，如果拉流地址与地址黑名单中的地址相匹配，则认为拉流地址存在异常，即判定流相关信息存在异常，否则，可认为拉流地址正常。

对于内容分发服务端标识的检测，可结合观看人数来实现，如果观看人数超过第一人数阈值，而内容分发服务端标识的数量小于标识数量阈值，说明该直播间的热度较高，而内容分发压力较大，则可认为内容分发服务端标识存在异常，即CDN业务异常，判定流相关信息存在异常。

对于清晰度集合的检测，可结合观看人数来实现，如果观看人数超过第二人数阈值，而清晰度集合中所包含的清晰度的种类的数量小于第一种类数量阈值，说明该直播间的热度较高，而清晰度种类的选择性较少，不便于不同观看用户根据自己需求选择不同画质的清晰度，则可认为清晰度集合存在异常，即转码业务异常，判定流相关信息存在异常。对于清晰度集合的检测，还可结合直播流码率来实现，如果直播流码率超过码率阈值，而清晰度集合中所包含的清晰度的种类的数量小于第二种类数量阈值，说明没有成功转码，相当于观看用户要直接观看很高的码率，会增加CDN带宽成本，则可认为清晰度集合存在异常，即转码业务异常，判定流相关信息存在异常。

在直播上行过程中，主播用户通常是依据SLA协议进行推流，而在直播下行过程中，观看用户通常是依据HLS协议进行下载与播放，那么对于传输协议信息的检测，可检测传输协议信息中的HLS协议信息与SLA协议信息是否相对齐。例如，SLA协议信息包括有流畅、标清和高清，而HLS协议信息包括有流畅和标清，即与SLA协议信息相比，HLS协议信息缺少了高清这种传输协议，HLS协议信息与SLA协议信息不相对齐，则可认为传输协议信息存在异常，即传输协议业务异常，判定流相关信息存在异常。

可选地，若流相关信息中所有信息都通过检测，则说明流相关信息正常，未存在异常；若流相关信息中的任一信息未通过检测，则说明流相关信息存在异常。

如果检测出流相关信息存在异常，则说明该直播流数据存在异常，需要进行异常修复，那么可确定流相关信息所存在的异常情况信息，并根据直播流数据的标识以及异常情况信息，生成流异常信息。其中，异常情况信息用于反映流相关信息所存在的异常的具体情况内容。直播流数据的标识为用于标识直播流数据的标识信息，可为直播流数据的名称、ID等。流异常信息具体可包括直播流数据的标识以及异常情况信息，根据流异常信息可清楚地获知是哪个直播流数据存在了异常以及异常的具体情况内容，以便根据流异常信息进行异常修复处理。

步骤S204，将流异常信息添加至消息队列中。

在生成了流异常信息之后，将流异常信息添加至消息队列中，通过消息队列实现了对流异常信息的有效管理。并且，在此情况下，直播下行调度服务可不向客户端返回流相关信息。在一种可选的实施方式中，在客户端中可向观看用户展示“加载中”、“请重试”、“请等待一会儿”等提示信息，以使观看用户等待片刻，待异常修复后即可正常观看。在另一种可选的实施方式中，在客户端中也可向观看用户展示用于标识当前直播存在异常或错误的提示信息等。

考虑到针对一个存在异常的直播流数据在短时间内直播下行调度服务会投递大量的用于反映同一异常情况的流异常信息，即这些流异常信息是重复的，那么在本实施例中还设置了消息去重机制，对流异常信息进行去重处理，使得异常处理服务针对相同的流异常信息仅需处理一次。

在一种可选的实施方式中，消息去重机制可以设置在将流异常信息添加至消息队列之前，从而仅将去重后的流异常信息添加至消息队列中。在另一种可选的实施方式中，消息去重机制可以设置在将流异常信息添加至消息队列之后，对消息队列中的流异常信息进行去重处理，以使异常处理服务仅对去重后的流异常信息进行异常修复处理。

具体地，可为流异常信息设置对应的数据键，其中，数据键可以是根据直播流数据的标识以及异常情况信息设置的。例如，可依据异常情况信息确定异常类型，异常类型可包括：转码异常、CDN异常、属于地址黑名单、传输协议未对齐等；数据键key可包括直播流数据的标识以及用于表示异常类型的信息等。可选地，可为数据键设置对应的数据值value，也可不设置数据值value，此处不做限定。当为数据键设置数据值value时，value具体可包括异常情况信息等。

在为流异常信息设置了数据键后，可判断数据库是否包含有相同的数据键。若数据库中包含有该数据键，说明该数据键对应的流异常信息已存在，已经处于处理中，是重复的流异常信息，则可直接忽略该流异常信息。若数据库中未包含有该数据键，说明该数据键对应的流异常信息是一条新的、不重复的流异常信息，则将数据键存储至数据库中，并将流异常信息作为去重后的流异常信息。具体地，数据库可为redis数据库等。

考虑到针对同一直播流数据，其在存在异常并修复后还可能再次发生相同的异常情况，为了有效避免针对同一直播流数据的流异常信息的误去重情况的发生，在本实施例中，数据键可具有过期时间，在到达过期时间时，从数据库中删除数据键，使得数据键并不是永久有效。本领域技术人员可根据实际需要设置过期时间，此处不做限定。例如，过期时间可根据异常修复所需的时长进行设置，若通常异常修复所需的时长为5s，那么可将过期时间设置为5s。

步骤S205，若监听到消息队列中包含有流异常信息，则从消息队列中提取流异常信息，根据流异常信息触发对应的服务模块进行异常修复处理。

异常处理服务监听消息队列，若监听到消息队列中包含有流异常信息，则及时对消息队列中的流异常信息进行异常修复处理，以纠正其所存在的问题。在本实施例中使用信号机制异步触发异常处理服务。具体地，若异常处理服务监听到消息队列中包含有流异常信息，则从消息队列中提取流异常信息，然后异常处理服务根据流异常信息确定异常的具体情况内容，并自动触发用于修复该异常的服务模块对其进行异常修复处理。其中，不同的服务模块用于处理不同异常类型的流异常信息。例如，若异常处理服务根据流异常信息确定是转码异常，则自动触发转码服务模块对其进行异常修复处理，例如触发转码服务模块对该直播流数据进行重新转码。在异常修复完成后，由直播下行调度服务向客户端返回流相关信息，以供客户端根据流相关信息获取对应的直播流数据进行播放。

图3示出了根据本申请另一个实施例的直播异常检测处理方法的流程示意图，如图3所示，在观看用户选定直播间后，客户端会向服务端中的直播下行调度服务发送针对该直播间的流数据获取请求，用于请求获取该直播间的直播流数据进行观看；直播下行调度服务向流状态服务请求该直播流数据的流相关信息，由流状态服务返回直播流数据的流相关信息；然后直播下行调度服务检测流相关信息中的各个信息是否存在异常，图3示意性地展示出直播下行调度服务依次检测流相关信息中的信息a、信息b和信息c是否存在异常；若流相关信息中的任一信息没有检测通过，说明存在异常，则生成流异常信息，并将流异常信息添加至消息队列中，由异常处理服务根据流异常信息进行异常修复处理；若流相关信息中所有信息都检测通过，说明流相关信息是正常的，则直播下行调度服务向客户端返回流相关信息，以供客户端根据流相关信息获取对应的直播流数据进行播放。

根据本申请实施例提供的直播异常检测处理方法，在直播下行过程中增加了直播异常检测功能，通过直播下行调度服务、流状态服务以及异常处理服务等之间的相互协作实现了对异常的直播流数据的及时发现与修复；根据客户端的流数据获取请求被动触发直播下行调度服务进行直播异常检测，当观看用户请求到异常的直播流数据时就能够生成流异常信息并添加至消息队列中；并且，使用信号机制异步触发异常处理服务，异常处理服务可动态地监听消息队列，在监听到消息队列中包含有流异常信息的情况下，自动触发对应的服务模块进行异常修复处理，有效地提高了异常修复的实时性，减少了异常的直播流数据对用户观看体验的不良影响；并且该方案无需定时对直播平台中当前处于直播中的直播流数据进行全量扫描，从而有效地减少了资源消耗。

图4示出了根据本申请一个实施例的直播异常检测处理装置的结构框图，如图4所示，该装置包括：接收模块410、获取模块420和处理模块430。

接收模块410适于：接收流数据获取请求，流数据获取请求用于从直播间获取直播流数据。

获取模块420适于：获取直播流数据的流相关信息。

处理模块430适于：若检测出流相关信息存在异常，则生成流异常信息，并根据流异常信息进行异常修复处理。

其中，流相关信息包括以下信息中的一项或多项：拉流地址、内容分发服务端标识、清晰度集合、直播流码率、观看人数和传输协议信息。

可选地，处理模块430进一步适于：确定流相关信息所存在的异常情况信息，根据直播流数据的标识以及异常情况信息，生成流异常信息。

可选地，处理模块430进一步适于：将流异常信息添加至消息队列中；若监听到消息队列中包含有流异常信息，则从消息队列中提取流异常信息，根据流异常信息触发对应的服务模块进行异常修复处理。

可选地，处理模块430进一步适于：对流异常信息进行去重处理。

可选地，处理模块430进一步适于：为流异常信息设置对应的数据键；若数据库中未包含有数据键，则将数据键存储至数据库中，并将流异常信息作为去重后的流异常信息。

其中，数据键具有过期时间，在到达过期时间时，从数据库中删除数据键。具体地，数据键是根据直播流数据的标识以及异常情况信息设置的。

以上各模块的描述参照方法实施例中对应的描述，在此不再赘述。

根据本申请实施例提供的直播异常检测处理装置，在直播下行过程中增加了直播异常检测功能，根据客户端的流数据获取请求触发直播异常检测，一旦观看用户请求到异常的直播流数据就能够触发异常修复机制，实现了对异常的直播流数据的及时发现与修复；并且该方案无需定时对直播平台中当前处于直播中的直播流数据进行全量扫描，从而有效地减少了资源消耗，优化了直播异常检测处理方式；并且，当观看用户请求到异常的直播流数据时就能够生成流异常信息并添加至消息队列中；使用信号机制异步触发异常处理服务，异常处理服务在监听到消息队列中包含有流异常信息的情况下，自动触发对应的服务模块进行异常修复处理，有效地提高了异常修复的实时性，减少了异常的直播流数据对用户观看体验的不良影响。

本申请实施例还提供了一种非易失性计算机存储介质，计算机存储介质存储有至少一可执行指令，可执行指令可执行上述任意方法实施例中的直播异常检测处理方法。

图5示出了根据本申请实施例的一种计算设备的结构示意图，本申请实施例的具体实施例并不对计算设备的具体实现做限定。

如图5所示，该计算设备可以包括：处理器(processor)502、通信接口(Communications Interface)504、存储器(memory)506、以及通信总线508。

其中：

处理器502、通信接口504、以及存储器506通过通信总线508完成相互间的通信。

通信接口504，用于与其它设备比如客户端或其它服务器等的网元通信。

处理器502，用于执行程序510，具体可以执行上述直播异常检测处理方法实施例中的相关步骤。

具体地，程序510可以包括程序代码，该程序代码包括计算机操作指令。

处理器502可能是中央处理器CPU，或者是特定集成电路ASIC(ApplicationSpecific Integrated Circuit)，或者是被配置成实施本申请实施例的一个或多个集成电路。计算设备包括的一个或多个处理器，可以是同一类型的处理器，如一个或多个CPU；也可以是不同类型的处理器，如一个或多个CPU以及一个或多个ASIC。

存储器506，用于存放程序510。存储器506可能包含高速RAM存储器，也可能还包括非易失性存储器(non-volatile memory)，例如至少一个磁盘存储器。

程序510具体可以用于使得处理器502执行上述任意方法实施例中的直播异常检测处理方法。程序510中各步骤的具体实现可以参见上述直播异常检测处理实施例中的相应步骤和单元中对应的描述，在此不赘述。所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的设备和模块的具体工作过程，可以参考前述方法实施例中的对应过程描述，在此不再赘述。

在此提供的算法和显示不与任何特定计算机、虚拟系统或者其它设备固有相关。各种通用系统也可以与基于在此的示教一起使用。根据上面的描述，构造这类系统所要求的结构是显而易见的。此外，本申请实施例也不针对任何特定编程语言。应当明白，可以利用各种编程语言实现在此描述的本申请实施例的内容，并且上面对特定语言所做的描述是为了披露本申请实施例的最佳实施方式。

在此处所提供的说明书中，说明了大量具体细节。然而，能够理解，本申请实施例可以在没有这些具体细节的情况下实践。在一些实例中，并未详细示出公知的方法、结构和技术，以便不模糊对本说明书的理解。

类似地，应当理解，为了精简本公开并帮助理解各个发明方面中的一个或多个，在上面对本申请实施例的示例性实施例的描述中，本申请实施例的各个特征有时被一起分组到单个实施例、图、或者对其的描述中。然而，并不应将该公开的方法解释成反映如下意图：即所要求保护的本申请实施例要求比在每个权利要求中所明确记载的特征更多的特征。更确切地说，如下面的权利要求书所反映的那样，发明方面在于少于前面公开的单个实施例的所有特征。因此，遵循具体实施方式的权利要求书由此明确地并入该具体实施方式，其中每个权利要求本身都作为本申请实施例的单独实施例。

本领域那些技术人员可以理解，可以对实施例中的设备中的模块进行自适应性地改变并且把它们设置在与该实施例不同的一个或多个设备中。可以把实施例中的模块或单元或组件组合成一个模块或单元或组件，以及此外可以把它们分成多个子模块或子单元或子组件。除了这样的特征和/或过程或者单元中的至少一些是相互排斥之外，可以采用任何组合对本说明书(包括伴随的权利要求、摘要和附图)中公开的所有特征以及如此公开的任何方法或者设备的所有过程或单元进行组合。除非另外明确陈述，本说明书(包括伴随的权利要求、摘要和附图)中公开的每个特征可以由提供相同、等同或相似目的的替代特征来代替。

此外，本领域的技术人员能够理解，尽管在此所述的一些实施例包括其它实施例中所包括的某些特征而不是其它特征，但是不同实施例的特征的组合意味着处于本申请实施例的范围之内并且形成不同的实施例。例如，在下面的权利要求书中，所要求保护的实施例的任意之一都可以以任意的组合方式来使用。

本申请实施例的各个部件实施例可以以硬件实现，或者以在一个或者多个处理器上运行的软件模块实现，或者以它们的组合实现。本领域的技术人员应当理解，可以在实践中使用微处理器或者数字信号处理器(DSP)来实现根据本申请实施例中的一些或者全部部件的一些或者全部功能。本申请实施例还可以实现为用于执行这里所描述的方法的一部分或者全部的设备或者装置程序(例如，计算机程序和计算机程序产品)。这样的实现本申请实施例的程序可以存储在计算机可读介质上，或者可以具有一个或者多个信号的形式。这样的信号可以从因特网网站上下载得到，或者在载体信号上提供，或者以任何其他形式提供。

应该注意的是上述实施例对本申请实施例进行说明而不是对本申请实施例进行限制，并且本领域技术人员在不脱离所附权利要求的范围的情况下可设计出替换实施例。在权利要求中，不应将位于括号之间的任何参考符号构造成对权利要求的限制。单词“包含”不排除存在未列在权利要求中的元件或步骤。位于元件之前的单词“一”或“一个”不排除存在多个这样的元件。本申请实施例可以借助于包括有若干不同元件的硬件以及借助于适当编程的计算机来实现。在列举了若干装置的单元权利要求中，这些装置中的若干个可以是通过同一个硬件项来具体体现。单词第一、第二、以及第三等的使用不表示任何顺序。可将这些单词解释为名称。

Claims (12)

1.一种直播异常检测处理方法，包括：

接收流数据获取请求，所述流数据获取请求用于从直播间获取直播流数据；

获取所述直播流数据的流相关信息；

若检测出所述流相关信息存在异常，则生成流异常信息，并根据所述流异常信息进行异常修复处理。

2.根据权利要求1所述的方法，其中，所述流相关信息包括以下信息中的一项或多项：

拉流地址、内容分发服务端标识、清晰度集合、直播流码率、观看人数和传输协议信息。

3.根据权利要求2所述的方法，其中，所述方法还包括：

若所述拉流地址与预先设置的地址黑名单中的地址相匹配，则判定所述流相关信息存在异常；和/或，

若所述观看人数超过第一人数阈值且所述内容分发服务端标识的数量小于标识数量阈值，则判定所述流相关信息存在异常；和/或，

若所述观看人数超过第二人数阈值且所述清晰度集合中所包含的清晰度的种类的数量小于第一种类数量阈值，则判定所述流相关信息存在异常；和/或，

若所述直播流码率超过码率阈值且所述清晰度集合中所包含的清晰度的种类的数量小于第二种类数量阈值，则判定所述流相关信息存在异常；和/或，

若所述传输协议信息中的HLS协议信息与SLA协议信息不相对齐，则判定所述流相关信息存在异常。

4.根据权利要求1-3任一项所述的方法，其中，所述生成流异常信息进一步包括：

确定所述流相关信息所存在的异常情况信息，根据所述直播流数据的标识以及所述异常情况信息，生成流异常信息。

5.根据权利要求1-4任一项所述的方法，其中，所述根据所述流异常信息进行异常修复处理进一步包括：

将所述流异常信息添加至消息队列中；

若监听到所述消息队列中包含有流异常信息，则从所述消息队列中提取所述流异常信息，根据所述流异常信息触发对应的服务模块进行异常修复处理。

6.根据权利要求5所述的方法，其中，所述方法还包括：对所述流异常信息进行去重处理。

7.根据权利要求6所述的方法，其中，所述对所述流异常信息进行去重处理进一步包括：

为所述流异常信息设置对应的数据键；

若数据库中未包含有所述数据键，则将所述数据键存储至数据库中，并将所述流异常信息作为去重后的流异常信息。

8.根据权利要求7所述的方法，其中，所述数据键具有过期时间；所述方法还包括：

在到达所述过期时间时，从所述数据库中删除所述数据键。

9.根据权利要求7或8所述的方法，其中，所述数据键是根据所述直播流数据的标识以及异常情况信息设置的。

10.一种直播异常检测处理装置，包括：

接收模块，适于接收流数据获取请求，所述流数据获取请求用于从直播间获取直播流数据；

获取模块，适于获取所述直播流数据的流相关信息；

处理模块，适于若检测出所述流相关信息存在异常，则生成流异常信息，并根据所述流异常信息进行异常修复处理。

11.一种计算设备，包括：处理器、存储器、通信接口和通信总线，所述处理器、所述存储器和所述通信接口通过所述通信总线完成相互间的通信；

所述存储器用于存放至少一可执行指令，所述可执行指令使所述处理器执行如权利要求1-9中任一项所述的直播异常检测处理方法对应的操作。

12.一种计算机存储介质，所述存储介质中存储有至少一可执行指令，所述可执行指令使处理器执行如权利要求1-9中任一项所述的直播异常检测处理方法对应的操作。

Images