视频监控系统及其控制方法与流程

本发明涉及视频监控技术领域，具体而言，涉及一种视频监控系统及其控制方法。

背景技术：

安防视频监控是重要的技术防范手段，广泛应用在公安、金融、建筑、交通等领域。多年来，政府和社会各界持续投入建设视频监控工程，目前的视频监控系统具有以下特点：设备存量大、协议类型多、系统规模大、联网环境复杂。

视频监控系统主要由视频获取端、服务器和客户端组成，为满足安防要求，视频监控系统的稳定性和服务器的高利用率是重要评价指标，其中视频监控系统的稳定性最为关键，直接影响视频监控系统功能的发挥。

目前业内主要通过守护进程和主从机热备等多种方式提高视频监控系统的工作稳定性，然而，现有技术普遍存在一个问题，难以在服务器稳定性和利用率这两点之间取得平衡，比如，利用守护进程保证服务器的稳定性时，需要开发部分资源维护守护进程，服务器利用率变低；利用主从机热备方式保证服务器的稳定性时，主机运行，从机处于待用状态，服务器利用率低。

针对现有技术中视频监控系统难以在服务器稳定性和利用率这两点之间取得平衡的问题，目前尚未有很好的解决方案。

技术实现要素：

有鉴于此，本发明的目的在于提供一种视频监控系统及其控制方法，能够在服务器稳定性和利用率这两点之间取得平衡。

第一方面，本发明实施例提供了一种视频监控系统，包括多个监控端、多个服务器和客户端，每个所述服务器对应至少一个所述监控端；每个所述监控端均用于，采集视频数据；所述客户端用于，获取用户的操作请求并发送至一所述服务器，其中，所述操作请求对应一所述监控端，包括监控端配置请求和/或视频获取请求；每个所述服务器均用于，在接收到所述操作请求后，判定所述操作请求对应的所述监控端是否为自身对应的所述监控端，若是，则将所述操作请求发送至自身对应的所述监控端，否则，将所述操作请求转发至其余的所述服务器，并在重复接收到所述操作请求时，将所述操作请求发送至所述操作请求相对应的所述监控端。

结合第一方面，本发明实施例提供了第一方面第一种可能的实施方式，其中，所述客户端具体用于，根据所述操作请求对应的所述监控端、每个所述服务器与每个所述监控端之间的对应关系，确定所述操作请求对应的所述服务器，若确定的所述服务器可用，则将所述操作请求发送至确定的所述服务器，否则，按照预设规则将所述操作请求发送至一可用的所述服务器。

结合第一方面，本发明实施例提供了第一方面第二种可能的实施方式，其中，所有所述服务器采用单向循环顺序依次建立连接，每个所述服务器具体用于，在判定所述操作请求对应的所述监控端与自身不相对应时，按照所述单向循环顺序将所述操作请求转发至下一所述服务器。

结合第一方面，本发明实施例提供了第一方面第三种可能的实施方式，其中，每个所述服务器在判定所述操作请求对应的所述监控端是否为自身对应的所述监控端之前，还用于依次判定所述操作请求是否为流媒体请求、是否满足负载要求以及是否符合流复用条件，若判定所述操作请求为流媒体请求、满足负载要求、且不满足流复用条件，则判定所述操作请求对应的所述监控端是否为自身对应的所述监控端。

结合第一方面第三种可能的实施方式，本发明实施例提供了第一方面第四种可能的实施方式，其中，每个所述服务器还用于，若判定所述操作请求不为流媒体请求，则判定所述操作请求对应的所述监控端是否为自身对应的所述监控端。

结合第一方面第三种可能的实施方式，本发明实施例提供了第一方面第五种可能的实施方式，其中，每个所述服务器还用于，若判定所述操作请求为流媒体请求且不满足负载条件，则判定是否重复接收到所述操作请求，若是，则通知所述客户端请求失败，否则，将所述操作请求转发至其余所述服务器。

结合第一方面第三种可能的实施方式，本发明实施例提供了第一方面第六种可能的实施方式，其中，每个所述服务器还用于，若判定所述操作请求为流媒体请求、满足负载要求、且满足流复用条件，则进行流复用转发。

