CN113094239B - 直播异常原因的确定方法及服务器 - Google Patents

Abstract

本申请提供直播异常原因的确定方法及服务器，其中所述直播异常原因的确定方法包括：在满足服务端检测条件的情况下，获取边缘节点中的直播流，根据所述直播流的质量，确定直播异常是否包括第一参考原因；从卡顿统计***中获取用户端上报的卡顿信息，根据所述卡顿信息，确定直播异常是否包括第二参考原因；在确定出所述直播异常包括所述第一参考原因和/或所述第二参考原因的情况下，根据所述第一参考原因和/或所述第二参考原因，确定所述直播异常的服务端原因。如此，可以在短时间内快速准确确定出直播异常的服务端原因，大大节省处理时间，提高了确定直播异常的原因的效率，从而提高了直播异常的响应速度。

Description

直播异常原因的确定方法及服务器

技术领域

本申请涉及直播技术领域，特别涉及一种直播异常原因的确定方法。本申请同时涉及一种直播异常原因的确定服务器，一种计算设备，以及一种计算机可读存储介质。

背景技术

随着计算机技术和网络技术的快速发展，各种各样的直播在人们的工作、生活、娱乐中愈发普及。在现有直播体系中，从主播端推流到用户端拉流的链路很长，影响的因素繁多，任何一个环节出现问题，均可能会导致用户观看的直播卡顿或者无法观看。

现有技术中，用户在观看的直播卡顿或者无法观看的情况下，会联系客服反馈问题，然后客服录入反馈工单，等待相关研发人员给出结论，再由客服反馈给用户。然而，造成直播卡顿或无法观看的流程复杂，需要研发人员一一排除各个环节，最后确定出直播异常的原因，由于研发人员并非能时刻处理相关反馈，因而客服和用户均需要等待反馈结果，处理时间长，导致确定直播异常的原因的效率较低，从而影响直播异常的响应速度，且对于研发人员的能力要求较高，人工成本较高。

发明内容

有鉴于此，本申请实施例提供了一种直播异常原因的确定方法。本申请同时涉及一种直播异常原因的确定服务器，一种计算设备，以及一种计算机可读存储介质，以解决现有技术中存在的确定直播异常的原因的效率较低的问题。

根据本申请实施例的第一方面，提供了一种直播异常原因的确定方法，包括：

在满足服务端检测条件的情况下，获取边缘节点中的直播流，根据所述直播流的质量，确定直播异常是否包括第一参考原因；

从卡顿统计***中获取用户端上报的卡顿信息，根据所述卡顿信息，确定直播异常是否包括第二参考原因；

在确定出所述直播异常包括所述第一参考原因和/或所述第二参考原因的情况下，根据所述第一参考原因和/或所述第二参考原因，确定所述直播异常的服务端原因。

根据本申请实施例的第二方面，提供了一种直播异常原因的确定服务器，包括：

第一获取模块，被配置为在满足服务端检测条件的情况下，获取边缘节点中的直播流，根据所述直播流的质量，确定直播异常是否包括第一参考原因；

第二获取模块，被配置为从卡顿统计***中获取用户端上报的卡顿信息，根据所述卡顿信息，确定直播异常是否包括第二参考原因；

第一确定模块，被配置为在确定出所述直播异常包括所述第一参考原因和/或所述第二参考原因的情况下，根据所述第一参考原因和/或所述第二参考原因，确定所述直播异常的服务端原因。

根据本申请实施例的第三方面，提供了一种计算设备，包括：

存储器和处理器；

所述存储器用于存储计算机可执行指令，所述处理器用于执行所述计算机可执行指令，以实现下述方法：

在满足服务端检测条件的情况下，获取边缘节点中的直播流，根据所述直播流的质量，确定直播异常是否包括第一参考原因；

从卡顿统计***中获取用户端上报的卡顿信息，根据所述卡顿信息，确定直播异常是否包括第二参考原因；

在确定出所述直播异常包括所述第一参考原因和/或所述第二参考原因的情况下，根据所述第一参考原因和/或所述第二参考原因，确定所述直播异常的服务端原因。

根据本申请实施例的第四方面，提供了一种计算机可读存储介质，其存储有计算机可执行指令，该计算机可执行指令被处理器执行时实现任意所述直播异常原因的确定方法的步骤。

本申请提供的直播异常原因的确定方法，在满足服务端检测条件的情况下，获取边缘节点中的直播流，根据所述直播流的质量，确定直播异常是否包括第一参考原因；从卡顿统计***中获取用户端上报的卡顿信息，根据所述卡顿信息，确定直播异常是否包括第二参考原因；在确定出所述直播异常包括所述第一参考原因和/或所述第二参考原因的情况下，根据所述第一参考原因和/或所述第二参考原因，确定所述直播异常的服务端原因。这种情况下，可以综合边缘节点和卡顿统计***中的数据，自动化处理判断主播端推流到用户端拉流的链路中，可能出现的服务端异常，从而在短时间内快速确定出直播异常的服务端原因，给出反馈结果，大大节省处理时间，提高了确定直播异常的原因的效率，从而提高了直播异常的响应速度，无需研发人员一一排除各个环节，降低对于研发人员的能力要求，节省了人工成本。另外，由于可以结合卡顿统计***中多个用户端上报的卡顿信息，分析确定服务端存在的异常，从而可以从多个用户端的角度分析直播出现问题的实质原因，从根本解决投诉问题，提高了确定直播异常的原因的准确性，进而可以及时处理服务端出现的异常，避免大部分用户反馈相同的异常。

附图说明

图1是本申请一实施例提供的一种直播异常原因的确定方法的流程图；

图2是本申请一实施例提供的一种主播推流的整体链路示意图；

图3是本申请一实施例提供的一种直播异常原因的确定过程的示意图；

图4是本申请一实施例提供的另一种直播异常原因的确定方法的流程图；

图5是本申请一实施例提供的一种直播异常原因的确定服务器的结构示意图；

图6是本申请一实施例提供的一种计算设备的结构框图。

具体实施方式

在下面的描述中阐述了很多具体细节以便于充分理解本申请。但是本申请能够以很多不同于在此描述的其它方式来实施，本领域技术人员可以在不违背本申请内涵的情况下做类似推广，因此本申请不受下面公开的具体实施的限制。

在本申请一个或多个实施例中使用的术语是仅仅出于描述特定实施例的目的，而非旨在限制本申请一个或多个实施例。在本申请一个或多个实施例和所附权利要求书中所使用的单数形式的“一种”、“所述”和“该”也旨在包括多数形式，除非上下文清楚地表示其他含义。还应当理解，本申请一个或多个实施例中使用的术语“和/或”是指并包含一个或多个相关联的列出项目的任何或所有可能组合。

应当理解，尽管在本申请一个或多个实施例中可能采用术语第一、第二等来描述各种信息，但这些信息不应限于这些术语。这些术语仅用来将同一类型的信息彼此区分开。例如，在不脱离本申请一个或多个实施例范围的情况下，第一也可以被称为第二，类似地，第二也可以被称为第一。取决于语境，如在此所使用的词语“如果”可以被解释成为“在……时”或“当……时”或“响应于确定”。

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

直播流：直播音视频数据的传输，它能够被作为一个稳定的和连续的流通过网络传输给观众观看。

推流：主播通过主播端从直播平台获取到推流地址，将采集的流媒体通过推流地址实时地推送至直播平台的接收端。

