CN111935490B - 一种直播录流容灾处理方法及系统 - Google Patents

Abstract

本发明公开了一种直播录流容灾处理方法及系统，方法包括：通过缓存数据服务器接收组播数据，并将组播数据缓存至内存缓冲区；通过录流服务器发起补流请求，确定出待恢复数据的开始位置和结束位置；缓存数据服务器接收所述补流请求，基于开始位置和结束位置得到内存缓冲区的对应位置；提取存缓冲区的对应位置的数据，更新文件索引信息。本发明能够简单有效的实现容灾数据流的恢复。

Description

一种直播录流容灾处理方法及系统

技术领域

本发明涉及数据处理技术领域，尤其涉及一种直播录流容灾处理方法及系统。

背景技术

现有的IP网络直播视频时，最大的问题是如何解决大容量视频的并发问题，例如在直播春节晚会，足球世界杯时，目前可使用组播模式下的变码率ABR技术结合CDN(Content Delivery Network，内容分发网络)解决这一难题。通过组播传送所有观众请求的流，意味着运营商只要从原始服务器提供单个流就可以减轻自身网络带宽压力。所以现有的直播业务一般采用组播的网络方式来实现，所谓组播就是利用一组协议将IP数据包从一个信息源送到多个目的地，将信息的拷贝发送到一组地址，送达所有想要接收它的接收者。

根据每一个录流服务所有的内存，CPU负载及IO等资源的消耗等情况，每个录流进程服务可以负责多路频道节目的TS流录流工作、当录流服务程序挂掉重启或重新分配时，前端的组播源还在持续播发、而接收TS流服务却没有，那么在新的录流服务程序重新启动接收TS流的这段时间内，如果不进行一定的处理，那么此时间段内的数据将会丢失。

为了确保数据不丢失，目前常用的方法是启动一组两个或多个同时录制相同的频道节目的码流，通过多备份来解决高可用问题。采用这种方法的缺点是需要冗余的磁盘空间和服务器来解决，同时这一组需要一个管理服务程序进行主从切换，从而当故障发生时触发数据补齐操作。

在录流服务器出现故障时，为了将所缺失的数据补齐就需要一个组控制管理器，并需要知道开始和结束的位置进行数据补齐，为了实时知道录流服务器的健康情况则需要一个健康控测程序。

每台录流服务器一般需要根据CPU使用率、网络带宽、IO处理速度及文件存盘速度多个角色来共同决定。每个频道节目开启一个独立线程、先根据前端播发地址加入组播，接收组播数据并将TS流数据存储到磁盘中，根据现有的测试环境，每个频道节目的CPU使用率在5％之间，网络带宽由实际的节目码率决定，一般是20-64M(单位：bps)、录流接收操作是一个低IO使用率的应用场景、文件的存盘是由磁盘的存储速度决定，是一个阻塞式的操作，如果存在瓶颈可以采用先写入内存然后额外的写入线程慢慢写入磁盘存储介质。

目前为了减小写磁盘的瓶颈是每个频道节目的码流录制开启两个线程，一个线程用于接收组播码流数据、另外一个线程用于将码流数据写到磁盘，中间通过内存进行缓存，一般缓存20s左右的数据。

根据目前系统测算，开启一个录流服务程序，可以同时录制80路高清节目，整体CPU使用率400％左右即占用4个CPU核、磁盘由于采用了内存转存，每路需要分配内存160MB(64Mbps*20s＝160MB)左右，即160M*100＝16000M≈16GB、对于现在的标配24核，64G内存的服务器来说，物理资源的使用是完全没有问题。为了避免CPU的负载太重，且为了峰值的降压，同时或许还有其它的一些CPU耗时工作，预算分配了8核CPU、16G内存空间。

现有一般地市的全部频道总节目数大概300多个左右，即需要部署4台服务完成直播录流工作，考虑到录流服务程序会出现故障的情况下，至少需要进行双备份录流服务器同时录制相同的频道节目保证冗余容灾的问题、即总共需要8台服务器。

