一种数据处理方法及装置与流程

本申请涉及计算机技术领域，尤其涉及一种数据处理方法及装置。

背景技术：

目前，在诸如网络、电视直播的场景下，数据直播得到了广泛的应用(其中，数据直播就是数据的实时显示)，通过数据直播，用户可及时的获知相应的信息。

例如：在电视直播过程中，显示春运客流量数据，那么，收看该电视直播的用户便可以获知相应的春运客流量。又例如：购物网站显示该网站的访问量、销售额等数据，那么，访问至该购物网站的用户便可以在相应页面中获知访问量及销售额。

上述数据的直播显示，通常由相应的服务器(或服务器集群)中的直播数据服务实现(该直播数据服务运行在服务器中)：直播数据服务从数据源处实时获取数据，并经过相应的统计处理后，得到直播数据，发送给终端显示。需要说明的是，对于实际的数据直播显示过程而言，实质上是一种延时直播，换言之，终端所显示的数据与服务器所生成的数据之间存在一定的时间差，也即，终端所显示的直播数据通常是n秒前服务器所生成的。

而在实际应用场景下，直播数据服务在运行的过程中可能出现异常的情况(如：计数出错、运行卡顿等)，这就需要相应的业务人员进行排障及修复的操作。

现有技术中，当直播数据服务出现异常时，服务器会采用备用服务切换的方式，启动备用的直播数据服务代替出现异常的直播数据服务。

但是，采用备份服务切换方式，就有可能导致实时数据出现“跳跃”或回退，这是因为：服务器中所运行的直播数据服务会将从数据源处所获得实时数据进行缓存，以便进行相应的统计处理，若该直播数据服务出现了异常而被备用的直播数据服务替换后，其存储在缓存中的实时数据将被清除，备用的直播数据服务上线后，将重新缓存这部分实时数据进行统计处理。这样就会造成数据的重复统计处理，进一步导致出现数据直播时的回退现象。

例如：以访问量数据为例，原有的直播数据服务将从数据源处获取的实时数据a₉₀₀～a₉₆₀进行缓存，并针对这60条数据进行统计处理，最终可生成访问量数据900～960，假设，直播数据服务器已根据实时数据a₉₃₀～a₉₅₀，生成了访问量数据930～950，发送给终端进行显示，如图1a所示，终端基于服务器所发送的访问量数据，当前所显示的访问量为：935。

假设，直播数据服务在生成访问量数据955时出现了异常，此时，服务器将该出现异常的直播数据服务停止，并启用备用的直播数据服务代替出现异常的直播数据服务，但在备用的直播数据服务上线运行后，将清除原有直播数据服务所缓存的数据，并重新将实时数据a₉₀₀～a₉₆₀缓存以进行统计处理，并重新生成访问量数据900～920发送给终端进行显示，那么，对于终端而言，其根据之前接收到的访问量数据，显示访问量950后(如图1b所示)，又将根据最新接收到的访问量数据900～920，将回退至900，并从900开始重新显示，如图1c所示。可见，该情况便是数据的回退。

显然，这样的方式将影响终端所显示的直播数据。

技术实现要素：

本申请实施例提供一种数据处理方法，用以解决现有技术中直播数据出现异常可能导致显示跳变、回退的问题。

本申请实施例提供一种数据处理装置，用以解决现有技术中直播数据出现异常可能导致显示跳变、回退的问题。

本申请实施例采用下述技术方案：

本申请实施例提供的一种数据处理方法，包括：

服务器监测直播数据服务的运行状态；

当监测到所述运行状态发生异常时，确定预估修复时长；

根据所述预估修复时长，计算第一速率；

将计算得到的第一速率发送至终端，以使得所述终端根据所述第一速率显示直播数据。

本申请实施例还提供的一种数据处理方法，包括：

终端接收服务器发送的第一速率，其中，所述第一速率由所述服务器监测到所述运行状态发生异常时，确定预估修复时长，并根据所述预估修复时长计算得到；

根据所述第一速率显示直播数据。

本申请实施例提供的一种数据处理装置，包括：

监测模块，监测直播数据服务的运行状态；

预估模块，当监测到所述运行状态发生异常时，确定预估修复时长；

计算模块，根据所述预估修复时长，计算第一速率；

发送模块，将计算得到的第一速率发送至终端，以使得所述终端根据所述第一速率显示直播数据。

本申请实施例还提供的一种数据处理装置，包括：

