周錦民：騰訊在線教育視頻互動直播間技術實踐

時間 2019-12-19

原文原文鏈接

本文來自騰訊雲技術沙龍，本次沙龍主題爲在線教育個性化教學技術實踐linux

演講嘉賓：周錦民 | 2011年畢業進入騰訊，現任在線教育部在線教育後臺中心高級工程師，多年linux後臺開發工做經驗，目前主要負責騰訊課堂和企鵝輔導兩款產品的後臺系統架構設計與研發管理。c++

今天分享的主題分三個部分。第一部分，跟你們介紹一下騰訊課堂和企鵝輔導這兩款產品。第二，講一下課堂直播系統，和騰訊雲這邊的具體實踐案例。第三，談一下在線教育的房間系統設計方案和這幾年過程當中的優化效果。redis

騰訊課堂是什麼？(ke.qq.com)

騰訊課堂是什麼？騰訊課堂是騰訊推出的在線教育平臺，它會聚了大量的優質機構和講師，涵蓋了大量的精品課程。包括考驗考證、IT教學、英語培訓等等。這裏給老師一站式的線上教學和學生的互動學習體驗，這是咱們的課堂特色。咱們有海量的資源和流量，目前的入駐機構超過了4萬多家，其中在線教育課程超過了20多萬了。各類各樣的科目類型能夠選擇，目前累計的上課數3000萬，每週有超百萬級，目前單門課程同時在線6萬人。騰訊課堂裏面有豐富的教學教務工具，助力機構和老師有一個更加豐富的教學管理。算法

企鵝輔導是什麼？(fudao.qq.com)

企鵝輔導是面向小學、初中、高中的學生在線學習平臺，目前已經有教師團隊200多人，學科覆蓋10個年級，有200萬的學生用戶。這是企鵝輔導的教師團隊，他們都是咱們輔導的全職教師團隊，這些老師都是來自於清華、北大各個名校，咱們曾經是各科的高考狀元。企鵝輔導有完整細緻的教學任務，從學前到學後，助力學生完整地提高。企鵝輔導支持直播1V1的答疑輔導，還有專業的課後老師給學生進行做業的批改。企鵝輔導有各類各樣的輔助學習工具，例如在線互動搶答，利用圖像識別技術，在線拍照批改，還有搶紅包互動，提高學生的學習興趣。騰訊課堂和企鵝輔導支持多終端學習，在電腦或手機上能夠輕鬆學。sql

騰訊課堂整體技術架構

下面是騰訊課堂整個後臺的技術架構，終端包括PCQQ、H5端、APP端、PC獨立版、Mac端。通道層，這是對應的通道。接入層是統一的接入層，主要做用是把各端各自的協議，轉成內部的通訊協議。邏輯層。咱們整個教育課堂後臺主要分三大塊，第一塊，是機構平臺，包括資料、訂單支付、活動運營。第二塊，是直播系統。第三，房間系統。下面是咱們的核心模塊，就是基礎功能，像數據中心、訂單系統、基礎資料、我的中心。存儲層有多種，Mysql、Ckv、Es、Redis。數據庫

下面介紹一下騰訊在線教育結合騰訊雲互動直播技術的案例，咱們具體是這麼作的。老師直播的時候，接入了騰訊雲的互動直播系統，走的是騰訊雲私有協議UDP協議。學生端能夠實時跟老師進行互動。小程序

騰訊雲的互動直播系統，會經過旁路推流，轉發音視頻流給騰訊雲直播系統。直播系統接入模塊收到推過來的流，會作兩件事情。api

第一件事，把互動直播系統推過來的流，轉交給全局轉碼模塊。全局轉碼模塊支持定製不少參數，例如能夠制定多種分辨率的轉碼方式；能夠加上騰訊課堂的LOGO水印，並支持視頻加密，保證視頻的資料、知識產權的安全，還有支持多種協議的封裝等。緩存

第二件事情，全局轉碼模塊會提供音視頻流給雲端混流功能，雲端混流功能也是直播系統的能力。這個功能怎麼用呢？它支持預設多種混流模塊。咱們教育這邊有幾款產品，好比咱們有PPT、畫中畫、學生端的舉手上麥。咱們會預設幾種混流模板，當老師把PPT切畫中畫，或者畫中畫切PPT，或者有學生舉手上麥的時候，客戶端會發起一個變動信令到教育服務，教育服務這邊會調雲端混流服務的接口，來改變混流的方式。雲端混流模塊會根據混流模板的要求，到直播接入模塊拉取指定的多路音視頻流，而後把多路流合成一路，再交給全局轉碼進行從新轉碼。轉碼完成以後，交給分發模式，分發模塊把音視頻文件緩存到cdn模塊。安全

