本發(fā)明涉及視頻監(jiān)控技術領域，具體而言，涉及一種視頻監(jiān)控系統(tǒng)及其控制方法。

背景技術：

安防視頻監(jiān)控是重要的技術防范手段，廣泛應用在公安、金融、建筑、交通等領域。多年來，政府和社會各界持續(xù)投入建設視頻監(jiān)控工程，目前的視頻監(jiān)控系統(tǒng)具有以下特點：設備存量大、協(xié)議類型多、系統(tǒng)規(guī)模大、聯(lián)網(wǎng)環(huán)境復雜。

視頻監(jiān)控系統(tǒng)主要由視頻獲取端、服務器和客戶端組成，為滿足安防要求，視頻監(jiān)控系統(tǒng)的穩(wěn)定性和服務器的高利用率是重要評價指標，其中視頻監(jiān)控系統(tǒng)的穩(wěn)定性最為關鍵，直接影響視頻監(jiān)控系統(tǒng)功能的發(fā)揮。

目前業(yè)內主要通過守護進程和主從機熱備等多種方式提高視頻監(jiān)控系統(tǒng)的工作穩(wěn)定性，然而，現(xiàn)有技術普遍存在一個問題，難以在服務器穩(wěn)定性和利用率這兩點之間取得平衡，比如，利用守護進程保證服務器的穩(wěn)定性時，需要開發(fā)部分資源維護守護進程，服務器利用率變低；利用主從機熱備方式保證服務器的穩(wěn)定性時，主機運行，從機處于待用狀態(tài)，服務器利用率低。

針對現(xiàn)有技術中視頻監(jiān)控系統(tǒng)難以在服務器穩(wěn)定性和利用率這兩點之間取得平衡的問題，目前尚未有很好的解決方案。

技術實現(xiàn)要素：

有鑒于此，本發(fā)明的目的在于提供一種視頻監(jiān)控系統(tǒng)及其控制方法，能夠在服務器穩(wěn)定性和利用率這兩點之間取得平衡。

第一方面，本發(fā)明實施例提供了一種視頻監(jiān)控系統(tǒng)，包括多個監(jiān)控端、多個服務器和客戶端，每個所述服務器對應至少一個所述監(jiān)控端；每個所述監(jiān)控端均用于，采集視頻數(shù)據(jù)；所述客戶端用于，獲取用戶的操作請求并發(fā)送至一所述服務器，其中，所述操作請求對應一所述監(jiān)控端，包括監(jiān)控端配置請求和/或視頻獲取請求；每個所述服務器均用于，在接收到所述操作請求后，判定所述操作請求對應的所述監(jiān)控端是否為自身對應的所述監(jiān)控端，若是，則將所述操作請求發(fā)送至自身對應的所述監(jiān)控端，否則，將所述操作請求轉發(fā)至其余的所述服務器，并在重復接收到所述操作請求時，將所述操作請求發(fā)送至所述操作請求相對應的所述監(jiān)控端。

結合第一方面，本發(fā)明實施例提供了第一方面第一種可能的實施方式，其中，所述客戶端具體用于，根據(jù)所述操作請求對應的所述監(jiān)控端、每個所述服務器與每個所述監(jiān)控端之間的對應關系，確定所述操作請求對應的所述服務器，若確定的所述服務器可用，則將所述操作請求發(fā)送至確定的所述服務器，否則，按照預設規(guī)則將所述操作請求發(fā)送至一可用的所述服務器。

結合第一方面，本發(fā)明實施例提供了第一方面第二種可能的實施方式，其中，所有所述服務器采用單向循環(huán)順序依次建立連接，每個所述服務器具體用于，在判定所述操作請求對應的所述監(jiān)控端與自身不相對應時，按照所述單向循環(huán)順序將所述操作請求轉發(fā)至下一所述服務器。

結合第一方面，本發(fā)明實施例提供了第一方面第三種可能的實施方式，其中，每個所述服務器在判定所述操作請求對應的所述監(jiān)控端是否為自身對應的所述監(jiān)控端之前，還用于依次判定所述操作請求是否為流媒體請求、是否滿足負載要求以及是否符合流復用條件，若判定所述操作請求為流媒體請求、滿足負載要求、且不滿足流復用條件，則判定所述操作請求對應的所述監(jiān)控端是否為自身對應的所述監(jiān)控端。

結合第一方面第三種可能的實施方式，本發(fā)明實施例提供了第一方面第四種可能的實施方式，其中，每個所述服務器還用于，若判定所述操作請求不為流媒體請求，則判定所述操作請求對應的所述監(jiān)控端是否為自身對應的所述監(jiān)控端。

結合第一方面第三種可能的實施方式，本發(fā)明實施例提供了第一方面第五種可能的實施方式，其中，每個所述服務器還用于，若判定所述操作請求為流媒體請求且不滿足負載條件，則判定是否重復接收到所述操作請求，若是，則通知所述客戶端請求失敗，否則，將所述操作請求轉發(fā)至其余所述服務器。