接收模块，接收服务器发送的第一速率，其中，所述第一速率由所述服务器监测到所述运行状态发生异常时，确定预估修复时长，并根据所述预估修复时长计算得到；

显示模块，根据所述第一速率显示直播数据。

本申请实施例采用的上述至少一个技术方案能够达到以下有益效果：

当服务器在监测到直播数据服务出现异常时，将确定预估的修复时长，并基于预估的修复时长，计算出第一速率发送给终端，其中，这里的第一速率能够控制终端显示直播数据的显示速率，换言之，在第一速率的作用下，能够减慢终端显示直播数据的显示速率，那么，终端将根据第一速率降低其显示直播数据的速率，从而，对于终端本地的存储的待显示的直播数据，终端将消耗更长的时间显示这些直播数据，这样一来，在服务器侧，业务人员也将获得足够的时间对服务器中运行的直播数据服务进行排障、修复。

相较于现有技术切换备用直播数据服务的方式，采用本申请中的上述方式可以保留原有的直播数据服务(不进行服务的切换)，那么，在直播数据服务恢复正常后，将继续根据其缓存的实时数据进行统计处理，换言之，在不切换直播数服务器的情况下，其缓存的实时数据就不会被清除，进而，也就不会出现直播数据的回退、跳变等异常的显示现象。

同时，使得前端用户不会明显地察觉到直播数据的跳变、回退、停滞等现象。

附图说明

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

图1a～1c为现有技术中的数据直播示意图；

图2a为本申请实施例提供的数据处理过程示意图；

图2b～2d为本申请实施例提供的服务器对终端显示速率的调整过程示意图；

图3为本申请实施例提供的服务器侧的数据处理装置结构示意图；

图4为本申请实施例提供的终端侧的数据处理装置结构示意图。

具体实施方式

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

如前所述，在数据直播的场景下，服务器所生成的直播数据将持续地发送至终端，终端便可根据直播数据进行数据直播显示，但若服务器侧的直播数据服务发生了异常之后，服务器采用备用服务切换的方式，将导致在数据直播过程中出现数据回退、跳变的现象，从而影响数据直播的正常运行。

基于此，就需要一种在数据直播过程中可降低或避免出现数据回退、跳变的方法。故在本申请实施例中，提供一种数据处理方法，以实现即使在服务器中的直播数据服务出现异常的情况下，也不发生数据回退或跳变的现象。，从而保证数据直播的正常运行。

本申请实施例中，所述的服务器可以是能够提供直播数据业务的服务器，包括但不限于：网站服务器、数据中心服务器等。服务器可以采用独立的工作方式(仅一台服务器提供直播数据业务)，也可以采用集群式的工作方式。所述的终端，可以是用户所使用的手机、平板电脑、智能电视、计算机等具有数据显示功能的终端，在某些实际应用场景中，终端还可以是的大型显示设备(如：直播厅中具有大型显示屏的设备)，这里并不构成对本申请的限定。

另外，需要说明的是，对于服务器中的直播数据服务而言，在其进行统计处理生成直播数据的过程中，通常是批量生成直播数据，换言之，直播数据服务会以极短时间间隔，生成一定数量的直播数据。如：直播数据服务距前一次生成直播数据15ms后，生成本次的2000条直播数据。当然，在实际应用中，直播数据服务每次生成直播数据的时间间隔，以及每次所生成的直播数据数量，与数据源的实时数据及服务器的运行负荷相关，这里并不构成对本申请的限定。

那么，在服务器中的直播数据服务正常运行时，终端显示直播数据的过程具体如下：

首先，终端将与服务器进行交互，以获得直播数据。

在本申请实施例中的一种方式下：终端以极短时间间隔的方式周期性地从服务器获取直播数据，例如：终端每0.5s从服务器中获取一次直播数据。也即，该方式中，终端将主动从服务器获取数据，在实际应用中，这样的方式适用于服务器面向大量终端提供数据直播业务的场景。

在另一种方式下，终端与服务器之间保持长连接，那么，当服务器中的直播数据服务每次生成了直播数据后，都会通过与终端之间建立的长连接，将新生成的直播数据发送给终端。当然，在实际应用时，终端与服务器之间建立长连接的方式，更适用于诸如数据直播厅、集中式数据直播等场景下，在面对大量终端的情况下，服务器维持与各终端之间的长连接可能会急剧增加服务器的工作负荷，当然，实际应用中，如果服务器的工作负载足够，也可以针对大量的终端使用长连接的方式，这里并不构成对本申请的限定。

