如何打造千萬級Feed流系統

時間 2019-11-21

標籤如何打造千萬 feed 系統简体版

原文原文鏈接

摘要：Feed流是一個目前很是常見的功能，在衆多產品中都有展示，經過Feed流能夠把動態實時的傳播給訂閱者，是用戶獲取信息流的一種有效方式。在大數據時代，如何打造一個千萬級規模的Feed流系統仍然是一個挑戰。數據庫

在互聯網領域，尤爲如今的移動互聯網時代，Feed流產品是很是常見的，好比咱們天天都會用到的朋友圈，微博，就是一種很是典型的Feed流產品，還有圖片分享網站Pinterest，花瓣網等又是另外一種形式的Feed流產品。除此以外，不少App的都會有一個模塊，要麼叫動態，要麼叫消息廣場，這些也是Feed流產品，能夠說，Feed流產品是遍及天下全部的App中。性能優化

概念

咱們在講如何設計Feed流系統以前，先來看一下Feed流中的一些概念：微信

Feed：Feed流中的每一條狀態或者消息都是Feed，好比朋友圈中的一個狀態就是一個Feed，微博中的一條微博就是一個Feed。網絡

Feed流：持續更新並呈現給用戶內容的信息流。每一個人的朋友圈，微博關注頁等等都是一個Feed流。架構

Timeline：Timeline實際上是一種Feed流的類型，微博，朋友圈都是Timeline類型的Feed流，可是因爲Timeline類型出現最先，使用最普遍，最爲人熟知，有時候也用Timeline來表示Feed流。併發

關注頁Timeline：展現其餘人Feed消息的頁面，好比朋友圈，微博的首頁等。運維

我的頁Timeline：展現本身發送過的Feed消息的頁面，好比微信中的相冊，微博的我的頁等。異步

特徵

Feed流系統有一些很是典型的特色，好比：分佈式

多帳號內容流：Feed流系統中確定會存在成千上萬的帳號，帳號之間能夠關注，取關，加好友和拉黑等操做。只要知足這一條，那麼就能夠當作Feed流系統來設計。性能

非穩定的帳號關係：因爲存在關注，取關等操做，因此係統中的用戶之間的關係就會一直在變化，是一種非穩定的狀態。

讀寫比例100:1：讀寫嚴重不平衡，讀多寫少，通常讀寫比例在10：1，甚至100：1以上。

消息必達性要求高：好比發送了一條朋友圈後，結果部分朋友看到了，部分朋友沒看到，若是恰恰女友沒看到，那麼可能會產生很嚴重的感情矛盾，後果很嚴重。

上面的就是Feed流產品的一些特色，下面咱們來看一下Feed流系統的分類。

分類

Feed流的分類有不少種，但最多見的分類有兩種：

Timeline：按發佈的時間順序排序，先發布的先看到，後發佈的排列在最頂端，相似於微信朋友圈，微博等。這也是一種最多見的形式。產品若是選擇Timeline類型，那麼就是認爲Feed流中的Feed很少，可是每一個Feed都很重要，都須要用戶看到。

Rank：按某個非時間的因子排序，通常是按照用戶的喜愛度排序，用戶最喜歡的排在最前面，次喜歡的排在後面。這種通常假定用戶可能看到的Feed很是多，而用戶花費在這裏的時間有限，那麼就爲用戶選擇出用戶最想看的Top N結果，場景的應用場景有圖片分享、新聞推薦類、商品推薦等。

上面兩種是最典型，也是最多見的分類方式，另外的話，也有其餘的分類標準，在其餘的分類標準中的話，會多出兩種類型：

Aggregate：聚合類型，好比好幾個朋友都看了同一場電影，這個就能夠聚合爲一條Feed：A，B，C看了電影《你的名字》，這種聚合功能比較適合在客戶端作。通常的Aggregate類型是Timeline類型 + 客戶端聚合。

Notice：通知類型，這種其實已是功能類型了，通知類型通常用於APP中的各類通知，私信等常見。這種也是Timeline類型，或者是Aggregate類型。

實現

上面介紹了Feed流系統的概念，特徵以及分類，接下來開始進入關鍵部分：如何實現一個千萬級Feed流系統。因爲系統中的全部用戶不可能所有在線，且不可能同時刷新和發佈Feed，那麼一個能支撐千萬量級Feed流的系統，其實在產品上能夠支撐上億的用戶。

若是要設計一個Feed流系統，最關鍵的兩個核心，一個是存儲，一個是推送。

