背景

Feed流：可以理解為信息流叭莫，解決的是信息生產(chǎn)者與信息消費者之間的信息傳遞問題训貌。

我們常見的Feed流場景有：

1 手淘璃吧，微淘提供給消費者的首頁商品信息漓骚，用戶關(guān)注店鋪的新消息等

2 微信朋友圈，及時獲取朋友分享的信息

3 微博闰歪，粉絲獲取關(guān)注明星嚎研、大V的信息

4 頭條，用戶獲取系統(tǒng)推薦的新聞库倘、評論嘉赎、八卦

關(guān)于Feed流的架構(gòu)設(shè)計，包括以上場景中的很多業(yè)內(nèi)專家給出了相應的思考于樟、設(shè)計和實踐公条。本人是大數(shù)據(jù)方向出身的技術(shù)人，所在的團隊參與了阿里手淘迂曲、微淘Feed流的存儲層相關(guān)服務靶橱，我們的HBase/Lindorm數(shù)據(jù)存儲產(chǎn)品在公有云上也支持著Soul、趣頭條路捧、惠頭條等一些受歡迎的新媒體关霸、社交類產(chǎn)品。我們在數(shù)據(jù)存儲產(chǎn)品的功能杰扫、性能队寇、可用性上的一些理解，希望對真實落地一個Feed流架構(gòu)可以有一些幫助章姓，以及一起探討Feed流的未來以及數(shù)據(jù)產(chǎn)品如何幫助Feed流進一步迭代佳遣。

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

1 Feed流當前的主流架構(gòu)以及落地方案

2 一個初創(chuàng)公司如何選擇Feed流的架構(gòu)演進路徑

業(yè)務分析

Feed流參與者的價值

信息生產(chǎn)者

希望信息支持格式豐富（文字、圖片凡伊、視頻）零渐，發(fā)布流暢（生產(chǎn)信息的可用性），訂閱者及時收到消息（時效性）系忙，訂閱者不漏消息（傳遞的可靠性）

信息消費者

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

平臺

希望吸引更多的生產(chǎn)者和消費者（PV风宁、UV）洁墙，用戶更長的停留時間，廣告戒财、商品更高的轉(zhuǎn)化率

Feed信息傳遞方式

一種是基于關(guān)系的消息傳遞热监，關(guān)系通過加好友、關(guān)注固翰、訂閱等方式建立狼纬，可能是雙向的也可能是單向的羹呵。一種是基于推薦算法的骂际，系統(tǒng)根據(jù)用戶畫像、消息畫像利用標簽分類或者協(xié)同過濾等算法向用戶推送消息冈欢。微信和微博偏向于基于關(guān)系歉铝，頭條、抖音偏向于基于推薦凑耻。

Feed流的技術(shù)難點

互聯(lián)網(wǎng)場景總是需要一定規(guī)模才能體現(xiàn)出技術(shù)的瓶頸太示，下面我們先看兩組公開數(shù)據(jù)：

新浪微博為例，作為移動社交時代的重量級社交分享平臺香浩，2017年初日活躍用戶1.6億类缤，月活躍用戶近3.3億，每天新增數(shù)億條數(shù)據(jù)邻吭，總數(shù)據(jù)量達千億級餐弱，核心單個業(yè)務的后端數(shù)據(jù)訪問QPS高達百萬級

（來自 Feed系統(tǒng)架構(gòu)與Feed緩存模型）

截止2016年12月底，頭條日活躍用戶7800W囱晴，月活躍用戶1.75億膏蚓，單用戶平均使用時長76分鐘，用戶行為峰值150w+msg/s畸写，每天訓練數(shù)據(jù)300T+（壓縮后）驮瞧，機器規(guī)模萬級別

（來自 今日頭條推薦系統(tǒng)架構(gòu)設(shè)計實踐）

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

因此我們需要一個高吞吐皂林、易擴展、低延遲蚯撩、高可用础倍、低成本的Feed流架構(gòu)