由此可以看出，现有的技术架构都是利用双备份冗余架构方式解决服务器故障问题，即运行一组或多组的录流服务程序负责相同频道节目的录制。综上所述现有的方法有如下缺点：

1、存储N个备份数据则需要占用多份磁盘空间，成本增加。

2、运行N个录流服务程序则需要占用CPU、内存等服务器资源。

3、需要协调一组内的N台录流服务程序之间的关系，比如主从或者冷热设备切换、从而增加程序设计的复杂度。

4、增加的资源按照录流服务程序的备用机N台，则需要增加N台服务器的成本开销。

5、服务器增加则运维成本上升，还有电能消耗及制冷系统成本等。

因此，如何简单有效的实现直播录流的容灾处理，是一项亟待解决的问题。

发明内容

有鉴于此，本发明提供了一种直播录流容灾处理方法，能够简单有效的实现容灾数据流的恢复。

本发明提供了一种直播录流容灾处理方法，包括：

通过缓存数据服务器接收组播数据，并将所述组播数据缓存至内存缓冲区；

通过录流服务器发起补流请求，确定出待恢复数据的开始位置和结束位置；

所述缓存数据服务器接收所述补流请求，基于所述开始位置和结束位置得到内存缓冲区的对应位置；

提取所述内存缓冲区的对应位置的数据，更新文件索引信息。

优选地，所述内存缓冲区为可循环缓冲区。

优选地，通过录流服务器发起补流请求，确定出待恢复数据的开始位置和结束位置，包括：

通过录流服务器发起补流请求，使用TS包进行数据比较匹配，确定出待恢复数据的开始位置和结束位置。

优选地，所述通过录流服务器发起补流请求，使用TS包进行数据比较匹配，确定出待恢复数据的开始位置和结束位置，包括：

通过录流服务器发起补流请求，所述录流服务器读取上一次断流的最后一个TS包作为开始位置，读取开始重新录流的第一个TS包作为结束位置。

优选地，所述缓存数据服务器接收所述补流请求，基于所述开始位置和结束位置得到内存缓冲区的对应位置，包括：

缓存数据服务器接收所述补流请求，基于所述开始位置和结束位置，通过内存数据比较函数确定出内存缓冲区的对应位置。

一种直播录流容灾处理系统，包括：

缓存数据服务器，用于接收组播数据，并将所述组播数据缓存至内存缓冲区；

录流服务器，用于发起补流请求，确定出待恢复数据的开始位置和结束位置；

所述缓存数据服务器，还用于接收所述补流请求，基于所述开始位置和结束位置得到内存缓冲区的对应位置；

所述缓存数据服务器，还用于提取所述内存缓冲区的对应位置的数据，更新文件索引信息。

优选地，所述内存缓冲区为可循环缓冲区。

优选地，所述录流服务器在执行发起补流请求，确定出待恢复数据的开始位置和结束位置时，具体用于：

发起补流请求，使用TS包进行数据比较匹配，确定出待恢复数据的开始位置和结束位置。

优选地，所述录流服务器在执行发起补流请求，使用TS包进行数据比较匹配，确定出待恢复数据的开始位置和结束位置时，具体用于：

发起补流请求，读取上一次断流的最后一个TS包作为开始位置，读取开始重新录流的第一个TS包作为结束位置。

优选地，所述缓存数据服务器在执行接收所述补流请求，基于所述开始位置和结束位置得到内存缓冲区的对应位置时，具体用于：

缓存数据服务器接收所述补流请求，基于所述开始位置和结束位置，通过内存数据比较函数确定出内存缓冲区的对应位置。

综上所述，本发明公开了一种直播录流容灾处理方法，当需要对直播录流进行容灾处理时，通过缓存数据服务器接收组播数据，并将组播数据缓存至内存缓冲区，通过录流服务器发起补流请求，确定出待恢复数据的开始位置和结束位置；缓存数据服务器接收补流请求，基于开始位置和结束位置得到内存缓冲区的对应位置；提取内存缓冲区的对应位置的数据，更新文件索引信息。本发明能够简单有效的实现容灾数据流的恢复。

附图说明

为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1为本发明公开的一种直播录流容灾处理方法实施例1的方法流程图；