结合第一方面，本发明实施例提供了第一方面第七种可能的实施方式，其中，每个所述监控端均具有第一标识，每个所述服务器均具有第二标识，每个所述监控端的所述第一标识的数量等于每个所述监控端的允许接入次数。

结合第一方面第七种可能的实施方式，本发明实施例提供了第一方面第八种可能的实施方式，其中，每个所述第一标识和每个所述第二标识均包括数字，每个所述服务器与每个所述监控端的对应关系根据所述第一标识、所述第二标识、所有所述服务器的数量确定。

结合第一方面第二种可能的实施方式，本发明实施例提供了第一方面第九种可能的实施方式，其中，每个所述服务器还用于，接收所述客户端发送的配置更新请求，根据所述配置更新请求更新自身的配置信息，并按照所述单向循环顺序将所述配置更新请求转发至下一所述服务器，在重复接收到所述配置更新请求时，确定更新完成，计算更新后每个所述服务器与每个所述监控端之间的对应关系。

结合第一方面第二种可能的实施方式，本发明实施例提供了第一方面第十种可能的实施方式，其中，所有所述服务器之间的单向循环顺序采用单向循环链表记录，采用在所述单向循环链表中删除和/或添加所述服务器的方式变更所有所述服务器之间的单向循环顺序。

第二方面，本发明实施例提供了一种视频监控系统的控制方法，所述视频监控系统为上述第一方面所述的视频监控系统，所述控制方法由所述服务器执行，包括：在接收到所述操作请求后，判定所述操作请求对应的所述监控端是否为自身对应的所述监控端；若是，则将所述操作请求发送至自身对应的所述监控端，否则，将所述操作请求转发至其余的所述服务器，并在重复接收到所述操作请求时，将所述操作请求发送至所述操作请求相对应的所述监控端。

本发明实施例中，设置视频监控系统包括多个监控端、多个服务器和客户端，并设置每个服务器对应至少一个监控端；在服务器接收到用户的操作请求时，判定该操作请求对应的监控端是否为自身对应的监控端，若是，则将该操作请求发送至自身对应的监控端，否则，将该操作请求转发至其余的服务器，并在重复接收到该操作请求时，将该操作请求发送至该操作请求相对应的监控端。通过本发明实施例中的视频监控系统及其控制方法，多个服务器均参与到系统工作中，服务器利用率高，采用多个服务器的架构，当与某个监控端对应的服务器故障时，还能够由其他服务器处理该针对该监控端的操作请求，从而提高系统工作的稳定性，因此本实施例中的视频监控系统及其控制方法，能够在服务器稳定性和利用率这两点之间取得平衡，避免现有技术中视频监控系统稳定性高而服务器利用率低的问题。

为使本发明的上述目的、特征和优点能更明显易懂，下文特举较佳实施例，并配合所附附图，作详细说明如下。

附图说明

为了更清楚地说明本发明实施例的技术方案，下面将对实施例中所需要使用的附图作简单地介绍，应当理解，以下附图仅示出了本发明的某些实施例，因此不应被看作是对范围的限定，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他相关的附图。

图1为本发明第一实施例提供的视频监控系统的结构示意图；

图2为本发明第一实施例提供的监控端的第一标识设置示意图；

图3为本发明第一实施例提供的服务器之间的连接关系示意图；

图4为本发明第一实施例提供的服务器配置变更示意图；

图5为本发明第一实施例提供的服务器配置变更流程图；

图6为本发明第一实施例提供的服务器端的操作请求处理流程示意图；

图7为本发明第二实施例提供的视频监控系统的控制方法的流程示意图。

具体实施方式

为使本发明实施例的目的、技术方案和优点更加清楚，下面将结合本发明实施例中附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。通常在此处附图中描述和示出的本发明实施例的组件可以以各种不同的配置来布置和设计。因此，以下对在附图中提供的本发明的实施例的详细描述并非旨在限制要求保护的本发明的范围，而是仅仅表示本发明的选定实施例。基于本发明的实施例，本领域技术人员在没有做出创造性劳动的前提下所获得的所有其他实施例，都属于本发明保护的范围。

