TW201800963A - 資料處理方法及裝置 - Google Patents

資料處理方法及裝置 Download PDF

Info

Publication number
TW201800963A
TW201800963A TW106112619A TW106112619A TW201800963A TW 201800963 A TW201800963 A TW 201800963A TW 106112619 A TW106112619 A TW 106112619A TW 106112619 A TW106112619 A TW 106112619A TW 201800963 A TW201800963 A TW 201800963A
Authority
TW
Taiwan
Prior art keywords
rate
time
live data
terminal
server
Prior art date
Application number
TW106112619A
Other languages
English (en)
Inventor
冀文杰
Original Assignee
阿里巴巴集團服務有限公司
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 阿里巴巴集團服務有限公司 filed Critical 阿里巴巴集團服務有限公司
Publication of TW201800963A publication Critical patent/TW201800963A/zh

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N5/00—Details of television systems
    • H04N5/76—Television signal recording
    • H04N5/78—Television signal recording using magnetic recording
    • H04N5/782—Television signal recording using magnetic recording on tape
    • H04N5/783—Adaptations for reproducing at a rate different from the recording rate
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/238—Interfacing the downstream path of the transmission network, e.g. adapting the transmission rate of a video stream to network bandwidth; Processing of multiplex streams
    • H04N21/23805—Controlling the feeding rate to the network, e.g. by controlling the video pump
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/21—Server components or server architectures
    • H04N21/218—Source of audio or video content, e.g. local disk arrays
    • H04N21/2187—Live feed
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/238—Interfacing the downstream path of the transmission network, e.g. adapting the transmission rate of a video stream to network bandwidth; Processing of multiplex streams
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/24—Monitoring of processes or resources, e.g. monitoring of server load, available bandwidth, upstream requests
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/24—Monitoring of processes or resources, e.g. monitoring of server load, available bandwidth, upstream requests
    • H04N21/2407—Monitoring of transmitted content, e.g. distribution time, number of downloads
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/442—Monitoring of processes or resources, e.g. detecting the failure of a recording device, monitoring the downstream bandwidth, the number of times a movie has been viewed, the storage space available from the internal hard disk
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/65—Transmission of management data between client and server
    • H04N21/654—Transmission by server directed to the client
    • H04N21/6547—Transmission by server directed to the client comprising parameters, e.g. for client setup
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/83—Generation or processing of protective or descriptive data associated with content; Content structuring
    • H04N21/845—Structuring of content, e.g. decomposing content into time segments
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N5/00—Details of television systems
    • H04N5/76—Television signal recording
    • H04N5/765—Interface circuits between an apparatus for recording and another apparatus
    • H04N5/775—Interface circuits between an apparatus for recording and another apparatus between a recording apparatus and a television receiver

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Signal Processing (AREA)
  • Databases & Information Systems (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
  • Retry When Errors Occur (AREA)
  • Telephonic Communication Services (AREA)
  • Computer And Data Communications (AREA)
  • Information Transfer Between Computers (AREA)
  • Debugging And Monitoring (AREA)

Abstract

本申請公開了一種資料處理方法及裝置。該方法包括：伺服器監測直播資料服務的運行狀態，當監測到所述運行狀態發生異常時，確定預估修復時長，根據所述預估修復時長，計算第一速率，將計算得到的第一速率發送至終端，以使得所述終端根據所述第一速率顯示直播資料。經過本方法，當伺服器中的直播資料服務出現異常時，伺服器可將終端當前的顯示速率減緩，可以延長後台的工作人員排障或修復的時間，同時，使得前端用戶不會明顯地察覺到直播資料的跳變、回退、停滯等現象。相應地，在直播資料服務修復之後，可加快終端的顯示速率，使得終端適於伺服器發送的新增直播資料。

Description

資料處理方法及裝置
本申請關於電腦技術領域，尤其關於一種資料處理方法及裝置。
目前，在諸如網路、電視直播的場景下，資料直播得到了廣泛的應用(其中，資料直播就是資料的即時顯示)，通過資料直播，使用者可及時的獲知相應的資訊。
例如：在電視直播過程中，顯示春運客流量資料，那麼，收看該電視直播的使用者便可以獲知相應的春運客流量。又例如：購物網站顯示該網站的訪問量、銷售額等資料，那麼，訪問至該購物網站的使用者便可以在相應頁面中獲知訪問量及銷售額。
上述資料的直播顯示，通常由相應的伺服器(或伺服器集群)中的直播資料服務實現(該直播資料服務運行在伺服器中)：直播資料服務從資料來源處即時獲取資料，並經過相應的統計處理後，得到直播資料，發送給終端顯示。需要說明的是，對於實際的資料直播顯示過程而言，實質上是一種延時直播，換言之，終端所顯示的資料與伺 服器所生成的資料之間存在一定的時間差，亦即，終端所顯示的直播資料通常是n秒前伺服器所生成的。
而在實際應用場景下，直播資料服務在運行的過程中可能出現異常的情況(如：計數出錯、運行卡頓等)，這就需要相應的業務人員進行排障及修復的操作。
現有技術中，當直播資料服務出現異常時，伺服器會採用備用服務切換的方式，啟動備用的直播資料服務代替出現異常的直播資料服務。
但是，採用備份服務切換方式，就有可能導致即時資料出現“跳躍”或回退，這是因為：伺服器中所運行的直播資料服務會將從資料來源處所獲得即時資料進行快取，以便進行相應的統計處理，若該直播資料服務出現了異常而被備用的直播資料服務替換後，其儲存在快取中的即時資料將被清除，備用的直播資料服務上線後，將重新快取這部分即時資料進行統計處理。這樣就會造成資料的重複統計處理，進一步導致出現資料直播時的回退現象。
例如：以訪問量資料為例，原有的直播資料服務將從資料來源處獲取的即時資料a900~a960進行快取，並針對這60條資料進行統計處理，最終可生成訪問量資料900~960，假設，直播資料伺服器已根據即時資料a930~a950，生成了訪問量資料930~950，發送給終端進行顯示，如圖1a所示，終端基於伺服器所發送的訪問量資料，當前所顯示的訪問量為：935。
假設，直播資料服務在生成訪問量資料955時出現了 異常，此時，伺服器將該出現異常的直播資料服務停止，並啟用備用的直播資料服務代替出現異常的直播資料服務，但在備用的直播資料服務上線運行後，將清除原有直播資料服務所快取的資料，並重新將即時資料a900~a960快取以進行統計處理，並重新生成訪問量資料900~920發送給終端進行顯示，那麼，對於終端而言，其根據之前接收到的訪問量資料，顯示訪問量950後(如圖1b所示)，又將根據最新接收到的訪問量資料900~920，將回退至900，並從900開始重新顯示，如圖1c所示。可見，該情況便是資料的回退。
顯然，這樣的方式將影響終端所顯示的直播資料。
本申請實施例提供一種資料處理方法，用以解決現有技術中直播資料出現異常可能導致顯示跳變、回退的問題。
本申請實施例提供一種資料處理裝置，用以解決現有技術中直播資料出現異常可能導致顯示跳變、回退的問題。
本申請實施例採用下述技術方案：本申請實施例提供的一種資料處理方法，包括：伺服器監測直播資料服務的運行狀態；當監測到所述運行狀態發生異常時，確定預估修復時長； 根據所述預估修復時長，計算第一速率；將計算得到的第一速率發送至終端，以使得所述終端根據所述第一速率顯示直播資料。
本申請實施例還提供的一種資料處理方法，包括：終端接收伺服器發送的第一速率，其中，所述第一速率由所述伺服器監測到所述運行狀態發生異常時，確定預估修復時長，並根據所述預估修復時長計算得到；根據所述第一速率顯示直播資料。
本申請實施例提供的一種資料處理裝置，包括：監測模組，監測直播資料服務的運行狀態；預估模組，當監測到所述運行狀態發生異常時，確定預估修復時長；計算模組，根據所述預估修復時長，計算第一速率；發送模組，將計算得到的第一速率發送至終端，以使得所述終端根據所述第一速率顯示直播資料。
本申請實施例還提供的一種資料處理裝置，包括：接收模組，接收伺服器發送的第一速率，其中，所述第一速率由所述伺服器監測到所述運行狀態發生異常時，確定預估修復時長，並根據所述預估修復時長計算得到；顯示模組，根據所述第一速率顯示直播資料。
本申請實施例採用的上述至少一個技術方案能夠達到以下有益效果：當伺服器在監測到直播資料服務出現異常時，將確定預估的修復時長，並基於預估的修復時長，計算出第一速 率發送給終端，其中，這裡的第一速率能夠控制終端顯示直播資料的顯示速率，換言之，在第一速率的作用下，能夠減慢終端顯示直播資料的顯示速率，那麼，終端將根據第一速率降低其顯示直播資料的速率，從而，對於終端本地的儲存的待顯示的直播資料，終端將消耗更長的時間顯示這些直播資料，這樣一來，在伺服器側，業務人員也將獲得足夠的時間對伺服器中運行的直播資料服務進行排障、修復。
相較於現有技術切換備用直播資料服務的方式，採用本申請中的上述方式可以保留原有的直播資料服務(不進行服務的切換)，那麼，在直播資料服務恢復正常後，將繼續根據其快取的即時資料進行統計處理，換言之，在不切換直播數伺服器的情況下，其快取的即時資料就不會被清除，進而，也就不會出現直播資料的回退、跳變等異常的顯示現象。
同時，使得前端用戶不會明顯地察覺到直播資料的跳變、回退、停滯等現象。
301‧‧‧監測模組
302‧‧‧預估模組
303‧‧‧計算模組
304‧‧‧發送模組
305‧‧‧修復模組
401‧‧‧接收模組
402‧‧‧顯示模組
此處所說明的附圖用來提供對本申請的進一步理解，構成本申請的一部分，本申請的示意性實施例及其說明用於解釋本申請，並不構成對本申請的不當限定。在附圖中：圖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。
在確定出預估修復時長後，就可以進一步計算出第一時間速率。具體而言，確定在直播資料的運行狀態發生異常時，終端停止顯示直播數的時間，根據確定出的、終端停止顯示直播數的時間及預估修復時長，確定所述第一速率。
其中，所述預估修復時長越長，則第一速率越慢。為了便於描述，以下將預估修復時長稱為Tyu。
這裡需要說明的是，當直播資料服務出現異常時，伺服器將停止向終端發送直播資料，那麼，對於終端而言，其將按照原有的顯示速率顯示其本地的直播資料，可以理解，終端會在一段時間後，將其本地未顯示的直播資料顯示完畢，這樣一來，終端在顯示出最後一個直播資料後，停止直播資料的變更(因為在此時，終端已將本地快取的所有直播資料均進行顯示，且還未獲得由伺服器所提供的新增的直播資料)，其表現形式為，終端所顯示的直播資料停止在某一數值處。例如：終端所顯示的訪問量在500處停止。
所以，在本申請實施例中，當直播資料服務的運行狀態發生異常時，伺服器將確定出終端從此時刻開始，直到停止變更直播資料的時間(為了便於描述，以下將終端從直播資料服務運行異常時刻起，到停止變更直播資料時之間的時長稱為Tc1)。當然，作為本申請實施例中的一種可選方式，終端內顯示直播資料的顯示速率是由伺服器所 規定的，所以，伺服器可以獲知終端的顯示速率。並且，由於伺服器中的直播資料服務每次統計處理生成直播資料的時間點均有記錄(如：記錄在相應的資料日誌中)，相應地，該時間點所對應的直播資料的數量也有相應的記錄，那麼，伺服器可以確定出前一次向終端發送直播資料時，這些直播資料生成的時間點，基於此，就可以確定出終端本地所儲存的直播資料量。可以理解地，終端本地所儲存的直播資料量、顯示速率均已知，故伺服器可以確定出Tc1。
可以認為，Tc1是顯示速率未發生變化的情況下，終端顯示直播資料的耗時，但是，一旦終端經過Tc1時間後，終端就會停止直播資料的變更，這就會造成資料直播的顯示異常，而Tyu是後台業務人員進行修復可能所需的時間，所以，在本申請實施例中，就將根據Tc1和Tyu確定出第一速率，以使得在第一速率的作用下，延長Tc1。
例如：假設終端顯示網站的訪問量資料，其顯示速率為：每秒10個資料遞增，目前終端從伺服器獲得的訪問量資料包括1000~1200。並假設，終端在顯示訪問量1000時，伺服器中運行的直播資料服務出現異常，那麼，終端此時並不能繼續從伺服器中獲得訪問量資料。可知，終端按照該顯示速率，從訪問量1000起，顯示到訪問量1200所需的時長Tc1為20s。但是，預估修復時長Tyu為40s，為了避免出現終端在20s之後出現資料停滯的現象，就需要調整終端當前的顯示速率。
在本示例中，第一速率=Tc1/Tyu*當前顯示速率=0.5*10=5。
也即，第一速率為：每秒5個資料遞增，顯然，在該第一速率的作用下，終端從訪問量1000起，顯示到訪問量1200所需的時長就變為40s，延長了原本的顯示時長。
當然，上述方式是以第一速率為直播資料的跳變數的情況所進行的說明。而如果第一速率為時間流速，那麼，可採用如下方式計算第一速率：第一速率(用戶端的時間流速)=[(伺服器與用戶端之間的時間差異*用戶端時間)/Tyu]+用戶端原有的時間流速。
以上內容是在直播資料服務出現異常時對終端顯示速率的調整過程，具體如圖2b所示，在上述過程中，根據計算得到的第一速率，實質上減緩了終端的顯示速率。而在實際應用場景下，當後台的業務人員將直播資料服務修復後，那麼，直播資料服務又將正常地對即時資料進行統計處理，生成相應的直播資料，發送給終端。對於終端而言，其在之前第一速率的作用下，顯示直播資料時，維持在較低的顯示速率，當終端能夠正常接收伺服器發送的直播資料後，便可將其顯示速率加快，以適應於新增的直播資料。
下面對直播資料服務恢復後的過程進行詳細說明：由於前述的修復過程中，業務人員會預估某一時刻可將直播資料服務修復(即，預估修復時刻)，實際應用場 景下，直播資料服務實際的恢復時刻與之前由業務人員預估的修復時刻之間可能具有時差。如：假設由業務人員預估的修復時刻為12：08：40，而實際上，直播資料服務在12：07：50時已經恢復，所以，兩個時間點之間存在50s的時差。
在實際應用中，由於第一速率是根據預估修復時長而確定的，那麼，如果直播資料服務的實際恢復時間與預估修復時刻之間具有一定的時差，就應根據該時差來確定終端的顯示速率應該加快的程度，亦即，確定第二速率。
所示，對於前述方法，在直播資料服務恢復後，還包括：當監測到所述直播資料的運行狀態恢復正常時，確定修復時差，根據所述修復時差，計算第二速率，將計算得到的第二時間速率發送至終端，以使得所述終端根據所述第二速率顯示直播資料。
當然，根據前述內容可知，確定修復時差，具體包括：確定所述直播資料服務的運行狀態恢復正常時的時刻，根據直播資料服務的運行狀態恢復正常時的時刻以及預估修復時刻，確定所述修復時差。
延續前述示例：假設前述示例中，在12：01：00時直播資料服務出現異常，由於預估修復時長為40s，那麼，其預估修復時刻為12：01：40，但是直播資料服務的實際恢復時間為12：01：20(並於此刻新生成了訪問量資料)，也就是說，直播資料服務相較於預估修復時刻，其提前了20s恢復，此時，在終端側，其還有數量為100的訪問量資料 並未顯示，假設，直播資料服務照常工作後，為了使得終端能夠適於直播資料服務照常工作而生成的新訪問量資料，所以，伺服器將調整終端此時的顯示速率(即，第一速率)，使得終端加速顯示剩餘的訪問量資料(即，生成第二速率)。
當然，可以理解，修復時差越短，則第二速率越快。
同樣，上述方式是以第二速率為直播資料的跳變數的情況所進行的說明。而如果第二速率為時間流速，那麼，可採用如下方式計算第二速率：第二速率(用戶端的時間流速)=[(實際修復時刻-用戶端時間)* Tyu/實際修復時差]+第一速率。
以上是直播資料服務恢復正常時對終端顯示速率的調整過程，具體如圖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、光學記憶體等)上實施的電腦程式產品的形式。
以上所述僅為本申請的實施例而已，並不用於限制本申請。對於本領域技術人員來說，本申請可以有各種更改和變化。凡在本申請的精神和原理之內所作的任何修改、 等同替換、改進等，均應包含在本申請的申請專利範圍範圍之內。