图2为本发明公开的一种直播录流容灾处理方法实施例2的方法流程图；

图3为本发明公开的一种直播录流容灾处理系统实施例1的结构示意图；

图4为本发明公开的一种直播录流容灾处理系统实施例2的结构示意图；

图5为本发明公开的数据缓冲区读写示意图。

具体实施方式

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

下面首先对整体流播发与录流的架构进行说明：

直播功能协议中，比较常见的有RTMP、HLS、HTTP等协议。比如RTMP的实时性在3秒之内，经过多层CDN节点分发后，实时性也在3秒左右，其实时性不如组播，而且RTMP最大软肋，因为是Adobe的私有协议，很多设备都无法直接播放，比如iOS，需要外挂第三方解码器，由此会带来发热、耗电等问题。

HTTP协议性能好且简单、如果分发的量特别大，譬如点播视频网站，没有直播的实时性要求，HTTP协议是最好选择，但其实时性差。

HLS是一个切片的协议，但分发HLS，码流低，切片较小时，小文件分发不是很友好。特别是一些对存储比较敏感的情况，譬如源站的存储，嵌入式的SD卡。

综上所述使用组播协议是直播TS流播发的最好协议。

1、播发前端-组播的优点包括以下几点：

a、需要相同数据流的客户端加入相同的组共享一条数据流，节省了服务器的负载。

b、组播协议是根据接受者的需要对数据流进行复制转发，所以服务端的服务总带宽不受客户接入端带宽的限制。

c、组播可以穿越公网广泛传播，不受限于局域网或广播网内部传播

举例来说，使用基于组播协议的直播系统可以用一台服务器支持数万客户收看一个或几个频道的网上电视直播。假设一共提供100个频道的电视节目，每个频道是8Mbps的MPEG4高清晰码流，则无论有1万客户还是100万客户，其占用的网络主干网都是100M(byte)，而3～5台服务器硬件的投资不到20万。

2、接收终端

不同的主机之间“一对一组”的通讯模式，也就是加入了同一个组的主机可以接受到此组内的所有数据，网络中的交换机和路由器只向有需求者复制并转发其所需数据。主机可以向路由器请求加入或退出某个组，网络中的路由器和交换机有选择的复制并传输数据，即只将组内数据传输给那些加入组的主机。这样既能一次将数据传输给多个有需要(加入组)的主机，又能保证不影响其他不需要(未加入组)的主机的其他通讯。

结合整体流播发与录流的架构下面对本发明公开的直播录流容灾处理方法及系统进行详细说明。

如图1所示，为本发明公开的一种直播录流容灾处理方法实施例1的流程图，所述方法可以包括以下步骤：

S101、通过缓存数据服务器接收组播数据，并将组播数据缓存至内存缓冲区；

当需要对直播录流进行容灾处理时，通过增加缓存数据服务器来实现接收组播数据，并将组播数据缓存至内存缓冲区。

根据实际测试，每台缓存数据服务器可实时处理300多路的频道节目录流工作，接收到组播数据流后直接缓存在内存中。无论是CPU使用率还是IO利用率都很低。假如每个频道节目高清16Mbps码率，缓存1分钟数据则需要的内存空间：16Mbps*60＝960Mb≈120MB。根据缓存数据服务器的64G内存可容纳的频道节目数：64G/120MB＝533路节目。所以一台服务器即可对所有频道的数据备份1分钟，硬件成本增加不多。

具体的，对于缓存数据服务器的数据缓冲区，可设计成可循环缓冲区，比如按照最大缓存一分钟时间段内的数据，后面的数据会将老的数据覆盖掉，循环使用。对于录流服务功能来说只需要一直往里面写即可，写到尾部自动回转从头开始写入。

对于缓存多长时间数据的问题取决于录流任务程序的恢复时间，一般来说是都是秒级的时间跨度、但考虑到网络延迟或重启耗时时间来说，一分钟已足够。并将定义的缓冲区大小分成8段，那么读写指针的位置形式如图5所示。

S102、通过录流服务器发起补流请求，确定出待恢复数据的开始位置和结束位置；