結合第一方面第三種可能的實施方式，本發(fā)明實施例提供了第一方面第六種可能的實施方式，其中，每個所述服務器還用于，若判定所述操作請求為流媒體請求、滿足負載要求、且滿足流復用條件，則進行流復用轉發(fā)。

結合第一方面，本發(fā)明實施例提供了第一方面第七種可能的實施方式，其中，每個所述監(jiān)控端均具有第一標識，每個所述服務器均具有第二標識，每個所述監(jiān)控端的所述第一標識的數(shù)量等于每個所述監(jiān)控端的允許接入次數(shù)。

結合第一方面第七種可能的實施方式，本發(fā)明實施例提供了第一方面第八種可能的實施方式，其中，每個所述第一標識和每個所述第二標識均包括數(shù)字，每個所述服務器與每個所述監(jiān)控端的對應關系根據(jù)所述第一標識、所述第二標識、所有所述服務器的數(shù)量確定。

結合第一方面第二種可能的實施方式，本發(fā)明實施例提供了第一方面第九種可能的實施方式，其中，每個所述服務器還用于，接收所述客戶端發(fā)送的配置更新請求，根據(jù)所述配置更新請求更新自身的配置信息，并按照所述單向循環(huán)順序將所述配置更新請求轉發(fā)至下一所述服務器，在重復接收到所述配置更新請求時，確定更新完成，計算更新后每個所述服務器與每個所述監(jiān)控端之間的對應關系。

結合第一方面第二種可能的實施方式，本發(fā)明實施例提供了第一方面第十種可能的實施方式，其中，所有所述服務器之間的單向循環(huán)順序采用單向循環(huán)鏈表記錄，采用在所述單向循環(huán)鏈表中刪除和/或添加所述服務器的方式變更所有所述服務器之間的單向循環(huán)順序。

第二方面，本發(fā)明實施例提供了一種視頻監(jiān)控系統(tǒng)的控制方法，所述視頻監(jiān)控系統(tǒng)為上述第一方面所述的視頻監(jiān)控系統(tǒng)，所述控制方法由所述服務器執(zhí)行，包括：在接收到所述操作請求后，判定所述操作請求對應的所述監(jiān)控端是否為自身對應的所述監(jiān)控端；若是，則將所述操作請求發(fā)送至自身對應的所述監(jiān)控端，否則，將所述操作請求轉發(fā)至其余的所述服務器，并在重復接收到所述操作請求時，將所述操作請求發(fā)送至所述操作請求相對應的所述監(jiān)控端。

本發(fā)明實施例中，設置視頻監(jiān)控系統(tǒng)包括多個監(jiān)控端、多個服務器和客戶端，并設置每個服務器對應至少一個監(jiān)控端；在服務器接收到用戶的操作請求時，判定該操作請求對應的監(jiān)控端是否為自身對應的監(jiān)控端，若是，則將該操作請求發(fā)送至自身對應的監(jiān)控端，否則，將該操作請求轉發(fā)至其余的服務器，并在重復接收到該操作請求時，將該操作請求發(fā)送至該操作請求相對應的監(jiān)控端。通過本發(fā)明實施例中的視頻監(jiān)控系統(tǒng)及其控制方法，多個服務器均參與到系統(tǒng)工作中，服務器利用率高，采用多個服務器的架構，當與某個監(jiān)控端對應的服務器故障時，還能夠由其他服務器處理該針對該監(jiān)控端的操作請求，從而提高系統(tǒng)工作的穩(wěn)定性，因此本實施例中的視頻監(jiān)控系統(tǒng)及其控制方法，能夠在服務器穩(wěn)定性和利用率這兩點之間取得平衡，避免現(xiàn)有技術中視頻監(jiān)控系統(tǒng)穩(wěn)定性高而服務器利用率低的問題。

為使本發(fā)明的上述目的、特征和優(yōu)點能更明顯易懂，下文特舉較佳實施例，并配合所附附圖，作詳細說明如下。

附圖說明

為了更清楚地說明本發(fā)明實施例的技術方案，下面將對實施例中所需要使用的附圖作簡單地介紹，應當理解，以下附圖僅示出了本發(fā)明的某些實施例，因此不應被看作是對范圍的限定，對于本領域普通技術人員來講，在不付出創(chuàng)造性勞動的前提下，還可以根據(jù)這些附圖獲得其他相關的附圖。

圖1為本發(fā)明第一實施例提供的視頻監(jiān)控系統(tǒng)的結構示意圖；

圖2為本發(fā)明第一實施例提供的監(jiān)控端的第一標識設置示意圖；

圖3為本發(fā)明第一實施例提供的服務器之間的連接關系示意圖；