在终端获得直播数据后，便会针对所获得的直播数据进行显示。

基于前述内容，终端所获取的直播数据就是上述数据直播服务所生成的某一批直播数据(这一批直播数据中包含多条数据)，终端获取到这些直播数据后，将缓存在终端本地，并按照服务器所规定的速率对直播数据进行显示。例如：在网站访问量的数据直播过程中，假设终端从服务器中获取的某一批访问量数据包含：访问量300～350的数据，并且，服务器规定对这些访问量数据的显示速率为：每1s变换一次(每次增加5个数据)，那么，假设终端在08:01:10时显示访问量为300，则终端在08:01:11时所显示的访问量为305。

结合上述内容，以下将详细说明本申请各实施例提供的技术方案。

如图2a所示，示出了本申请实施中的数据处理过程，该过程具体包括以下步骤：

S201：服务器监测直播数据服务的运行状态。

直播数据服务运行在服务器中，用以从数据源处获得实时数据，并进行相应的统计处理后，生成可用于显示的直播数据。在实际应用的过程中，直播数据服务将处理海量的数据，那么，在运行的过程中，就可能由于巨大的运算量出现后台调用冲突、运算卡顿等现象，从而导致直播数据服务出现运行异常。可以理解，直播数据服务出现异常后，将进一步导致其生成的直播数据异常。

因此，服务器将监测直播数据服务的运行状态，以便在直播数据服务出现异常时，实施相应的措施，从而避免终端中所显示的直播数据不出现明显的跳变、回退等异常情况。

S202：当监测到所述运行状态发生异常时，确定预估修复时长。

在实际应用中，直播数据服务发生异常，可以由相应的业务人员进行排障、修复等操作，而排障或修复操作需要一定的时间，所以，服务器将确定从直播数据服务发生异常至预计修复时刻之间所需的耗时(也即，预估修复时长)。

S203：根据所述预估修复时长，计算第一速率。

需要说明的是，本申请实施例中所述的第一速率，可以是一种直播数据的变化速率，如：直播数据每ns变化一次。

也可以是直播数据每次变化的幅度，如：直播数据增加n个/次、或直播数据减少n个/次。

还可以是一种时间的流速，即，以实际时间作为基准，采用流速系数*单位时间确定第一速率，如：可以设定第一速率的1s＝1.5*实际时间中的1s，也就是说，在第一速率的作用下，终端中的1s就是实际时间的1.5s。当然，上述第一速率的可选方式并不构成对本申请的限定。

考虑到前述内容，终端在显示直播数据时，其显示速率是由服务器所规定的，终端将按照服务器所规定的显示速率，显示该终端获得的直播数据，那么，当服务器中的直播数据服务出现异常后，如果将终端对直播数据的显示速率降低，则可以增加业务人员对直播数据服务进行排障或恢复的时间。

例如：假设在正常状态下，终端本地存储有访问量300～350的数据，终端按照1s变换一次(设定：访问量将以5个/次增加)直播数据的方式进行直播显示，那么，在正常情况下，终端从访问量300开始显示，直到显示至350，将需要10s的时长。假设，服务器中的直播数据服务运行出现异常，服务器根据预估修复时长计算出第一速率为：每2s变换一次(访问量仍以5个/次增加)，那么，对于终端而言，按照第一速率，从访问量300显示至350时，将需要20s的时长。

从上例可见，在第一速率的作用下，终端在显示直播数据的过程中，相较于正常状态，其显示时间延长了10s。那么，对于后台的业务人员而言，将有10s的时间对直播数据服务进行排障或修复。当然，上述示例仅是对第一速率的作用进行说明，实际应用中可根据预估修复时长进行预估确定，这里并不构成对本申请的限定。

S104：将计算得到的第一时间速率发送至终端，以使得所述终端根据所述第一速率显示直播数据。

在前述内容得到了第一速率的基础上，服务器便会向终端发送第一速率，这样一来，终端将根据第一速率，对终端所获得的直播数据进行显示。具体如前述示例。

通过上述步骤，当服务器在监测到直播数据服务出现异常时，将确定预估的修复时长，并基于预估的修复时长，计算出第一速率发送给终端，其中，这里的第一速率能够控制终端显示直播数据的显示速率，换言之，在第一速率的作用下，能够减慢终端显示直播数据的显示速率，那么，终端将根据第一速率降低其显示直播数据的速率，从而，对于终端本地的存储的待显示的直播数据，终端将消耗更长的时间显示这些直播数据，这样一来，在服务器侧，业务人员也将获得足够的时间对服务器中运行的直播数据服务进行排障、修复。