存儲

咱們先來看存儲，Feed流系統中須要存儲的內容分爲兩部分，一個是帳號關係（好比關注列表），一種是Feed消息內容。無論是存儲哪種，都有幾個問題須要考慮：

如何能支持100TB，甚至PB級數據量？

數據量大了後成本就很關鍵，成本如何能更便宜？

如何保證帳號關係和Feed不丟失？

咱們後面再解答這三個問題，先繼續看推送

推送

推送系統須要的功能有兩個，一個是發佈Feed，一個是讀取Feed流。對於提送系統，仍然有一些問題須要在選型以前考慮：

如何才能提供千萬的TPS和QPS？

如何保證讀寫延遲在10ms，甚至2ms如下？

如何保證Feed的必達性？

再解答這些問題以前，咱們先來大概瞭解下阿里雲的表格存儲TableStore。

TableStore

表格存儲(TableStore)是阿里雲自主研發的專業級分佈式NoSQL數據庫，是基於共享存儲的高性能、低成本、易擴展、全託管的半結構化數據存儲平臺，

支撐互聯網和物聯網數據的高效計算與分析。

目前無論是阿里巴巴集團內部，仍是外部公有云用戶，都有成千上萬的系統在使用。覆蓋了重吞吐的離線應用，以及重穩定性，性能敏感的在線應用。目前使用的系統中，有些系統每秒寫入行數超過3500萬行，每秒流量超過5GB，單表總行數超過10萬億行，單表數據量超過10PB。

表格存儲的具體的特性能夠看下面這張圖片。

這裏就不詳細介紹表格存儲(TableStore)的功能和特性了，有興趣的話能夠到官網頁面和雲棲博客瞭解，地址以下：

表格存儲的官網地址：www.aliyun.com/product/ots…

表格存儲雲棲博客：yq.aliyun.com/teams/4/typ…

表格存儲釘釘交流羣：11789671

存儲系統選擇

咱們接下來解決以前提出來的問題。

Feed流系統中須要存儲的系統有兩類，一類是帳號關係（好比關注列表），一類是Feed消息。

存儲帳號關係

咱們先來看帳號關係（好比關注列表）的存儲，對於帳號關係，它有一些特色：

是一系列的變長鏈表，長度可達億級別。

這樣就會致使數據量比較大，可是關係極其簡單。

還有一點是性能敏感，直接影響關注，取關的響應速度。

最適合存帳號關係（關注列表）的系統應該是分佈式NoSQL數據庫，緣由是數據量極大，關係簡單不須要複雜的join，性能要求高。

對內設計實現簡單，對外用戶體驗好。

除了上面這些特色外，還有一個特色：

有序性：有序性並不要求具備排序功能，只須要能按照主鍵排序就行，只要能按照主鍵排序，那麼關注列表和粉絲列表的順序就是固定的，可預期的。

使用開源HBase存儲帳號關係

能知足有序性的分佈式NoSQL數據庫中，開源HBase就是一個，因此不少企業會選擇開源HBase來存儲帳號關係，或者是關注列表。

這樣雖然知足了上述四個特徵，能夠把系統搭建起來，可是會有一些麻煩的問題：

須要本身運維，調查問題，Fix bug，會帶來較大的複雜度和成本開支。

GC會致使比較大的毛刺，影響用戶體驗，

使用表格存儲(TableStore)存儲帳號關係

除此以外，阿里雲的表格存儲也屬於有序性的分佈式NoSQL數據庫，以前有很多頗有名的系統選擇使用表格存儲，在下面一些地方給系統帶來了收益：

單表支持10萬億行+，10PB+的數據量，再快的數據增加速度都不用擔憂。

數據按主鍵列排序，保證有序性和可預期性。

單key讀寫延遲在毫秒級別，保證關注，取關的響應時間。

是全託管的分佈式NoSQL數據庫服務，無需任何運維。

所有采用C++實現，完全無GC問題，也就不會因爲GC而致使較大的毛刺。

使用表格存儲(TableStore)來存儲帳號關係會是一個比較好的選擇。

接下來看一下Feed消息的存儲。

存儲Feed消息

Feed消息有一個最大的特色：

數據量大，並且在Feed流系統裏面不少時候都會選擇寫擴散（推模式）模式，這時候數據量會再膨脹幾個數量級，因此這裏的數據量很容易達到100TB，甚至PB級別。

除此以外，還有一些其餘特色：

