Feed流這塊相較于電商偏冷門一些，可能有些同學對其概念不太理解，我先來解釋一下。

其實，咱們每天刷的小紅書首頁、抖音推薦頁、新浪微博等，這些都是Feed流，說白了就是“按規則排序的內容信息流”。

如下圖所示：

圖片

Feed流一共分為三大類，基于興趣推薦內容、基于用戶關注獲取內容，以及將兩者相結合起來。

把你所關注博主的內容、系統推薦的內容，按時間先后、興趣匹配、熱度高低等因素，整合成一條能持續往下滑的內容列表，你刷的每一頁都是Feed流動態生成的結果。

Feed流具備三個核心特點：

1、動態更新，你關注的博主新增了筆記或視頻，就可能會出現到Feed流信息中，不是一成不變的固定頁面。

2、個性化推薦，會根據平臺算法給你挑內容推薦，如果你對“汽車”方向感興趣，就不會一直給你推薦“寵物”相關的內容。

3、沉浸式閱覽，你不用點進不同頁面查找內容，上下滑動就能持續閱覽，猶如“刷瀑布” 般順暢。

接下來我們就來講講基于用戶關注獲取內容的Feed流，以及其相關的讀擴散和寫擴散方案。

讀擴散機制

我們還是以小紅書APP為例進行講解。

當我在小紅書APP中點擊“關注”頁時，系統會從我關注的所有博主的發件箱中獲取筆記，并選擇其中的一些熱度較高、質量優質、時間較近的筆記進行展示。

這就是讀擴散機制，所謂“擴散”，就是需要讀取我關注的所有博主的筆記。

如下圖所示：

圖片

圖片

這里有個發件箱和收件箱的概念，我來解釋一下。

發件箱（Outbox）

用戶發布內容時，消息首先被寫入的存儲區域，記錄用戶所有歷史發布內容，類似于電子郵箱中的“已發送”文件夾，每條消息僅存儲一份。

收件箱（Inbox）

用戶接收關注對象發布內容的存儲區域，按時間順序聚合所有關注人的消息，類似于電子郵箱中的“收件箱”文件夾，每條消息可能被存儲多份（群發）。

細心的同學會想到，按照上述“讀擴散”機制獲取筆記，如果我關注了特別多（幾百上千）的博主，那當我點擊“關注”頁的時候才現從各個博主的收件箱中讀取筆記，并基于規則因子進行排序，這樣會耗時非常久，嚴重影響用戶體驗。

于是就衍生出了一種新的機制來進行互補——寫擴散機制。

寫擴散機制

所謂寫擴散機制，就是當小紅書博主發布筆記時，除了寫入自己的發件箱外，同時將筆記寫入到所有粉絲（包括我）的收件箱中。

這樣當我點擊“關注”頁時，直接從自己的收件箱中選擇其中的一些熱度較高、質量優質、時間較近的筆記進行展示即可。

通過這種方式，就無需從我所關注博主的發件箱中獲取筆記了，可以大幅縮短耗時，這是一種用空間換時間的思想。

如下圖所示：

圖片

這種機制看似很美好，但真的可以一招鮮解決所有Feed流問題，讓讀擴散機制完全沒有用武之地嗎？

當然不能，因為小紅書APP上還有另外兩種生物，一種生物叫做大V，也就是粉絲量特別多的那種博主。

以演員趙露思為例，如果她發布一條筆記，2000多萬粉絲采用寫擴散機制，那不把數據庫服務器硬盤的IOPS打滿才怪。

圖片

另一種生物叫做僵尸粉，也就是常年都不登錄小紅書APP的用戶，往這類用戶的收件箱里面不斷地寫入筆記，實屬有些消耗寫擴散性能和浪費硬件存儲資源。

讀擴散 + 寫擴散機制結合

這種讀擴散 + 寫擴散結合的機制才是主流的Feed流解決方案，我們來詳細介紹一下。

如上文所述，小紅書APP上的用戶分為三大類：活躍用戶、僵尸用戶和大V，這三類人是可以通過用戶粉絲數和用戶行為識別出來的。

1、如果大V進行筆記發布，需要通過讀擴散機制來代替寫擴散機制，來避免其寫入熱點導致數據庫服務器硬盤的IOPS打滿問題。

2、對于僵尸用戶，同樣需要通過讀擴散機制來代替寫擴散機制，來避免寫擴散機制所帶來的性能消耗和存儲資源浪費問題。

3、而對于活躍用戶，我們可以采用寫擴散為主、讀擴散為輔的方式，前者可以縮短筆記展示耗時，提升用戶體驗，后者則可以規避大V發布筆記的情況。

因此，對于寫擴散機制來說，其只適用于非大V博主進行筆記發布時，往活躍粉絲的收件箱進行寫入的場景。

圖片

結語

對于Feed流的讀擴散和寫擴散機制來說，根本沒有好壞之分，只有場景適用或不適用，我們來做個總結。

1、讀擴散機制的優點是消息寫入效率高，且消息僅在發件箱存儲一份，無需冗余存儲。

缺點則是Feed流讀取性能差，需要從多個發件箱讀取消息，并按照規則因子進行排序，高并發下容易成為瓶頸。

2、寫擴散機制的優點則是讀擴散機制的缺點，那就是Feed流去讀性能好，直接從自己的收件箱讀取數據，并按照規則因子進行排序即可，無需進行多源聚合。

缺點則是消息寫入效率低且復雜度高，且消息需要在所有粉絲的發件箱冗余存儲一份，浪費硬件存儲資源。

另外就是，我們可以在項目采用讀擴散機制快速驗證業務，降低存儲與開發成本，發展至中長期再逐步迭代至讀擴散 + 寫擴散機制結合終態方案。