圖4為本發(fā)明第一實施例提供的服務器配置變更示意圖；

圖5為本發(fā)明第一實施例提供的服務器配置變更流程圖；

圖6為本發(fā)明第一實施例提供的服務器端的操作請求處理流程示意圖；

圖7為本發(fā)明第二實施例提供的視頻監(jiān)控系統(tǒng)的控制方法的流程示意圖。

具體實施方式

為使本發(fā)明實施例的目的、技術方案和優(yōu)點更加清楚，下面將結合本發(fā)明實施例中附圖，對本發(fā)明實施例中的技術方案進行清楚、完整地描述，顯然，所描述的實施例僅僅是本發(fā)明一部分實施例，而不是全部的實施例。通常在此處附圖中描述和示出的本發(fā)明實施例的組件可以以各種不同的配置來布置和設計。因此，以下對在附圖中提供的本發(fā)明的實施例的詳細描述并非旨在限制要求保護的本發(fā)明的范圍，而是僅僅表示本發(fā)明的選定實施例?；诒景l(fā)明的實施例，本領域技術人員在沒有做出創(chuàng)造性勞動的前提下所獲得的所有其他實施例，都屬于本發(fā)明保護的范圍。

考慮到現(xiàn)有技術中視頻監(jiān)控系統(tǒng)難以在服務器200穩(wěn)定性和利用率這兩點之間取得平衡，本發(fā)明提供了一種視頻監(jiān)控系統(tǒng)及其控制方法，能夠在服務器200穩(wěn)定性和利用率這兩點之間取得平衡，下面結合實施例進行具體說明。

實施例一

本發(fā)明第一實施例提供了一種視頻監(jiān)控系統(tǒng)，圖1為本發(fā)明第一實施例提供的視頻監(jiān)控系統(tǒng)的結構示意圖，如圖1所示，該系統(tǒng)包括：多個監(jiān)控端100、多個服務器200和客戶端300，每個服務器200對應至少一個監(jiān)控端100，客戶端300可以為多個；

每個監(jiān)控端100均用于，采集視頻數(shù)據(jù)；

客戶端300用于，獲取用戶的操作請求并發(fā)送至一服務器200，其中，該操作請求對應一監(jiān)控端100，包括監(jiān)控端配置請求和/或視頻獲取請求；

每個服務器200均用于，在接收到該操作請求后，判定該操作請求對應的監(jiān)控端100是否為自身對應的監(jiān)控端100，若是，則將該操作請求發(fā)送至自身對應的監(jiān)控端100，否則，將該操作請求轉發(fā)至其余的服務器200，并在重復接收到該操作請求時，將該操作請求發(fā)送至該操作請求相對應的監(jiān)控端100。

本發(fā)明實施例中，設置視頻監(jiān)控系統(tǒng)包括多個監(jiān)控端100、多個服務器200和客戶端300，并設置每個服務器200對應至少一個監(jiān)控端100；在服務器200接收到用戶的操作請求時，判定該操作請求對應的監(jiān)控端100是否為自身對應的監(jiān)控端100，若是，則將該操作請求發(fā)送至自身對應的監(jiān)控端100，否則，將該操作請求轉發(fā)至其余的服務器200，并在重復接收到該操作請求時，將該操作請求發(fā)送至該操作請求相對應的監(jiān)控端100。通過本發(fā)明實施例中的系統(tǒng)，多個服務器200均參與到系統(tǒng)工作中，服務器200利用率高，采用多個服務器200的架構，當與某個監(jiān)控端100對應的服務器200故障時，還能夠由其他服務器200處理該針對該監(jiān)控端100的操作請求，從而提高系統(tǒng)工作的穩(wěn)定性，因此本實施例中的系統(tǒng)能夠在服務器穩(wěn)定性和利用率這兩點之間取得平衡，避免現(xiàn)有技術中視頻監(jiān)控系統(tǒng)穩(wěn)定性高而服務器利用率低的問題。

本實施例中，監(jiān)控端100包括音視頻采集設備、編碼設備、解碼設備以及顯示裝置等，具體可以為監(jiān)控攝像機、解碼器、監(jiān)控平臺等發(fā)送或接收消息和媒體流的裝置。比如，監(jiān)控端100設置于電梯間、消防通道等處，包括攝像頭和編碼設備，用于采集電梯間、消防通道等處的視頻數(shù)據(jù)。

本實施例中，客戶端300包括手機、電腦等終端設備，用于將用戶操作轉換成計算機指令序列，也即根據(jù)用戶操作生成操作請求，并將該操作請求發(fā)送至一服務器200?？蛻舳?00還用于接收處理服務器200返回的信息和媒體數(shù)據(jù)。