數據格式簡單

數據不能丟失，可靠性要求高

自增主鍵功能，保證我的發的Feed的消息ID在我的發件箱中都是嚴格遞增的，這樣讀取時只須要一個範圍讀取便可。因爲我的發佈的Feed併發度很低，這裏用時間戳也能知足基本需求，可是當應用層隊列堵塞，網絡延遲變大或時間回退時，用時間戳仍是沒法保證嚴格遞增。這裏最好是有自增功能。

成本越低越好

潛在的存儲系統

根據上述這些特徵，最佳的系統應該是具備主鍵自增功能的分佈式NoSQL數據庫，可是在開源系統裏面沒有，因此經常使用的作法有兩種：

關係型數據庫 + 分庫分表

關係型數據庫 + 分佈式NoSQL數據庫：其中關係型數據庫提供主鍵自增功能。

使用關係型數據庫存儲Feed消息

目前業界有不少用戶選擇了關係係數據庫+ 分庫分表，包括了一些很是著名的Feed流產品，雖然這個架構能夠運行起來，可是存在一些問題。

分庫分錶帶來了運維複雜性。

分庫分錶帶來了邏輯層和數據層的極大耦合性。

關係型數據庫，好比開源MySQL數據庫的主鍵自增功能性能差。無論是用MyISAM，仍是InnoDB引擎，要保證自增ID嚴格遞增，必須使用表鎖，這個粒度很是大，會嚴重限制併發度，影響性能。

有些用戶以爲關係型數據庫的可靠性高一些，可是關係型數據庫的可靠性通常也就最多6個9，這個可靠性和分佈式數據庫徹底不在一個層級，要低4到5個級別。

使用TableStore存儲帳號關係

基於上述緣由，一些技術公司開始考慮使用表格存儲(TableStore)，表格存儲是一個具備自增主鍵功能的分佈式NoSQL數據庫，這樣就只須要使用一種系統，除此以外還有如下的考慮：

單表可達10PB，10萬億行。

10個9的SLA保障Feed內容不丟失。

自然分佈式數據庫，無需分庫分表

兩種實例類型：高性能實例採用全SSD存儲媒介，提供極佳的讀寫性能。混合存儲實例採用SSD+SATA存儲媒介，提供極低的存儲成本。

主鍵自增功能性能極佳，其餘全部系統在作自增功能的時候都須要加鎖，可是表格存儲的主鍵自增功能在寫入自增列行的時候，徹底不須要鎖，既不須要表鎖，也不須要行鎖。

從上面看，使用TableStore的話，無論是在功能，性能，擴展性仍是成本方面都要更加適合一些。

看完推送系統選擇後，咱們再來看看推送方案的選擇。

推送方案

咱們先來回顧下以前說的Feed流系統最大的特色：

讀寫嚴重不平衡，讀多寫少，通常讀寫比例都在10；1，甚至100：1之上。

除此以外，還有一個方面會被推送方案影響：

發佈，刷新Feed時的延時本質上由推送方案決定，其餘的任何操做都只能是優化，質量量變，沒法質變。

推模式和拉模式對比

在推送方案裏面的，有兩種方案，分別是：

拉方案：也稱爲讀擴散。

推方案：也成爲寫擴散。

對於拉方案和推方案，他們在不少方面徹底相反，在看對比以前有一點要強調下：

對Feed流產品的用戶而言，刷新Feed流（讀取）時候的延遲敏感度要遠遠大於發佈（寫入）的時候。

推模式的一個反作用

在上面的對比中能夠明顯看出來，推模式要遠遠比拉模式更好一些，可是也有一個反作用：

數據會極大膨脹。

針對這個缺點，能夠從兩個方面考慮：

目前的存儲價格很低很低了，就以表格存儲爲例，容量型實例存儲10TB的數據量，在如今（2017年10月）每一年費用是1萬六千元，之後價格會隨着硬件技術升級，軟件性能優化等繼續下降。還有數據量越大價格越便宜。

想省點錢，那繼續能夠優化：

對大V採用拉模式，普通用戶使用推模式，這種模式有個缺點，後面會有分析。

對活躍粉絲採用推模式，非活躍粉絲採用拉模式（這種方式能夠較好的避免大流量對平臺的衝擊）

適用場景

經過上述兩個方案的對比後，總結下各個方案的適用場景：

拉模式：

不少Feed流產品的初版會採用這種方案，但很快就會拋棄。

