【51CTO.com原創(chuàng)稿件】由于直播平臺的特點，對系統(tǒng)功能設計的可靠性要求更高，同時，如何在直播火熱的當下快速實現(xiàn)直播平臺的構(gòu)建，成為很多企業(yè)的現(xiàn)實需求。本文主要分享融云直播互動系統(tǒng)的設計與實踐，詳細介紹禮物、紅包等以消息為基礎的互動方案設計思路和實踐方案并闡述如何結(jié)合融云自身技術(shù)優(yōu)勢，助力直播企業(yè)快速布局市場。

直播互動平臺的特點

融云于 2014 年成立時，國內(nèi)直播平臺還未大批興起，當時我們只提供聊天室服務。2015 年，源于大量客戶對直播互動的需求，融云預見直播平臺未來會有很好的前景，于是開始與客戶積極交流來挖掘需求，最終我們將聊天室轉(zhuǎn)變?yōu)橹辈セ悠脚_。經(jīng)歷了 2016 年一個完整的直播元年，直播互動系統(tǒng)也正式步入了成熟期。

目前，融云主要做實時通信云平臺，就是所謂的 IM 云，提供包含單聊、群聊、客服、推送、公眾賬號、直播平臺等云服務。得益于 2016 年直播市場的異?；馃?，平臺每天可達到對外產(chǎn)生 2200 億條消息，峰值每小時 450 億，每秒高達千萬的分發(fā)。

直播互動平臺的特點是什么呢?我們做視頻直播的時候，可能有用戶需要跟主播以及其他用戶發(fā)一些文字消息、點贊消息等等進行互動，由于這些消息的存在，把以前單純的只是受眾于視頻的應用這種視頻直播，變成了可以進行互動的平臺。

用戶在平臺發(fā)消息進行互動，這個互動場景和聊天室類似，就是用戶加入聊天室，可收到別人的消息，同時也可發(fā)送消息，用戶下線時消息不再進行推送，這個場景實際上可以滿足簡單的直播互動。

相較其他 IM 來講，沒有離線消息存儲，也沒有離線消息 Push，在業(yè)務形態(tài)來講，聊天室比較簡單一些。

如下是直播互動平臺的主要特性：

• 直播互動平臺的用戶量實際是無上限的，因為不可能去限制一個主播加入觀眾的成員數(shù)量。
• 通過把消息進行分級控制的方式來保證禮物、紅包等消息傳輸?shù)目煽啃浴?/li>
• 瞬時消息吞吐量大，融云某個聊天室曾經(jīng)一秒鐘產(chǎn)生過近千萬的消息。
• 針對伸縮及穩(wěn)定性方面的高要求。

消息平臺的邏輯設計及設計原理

消息是直播互動系統(tǒng)最重要的元素，消息處理做的好不好會直接影響用戶的體驗。融云的消息平臺邏輯設計是怎樣的呢?

如上圖，我用一張時序圖針對這個問題進行了解答。A 客戶端是發(fā)消息方，服務端是融云整個后端平臺，B 客戶端是接收消息方。

首先，客戶端向服務端發(fā)送消息，服務端接收消息先進行消息驗證，消息驗證里面包含了高危詞、敏感詞的過濾，反垃圾系統(tǒng)對消息進行反垃圾的過濾及權(quán)限驗證。

當消息通過之后，對消息優(yōu)先進行存儲，之后會給 A 客戶端返回應答，告知消息已經(jīng)發(fā)送成功，這時服務端會遍歷成員分發(fā)通知。

值得注意的是，現(xiàn)在還沒有向客戶端發(fā)送消息實體，當接收客戶端接收消息通知時，會從自己本地存儲里面拿到當前直播間里面最新的消息版本號。

同時向服務器發(fā)起同步請求，服務器獲取客戶提交的版本號之后，會以這個版本號為起點，到最新版本號把所有消息全部拿回來返回給客戶端，客戶端收到這個消息進行消息展示以及存儲這個最新版本號。

整個通信流程，版本號獲取方式，跟常用版本控制軟件比較類似。之所以把流程變得這么復雜，在發(fā)送完通知之后再同步消息，主要原因如下：

• 通知的推送重試可以依賴 TCP 的重試，無須邏輯保障。
• 服務器端存儲的消息順序與到達的客戶端順序一致。
• 當消息密集時可以將多條消息進行合并。
• 可以控制下發(fā)的消息條數(shù)。
• 以存儲分級實現(xiàn)消息分級。
• 不以消息數(shù)量衡量服務器規(guī)模，以在線用戶數(shù)量做為考量。

消息平臺在服務端實現(xiàn)細節(jié)及最佳應用實踐

直播消息系統(tǒng)在服務端的實現(xiàn)細節(jié)，主要從數(shù)據(jù)預處理、消息分級、消息存儲和消息分發(fā)隊列四方面進行介紹，但在實際服務開發(fā)過程中，還有很多優(yōu)化。

數(shù)據(jù)預處理