相较于现有技术切换备用直播数据服务的方式，采用本申请中的上述方式可以保留原有的直播数据服务(不进行服务的切换)，那么，在直播数据服务恢复正常后，将继续根据其缓存的实时数据进行统计处理，换言之，在不切换直播数服务器的情况下，其缓存的实时数据就不会被清除，进而，也就不会出现直播数据的回退、跳变等异常的显示现象。

需要说明的是，上述实施例所提供方法的各步骤的执行主体均可以是同一设备，具体而言，执行主体可以是服务器。

下面将详细说明在直播数据服务出现异常时的情况：

需要说明的是，在实际应用中，当直播数据服务出现异常时，通常是采用人工介入的方式对异常的直播数据服务进行排障或修复，在该过程中，相应的业务人员会设定预计修复的时间，当然，作为一种可选方式，具体可由服务器提供相应的修复诊断界面，该界面中提供了预计修复时间的选项，业务人员在进行排障或修复时，可以在该选项中输入相应的预计修复时间。

那么，在本申请实施例中，确定预估修复时长，具体包括：确定预估修复时刻，确定在直播数据的运行状态发生异常时的时间，根据确定出的所述预估修复时刻以及所述时间，确定所述预估修复时长。

例如：直播数据服务出现异常的时间为：12:08:02，业务人员所预计的预估修复时刻为：12:08:40。那么，预估修复时长就为：38s。

在确定出预估修复时长后，就可以进一步计算出第一时间速率。具体而言，确定在直播数据的运行状态发生异常时，终端停止显示直播数的时间，根据确定出的、终端停止显示直播数的时间及预估修复时长，确定所述第一速率。

其中，所述预估修复时长越长，则第一速率越慢。为了便于描述，以下将预估修复时长称为T_yu。

这里需要说明的是，当直播数据服务出现异常时，服务器将停止向终端发送直播数据，那么，对于终端而言，其将按照原有的显示速率显示其本地的直播数据，可以理解，终端会在一段时间后，将其本地未显示的直播数据显示完毕，这样一来，终端在显示出最后一个直播数据后，停止直播数据的变更(因为在此时，终端已将本地缓存的所有直播数据均进行显示，且还未获得由服务器所提供的新增的直播数据)，其表现形式为，终端所显示的直播数据停止在某一数值处。例如：终端所显示的访问量在500处停止。

所以，在本申请实施例中，当直播数据服务的运行状态发生异常时，服务器将确定出终端从此时刻开始，直到停止变更直播数据的时间(为了便于描述，以下将终端从直播数据服务运行异常时刻起，到停止变更直播数据时之间的时长称为T_c1)。当然，作为本申请实施例中的一种可选方式，终端内显示直播数据的显示速率是由服务器所规定的，所以，服务器可以获知终端的显示速率。并且，由于服务器中的直播数据服务每次统计处理生成直播数据的时间点均有记录(如：记录在相应的数据日志中)，相应地，该时间点所对应的直播数据的数量也有相应的记录，那么，服务器可以确定出前一次向终端发送直播数据时，这些直播数据生成的时间点，基于此，就可以确定出终端本地所存储的直播数据量。可以理解地，终端本地所存储的直播数据量、显示速率均已知，故服务器可以确定出T_c1。

可以认为，T_c1是显示速率未发生变化的情况下，终端显示直播数据的耗时，但是，一旦终端经过T_c1时间后，终端就会停止直播数据的变更，这就会造成数据直播的显示异常，而T_yu是后台业务人员进行修复可能所需的时间，所以，在本申请实施例中，就将根据T_c1和T_yu确定出第一速率，以使得在第一速率的作用下，延长T_c1。

例如：假设终端显示网站的访问量数据，其显示速率为：每秒10个数据递增，目前终端从服务器获得的访问量数据包括1000～1200。并假设，终端在显示访问量1000时，服务器中运行的直播数据服务出现异常，那么，终端此时并不能继续从服务器中获得访问量数据。可知，终端按照该显示速率，从访问量1000起，显示到访问量1200所需的时长T_c1为20s。但是，预估修复时长T_yu为40s，为了避免出现终端在20s之后出现数据停滞的现象，就需要调整终端当前的显示速率。