拉流：拉流是指通过直播云平台到用户指定的源站拉取直播流的过程。

CDN(Content DeliveryNetwork，内容分发网络)：是构建在网络之上的内容分发网络，CDN的基本原理是广泛采用各种缓存服务器，将这些缓存服务器分布到用户访问相对集中的地区或网络中，在用户访问网站时，利用全局负载技术将用户的访问指向距离最近的工作正常的缓存服务器上，由缓存服务器直接响应用户请求，提高用户访问响应速度和命中率。CDN的关键技术主要有内容存储技术、内容分发技术和负载均衡技术。

码率：就是数据传输时单位时间传送的数据位数，码率也叫比特率，表示经过压缩编码后的音视频数据每秒需要用多少个比特来表示，即把每秒显示的图像进行压缩后的数据量，一般采用的单位是kbps即千位每秒。通俗一点的理解就是取样率，单位时间内取样率越大，精度就越高，处理出来的文件就越接近原始文件，也就是说画面的细节就越丰富。

边缘运算：又称为边缘计算，是一种分散式运算架构，将应用程序、数据资料与服务的运算，由网络中心节点，移往网络逻辑上的边缘节点来处理。也即，边缘运算可以将原本完全由中心节点处理大型服务加以分解，切割成更小与更易管理的部分，分散到边缘节点去处理。边缘节点更接近用户终端装置，可以加快资料的处理与传送速度，减少延迟。本申请中边缘节点可以为部署在全国各地的小型推流节点，成本低。

DNS解析：是把域名指向网站空间IP，使得通过注册的域名可以方便地访问到网站的一种服务。人们习惯记忆域名，但机器间互相只认IP地址，域名与IP地址之间是一一对应的，它们之间的转换工作称为域名解析，域名解析需要由专门的域名解析服务器来完成，整个过程是自动进行的。

其次，对本申请的应用场景进行介绍。

在现有直播体系中，从主播端推流到用户端拉流的链路很长，影响的因素繁多，任何一个环节出现问题，均会导致用户观看的直播卡顿或者无法观看。用户在直播卡顿或者无法观看的情况下，会联系客服反馈问题，因而如何及时处理用户的各种反馈，针对不同的反馈响应不同的结果，对于优化用户体验，及时发现隐患，有重大作用。

在当前的客服处理流程中，一般是用户通过自己持有的用户端将问题反馈给客服，客服录入反馈工单，等待相关研发人员给出结论，再由客服反馈给用户。

然而，造成直播卡顿或无法观看的流程复杂，需要研发人员一一排除各个环节，最后确定出直播异常的原因，由于研发人员并非能时刻处理相关反馈，因而客服和用户均需要等待反馈结果，处理时间长，导致确定直播异常的原因的效率较低，从而影响直播异常的响应速度，且对于研发人员的能力要求较高，人工成本较高。

另外，单个用户端反馈后，针对单个用户端反馈的问题进行排查分析，只能简单发现并解决单个用户端所遇到的问题，但若是推流过程中的某个环节出现了问题，影响的可能是大部分用户，因而针对单个用户端的反馈，进行分析，确定直播异常的原因，往往不具有普遍性，无法确定出直播异常的实质原因，导致无法及时响应并解决实质问题，从而带来一定的损失。

因而，本申请中可以自动对接客服反馈工单，利用用户反馈日志，结合卡顿统计***，自动化处理判断直播的每个环节，实时统计分析各个环节是否存在异常，如此可以综合评判影响因素，发现导致卡顿的实质原因，从而在短时间内给出反馈结果，并降低大面积反馈。

在本申请中，提供了一种直播异常原因的确定方法，本申请同时涉及一种直播异常原因的确定服务器，一种计算设备，以及一种计算机可读存储介质，在下面的实施例中逐一进行详细说明。

图1示出了根据本申请一实施例提供的一种直播异常原因的确定方法的流程图，具体包括以下步骤：

步骤102：在满足服务端检测条件的情况下，获取边缘节点中的直播流，根据所述直播流的质量，确定直播异常是否包括第一参考原因。

具体的，服务端检测条件是指需要检测分析服务端是否出现异常的条件，由于如果用户端未确定出异常，则大概率是服务端出现了异常，导致直播卡顿，因而在未确定出用户端异常的情况下，则说明满足服务端检测条件，可以进一步对服务端进行深层次的检测，即服务端检测条件可以为未确定出用户端存在异常；或者，若短时间内存在大量用户反馈异常，则说明大概率可能是服务端出现了异常，影响了大面积的用户端，此时说明满足服务端检测条件，可以进一步对服务端进行深层次的检测，即服务端检测条件可以为预设时长内发起异常反馈的用户数量过多。

图2是本申请一实施例提供的一种主播推流的整体链路示意图，如图2所示，主播端将采集到的多媒体数据推流至边缘节点1(对应链路1)，边缘节点1将接收到的直播流分别转推至CDNA(对应链路2)和CDN B(对应链路3)。CDNA中的边缘节点A1进行内部转推，即边缘节点A1将直播流内部转推给服务节点A2(对应链路4a)和服务节点A3(对应链路4b)，就近服务用户的拉流，服务节点A2中的直播流供用户1观看(即用户1对应的用户端拉流，对应链路5)，服务节点A3中的直播流供用户2观看(即用户2对应的用户端拉流，对应链路6)。CDN B中的边缘节点B1进行内部转推，即边缘节点B1将直播流内部转推给服务节点B2(对应链路4c)和服务节点B3(对应链路4d)，服务节点B2中的直播流供用户3观看(即用户3对应的用户端拉流，对应链路7)，服务节点B3中的直播流供用户4观看(即用户4对应的用户端拉流，对应链路8)。

需要说明的是，从如图2所示的链路中可以确定从主播端推流到用户端观看，可能影响直播的因素有用户端自身的问题：(1)用户端DNS解析异常，无法解析获取CDN中的服务节点，从而导致无法观看直播；(2)用户端网络存在异常，网速太差，不足够支持直播观看的带宽，最后引起直播卡顿，即图2中的链路5、6、7、8；(3)用户端性能较差，用户使用的用户端设备老化或设备性能较差，导致编解码异常，进而导致直播卡顿。非用户端问题：(4)主播端推流网络存在问题，推流网络太差，导致推上的流数据质量有问题，从而导致用户观看的直播存在问题，即图2中的链路1；(5)边缘节点转推到CDN节点的网络存在问题，即图2中的链路2；(6)CDN服务节点存在问题，即图2中的服务节点A2、A3、B2、B3；(7)用户端所在区域问题，用户端所在的省份运营商(多为小运营商)出现了问题，导致大面积网络不可用；(8)转码流存在问题，用户端观看的直播流为转码流，用户拉流后，若码率过高，观看人数较多，则主播端则会开启转码，提供多路清晰度以供选择，在用户端拉流没有问题的情况下，转码流导致观看的直播卡顿，则可能是转码流存在问题；(9)CDN服务商存在问题，接入多个CDN服务商后，单个CDN服务商，亦会存在CDN的拉流观看服务出现问题，从而大范围影响用户观看。