Claims (10)

  1. 一種資料處理方法，包括：伺服器監測直播資料服務的運行狀態；當監測到該運行狀態發生異常時，確定預估修復時長；根據該預估修復時長，計算第一速率；將計算得到的第一速率發送至終端，以使得該終端根據該第一速率顯示直播資料。
  2. 如申請專利範圍第1項所述的方法，其中，確定預估修復時長，具體包括：確定預估修復時刻；確定在直播資料服務的運行狀態發生異常時的時間；根據確定出的該預估修復時刻以及該時間，確定該預估修復時長。
  3. 如申請專利範圍第2項所述的方法，其中，根據該預估修復時長，計算第一速率，具體包括：確定在直播資料的運行狀態發生異常時，終端停止變更直播資料的時間；根據確定出的、終端停止顯示直播數的時間及預估修復時長，確定該第一速率；其中，該預估修復時長越長，則第一速率越慢。
  4. 如申請專利範圍第3項所述的方法，其中，該方法還包括：當監測到該直播資料的運行狀態恢復正常時，確定修 復時差；根據該修復時差，計算第二速率；將計算得到的第二時間速率發送至終端，以使得該終端根據該第二速率顯示直播資料。
  5. 如申請專利範圍第4項所述的方法，其中，確定修復時差，具體包括：確定該直播資料服務的運行狀態恢復正常時的時刻；根據直播資料服務的運行狀態恢復正常時的時刻以及預估修復時刻，確定該修復時差。
  6. 如申請專利範圍第5項所述的方法，其中，根據該修復時差，計算第二時間速率，具體包括：根據該修復時差以及第一速率，確定該第二速率；其中，該修復時差越短，則第二速率越快。
  7. 一種資料處理方法，包括：終端接收伺服器發送的第一速率，其中，該第一速率由該伺服器監測到該運行狀態發生異常時，確定預估修復時長，並根據該預估修復時長計算得到；根據該第一速率顯示直播資料。
  8. 如申請專利範圍第7項所述的方法，其中，該方法還包括：該終端接收該伺服器發送的第二速率，其中，該第二速率由該伺服器監測到該直播資料的運行狀態恢復正常時，確定修復時差，並根據該修復時差計算得到；根據該第二速率顯示直播資料。
  9. 一種資料處理裝置，其特徵在於，包括：監測模組，監測直播資料服務的運行狀態；預估模組，當監測到該運行狀態發生異常時，確定預估修復時長；計算模組，根據該預估修復時長，計算第一速率；發送模組，將計算得到的第一速率發送至終端，以使得該終端根據該第一速率顯示直播資料。
  10. 一種資料處理裝置，其特徵在於，包括：接收模組，接收伺服器發送的第一速率，其中，該第一速率由該伺服器監測到該運行狀態發生異常時，確定預估修復時長，並根據該預估修復時長計算得到；顯示模組，根據該第一速率顯示直播資料。
