[發明專利]基于動態漏桶算法的實時音視頻服務的通話方法

有效

• 申請號: 201910098688.4
• 申請日: 2019-01-31
• 公開（公告）號: CN109639915B
• 公開（公告）日: 2020-02-21
• 發明（設計）人: 王勇;姜大權
• 申請（專利權）人: 上海天好信息技術股份有限公司
• 主分類號: H04M3/523
• 分類號: H04M3/523
• 代理公司: 上海精晟知識產權代理有限公司 31253
• 代理人: 馮子玲

本發明公開了一種基于動態漏桶算法的實時音視頻服務的通話方法，可以根據用戶請求數據的優先級實時更新漏桶內數據隊列，保證優先級高的用戶請求得到優先處理，同時，對用戶請求判斷是否已經超出處理的最大承載量，若超出則進行友好提示后忽略，保證音視頻服務的高效流暢運轉。本發明的基于動態漏桶算法的實時音視頻服務的通話方法，可以避免用戶長時間等待，通過漏桶算法保證整個系統高效流暢運行，實時漏桶內數據隊列更新，保證漏桶內的數據最大承載量的實時更新及高優先級用戶請求優先處理。

技術領域

本發明涉及通信方法技術領域，尤其涉及一種靈活性高，可以快速處理緊急請求的基于動態漏桶算法的實時音視頻服務的通話方法。

背景技術

現有老百姓辦事都要本人去政務中心，對鎮村級或者地域廣的地區，如新疆，內蒙古的人來說很不方便，可通過實時音視頻可實現24小時在線服務，大大方便民眾辦事，并提高辦事效率。但是在實現過程中存在一些難題：

難題1：當有大量用戶同時進行視頻請求時，如何高效的將用戶的呼叫請求隨機分發給坐席人員，避免長時間等待的情況？

難題2：用戶請求量已超出系統處理范圍，沒有足夠的坐席人員來處理，如何處理再進來呼叫的請求？

難題3：當有新的坐席人員上線，或者在線的坐席人員掉線，在等待中的用戶請求如何處理？

現有的Webrtc是在瀏覽器端實現音視頻通話的通話標準，只能實現如打電話類似的點對點通話服務，在多用戶端呼叫多坐席端接收時，需要額外實現呼叫分發的功能，否則音視頻服務將無法高效流暢的運轉。

因此，有必要提出一種新的基于動態漏桶算法的實時音視頻服務的通話方法以克服現有技術缺點。

發明內容

本發明的目的是解決現有技術中的問題，提供一種可以快速處理緊急請求的基于動態漏桶算法的實時音視頻服務的通話方法，保證音視頻服務高效流暢地運轉。

本發明的技術方案是：一種基于動態漏桶算法的實時音視頻服務的通話方法，包括以下步驟：S1、收集用戶請求數據及已上線的坐席人員數據；S2、根據所述用戶請求數據判斷所述用戶請求數據的優先級并進行標注；采用漏桶算法，根據所述坐席人員數據判斷漏桶最大承載量，將標記后的用戶請求數據進入漏桶，根據用戶請求數據的優先級安排出桶順序；S3、當新的用戶請求數據a超出漏桶最大承載量時，比較所述新的用戶請求數據a的優先級與漏桶內原有數據的優先級以判斷所述新的用戶請求數據a的處理方法；S4、服務器分配所述用戶請求數據與所述坐席人員數據進行匹配，坐席人員確認服務器發送的確認指令后，服務器為用戶和坐席人員打通連接，此后便可進行點對點的音視頻通話。

作為一種優選的技術方案，所述步驟S3內比較所述新的用戶請求數據a的優先級與漏桶內原有數據的優先級以判斷所述新的用戶請求數據a的處理方法具體為：若所述新的用戶請求數據a的優先級高于漏桶內的原有數據b的優先級，則將所述新的用戶請求數據插入到漏桶內并排放于所述原有數據b之前，將漏桶中最后一個數據c從漏桶中溢出，給予用戶友好提示并不再處理所述漏桶中最后一個數據c，需要用戶重新提出請求數據；若漏桶內沒有優先級低于所述新的用戶請求數據a的數據，則給予用戶友好提示，不會將所述新的用戶請求數據進行處理，需要用戶一段時間后重新提出請求數據。

作為一種優選的技術方案，在執行步驟S2及S3時，系統會根據新的用戶請求數據及已上線的坐席人員數據動態更新漏桶最大承載量及漏桶內用戶請求數據的順序。

作為一種優選的技術方案，所述已上線的坐席人員數據存儲于redis緩存數據庫內，所述漏桶內的用戶請求數據也存儲于redis緩存數據庫內。

作為一種優選的技術方案，所述漏桶中的用戶請求數據采用鏈表結構。

作為一種優選的技術方案，所述漏桶的最大承載量由所述已上線的坐席人員數據決定，所述漏桶的最大承載量為已上線的坐席人員數量的5倍。