实际应用中，用户在观看的直播卡顿或者无法观看的情况下，会通过使用的用户端向客服反馈自己观看直播遇到了问题，客服接收到用户端的反馈后，可以引导用户通过使用的用户端提交卡顿日志，并由客服主动发起确定直播异常的原因的流程，该流程可以分为2大部分，其一是对用户端进行分析，确定用户端是否存在异常，其二是更深层次的服务端分析，确定服务端的各个环节是否存在异常，最后综合评判，确定出导致直播卡顿的实质原因。

本实施例一个可选的实施方式中，在进行更深层次的服务端分析之前，还可以先对反馈异常的用户端进行分析，确定该用户端是否存在异常，也即在满足服务端检测条件的情况下，获取边缘节点中的直播流之前，还包括：

在接收到异常检测请求的情况下，获取所述异常检测请求对应的目标用户端的日志数据；

根据所述日志数据，对所述目标用户端进行分析。

具体的，异常检测请求可以是客服通过预设操作发起的请求，该异常检测请求可以使得中心服务自动对接客服反馈工单，获取向客服反馈异常的目标用户端的日志数据，从而对该目标用户端的日志数据进行分析，确定该目标用户端是否存在异常。其中，预设操作可以为检测控件的点击操作，目标用户端可以是指向客服反馈异常的用户端。

需要说明的是，用户在通过自己持有的目标用户端观看直播时，如果出现直播卡顿或者无法观看的情况，则用户可以通过自己持有的目标用户端，向客服反馈异常情况，客服可以引导该目标用户端提交卡顿的日志数据，然后客服可以通过预设操作发起异常检测请求，客服在发起异常检测请求时，可以在该异常检测请求中携带反馈异常的目标用户端的标识，从而使得中心服务可以获取所述异常检测请求对应的目标用户端的日志数据，进行分析，从而确定目标用户端是否存在异常。

另外，除了用户端向客服反馈异常，再由客服发起异常检测请求外，还可以由用户端直接向中心服务反馈异常，即由用户端发起异常检测请求，并提交自身直播卡顿的日志数据，从而使得中心服务直接对该日志数据进行分析，确定目标用户端是否存在异常。

本实施例一个可选的实施方式中，中心服务可以预先和用户端的播放器约定好各种异常对应的异常字段，当用户端的播放器监测到用户端播放直播的过程中出现了某个异常，此时可以在用户端的日志数据中加入相应的异常字段，中心服务在获取到日志数据后，只需查找是否存在异常字段，即可确定用户端是否存在异常，也即根据所述日志数据，对所述目标用户端进行分析，具体实现过程可以如下：

确定所述日志数据中是否存在预设异常字段；

在所述日志数据中存在所述预设异常字段的情况下，根据所述异常字段，确定并反馈所述直播异常的用户端原因。

需要说明的是，预设异常字段是中心服务预先和用户端的播放器约定好的各种异常对应的字段。示例的，用户端网络异常对应的预设异常字段为AA，用户端DNS解析异常对应的预设异常字段为BB，用户端性能较差对应的预设异常字段为CC。

实际应用中，中心服务获取到目标用户端提交的日志数据后，可以自动对该日志数据进行查找分析，确定日志数据中是否存在预设异常字段，在查找到预设异常字段的情况下，确定目标用户端存在异常，且可以根据该异常字段确定出目标用户端存在的具体异常(即直播异常的用户端原因)，并根据该具体异常原因进行记录反馈。

需要说明的是，若针对目标用户端，确定出了直播异常的用户端原因，则说明目标用户端存在异常，此时可以对确定出的目标用户端存在的具体异常进行汇总记录，并可以提供相应的解决措施。如此，一个用户端提交直播投诉，根据对日志数据的分析，确定异常情况为用户端异常，则可以直接向该用户端反馈异常报告，告知异常原因，及时响应并解决该投诉，以提高投诉响应速度，减少由于响应不及时或者自身网络原因导致的重复投诉。

沿用上例，查找到的预设异常字段为AA，则说明目标用户端网络存在异常，记录目标用户端的分析结果为网络问题；若查找到的预设异常字段为BB，则说明目标用户端DNS解析异常，记录目标用户端的分析结果为DNS解析问题；若查找到的预设异常字段为CC，则说明目标用户端性能较差，记录目标用户端的分析结果为设备问题，建议切换设备。

本实施例一个可选的实施方式中，在满足服务端检测条件的情况下，获取边缘节点中的直播流之前，还包括：

在所述日志数据中不存在所述预设异常字段的情况下，确定满足所述服务端检测条件。

需要说明的是，在所述日志数据中不存在所述预设异常字段的情况下，说明目标用户端不存在异常，此时大概率是服务端出现了异常，导致直播卡顿，此时需要进一步深层次的分析服务端是否存在异常，即此时满足服务端检测条件。

本实施例一个可选的实施方式中，在满足服务端检测条件的情况下，获取边缘节点中的直播流之前，还包括：

确定当前时间之前预设时长内接收到的异常检测请求的数量；

在所述异常检测请求的数量超过异常数量阈值的情况下，确定满足所述服务端检测条件。

具体的，预设时长是指预先设置的时长，该预设时长一般设置的较短，可以为1分钟、2分钟、3分钟等；异常数量阈值是预先设置的数值，该异常数量阈值用于判断预设时长内接收到的异常检测请求是否过量，如异常数量阈值可以为50个、100个、500个等。

需要说明的是，在接收到单一的目标用户端反馈异常后，若已经确定出该目标用户端存在异常，则可以直接反馈给目标用户端。另外，无论是否确定出目标用户端存在异常，若在预设时长内接收到大量的异常检测请求，则说明在短时间内，存在大量的用户在观看直播时出现了问题，此时极有可能是服务端出现了异常，影响了大面积的用户端，因而此时确定满足服务端检测条件，后续可以进一步深层次的分析服务端是否存在异常。

本实施例一个可选的实施方式中，边缘节点用于接收主端播推送的直播流，并将接收到的直播流转推给相应的内容分发网络中的节点，因而边缘节点中存在两种直播流，可以根据该两种直播流的质量确定相应的节点是否存在异常，也即获取边缘节点中的直播流，根据所述直播流的质量，确定直播异常是否包括第一参考原因，包括以下至少任一项：

获取所述边缘节点接收到的直播流，在所述接收到的直播流的质量低于质量阈值的情况下，确定所述直播异常包括所述第一参考原因，且所述第一参考原因为主播端网络异常；

获取所述边缘节点发送的直播流，在所述发送的直播流的质量低于质量阈值的情况下，确定所述直播异常包括所述第一参考原因，且所述第一参考原因为所述边缘节点异常。

具体的，边缘节点是指接收主播端推流的节点，该边缘节点可以将接收到的直播流转推给不同的内容分发网络(CDN)。另外，直播流的质量可以是指直播流的清晰度，也可以是指直播流的流畅度，当然还可以为其他可以表示直播流质量的参数，本申请对此不进行限制；质量阈值可以是指预先设置的数值，该质量阈值用于判断直播流的质量是否较差，不同的质量衡量标准，可以对应有不同的质量阈值。

需要说明的是，可以根据边缘节点接收到的直播流的质量确定主播端推流的过程是否存在异常，在边缘节点接收到的直播流的质量低于质量阈值的情况下，说明主播端向边缘节点推送的直播流的质量较差，此时说明主播端推流网络可能存在问题，因而确定出直播异常的第一参考原因为主播端网络异常。