在本示例中，第一速率＝T_c1/T_yu*当前显示速率＝0.5*10＝5。

也即，第一速率为：每秒5个数据递增，显然，在该第一速率的作用下，终端从访问量1000起，显示到访问量1200所需的时长就变为40s，延长了原本的显示时长。

当然，上述方式是以第一速率为直播数据的跳变量的情况所进行的说明。而如果第一速率为时间流速，那么，可采用如下方式计算第一速率：

第一速率(客户端的时间流速)＝[(服务器与客户端之间的时间差异*客户端时间)/T_yu]+客户端原有的时间流速。

以上内容是在直播数据服务出现异常时对终端显示速率的调整过程，具体如图2b所示，在上述过程中，根据计算得到的第一速率，实质上减缓了终端的显示速率。而在实际应用场景下，当后台的业务人员将直播数据服务修复后，那么，直播数据服务又将正常地对实时数据进行统计处理，生成相应的直播数据，发送给终端。对于终端而言，其在之前第一速率的作用下，显示直播数据时，维持在较低的显示速率，当终端能够正常接收服务器发送的直播数据后，便可将其显示速率加快，以适应于新增的直播数据。

下面对直播数据服务恢复后的过程进行详细说明：

由于前述的修复过程中，业务人员会预估某一时刻可将直播数据服务修复(即，预估修复时刻)，实际应用场景下，直播数据服务实际的恢复时刻与之前由业务人员预估的修复时刻之间可能具有时差。如：假设由业务人员预估的修复时刻为12:08:40，而实际上，直播数据服务在12:07:50时已经恢复，所以，两个时间点之间存在50s的时差。

在实际应用中，由于第一速率是根据预估修复时长而确定的，那么，如果直播数据服务的实际恢复时间与预估修复时刻之间具有一定的时差，就应根据该时差来确定终端的显示速率应该加快的程度，也即，确定第二速率。

所示，对于前述方法，在直播数据服务恢复后，还包括：当监测到所述直播数据的运行状态恢复正常时，确定修复时差，根据所述修复时差，计算第二速率，将计算得到的第二时间速率发送至终端，以使得所述终端根据所述第二速率显示直播数据。

当然，根据前述内容可知，确定修复时差，具体包括：确定所述直播数据服务的运行状态恢复正常时的时刻，根据直播数据服务的运行状态恢复正常时的时刻以及预估修复时刻，确定所述修复时差。

延续前述示例：假设前述示例中，在12:01:00时直播数据服务出现异常，由于预估修复时长为40s，那么，其预估修复时刻为12:01:40，但是直播数据服务的实际恢复时间为12:01:20(并于此刻新生成了访问量数据)，也就是说，直播数据服务相较于预估修复时刻，其提前了20s恢复，此时，在终端侧，其还有数量为100的访问量数据并未显示，假设，直播数据服务照常工作后，为了使得终端能够适于直播数据服务照常工作而生成的新访问量数据，所以，服务器将调整终端此时的显示速率(即，第一速率)，使得终端加速显示剩余的访问量数据(即，生成第二速率)。

当然，可以理解，修复时差越短，则第二速率越快。

同样，上述方式是以第二速率为直播数据的跳变量的情况所进行的说明。而如果第二速率为时间流速，那么，可采用如下方式计算第二速率：

第二速率(客户端的时间流速)＝[(实际修复时刻-客户端时间)*T_yu/实际修复时差]+第一速率。

以上是直播数据服务恢复正常时对终端显示速率的调整过程，具体如图2c所示。

当然，在终端加速显示其本地剩余的直播数据后(并接收到了新增的直播数据)，服务器还会再一次向终端发送正常的速率，以使得终端按照正常速率显示直播数据。其过程如图2d所示。

另外，需要说明的是，在实际应用场景下，直播数据服务实际的恢复时刻可以晚于预估修复时刻，例如：假设在12:01:00时直播数据服务出现异常，预估修复时刻为12:01:40，但实际上在12:02:20时，直播数据服务才恢复正常，显然，对于这种情况而言，如果终端只按照前述方法计算得到的第一速率对直播数据进行显示，仍会出现直播数据显示停滞的现象，所以，在本申请实施例中，为了避免上述情况的出现，可以动态的调整第一速率，也即，可以多次计算第一速率并发送给终端。