當服務端接收消息之后，優(yōu)先對數(shù)據(jù)進行序列化以及存儲，序列化消息和要下發(fā)的客戶端數(shù)據(jù)要保持一致，通過這種預處理的方式，CPU 的使用率在當前基礎上降低了 30%。

消息分級存儲

根據(jù)消息類型按照中、高、低序列進行分級存儲。

Skiplist 轉(zhuǎn)化為環(huán)形隊列存儲

每條消息有唯一且遞增版本號，消息按照版本號順序存儲。這樣的數(shù)據(jù)在內(nèi)存存儲情況下，跳表是一種非常合適的數(shù)據(jù)結(jié)構(gòu)。

但是，跳表時間復雜度和空間復雜度比較大，同時往跳表中插入數(shù)據(jù)時使用的鎖范圍非常大，會對服務器產(chǎn)生一些額外的開銷。之后，由跳表演進成一種類似環(huán)形隊列的數(shù)據(jù)結(jié)構(gòu)，會對服務器性能開銷提升很多。

Map 與隊列構(gòu)建復合數(shù)據(jù)結(jié)構(gòu)，降低無意義消費

服務端下發(fā)通知，對于通知來講在這一時刻無論有多少條消息，每個用戶只有一條通知，通過 Map 與隊列構(gòu)建這樣的復合結(jié)構(gòu)進行存儲。

隊列里面存儲是數(shù)據(jù)的指針，Map 存儲用于下發(fā)的通知實體，Map 使用的 key 為用戶標識，這樣可以降低無意義的消費。

融云線上直播互動平臺的整體架構(gòu)

直播互動平臺的 2.1 架構(gòu)

如上圖，是融云線上 2.1 架構(gòu)圖，可分為連接層、業(yè)務層和存儲層等，連接層和業(yè)務層構(gòu)建成整個大的集群，然后進行服務。

連接層主要是負責客戶端與服務器保持長連接，同時將客戶端的協(xié)議與內(nèi)部服務的協(xié)議進行相互轉(zhuǎn)化。

業(yè)務層負責 IM 相關(guān)業(yè)務處理，采用的是微服務架構(gòu)，線上服務有 40 多個類型，但對于直播互動平臺包含如下三項服務：

• 上行控制服務。主要目的是用于處理接收的上行客戶端的消息，進行敏感詞和高危詞的過濾。這個服務的負載方式采用的是隨機分配。
• 直播服務。負責維護直播間的成員關(guān)系和負責接收上行控制服務給它的消息，上行控制服務會先期進行消息拋棄，拋棄到直播服務可以接收的范圍之內(nèi)，然后將消息下發(fā)到直播服務，直播服務再廣播到直播消息服務。
• 直播消息服務。負責給用戶進行分發(fā)通知，是以用戶 ID 進行一致的哈希方式進行負載。每個服務節(jié)點包含部分用戶關(guān)系。

整個直播消息服務構(gòu)建了一個整體成員關(guān)系，等同于直播消息服務上的一個節(jié)點。這層除分發(fā)通知外，還負責客戶端同步拉取獲取的消息。

存儲層主要職責是用來存儲各種消息，數(shù)據(jù)等，含多個數(shù)據(jù)庫。

線上 2.1 架構(gòu)和之前的架構(gòu)相比，降低了直播服務壓力和上行總量的控制，但面臨的問題是需要更高的網(wǎng)絡質(zhì)量要求。

直播互動平臺的網(wǎng)絡優(yōu)化

如下圖，是鏈路架構(gòu) 1.0：

鏈路架構(gòu) 1.0，線上進行網(wǎng)絡加速主要是加速海外業(yè)務。融云選購了第三方海外專線鏈路，涉及全球五個國家，覆蓋歐洲、美洲以及中東、日本等等。

實現(xiàn)國際鏈路優(yōu)化，就近區(qū)域接入的同時，又出現(xiàn)專線的流量過大，成本過高，跨國消息延時等問題。

如下圖，是鏈路架構(gòu) 2.0：

鏈路架構(gòu) 2.0 采用模擬 CDN 模式進行數(shù)據(jù)分發(fā)，專線內(nèi)只跑上行消息和廣播消息的方式。

融云提供的是直播互動平臺，是一個基礎的 PAAS 服務，本身并不會去做直接面對用戶的直播 APP。未來，它也會不停地向前探索，如降低專線的依賴，數(shù)據(jù)中心進行鏈路選擇等。

以上內(nèi)容根據(jù)李淼老師在 WOTA2017 “高性能直播系統(tǒng)架構(gòu)”專場的演講內(nèi)容整理。

[[201062]]

負責融云后端服務平臺的設計和架構(gòu)工作，2007-2013 年就職于移動飛信團隊，歷任高級技術(shù)經(jīng)理，架構(gòu)師，一直關(guān)注大規(guī)模高并發(fā)系統(tǒng)設計和研究。

【51CTO原創(chuàng)稿件，合作站點轉(zhuǎn)載請注明原文作者和出處為51CTO.com】