本實施例中，服務器200上運行有服務軟件，服務器200運行服務軟件，用于接收客戶端300發(fā)送的操作請求，執(zhí)行該操作請求，控制監(jiān)控端100做出響應。比如，操作請求為監(jiān)控端配置請求，則服務器200根據(jù)該監(jiān)控端配置請求控制監(jiān)控端100進行配置，又如，操作請求為視頻獲取請求，則服務器200根據(jù)該視頻獲取請求從監(jiān)控端100處獲取監(jiān)控端100采集的視頻數(shù)據(jù)。

本實施例中，客戶端300與服務器200通信，服務器200與監(jiān)控端100通信。每個服務器200可以稱為一個服務節(jié)點，任何一個服務器200的處理邏輯都一樣，不考慮服務器200的硬件差異以及通信端口的不同，系統(tǒng)中的服務器200之間是全對稱的，這種全對稱的結構能夠保證每個服務器200均得到充分利用，從而提高所有服務器200的利用率。

服務器200需要基于一些配置信息來運行，配置信息是整套系統(tǒng)運行的基礎，主要包括:監(jiān)控端100的訪問和控制信息，全部服務器200的通信信息。服務器200根據(jù)監(jiān)控端100的配置信息可以實現(xiàn)對監(jiān)控端100的訪問，根據(jù)全部服務器200的信息實現(xiàn)調度邏輯。客戶端300接入本實施例中的系統(tǒng)后，獲取部分配置信息(主要是監(jiān)控端配置信息和服務器配置信息)，以此為依據(jù)向目標服務器200發(fā)起操作請求。

為便于監(jiān)控端100的管理，本實施例中，每個監(jiān)控端100均具有第一標識，且每個監(jiān)控端100的第一標識的數(shù)量等于每個監(jiān)控端100的允許接入次數(shù)。

對于每個監(jiān)控端100而言，第一標識由兩部分組成，一部分為監(jiān)控端100的設備序號，一部分為監(jiān)控端100的接入序號，其中設備序號采用單調遞增規(guī)則設置，每個監(jiān)控端100的設備序號均不相同，接入序號采用單調遞增規(guī)則設置，每個監(jiān)控端100的接入序號均不同。在系統(tǒng)中采用有序隊列保存每個監(jiān)控端100的第一標識。在添加新的監(jiān)控端100時，按照設備序號單調遞增規(guī)則為該新增加的監(jiān)控端100分配設備序號，按照接入序號單調遞增規(guī)則為其分配接入序號。在系統(tǒng)中，當某個監(jiān)控端100被刪除，如暫時不用或者永久不用時，其占用的第一標識不被釋放。

圖2為本發(fā)明第一實施例提供的監(jiān)控端100的第一標識設置示意圖，如圖2所示，S表示接入序號，D表示設備序號，S1-D1表示設備序號為D1的監(jiān)控端100第一次接入系統(tǒng)，虛線框中的監(jiān)控端100表示從系統(tǒng)中刪除，圖中左側的監(jiān)控端100被接入系統(tǒng)中。

根據(jù)前述，當一個監(jiān)控端100支持多次接入時，其具有兩個第一標識，比如，S1-D1,S2-D1，表示設備序號為D1的監(jiān)控端100的兩次接入記錄。同樣，如果某個監(jiān)控端100被刪除，與其相關的記錄都要刪除，比如S5-D3，S6-D3同時刪除。

本實施例中第一標識的具體生成能夠用以下偽代碼表示：

/*********

功能：生成監(jiān)控端100在系統(tǒng)中的序列號，即監(jiān)控端100的唯一標識。

IN DeviceInfo根據(jù)監(jiān)控端100情況配置的，監(jiān)控端100可以被同時接入的次數(shù)上限(該上限根是根據(jù)監(jiān)控端100實際的接入能力配置的)

IN ServerNode服務器200序列

*********/

void GenerateDeviceSerialNum(DeviceInfo,ServerNodeQueue,)

{

//每個監(jiān)控端100占用幾個連續(xù)的序號

//DeviceInfo.AccessLimit是根據(jù)監(jiān)控端100情況配置的，監(jiān)控端100支持的同時接入次數(shù)上限

//ServerNodeQueue.size是服務器200隊列的長度

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

UpdateDeviceQueue(SerialInterval,DeviceInfo)；

}。

本實施例中，每個服務器200均具有第二標識，該第二標識用于標識每個服務器200。優(yōu)選地，每個第一標識和每個第二標識均包括數(shù)字，如用序號1、2、3的形式表示每個服務器200的第二標識。本實施例中，所有服務器200采用單向循環(huán)順序依次建立連接，所有服務器200之間的單向循環(huán)順序采用單向循環(huán)鏈表記錄。