考虑到现有技术中视频监控系统难以在服务器200稳定性和利用率这两点之间取得平衡，本发明提供了一种视频监控系统及其控制方法，能够在服务器200稳定性和利用率这两点之间取得平衡，下面结合实施例进行具体说明。

实施例一

本发明第一实施例提供了一种视频监控系统，图1为本发明第一实施例提供的视频监控系统的结构示意图，如图1所示，该系统包括：多个监控端100、多个服务器200和客户端300，每个服务器200对应至少一个监控端100，客户端300可以为多个；

每个监控端100均用于，采集视频数据；

客户端300用于，获取用户的操作请求并发送至一服务器200，其中，该操作请求对应一监控端100，包括监控端配置请求和/或视频获取请求；

每个服务器200均用于，在接收到该操作请求后，判定该操作请求对应的监控端100是否为自身对应的监控端100，若是，则将该操作请求发送至自身对应的监控端100，否则，将该操作请求转发至其余的服务器200，并在重复接收到该操作请求时，将该操作请求发送至该操作请求相对应的监控端100。

本发明实施例中，设置视频监控系统包括多个监控端100、多个服务器200和客户端300，并设置每个服务器200对应至少一个监控端100；在服务器200接收到用户的操作请求时，判定该操作请求对应的监控端100是否为自身对应的监控端100，若是，则将该操作请求发送至自身对应的监控端100，否则，将该操作请求转发至其余的服务器200，并在重复接收到该操作请求时，将该操作请求发送至该操作请求相对应的监控端100。通过本发明实施例中的系统，多个服务器200均参与到系统工作中，服务器200利用率高，采用多个服务器200的架构，当与某个监控端100对应的服务器200故障时，还能够由其他服务器200处理该针对该监控端100的操作请求，从而提高系统工作的稳定性，因此本实施例中的系统能够在服务器稳定性和利用率这两点之间取得平衡，避免现有技术中视频监控系统稳定性高而服务器利用率低的问题。

本实施例中，监控端100包括音视频采集设备、编码设备、解码设备以及显示装置等，具体可以为监控摄像机、解码器、监控平台等发送或接收消息和媒体流的装置。比如，监控端100设置于电梯间、消防通道等处，包括摄像头和编码设备，用于采集电梯间、消防通道等处的视频数据。

本实施例中，客户端300包括手机、电脑等终端设备，用于将用户操作转换成计算机指令序列，也即根据用户操作生成操作请求，并将该操作请求发送至一服务器200。客户端300还用于接收处理服务器200返回的信息和媒体数据。

本实施例中，服务器200上运行有服务软件，服务器200运行服务软件，用于接收客户端300发送的操作请求，执行该操作请求，控制监控端100做出响应。比如，操作请求为监控端配置请求，则服务器200根据该监控端配置请求控制监控端100进行配置，又如，操作请求为视频获取请求，则服务器200根据该视频获取请求从监控端100处获取监控端100采集的视频数据。

本实施例中，客户端300与服务器200通信，服务器200与监控端100通信。每个服务器200可以称为一个服务节点，任何一个服务器200的处理逻辑都一样，不考虑服务器200的硬件差异以及通信端口的不同，系统中的服务器200之间是全对称的，这种全对称的结构能够保证每个服务器200均得到充分利用，从而提高所有服务器200的利用率。

服务器200需要基于一些配置信息来运行，配置信息是整套系统运行的基础，主要包括:监控端100的访问和控制信息，全部服务器200的通信信息。服务器200根据监控端100的配置信息可以实现对监控端100的访问，根据全部服务器200的信息实现调度逻辑。客户端300接入本实施例中的系统后，获取部分配置信息(主要是监控端配置信息和服务器配置信息)，以此为依据向目标服务器200发起操作请求。

为便于监控端100的管理，本实施例中，每个监控端100均具有第一标识，且每个监控端100的第一标识的数量等于每个监控端100的允许接入次数。

对于每个监控端100而言，第一标识由两部分组成，一部分为监控端100的设备序号，一部分为监控端100的接入序号，其中设备序号采用单调递增规则设置，每个监控端100的设备序号均不相同，接入序号采用单调递增规则设置，每个监控端100的接入序号均不同。在系统中采用有序队列保存每个监控端100的第一标识。在添加新的监控端100时，按照设备序号单调递增规则为该新增加的监控端100分配设备序号，按照接入序号单调递增规则为其分配接入序号。在系统中，当某个监控端100被删除，如暂时不用或者永久不用时，其占用的第一标识不被释放。

