關於類微博的timeline的設計思考
SNS網站中，一個很基本的功能就是timeline。用戶在自己的主頁可以看到其關注的所有用戶發表的信息列表，其它用戶可以在他的個人主頁看到這個人發佈的信息列表。
這時候我們常常有兩種模式，推模式和拉模式。
推模式：我們通常用redis來實現此模式，思路是，每個用戶保存一個他關注的所有人的feed存儲流。
推模式結構圖
比如用戶A有100個粉絲，當用戶A發表一條feed時，我們需要去獲取用戶A的粉絲列表，然後把該feed逐一添加到每個粉絲的feeds表中。
優點：這是空間換時間的思路，因爲給每個用戶保存自己關注的所有人的feed，需要耗費大量的空間，但這樣用戶查詢相關feed時，速度更快。
缺點：
如果用戶A有百萬級的粉絲，那麼每次用戶A發表一條smg，我們就需要插入百萬條數據，如果這樣的用戶來多幾個，這對系統會有極大的壓力。當然，如果用戶A把自己的這條msg刪除，那系統也需要把用戶A的所有粉絲的數據存儲中的這條msg刪除。
拉模式：每個用戶保存一個自己的feed表，該表保存關於自己的所有feed，比如用戶A在自己的微博上發表了100條說說，那麼他的feed表就會有100條feed記錄。用戶登錄主頁的時候，抓取他關注的其他用戶的feed列表（feed表可以是一個臨時表，只保存近期可接受範圍的數據)，然後把這些feeds進行merge。
拉模式結構圖
優點：邏輯簡單。
缺點：
一，如果用戶A的粉絲很多，數據庫壓力會很大，因爲粉絲量大表明會有粉絲不斷的拉取他的feed表。我們可以把用戶的feed存入redis中，粉絲拉取他的feed時直接去redis中獲取，這樣速度會快很多。
二，一個用戶發的消息越來越多，用戶的消息列表數據會越來越長，這時候merge一個用戶關注的其他用戶的信息過程會耗時非常長，而且消息列表數據長的時候，大數據網絡傳輸也會特別耗時。這個問題是數據庫存儲和redis存儲都會有的。解決方法可以考慮，在redis中爲每個用戶存儲當天的feed列表，這樣就可以細化數據的粒度，減少每次取數據的數據量。如果數據量不夠，可以考慮再抓取之前的數據。這種分片的思想，可以減少每次抓取的數據量，減小merge的耗時和網絡數據傳輸耗時。