背景

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

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

本文希望可以提供兩點(diǎn)價(jià)值：

1 Feed流當(dāng)前的主流架構(gòu)以及落地方案
2 一個(gè)初創(chuàng)公司如何選擇Feed流的架構(gòu)演進(jìn)路徑

業(yè)務(wù)分析

Feed流參與者的價(jià)值

• 信息生產(chǎn)者

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

• 信息消費(fèi)者

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

• 平臺(tái)

希望吸引更多的生產(chǎn)者和消費(fèi)者（PV、UV），用戶更長(zhǎng)的停留時(shí)間，廣告、商品更高的轉(zhuǎn)化率

Feed信息傳遞方式

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

Feed流的技術(shù)難點(diǎn)

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

新浪微博為例，作為移動(dòng)社交時(shí)代的重量級(jí)社交分享平臺(tái)，2017年初日活躍用戶1.6億，月活躍用戶近3.3億，每天新增數(shù)億條數(shù)據(jù)，總數(shù)據(jù)量達(dá)千億級(jí)，核心單個(gè)業(yè)務(wù)的后端數(shù)據(jù)訪問QPS高達(dá)百萬(wàn)級(jí)

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

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

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

主流架構(gòu)

圖1是對(duì)Feed流的最簡(jiǎn)單抽象，完成一個(gè)從生產(chǎn)者向消費(fèi)者傳遞消息的過程。

圖1 Feed流簡(jiǎn)單抽象

消息和關(guān)系

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

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

消息本身應(yīng)該算是一種半結(jié)構(gòu)化數(shù)據(jù)（包含文字，圖片，短視頻，音頻，元數(shù)據(jù)等）。其讀寫吞吐量要求高，讀寫比例需要看具體場(chǎng)景。總的存儲(chǔ)空間大，需要很好的擴(kuò)展性來(lái)支撐業(yè)務(wù)增長(zhǎng)。消息可能會(huì)有多次更新，比如內(nèi)容修改，瀏覽數(shù)，點(diǎn)贊數(shù)，轉(zhuǎn)發(fā)數(shù)（成熟的系統(tǒng)會(huì)獨(dú)立一個(gè)counter模塊來(lái)服務(wù)這些元數(shù)據(jù)）以及標(biāo)記刪除。消息一般不會(huì)永久保存，可能要在1年或者3年后刪除。

綜上，個(gè)人推薦使用HBase存儲(chǔ)

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

具有非常好的寫入性能，特別對(duì)于Feed流場(chǎng)景可以利用批量寫接口單機(jī)（32核64GB）達(dá)到幾十萬(wàn)的寫入效率；

HBase具備非常平滑的水平擴(kuò)展能力，自動(dòng)進(jìn)行Sharding和Balance；

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

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

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

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

圖3 使用HBase存儲(chǔ)Feed流消息

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

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

消息傳遞

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

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

推模式實(shí)現(xiàn)相對(duì)簡(jiǎn)單，時(shí)效性也比較好。拉模式要想獲得好的性能需要多級(jí)的緩存架構(gòu)。推模式重寫，拉模式重讀，Feed流場(chǎng)景下寫的聚合效果要優(yōu)于讀，寫可以大批量聚合。N越大，寫入造成的數(shù)據(jù)冗余就越大。M越大，讀消耗的資源越大。

隨著業(yè)務(wù)的增長(zhǎng)，推模式資源浪費(fèi)會(huì)越發(fā)嚴(yán)重。原因在于兩點(diǎn)：第一存在著大量的僵尸賬號(hào)，以及大比例的非活躍用戶幾天或者半個(gè)月才登陸一次；第二信息過載，信息太多，重復(fù)信息太多，垃圾信息太多，用戶感覺有用的信息少，消息的閱讀比例低。這種情況下推模式相當(dāng)一部分在做無(wú)用功，白白浪費(fèi)系統(tǒng)資源。

是推？是拉？還是混合？沒有最好的架構(gòu)，只有適合的場(chǎng)景~

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

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

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

多級(jí)隊(duì)列。Dispatcher可以根據(jù)消費(fèi)者的狀態(tài)，信息的分類等劃分不同的處理方式，分配不同的資源。比如對(duì)于大V賬號(hào)的消息，當(dāng)前活躍用戶選擇直接發(fā)送，保障消息的時(shí)效性，非活躍用戶放入隊(duì)列延遲發(fā)送。比如轉(zhuǎn)發(fā)多的消息可以優(yōu)先處理等。隊(duì)列里的消息可以采用批量聚合寫的方式提高吞吐。

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

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

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

HBase單機(jī)批量寫能力在幾十萬(wàn)并且可以水平擴(kuò)展。

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

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

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

消費(fèi)者收信箱hbase表設(shè)計(jì)如下，其中序列號(hào)要保證遞增，一般用時(shí)間戳即可，特別高頻情況下可以用一個(gè)RDS來(lái)制造序列號(hào)

Rowkey消息元數(shù)據(jù)列狀態(tài)列其它列

MD5(用戶ID)+用戶ID+序列號(hào)	消息ID、作者、發(fā)布時(shí)間、關(guān)鍵字等	已讀、未讀	?

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

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

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

基于推薦的傳遞

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

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

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

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

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

用戶畫像使用HBase存儲(chǔ)

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

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

臨時(shí)收信箱使用云HBase

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

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

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

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

在業(yè)務(wù)發(fā)展的初期，用戶量和資源都沒有那么多，團(tuán)隊(duì)的人力投入也是有限的，不可能一上來(lái)就搞一個(gè)特別復(fù)雜的架構(gòu)，“夠用”就行了，重要的是

可以快速的交付

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

未來(lái)可以從容的迭代，避免推倒重來(lái)

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

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

消息分為主體和索引

采用純推的模式

采用異步化

圖9 起步架構(gòu)

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

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

控制存儲(chǔ)成本

提升讀寫性能

提升一定的Inbox搜索能力

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

消息分為主體和索引

采用純推的模式

采用異步化

采用多級(jí)隊(duì)列解決大V問題

采用冷熱分離降低存儲(chǔ)成本

此時(shí)Inbox中的消息也很多，對(duì)搜索的需求增強(qiáng)，僅僅Scan+Filter不夠，可能需要二級(jí)索引

圖10 純推模式的演進(jìn)

業(yè)務(wù)迅猛發(fā)展，消息和用戶增長(zhǎng)迅速，僵尸賬號(hào)、非活躍賬號(hào)較多，信息過載嚴(yán)重

消息分為主體和索引

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

采用異步化

引入推薦系統(tǒng)

采用冷熱分離降低存儲(chǔ)成本

Outbox采用多級(jí)緩存提高讀取性能

Inbox增加二級(jí)索引提升搜索能力

使用云Kafka+云HBase+云Redis

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

總結(jié)

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

原文鏈接
本文為云棲社區(qū)原創(chuàng)內(nèi)容，未經(jīng)允許不得轉(zhuǎn)載。

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。