图2为本发明第一实施例提供的监控端100的第一标识设置示意图，如图2所示，S表示接入序号，D表示设备序号，S1-D1表示设备序号为D1的监控端100第一次接入系统，虚线框中的监控端100表示从系统中删除，图中左侧的监控端100被接入系统中。

根据前述，当一个监控端100支持多次接入时，其具有两个第一标识，比如，S1-D1,S2-D1，表示设备序号为D1的监控端100的两次接入记录。同样，如果某个监控端100被删除，与其相关的记录都要删除，比如S5-D3，S6-D3同时删除。

本实施例中第一标识的具体生成能够用以下伪代码表示：

/*********

功能：生成监控端100在系统中的序列号，即监控端100的唯一标识。

IN DeviceInfo根据监控端100情况配置的，监控端100可以被同时接入的次数上限(该上限根是根据监控端100实际的接入能力配置的)

IN ServerNode服务器200序列

*********/

void GenerateDeviceSerialNum(DeviceInfo,ServerNodeQueue,)

{

//每个监控端100占用几个连续的序号

//DeviceInfo.AccessLimit是根据监控端100情况配置的，监控端100支持的同时接入次数上限

//ServerNodeQueue.size是服务器200队列的长度

INT SerialInterval＝Min(DeviceInfo.AccessLimit,ServerNodeQueue.size)；

UpdateDeviceQueue(SerialInterval,DeviceInfo)；

}。

本实施例中，每个服务器200均具有第二标识，该第二标识用于标识每个服务器200。优选地，每个第一标识和每个第二标识均包括数字，如用序号1、2、3的形式表示每个服务器200的第二标识。本实施例中，所有服务器200采用单向循环顺序依次建立连接，所有服务器200之间的单向循环顺序采用单向循环链表记录。

图3为服务器200之间的连接关系示意图，图3中，SNi为第二标识，其中i为数字，如图3所示，采用单向循环链表记录服务器200的配置。服务器200的配置信息是全局同步的。在完成一次配置之后，该单向循环链表就固定并唯一，如果出现某个服务器200失效的情况，则将该服务器200的状态修改为不可用，(服务器200和客户端300通过通信协议判断其他服务器200的有效性，并在各自程序里做标注)，系统不会在该单向循环链表中自动删除该服务器200，失效的服务器200恢复响应之后，还能继续工作。每个服务器200和客户端300都能获取到这份服务配置(即图3中的所有服务器之间的连接关系)。客户端300可以结合操作请求对应的监控端100、监控端100与服务器200之间的对应关系，判断出向哪个服务器200发起操作请求。服务器200可以根据该单向循环链表，决定操作请求的转发目标。

本实施例中，每个服务器200与每个监控端100的对应关系根据第一标识、第二标识、所有服务器200的数量确定。

具体地，为了提高系统处理效率，将监控端100和服务器200进行“弱绑定”。这种绑定关系是根据服务器200和监控端100的标识进行计算的，当客户端300获获取到全部监控端100的第一标识和服务器200的第二标识后，就可以计算每个监控端100与每个服务器200之间的对应关系。

对应关系的计算公式：ServerIndex＝DeviceSerialNum％ServerNodeQueue.size。该公式中，ServerIndex表示服务器200的第二标识的下标，DeviceSerialNum为监控端100第一标识中的设备序号，％是求余数计算描述符，ServerNodeQueue.size是单向循环链表的长度，也即所有服务器的数量。

本实施例中，基于上述所有服务器200之间的单向循环关系，还能够采用在上述的单向循环链表中删除和/或添加服务器200的方式变更所有服务器200之间的单向循环顺序。

图4为本实施例提供的服务器200配置变更示意图，如图4所示，将当前服务器200之间的单向循环关系进行修改，修改时采用在上述的单向循环链表中删除和/或添加服务器200的方式实现。本实施例中在修改服务器200之间的配置关系时，基于所有服务器200之间的单向循环关系，能够保证在配置变更的过渡期，或者使用过时配置信息访问服务器200的情况下，也能成功执行指令。本实施例支持的配置行为包括添加和删除(不支持修改操作，修改可以通过删除和添加的组合来实现)。

