背景

Feed流：可以理解為信息流，解決的是信息生產者與信息消費者之間的信息傳遞問題。
我們常見的Feed流場景有：
1 手淘，微淘提供給消費者的首頁商品信息，用戶關注店鋪的新消息等
2 微信朋友圈，及時獲取朋友分享的信息
3 微博，粉絲獲取關注明星、大V的信息
4 頭條，用戶獲取系統推薦的新聞、評論、八卦

關于Feed流的架構設計，包括以上場景中的很多業內專家給出了相應的思考、設計和實踐。本人是大數據方向出身的技術人，所在的團隊參與了阿里手淘、微淘Feed流的存儲層相關服務，我們的HBase/Lindorm數據存儲產品在公有云上也支持著Soul、趣頭條、惠頭條等一些受歡迎的新媒體、社交類產品。我們在數據存儲產品的功能、性能、可用性上的一些理解，希望對真實落地一個Feed流架構可以有一些幫助，以及一起探討Feed流的未來以及數據產品如何幫助Feed流進一步迭代。

本文希望可以提供兩點價值：

1 Feed流當前的主流架構以及落地方案
2 一個初創公司如何選擇Feed流的架構演進路徑

業務分析

Feed流參與者的價值

• 信息生產者

希望信息支持格式豐富（文字、圖片、視頻），發布流暢（生產信息的可用性），訂閱者及時收到消息（時效性），訂閱者不漏消息（傳遞的可靠性）

• 信息消費者

希望及時收到關注的消息（時效性），希望不錯過朋友、偶像的消息（傳遞的可靠性），希望獲得有價值的消息（解決信息過載）

• 平臺

希望吸引更多的生產者和消費者（PV、UV），用戶更長的停留時間，廣告、商品更高的轉化率

Feed信息傳遞方式

一種是基于關系的消息傳遞，關系通過加好友、關注、訂閱等方式建立，可能是雙向的也可能是單向的。一種是基于推薦算法的，系統根據用戶畫像、消息畫像利用標簽分類或者協同過濾等算法向用戶推送消息。微信和微博偏向于基于關系，頭條、抖音偏向于基于推薦。

Feed流的技術難點

互聯網場景總是需要一定規模才能體現出技術的瓶頸，下面我們先看兩組公開數據：

新浪微博為例，作為移動社交時代的重量級社交分享平臺，2017年初日活躍用戶1.6億，月活躍用戶近3.3億，每天新增數億條數據，總數據量達千億級，核心單個業務的后端數據訪問QPS高達百萬級

截止2016年12月底，頭條日活躍用戶7800W，月活躍用戶1.75億，單用戶平均使用時長76分鐘，用戶行為峰值150w+msg/s，每天訓練數據300T+（壓縮后），機器規模萬級別

上面還是兩大巨頭的歷史指標，假設一條消息1KB那么千億消息約93TB的數據量，日增量在幾百GB規模且QPS高達百萬，因此需要一個具備高讀寫吞吐，擴展性良好的分布式存儲系統。用戶瀏覽新消息期望百毫秒響應，希望新消息在秒級或者至少1分鐘左右可見，對系統的實時性要求很高，這里需要多級的緩存架構。系統必須具備高可用，良好的容錯性。最后這個系統最好不要太貴。

因此我們需要一個高吞吐、易擴展、低延遲、高可用、低成本的Feed流架構

主流架構

圖1是對Feed流的最簡單抽象，完成一個從生產者向消費者傳遞消息的過程。

圖1 Feed流簡單抽象

消息和關系

首先，用戶在APP側獲得的是一個Feed ID列表，這個列表不一定包含了所有的新消息，用戶也不一定每一個都打開瀏覽，如果傳遞整個消息非常浪費資源，因此產生出來的消息首先生成主體和索引兩個部分，其中索引包含了消息ID和元數據。其次一個應用總是存在關系，基于關系的傳遞是必不可少的，也因此一定有一個關系的存儲和查詢服務。

圖2 Feed流消息、關系的存儲

消息本身應該算是一種半結構化數據（包含文字，圖片，短視頻，音頻，元數據等）。其讀寫吞吐量要求高，讀寫比例需要看具體場景。總的存儲空間大，需要很好的擴展性來支撐業務增長。消息可能會有多次更新，比如內容修改，瀏覽數，點贊數，轉發數（成熟的系統會獨立一個counter模塊來服務這些元數據）以及標記刪除。消息一般不會永久保存，可能要在1年或者3年后刪除。

綜上，個人推薦使用HBase存儲

HBase支持結構化和半結構化數據；

具有非常好的寫入性能，特別對于Feed流場景可以利用批量寫接口單機（32核64GB）達到幾十萬的寫入效率；