另外，可以根据边缘节点转推出去的直播流的质量确定边缘节点推送直播流的过程是否存在异常，在边缘节点转推出去的直播流的质量低于质量阈值的情况下，说明边缘节点转推出去的直播流的质量较差，此时说明边缘节点可能存在问题，因而确定出直播异常的第一参考原因为边缘节点异常。

本申请中可以在满足服务端检测条件的情况下，获取边缘节点中接收到的直播流和/或发送出去的直播流，然后根据获取到的直播流的质量，确定主播端是否存在异常，和/或边缘节点是否存在异常，从而自动、高效、准确地确定直播异常的服务端原因。

步骤104：从卡顿统计***中获取用户端上报的卡顿信息，根据所述卡顿信息，确定直播异常是否包括第二参考原因。

需要说明的是，用户端中的直播播放器可以自动监控用户的每次观看行为，若用户观看过程中直播发生卡顿，则用户端可以自动向卡顿统计***上报卡顿信息，上报的卡顿信息中可以包括：观看的直播流、观看时间、拉流对应的内容分发网络中的服务节点、内容分发网络的服务商、用户端访问直播使用的运营商、用户端所处区域等。

另外，卡顿统计***在接收到各个用户端上报的卡顿信息后，还可以从不同的维度，计算对应的卡顿率，其中，卡顿率等于单位时间卡顿次数除以播放时长。

本实施例一个可选的实施方式中，每个用户端在直播卡顿或者无法观看时，均会向卡顿统计***上报卡顿信息，因而卡顿统计***中可以存储有各个用户端上报的卡顿信息，在需要对服务端进行分析，确定服务端是否出现异常时，可以通过从卡顿统计***中获取相应的卡顿信息，从而确定出相应节点是否存在异常，也即从卡顿统计***中获取用户端上报的卡顿信息，并根据所述卡顿信息，确定直播异常是否包括第二参考原因，包括以下至少任一项：

确定所述用户端访问的内容分发网络中的目标服务节点，从所述卡顿统计***中获取预设统计周期内针对所述目标网络节点的卡顿上报数量，在所述卡顿上报数量大于上报阈值的情况下，确定所述直播异常包括所述第二参考原因，且所述第二参考原因为所述目标服务节点异常；

在确定出所述用户端访问的直播流为转码得到的目标码率直播流的情况下，从所述卡顿统计***中获取预设统计周期内源码率直播流的卡顿率以及所述目标码率直播流的卡顿率，在所述目标码率直播流的卡顿率与所述源码率直播流的卡顿率之间的卡顿率差值大于差值阈值的情况下，确定所述直播异常包括所述第二参考原因，且所述第二参考原因为所述目标码率直播流异常；

确定所述用户端访问直播时所处区域和运营商，从所述卡顿统计***中获取当前预设统计周期所述区域对应的卡顿率，计算所述当前预设统计周期相对于上一预设统计周期的卡顿增长率，在所述卡顿增长率大于增长率阈值的情况下，确定所述直播异常包括所述第二参考原因，且所述第二参考原因为运营商异常；

确定所述用户端访问的内容分发网络服务商，从所述卡顿统计***中获取当前预设统计周期所述内容分发网络服务商对应的卡顿率，计算所述当前预设统计周期相对于上一预设统计周期的卡顿增长率，在所述卡顿增长率大于增长率阈值的情况下，确定所述直播异常包括所述第二参考原因，且所述第二参考原因为内容分发网络服务商异常。

具体的，服务节点是指内容分发网络中向用户端提供直播流的节点。预设统计周期是预先设置的时间段，可以通过对该时间段内的卡顿信息的分析，确定是否有节点存在异常，如预设统计周期可以为5分钟、10分钟，或者1小时、2小时等。另外，源码率直播流是指主播端推送的码率的直播流，目标码率直播流为源码率直播流转码得到的直播流。

此外，上报阈值可以是指预先设置的数值，该数值用于判断一段时间内针对某个服务节点的卡顿上报数量是否过量，从而确定该服务节点是否存在异常。差值阈值可以是指预先设置的数值，该数值用于判断一段时间内转码得到的目标码率直播流的卡顿率是否远大于源码率直播流的卡顿率，从而确定转码得到的该目标码率直播流是否存在异常。

需要说明的是，由于预设统计周期内卡顿统计***会接收到多个用户端上报的卡顿信息，因而可以分不同维度，对卡顿统计***中各个用户端上报的卡顿信息进行分析，从而从不同维度确定直播异常的原因。

实际应用中，若针对内容分发网络中的某个目标服务节点，出现了大量的卡顿上报，此时大概率说明该目标服务节点存在问题，因而可以确定出直播异常的第二参考原因为目标服务节点异常。

沿用上例，如图2所示，中心服务读取到用户端访问CDN中的服务节点A2，然后可以从卡顿统计***中查询，在预设统计周期内，针对服务节点A2是否出现大量的卡顿上报，若是，则说明服务节点A2存在异常，访问到该服务节点的用户端都存在问题。

另外，用户端拉流后，若码率过高，观看人数较多，主播端则会开启转码，提供多路清晰度以供选择，在用户端拉的源流没有问题的情况下，可能是转码流导致观看的直播卡顿，因而在确定出用户端访问的直播流为转码得到的目标码率直播流时，可以从卡顿统计***中获取预设统计周期内源码率直播流的卡顿率以及目标码率直播流的卡顿率，从而确定目标码率直播流的卡顿率是否远远大于源码率直播流的卡顿率，若是，则说明转码后得到的目标码率直播流出现了异常，即确定出的直播异常的第二参考原因为目标码率直播流异常。

再者，中心服务还可以读取所述用户端在访问直播时使用的运营商，并确定该用户端在访问直播时所处的区域，然后从卡顿统计***中查询，在当前预设统计周期内该区域的所有直播流的卡顿率，并确定上一预设统计周期内该区域的所有直播流的卡顿率，从而计算得到该区域内的卡顿增长率，若卡顿增长率在当前预设统计周期内发生陡增，则说明当前预设统计周期内，该运营商的服务出现了问题，即确定出的直播异常的第二参考原因为运营商异常。

此外，若一段时间内针对某个内容分发网络服务商上报的卡顿率陡增，则大概率说明该内容分发网络服务商存在问题，因而中心服务还可以从卡顿统计***中查询，在当前预设统计周期内所有由该内容分发网络服务商提供观看服务上报的卡顿率，以及上一预设统计周期内所有由该内容分发网络服务商提供观看服务上报的卡顿率，从而计算得到该内容分发网络服务商的卡顿增长率，若卡顿增长率在当前预设统计周期内发生陡增，则说明当前预设统计周期内，该内容分发网络服务商的服务可能出现了问题，即确定出的直播异常的第二参考原因为内容分发网络服务商异常。

本申请中可以在满足服务端检测条件的情况下，分不同维度对卡顿统计***中各个用户端上报的卡顿信息进行分析统计，从不同维度确定直播异常的原因，从而自动、高效、准确地确定直播异常的服务端原因。

需要说明的是，上述步骤104在步骤102后描述，只是一种示例的描述顺序，实际应用中，上述步骤102中的获取边缘节点中的直播流，根据所述直播流的质量，确定直播异常的第一参考原因，以及步骤104中的从卡顿统计***中获取用户端上报的卡顿信息，根据所述卡顿信息，确定直播异常的第二参考原因，在执行上可以不存在先后顺序关系，并发执行，也可以为顺序检测，即先执行步骤102，再执行步骤104，当然也可以为先执行步骤104，再执行步骤102，本申请对此不进行限定。