当某台录流服务器或进程服务挂掉后，在恢复从挂掉到重新派发时间段内的数据时，首先通过录流服务器发起补流请求，并确定出待恢复数据的开始位置和结束位置。

S103、缓存数据服务器接收补流请求，基于开始位置和结束位置得到内存缓冲区的对应位置；

然后通过缓存数据服务器接收补流请求，在缓存数据服务器接收补流请求后，根据开始位置和结束位置在内存缓冲中查找到对应的位置。

S104、提取内存缓冲区的对应位置的数据，更新文件索引信息。

在得到内存缓冲区的对应位置后，根据补流请求的文件路径将文件打开并写入需要补齐的数据，写入完毕后更新相应的描述信息结构，即完成整个数据的补流操作。

综上所述，在上述实施例中，当需要对直播录流进行容灾处理时，通过缓存数据服务器接收组播数据，并将组播数据缓存至内存缓冲区，通过录流服务器发起补流请求，确定出待恢复数据的开始位置和结束位置；缓存数据服务器接收补流请求，基于开始位置和结束位置得到内存缓冲区的对应位置；提取内存缓冲区的对应位置的数据，更新文件索引信息。本发明能够简单有效的实现容灾数据流的恢复。

如图2所示，为本发明公开的一种直播录流容灾处理方法实施例2的流程图，所述方法可以包括以下步骤：

S201、通过缓存数据服务器接收组播数据，并将组播数据缓存至内存缓冲区；

当需要对直播录流进行容灾处理时，通过增加缓存数据服务器来实现接收组播数据，并将组播数据缓存至内存缓冲区。

根据实际测试，每台缓存数据服务器可实时处理300多路的频道节目录流工作，接收到组播数据流后直接缓存在内存中。无论是CPU使用率还是IO利用率都很低。假如每个频道节目高清16Mbps码率，缓存1分钟数据则需要的内存空间：16Mbps*60＝960Mb≈120MB。根据缓存数据服务器的64G内存可容纳的频道节目数：64G/120MB＝533路节目。所以一台服务器即可对所有频道的数据备份1分钟，硬件成本增加不多。

具体的，对于缓存数据服务器的数据缓冲区，可设计成可循环缓冲区，比如按照最大缓存一分钟时间段内的数据，后面的数据会将老的数据覆盖掉，循环使用。对于录流服务功能来说只需要一直往里面写即可，写到尾部自动回转从头开始写入。

对于缓存多长时间数据的问题取决于录流任务程序的恢复时间，一般来说是都是秒级的时间跨度、但考虑到网络延迟或重启耗时时间来说，一分钟已足够。并将定义的缓冲区大小分成8段，那么读写指针的位置形式如图5所示。

S202、通过录流服务器发起补流请求，录流服务器读取上一次断流的最后一个TS包作为开始位置，读取开始重新录流的第一个TS包作为结束位置；

当某台录流服务器或进程服务挂掉后，在恢复从挂掉到重新派发时间段内的数据时，首先通过录流服务器发起补流请求，并使用TS包进行数据比较匹配，录流服务器读取上一次断流的最后一个TS包作为开始位置，读取开始重新录流的第一个TS包作为结束位置，并读取上一个录流的文件路径。

S103、缓存数据服务器接收补流请求，基于开始位置和结束位置，通过内存数据比较函数确定出内存缓冲区的对应位置；

然后通过缓存数据服务器接收补流请求，在缓存数据服务器接收补流请求后，根据开始位置及结束位置在内存缓冲中查找到对应的位置、搜索可根据TS包长度的特性，每个TS包长度都是188固定长，直接使用内存数据比较函数对整个数据进行比较，快速的定位到相应的内存缓冲区中的位置。具体的，可以优化只匹配TS包头的16个字节，其中有4字节的TS包头，可确认属于相同的PID指示数据，后面的12字节是为了区分不同的数据包，两个TS包的数据相同的可能情况几乎没有。读入数据都是以188字节对齐读写操作，从而简化读写及补齐的操作，可以快速的查找及匹配的模式操作。

S104、提取内存缓冲区的对应位置的数据，更新文件索引信息。