HBase具備非常平滑的水平擴展能力，自動進行Sharding和Balance；

HBase內置的BlockCache加上SSD盤可以提供ms級的高并發讀；

HBase的TTL特性可以自動的淘汰過期數據；

利用數據復制搭建一個冷熱分離系統，新消息存儲在擁有SSD磁盤和大規格緩存的熱庫，舊數據存儲在冷庫。

運用編碼壓縮有效的控制存儲成本，見HBase優化之路-合理的使用編碼壓縮

圖3 使用HBase存儲Feed流消息

對于關系服務，其寫入操作是建立關系和刪除關系，讀取操作是獲取關系列表，邏輯上僅需要一個KV系統。如果數據量較少可以使用RDS，如果數據量較大推薦使用HBase。如果對關系的QPS壓力大可以考慮用Redis做緩存。

圖4 用戶關系存儲

消息傳遞

講到Feed流一定會有關于推模式和拉模式的討論，推模式是把消息復制N次發送到N個用戶的收信箱，用戶想看消息時從自己的收信箱直接獲取。拉模式相反，生產者的消息寫入自己的發信箱，用戶想看消息時從關注的M個發信箱中收集消息。

圖5 消息傳遞的推模式和拉模式

推模式實現相對簡單，時效性也比較好。拉模式要想獲得好的性能需要多級的緩存架構。推模式重寫，拉模式重讀，Feed流場景下寫的聚合效果要優于讀，寫可以大批量聚合。N越大，寫入造成的數據冗余就越大。M越大，讀消耗的資源越大。

隨著業務的增長，推模式資源浪費會越發嚴重。原因在于兩點：第一存在著大量的僵尸賬號，以及大比例的非活躍用戶幾天或者半個月才登陸一次；第二信息過載，信息太多，重復信息太多，垃圾信息太多，用戶感覺有用的信息少，消息的閱讀比例低。這種情況下推模式相當一部分在做無用功，白白浪費系統資源。

是推？是拉？還是混合？沒有最好的架構，只有適合的場景~

基于關系的傳遞

圖6是純推模式的架構，該架構有3個關鍵的部分

異步化。生產者提交消息首先寫入一個隊列，成功則表示發布成功，Dispatcher模塊會異步的處理消息。這一點非常關鍵，首先生產者的消息發布體驗非常好，不需要等待消息同步到粉絲的收信箱，發布延遲低成功率高；其次Dispatcher可以控制隊列的處理速度，可以有效的控制大V賬號造成的脈沖壓力。

多級隊列。Dispatcher可以根據消費者的狀態，信息的分類等劃分不同的處理方式，分配不同的資源。比如對于大V賬號的消息，當前活躍用戶選擇直接發送，保障消息的時效性，非活躍用戶放入隊列延遲發送。比如轉發多的消息可以優先處理等。隊列里的消息可以采用批量聚合寫的方式提高吞吐。

收信箱。假如有兩億用戶，每個用戶保留最新2000條推送消息。即便存儲的是索引也是千億的規模。收信箱一般的表結構為用戶ID+消息序列 + 消息ID + 消息元數據，消息序列是一個遞增的ID，需要存儲一個偏移量表示上次讀到的消息序列ID。用戶讀取最新消息 select * from inbox where 消息序列 > offset。

圖6 基于關系傳遞的純推模式

推薦使用HBase實現收信箱

HBase單機批量寫能力在幾十萬并且可以水平擴展。

HBase的高效前綴掃描非常適合讀取最新的消息。

HBase的TTL功能可以對數據定義生命周期，高效的淘汰過期數據。

HBase的Filter過濾器和二級索引可以有效的實現Inbox的搜索能力。

消費者收信箱hbase表設計如下，其中序列號要保證遞增，一般用時間戳即可，特別高頻情況下可以用一個RDS來制造序列號

Rowkey消息元數據列狀態列其它列

MD5(用戶ID)+用戶ID+序列號	消息ID、作者、發布時間、關鍵字等	已讀、未讀	?

圖7是推拉結合的模式

• 增加發信箱，大V的發布進入其獨立的發信箱。非大V的發布直接發送到用戶的收信箱。其好處是解決大量的僵尸賬號和非活躍賬號的問題。用戶只有在請求新消息的時候（比如登陸、下拉消息框）才會去消耗系統資源。
• 發信箱的多級緩存架構。一個大V可能有百萬粉絲，一條熱點消息的傳播窗口也會非常短，即短時間內會對發信箱中的同一條消息大量重復讀取，對系統挑戰很大。終態下我們可能會選擇兩級緩存，收信箱數據還是要持久化的，否則升級或者宕機時數據就丟失了，所以第一層是一個分布式數據存儲，這個存儲推薦使用HBase，原因和Inbox類似。第二層使用redis緩存加速，但是大V過大可能造成熱點問題還需要第三層本地緩存。緩存層的優化主要包括兩個方向：第一提高緩存命中率，常用的方式是對數據進行編碼壓縮，第二保障緩存的可用性，這里涉及到對緩存的冗余。