步骤106：在确定出所述直播异常包括所述第一参考原因和/或所述第二参考原因的情况下，根据所述第一参考原因和/或所述第二参考原因，确定所述直播异常的服务端原因。

本实施例一个可选的实施方式中，根据所述第一参考原因和/或所述第二参考原因，确定所述直播异常的服务端原因，具体实现过程可以如下：

合并所述第一参考原因和/或所述第二参考原因；

将合并后的所述第一参考原因和/或所述第二参考原因确定为所述直播异常的服务端原因。

需要说明的是，根据边缘节点可以确定出直播异常是否包括第一参考原因，根据卡顿统计***中用户端上报的卡顿信息，可以确定出直播异常是否包括第二参考原因，在确定出所述直播异常包括所述第一参考原因和/或所述第二参考原因的情况下，可以直接将确定出的全部参考原因作为最后的直播异常的服务端原因，进行反馈和处理。

本实施例一个可选的实施方式中，根据所述第一参考原因和/或所述第二参考原因，确定所述直播异常的服务端原因，具体实现过程可以如下：

确定所述第一参考原因和/或所述第二参考原因中的目标参考原因；

将所述目标参考原因确定为所述直播异常的服务端原因。

需要说明的是，确定出的不同的第一参考原因和/或第二参考原因，其能够影响的用户端数量不同，即直播异常的影响程度是不同的，因而在确定出所述直播异常包括所述第一参考原因和/或所述第二参考原因的情况下，可以将反应直播异常程度最深的目标参考原因，确定为最后的直播异常的服务端原因。

示例的，确定出了第二参考原因为运营商异常，并且进一步确定出了第二参考原因为内容分发网络服务商异常，由于运营商异常影响的是使用该运营商的用户端，而内容分发网络服务商异常则影响的是使用该内容分发网络服务商提供服务的全部用户端(不限制运营商)，内容分发网络服务商异常对直播过程的影响程度更深，因而运营商异常可能是表象，而内容分发网络服务商异常才是实质，此时可以将内容分发网络服务商异常确定为最后的直播异常的服务端原因，进行反馈和处理。

本实施例一个可选的实施方式中，根据所述第一参考原因和/或所述第二参考原因，确定所述直播异常的服务端原因，包括：

在确定出直播异常包括任一所述第一参考原因或所述第二参考原因的情况下，停止继续执行确定直播异常是否包括其他所述第一参考原因或所述第二参考原因的操作步骤；

将确定出的直播异常包括的所述第一参考原因或所述第二参考原因确定为所述直播异常的服务端原因。

需要说明的是，在确定出直播异常包括任一参考原因时，可以停止继续检测，即若匹配到服务端存在任一异常后，停止再继续检测服务端是否存在其他异常。将确定出的参考原因作为最后的直播异常的服务端原因，进行反馈和处理。

进一步地，在确定出直播异常的用户端原因和服务端原因后，还可以根据不同的原因，采取不同的处理措施，进行不同的反馈。具体实现时，若确定出单个用户端存在异常，则可以为单个用户端提供相应的报告，提高投诉响应速度，减少由于响应不及时或者自身网络原因导致的重复投诉。

若确定出直播异常的服务端原因为主播端网络异常，则可以向客服返回主播端推流异常，并通知客服联系主播，调整推流质量；若确定出直播异常的服务端原因为边缘节点异常，则可以由中心服务主动通知边缘计算节点，断开转推，重新发起连接，并向客服返回已经处理，请用户刷新重试；若确定出直播异常的服务端原因为目标服务节点异常，则自动将目标服务节点反馈给内容分发网络服务商，通知对方摘除异常服务节点，并向客服返回已经处理，请用户刷新重试。

若确定出直播异常的服务端原因为目标码率直播流异常，则自动将该目标码率直播流异常的信息反馈给开发人员，同时向客服返回建议用户切换清晰度观看；若确定出直播异常的服务端原因为运营商异常，则向客服返回建议用户联系运营商解决，或切换网络；若确定出直播异常的服务端原因为内容分发网络服务商异常，则可以通知内容分发网络服务商确定服务是否正常，并向客服返回内容分发网络服务商异常，请稍后重试。

本实施例一个可选的实施方式中，根据所述第一参考原因和/或所述第二参考原因，确定所述直播异常的服务端原因之后，还包括：

记录确定出所述直播异常的服务端原因的异常确定时间；

在接收到新异常检测请求的情况下，确定所述新异常检测请求的接收时间；

确定所述接收时间和所述异常确定时间之间的时间差值是否小于时间阈值；

若是，则根据确定出的所述直播异常的服务端原因，确定所述新异常检测请求对应的异常原因。

具体的，时间阈值是指预先设置的数值，用于判断接收到的新异常检测请求与异常确定时间是否相差较大，即接收到的新异常检测请求是否是在预设时长内接收到的。

需要说明的是，当将直播异常的原因定位到上述某一服务端原因后，对于预设时长内新接收到的用户反馈或投诉，则可以在确定用户端是否存在异常以后，优先检测上述所定位的这一服务端原因问题，以提高检测效率。

示例的，若根据若干用户端的反馈，定位直播异常的原因为内容分发网络服务商异常，在10分钟内(即预设时长)新收到用户反馈后，首先对新收到的用户反馈对应的用户端进行检测，若用户端不存在异常，则优先对内容分发网络服务商是否异常进行检测。

接下来，结合附图3对上述直播异常确定方法的整体流程进行示意性说明，图3是本申请一实施例提供的一种直播异常原因的确定过程的示意图。如图3所示，客服发起检测流程后，第一部分可以检测用户端问题，包括确定是否包含设备异常字段、确定是否包含网络异常字段、确定是否包含DNS解析异常字段。第二部分可以进行深层次的服务端检测，包括确定推流端是否有问题、确定转推链路是否有问题、确定CDN节点是否有问题、确定转码流是否有问题、确定区域运营商是否有问题、确定CDN服务商是否有问题。从而基于两部分的检测，给出直播异常的结论。

本申请提供的直播异常原因的确定方法，在满足服务端检测条件的情况下，获取边缘节点中的直播流，根据所述直播流的质量，确定直播异常是否包括第一参考原因；从卡顿统计***中获取用户端上报的卡顿信息，根据所述卡顿信息，确定直播异常是否包括第二参考原因；根据所述第一参考原因和所述第二参考原因，确定所述直播异常的服务端原因。这种情况下，可以综合边缘节点和卡顿统计***中的数据，自动化处理判断主播端推流到用户端的链路中，可能出现的服务端异常，从而在短时间内快速确定出直播异常的服务端原因，给出反馈结果，大大节省处理时间，提高了确定直播异常的原因的效率，从而提高了直播异常的响应速度，无需研发人员一一排除各个环节，降低对于研发人员的能力要求，节省了人工成本。另外，由于可以结合卡顿统计***中多个用户端上报的卡顿信息，分析确定服务端存在的异常，从而可以从多个用户端的角度分析直播出现问题的实质原因，提高了确定直播异常的原因的准确性，进而可以及时处理服务端出现的异常，避免大部分用户反馈相同的异常。