另外，拉模式 + 圖計算就會是另外一番天地，可是這個時候重心就是圖計算了。

推模式：

Feed流系統中最經常使用、有效的模式；

用戶關係數比較均勻，或者有上限，好比朋友圈；

偏推薦類，同一個Feed對不一樣用戶價值不一樣，須要爲不一樣用戶計算分數，好比pinterest。

推拉結合

大部分用戶的帳號關係都是幾百個，可是有個別用戶是1000萬以上，好比微博。

上面瞭解了推送方案，接下來看下推送系統選擇

推送系統

若是要實現一個千萬量級的Feed流產品，那麼推送系統須要具有一些特色：

具有千萬TPS/QPS的能力。

讀寫鏈路延遲敏感，讀寫直接會影響用戶發佈，刷新Feed流時的延遲，尤爲是極其敏感的刷新時的延遲。

Feed消息的必達性要求很高。

主鍵自增功能，仍然是保證用戶收件箱中的Feed ID是嚴格遞增的，保證能夠經過Scan(上次讀取的最大ID --->MAX)讀取到最新未讀消息。

最好能爲用戶存儲Timeline中全部的Feed。

從上述特色來看，須要的推送系統最好是一個性能極佳，又可靠的有自增功能的NoSQL系統，因此，業內通常若是選擇開源系統的話，會在選擇了關係型數據庫做爲存儲系統的基礎上，選擇開源Redis，這樣就能覆蓋上述的幾個特徵，也能保證Feed流系統正常運行起來，可是也會帶來一些其餘問題：

純內存系統，內存價格極高，總體成本就比較高了。

屬於單機系統，爲了支持千萬TPS和保證消息必達性，須要使用cluster和replica模式，結果就是不只帶來了運維的複雜性，並且帶來了成本的機器增長，成本再次上升。

成本上升了之後，就有架構師開始考慮是否能夠節省一些成本，要節省成本只能是減小開源Redis裏面存儲的數據量，通常有兩種作法，這兩種作法都能減小存入Redis中的數據量：

只在開源Redis中存儲Feed ID，不存儲Feed內容。總體數據量會大量減小，可是在讀取的時候須要先讀Feed ID，而後在到存儲系統裏面去讀取Feed內容，網絡開銷增加了一倍，並且是串行的，對用戶的刷新延遲有較大影響。

只對普通用戶或者活躍用戶使用推模式，對大V和非活躍用戶直接使用拉模式。

上述兩個方案雖然能夠節省成本，可是是以犧牲用戶體驗爲代價的，最終須要在成本和用戶體驗之間權衡。

使用TableStore做爲推送系統

除了使用開源系統外，還可使用阿里雲的表格存儲（TahleStore），有很多用戶選擇TableStore做爲推送系統的緣由無非下面幾點：

自然分佈式，單表可支持千萬級TPS/QPS。

LSM存儲引擎極大優化寫，高性能實例極大優化讀。

寫入成功即保證落盤成功，數據可靠性提供10個9的SLA保障。

磁盤性數據庫，費用比內存性的要低幾個量級。

單表可存儲十萬億行以上的數據，價格又低，輕鬆保存用戶Feed流中的全部Feed數據。

上面說了使用開源Redis和阿里雲TableStore的異同，若是使用開源能夠用Redis，若是選擇阿里雲自研NoSQL數據庫，可使用TableStore。

架構圖

下面咱們來看一下使用TableStore的架構圖，這裏爲了通用性，選用推拉結合的方式，推模式更加簡單。

存儲

咱們先來看中間黑色框中的部分，這部分是使用TableStore的數據，從左往右分別是：

我的頁Timeline：這個是每一個用戶的發件箱，也就是本身的我的頁頁面。

關注頁Timeline：這個是每一個用戶的收件箱，也就是本身的關注頁頁面，內容都是本身關注人發佈的消息。

關注列表：保存帳號關係，好比朋友圈中的好友關係；微博中的關注列表等。

虛擬關注列表：這個主要用來個性化和廣告。

發佈Feed流程

當你發佈一條Feed消息的時候，流程是這樣的：

1. Feed消息先進入一個隊列服務。

2. 先從關注列表中讀取到本身的粉絲列表，以及判斷本身是不是大V。

3. 將本身的Feed消息寫入我的頁Timeline（發件箱）。若是是大V，寫入流程到此就結束了。

4. 若是是普通用戶，還須要將本身的Feed消息寫給本身的粉絲，若是有100個粉絲，那麼就要寫給100個用戶，包括Feed內容和Feed ID。