主流架構(gòu)

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

圖1 Feed流簡單抽象

消息和關(guān)系

首先沟启，用戶在APP側(cè)獲得的是一個Feed ID列表，這個列表不一定包含了所有的新消息犹菇，用戶也不一定每一個都打開瀏覽德迹，如果傳遞整個消息非常浪費資源，因此產(chǎn)生出來的消息首先生成主體和索引兩個部分揭芍，其中索引包含了消息ID和元數(shù)據(jù)胳搞。其次一個應用總是存在關(guān)系，基于關(guān)系的傳遞是必不可少的称杨，也因此一定有一個關(guān)系的存儲和查詢服務肌毅。

圖2 Feed流消息、關(guān)系的存儲

消息本身應該算是一種半結(jié)構(gòu)化數(shù)據(jù)（包含文字姑原，圖片悬而，短視頻，音頻锭汛，元數(shù)據(jù)等）笨奠。其讀寫吞吐量要求高，讀寫比例需要看具體場景店乐〖杼桑總的存儲空間大，需要很好的擴展性來支撐業(yè)務增長眨八。消息可能會有多次更新腺兴，比如內(nèi)容修改，瀏覽數(shù)廉侧，點贊數(shù)页响，轉(zhuǎn)發(fā)數(shù)（成熟的系統(tǒng)會獨立一個counter模塊來服務這些元數(shù)據(jù)）以及標記刪除。消息一般不會永久保存段誊，可能要在1年或者3年后刪除闰蚕。

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

HBase支持結(jié)構(gòu)化和半結(jié)構(gòu)化數(shù)據(jù)连舍；

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

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

HBase內(nèi)置的BlockCache加上SSD盤可以提供ms級的高并發(fā)讀贴彼；

HBase的TTL特性可以自動的淘汰過期數(shù)據(jù)；

利用數(shù)據(jù)復制搭建一個冷熱分離系統(tǒng)埃儿，新消息存儲在擁有SSD磁盤和大規(guī)格緩存的熱庫器仗，舊數(shù)據(jù)存儲在冷庫。

運用編碼壓縮有效的控制存儲成本童番，見HBase優(yōu)化之路-合理的使用編碼壓縮

圖3 使用HBase存儲Feed流消息

對于關(guān)系服務精钮，其寫入操作是建立關(guān)系和刪除關(guān)系，讀取操作是獲取關(guān)系列表剃斧，邏輯上僅需要一個KV系統(tǒng)轨香。如果數(shù)據(jù)量較少可以使用RDS，如果數(shù)據(jù)量較大推薦使用HBase悯衬。如果對關(guān)系的QPS壓力大可以考慮用Redis做緩存弹沽。

圖4 用戶關(guān)系存儲

消息傳遞

講到Feed流一定會有關(guān)于推模式和拉模式的討論檀夹，推模式是把消息復制N次發(fā)送到N個用戶的收信箱筋粗，用戶想看消息時從自己的收信箱直接獲取。拉模式相反炸渡，生產(chǎn)者的消息寫入自己的發(fā)信箱娜亿，用戶想看消息時從關(guān)注的M個發(fā)信箱中收集消息。

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

推模式實現(xiàn)相對簡單蚌堵，時效性也比較好买决。拉模式要想獲得好的性能需要多級的緩存架構(gòu)。推模式重寫吼畏，拉模式重讀督赤，F(xiàn)eed流場景下寫的聚合效果要優(yōu)于讀，寫可以大批量聚合泻蚊。N越大躲舌，寫入造成的數(shù)據(jù)冗余就越大。M越大性雄，讀消耗的資源越大没卸。

隨著業(yè)務的增長，推模式資源浪費會越發(fā)嚴重秒旋。原因在于兩點：第一存在著大量的僵尸賬號约计，以及大比例的非活躍用戶幾天或者半個月才登陸一次；第二信息過載迁筛，信息太多煤蚌，重復信息太多，垃圾信息太多，用戶感覺有用的信息少尉桩，消息的閱讀比例低俗孝。這種情況下推模式相當一部分在做無用功，白白浪費系統(tǒng)資源魄健。