圖3為服務器200之間的連接關系示意圖，圖3中，SNi為第二標識，其中i為數(shù)字，如圖3所示，采用單向循環(huán)鏈表記錄服務器200的配置。服務器200的配置信息是全局同步的。在完成一次配置之后，該單向循環(huán)鏈表就固定并唯一，如果出現(xiàn)某個服務器200失效的情況，則將該服務器200的狀態(tài)修改為不可用，(服務器200和客戶端300通過通信協(xié)議判斷其他服務器200的有效性，并在各自程序里做標注)，系統(tǒng)不會在該單向循環(huán)鏈表中自動刪除該服務器200，失效的服務器200恢復響應之后，還能繼續(xù)工作。每個服務器200和客戶端300都能獲取到這份服務配置(即圖3中的所有服務器之間的連接關系)?？蛻舳?00可以結合操作請求對應的監(jiān)控端100、監(jiān)控端100與服務器200之間的對應關系，判斷出向哪個服務器200發(fā)起操作請求。服務器200可以根據(jù)該單向循環(huán)鏈表，決定操作請求的轉發(fā)目標。

本實施例中，每個服務器200與每個監(jiān)控端100的對應關系根據(jù)第一標識、第二標識、所有服務器200的數(shù)量確定。

具體地，為了提高系統(tǒng)處理效率，將監(jiān)控端100和服務器200進行“弱綁定”。這種綁定關系是根據(jù)服務器200和監(jiān)控端100的標識進行計算的，當客戶端300獲獲取到全部監(jiān)控端100的第一標識和服務器200的第二標識后，就可以計算每個監(jiān)控端100與每個服務器200之間的對應關系。

對應關系的計算公式：ServerIndex＝DeviceSerialNum％ServerNodeQueue.size。該公式中，ServerIndex表示服務器200的第二標識的下標，DeviceSerialNum為監(jiān)控端100第一標識中的設備序號，％是求余數(shù)計算描述符，ServerNodeQueue.size是單向循環(huán)鏈表的長度，也即所有服務器的數(shù)量。

本實施例中，基于上述所有服務器200之間的單向循環(huán)關系，還能夠采用在上述的單向循環(huán)鏈表中刪除和/或添加服務器200的方式變更所有服務器200之間的單向循環(huán)順序。

圖4為本實施例提供的服務器200配置變更示意圖，如圖4所示，將當前服務器200之間的單向循環(huán)關系進行修改，修改時采用在上述的單向循環(huán)鏈表中刪除和/或添加服務器200的方式實現(xiàn)。本實施例中在修改服務器200之間的配置關系時，基于所有服務器200之間的單向循環(huán)關系，能夠保證在配置變更的過渡期，或者使用過時配置信息訪問服務器200的情況下，也能成功執(zhí)行指令。本實施例支持的配置行為包括添加和刪除(不支持修改操作，修改可以通過刪除和添加的組合來實現(xiàn))。

如圖4所示，在更新配置的過程中存在短暫的中間狀態(tài)，比如某個服務器200(以上圖中的SN₂為例)配置信息是過時的，對于該服務器200而言，后繼的服務器200SN₃還存在，但是由于實際上SN₃服務進程已經(jīng)退出，也就不會再響應請求，所有的請求轉發(fā)給SN₄。對于新添加的SN₆來說，SN₂的過期配置中，SN₆并不存在，也就不會接收到新的響應。

本實施例中，服務器200修改配置信息(即服務器之間連接關系)的過程為：服務器200接收客戶端300發(fā)送的配置更新請求，根據(jù)配置更新請求更新自身的配置信息，并按照上述單向循環(huán)順序將配置更新請求轉發(fā)至下一服務器200，在重復接收到該配置更新請求時，確定更新完成，計算更新后每個服務器200與每個監(jiān)控端100之間的對應關系。

圖5為本實施例提供的服務器200配置變更流程圖，如圖5所示，服務器200配置變更流程為：

步驟S501，服務器200接收更新服務器配置的請求。

步驟S502，服務器200更新自身的配置。

步驟S503，服務器200按照已有的單向循環(huán)順序，將更新服務器配置的請求轉發(fā)至下一服務器200。

步驟S504，判斷是否再次接收到該更新服務器配置的請求，若是，執(zhí)行步驟S505，否則，循環(huán)本步驟。

步驟S505，根據(jù)更新后的服務器配置重新計算每個服務器200與每個監(jiān)控端100的對應關系。

需要說明的是，服務器200收到更新服務器配置的請求后，所有服務器200和客戶端300并不會馬上重新計算服務器200和監(jiān)控端100的對應關系，要等到所有正常運行的服務器200全部完成配置更新，服務器200才會重新計算服務器200和監(jiān)控端100的對應關系，并且通知各個登錄的客戶端300更新配置。