如图4所示，在更新配置的过程中存在短暂的中间状态，比如某个服务器200(以上图中的SN₂为例)配置信息是过时的，对于该服务器200而言，后继的服务器200SN₃还存在，但是由于实际上SN₃服务进程已经退出，也就不会再响应请求，所有的请求转发给SN₄。对于新添加的SN₆来说，SN₂的过期配置中，SN₆并不存在，也就不会接收到新的响应。

本实施例中，服务器200修改配置信息(即服务器之间连接关系)的过程为：服务器200接收客户端300发送的配置更新请求，根据配置更新请求更新自身的配置信息，并按照上述单向循环顺序将配置更新请求转发至下一服务器200，在重复接收到该配置更新请求时，确定更新完成，计算更新后每个服务器200与每个监控端100之间的对应关系。

图5为本实施例提供的服务器200配置变更流程图，如图5所示，服务器200配置变更流程为：

步骤S501，服务器200接收更新服务器配置的请求。

步骤S502，服务器200更新自身的配置。

步骤S503，服务器200按照已有的单向循环顺序，将更新服务器配置的请求转发至下一服务器200。

步骤S504，判断是否再次接收到该更新服务器配置的请求，若是，执行步骤S505，否则，循环本步骤。

步骤S505，根据更新后的服务器配置重新计算每个服务器200与每个监控端100的对应关系。

需要说明的是，服务器200收到更新服务器配置的请求后，所有服务器200和客户端300并不会马上重新计算服务器200和监控端100的对应关系，要等到所有正常运行的服务器200全部完成配置更新，服务器200才会重新计算服务器200和监控端100的对应关系，并且通知各个登录的客户端300更新配置。

基于上述的监控端100与服务器200之间的对应关系，服务器200与监控端100采用对应关系，每个服务器200至少对应一个监控端100。客户端300上显示有服务器列表，该列表中标注有每个服务器200的图标，且标注有每个服务器200的状态，即该服务器200是可用还是不可用。当客户端300向服务器200发送操作请求，且该操作请求是针对某个监控端100时，客户端300的处理方式为，获取该操作请求，根据获取的操作请求对应的监控端100、每个服务器200与每个监控端100之间的对应关系，确定获取的操作请求对应的服务器200，若确定的服务器200可用，则将操作请求发送至确定的服务器200，否则，按照预设规则将操作请求发送至一可用的服务器200。

上述预设规则可以为预先指定一个服务器200，如列表中第一个服务器200，在操作请求对应的服务器200不可用时，将该操作请求发送至预先指定的服务器200。预设规则还可以为，当操作请求对应的服务器200不可用时，在服务器200列表中随机选择一个可用的服务器200，将该操作请求发送至该随机选择的可用的服务器200。上述所指的服务器200不可用，包括服务器200单点故障、服务器200调试、服务器200未接入本实施例中的系统等情况。

基于上述的监控端100与服务器200之间的对应关系，每个服务器200在接收到操作请求后，判定该操作请求对应的监控端100是否为自身对应的监控端100，若是，则将该操作请求发送至自身对应的监控端100，否则，按照上述的单向循环顺序将该操作请求转发至下一服务器200。

按照这种方式，当与操作请求对应的服务器200处于不可用状态时，则客户端300按照预设规则确定接收该操作请求的服务器200，该服务器200接收到该操作请求后，将按照上述的单向循环顺序将操作请求发送至下一服务器200，由于与操作请求对应的服务器200处于不可用状态，因此该操作请求将始终在所有可用的服务器200之间流转，在操作请求的流转过程中，每个服务器200在接收到该操作请求时，都判断是否为重复接收到该操作请求，当该操作请求流转过所有服务器200后，最开始接收到该操作请求的服务器200将判定重复接收到该操作请求，则最开始接收到该操作请求的服务器200，将该操作请求发送至该操作请求相对应的监控端100，以使该操作请求得到处理。

