什么是feed流?什么是讀擴散?什么是寫擴散?

任何脫離業務的架構設計都是耍流氓，今天和大家聊聊這幾個話題。

哪些產品是feed流典型業務?

微博，微信朋友圈，Pinterest是典型的feed流業務，系統中的每一條消息就是一個feed。

這類業務有什么特點?

(1)有好友關系，例如關注，粉絲;

(2)我們的主頁由別人發布的feed組成。

這類業務的核心業務動作是什么?

(1)關注，取關;

(2)發布feed;

(3)拉取自己的主頁feed流。

這類業務的核心元數據是什么?

(1)關系數據;

(2)feed數據。

feed流的“拉取”與“推送”實現，是個怎么回事?

feed流業務最大的特點是“我們的主頁由別人發布的feed組成”，獲得朋友圈消息feed流集合，從技術上說，主要有：

(1)拉取(讀擴散);

(2)推送(寫擴散)。

兩種方式。feed流的推與拉主要指的是這里。

什么是拉模式 ，讀擴散方案?

例如，某feed系統里有ABCD四個用戶，其中：

(1)A關注了BC，D關注了B;

其關系存儲又包含關注關系與粉絲關系，“A關注了BC，D關注了B”的潛臺詞是“B有兩個粉絲AD，C有一個粉絲A”。

(2)B發布過四條feed：msg1, msg3, msg5, msg10;

(3)C發布過兩條feed：msg2, msg8;

每一個用戶，都有一個feed隊列，記錄自己曾經發布的所有feed數據。

拉模式讀擴散如何實現feed發布?

在拉模式中，發布一條feed的流程非常簡單，例如C新發布了一條msg12：

此時只需往C的feed隊列里加入一條feed即可。

拉模式讀擴散如何實現關注/取關?

在拉模式中，取消關注的流程也非常簡單，例如A取消關注C：

此時只需要在A的關注列表里刪除C，并在C的粉絲列表里刪除A即可。

拉模式讀擴散如何實現個人主頁feed流?

在拉模式中，用戶A獲取“由別人發布的feed組成的主頁”的過程及其復雜，此時需要：

(1)獲取A的關注列表;

(2)獲取所關注列表中，所有用戶發布的feed;

(3)對消息進行rank排序(假設按照發布時間排序)，分頁取出對應的一頁feeds。

拉模式讀擴散有什么優點?

(1)存儲結構簡單，數據存儲量較小，關系數據與feed數據都只存一份;

(2)關注，取關，發布feed的業務流程非常簡單;

(3)存儲結構，業務流程都比較容易理解，適合項目早期用戶量、數據量、并發量不大時的快速實現。

拉模式讀擴散有什么缺點?

(1)拉取朋友圈feed流列表的業務流程非常復雜;

(2)有多次數據訪問，并且要進行大量的內存計算，網絡傳輸，性能較低。

什么是推模式 ，寫擴散方案?

推模式(寫擴散)，關系數據的存儲與拉模式(讀擴散)完全一樣。

feed數據，每個用戶也存儲自己發布的feed。

如上圖：

(1)B曾經發布過1，3，5，10;

(2)C曾經發布過2，8。

畫外音：不妨設，這里的msgid按照feed的發布時間偏序。

feed數據存儲，與拉(讀擴散)不同的是，每個用戶還需要存儲自己收到的feed流。

如上圖：

(1)A關注了BC，所以A的接收隊列是1，2，3，5，8，10;

(2)D關注了B，所以D的接受隊列是1，3，5，10。

推模式寫擴散如何實現個人主頁feed流?

在推模式(寫擴散)中，獲取“由別人發布的feed組成的主頁”會變得異常簡單，假設一頁消息為3條feed，A如果要看自己朋友圈的第二頁消息，直接返回1，2，3即可。

畫外音：第一頁朋友圈是最新的消息，即5，8，10。

推模式寫擴散如何實現feed發布?

在推模式(寫擴散)中，發布一條feed的流程會更復雜一點。

例如B新發布了一條msg12：

(1)在B的發布feed存儲里加入消息12;

(2)查詢B全部粉絲AD;

(3)在粉絲AD的接收feed存儲里也加入消息12。

之所以該方案稱為推模式(寫擴散)，就是因為，用戶發布feed的時候：

(1)直接將feed推到了粉絲的接收列表里，故稱為“推模式”;

(2)不止寫發布feed存儲，而且要寫多個粉絲的接收feed存儲，故稱為“寫擴散”。

推模式寫擴散如何實現關注/取關?

在推模式(寫擴散)中，添加關注的流程也會變得復雜。

例如D新增關注C：

(1)在D的關注存儲里添加C;

(2)在C的粉絲存儲里添加D;

(3)在D的接收feed存儲里加入C發布的feed。

畫外音：有些產品有這樣的邏輯，“關注之后才能看到feed”，這樣的話就不需要第三步，舊feed無需插入。

在推模式(寫擴散)中，取消關注的流程也會變得復雜。

例如A取消關注C：

(1)在A的關注存儲里刪除C;

(2)在C的粉絲存儲里刪除A;

(3)在A的接收feed存儲里刪除C發布的feed。

推模式寫擴散有什么優點?

(1)消除了拉模式(讀擴散)的IO集中點，每個用戶都讀自己的數據，高并發下鎖競爭少;

畫外音：拉模式(讀擴散)中，用戶發布feed存儲容易成為IO瓶頸。

(2)拉取朋友圈feed流列表的業務流程異常簡單，速度很快;

(3)拉取朋友圈feed流列表，不需要進行大量的內存計算，網絡傳輸，性能很高。

畫外音：feed業務是典型的讀多寫少業務場景，讀寫比甚至高于100：1，即平均發布1條消息，有至少100次閱讀。

推模式寫擴散有什么缺點?

(1)極大極大消耗存儲資源，feed數據會存儲很多份，例如楊冪5KW粉絲，她每次一發博文，消息會冗余5KW份;

畫外音：有朋友提出，可以存儲一份消息實體，只冗余msgid，這樣的話，拉取feed流列表時，還要再次拉取實體，網絡時延會更長，所以很多公司選擇直接冗余消息實體，當然，這是一個用戶體驗與存儲量的折衷設計。

(2)新增關注，取消關注，發布feed的業務流會更復雜。

小結

feed流業務的推拉模式：

(1)拉模式，讀擴散，feed存一份，存儲小，用戶集中訪問數據，性能差;

(2)推模式，寫擴散，feed存多份，用冗余存儲換鎖沖突，性能高;

推拉結合的方式是否可行?又該如何優化呢?

【本文為51CTO專欄作者“58沈劍”原創稿件，轉載請聯系原作者】

戳這里，看該作者更多好文