劉志勇：微博短視訊百萬級高併發架構

本文來自新浪微博視訊平臺資深架構師劉志勇在LiveVideoStackCon 2018講師熱身分享，並由LiveVideoStack整理而成。分享中劉志勇從設計及服務可用性方面，詳細解析了微博短視訊高可用、高併發架構設計中的問題與解決方案。

文 / 劉志勇

整理 / LiveVideoStack

直播回放：

https://www.baijiayun.com/web/playback/index?classid=18091254327792&session_id=201809131&token=V-GypC7MX7Rt681rrJ0J_YZjM5wzBWRKromDMAweLMaYPgi2WdpRNiiafcpzt7HXn2QZxUVW5JoKp0fXMnVKLQ

大家好，我是來自新浪微博的劉志勇，今天與大家分享的是微博短視訊業務的高併發架構，具體內容分為三個方面：

1、團隊介紹

2、微博視訊業務場景

3、“微博故事”業務場景架構設計

1、團隊介紹

我們是隸屬於微博研發部視訊平臺研發部門的技術團隊。平臺研發是微博的核心部門之一，包括大家熟知的微博視訊在內的微博所有核心業務的基礎平臺架構、使用者關係體系等都依賴微博平臺研發部門的技術支援。我們的團隊主要負責與視訊相關的上層業務也就是視訊微博、“微博故事”以及短視訊和直播，其中直播包括常規的直播與直播答題等新玩法；同時我們還負責底層視訊平臺的架構搭建，包括檔案平臺、轉碼平臺、配置排程中心與媒體庫。我們致力於用技術幫助微博從容應對每天百萬級的視訊增量與其背後多項業務的多種定製化需求。

2、微博視訊業務場景

我們的業務場景主要是應對熱門事件的流量暴漲，例如明星緋聞、爆炸性新聞等勢必會讓流量在短時間內急劇增長的事件。如何從架構上保證流量暴漲時整體平臺的穩定性？如果只是簡單地通過調整伺服器規模解決，流量較小時過多的伺服器冗餘帶來成本的浪費，流量暴漲時過少的伺服器又令平臺服務處於崩潰的邊緣；比較特別的是，我們面臨的問題與諸如“雙十一”這種在某一確定時間段內流量的可預見式高併發有著本質的不同，我們面臨的流量暴漲是不可預見的。因此通過哪些技術手段來妥善解決以上問題，將是接下探討的重點。

以上是基於微博的過去已經公開資料量級，非近期內部資料。微博視訊是一個多業務接入的綜合平臺，你可以在微博上看見現在市面上的各種玩法。這就導致我們即將面臨的並不是某個垂直業務領域的命題，而是一個構建在龐大體量下的綜合性命題，這就導致現有的通用技術框架無法妥善解決我們所面臨的難題。因為一些開源方案無法順利通過技術壓測，所以我們只能在開源方案的基礎上進行自研與優化才能得到符合微博應用場景需求的技術解決方案。

微博的短視訊業務被稱為“微博故事”，上圖展示的是“微博故事”的展現形態。這是一個佈置在微博首頁一級入口上的模組，主要展示的是使用者關注的人所上傳的15秒內的短視訊。我們希望強調其“即時互動”的屬性，視訊只有24小時的有效展示時間。不同使用者的視訊按照時間軸在上方排序，多個視訊可依次觀看、評論、點贊等。

3、“微博故事”業務場景架構設計

3.1 微服務架構

上圖展示的是這項業務的微服務架構：在介面層我們混布了Web API與內部的RPC請求；在這裡我們並未整合具有實際意義的門面層，而接下來的服務層整合了許多微服務，每個微服務集中在一個垂直功能上並可對外提供介面，這裡的門面層主要作用是聚合一些微服務並對外提供綜合性介面；除此之外還有一些依賴服務例如使用者關注、也需要依賴於其他部門的RPC服務；最後的儲存層則是整合了Cache與db的標準方案。

3.2 技術挑戰

有人曾問到：微博短視訊業務的高併發有多高？假設我關注了500名好友，如果有好友釋出一個視訊就會在“微博故事”頭像列表上顯示一個彩圈用以提示我去觀看；如果我想知道自己所有關注的500個人所發的視訊內容，假設首頁每秒重新整理十萬次，那麼需要每秒鐘五千萬的QPS。除此之外我們還需要確定視訊是否過期、視訊傳送順序等，實際的資源層讀取量將遠遠高於五千萬。

3.3 方案比較

 

在構建解決方案時我們思考：可以借鑑微博之前的Feed解決方案，我們不會進行無意義的重複性工作與思考。即使短視訊與Feed都具有首頁重新整理與關注人釋出訊息聚合的特點，但以使用者列表為形式，強調進度續播與即時互動的短視訊和以內容列表為形式，強調無閱讀狀態與永久儲存的微博具有本質的區別。

面對一般的Feed應用場景可以使用以下兩種模型：Feed推模型與Feed拉模型。

1）Feed 推模型

Feed推模型是指將使用者上傳發布的內容推送至每一位粉絲，這種方案具有很大的弊端。由於使用者尚未達成一定規模，早期的微博以Feed推模型為主導。而現在一個大V使用者的粉絲數量普遍都是千萬級別，如果依舊使用Feed推模型則意味著千萬量級的內容推送，在難以保證千萬份推送一致性的情況下，勢必會為伺服器帶來巨大壓力。微博的業務強調的就是強時效性下的內容一致性，我們需要確保熱點事件推送的瞬時與一致。除了從技術層面很難確保千萬級別內容推送的時效性與一致性，由於使用者上線狀態的不統一，為離線的使用者推送強時效性的內容無疑是對伺服器等資源的巨大浪費，為了避免以上麻煩我們必須改變思路。