基于上述的監(jiān)控端100與服務器200之間的對應關系，服務器200與監(jiān)控端100采用對應關系，每個服務器200至少對應一個監(jiān)控端100?？蛻舳?00上顯示有服務器列表，該列表中標注有每個服務器200的圖標，且標注有每個服務器200的狀態(tài)，即該服務器200是可用還是不可用。當客戶端300向服務器200發(fā)送操作請求，且該操作請求是針對某個監(jiān)控端100時，客戶端300的處理方式為，獲取該操作請求，根據(jù)獲取的操作請求對應的監(jiān)控端100、每個服務器200與每個監(jiān)控端100之間的對應關系，確定獲取的操作請求對應的服務器200，若確定的服務器200可用，則將操作請求發(fā)送至確定的服務器200，否則，按照預設規(guī)則將操作請求發(fā)送至一可用的服務器200。

上述預設規(guī)則可以為預先指定一個服務器200，如列表中第一個服務器200，在操作請求對應的服務器200不可用時，將該操作請求發(fā)送至預先指定的服務器200。預設規(guī)則還可以為，當操作請求對應的服務器200不可用時，在服務器200列表中隨機選擇一個可用的服務器200，將該操作請求發(fā)送至該隨機選擇的可用的服務器200。上述所指的服務器200不可用，包括服務器200單點故障、服務器200調試、服務器200未接入本實施例中的系統(tǒng)等情況。

基于上述的監(jiān)控端100與服務器200之間的對應關系，每個服務器200在接收到操作請求后，判定該操作請求對應的監(jiān)控端100是否為自身對應的監(jiān)控端100，若是，則將該操作請求發(fā)送至自身對應的監(jiān)控端100，否則，按照上述的單向循環(huán)順序將該操作請求轉發(fā)至下一服務器200。

按照這種方式，當與操作請求對應的服務器200處于不可用狀態(tài)時，則客戶端300按照預設規(guī)則確定接收該操作請求的服務器200，該服務器200接收到該操作請求后，將按照上述的單向循環(huán)順序將操作請求發(fā)送至下一服務器200，由于與操作請求對應的服務器200處于不可用狀態(tài)，因此該操作請求將始終在所有可用的服務器200之間流轉，在操作請求的流轉過程中，每個服務器200在接收到該操作請求時，都判斷是否為重復接收到該操作請求，當該操作請求流轉過所有服務器200后，最開始接收到該操作請求的服務器200將判定重復接收到該操作請求，則最開始接收到該操作請求的服務器200，將該操作請求發(fā)送至該操作請求相對應的監(jiān)控端100，以使該操作請求得到處理。

圖6為本實施例提供的服務器200端的操作請求處理流程示意圖。如圖6所示，每個服務器200在判定接收到的操作請求對應的監(jiān)控端100是否為自身對應的監(jiān)控端100之前，還用于依次判定該操作請求是否為流媒體請求、是否滿足負載要求以及是否符合流復用條件，若該操作請求為流媒體請求、滿足負載要求、且不滿足流復用條件，則判定該操作請求對應的監(jiān)控端100是否為自身對應的監(jiān)控端100。

如圖6所示，每個服務器200還用于，若判定接收到的操作請求不為流媒體請求，則判定該操作請求對應的監(jiān)控端100是否為自身對應的監(jiān)控端100。

如圖6所示，每個服務器200還用于，若判定操作請求為流媒體請求且不滿足負載條件，則判定是否重復接收到該操作請求(也即該操作請求是否在所有服務器間流轉一輪)，若是，則通知客戶端300請求失敗，否則，將該操作請求轉發(fā)至其余服務器200。具體地，按照服務器200之間的配置關系將操作請求轉發(fā)至下一服務器200。

如圖6所示，每個服務器200還用于，若判定接收到的操作請求為流媒體請求、滿足負載要求、且滿足流復用條件，則進行流復用轉發(fā)。

具體地，客戶端300發(fā)送操作請求：客戶端300根據(jù)監(jiān)控端100與服務器200之間的對應關系，確定該操作請求對應的服務器200，由于一個監(jiān)控端100能夠多次接入，因此一個監(jiān)控端100可能歸屬多個連續(xù)的服務器200，此時客戶端300每次嘗試向第一個服務器200發(fā)起請求，如果與第一個服務器200通信失敗，則向下一個服務器200發(fā)起請求，以此類推。

對圖6中的流程做詳細說明。視頻監(jiān)控系統(tǒng)的操作請求分為兩大類，一種是請求控制流媒體傳輸，另一種是獲取、設置監(jiān)控端配置信息。圖6步驟S601中，服務器200首先要對接收到的操作請求進行判斷，如果判斷是流媒體相關的請求，是則執(zhí)行步驟S602，判斷當前服務器200是否滿足負載條件，若不滿足，則執(zhí)行步驟S603，,繼續(xù)判斷該操作請求是否已經(jīng)在所有服務器200間流轉過一輪，本步驟中判斷是否重復接收到該操作請求，若是，則確定該操作請求是否已經(jīng)在所有服務器200間流轉過一輪，否則，確定未流轉過一輪。若該操作請求已經(jīng)在所有服務器200間流轉過一輪，則認為沒有服務器200能夠處理該操作請求，執(zhí)行步驟S604，向客戶端300返回失敗，若該操作請求未在所有服務器200間流轉過一輪，則執(zhí)行步驟S605，按照之前定義的單向循環(huán)順序繼續(xù)向下一服務器200轉發(fā)該操作請求。