在得到内存缓冲区的对应位置后，根据补流请求的文件路径将文件打开并写入需要补齐的数据，写入完毕后更新相应的描述信息结构，即完成整个数据的补流操作。

对于一个频道的录流，如果一切正常的话，则整天24小时只会录制写入到同一个文件，当发生故障时，由于数据补齐的操作与录流为异步行为，且预先并不知道需要补齐多长的数据，所以为了尽快的将数据存盘就有一个流描述文件。比如先写的文件名是1.ts、后面发生故障后重新写入的文件是2.ts、则发生补齐的数据是追加写入到文件1.ts中，并将相关的信息比如文件名，长度、后续的文件信息写入到流的描述文件中。同样的正在录制2.ts文件时发生故障再另起3.ts即可，追加补写入2.ts即可。

所以流的描述文件需要按照录制的时间顺序记录下流的名称、起始字节、文件长度、起始和结束PTS时间。

那么当由CDN分发数据到下级子节点，则将整个TS流拼接起来，通过流的描述文件将所有的TS流合成一个文件。

下面以具体的实例进一步对直播录流容灾进行详细说明：

1、读取最后存储系统文件比如1.ts的最后3个TS流，总共3*188＝564B字节，这段内容找到的位置即开始位置start_pos。

2、读取重新录制的文件比如2.ts的最开始的3个TS流，总共3*188＝564B字节，这段内容找到的位置即结束位置end_pos。

3、发起内容补流请求，将两块数据及需要追加写的文件1.ts发给缓存数据服务器。

4、缓存数据服务器接收到start_data/end_data/1.ts这几个参数，定位到频道节目所属的循环缓冲区、通过数据的一一比较找到start_pos/end_pos位置，然后将循环缓冲区中的数据写到需要补齐的文件1.ts的最后面，同时更新一下流的描述文件。

通过以上的操作，补齐的数据操作完成，那个多个文件1.ts、2.ts、...n.ts都将是一个完整码流，从而解决某台录流服务器宕机造成的数据丢失问题。

如图3所示，为本发明公开的一种直播录流容灾处理系统实施例1的结构示意图，所述系统可以包括：

缓存数据服务器，用于接收组播数据，并将组播数据缓存至内存缓冲区；

当需要对直播录流进行容灾处理时，通过增加缓存数据服务器来实现接收组播数据，并将组播数据缓存至内存缓冲区。

根据实际测试，每台缓存数据服务器可实时处理300多路的频道节目录流工作，接收到组播数据流后直接缓存在内存中。无论是CPU使用率还是IO利用率都很低。假如每个频道节目高清16Mbps码率，缓存1分钟数据则需要的内存空间：16Mbps*60＝960Mb≈120MB。根据缓存数据服务器的64G内存可容纳的频道节目数：64G/120MB＝533路节目。所以一台服务器即可对所有频道的数据备份1分钟，硬件成本增加不多。

具体的，对于缓存数据服务器的数据缓冲区，可设计成可循环缓冲区，比如按照最大缓存一分钟时间段内的数据，后面的数据会将老的数据覆盖掉，循环使用。对于录流服务功能来说只需要一直往里面写即可，写到尾部自动回转从头开始写入。

对于缓存多长时间数据的问题取决于录流任务程序的恢复时间，一般来说是都是秒级的时间跨度、但考虑到网络延迟或重启耗时时间来说，一分钟已足够。并将定义的缓冲区大小分成8段，那么读写指针的位置形式如图5所示。

录流服务器，用于发起补流请求，确定出待恢复数据的开始位置和结束位置；

当某台录流服务器或进程服务挂掉后，在恢复从挂掉到重新派发时间段内的数据时，首先通过录流服务器发起补流请求，并确定出待恢复数据的开始位置和结束位置。

缓存数据服务器，还用于接收所述补流请求，基于所述开始位置和结束位置得到内存缓冲区的对应位置；

然后通过缓存数据服务器接收补流请求，在缓存数据服务器接收补流请求后，根据开始位置和结束位置在内存缓冲中查找到对应的位置。