5. 第三步和第四步能夠合併在一塊兒，使用BatchWriteRow接口一次性將多行數據寫入TableStore。

6. 發佈Feed的流程到此結束。

讀取Feed流流程

當刷新本身的Feed流的時候，流程是這樣的：

1. 先去讀取本身關注的大V列表

2. 去讀取本身的收件箱，只須要一個GetRange讀取一個範圍便可，範圍起始位置是上次讀取到的最新Feed的ID，結束位置可使當前時間，也能夠是MAX，建議是MAX值。因爲以前使用了主鍵自增功能，因此這裏可使用GetRange讀取。

3. 若是有關注的大V，則再次併發讀取每個大V的發件箱，若是關注了10個大V，那麼則須要10次訪問。

4. 合併2和3步的結果，而後按時間排序，返回給用戶。

至此，使用推拉結合方式的發佈，讀取Feed流的流程都結束了。

更簡單的推模式

若是隻是用推模式了，則會更加簡單：

發佈Feed：

不用區分是否大V，全部用戶的流程都同樣，都是三步。

讀取Feed流：

不須要第一步，也不須要第三步，只須要第二步便可，將以前的2 + N(N是關注的大V個數) 次網絡開銷減小爲 1 次網絡開銷。讀取延時大幅降級。

個性化和定向廣告

個性化和定向廣告是兩種很強烈的產品需求。個性化能夠服務好用戶，增大產品競爭力和用戶粘性，而定向廣告能夠爲產品增長盈利渠道，並且還能夠不招來用戶反感，那麼這兩種方式如何實現呢？在Feeds流裏面這兩種功能的實現方式差很少，咱們以定向廣告爲例來講明：

1. 經過用戶特徵分析對用戶分類，好比其中有一類是新生類：今年剛上大學的新生。（具體的用戶特徵分析能夠依靠TableStore + MaxCompute，這裏就不說了）。

2. 建立一個廣告帳號：新生廣告

3. 讓這些具備新生特徵的用戶虛擬關注新生廣告帳號。用戶看不到這一層關注關係。

4. 從七月份開始就能夠經過新生廣告帳號發送廣告了。

5. 最終，每一個用戶可能會有多個特徵，那麼就可能虛擬關注多個廣告帳號。

上面是定向廣告的一種比較簡單的實現方式，其餘方式就再也不贅述了。

收益

上面咱們詳細說了使用TableStore做爲存儲和推送系統的架構，接下來咱們看看新架構能給咱們帶來多大收益。

只使用1種系統，架構、實現簡單。再也不須要訪問多個系統，架構，開發，測試，運維都能節省大力人力時間。

TableStore 主鍵自增列功能性能極優。因爲架構的不一樣，不只不須要表鎖，行鎖也不須要，因此性能要遠遠好於關係型數據庫。

能夠保存全部的Feed。一是系統能夠支持存儲全部Feed，二是價格便宜，存的起。

無須將Feed ID和內容分開存儲。價格便宜，也就不須要再分開存儲ID和內容了。

全託管服務，無運維操做，更無需分庫分表。

磁盤型(SSD、Hybrid)數據庫，成本低。

可靠性10個9，數據更可靠，更不易丟失。

大V和普通用戶的切分閾值更高，讀取大V的次數更少，總體延時更低。

一個設計缺陷

若是使用大V/普通用戶的切分方式，大V使用拉模式，普通用戶使用推模式，那麼這種架構就會存在一種很大的風險。

好比某個大V忽然發了一個頗有話題性的Feed，那麼就有可能致使整個Feed產品中的全部用戶都無法讀取新內容了，緣由是這樣的：

大V發送Feed消息。

大V，使用拉模式。

大V的活躍粉絲（用戶羣A）開始經過拉模式（架構圖中讀取的步驟3，簡稱讀3）讀取大V的新Feed。

Feed內容太有話題性了，快速傳播。

未登陸的大V粉絲（用戶羣B）開始登錄產品，登錄進去後自動刷新，再次經過讀3步驟讀取大V的Feed內容。

非粉絲（用戶羣C）去大V的我的頁Timeline裏面去圍觀，再次須要讀取大V我的的Timeline，同讀3.