本申请提供的直播异常原因的确定方法，在满足服务端检测条件的情况下，获取边缘节点中的直播流，根据所述直播流的质量，确定直播异常是否包括第一参考原因；从卡顿统计***中获取用户端上报的卡顿信息，根据所述卡顿信息，确定直播异常是否包括第二参考原因；在确定出所述直播异常包括所述第一参考原因和/或所述第二参考原因的情况下，根据所述第一参考原因和/或所述第二参考原因，确定所述直播异常的服务端原因。这种情况下，在接收到异常检测请求的情况下，可以先对用户端进行检测，确定用户端是否存在异常，然后在满足服务端检测条件的情况下，再进一步综合边缘节点和卡顿统计***中的数据，自动化处理判断主播端推流到用户端拉流的链路中，可能出现的服务端异常，从而在短时间内快速确定出直播异常的用户端和服务端原因，给出反馈结果，大大节省处理时间，提高了确定直播异常的原因的效率，从而提高了直播异常的响应速度，无需研发人员一一排除各个环节，降低对于研发人员的能力要求，节省了人工成本。另外，由于可以结合卡顿统计***中多个用户端上报的卡顿信息，分析确定服务端存在的异常，从而可以从多个用户端的角度分析直播出现问题的实质原因，从根本解决投诉问题，提高了确定直播异常的原因的准确性，进而可以及时处理服务端出现的异常，避免大部分用户反馈相同的异常。

图4示出了根据本申请一实施例提供的另一种直播异常原因的确定方法的流程图，具体包括以下步骤：

步骤402：在接收到异常检测请求的情况下，获取所述异常检测请求对应的目标用户端的日志数据，确定所述日志数据中是否存在预设异常字段。

步骤404：在所述日志数据中存在所述预设异常字段的情况下，根据所述异常字段，确定并反馈所述直播异常的用户端原因。

步骤406：在所述日志数据中不存在所述预设异常字段的情况下，获取边缘节点中的直播流，根据所述直播流的质量，确定直播异常是否包括第一参考原因；并从卡顿统计***中获取用户端上报的卡顿信息，根据所述卡顿信息，确定直播异常是否包括第二参考原因。

步骤408：在确定出所述直播异常包括所述第一参考原因和/或所述第二参考原因的情况下，根据所述第一参考原因和/或所述第二参考原因，确定所述直播异常的服务端原因。

本申请提供的直播异常原因的确定方法，在接收到异常检测请求的情况下，可以先对用户端进行检测，确定用户端是否存在异常，然后在满足服务端检测条件的情况下，再进一步综合边缘节点和卡顿统计***中的数据，自动化处理判断主播端推流到用户端拉流的链路中，可能出现的服务端异常，从而在短时间内快速确定出直播异常的用户端和服务端原因，给出反馈结果，大大节省处理时间，提高了确定直播异常的原因的效率，从而提高了直播异常的响应速度，无需研发人员一一排除各个环节，降低对于研发人员的能力要求，节省了人工成本。另外，由于可以结合卡顿统计***中多个用户端上报的卡顿信息，分析确定服务端存在的异常，从而可以从多个用户端的角度分析直播出现问题的实质原因，从根本解决投诉问题，提高了确定直播异常的原因的准确性，进而可以及时处理服务端出现的异常，避免大部分用户反馈相同的异常。

上述为本实施例的一种直播异常原因的确定方法的示意性方案。需要说明的是，该直播异常原因的确定方法的技术方案与上述图1所示的直播异常原因的确定方法的技术方案属于同一构思，图4所示的直播异常原因的确定方法的技术方案未详细描述的细节内容，均可以参见上述图1所示的直播异常原因的确定方法的技术方案的描述。

与上述方法实施例相对应，本申请还提供了直播异常原因的确定服务器实施例，图5示出了本申请一实施例提供的一种直播异常原因的确定服务器的结构示意图。如图5所示，该服务器包括：

第一获取模块502，被配置为在满足服务端检测条件的情况下，获取边缘节点中的直播流，根据所述直播流的质量，确定直播异常是否包括第一参考原因；

第二获取模块504，被配置为从卡顿统计***中获取用户端上报的卡顿信息，根据所述卡顿信息，确定直播异常是否包括第二参考原因；

第一确定模块506，被配置为在确定出所述直播异常包括所述第一参考原因和/或所述第二参考原因的情况下，根据所述第一参考原因和/或所述第二参考原因，确定所述直播异常的服务端原因。

可选地，第一获取模块502进一步被配置为以下至少任一项：

获取所述边缘节点接收到的直播流，在所述接收到的直播流的质量低于质量阈值的情况下，确定所述直播异常包括所述第一参考原因，且所述第一参考原因为主播端异常；

获取所述边缘节点发送的直播流，在所述发送的直播流的质量低于质量阈值的情况下，确定所述直播异常包括所述第一参考原因，且所述第一参考原因为所述边缘节点异常。

可选地，第二获取模块504进一步被配置为以下至少任一项：

确定所述用户端访问的内容分发网络中的目标服务节点，从所述卡顿统计***中获取预设统计周期内针对所述目标服务节点的卡顿上报数量，在所述卡顿上报数量大于上报阈值的情况下，确定所述直播异常包括所述第二参考原因，且所述第二参考原因为所述目标服务节点异常；

在确定出所述用户端访问的直播流为转码得到的目标码率直播流的情况下，从所述卡顿统计***中获取预设统计周期内源码率直播流的卡顿率以及所述目标码率直播流的卡顿率，在所述目标码率直播流的卡顿率与所述源码率直播流的卡顿率之间的卡顿率差值大于差值阈值的情况下，确定所述直播异常包括所述第二参考原因，且所述第二参考原因为所述目标码率直播流异常；

确定所述用户端访问直播时所处区域和运营商，从所述卡顿统计***中获取当前预设统计周期所述区域对应的卡顿率，计算所述当前预设统计周期相对于上一预设统计周期的卡顿增长率，在所述卡顿增长率大于增长率阈值的情况下，确定所述直播异常包括所述第二参考原因，且所述第二参考原因为运营商异常；

确定所述用户端访问的内容分发网络服务商，从所述卡顿统计***中获取当前预设统计周期所述内容分发网络服务商对应的卡顿率，计算所述当前预设统计周期相对于上一预设统计周期的卡顿增长率，在所述卡顿增长率大于增长率阈值的情况下，确定所述直播异常包括所述第二参考原因，且所述第二参考原因为内容分发网络服务商异常。

可选地，第一确定模块506进一步被配置为：

合并所述第一参考原因和/或所述第二参考原因；

将合并后的所述第一参考原因和/或所述第二参考原因确定为所述直播异常的服务端原因。

可选地，第一确定模块506进一步被配置为：

确定所述第一参考原因和/或所述第二参考原因中的目标参考原因；

将所述目标参考原因确定为所述直播异常的服务端原因。

可选地，第一确定模块506进一步被配置为：

在确定出直播异常包括任一所述第一参考原因或所述第二参考原因的情况下，停止继续执行确定直播异常是否包括其他所述第一参考原因或所述第二参考原因的操作步骤；

将确定出的直播异常包括的所述第一参考原因或所述第二参考原因确定为所述直播异常的服务端原因。

可选地，所述服务器还包括分析模块，被配置为：

在接收到异常检测请求的情况下，获取所述异常检测请求对应的目标用户端的日志数据；

根据所述日志数据，对所述目标用户端进行分析。

可选地，所述分析模块进一步被配置为：