缓存数据服务器，还用于提取所述内存缓冲区的对应位置的数据，更新文件索引信息。

在得到内存缓冲区的对应位置后，根据补流请求的文件路径将文件打开并写入需要补齐的数据，写入完毕后更新相应的描述信息结构，即完成整个数据的补流操作。

综上所述，在上述实施例中，当需要对直播录流进行容灾处理时，通过缓存数据服务器接收组播数据，并将组播数据缓存至内存缓冲区，通过录流服务器发起补流请求，确定出待恢复数据的开始位置和结束位置；缓存数据服务器接收补流请求，基于开始位置和结束位置得到内存缓冲区的对应位置；提取内存缓冲区的对应位置的数据，更新文件索引信息。本发明能够简单有效的实现容灾数据流的恢复。

如图4所示，为本发明公开的一种直播录流容灾处理系统实施例2的结构示意图，所述系统可以包括：

缓存数据服务器，用于接收组播数据，并将组播数据缓存至内存缓冲区；

当需要对直播录流进行容灾处理时，通过增加缓存数据服务器来实现接收组播数据，并将组播数据缓存至内存缓冲区。

根据实际测试，每台缓存数据服务器可实时处理300多路的频道节目录流工作，接收到组播数据流后直接缓存在内存中。无论是CPU使用率还是IO利用率都很低。假如每个频道节目高清16Mbps码率，缓存1分钟数据则需要的内存空间：16Mbps*60＝960Mb≈120MB。根据缓存数据服务器的64G内存可容纳的频道节目数：64G/120MB＝533路节目。所以一台服务器即可对所有频道的数据备份1分钟，硬件成本增加不多。

具体的，对于缓存数据服务器的数据缓冲区，可设计成可循环缓冲区，比如按照最大缓存一分钟时间段内的数据，后面的数据会将老的数据覆盖掉，循环使用。对于录流服务功能来说只需要一直往里面写即可，写到尾部自动回转从头开始写入。

对于缓存多长时间数据的问题取决于录流任务程序的恢复时间，一般来说是都是秒级的时间跨度、但考虑到网络延迟或重启耗时时间来说，一分钟已足够。并将定义的缓冲区大小分成8段，那么读写指针的位置形式如图5所示。

录流服务器，用于发起补流请求，读取上一次断流的最后一个TS包作为开始位置，读取开始重新录流的第一个TS包作为结束位置；

当某台录流服务器或进程服务挂掉后，在恢复从挂掉到重新派发时间段内的数据时，首先通过录流服务器发起补流请求，并使用TS包进行数据比较匹配，录流服务器读取上一次断流的最后一个TS包作为开始位置，读取开始重新录流的第一个TS包作为结束位置，并读取上一个录流的文件路径。

缓存数据服务器，还用于接收所述补流请求，基于开始位置和结束位置，通过内存数据比较函数确定出内存缓冲区的对应位置；

然后通过缓存数据服务器接收补流请求，在缓存数据服务器接收补流请求后，根据开始位置及结束位置在内存缓冲中查找到对应的位置、搜索可根据TS包长度的特性，每个TS包长度都是188固定长，直接使用内存数据比较函数对整个数据进行比较，快速的定位到相应的内存缓冲区中的位置。具体的，可以优化只匹配TS包头的16个字节，其中有4字节的TS包头，可确认属于相同的PID指示数据，后面的12字节是为了区分不同的数据包，两个TS包的数据相同的可能情况几乎没有。读入数据都是以188字节对齐读写操作，从而简化读写及补齐的操作，可以快速的查找及匹配的模式操作。

缓存数据服务器，还用于提取所述内存缓冲区的对应位置的数据，更新文件索引信息。

在得到内存缓冲区的对应位置后，根据补流请求的文件路径将文件打开并写入需要补齐的数据，写入完毕后更新相应的描述信息结构，即完成整个数据的补流操作。

