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