TW106112619A 2016-06-28 2017-04-14 資料處理方法及裝置 TW201800963A (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
??201610490808.1 2016-06-28
CN201610490808.1A CN106899863B (zh) 2016-06-28 2016-06-28 一种数据处理方法及装置

Publications (1)

Publication Number Publication Date
TW201800963A true TW201800963A (zh) 2018-01-01

Family

ID=59190573

Family Applications (1)

Application Number Title Priority Date Filing Date
TW106112619A TW201800963A (zh) 2016-06-28 2017-04-14 資料處理方法及裝置

Country Status (10)

Country Link
US (1) US10694220B2 (zh)
EP (1) EP3477953B1 (zh)
JP (1) JP6703147B2 (zh)
KR (1) KR102145137B1 (zh)
CN (1) CN106899863B (zh)
MY (1) MY189664A (zh)
PH (1) PH12019500008A1 (zh)
SG (1) SG11201811568VA (zh)
TW (1) TW201800963A (zh)
WO (1) WO2018001114A1 (zh)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112752109B (zh) * 2019-10-30 2022-05-17 上海哔哩哔哩科技有限公司 视频播放控制方法和系统
CN114860370B (zh) * 2022-05-17 2024-03-29 聚好看科技股份有限公司 一种显示设备、服务器及软件开发工具包切换方法

Family Cites Families (21)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7660512B2 (en) * 2003-10-16 2010-02-09 Microsoft Corporation Systems and methods for managing frame rates during multimedia playback
CN101166322B (zh) * 2006-10-19 2010-10-27 华为技术有限公司 一种双模移动接收装置及在该装置上实现接收的方法
US8958486B2 (en) * 2007-07-31 2015-02-17 Cisco Technology, Inc. Simultaneous processing of media and redundancy streams for mitigating impairments
CN101472143A (zh) * 2007-12-27 2009-07-01 华为技术有限公司 一种实现流媒体服务的方法和系统
JP2010074726A (ja) * 2008-09-22 2010-04-02 Nec Personal Products Co Ltd 携帯型テレビジョン受信機および該受信機のプログラム
JP2011066817A (ja) * 2009-09-18 2011-03-31 Honda Motor Co Ltd 車両用デジタル放送受信装置
JP5812634B2 (ja) * 2011-03-17 2015-11-17 キヤノン株式会社 送信装置及び送信方法、並びにプログラム
CN102421034A (zh) * 2011-12-19 2012-04-18 中山爱科数字科技股份有限公司 一种视频直播或视频监控所形成的视频播放方法
US9450997B2 (en) * 2012-02-27 2016-09-20 Qualcomm Incorporated Dash client and receiver with request cancellation capabilities
US8683542B1 (en) * 2012-03-06 2014-03-25 Elemental Technologies, Inc. Concealment of errors in HTTP adaptive video sets
TWI520590B (zh) * 2012-12-17 2016-02-01 財團法人工業技術研究院 影音串流傳輸方法、影音裝置以及影音提供裝置
US9204201B2 (en) * 2012-12-27 2015-12-01 Echostar Technologies L.L.C. Enhanced reliability for satellite data delivery
TWI562625B (en) 2012-12-28 2016-12-11 Ind Tech Res Inst Methods and systems for event-driven adaptive streaming
CN104079955B (zh) * 2013-03-26 2017-12-15 华为技术有限公司 越顶ott直播的方法、装置及系统
CN104010232B (zh) 2014-05-23 2017-12-12 惠州Tcl移动通信有限公司 一种智能播放在线视频的方法、系统、播放器及移动终端
CN104065982B (zh) * 2014-06-19 2015-12-30 腾讯科技（深圳）有限公司 流媒体直播的方法和装置
TW201601528A (zh) 2014-06-21 2016-01-01 Jyt Inc 流暢影片播放方法
CN104080006B (zh) * 2014-07-10 2017-10-27 福州瑞芯微电子股份有限公司 一种视频处理装置及方法
US9788071B2 (en) * 2014-11-03 2017-10-10 Microsoft Technology Licensing, Llc Annotating and indexing broadcast video for searchability
CN105100876B (zh) * 2015-08-28 2019-04-12 北京奇艺世纪科技有限公司 一种流媒体的播放方法及装置
US9973816B2 (en) * 2015-11-18 2018-05-15 At&T Intellectual Property I, L.P. Media content distribution

Also Published As

Publication number Publication date
CN106899863A (zh) 2017-06-27
US10694220B2 (en) 2020-06-23
KR102145137B1 (ko) 2020-08-18
MY189664A (en) 2022-02-23
WO2018001114A1 (zh) 2018-01-04
EP3477953A4 (en) 2019-05-01
SG11201811568VA (en) 2019-01-30
US20190132615A1 (en) 2019-05-02
PH12019500008A1 (en) 2019-10-14
EP3477953B1 (en) 2023-09-06
CN106899863B (zh) 2019-10-25
KR20190021458A (ko) 2019-03-05
JP6703147B2 (ja) 2020-06-03
JP2019522292A (ja) 2019-08-08
EP3477953A1 (en) 2019-05-01

Similar Documents

Publication Publication Date Title
CA3036924C (en) Detecting service vulnerabilities in a distributed computing system
US20200204498A1 (en) Nonintrusive dynamically-scalable network load generation
EP3449205B1 (en) Predictive rollup and caching for application performance data
US20160315837A1 (en) Group server performance correction via actions to server subset
US20210006628A1 (en) Managing operation of instances
US8825779B2 (en) Systems and methods of real-time data subscription and reporting for telecommunications systems and devices
CN111343009B (zh) 服务告警通知方法及装置、存储介质、电子设备
US11200086B1 (en) Asynchronous transactions reported as critical path
US10795744B2 (en) Identifying failed customer experience in distributed computer systems
CN107992392B (zh) 一种用于云渲染系统的自动监控修复系统和方法
CN109245908B (zh) 一种主从集群切换的方法和装置
CN112527567A (zh) 系统容灾方法、装置、设备以及存储介质
CN109522100B (zh) 实时计算任务调整方法和装置
TW201800963A (zh) 資料處理方法及裝置
CN113395671B (zh) 消息推送速率的调节方法、装置和服务器
US11075977B2 (en) Accurately determining web page visually complete time
US20140201353A1 (en) Connectivity notification
CN111639086A (zh) 一种数据对账方法、装置、设备及存储介质
CN115033927A (zh) 一种检测数据完整性的方法、装置、设备及介质
CN110865895A (zh) 访问流量控制方法、装置、电子设备及存储介质
CN112463514A (zh) 分布式缓存集群的监测方法和装置
CN116627642A (zh) 用于管理应用的访问请求的方法、装置、设备和介质
CN116346578A (zh) Kafka双集群实时流量的自动切换方法、装置、电子设备
CN113190416A (zh) 数据库执行计划的预警方法、装置、电子设备和存储介质