确定所述日志数据中是否存在预设异常字段；

在所述日志数据中存在所述预设异常字段的情况下，根据所述异常字段，确定并反馈所述直播异常的用户端原因。

可选地，所述服务器还包括第二确定模块，被配置为：

在所述日志数据中不存在所述预设异常字段的情况下，确定满足所述服务端检测条件。

可选地，所述服务器还包括第三确定模块，被配置为：

确定当前时间之前预设时长内接收到的异常检测请求的数量；

在所述异常检测请求的数量超过异常数量阈值的情况下，确定满足所述服务端检测条件。

可选地，所述服务器还包括第四确定模块，被配置为：

记录确定出所述直播异常的服务端原因的异常确定时间；

在接收到新异常检测请求的情况下，确定所述新异常检测请求的接收时间；

确定所述接收时间和所述异常确定时间之间的时间差值是否小于时间阈值；

若是，则根据确定出的所述直播异常的服务端原因，确定所述新异常检测请求对应的异常原因。

本申请提供的直播异常原因的确定服务器，在接收到异常检测请求的情况下，可以先对用户端进行检测，确定用户端是否存在异常，然后在满足服务端检测条件的情况下，再进一步综合边缘节点和卡顿统计***中的数据，自动化处理判断主播端推流到用户端拉流的链路中，可能出现的服务端异常，从而在短时间内快速确定出直播异常的用户端和服务端原因，给出反馈结果，大大节省处理时间，提高了确定直播异常的原因的效率，从而提高了直播异常的响应速度，无需研发人员一一排除各个环节，降低对于研发人员的能力要求，节省了人工成本。另外，由于可以结合卡顿统计***中多个用户端上报的卡顿信息，分析确定服务端存在的异常，从而可以从多个用户端的角度分析直播出现问题的实质原因，从根本解决投诉问题，提高了确定直播异常的原因的准确性，进而可以及时处理服务端出现的异常，避免大部分用户反馈相同的异常。

上述为本实施例的一种直播异常原因的确定服务器的示意性方案。需要说明的是，该直播异常原因的确定服务器的技术方案与上述的直播异常原因的确定方法的技术方案属于同一构思，直播异常原因的确定服务器的技术方案未详细描述的细节内容，均可以参见上述直播异常原因的确定方法的技术方案的描述。

图6示出了根据本申请一实施例提供的一种计算设备600的结构框图。该计算设备600的部件包括但不限于存储器610和处理器620。处理器620与存储器610通过总线630相连接，数据库650用于保存数据。

计算设备600还包括接入设备640，接入设备640使得计算设备600能够经由一个或多个网络660通信。这些网络的示例包括公用交换电话网(PSTN)、局域网(LAN)、广域网(WAN)、个域网(PAN)或诸如因特网的通信网络的组合。接入设备640可以包括有线或无线的任何类型的网络接口(例如，网络接口卡(NIC))中的一个或多个，诸如IEEE802.11无线局域网(WLAN)无线接口、全球微波互联接入(Wi-MAX)接口、以太网接口、通用串行总线(USB)接口、蜂窝网络接口、蓝牙接口、近场通信(NFC)接口，等等。

在本申请的一个实施例中，计算设备600的上述部件以及图6中未示出的其他部件也可以彼此相连接，例如通过总线。应当理解，图6所示的计算设备结构框图仅仅是出于示例的目的，而不是对本申请范围的限制。本领域技术人员可以根据需要，增添或替换其他部件。

计算设备600可以是任何类型的静止或移动计算设备，包括移动计算机或移动计算设备(例如，平板计算机、个人数字助理、膝上型计算机、笔记本计算机、上网本等)、移动电话(例如，智能手机)、可佩戴的计算设备(例如，智能手表、智能眼镜等)或其他类型的移动设备，或者诸如台式计算机或PC的静止计算设备。计算设备600还可以是移动式或静止式的服务器。

其中，处理器620用于执行如下计算机可执行指令：

在满足服务端检测条件的情况下，获取边缘节点中的直播流，根据所述直播流的质量，确定直播异常是否包括第一参考原因；

从卡顿统计***中获取用户端上报的卡顿信息，根据所述卡顿信息，确定直播异常是否包括第二参考原因；

在确定出所述直播异常包括所述第一参考原因和/或所述第二参考原因的情况下，根据所述第一参考原因和/或所述第二参考原因，确定所述直播异常的服务端原因。

上述为本实施例的一种计算设备的示意性方案。需要说明的是，该计算设备的技术方案与上述的直播异常原因的确定方法的技术方案属于同一构思，计算设备的技术方案未详细描述的细节内容，均可以参见上述直播异常原因的确定方法的技术方案的描述。

本申请一实施例还提供一种计算机可读存储介质，其存储有计算机可执行指令，该计算机可执行指令被处理器执行时以用于实现任意一项所述直播异常原因的确定方法的步骤。

上述为本实施例的一种计算机可读存储介质的示意性方案。需要说明的是，该存储介质的技术方案与上述的直播异常原因的确定方法的技术方案属于同一构思，存储介质的技术方案未详细描述的细节内容，均可以参见上述直播异常原因的确定方法的技术方案的描述。

上述对本申请特定实施例进行了描述。其它实施例在所附权利要求书的范围内。在一些情况下，在权利要求书中记载的动作或步骤可以按照不同于实施例中的顺序来执行并且仍然可以实现期望的结果。另外，在附图中描绘的过程不一定要求示出的特定顺序或者连续顺序才能实现期望的结果。在某些实施方式中，多任务处理和并行处理也是可以的或者可能是有利的。

所述计算机指令包括计算机程序代码，所述计算机程序代码可以为源代码形式、对象代码形式、可执行文件或某些中间形式等。所述计算机可读介质可以包括：能够携带所述计算机程序代码的任何实体或装置、记录介质、U盘、移动硬盘、磁碟、光盘、计算机存储器、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，Random Access Memory)、电载波信号、电信信号以及软件分发介质等。需要说明的是，所述计算机可读介质包含的内容可以根据司法管辖区内立法和专利实践的要求进行适当的增减，例如在某些司法管辖区，根据立法和专利实践，计算机可读介质不包括电载波信号和电信信号。

需要说明的是，对于前述的各方法实施例，为了简便描述，故将其都表述为一系列的动作组合，但是本领域技术人员应该知悉，本申请并不受所描述的动作顺序的限制，因为依据本申请，某些步骤可以采用其它顺序或者同时进行。其次，本领域技术人员也应该知悉，说明书中所描述的实施例均属于优选实施例，所涉及的动作和模块并不一定都是本申请所必须的。

在上述实施例中，对各个实施例的描述都各有侧重，某个实施例中没有详述的部分，可以参见其它实施例的相关描述。

以上公开的本申请优选实施例只是用于帮助阐述本申请。可选实施例并没有详尽叙述所有的细节，也不限制该发明仅为所述的具体实施方式。显然，根据本申请的内容，可作很多的修改和变化。本申请选取并具体描述这些实施例，是为了更好地解释本申请的原理和实际应用，从而使所属技术领域技术人员能很好地理解和利用本申请。本申请仅受权利要求书及其全部范围和等效物的限制。

Claims (14)

1.一种直播异常原因的确定方法，其特征在于，包括：

在满足服务端检测条件的情况下，获取边缘节点中的直播流，根据所述直播流的质量，确定直播异常是否包括第一参考原因，其中，所述第一参考原因包括主播端异常和/或边缘节点异常；

