一、微博feed系統的推模式架構
1、發布服務
負責生成用戶的消息,將消息推送到數據發布中心。
2、推送服務
在接收到新消息后,根據消息的類型和內容信息進行用戶匹配,向用戶推送個性化的消息流。
3、數據發布中心
接收發布服務推送的消息,將消息進行轉換、去重和分級處理,同時創建索引,為后續的消息處理提供支持。
4、移動終端
接收用戶推送的消息流。
二、微博feed系統的拉模式架構
1、消息查詢服務
提供消息查詢接口,支持按時間線查詢消息。
2、推送服務
維護用戶的消息流,當有新的消息到達或舊的消息需要更新時,會將更新后的消息推送到用戶的消息流中。
3、移動終端
根據用戶請求,向消息查詢服務發送查詢請求,通過推送服務獲取需要展示的消息。
三、Feed系統介紹
1、簡介
當互聯網開始進入移動互聯網時代,具代表性的產品就是微博、微信,以及后來的今日頭條、快手等。這些移動互聯網時代的新產品在過去幾年間借著智能手機的風高速成長。這些產品都是Feed流類型產品,由于Feed流一般是按照時間“從上往下流動”,非常適合在移動設備端瀏覽,最終這一類應用就脫穎而出,迅速搶占了上一代產品的市場空間。
Feed流是Feed+流,Feed的本意是飼料,Feed流的本意就是有人一直在往一個地方投遞新鮮的飼料,如果需要飼料,只需要盯著投遞點就可以了,這樣就能源源不斷獲取到新鮮的飼料。在信息學里面,Feed其實是一個信息單元,比如一條朋友圈狀態、一條微博、一條咨詢或一條短視頻等,所以Feed流就是不停更新的信息單元,只要關注某些發布者就能獲取到源源不斷的新鮮信息,我們的用戶也就可以在移動設備上逐條去瀏覽這些信息單元。
當前最流行的Feed流產品有微博、微信朋友圈、頭條的資訊推薦、快手抖音的視頻推薦等,還有一些變種,比如私信、通知等,這些系統都是Feed流系統,接下來我們會介紹如何設計一個Feed流系統架構。
2、Feed流系統特點
Feed流本質上是一個數據流,是將 “N個發布者的信息單元” 通過 “關注關系” 傳送給 “M個接收者”。
3、Feed流系統的數據
Feed流系統是一個數據流系統,所以我們核心要看數據。從數據層面看,數據分為三類,分別是:
發布者的數據:發布者產生數據,然后數據需要按照發布者組織,需要根據發布者查到所有數據,比如微博的個人頁面、朋友圈的個人相冊等。關注關系:系統中個體間的關系,微博中是關注,是單向流,朋友圈是好友,是雙向流。不管是單向還是雙向,當發布者發布一條信息時,該條信息的流動永遠是單向的。接收者的數據:從不同發布者那里獲取到的數據,然后通過某種順序(一般為時間)組織在一起,比如微博的首頁、朋友圈首頁等。這些數據具有時間熱度屬性,越新的數據越有價值,越新的數據就要排在最前面。針對這三類數據,我們可以有如下定義:
存儲庫:存儲發布者的數據,永久保存。關注表:用戶關系表,永久保存。同步庫:存儲接收者的時間熱度數據,只需要保留最近一段時間的數據即可。4、排序
目前的Feed流系統中的排序方式有兩種,一種是時間,一種是分數。我們常用的微博、朋友圈、私信這些都是時間線類型的,因為這些產品定義中,需要我們主動關注某些人后才會看到這些人發表的內容,這個時候,最重要的是實時性,而不是發布質量,就算關注人發布了一條垃圾信息,我們也會被動看到。這種類型的產品適用于按照時間線排序。這一篇我們介紹的架構都是基于時間類型的。
另外一種是不需要關注任何人,我們能看到的都是系統希望我們看到的,系統在后臺會分析我們的每個人的愛好,然后給每個人推送差異化的、各自喜歡的內容,這一種的架構和基于時間的完全不一樣,我們在后續的推薦類型中專門介紹。
延伸閱讀1:如何刪除Feed內容
在Feed流應用中有一個問題,就是如果用戶刪除了之前發表的內容,系統該如何處理?因為系統里面有寫擴散,那么刪除的時候是不是也要寫擴散一遍?這樣的話,刪除就不及時了,很難應對法律法規要求的快速刪除。針對這個問題,我們在之前設計的時候,同步表中只有消息ID,沒有消息內容,在用戶讀取的時候需要到存儲庫中去讀消息內容,那么我們可以直接刪除存儲庫中的這一條消息,這樣用戶讀取的時候使用消息ID是讀不到數據的,也就相當于刪除的內容,而且刪除速度會很快。除了直接刪除外,另外一種辦法是邏輯刪除,對于刪除的feed內容,只做標記,當查詢到帶有標記的數據時就認為刪除了。