結果就是，平時正常流量只有用戶羣A，結果如今倒是用戶羣A + 用戶羣B+ 用戶羣C，流量增長了好幾倍，甚至幾十倍，致使讀3路徑的服務模塊被打到server busy或者機器資源被打滿，致使讀取大V的讀3路徑沒法返回請求，若是Feed產品中的用戶都有關注大V，那麼基本上全部用戶都會卡死在讀取大V的讀3路徑上，而後就無法刷新了。

因此這裏設計的時候就須要重點關心下面兩點：

單個模塊的不可用，不該該阻止整個關鍵的讀Feed流路徑，若是大V的沒法讀取，可是普通用戶的要能返回，等服務恢復後，再補齊大V的內容便可。

當模塊沒法承受這麼大流量的時候，模塊不該該徹底不可服務，而應該能繼續提供最大的服務能力，超過的拒絕掉。

那麼如何優化呢？

不使用大V/普通用戶的優化方式，使用活躍用戶/非活躍用戶的優化方式。這樣的話，就能把用戶羣A和部分用戶羣B分流到其餘更分散的多個路徑上去。並且，就算讀3路徑不可用，仍然對活躍用戶無任何影響。

徹底使用推模式就能夠完全解決這個問題，可是會帶來存儲量增大，大V微博發送總時間增大，從發給第一個粉絲到發給最後一個粉絲可能要幾分鐘時間（一億粉絲，100萬行每秒，須要100秒），還要爲最大併發預留好資源，若是使用表格存儲，由於是雲服務，則不須要考慮預留最大額度資源的問題。

實踐

接下來咱們來實現一個消息廣場的功能。不少App中都有動態或消息廣場的功能，在消息廣場中通常有兩個Tab，一個是關注人，一個是廣場，咱們這裏重點來看關注人。

要實現的功能以下：

用戶之間能夠相互關注

用戶能夠發佈新消息

用戶能夠查看本身發佈的消息列表

用戶能夠查看本身關注的人的消息

採起前面的方案：

使用TableStore做爲存儲和推送系統

採用Timeline的顯示方式，但願用戶能夠認真看每條Feed

採用推模式

角色

接着，咱們看看角色和每一個角色須要的功能：

發送者

發送狀態：add_activity()

接收者

關注：follow()

讀取Feed流：get_activity()

Feed消息中至少須要包括下面內容：

消息：

發送人：actor

類型：verb，好比圖片，視頻，文本

文本文字：message

架構圖

發佈新消息

接口：add_activity()

實現：

get_range接口調用關注列表，返回粉絲列表。

batch_write_row接口將feed內容和ID批量寫入我的頁表（發件箱）和全部粉絲的關注頁表（收件箱），若是量太大，能夠屢次寫入。或者調用異步batch_write_row接口，目前C++ SDK和JAVA SDK提供異步接口。

關注

接口：follow()

實現：

put_row接口直接寫入一行數據(關注人，粉絲)到關注列表和粉絲列表（粉絲，關注人）便可。

獲取Feed流消息

接口：get_activity()

實現：

從客戶端獲取上次讀取到的最新消息的ID：last_id

使用get_range接口讀取最新的消息，起始位置是last_id，結束位置是MAX。

若是是讀取我的頁的內容，訪問我的頁表便可。若是是讀取關注頁的內容，訪問關注頁表便可。

計劃

上面展現瞭如何使用表格存儲TableStore的API來實現。這個雖然只用到幾個接口，可是仍然須要學習表格存儲的API和特性，仍是有點費時間。

爲了更加易用性，咱們接下來會提供Feeds流完整解決方案，提供一個LIB，接口直接是add_activity()，follow()和get_activity()相似的接口，使用上會更加簡單和快捷。

擴展

前面講述的都是Timeline類型的Feed流類型，可是還有一種Feed流類型比較常見，那就是新聞推薦，圖片分享網站經常使用的Rank類型。

咱們再來回顧下Rank類型擅長的領域：

潛在Feed內容很是多，用戶沒法所有看完，也不須要所有看完，那麼須要爲用戶選出她最想看的內容，典型的就是圖片分享網站，新聞推薦網站等。

咱們先來看一種架構圖：

這種Rank方式比較輕量級，適用於推拉結合的場景。

寫流程基本同樣

讀流程裏面會先讀取全部的Feed內容，這個和Timeline也同樣，Timeline裏面的話，這裏會直接返回給用戶，可是Rank類型須要在一個排序模塊裏面，按照某個屬性值排序，而後將全部結果存入一個timeline cache中，並返回分數最高的N個結果，下次讀取的時候再返回[N+1, 2N]的結果。

再來看另一種：