今天Redis教學欄位一起看看如何實作feed流
1 簡介
朋友圈，微博，都是Feed 流產品，還有圖片分享網站Pinterest，花瓣網等又是另一種形式的Feed 流產品。很多 App 也會有一個模組，叫做動態或訊息廣場，這些也是 Feed 流產品。
核心概念
- Feed
Feed 流中的每一則狀態或訊息。例如朋友圈中的一個狀態就是一個 Feed，微博中的一條微博就是一個 Feed。
- Feed 流
持續更新並呈現給使用者內容的資訊流。每個人的朋友圈，微博關注頁等等都是一個 Feed 流。
- Timeline
Feed 流的一種，微博，朋友圈都是Timeline 類型的Feed 流，但由於Timeline 類型出現最早，使用最廣泛，最為人熟知，有時也用Timeline 表示Feed流。
- 追蹤頁 Timeline
展示其他人 Feed 訊息的頁面，例如朋友圈，微博首頁。
- 個人頁 Timeline
展示自己發送過的 Feed 訊息的頁面，例如微信中的相冊，微博的個人頁。
2 特點
- 多帳號內容流
Feed 流系統中肯定會存在成千上萬的帳號，帳號之間可以關注，取關，加好友和拉黑等操作。只要滿足這條，那麼就可以當做 Feed 流系統來設計。
- 非穩定的帳號關係
由於存在關注，取關等操作，所以系統中的使用者之間的關係就會一直在變化，是一種非穩定的狀態。
- 讀寫比例 100:1
讀寫嚴重不平衡，讀多寫少，一般讀寫比例在 10：1，甚至 100：1 以上。
- 訊息必達性要求高
例如發送了一條朋友圈後，結果部分朋友看到了，部分朋友沒看到，如果偏偏女朋友沒看到，那麼可能會產生很嚴重的感情矛盾，後果很嚴重。
3 分類
- Timeline
依照發布的時間順序排序，先發布的先看到，後發布的排列在最頂端，類似微信朋友圈，微博等。這也是一種最常見的形式。產品如果選擇 Timeline 類型，那就是認為Feed流中的Feed不多，但是每個Feed都很重要，都需要使用者看到。
- Rank
依照某個非時間的因子排序，一般是依照使用者的喜好度排序，使用者最喜歡的排在最前面，次喜歡的排在後面。這種一般假定用戶可能看到的Feed 非常多，而用戶花費在這裡的時間有限，那麼就為用戶選擇出用戶最想看的Top N 結果，場景的應用場景有圖片分享、新聞推薦類、商品推薦等。
4 困難
4.1 儲存
因為該專案中Feed 比較簡單，就類比於空間說說，因此可以使用MySQL存儲，如果對於資料結構比較複雜的Feed 流就要使用NoSQL 資料庫，這樣存儲更方便與高效，例如MongoDB 或HBase。
4.2 推送
在推送方案裡面的，有三種方案，分別是：
拉模式
又稱讀取擴散，使用者主動去拉取追蹤人的Feed 內容。
即當一個使用者（特別是追蹤了很多人）觸發行為時，拉取自己動態，檢索使用者的關注表，然後根據關注表檢索新發的feed。如果用戶關注過多的時候，查詢該用戶的關注清單也是有很大數據成本。
推模式
也變成寫入擴散，當使用者加入 Feed 時，會自動將 Feed 通知給追蹤的人（優選）。
即當一個使用者觸發行為（例如發微博），自身行為記錄到行為表中，同時也對應到這個使用者的粉絲表，為每個粉絲插入一條feed。但對於粉絲過萬的大V，為每個粉絲插入一條feed對儲存資料成本很大。
使用Redis Sorted Sets（方便按時間排序Timeline）維護粉絲的Feed 集合，當部落客加入Feed 時，主動將內容推送到粉絲的Feed 集合中，讓使用者可以很方便快速從集合中讀取
推拉結合
例如微博，大部分用戶的帳號關係都是幾百個，但是有個別用戶是1000萬以上才使用。
線上推，離線拉
- When big V posts news, they will only publish the news to fans who are online at the same time. Offline fans will pull the news after they come online. to complete push and pull.
Regular push, offline pull
After the big V posts the update, it will be pushed to the fan update table regularly in the form of a resident process.
5 Table Design
##Recommended (free): redis tutorial
以上是Redis如何實現feed串流的詳細內容。更多資訊請關注PHP中文網其他相關文章！