2）Feed 拉模型

Feed拉模型：拉取關注的人並實時查詢狀態及內容。綜合微博的龐大使用者體量、資料寫入開銷與確保一致性三方面我們決定選擇Feed拉模型。

 

如何通過Feed拉模型應對如此規模龐大的QPS？首先我們採用了分散式快取架構，在快取層整合了資料分片並將快取通過雜湊演算法合理分片，之後再把快取去切片化並進行存取。

3.4 分散式快取架構

其次我們使用了獨有的多級快取方案也就是L1、 Master 、slave三層快取方案。L1是一個熱度極高容量極小的快取，我們稱其為“極熱快取”，其特點是便於橫向擴充套件。假設L1只有200MB快取，我們使用LRU演算法通過熱度分析把訪問最熱的資料儲存在L1中；之後的Master 與Slave的快取空間則是4GB、6GB，比L1大很多倍。因為微博的流量比較集中於熱點事件中某幾位明星或某個新聞，小容量的L1可進行快速擴容；在發生熱門事件時利用雲的彈性自動擴容從而分擔熱點事件短時間激增的流量壓力；由於自動擴容時L1僅佔用每臺快取中很小的空間，擴容的速度就會非常快，通過這種手動或自動的瞬間彈性擴容來確保伺服器穩定承受熱點事件背後的資料激增量。第二層的Master與 Slave具有比L1大好多倍的快取空間，主要用於防止資料冷穿。雖然L1主要承擔的是熱點資料，但卻無法確保一些短時間內不熱但在某個時間段熱度突然高漲所帶來的流量短時間爆發時伺服器的穩定性。

3.5 HA多機房部署

而Master 與Slave作為L1的邏輯分組可有效防止資料過冷，在這裡我們採用的是HA多機房部署。例如圖中的的兩臺IDC，我們稱左邊為IDC-A，右邊為IDC-B。快取層的Master 與Slave是主從同步的關係，雙機房的快取互相主從同步。這裡的“互相主從同步”是指IDC-A的MC與IDC-B的MC之間進行雙向同步互為主從。因為在進行雙機房部署時需要均衡兩個機房的流量負載，在快取層需要使用LRU演算法進行熱度分析。如果我們將流量分為兩份並傳輸至兩個機房，通過每個機房的IRU演算法得到的熱度資訊有一定失真；如果我們在快取層做相互同步後每個機房的MC都是一個全量的熱度演算法，那麼兩個機房的L1基本可實現同步計算得出的熱度資訊一定是準確的，只有保證熱度資訊的準確無誤才能從容應對流量激增與整個系統的高可用性。在這裡需要強調的是，實際上我們在選型上使用的是MC而未使用Redis。

MC對於純簡單資料Key,value的抗量遠大於Redis；MC採用預分配記憶體的形式放置Key,Value，也就是把記憶體分成若干組相同資料區域，實際上就是若干個陣列。這種特殊結構使其在資料定位陣列定址與讀寫上的速度非常快；這種結構的缺點是：一旦快取的資料出現變動就會出現即使記憶體留有空餘但資料依舊無法儲存的現象。由於這種問題的存在，MC不適用於儲存變動大、Value跨度大、業務多變的資料。而Redis作為單執行緒方案，一致性更好，但在超大規模簡單Key,Value讀取上速度比MC是要差很多的。

除了上述方案之外，我們還採用了彈性擴縮容。實際應用中，基於成本的考量我們無法部署大量的伺服器，於是我們採用了自研的DCP彈性擴縮容平臺。首先，我們的自有機房有一些共享機器資源可在特殊情況下動態彈性擴充以應對增加的流量壓力。當然，這部分機器的效能是有限的，當資料量超過一定閾值後我們就會接入阿里雲並利用我們與阿里雲的混合雲DCP方式構建一層彈性軟平臺用於自動擴容承擔流量壓力；除了彈性擴容我們同時也採用了定時擴容的邏輯，在每天晚高峰時段進行擴縮容從而確保整體服務的穩定性。之所以這麼做，主要是為了在保證使用者體驗的前提下儘可能節約成本。

需要強調的是，擴容對速度的要求十分嚴格。只有擴容的速度越快，流量峰值來臨時可承受的資料量越大，才能確保整體服務的高可用，因而我們也在努力優化擴容的速度。我們的DCP平臺上也有晚高峰固定時段擴縮容與突發流量臨時擴縮容，通過如流量監控等的自動化容量評估來判斷伺服器荷載，並通過自動化任務排程妥善解決突發流量對伺服器的影響。

3.6 微服務熔斷機制

當然，為了保證伺服器整體的健康與穩定，我們也在其中整合了微服務熔斷機制，其原理類似於家用電錶中的保險絲，可在過載的情況下迅速自動熔斷。系統會定期進行自我評估並確定每個服務的最大荷載，假設將熔斷值定為3000QPS，那麼當QPS超過3000、超時或異常時服務即會迅速熔斷並關閉，從而確保其他資源的安全穩定。通過這種框架級、細粒度的自動降級機制，系統失敗隔離能力可被有效提高，避免了雪崩式的鏈式當機事件的發生。在熔斷的同時，自動擴容也會同步執行。熔斷之後系統會不斷更新服務流量荷載，一旦擴容完成或者服務還能繼續承受流量即可重新恢復工作，這種熔斷機制同樣也是為伺服器擴容爭取時間。