業務中很多需求都會用到類似feed流的架構。
例如微博
動態1對n訊息。
一般feed流的架構實現有下面幾種。
假如現在的業務場景是微博，然後當前的資料情況是：
使用者a關注了使用者b和c，使用者d關注了使用者b
使用者b發了微博a，b，使用者c發了微博c，d
資料表**邏輯：
使用者 b發布微博介面，插入記錄到微博表，只有一行記錄
使用者a獲取我關注的使用者的微博介面：
獲取當前登入使用者關注的使用者，例如a關注的使用者b和c
獲取b和c發布的所有微博，
按時間倒序排列，分頁，返回
優缺點：
資料表**邏輯：
發布微博介面
插入記錄到微博表
獲取當前使用者粉絲使用者列表，假如當前使用者是b，那就是獲取a和d
插入2行記錄到feed流表
接收人=a，微博id=剛才的微博表id
接收人=b，微博id=剛才的微博表id
使用者a獲取我關注的使用者的微博介面：
查詢feed流表，找到接收人=a的記錄，按發布時間倒序排，分頁，返回
優缺點：
上面兩種方案都有優缺點，當對讀的要求很高，同時使用者粉絲數很大，就要想辦法優化，推+拉是其中一種方案。
具體方法是區分使用者：
從產品的角度看，有很多種方法可以區分使用者是否屬於經常讀，這裡提供其中乙個可行的方案：
資料表**邏輯：
發布微博介面
插入記錄到微博表
獲取當前使用者活躍粉絲使用者列表，假如當前使用者是b，那就是獲取a和d，其中a是活躍使用者，d是非活躍，那就只獲取a。sql可以用exists，例如：select * from fans where exists (select * from 活躍表 where 是否活躍=1)
插入1行記錄到feed流表（d不是活躍使用者，就不插入了）
接收人=a，微博id=剛才的微博表id
使用者a獲取我關注的使用者的微博介面：
查詢feed流表，找到接收人=a的記錄，按發布時間倒序排，分頁，返回
如果使用者是活躍使用者，更新使用者最新登入時間
如果不是，通過拉方式為使用者補發feed流：
獲取使用者所有關注的使用者
獲取這些使用者發的微博
把這些微博id插入到使用者的feed流表（要避免重複插入）
定時任務
每天把最新登入時間小於1天前的使用者，設定為非活躍
優缺點：
feed流和瀑布流 積累 feed流
了解feed流 feed v.餵養 進食 為.提供.n.飼養 餵食 正如現在各個平台為使用者提供的精神層面的資訊內容，這些內容組合起來的格式，便是feed。平台藉此傳遞給使用者，乙個朋友圈動態，一條微博，即為feed。feed流是持續更新呈現給使用者的資訊流。feed流模式 推模式 例如乙個大v發了...
feed流和瀑布流 什麼叫feed流？
feed流是乙個資訊出口，想要與他人或資訊建立連線，只需要重新整理這乙個動作，即可獲得大量所需，並且不斷在更新，可謂殺時間好手，令人沉溺。想要設計好feed流頁面，對feed流的概念，模式進行了解是十分必要的。什麼是feed流呢？feed，源自早期的rss。2006年 facebook重新定義了fe...
什麼是feed流？
總結一下 feed是將使用者主動訂閱的若干訊息源組合在一起形成內容聚合器，幫助使用者持續地獲取最新的訂閱源內容。嚴格按照上述定義來說，我們通常說的搜尋結果 排序列表都不能算作feed流。feed流的展現形式有很多種，主要的有timeline以及rank。timeline 是最典型的feed流展示方式...