步驟S602中，如果判斷滿足負載要求，則執(zhí)行步驟S606，判斷該操作請求是否符合流復用的條件。其中流復用，是指服務器200只向監(jiān)控端100獲取一次實時流，客戶端300再次發(fā)起瀏覽請求時，會直接從服務端轉發(fā)這路媒體流，這樣可以有效降低監(jiān)控端100的接入壓力，尤其在大量并發(fā)瀏覽的情況下，必須使用流復用技術。若步驟S606判斷符合流復用條件，則執(zhí)行步驟S607，進行流轉發(fā)，若步驟S606判斷不符合流復用條件，則執(zhí)行步驟S608，判斷該操作請求對應的監(jiān)控端100是否對應本服務器200，若是，則執(zhí)行步驟S609，則直接向本服務器200對應的監(jiān)控端100發(fā)送該操作請求，若否，則執(zhí)行步驟S610，判斷該操作請求是否已經(jīng)在所有服務器200間流轉過一輪(也即判定是否重復接收到該操作請求)，該步驟與S603相同，不再贅述。若步驟S610判斷為是，則執(zhí)行步驟S611，直接向該操作請求對應的監(jiān)控端100發(fā)送該操作請求，若否，則執(zhí)行步驟S612，按照之前定義的單向循環(huán)順序繼續(xù)向下一服務器200轉發(fā)該操作請求。

圖6中，若步驟S601判斷操作請求不為流媒體相關請求，則轉至步驟S608繼續(xù)執(zhí)行。

需要說明的是，本實施例中所指的“判斷操作請求是否在所有服務器間流轉過一輪”，其實質含義就是“判定是否重新接收到該操作請求”，因此這兩種表達方式可以互換，上述內容中若有與圖6不對應處，或者表達不一致處，按照“判斷操作請求是否在所有服務器間流轉過一輪”等同于“判斷是否重新接收到該操作請求”處理即可。

需要說明的是，即使某個監(jiān)控端100不屬于本服務器200，也可以通過本服務器200控制該監(jiān)控端100。具體地，服務器200第一次收到操作請求的時候，如果該操作請求對應的監(jiān)控端100不屬于本服務器200，就會向下一個服務器200轉發(fā)(如果直接相鄰的服務器200轉發(fā)失敗，則會跳過這個服務器200繼續(xù)向下轉發(fā)，直到轉發(fā)成功為止)。因為服務器200的配置關系使用單向循環(huán)鏈表保存，如果全局范圍內，所服務器200都未處理該操作請求，則本服務器200將會再次接收到這個操作請求，這時候，本服務器200就要臨時接管該操作請求對應的監(jiān)控端100，向它發(fā)起操作請求。

這種操作方式能夠保證優(yōu)先使用與監(jiān)控端100存在對應關系的服務器200，提高請求命中率，縮短響應延時，同時又解決對應的服務器200失效的情況下，訪問控制目標監(jiān)控端100的問題。

綜上，通過本發(fā)明實施例中的系統(tǒng)，多個服務器200均參與到系統(tǒng)工作中，服務器200利用率高，采用多個服務器200的架構，當與某個監(jiān)控端100對應的服務器200故障時，還能夠由其他服務器200處理該針對該監(jiān)控端100的操作請求，從而提高系統(tǒng)工作的穩(wěn)定性，因此本實施例中的系統(tǒng)能夠在服務器穩(wěn)定性和利用率這兩點之間取得平衡，避免現(xiàn)有技術中視頻監(jiān)控系統(tǒng)穩(wěn)定性高而服務器利用率低的問題。

綜上，本發(fā)明實施例中的系統(tǒng)，至少具有以下效果：

(1)多服務器200協(xié)作，避免單點軟硬件故障引發(fā)的系統(tǒng)癱瘓；

(2)維護和管理簡單，所有服務器200全對稱(每臺服務器200部署和運行的程序一樣)，簡化了部署和降低維護成本，每個服務器都參與系統(tǒng)任務調度，服務器利用率高；

(3)和多機熱備的方案相比，不用區(qū)分主備機，不用手動(或自動)切換主備機，所有正常運行的服務器200都能參與系統(tǒng)任務，充分利用硬件資源；

(4)部分服務器的失效，可能會降低整個系統(tǒng)的媒體轉發(fā)能力，但是在余下轉發(fā)負載范圍內，系統(tǒng)能繼續(xù)提供服務；

(5)規(guī)模可伸縮，本發(fā)明對服務器200的個數(shù)沒有限制，不像云平臺那樣，需要達到一定服務器200數(shù)量才能體現(xiàn)技術優(yōu)勢。