图6为本实施例提供的服务器200端的操作请求处理流程示意图。如图6所示，每个服务器200在判定接收到的操作请求对应的监控端100是否为自身对应的监控端100之前，还用于依次判定该操作请求是否为流媒体请求、是否满足负载要求以及是否符合流复用条件，若该操作请求为流媒体请求、满足负载要求、且不满足流复用条件，则判定该操作请求对应的监控端100是否为自身对应的监控端100。

如图6所示，每个服务器200还用于，若判定接收到的操作请求不为流媒体请求，则判定该操作请求对应的监控端100是否为自身对应的监控端100。

如图6所示，每个服务器200还用于，若判定操作请求为流媒体请求且不满足负载条件，则判定是否重复接收到该操作请求(也即该操作请求是否在所有服务器间流转一轮)，若是，则通知客户端300请求失败，否则，将该操作请求转发至其余服务器200。具体地，按照服务器200之间的配置关系将操作请求转发至下一服务器200。

如图6所示，每个服务器200还用于，若判定接收到的操作请求为流媒体请求、满足负载要求、且满足流复用条件，则进行流复用转发。

具体地，客户端300发送操作请求：客户端300根据监控端100与服务器200之间的对应关系，确定该操作请求对应的服务器200，由于一个监控端100能够多次接入，因此一个监控端100可能归属多个连续的服务器200，此时客户端300每次尝试向第一个服务器200发起请求，如果与第一个服务器200通信失败，则向下一个服务器200发起请求，以此类推。

对图6中的流程做详细说明。视频监控系统的操作请求分为两大类，一种是请求控制流媒体传输，另一种是获取、设置监控端配置信息。图6步骤S601中，服务器200首先要对接收到的操作请求进行判断，如果判断是流媒体相关的请求，是则执行步骤S602，判断当前服务器200是否满足负载条件，若不满足，则执行步骤S603，,继续判断该操作请求是否已经在所有服务器200间流转过一轮，本步骤中判断是否重复接收到该操作请求，若是，则确定该操作请求是否已经在所有服务器200间流转过一轮，否则，确定未流转过一轮。若该操作请求已经在所有服务器200间流转过一轮，则认为没有服务器200能够处理该操作请求，执行步骤S604，向客户端300返回失败，若该操作请求未在所有服务器200间流转过一轮，则执行步骤S605，按照之前定义的单向循环顺序继续向下一服务器200转发该操作请求。

步骤S602中，如果判断满足负载要求，则执行步骤S606，判断该操作请求是否符合流复用的条件。其中流复用，是指服务器200只向监控端100获取一次实时流，客户端300再次发起浏览请求时，会直接从服务端转发这路媒体流，这样可以有效降低监控端100的接入压力，尤其在大量并发浏览的情况下，必须使用流复用技术。若步骤S606判断符合流复用条件，则执行步骤S607，进行流转发，若步骤S606判断不符合流复用条件，则执行步骤S608，判断该操作请求对应的监控端100是否对应本服务器200，若是，则执行步骤S609，则直接向本服务器200对应的监控端100发送该操作请求，若否，则执行步骤S610，判断该操作请求是否已经在所有服务器200间流转过一轮(也即判定是否重复接收到该操作请求)，该步骤与S603相同，不再赘述。若步骤S610判断为是，则执行步骤S611，直接向该操作请求对应的监控端100发送该操作请求，若否，则执行步骤S612，按照之前定义的单向循环顺序继续向下一服务器200转发该操作请求。

图6中，若步骤S601判断操作请求不为流媒体相关请求，则转至步骤S608继续执行。

需要说明的是，本实施例中所指的“判断操作请求是否在所有服务器间流转过一轮”，其实质含义就是“判定是否重新接收到该操作请求”，因此这两种表达方式可以互换，上述内容中若有与图6不对应处，或者表达不一致处，按照“判断操作请求是否在所有服务器间流转过一轮”等同于“判断是否重新接收到该操作请求”处理即可。

需要说明的是，即使某个监控端100不属于本服务器200，也可以通过本服务器200控制该监控端100。具体地，服务器200第一次收到操作请求的时候，如果该操作请求对应的监控端100不属于本服务器200，就会向下一个服务器200转发(如果直接相邻的服务器200转发失败，则会跳过这个服务器200继续向下转发，直到转发成功为止)。因为服务器200的配置关系使用单向循环链表保存，如果全局范围内，所服务器200都未处理该操作请求，则本服务器200将会再次接收到这个操作请求，这时候，本服务器200就要临时接管该操作请求对应的监控端100，向它发起操作请求。

