LZ可能要去新的公司從事Feed流推薦相關的工作，在此之前，打算先對這一塊內容做一個簡單的介紹，也有利於我自身後續在這一方面的深耕。

在網際網路領域，尤其現在的移動網際網路時代，Feed流產品是非常常見的，比如我們每天都會用到的朋友圈，微博，就是一種非常典型的Feed流產品，還有圖片分享網站Pinterest，花瓣網等又是另一種形式的Feed流產品。除此之外，很多App的都會有一個模組，要麼叫動態，要麼叫訊息廣場，這些也是Feed流產品，可以說，Feed流產品是遍佈天下所有的App中。

概念

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

Feed流：持續更新並呈現給使用者內容的資訊流。每個人的朋友圈，微博關注頁面也都是一個Feed流。

Timeline：Timeline其實是一種Feed流的型別，微博，朋友圈其實都是Timeline型別的Feed流，但是由於Timeline型別出現最早，使用最廣泛，最為人熟知，因此也用Timeline來表示Feed流。

關注頁Feed流：展示其他人的Feed訊息的頁面，比如朋友圈、微博首頁等。

個人頁Feed流：展示自己傳送過來的Feed訊息的頁面，比如微信中的相簿、微博個人頁等。

特徵

Feed流系統有一些典型的特點，比如：

• 多賬號內容流：Feed流系統中肯定會存在成千上萬的賬號，賬號之間可以關注，取關，加好友和拉黑等操作。只要滿足這一條，那麼就可以當做Feed流系統來設計。
• 非穩定的賬號關係：由於存在關注，取關等操作，所以系統中的使用者之間的關係就會一直在變化，是一種非穩定的狀態。
• 讀寫比例100:1：讀寫嚴重不平衡，讀多寫少，一般讀寫比例在10：1，甚至100：1以上。
• 訊息必達性要求高：比如傳送了一條朋友圈後，結果部分朋友看到了，部分朋友沒看到，如果偏偏女朋友沒看到，那麼可能會產生很嚴重的感情矛盾，後果很嚴重。

分類

Feed流的分類有好多種，常見的分類有兩種：

Timeline：按照時間的順序排序，先發布的人先看到，後釋出的排列在最頂端，類似於微信朋友圈、微博等。如果選擇Timeline，就可以認為Feed流中的Feed不多，但每個Feed都很重要，都需要使用者看到，目前微信的朋友圈依然採用這種方式實現。

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

上面兩種是最常見的分類方式，也有其他的一些分類方式，比如Aggregate、Notice方式，其中：

Aggregate方式表示聚合型別，比如幾個朋友看了一部電影，這就可以聚合為一條Feed：A，B，C看了電影《你的名字》，這種聚合功能比較適合在客戶端做。一般的Aggregate型別是Timeline型別+客戶端聚合。

Notice：通知型別，功能型別，一般用於各種APP中的各種通知、私信等場景，也是Timeline和Aggregate型別等。

實現

設計一個Feed流系統，最關鍵的兩個核心在於儲存和推送。

儲存

我們先來看儲存，Feed流系統中需要儲存的內容分為兩部分，一個是賬號關係（比如關注列表），一種是Feed訊息內容。不管是儲存哪一種，都有幾個問題需要考慮：

• 如何能支援100TB，甚至PB級資料量？
• 資料量大了後成本就很關鍵，成本如何能更便宜？
• 如何保證賬號關係和Feed不丟失？

推送

推送系統需要考慮的功能有兩個：一個是釋出Feed，另一個是讀取Feed。對於推送系統，仍然需要考慮兩個問題：

如何能夠保證提供千萬級的TPS和QPS？

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

如何保證Feed的必達性？

儲存系統選擇

儲存系統主要有兩類：一類是賬號關係(例如關注列表)、一類是Feed訊息。

儲存賬號關係

賬號關係的儲存，有如下特徵：

一系列的變長連結串列，長度可達億級別

資料量非常大，關係極其簡單

效能敏感，直接影響關注，取關的響應速度

最適合儲存賬號關係的系統應該是NoSQL資料庫，資料量極大，關係簡單不需要複雜的join，效能要求高。

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

有序性：有序性不要求具有排序功能，而只需要按照主鍵排序即可，只要按照主鍵排序，關注列表和粉絲列表的順序就是固定的，可預見的。

儲存Feed訊息

Feed訊息有一個最大的特點：

資料量大，而且在Feed流系統裡很多時候都會選擇擴散(推模式)，這時候資料量會再膨脹幾個數量級，所以這裡的資料量往往達到100TB，甚至PB級別。

此外，還有一些如下特徵：

資料格式簡單

資料不能丟失，可靠性要求高

自增主鍵功能，保證個人發的Feed的訊息ID在個人發件箱中都是嚴格遞增的，則讀取時只需要一個範圍即可。由於個人釋出的Feed併發度很低，這裡用時間戳也能基本滿足需求，但是當應用層佇列堵塞，網路延遲變大或時間回退時，用時間戳還是無法保證嚴格遞增。

成本越低越好