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

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

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

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

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

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

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

騰訊課堂總體技術架構

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

下面介紹一下騰訊在線教育結合騰訊云互動直播技術的案例，我們具體是這么做的。老師直播的時候，接入了騰訊云的互動直播系統，走的是騰訊云私有協議UDP協議。學生端可以實時跟老師進行互動。

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

第一件事，把互動直播系統推過來的流，轉交給全局轉碼模塊。全局轉碼模塊支持定制很多參數，例如可以制定多種分辨率的轉碼方式；可以加上騰訊課堂的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個問題。1、服務擴展性。2、保證服務的可靠性。3、通用性設計。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， 后臺返回丟失的消息列表。通過這樣的方式來解決丟消息問題。

獲取更多詳細資料，請戳以下鏈接：
周錦民：騰訊在線教育視頻互動直播間技術實踐.pdf

問答
互動直播和直播的區別是什么？
相關閱讀
劉連響：小程序實時音視頻在互動場景下的應用
郭卓惺：互動課堂的搭建實例及相關領域應用?
楊婷：騰訊云在線教育解決方案分享

此文已由作者授權騰訊云+社區發布，原文鏈接：https://cloud.tencent.com/developer/article/1154667?fromSource=waitui

歡迎大家前往騰訊云+社區或關注云加社區微信公眾號（QcloudCommunity），第一時間獲取更多海量技術實踐干貨哦~

轉載于:https://www.cnblogs.com/qcloud1001/p/9252595.html

總結

以上是生活随笔為你收集整理的​周锦民：腾讯在线教育视频互动直播间技术实践的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。