这种操作方式能够保证优先使用与监控端100存在对应关系的服务器200，提高请求命中率，缩短响应延时，同时又解决对应的服务器200失效的情况下，访问控制目标监控端100的问题。

综上，通过本发明实施例中的系统，多个服务器200均参与到系统工作中，服务器200利用率高，采用多个服务器200的架构，当与某个监控端100对应的服务器200故障时，还能够由其他服务器200处理该针对该监控端100的操作请求，从而提高系统工作的稳定性，因此本实施例中的系统能够在服务器稳定性和利用率这两点之间取得平衡，避免现有技术中视频监控系统稳定性高而服务器利用率低的问题。

综上，本发明实施例中的系统，至少具有以下效果：

(1)多服务器200协作，避免单点软硬件故障引发的系统瘫痪；

(2)维护和管理简单，所有服务器200全对称(每台服务器200部署和运行的程序一样)，简化了部署和降低维护成本，每个服务器都参与系统任务调度，服务器利用率高；

(3)和多机热备的方案相比，不用区分主备机，不用手动(或自动)切换主备机，所有正常运行的服务器200都能参与系统任务，充分利用硬件资源；

(4)部分服务器的失效，可能会降低整个系统的媒体转发能力，但是在余下转发负载范围内，系统能继续提供服务；

(5)规模可伸缩，本发明对服务器200的个数没有限制，不像云平台那样，需要达到一定服务器200数量才能体现技术优势。

实施例二

对应上述实施例一中的视频监控系统，本实施例还提供了一种视频监控系统的控制方法，该视频监控系统为实施例一中的视频监控系统，图7为本发明实施例提供的视频监控系统的控制方法的流程示意图，该控制方法由上述的服务器200执行，如图7所示，该控制方法包括：

步骤S701，在接收到操作请求后，判定该操作请求对应的监控端100是否为自身对应的监控端100；

步骤S702，若是，则将该操作请求发送至自身对应的监控端100，否则，将该操作请求转发至其余的服务器200，并在重复接收到该操作请求时，将该操作请求发送至该操作请求相对应的监控端100。

能够知道，该控制方法与上述的视频监控系统一一对应，具体描述可见上述的系统部分，因此这里不再赘述。

通过本发明实施例中的控制方法，多个服务器200均参与到系统工作中，服务器利用率高，采用多个服务器的架构，当与某个监控端100对应的服务器200故障时，还能够由其他服务器200处理该针对该监控端100的操作请求，从而提高系统工作的稳定性，因此本实施例中的控制方法能够在服务器稳定性和利用率这两点之间取得平衡，避免现有技术中视频监控系统稳定性高而服务器利用率低的问题。

在本发明所提供的实施例中，应该理解到，所揭露装置和方法，可以通过其它的方式实现。以上所描述的装置实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，又例如，多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些通信接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。

所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。

另外，在本发明提供的实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。

所述功能如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本发明各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，Random Access Memory)、磁碟或者光盘等各种可以存储程序代码的介质。

应注意到：相似的标号和字母在下面的附图中表示类似项，因此，一旦某一项在一个附图中被定义，则在随后的附图中不需要对其进行进一步定义和解释，此外，术语“第一”、“第二”、“第三”等仅用于区分描述，而不能理解为指示或暗示相对重要性。

最后应说明的是：以上所述实施例，仅为本发明的具体实施方式，用以说明本发明的技术方案，而非对其限制，本发明的保护范围并不局限于此，尽管参照前述实施例对本发明进行了详细的说明，本领域的普通技术人员应当理解：任何熟悉本技术领域的技术人员在本发明揭露的技术范围内，其依然可以对前述实施例所记载的技术方案进行修改或可轻易想到变化，或者对其中部分技术特征进行等同替换；而这些修改、变化或者替换，并不使相应技术方案的本质脱离本发明实施例技术方案的精神和范围。都应涵盖在本发明的保护范围之内。因此，本发明的保护范围应所述以权利要求的保护范围为准。