从卡顿统计***中获取用户端上报的卡顿信息，根据所述卡顿信息，从不同维度确定直播异常是否包括第二参考原因；

在确定出所述直播异常包括所述第一参考原因和/或所述第二参考原因的情况下，根据所述第一参考原因和/或所述第二参考原因，确定所述直播异常的服务端原因。

2.根据权利要求1所述的直播异常原因的确定方法，其特征在于，获取边缘节点中的直播流，根据所述直播流的质量，确定直播异常是否包括第一参考原因，包括以下至少任一项：

获取所述边缘节点接收到的直播流，在所述接收到的直播流的质量低于质量阈值的情况下，确定所述直播异常包括所述第一参考原因，且所述第一参考原因为主播端异常；

获取所述边缘节点发送的直播流，在所述发送的直播流的质量低于质量阈值的情况下，确定所述直播异常包括所述第一参考原因，且所述第一参考原因为所述边缘节点异常。

3.根据权利要求1所述的直播异常原因的确定方法，其特征在于，从卡顿统计***中获取用户端上报的卡顿信息，并根据所述卡顿信息，确定直播异常是否包括第二参考原因，包括以下至少任一项：

确定所述用户端访问的内容分发网络中的目标服务节点，从所述卡顿统计***中获取预设统计周期内针对所述目标服务节点的卡顿上报数量，在所述卡顿上报数量大于上报阈值的情况下，确定所述直播异常包括所述第二参考原因，且所述第二参考原因为所述目标服务节点异常；

在确定出所述用户端访问的直播流为转码得到的目标码率直播流的情况下，从所述卡顿统计***中获取预设统计周期内源码率直播流的卡顿率以及所述目标码率直播流的卡顿率，在所述目标码率直播流的卡顿率与所述源码率直播流的卡顿率之间的卡顿率差值大于差值阈值的情况下，确定所述直播异常包括所述第二参考原因，且所述第二参考原因为所述目标码率直播流异常；

确定所述用户端访问直播时所处区域和运营商，从所述卡顿统计***中获取当前预设统计周期所述区域对应的卡顿率，计算所述当前预设统计周期相对于上一预设统计周期的卡顿增长率，在所述卡顿增长率大于增长率阈值的情况下，确定所述直播异常包括所述第二参考原因，且所述第二参考原因为运营商异常；

确定所述用户端访问的内容分发网络服务商，从所述卡顿统计***中获取当前预设统计周期所述内容分发网络服务商对应的卡顿率，计算所述当前预设统计周期相对于上一预设统计周期的卡顿增长率，在所述卡顿增长率大于增长率阈值的情况下，确定所述直播异常包括所述第二参考原因，且所述第二参考原因为内容分发网络服务商异常。

4.根据权利要求1-3任一所述的直播异常原因的确定方法，其特征在于，根据所述第一参考原因和/或所述第二参考原因，确定所述直播异常的服务端原因，包括：

合并所述第一参考原因和/或所述第二参考原因；

将合并后的所述第一参考原因和/或所述第二参考原因确定为所述直播异常的服务端原因。

5.根据权利要求1-3任一所述的直播异常原因的确定方法，其特征在于，根据所述第一参考原因和/或所述第二参考原因，确定所述直播异常的服务端原因，包括：

确定所述第一参考原因和/或所述第二参考原因中的目标参考原因；

将所述目标参考原因确定为所述直播异常的服务端原因。

6.根据权利要求1-3任一所述的直播异常原因的确定方法，其特征在于，根据所述第一参考原因和/或所述第二参考原因，确定所述直播异常的服务端原因，包括：

在确定出直播异常包括任一所述第一参考原因或所述第二参考原因的情况下，停止继续执行确定直播异常是否包括其他所述第一参考原因或所述第二参考原因的操作步骤；

将确定出的直播异常包括的所述第一参考原因或所述第二参考原因确定为所述直播异常的服务端原因。

7.根据权利要求1-3任一所述的直播异常原因的确定方法，其特征在于，在满足服务端检测条件的情况下，获取边缘节点中的直播流之前，还包括：

在接收到异常检测请求的情况下，获取所述异常检测请求对应的目标用户端的日志数据；

根据所述日志数据，对所述目标用户端进行分析。

8.根据权利要求7所述的直播异常原因的确定方法，其特征在于，根据所述日志数据，对所述目标用户端进行分析，包括：

确定所述日志数据中是否存在预设异常字段；

在所述日志数据中存在所述预设异常字段的情况下，根据所述异常字段，确定并反馈所述直播异常的用户端原因。

9.根据权利要求8所述的直播异常原因的确定方法，其特征在于，在满足服务端检测条件的情况下，获取边缘节点中的直播流之前，还包括：

在所述日志数据中不存在所述预设异常字段的情况下，确定满足所述服务端检测条件。

10.根据权利要求7所述的直播异常原因的确定方法，其特征在于，在满足服务端检测条件的情况下，获取边缘节点中的直播流之前，还包括：

确定当前时间之前预设时长内接收到的异常检测请求的数量；

在所述异常检测请求的数量超过异常数量阈值的情况下，确定满足所述服务端检测条件。

11.根据权利要求1-3任一所述的直播异常原因的确定方法，其特征在于，根据所述第一参考原因和所述第二参考原因，确定所述直播异常的服务端原因之后，还包括：

记录确定出所述直播异常的服务端原因的异常确定时间；

在接收到新异常检测请求的情况下，确定所述新异常检测请求的接收时间；

确定所述接收时间和所述异常确定时间之间的时间差值是否小于时间阈值；

若是，则根据确定出的所述直播异常的服务端原因，确定所述新异常检测请求对应的异常原因。

12.一种直播异常原因的确定服务器，其特征在于，包括：

第一获取模块，被配置为在满足服务端检测条件的情况下，获取边缘节点中的直播流，根据所述直播流的质量，确定直播异常是否包括第一参考原因，其中，所述第一参考原因包括主播端异常和/或边缘节点异常；

第二获取模块，被配置为从卡顿统计***中获取用户端上报的卡顿信息，根据所述卡顿信息，从不同维度确定直播异常是否包括第二参考原因；

第一确定模块，被配置为在确定出所述直播异常包括所述第一参考原因和/或所述第二参考原因的情况下，根据所述第一参考原因和/或所述第二参考原因，确定所述直播异常的服务端原因。

13.一种计算设备，其特征在于，包括：

存储器和处理器；

所述存储器用于存储计算机可执行指令，所述处理器用于执行所述计算机可执行指令，以实现下述方法：

在满足服务端检测条件的情况下，获取边缘节点中的直播流，根据所述直播流的质量，确定直播异常是否包括第一参考原因，其中，所述第一参考原因包括主播端异常和/或边缘节点异常；

从卡顿统计***中获取用户端上报的卡顿信息，根据所述卡顿信息，从不同维度确定直播异常是否包括第二参考原因；

在确定出所述直播异常包括所述第一参考原因和/或所述第二参考原因的情况下，根据所述第一参考原因和/或所述第二参考原因，确定所述直播异常的服务端原因。

14.一种计算机可读存储介质，其特征在于，其存储有计算机可执行指令，该计算机可执行指令被处理器执行时实现权利要求1至11任意一项所述直播异常原因的确定方法的步骤。

Images