是推赋铝？是拉？還是混合沽瘦？沒有最好的架構(gòu)革骨，只有適合的場景~

基于關(guān)系的傳遞

圖6是純推模式的架構(gòu)，該架構(gòu)有3個關(guān)鍵的部分

異步化析恋。生產(chǎn)者提交消息首先寫入一個隊列良哲，成功則表示發(fā)布成功，Dispatcher模塊會異步的處理消息助隧。這一點非常關(guān)鍵筑凫，首先生產(chǎn)者的消息發(fā)布體驗非常好，不需要等待消息同步到粉絲的收信箱并村，發(fā)布延遲低成功率高巍实；其次Dispatcher可以控制隊列的處理速度，可以有效的控制大V賬號造成的脈沖壓力哩牍。

多級隊列棚潦。Dispatcher可以根據(jù)消費者的狀態(tài)，信息的分類等劃分不同的處理方式膝昆，分配不同的資源丸边。比如對于大V賬號的消息，當前活躍用戶選擇直接發(fā)送荚孵，保障消息的時效性妹窖，非活躍用戶放入隊列延遲發(fā)送。比如轉(zhuǎn)發(fā)多的消息可以優(yōu)先處理等收叶。隊列里的消息可以采用批量聚合寫的方式提高吞吐骄呼。

收信箱。假如有兩億用戶滔驾，每個用戶保留最新2000條推送消息谒麦。即便存儲的是索引也是千億的規(guī)模。收信箱一般的表結(jié)構(gòu)為用戶ID+消息序列 + 消息ID + 消息元數(shù)據(jù)哆致，消息序列是一個遞增的ID绕德，需要存儲一個偏移量表示上次讀到的消息序列ID。用戶讀取最新消息 select * from inbox where 消息序列 > offset摊阀。

圖6 基于關(guān)系傳遞的純推模式

推薦使用HBase實現(xiàn)收信箱

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

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

HBase的TTL功能可以對數(shù)據(jù)定義生命周期，高效的淘汰過期數(shù)據(jù)臣咖。

HBase的Filter過濾器和二級索引可以有效的實現(xiàn)Inbox的搜索能力跃捣。

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

Rowkey消息元數(shù)據(jù)列狀態(tài)列其它列MD5(用戶ID)+用戶ID+序列號消息ID、作者刁赦、發(fā)布時間娶聘、關(guān)鍵字等已讀、未讀

圖7是推拉結(jié)合的模式

增加發(fā)信箱甚脉，大V的發(fā)布進入其獨立的發(fā)信箱丸升。非大V的發(fā)布直接發(fā)送到用戶的收信箱。其好處是解決大量的僵尸賬號和非活躍賬號的問題牺氨。用戶只有在請求新消息的時候（比如登陸狡耻、下拉消息框）才會去消耗系統(tǒng)資源。

發(fā)信箱的多級緩存架構(gòu)猴凹。一個大V可能有百萬粉絲夷狰，一條熱點消息的傳播窗口也會非常短，即短時間內(nèi)會對發(fā)信箱中的同一條消息大量重復讀取精堕，對系統(tǒng)挑戰(zhàn)很大孵淘。終態(tài)下我們可能會選擇兩級緩存蒲障，收信箱數(shù)據(jù)還是要持久化的歹篓，否則升級或者宕機時數(shù)據(jù)就丟失了，所以第一層是一個分布式數(shù)據(jù)存儲揉阎，這個存儲推薦使用HBase庄撮，原因和Inbox類似。第二層使用redis緩存加速毙籽，但是大V過大可能造成熱點問題還需要第三層本地緩存洞斯。緩存層的優(yōu)化主要包括兩個方向：第一提高緩存命中率，常用的方式是對數(shù)據(jù)進行編碼壓縮坑赡，第二保障緩存的可用性烙如，這里涉及到對緩存的冗余。