例如：延续前述第一速率的示例，从前例中可知，首次生成的第一速率为：每秒5个访问量递增，经过10秒后(此时，终端中所显示的访问量为1150，还剩余150个访问量数据，在30s后显示完)，直播数据服务仍未修复，那么，服务器可在此基础上重新计算新的第一速率(其作用在于继续延长终端的显示耗时)，假设，新计算的第一速率为：每秒2个访问量递增，这样，就可以将终端的显示耗时增加到75s。

当然，上述上例仅是本申请实施例中在实际应用场景下的一种可能方式，并不构成对本申请的限定。

经过以上内容，当服务器中的直播数据服务出现异常时，服务器可将终端当前的显示速率减缓，可以延长后台的工作人员排障或修复的时间，同时，使得前端用户不会明显地察觉到直播数据的跳变、回退、停滞等现象。相应地，在直播数据服务修复之后，可加快终端的显示速率，使得终端适于服务器发送的新增直播数据。

当然，在终端侧，本申请提供一种数据处理方法，具体而言，在服务器中的直播数据服务发生异常时：

步骤一：终端接收服务器发送的第一速率，其中，所述第一速率由所述服务器监测到所述运行状态发生异常时，确定预估修复时长，并根据所述预估修复时长计算得到。

步骤二：根据所述第一速率显示直播数据。

当服务器中的直播数据服务恢复正常时，该方法还包括：所述终端接收所述服务器发送的第二速率，其中，所述第二速率由所述服务器监测到所述直播数据的运行状态恢复正常时，确定修复时差，并根据所述修复时差计算得到；根据所述第二速率显示直播数据。

对于终端侧而言，其获取直播数据、根据不同速率显示直播数据等实现过程可参考前述内容，这里并不再过多赘述。

以上为本申请实施例提供的数据处理方法，基于同样的思路，本申请实施例还提供一种数据处理装置。

如图3所示，数据处理装置，设置于服务器侧，该装置包括：

监测模块301，监测直播数据服务的运行状态；

预估模块302，当监测到所述运行状态发生异常时，确定预估修复时长；

计算模块303，根据所述预估修复时长，计算第一速率；

发送模块304，将计算得到的第一速率发送至终端，以使得所述终端根据所述第一速率显示直播数据。

具体而言，预估模块302，确定预估修复时刻，确定在直播数据服务的运行状态发生异常时的时间，根据确定出的所述预估修复时刻以及所述时间，确定所述预估修复时长。

进一步地，预估模块302，确定在直播数据的运行状态发生异常时，终端停止变更直播数据的时间，根据确定出的、终端停止显示直播数的时间及预估修复时长，确定所述第一速率。

其中，所述预估修复时长越长，则第一速率越慢。

所述装置还包括：

修复模块305，当监测到所述直播数据的运行状态恢复正常时，确定修复时差，根据所述修复时差，计算第二速率，将计算得到的第二时间速率发送至终端，以使得所述终端根据所述第二速率显示直播数据。

进一步地，修复模块305，确定所述直播数据服务的运行状态恢复正常时的时刻，根据直播数据服务的运行状态恢复正常时的时刻以及预估修复时刻，确定所述修复时差。

基于此，计算模块303，根据所述修复时差以及第一速率，确定所述第二速率。

其中，所述修复时差越短，则第二速率越快。

如图4所示，本申请实施例中还提供一种数据处理装置，设置于终端侧，该装置包括：

接收模块401，接收服务器发送的第一速率，其中，所述第一速率由所述服务器监测到所述运行状态发生异常时，确定预估修复时长，并根据所述预估修复时长计算得到。

显示模块402，根据所述第一速率显示直播数据。

当然，在直播数据服务器恢复后，服务器还会向终端发送第二速率，那么，接收模块401，接收服务器发送的第二速率，其中，所述第二速率由所述服务器监测到所述直播数据的运行状态恢复正常时，确定修复时差，并根据所述修复时差计算得到。

显示模块402，根据所述第二速率显示直播数据。

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

本发明是参照根据本发明实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

在一个典型的配置中，计算设备包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。

内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器(RAM)和/或非易失性内存等形式，如只读存储器(ROM)或闪存(flash RAM)。内存是计算机可读介质的示例。

计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带，磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括暂存电脑可读媒体(transitory media)，如调制的数据信号和载波。

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

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

以上所述仅为本申请的实施例而已，并不用于限制本申请。对于本领域技术人员来说，本申请可以有各种更改和变化。凡在本申请的精神和原理之内所作的任何修改、等同替换、改进等，均应包含在本申请的权利要求范围之内。