實施例二

對應上述實施例一中的視頻監(jiān)控系統(tǒng)，本實施例還提供了一種視頻監(jiān)控系統(tǒng)的控制方法，該視頻監(jiān)控系統(tǒng)為實施例一中的視頻監(jiān)控系統(tǒng)，圖7為本發(fā)明實施例提供的視頻監(jiān)控系統(tǒng)的控制方法的流程示意圖，該控制方法由上述的服務器200執(zhí)行，如圖7所示，該控制方法包括：

步驟S701，在接收到操作請求后，判定該操作請求對應的監(jiān)控端100是否為自身對應的監(jiān)控端100；

步驟S702，若是，則將該操作請求發(fā)送至自身對應的監(jiān)控端100，否則，將該操作請求轉發(fā)至其余的服務器200，并在重復接收到該操作請求時，將該操作請求發(fā)送至該操作請求相對應的監(jiān)控端100。

能夠知道，該控制方法與上述的視頻監(jiān)控系統(tǒng)一一對應，具體描述可見上述的系統(tǒng)部分，因此這里不再贅述。

通過本發(fā)明實施例中的控制方法，多個服務器200均參與到系統(tǒng)工作中，服務器利用率高，采用多個服務器的架構，當與某個監(jiān)控端100對應的服務器200故障時，還能夠由其他服務器200處理該針對該監(jiān)控端100的操作請求，從而提高系統(tǒng)工作的穩(wěn)定性，因此本實施例中的控制方法能夠在服務器穩(wěn)定性和利用率這兩點之間取得平衡，避免現(xiàn)有技術中視頻監(jiān)控系統(tǒng)穩(wěn)定性高而服務器利用率低的問題。

在本發(fā)明所提供的實施例中，應該理解到，所揭露裝置和方法，可以通過其它的方式實現(xiàn)。以上所描述的裝置實施例僅僅是示意性的，例如，所述單元的劃分，僅僅為一種邏輯功能劃分，實際實現(xiàn)時可以有另外的劃分方式，又例如，多個單元或組件可以結合或者可以集成到另一個系統(tǒng)，或一些特征可以忽略，或不執(zhí)行。另一點，所顯示或討論的相互之間的耦合或直接耦合或通信連接可以是通過一些通信接口，裝置或單元的間接耦合或通信連接，可以是電性，機械或其它的形式。

所述作為分離部件說明的單元可以是或者也可以不是物理上分開的，作為單元顯示的部件可以是或者也可以不是物理單元，即可以位于一個地方，或者也可以分布到多個網(wǎng)絡單元上?？梢愿鶕?jù)實際的需要選擇其中的部分或者全部單元來實現(xiàn)本實施例方案的目的。

另外，在本發(fā)明提供的實施例中的各功能單元可以集成在一個處理單元中，也可以是各個單元單獨物理存在，也可以兩個或兩個以上單元集成在一個單元中。

所述功能如果以軟件功能單元的形式實現(xiàn)并作為獨立的產品銷售或使用時，可以存儲在一個計算機可讀取存儲介質中?；谶@樣的理解，本發(fā)明的技術方案本質上或者說對現(xiàn)有技術做出貢獻的部分或者該技術方案的部分可以以軟件產品的形式體現(xiàn)出來，該計算機軟件產品存儲在一個存儲介質中，包括若干指令用以使得一臺計算機設備(可以是個人計算機，服務器，或者網(wǎng)絡設備等)執(zhí)行本發(fā)明各個實施例所述方法的全部或部分步驟。而前述的存儲介質包括：U盤、移動硬盤、只讀存儲器(ROM，Read-Only Memory)、隨機存取存儲器(RAM，Random Access Memory)、磁碟或者光盤等各種可以存儲程序代碼的介質。

應注意到：相似的標號和字母在下面的附圖中表示類似項，因此，一旦某一項在一個附圖中被定義，則在隨后的附圖中不需要對其進行進一步定義和解釋，此外，術語“第一”、“第二”、“第三”等僅用于區(qū)分描述，而不能理解為指示或暗示相對重要性。

最后應說明的是：以上所述實施例，僅為本發(fā)明的具體實施方式，用以說明本發(fā)明的技術方案，而非對其限制，本發(fā)明的保護范圍并不局限于此，盡管參照前述實施例對本發(fā)明進行了詳細的說明，本領域的普通技術人員應當理解：任何熟悉本技術領域的技術人員在本發(fā)明揭露的技術范圍內，其依然可以對前述實施例所記載的技術方案進行修改或可輕易想到變化，或者對其中部分技術特征進行等同替換；而這些修改、變化或者替換，并不使相應技術方案的本質脫離本發(fā)明實施例技術方案的精神和范圍。都應涵蓋在本發(fā)明的保護范圍之內。因此，本發(fā)明的保護范圍應所述以權利要求的保護范圍為準。