探討微博時間流的實現

微博feed系統的推(push)模式和拉(pull)模式實現timeline

推拉結合

推數據和拉數據都有什麼優缺點？在用戶的信息流中，推數據的實現其實更簡單。姚晨發了條微博，只須要取出姚晨粉絲的信息流，依次推給粉絲就OK了。拉數據的邏輯實現就很是複雜，須要獲取全部我關注用戶的動態，並對其進行整合，每次刷新、或者加載更多須要判斷的邏輯就更多。

姚晨粉絲1000萬，若是有1000萬個姚晨同時更新了一條動態，數據要推到何時？假設這個狀況真的發生了，那麼首先確定這是一個並行的操做，其次網絡以及緩存那麼快，再加上一些算法優化，我相信超過不了5分鐘吧。並且給全部粉絲推數據也是不現實的。

爲何不是給全部姚晨的粉絲推數據？假設用戶A關注了姚晨以後就再也沒有玩過微博，在有限的內存空間維護用戶A的信息流會變得毫無心義。因此推的對象應該是活躍的用戶，或者是當天的在線用戶。

用戶信息流（Feed）構建

數據存儲基於Redis的ZSet數據結構。ZSet優點很是明顯：自動排序。信息流按照時間排序正是利用了這一點。爲何不考慮使用List，最基本的一點就是取消關注用戶A（或者用戶A刪除了剛剛發的動態）以後，刪除粉絲信息流中A的動態變得很是困難：一個可怕的遍歷操做。

用戶信息流該怎麼建立？APP端用戶對信息流有兩個基本操做，下拉刷新和上拉加載更多。對於活躍用戶，他的信息流都是推過來的，每時每刻都是最新的，因此只考慮數據顯示邏輯就OK了。對於不活躍的怎麼處理了，這個分支有點多？

若是用戶A消失一週以後又想看姚晨的狀態，怎麼辦？很顯然用戶A一下由殭屍粉變成了活躍粉，Redis裏沒有他任何的信息流數據（由於他消失的時間過久了），信息流須要徹底重建。咱們首先獲取他關注的全部用戶，假設爲用戶羣B。篩選用戶羣B中今日更新動態的用戶，而後合併信息流，依次類推。

若是用戶A消失2天以後又想看姚晨的狀態，此時系統已經中止了對他的實時推送，可是他的信息流卻依然存在，只是缺乏了（他的信息流中）最先動態時間到當前時間這段間隔的動態。重構該期間的動態。
綜上所述：中止信息流實時更新的時間間隔、信息流過時時間、用戶最後一次更新動態的時間都是須要認真權衡的。

區分冷熱數據

冷數據、溫數據和熱數據。冷數據——性別、興趣、常住地、職業、年齡等數據畫像，表徵「這是什麼樣的人」；溫數據——近期活躍應用、近期去過的地方等具備必定時效性的行爲數據，表徵「最近對什麼感興趣」；熱數據——當前地點、打開的應用等場景化明顯的、稍縱即逝的營銷機會，表徵「正在哪裏幹什麼」。

---

如何定義活躍用戶？基本上的答案都是：具體要看這個產品是什麼類型的。我以爲用戶產生行爲是根據產品來定義的：好比網易雲閱讀（閱讀類的），用戶只要看了某本書的目錄、看了做者簡介，下載閱讀了，都算是活躍；用戶去作了一些設置，例如換頭像，或者是完善我的信息，這些也都是能夠算的。再好比映客（直播類的），用戶只要打開看了某段視頻，搜索了某些關鍵詞，給某個視頻評論點讚了，也都算是活躍。因此確實產品不一樣，定義維度也不一樣，迴歸到產品戰略上，用戶發生的這些行爲是否是產品設計時想要的，用戶哪些參與行爲是有效的，那麼，有效的這些行爲每每都是屬於活躍行爲。

也就是區分活躍用戶和不活躍用戶。活躍用戶的幾個屬性：

1. 用戶最後一次發帖的時間
2. 用戶最後一次登陸的時間
3. 用戶只查看不發帖
4. 用戶今天是否在線

如何衡量用戶今日是否在線？須要找一個定義標準：用戶今日瀏覽過、或者用戶今日登錄過。本質上說就是找到一個：用戶今日有過與APP交互的動做。

總結：

文中信息流和時間流混用，可是表示的是同一個意思。簡單介紹了我對時間流的見解（只是我我的的認識，不知道微博具體是如何實現的）。你們認真看完了的話，就趕忙評論互噴起來吧。

文章爲原創，轉載請註明連接地址。以爲有幫助的話，不妨打個賞吧!

參考文章：

1. 冷數據、溫數據、熱數據，難道數據也是有溫度的？
2. 淺談如何定義活躍用戶