圖7 基于關系傳遞的推拉混合模式

基于推薦的傳遞

圖8是基于推薦的模型，可以看出它是在推拉結合的模式上融合了推薦系統。

引入畫像系統，保存用戶畫像、消息畫像（簡單情況下消息畫像可以放在消息元數據中）。畫像用于推薦系統算法的輸入。

引入了臨時收信箱，在信息過載的場景中，非大V的消息也是總量很大，其中不免充斥著垃圾、冗余消息，所以直接進入用戶收信箱不太合適。

收信箱和發信箱都需要有良好的搜索能力，這是推薦系統高效運行的關鍵。Outbox有緩存層，索引可以做到緩存里面；Inbox一般情況下二級索引可以滿足大部分需求，但如果用戶希望有全文索引或者任意維度的檢索能力，還需要引入搜索系統如Solr/ES

圖8 基于推薦的Feed流架構

用戶畫像使用HBase存儲

畫像一般是稀疏表，畫像總維度可能在200+甚至更多，但單個用戶的維度可能在幾十，并且維度可能隨業務不斷變化。那么HBase的Schema free和稀疏表的能力非常適合這個場景，易用且節省大量存儲空間。

對畫像的訪問一般是單行讀，hbase本身單行Get的性能就非常好。阿里云HBase在這個方向上做了非常多的優化，包括CCSMAP、SharedBucketCache、MemstoreBloomFilter、Index Encoding等，可以達到平均RT=1-2ms，單庫99.9% <100ms。阿里內部利用雙集群Dual Service可以做到 99.9% < 30ms，這一能力我們也在努力推到公有云。hbase的讀吞吐隨機器數量水平擴展。

臨時收信箱使用云HBase

HBase的讀寫高吞吐、低延遲能力，這里不再重復。

HBase提供Filter和全局二級索引，滿足不同量級的搜索需求。

阿里云HBase融合HBase與Solr能力，提供低成本的全文索引、多維索引能力。

初創公司的迭代路徑

在業務發展的初期，用戶量和資源都沒有那么多，團隊的人力投入也是有限的，不可能一上來就搞一個特別復雜的架構，“夠用”就行了，重要的是

可以快速的交付

系統要穩定

未來可以從容的迭代，避免推倒重來

本人水平有限，根據自身的經驗向大家推薦一種迭代路徑以供參考，如有不同意見歡迎交流

起步架構如圖9，使用云Kafka+云HBase。如果對Inbox有檢索需求，建議使用HBase的scan+filter即可。

消息分為主體和索引

采用純推的模式

采用異步化

圖9 起步架構

數據量逐漸增大后，對推模式進一步迭代，主要需求是

控制大V造成的寫入脈沖高峰

控制存儲成本

提升讀寫性能

提升一定的Inbox搜索能力

進一步的迭代架構如圖10

消息分為主體和索引

采用純推的模式

采用異步化

采用多級隊列解決大V問題

采用冷熱分離降低存儲成本

此時Inbox中的消息也很多，對搜索的需求增強，僅僅Scan+Filter不夠，可能需要二級索引

圖10 純推模式的演進

業務迅猛發展，消息和用戶增長迅速，僵尸賬號、非活躍賬號較多，信息過載嚴重

消息分為主體和索引

采用推拉結合模式

采用異步化

引入推薦系統

采用冷熱分離降低存儲成本

Outbox采用多級緩存提高讀取性能

Inbox增加二級索引提升搜索能力

使用云Kafka+云HBase+云Redis

圖11 基于推薦的推拉混合架構

總結

Feed信息流是互聯網場景中非常普遍的場景，遍布于電商、社交、新媒體等APP，因此研究Feed流是非常有價值的一件事情。本文總結了Feed流的業務場景和主流架構，分析了不同場景、體量下技術的難點與瓶頸。對Dispatcher、Inbox、Outout幾個組件進行了詳細的演進介紹，提供了基于云環境的落地方案。本人水平有限，希望可以拋磚引玉，歡迎大家一起探討。Feed流的架構演進還在持續，不同業務場景下還有哪些缺陷和痛點？數據產品如何從功能和性能上演進來支撐Feed流的持續發展？在這些問題的驅動下，云HBase未來將會大力投入到Feed流場景的持續優化和賦能！

原文鏈接
本文為云棲社區原創內容，未經允許不得轉載。

總結

以上是生活随笔為你收集整理的数据人看Feed流-架构实践的全部內容，希望文章能夠幫你解決所遇到的問題。

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