一、微博feed系統(tǒng)的推模式架構

1、發(fā)布服務

負責生成用戶的消息，將消息推送到數(shù)據(jù)發(fā)布中心。

2、推送服務

在接收到新消息后，根據(jù)消息的類型和內容信息進行用戶匹配，向用戶推送個性化的消息流。

3、數(shù)據(jù)發(fā)布中心

接收發(fā)布服務推送的消息，將消息進行轉換、去重和分級處理，同時創(chuàng)建索引，為后續(xù)的消息處理提供支持。

4、移動終端

接收用戶推送的消息流。

二、微博feed系統(tǒng)的拉模式架構

1、消息查詢服務

提供消息查詢接口，支持按時間線查詢消息。

2、推送服務

維護用戶的消息流，當有新的消息到達或舊的消息需要更新時，會將更新后的消息推送到用戶的消息流中。

3、移動終端

根據(jù)用戶請求，向消息查詢服務發(fā)送查詢請求，通過推送服務獲取需要展示的消息。

三、Feed系統(tǒng)介紹

1、簡介

當互聯(lián)網開始進入移動互聯(lián)網時代，具代表性的產品就是微博、微信，以及后來的今日頭條、快手等。這些移動互聯(lián)網時代的新產品在過去幾年間借著智能手機的風高速成長。這些產品都是Feed流類型產品，由于Feed流一般是按照時間“從上往下流動”，非常適合在移動設備端瀏覽，最終這一類應用就脫穎而出，迅速搶占了上一代產品的市場空間。

Feed流是Feed+流，F(xiàn)eed的本意是飼料，F(xiàn)eed流的本意就是有人一直在往一個地方投遞新鮮的飼料，如果需要飼料，只需要盯著投遞點就可以了，這樣就能源源不斷獲取到新鮮的飼料。在信息學里面，F(xiàn)eed其實是一個信息單元，比如一條朋友圈狀態(tài)、一條微博、一條咨詢或一條短視頻等，所以Feed流就是不停更新的信息單元，只要關注某些發(fā)布者就能獲取到源源不斷的新鮮信息，我們的用戶也就可以在移動設備上逐條去瀏覽這些信息單元。

當前最流行的Feed流產品有微博、微信朋友圈、頭條的資訊推薦、快手抖音的視頻推薦等，還有一些變種，比如私信、通知等，這些系統(tǒng)都是Feed流系統(tǒng)，接下來我們會介紹如何設計一個Feed流系統(tǒng)架構。

2、Feed流系統(tǒng)特點

Feed流本質上是一個數(shù)據(jù)流，是將 “N個發(fā)布者的信息單元” 通過 “關注關系” 傳送給 “M個接收者”。

3、Feed流系統(tǒng)的數(shù)據(jù)

Feed流系統(tǒng)是一個數(shù)據(jù)流系統(tǒng)，所以我們核心要看數(shù)據(jù)。從數(shù)據(jù)層面看，數(shù)據(jù)分為三類，分別是：

發(fā)布者的數(shù)據(jù)：發(fā)布者產生數(shù)據(jù)，然后數(shù)據(jù)需要按照發(fā)布者組織，需要根據(jù)發(fā)布者查到所有數(shù)據(jù)，比如微博的個人頁面、朋友圈的個人相冊等。關注關系：系統(tǒng)中個體間的關系，微博中是關注，是單向流，朋友圈是好友，是雙向流。不管是單向還是雙向，當發(fā)布者發(fā)布一條信息時，該條信息的流動永遠是單向的。接收者的數(shù)據(jù)：從不同發(fā)布者那里獲取到的數(shù)據(jù)，然后通過某種順序（一般為時間）組織在一起，比如微博的首頁、朋友圈首頁等。這些數(shù)據(jù)具有時間熱度屬性，越新的數(shù)據(jù)越有價值，越新的數(shù)據(jù)就要排在最前面。

針對這三類數(shù)據(jù)，我們可以有如下定義：

存儲庫：存儲發(fā)布者的數(shù)據(jù)，永久保存。關注表：用戶關系表，永久保存。同步庫：存儲接收者的時間熱度數(shù)據(jù)，只需要保留最近一段時間的數(shù)據(jù)即可。

4、排序

目前的Feed流系統(tǒng)中的排序方式有兩種，一種是時間，一種是分數(shù)。我們常用的微博、朋友圈、私信這些都是時間線類型的，因為這些產品定義中，需要我們主動關注某些人后才會看到這些人發(fā)表的內容，這個時候，最重要的是實時性，而不是發(fā)布質量，就算關注人發(fā)布了一條垃圾信息，我們也會被動看到。這種類型的產品適用于按照時間線排序。這一篇我們介紹的架構都是基于時間類型的。

另外一種是不需要關注任何人，我們能看到的都是系統(tǒng)希望我們看到的，系統(tǒng)在后臺會分析我們的每個人的愛好，然后給每個人推送差異化的、各自喜歡的內容，這一種的架構和基于時間的完全不一樣，我們在后續(xù)的推薦類型中專門介紹。

延伸閱讀1：如何刪除Feed內容

在Feed流應用中有一個問題，就是如果用戶刪除了之前發(fā)表的內容，系統(tǒng)該如何處理？因為系統(tǒng)里面有寫擴散，那么刪除的時候是不是也要寫擴散一遍？這樣的話，刪除就不及時了，很難應對法律法規(guī)要求的快速刪除。針對這個問題，我們在之前設計的時候，同步表中只有消息ID，沒有消息內容，在用戶讀取的時候需要到存儲庫中去讀消息內容，那么我們可以直接刪除存儲庫中的這一條消息，這樣用戶讀取的時候使用消息ID是讀不到數(shù)據(jù)的，也就相當于刪除的內容，而且刪除速度會很快。除了直接刪除外，另外一種辦法是邏輯刪除，對于刪除的feed內容，只做標記，當查詢到帶有標記的數(shù)據(jù)時就認為刪除了。