圖7 基于關(guān)系傳遞的推拉混合模式

基于推薦的傳遞

圖8是基于推薦的模型毅否，可以看出它是在推拉結(jié)合的模式上融合了推薦系統(tǒng)亚铁。

引入畫像系統(tǒng)，保存用戶畫像螟加、消息畫像（簡單情況下消息畫像可以放在消息元數(shù)據(jù)中）徘溢。畫像用于推薦系統(tǒng)算法的輸入吞琐。

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

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

圖8 基于推薦的Feed流架構(gòu)

用戶畫像使用HBase存儲

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

對畫像的訪問一般是單行讀，hbase本身單行Get的性能就非常好柬唯。阿里云HBase在這個方向上做了非常多的優(yōu)化认臊，包括CCSMAP、SharedBucketCache锄奢、MemstoreBloomFilter失晴、Index Encoding等，可以達到平均RT=1-2ms拘央，單庫99.9% <100ms涂屁。阿里內(nèi)部利用雙集群Dual Service可以做到 99.9% < 30ms，這一能力我們也在努力推到公有云灰伟。hbase的讀吞吐隨機器數(shù)量水平擴展拆又。

臨時收信箱使用云HBase

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

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

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

初創(chuàng)公司的迭代路徑

在業(yè)務發(fā)展的初期捻激，用戶量和資源都沒有那么多制轰，團隊的人力投入也是有限的，不可能一上來就搞一個特別復雜的架構(gòu)胞谭，“夠用”就行了垃杖，重要的是

可以快速的交付

系統(tǒng)要穩(wěn)定

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

本人水平有限丈屹，根據(jù)自身的經(jīng)驗向大家推薦一種迭代路徑以供參考调俘，如有不同意見歡迎交流

起步架構(gòu)如圖9，使用云Kafka+云HBase旺垒。如果對Inbox有檢索需求彩库，建議使用HBase的scan+filter即可。

消息分為主體和索引

采用純推的模式

采用異步化

圖9 起步架構(gòu)

數(shù)據(jù)量逐漸增大后先蒋，對推模式進一步迭代骇钦，主要需求是

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

控制存儲成本

提升讀寫性能

提升一定的Inbox搜索能力

進一步的迭代架構(gòu)如圖10

消息分為主體和索引

采用純推的模式

采用異步化

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

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

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

圖10 純推模式的演進

業(yè)務迅猛發(fā)展，消息和用戶增長迅速业岁，僵尸賬號鳞仙、非活躍賬號較多，信息過載嚴重

消息分為主體和索引

采用推拉結(jié)合模式

采用異步化

引入推薦系統(tǒng)

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

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

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

使用云Kafka+云HBase+云Redis

圖11 基于推薦的推拉混合架構(gòu)

總結(jié)

Feed信息流是互聯(lián)網(wǎng)場景中非常普遍的場景笔时，遍布于電商棍好、社交、新媒體等APP允耿，因此研究Feed流是非常有價值的一件事情借笙。本文總結(jié)了Feed流的業(yè)務場景和主流架構(gòu)，分析了不同場景右犹、體量下技術(shù)的難點與瓶頸提澎。對Dispatcher、Inbox念链、Outout幾個組件進行了詳細的演進介紹，提供了基于云環(huán)境的落地方案积糯。本人水平有限掂墓，希望可以拋磚引玉，歡迎大家一起探討看成。Feed流的架構(gòu)演進還在持續(xù)君编，不同業(yè)務場景下還有哪些缺陷和痛點？數(shù)據(jù)產(chǎn)品如何從功能和性能上演進來支撐Feed流的持續(xù)發(fā)展川慌？在這些問題的驅(qū)動下吃嘿，云HBase未來將會大力投入到Feed流場景的持續(xù)優(yōu)化和賦能祠乃！