騰訊雲的cdn模塊，在國內有1000多個加速節點，全球有200多個加速節點。由於騰訊課堂這邊的老師、學生遍及國內外。經過這些CDN節點的加速，可以給課堂的直播提供一個穩定良好的播放質量。

直播的時候，咱們H5和PcWeb端採用的是通過混流後的一路流的方式，這種方式它的好處就是可以減小手機帶寬流量，兼容性和穩定性更好。

直播的同時，騰訊雲的點播系統還會實時進行錄製。錄製的時候，會產生多個錄製文件分片。結束以後，會把分片拉回到本地，從新對這些分片進行視頻對齊，會從新進行佈局、調整，包括分辨率調整，而後插幀補流，當有視頻斷流時，會插入帶有課堂logo的靜態畫面，保證音視頻的連貫性。最後從新生成定製的回放文件。這樣學生看錄製回放的時候，能有一個連貫性的觀看體驗。

最後是錄製的方式。錄製這邊學生端也支持錄播一路的方式或者錄播多路的方式。PC端因爲家庭帶寬足夠穩定，咱們採用的是錄播多路的方式。路過多路的方式在客戶端能夠作不少定製化的需求。好比回放過程當中，PC客戶端能夠動態調整畫中畫和ppt的切換，分辨率或佈局的調整。

以上就是在線教育課堂結合騰訊雲音視頻產品的實踐。咱們運用了騰訊雲提供的的互動直播、直播、點播、CDN加速、視頻加密的一整套解決方案。應用了騰訊雲一整套解決方案，咱們還須要作的事情就不多了。如今騰訊內部CTO和公司總辦們也在大力推廣技術總體上雲的發展戰略。咱們也積極響應領導的號召，積極上雲，這樣能夠大大減小音視頻這塊的運營和維護成本，能夠把更多的精力聚焦於產品打磨，給老師和學生有一個更好的產品體驗。

房間系統架構

房間系統的架構請觀看下面的流程，它分幾個模塊。首先是接入層，進出代理服務接入客戶端請求，並把請求轉發給心跳服務和成員列表進行狀態存儲。接着是邏輯層，它包括不少課堂交互的功能，好比學生舉手、聊天區、紅包互動等等，每一個交互行爲會產生一個消息，經過push代理服務把消息轉播給其餘老師和學生。

房間系統在開發過程當中咱們遇到三大挑戰。心跳服務，成員列表，由於併發量很是大，那怎麼作到平滑擴容？怎麼保證服務的可靠性和可用性，還有容災怎麼作？另外消息push服務，怎麼保證通用性和易用性，怎麼保證消息的可靠性？在消息併發量高的時候，怎麼解決消息風暴致使服務過載的問題？下面分別講一下這三個模塊咱們的一些優化實踐。

心跳服務優化

心跳服務優化以前，它採用msgq接入（msgq是騰訊自研的內存消息隊列），採用雙機單進程模型。這個方案實踐簡單，在項目初期的時候可以知足業務快速上線，但隨着用戶量愈來愈大，如今已經沒法支撐如今業務的實現。它如今有幾個問題，高峯時期容易丟消息，當系統消息量忽然間增大的時候，msgq緩衝隊列到達上限或者msgq服務異常就有丟消息的風險。第二，邏輯複雜、不通用，好比超時檢查、多終端登陸須要定製開發。第三，由於心跳服務要保存目前的心跳狀態，如今雙機相互同步的方案沒法擴容。基於這三個問題咱們作了新的優化。

下面是新版的優化方案。咱們把心跳服務的架構分了兩層，心跳代理heart_proxy和心跳存儲服務heart_svr，而後經過L5服務進行路由。L5是什麼呢？L5是騰訊內部的路由決策服務。

新版的心跳服務要解決4個問題。一、服務擴展性。二、保證服務的可靠性。三、通用性設計。四、踢人檢測，避免誤踢。

擴展性方面，擴展性咱們怎麼作呢？咱們解決方案是引入了一致性哈希算法。根據業務bid+房間roomid+用戶qq進行hash，把請求路由到指定的heart_svr進行存儲。
可靠性方面，當某一個心跳存儲節點掛掉的話，L5服務會在1分鐘以內發現，並把此臺機ip剔除。Proxy就會把它路由到其餘正常節點上面去。經過這個方式，來保持心跳狀態的繼續維持。
通用性設計方面，咱們如今有課堂和輔導兩款產品，後面可能還有其餘新產品出現。每一款產品都涉及到心跳的功能，因此咱們預先把心跳服務做成一個通用的服務，引入業務號Bid的方式，這樣多個產品能夠套用同一套心跳服務，以此解決多個產品的共用問題。
踢人檢測方面，很重要的一個點怎麼避免誤踢？好比學生正在上課，忽然間被踢出課堂，就會引發學生的反饋，對學生形成不友好的體驗。因此一個心跳存儲節點發現某一個用戶超時的時候，會給heart_proxy發起反查，heart_proxy會把查詢請求廣播給全部heart_svr存儲節點，經過這種方式來保障踢人安全。

