IPTV雙AAA中應用緩存提升業(yè)務響應速度的探索與實踐

為貫徹全國IPTV建設管理工作會議精神，落實國家廣播電視總局和地方廣電局《關于開展IPTV專項治理的通知》要求，實現(xiàn)IPTV集成播控平臺、傳輸服務系統(tǒng)的規(guī)范對接，我司于2019啟動計費及運營系統(tǒng)的建設，即AAA平臺的建設。眾所周知，AAA是認證（Authentication）、授權（Authorization）和計費（Accounting）的簡稱，提供認證、授權和計費三種服務。認證是第一道大門，認證速度的快慢以及是否正常直接影響到用戶的第一感知。而授權的要求也是非常高，若每次打開某個視頻，網(wǎng)絡正常的情況下，轉了幾分鐘都出不來畫面；或者明明訂購了某部影片，播放的時候卻提示無法觀看，體驗感就特別差。所以AAA系統(tǒng)必須是響應速度快、信息準確度高、穩(wěn)定性高的系統(tǒng)。下面介紹一下AAA系統(tǒng)是怎么從準實時、到秒級再到毫秒級的提升之路。1.IPTV業(yè)務介紹IPTV即交互式網(wǎng)絡電視，是一種利用寬帶有線電視網(wǎng)，集互聯(lián)網(wǎng)、多媒體、通訊等多種技術于一體，向家庭用戶提供包括數(shù)字電視在內的多種交互式服務的嶄新技術，也是國家三網(wǎng)融合的產(chǎn)物之一。IPTV業(yè)務具有獨特的行業(yè)特殊性，既有傳統(tǒng)電視行業(yè)嚴格的安全播出要求，也有互聯(lián)網(wǎng)行業(yè)高效快速的要求，因此要求用戶開機時必須先進行用戶信息的認證，合法之后才能進入首頁，播放任何一部影片之前，都需要進行鑒權，鑒權通過后方可播放。這要求在認證和鑒權既要準確也要快速。相較于互聯(lián)網(wǎng)電視營銷常用的一個VIP影視大包不同，IPTV目前的影片產(chǎn)品包超級多，例如分為電影包、電視劇包、少兒包等等，這給用戶訂購和鑒權增加了復雜度。另外用戶和可訂購的產(chǎn)品包之間，不是直接的對應關系，中間存在一個服務的概念，一個產(chǎn)品可以包含多個服務，一個服務也可以屬于多個產(chǎn)品，是N對N的關系，當用戶進行播放鑒權時，傳的參數(shù)是影片ID和服務ID，以及用戶的訂購產(chǎn)品，這個時候需要進行查詢，影片對應的服務ID是否包含在已訂購的產(chǎn)品中，如果已經(jīng)訂購，則鑒權通過，都不存在已訂購的產(chǎn)品中，則鑒權失敗，系統(tǒng)部件多、鑒權邏輯復雜。產(chǎn)品、服務、用戶以及影片的對接關系如圖1所示。圖1產(chǎn)品、服務、用戶以及影片的對接關系2.緩存應用場景提升業(yè)務響應速度的探索與實踐根據(jù)總局和區(qū)局的文件精神要求，我司制定了IPTV規(guī)范對接方案，用于規(guī)范和指導IPTV的內容下發(fā)、EPG頁面發(fā)布和認證計費鑒權等流程中播控側和傳輸側的配合和分工。一開始進行規(guī)范對接時，我們遇到的難題就是如何既要規(guī)范對接，又要雙方系統(tǒng)快速響應，不影響用戶的體驗感受。雙AAA對接的有串行和并行方式可選。通過不斷的研究和調測，由于認證的特殊性，認證只有在開機時進行認證，開機本來就需要時間，所以認證的響應時長對用戶的體驗感知上影響不大，所以雙認證采用串行的方式，先通過電信的認證后，再到播控平臺進行認證。如果電信認證不成功，則不會向播控AAA發(fā)起認證請求。目前認證在EPG上設置有token機制，token有效期設置為24小時，24小時內只要不重啟都不會重新發(fā)起認證。超過24小時，token失效返回EPG首頁則會再次觸發(fā)認證請求。難點在于雙鑒權上，鑒權是發(fā)生在用戶點擊播放內容的時候，鑒權需要立即響應，否則用戶體驗上就會出現(xiàn)點擊播放后卡頓、轉圈、黑屏等現(xiàn)象，非常影響體驗效果。而因為內容、用戶、產(chǎn)品、影片的多對多關系，數(shù)據(jù)量非常的大，鑒權響應速度總是提升不上來。考慮到鑒權串行模式的話，響應時長是兩邊響應時長的總時長、并行則響應時長為單邊最長的響應時長，經(jīng)過不斷的研究和調測，最終把鑒權定為并行模式。下一步就是如何攻破提升響應速度這一難點了。雙鑒權模式流程如圖2所示。圖2IPTV雙鑒權模式流程圖2.1初始的1.0模式在系統(tǒng)部署中，我們節(jié)目緩存選擇為Memcache，用戶信息緩存為Redis，用戶訂購信息為Memcache，至于為什么有的選擇Memcache，有的選擇Redis，這里不再贅述。一開始覺得既然要快，那么所有的信息就都放到緩存中，不用到數(shù)據(jù)庫中進行查詢，這個速度肯定快。于是把用戶的所有信息字段以及16位標識符的對應關系放到緩存中，用戶進行認證時，首先到緩存進行查詢，有該用戶，且狀態(tài)正常，則認證通過，沒有則進一步查詢數(shù)據(jù)，數(shù)據(jù)庫再沒有，則認證失敗。認證的模式基本沒有問題。鑒權的緩存，參考其他同行的新媒體模式，即影片、產(chǎn)品、服務以及用戶訂購都放到緩存大池中，跳過產(chǎn)品和服務，按照{用戶：可觀看的節(jié)目}進行緩存，每個用戶為一個小緩存。后來發(fā)現(xiàn)速度并沒有提升，鑒權大約需要3秒鐘的時間，體驗效果不好。最后發(fā)現(xiàn)不能完全參考該省的模式，因為該省的AAA平臺只鑒權增值業(yè)務的影片，而增值影片數(shù)量不是很大，而我們需要鑒權基礎包月包的影片，也需要鑒權增值業(yè)務的影片，因此影片個數(shù)不是一個數(shù)量級的，所有的影片加起來上百萬，用戶也是幾百萬，因此緩存的數(shù)量非常多，緩存查詢次數(shù)多，查詢慢，導致鑒權慢。2.22.0模式在1.0模式的基礎上，我們考慮了本省的實際情況，所有的IPTV用戶都是只要交了IPTV基礎費用之后，就可以播放所有基礎包月中的影片，所有用戶的基礎包中的影片都是一模一樣的。因此把緩存分為兩個集合，一個為“公用收費節(jié)目緩存集合”，另一個為“個人購買的增值收費節(jié)目緩存集合”。當用戶進行播放鑒權的時候，首先去“公共收費節(jié)目緩存集合”進行查詢，如果有該節(jié)目，則鑒權通過，無須再去“個人購買的增值收費節(jié)目緩存集合”查詢，速度明顯提升，基礎包的內容鑒權速度提升到毫秒級別。但是這個時候又發(fā)現(xiàn)了另外一個問題，增值的內容更新服務綁定之后，鑒權不能及時通過，無法及時播放，但是過一段時間又可以播放了。經(jīng)過核查發(fā)現(xiàn)當前現(xiàn)有的“個人購買的增值收費節(jié)目緩存集合”為定時更新，更新時間是4小時更新一次，所以當有新節(jié)目和服務綁定關系發(fā)生時，不會立即更新緩存，這樣會造成部分節(jié)目在小于4小時的時間內鑒權結果無法和實際需求結果匹配。2.33.0模式鑒于2.0模式的4小時問題，我們又進行了進一步的優(yōu)化，考慮到產(chǎn)品、節(jié)目、用戶之間的關系，進行了如下的優(yōu)化：⑴修改收費節(jié)目信息緩存存儲機制。⑵建立三組緩存關系：{節(jié)目：產(chǎn)品}，{用戶：產(chǎn)品}，以及產(chǎn)品為單次狀態(tài)下的{用戶：單點節(jié)目}。⑶當用戶針對節(jié)目鑒權時，首先查找節(jié)目對應的產(chǎn)品信息，如果產(chǎn)品不是單次產(chǎn)品，則查找用戶訂購產(chǎn)品信息，如果有交集，則認為該用戶滿足；如果產(chǎn)品是單次產(chǎn)品，則查找用戶對應的單點節(jié)目緩存關系。⑷如按照以上方式處理，需要注意以下幾點：①用戶訂購時需要更新用戶訂購緩存{用戶：產(chǎn)品}。②用戶退訂時需要監(jiān)測是否更新對應緩存。③后臺管理系統(tǒng)操作添加服務和內容綁定關系時需要更新節(jié)目與產(chǎn)品關系緩存{節(jié)目：產(chǎn)品}。④下發(fā)節(jié)目和服務綁定關系時需要更新節(jié)目與產(chǎn)品關系緩存。優(yōu)化之后，目前的AAA平臺對用戶播放的鑒權效果基本達到了要求，緩存命中率達到99.9%以上，鑒權速度也是200毫秒左右波動，基本符合的業(yè)務要求。2.4當前的4.0模式2019年我們又進行了整體的系統(tǒng)升級，進行了數(shù)據(jù)分層管理、內存管理，需要存放在Redis中的配置和實例數(shù)據(jù)，通過全量或增量方式進行內存刷新，數(shù)據(jù)分為兩種：表數(shù)據(jù)和關系數(shù)據(jù)。圖3為數(shù)據(jù)分層架構圖。支持橫向擴展的數(shù)據(jù)層服務，提供用戶數(shù)據(jù)的定位和管理。圖3數(shù)據(jù)分層架構圖通過發(fā)布接口的方式提供前臺調用，包括開戶、商品訂購、商品退訂、賬號信息變更等業(yè)務接口。通過對Redis的交互，進行請求數(shù)據(jù)轉發(fā)到目標數(shù)據(jù)庫服務，由目標數(shù)據(jù)庫服務進行數(shù)據(jù)業(yè)務處理，并返回結果。維護全局的用戶定位的內存數(shù)據(jù)，保證用戶和商品信息可以被快速定位和訪問。目前通過Redis進行用戶快速定位，需要將用戶數(shù)據(jù)實時刷新到內存。數(shù)據(jù)層包含全局數(shù)據(jù)層和私有數(shù)據(jù)層，全局數(shù)據(jù)層提供面向系統(tǒng)所有客戶的定位，私有數(shù)據(jù)層面向單個數(shù)據(jù)庫的用戶信息。全局數(shù)據(jù)層由單獨的服務器提供，數(shù)據(jù)來源于所有子數(shù)據(jù)庫節(jié)點。私有數(shù)據(jù)層部署在子數(shù)據(jù)庫節(jié)點上，數(shù)據(jù)來源于所在的數(shù)據(jù)庫。包含的同步接口如下：2.4.1客戶信息（全局）【作用】根據(jù)賬號定位出客戶ID、客戶信息、手機號碼、證件信息等關鍵數(shù)據(jù)。根據(jù)客戶ID來定位業(yè)務所屬的子數(shù)據(jù)庫?！綤EY】賬號【VALUE】客戶ID、客戶名稱、手機號碼、證件類型、證件號碼實現(xiàn)邏輯：（1)掃描客戶表對應的iog表，按照主鍵順序獲取。（2)根據(jù)Custid查詢客戶表的客戶資料。（3)調用Redis接口設置對應的key-value值。（4)刪除iog表的記錄。2.4.2商品信息（全局）【作用】用于快速查詢商品核心信息?！綤EY】商品SKU-ID【VALUE】商品名稱、產(chǎn)品名稱、商品價格、包月/季/年/天、其他信息。2.4.3用戶定位（私有）【作用】記錄每個賬號對應的用戶ID，可能有多個賬號屬于同一用戶，形成統(tǒng)一計費關系?！綤EY】賬號【VALUE】用戶ID實現(xiàn)邏輯：（1)掃描用戶表對應的iog表，按照主鍵順序獲取。（2)據(jù)Servid查詢用戶對應的賬號信息。（3)調用Redis接口設置對應的key-value值。（4)刪除iog表的記錄。2.4.4用戶訂購信息（私有）【作用】記錄用戶與計費信息的關系，用戶信息包含所屬年月、累計點播次數(shù)、累計點播額度。用于快速計費，快速加載用戶當月實時賬單（點播使用情況）信息。【KEY】用戶ID【VALUE】所屬年月、在用商品SKUID、到期時間、累計點播次數(shù)、累計點播額度實現(xiàn)邏輯：（1)掃描用戶產(chǎn)品表對應的iog表，按照主鍵順序獲取。（2)根據(jù)prodid查詢產(chǎn)品表的商品信息，根據(jù)用戶ID獲取計費表信息（目前可以寫初始值為0）。（3)調用Redis接口設置對應的key-value值。（4)刪除iog表的記錄。進行了數(shù)據(jù)分層管理以及內存管理之后，我們的鑒權和認證響應速度都得到了很大的