本文來自新浪微博視頻平臺資深架構師劉志勇在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、超時或異常時服務即會迅速熔斷并關閉，從而確保其他資源的安全穩定。通過這種框架級、細粒度的自動降級機制，系統失敗隔離能力可被有效提高，避免了雪崩式的鏈式宕機事件的發生。在熔斷的同時，自動擴容也會同步運行。熔斷之后系統會不斷更新服務流量荷載，一旦擴容完成或者服務還能繼續承受流量即可重新恢復工作，這種熔斷機制同樣也是為服務器擴容爭取時間。

總結

以上是生活随笔為你收集整理的刘志勇：微博短视频百万级高并发架构的全部內容，希望文章能夠幫你解決所遇到的問題。

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