对于一个频道的录流，如果一切正常的话，则整天24小时只会录制写入到同一个文件，当发生故障时，由于数据补齐的操作与录流为异步行为，且预先并不知道需要补齐多长的数据，所以为了尽快的将数据存盘就有一个流描述文件。比如先写的文件名是1.ts、后面发生故障后重新写入的文件是2.ts、则发生补齐的数据是追加写入到文件1.ts中，并将相关的信息比如文件名，长度、后续的文件信息写入到流的描述文件中。同样的正在录制2.ts文件时发生故障再另起3.ts即可，追加补写入2.ts即可。

所以流的描述文件需要按照录制的时间顺序记录下流的名称、起始字节、文件长度、起始和结束PTS时间。

那么当由CDN分发数据到下级子节点，则将整个TS流拼接起来，通过流的描述文件将所有的TS流合成一个文件。

本说明书中各个实施例采用递进的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似部分互相参见即可。对于实施例公开的装置而言，由于其与实施例公开的方法相对应，所以描述的比较简单，相关之处参见方法部分说明即可。

专业人员还可以进一步意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件、计算机软件或者二者的结合来实现，为了清楚地说明硬件和软件的可互换性，在上述说明中已经按照功能一般性地描述了各示例的组成及步骤。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本发明的范围。

结合本文中所公开的实施例描述的方法或算法的步骤可以直接用硬件、处理器执行的软件模块，或者二者的结合来实施。软件模块可以置于随机存储器(RAM)、内存、只读存储器(ROM)、电可编程ROM、电可擦除可编程ROM、寄存器、硬盘、可移动磁盘、CD-ROM、或技术领域内所公知的任意其它形式的存储介质中。

对所公开的实施例的上述说明，使本领域专业技术人员能够实现或使用本发明。对这些实施例的多种修改对本领域的专业技术人员来说将是显而易见的，本文中所定义的一般原理可以在不脱离本发明的精神或范围的情况下，在其它实施例中实现。因此，本发明将不会被限制于本文所示的这些实施例，而是要符合与本文所公开的原理和新颖特点相一致的最宽的范围。

Claims (4)

1.一种直播录流容灾处理方法，其特征在于，包括：

通过缓存数据服务器接收组播数据，并将所述组播数据缓存至内存缓冲区，所述内存缓冲区为可循环缓冲区；所述缓存数据服务器缓存所有频道的录流；

通过录流服务器发起补流请求，确定出待恢复数据的开始位置和结束位置，包括：通过录流服务器发起补流请求，所述录流服务器读取上一次断流的最后一个TS包作为开始位置，读取开始重新录流的第一个TS包作为结束位置；

所述缓存数据服务器接收所述补流请求，基于所述开始位置和结束位置得到内存缓冲区的对应位置；

提取所述内存缓冲区的对应位置的数据，更新文件索引信息。

2.根据权利要求1所述的方法，其特征在于，所述缓存数据服务器接收所述补流请求，基于所述开始位置和结束位置得到内存缓冲区的对应位置，包括：

缓存数据服务器接收所述补流请求，基于所述开始位置和结束位置，通过内存数据比较函数确定出内存缓冲区的对应位置。

3.一种直播录流容灾处理系统，其特征在于，包括：

缓存数据服务器，用于接收组播数据，并将所述组播数据缓存至内存缓冲区，所述内存缓冲区为可循环缓冲区；所述缓存数据服务器缓存所有频道的录流；

录流服务器，用于发起补流请求，确定出待恢复数据的开始位置和结束位置；

所述缓存数据服务器，还用于接收所述补流请求，基于所述开始位置和结束位置得到内存缓冲区的对应位置；

所述缓存数据服务器，还用于提取所述内存缓冲区的对应位置的数据，更新文件索引信息；

所述录流服务器在执行发起补流请求，确定出待恢复数据的开始位置和结束位置时，具体用于：发起补流请求，读取上一次断流的最后一个TS包作为开始位置，读取开始重新录流的第一个TS包作为结束位置。

4.根据权利要求3所述的系统，其特征在于，所述缓存数据服务器在执行接收所述补流请求，基于所述开始位置和结束位置得到内存缓冲区的对应位置时，具体用于：

缓存数据服务器接收所述补流请求，基于所述开始位置和结束位置，通过内存数据比较函数确定出内存缓冲区的对应位置。