成員列表服務優化

成員列表的初期版本，採用了代理加CKV存儲的方式。CKV是騰訊內部的自研的key-value數據庫。每一個房間的成員列表用pb序列化後存入ckv，須要讀取時是總體讀出來再進行反序列化使用，這種方式存儲幾個問題。

第一，當房間用戶量過多，頻繁進出房間產生大量的網絡IO。一個用戶信息如今有40Bytes，若是有1萬人的話，成員列表就有400多K。若是是使用高峯期的時候，大量的網絡IO，網卡就成爲了瓶頸。
第二，CAS衝突嚴重。由於對ckv服務進行頻繁的更新、刪除、修改操做，會形成大量cas衝突，這樣會影響到服務性能。
第三，讀寫性能低。ckv get的方式，長列表反序列化耗時。整體上性能還打不到200qps,超時比較嚴重。目前咱們的用戶量已經高了不少，目前的架構已經沒法知足如今的需求，新版咱們作了改造。

新版的改造咱們怎麼作了？咱們調研了幾種存儲選型。

首先是redis，它是支持成員列表和排行榜存儲。但咱們的業務成員列表須要有定製化的查詢需求，例如按照版本號查詢，按照平臺類型查詢等，還須要支持分頁。在這一塊，redis的數據結構支持不夠。
第二個是grocery，是騰訊內部自研的存儲方案，採用的是多階hash的方式，它完美支持如今成員列表的存儲選型。問題是它的長度有限，最多支持5000人，如今QQ列表在用。但咱們單房間如今人數已經超過w級別，因此這種方案如今也不適合。
第三個是分級ilst，用於微博的場景，它支持超長列表。主要用於離線paas，延時較高。
第四個是phxkv，phxkv是微信出的一個解決方案，基於phxkv協議，強一致性、性能好。這個方案我目前在調研中。

目前咱們最終採用的是內存存儲，多主同步的設計方案。它由以下幾個特色：

全內存結構,使用二級hash_map結構,c++stl的標準數據結構,多主模式。最終一致性模型,寫完就返回,性能好,靠心跳來修復。單set性能可到3w qps。
擴展性,按照業務bid來分檔存儲,按照proxy來中轉,保證可擴展性。
內存列表數據每3分鐘dump到虛擬磁盤,保證重啓快速恢復。
一致性：
1)心跳修復，保證最終一致性
2)同時提供強一致性的api能力，經過多讀方式實現。

消息push優化

消息push優化前，每一個邏輯服務獨自拉成員列表，還要制定對應的每一個通道的push代理。此方案的缺點是代碼很是冗餘，沒有統一的接口，模塊間的強耦合。如今這個方案是沒法知足咱們的需求快速迭代開發，因此咱們對這個方案進行了改造。

新版消息push改造方案，新版push主要分三塊：push_proxy統一接入層，引入騰訊雲的ckafka作消息緩衝，引入redis作異步消息存儲。

push_proxy支持多種業務定製push方式：單播、廣播、指定人、指定角色、指定端。

咱們對push服務作了性能優化：

pushProxy採用的是進程級cache，緩存大房間（>2000人）成員列表，2s超時。小房間實時啦成員列表，保證push實時性。怎麼使用cache的。全局仍是進程級的?
消息分級：重要和非重要消息。若是消息比較少,那麼就直接推送,過多就走消息合併機制。這是msg_center能力，可以實時累計消息數，超過閥值採用合併推送
另外，老師客戶端也是提供直接禁言能力，防止惡意用戶刷屏。
房間大班拆小班，分小班推送，避免聊天消息滾屏，加強用戶體驗。

容災降級咱們怎麼作呢？

在正常狀況下，老師端能夠主動禁言。
另外支持全局流控，以時間戳(s)爲單位,限制向下遊push的消息總量。每當pushProxy的qps超過了3k/s,就反饋到edu_msg_center下降聊天消息頻率，以此保證重要消息正常push。

最後是消息可靠性的實踐：

消息實時推送，異步保存redis，採用kafka消息隊列能力緩解擴散寫壓力。
客戶端若是丟消息怎麼辦？處理方案：每一個用戶收到的push消息都帶有嚴格自增的msgid，客戶端維護已收到的最大msgid和缺失的msgid列表；定時2s上報丟失的msgid列表和收到的最大msgid，後臺返回丟失的消息列表。經過這樣的方式來解決丟消息問題。