關於APP的架構實現！微博和知乎中的 feed 流是如何實現的？
引自：https://www.zhihu.com/question/19645686/answer/85075806?from=profile_answer_cardphp
微博和知乎中的 feed 流是如何實現的？
在微博中每一個人關注的人會成百上千，在知乎上關注了人還關注話題關注特定主題，這些feed的輸出，如何能有效下降系統查詢負載，特別是知乎上feed流的結果還須要特定排序。不知道這些都是如何優化的，可否指點一二？
按投票排序按時間排序
6 個回答
簡單來講，Feeds這塊主要包括兩塊內容，就是生成feeds和更新feeds。生成feeds是什麼意思呢，好比咱們已經關注的人作了特定操做，咱們須要把這些活動加入你的feeds，讓你接收到。更新feeds包括的內容比較多，一種就是你關注點作了更新，好比你新關注了一我的，須要把他的活動加入已有feeds，與此相似，取消關注也同樣；另外一種就是你的關注點作了一些更新操做，好比你關注的一我的取消關注了一個問題。
咱們先來談feeds生成，用戶A作了某操做，好比關注了一個問題，這時候咱們首先找到用戶A的全部關注者，而後給須要推送的關注者推送此操做，你們能夠把每一個人的feeds簡單想象爲一個有序列表，推送很簡單，就是在每一個人的列表末尾添加這個操做。怎麼樣，是否是很簡單，:)
而後咱們談feeds更新，第一種狀況和第二種狀況其實都是同樣的，咱們須要針對這些活動更新來更新feeds，好比咱們新關注了一我的，這時候咱們須要取出此人的活動歷史，而後按照時間順序把這些歷史塞到你的feeds中。此操做的複雜度會比較高，須要使用合適的數據結構來達到最佳性能，目前是O(log(N))。
固然，真實狀況並無這麼簡單，還有不少其餘邏輯和注意點，好比咱們的feeds須要對多人作一樣的操做作合併（你們能夠自行把以上的feeds有序列表變爲有序集合），一樣的內容的建立時間是要按最新操做的時間來計算的，一我的連續作不少操做須要對操做作合併等。全部你們看到的feeds相應的存儲考慮到性能都會使用內存，除此以外全部的操做都須要作持久化存儲，不然咱們也就無法更新feeds了:)
下面咱們談談這裏面的技術挑戰和相關技術，此部分與知乎目前的技術決策和使用技術無關，我給你們分享幾個國外團隊的工程決策和他們的優化手段。
先來談談strava，他們使用了Kafka分佈式發佈訂閱消息系統，這個系統用來事件(event)發佈，還使用了Storm分佈式實時計算平臺，這個計算集羣會訂閱Kafka的事件，而後完成相應的處理，在這塊他們作了一個優化，就是一個事件不會推給全部關注者，只會推給活躍的用戶（如何斷定一個用戶爲活躍的，這就看實際狀況和數據本身優化了）。
而後再來談談Instagram，他們產品的讀寫比例達到了100：1，事實上大部分互聯網產品都是這樣，因此這也是推技術更合適的緣由，推一次開銷可能大一點，不過推（也就是寫）發生次數大大少於讀，由於有些大牛關注者很是多，達到幾百上千萬，爲了進行可靠地推，這個過程都會異步後臺執行。一樣，咱們須要一個任務調度器和消息隊列，任務調度他們選用了Celery，下面須要選擇一個消息隊列，Redis依賴訂閱者輪詢，不自帶複製備份，並且強依賴內存是個硬傷，不合適；Beanstalk其餘方面不錯，可仍是不支持複製(Replication)，棄掉；最後他們選用了RabbitMQ，快，高效，支持複製，並且和Celery高度兼容。
接着談談Pinterest，重心在於建立一個智能化的feed，也就是feed會包括一些熱點和推薦，並且會根據特定算法來排序。當事件發生後，會通過一系列流程最後才進入用戶的內容feed，首先通過智能feed worker來處理，這些worker會接收事件並且根據特定用戶給事件打分，而後這些事件會被插入到一個排好序的feed池中，不一樣類型的事件會被插入各自的池中，目前他們使用HBase的基於key的排序實現了此優先隊列，接着智能feed內容生成器接手了，它會從幾個池中根據策略取出feeds甚至剔除一些feeds，最後面向用戶的智能feed服務會整合舊的feed和新生成的feed，展示給用戶看到的Home Feeds。
最後簡單談談Facebook，用戶量大了以後對工程團隊要求會更高，每一個facebook用戶都會有一個屬於本身的獨一無二的動態生成的首頁。不少團隊都會用用戶ID爲Key來把feeds存入Key-Value存儲系統，好比Redis，問題是經過網絡鏈接作遠程過程調用很是慢，沒法知足實時性的要求，因此facebook團隊也開始使用了嵌入式數據庫，他們也開源了本身在用的 RocksDB。
這些內容都在他們的技術博客裏面有提到，連接在這裏：
Strava Engineering
How Instagram Feeds Work: Celery and RabbitMQ
Making Pinterest
https://www.facebook.com/notes/10151822347683920/
就像電影特效是爲劇情服務同樣，技術是爲產品服務的。針對不一樣的業務場景，適合的技術也是不同的。隨着產品的調整和業務規模的擴大，相應的技術都會作進化和調整。針對不一樣的難題，須要提出不一樣的技術方案，feeds的生成也是這樣，若是有必要，咱們也會對這些方案作調整，目的都是同樣，那就是又對又快又穩定。
若是有什麼錯誤，但願大神指出。若是有更好的方案或者建議，歡迎交流。
咱們先來談feeds生成，用戶A作了某操做，好比關注了一個問題，這時候咱們首先找到用戶A的全部關注者，而後給須要推送的關注者推送此操做，你們能夠把每一個人的feeds簡單想象爲一個有序列表，推送很簡單，就是在每一個人的列表末尾添加這個操做。怎麼樣，是否是很簡單，:)
而後咱們談feeds更新，第一種狀況和第二種狀況其實都是同樣的，咱們須要針對這些活動更新來更新feeds，好比咱們新關注了一我的，這時候咱們須要取出此人的活動歷史，而後按照時間順序把這些歷史塞到你的feeds中。此操做的複雜度會比較高，須要使用合適的數據結構來達到最佳性能，目前是O(log(N))。
固然，真實狀況並無這麼簡單，還有不少其餘邏輯和注意點，好比咱們的feeds須要對多人作一樣的操做作合併（你們能夠自行把以上的feeds有序列表變爲有序集合），一樣的內容的建立時間是要按最新操做的時間來計算的，一我的連續作不少操做須要對操做作合併等。全部你們看到的feeds相應的存儲考慮到性能都會使用內存，除此以外全部的操做都須要作持久化存儲，不然咱們也就無法更新feeds了:)
下面咱們談談這裏面的技術挑戰和相關技術，此部分與知乎目前的技術決策和使用技術無關，我給你們分享幾個國外團隊的工程決策和他們的優化手段。
先來談談strava，他們使用了Kafka分佈式發佈訂閱消息系統，這個系統用來事件(event)發佈，還使用了Storm分佈式實時計算平臺，這個計算集羣會訂閱Kafka的事件，而後完成相應的處理，在這塊他們作了一個優化，就是一個事件不會推給全部關注者，只會推給活躍的用戶（如何斷定一個用戶爲活躍的，這就看實際狀況和數據本身優化了）。
而後再來談談Instagram，他們產品的讀寫比例達到了100：1，事實上大部分互聯網產品都是這樣，因此這也是推技術更合適的緣由，推一次開銷可能大一點，不過推（也就是寫）發生次數大大少於讀，由於有些大牛關注者很是多，達到幾百上千萬，爲了進行可靠地推，這個過程都會異步後臺執行。一樣，咱們須要一個任務調度器和消息隊列，任務調度他們選用了Celery，下面須要選擇一個消息隊列，Redis依賴訂閱者輪詢，不自帶複製備份，並且強依賴內存是個硬傷，不合適；Beanstalk其餘方面不錯，可仍是不支持複製(Replication)，棄掉；最後他們選用了RabbitMQ，快，高效，支持複製，並且和Celery高度兼容。
接着談談Pinterest，重心在於建立一個智能化的feed，也就是feed會包括一些熱點和推薦，並且會根據特定算法來排序。當事件發生後，會通過一系列流程最後才進入用戶的內容feed，首先通過智能feed worker來處理，這些worker會接收事件並且根據特定用戶給事件打分，而後這些事件會被插入到一個排好序的feed池中，不一樣類型的事件會被插入各自的池中，目前他們使用HBase的基於key的排序實現了此優先隊列，接着智能feed內容生成器接手了，它會從幾個池中根據策略取出feeds甚至剔除一些feeds，最後面向用戶的智能feed服務會整合舊的feed和新生成的feed，展示給用戶看到的Home Feeds。
最後簡單談談Facebook，用戶量大了以後對工程團隊要求會更高，每一個facebook用戶都會有一個屬於本身的獨一無二的動態生成的首頁。不少團隊都會用用戶ID爲Key來把feeds存入Key-Value存儲系統，好比Redis，問題是經過網絡鏈接作遠程過程調用很是慢，沒法知足實時性的要求，因此facebook團隊也開始使用了嵌入式數據庫，他們也開源了本身在用的 RocksDB。
這些內容都在他們的技術博客裏面有提到，連接在這裏：
Strava Engineering
How Instagram Feeds Work: Celery and RabbitMQ
Making Pinterest
https://www.facebook.com/notes/10151822347683920/
就像電影特效是爲劇情服務同樣，技術是爲產品服務的。針對不一樣的業務場景，適合的技術也是不同的。隨着產品的調整和業務規模的擴大，相應的技術都會作進化和調整。針對不一樣的難題，須要提出不一樣的技術方案，feeds的生成也是這樣，若是有必要，咱們也會對這些方案作調整，目的都是同樣，那就是又對又快又穩定。
若是有什麼錯誤，但願大神指出。若是有更好的方案或者建議，歡迎交流。
恰好最近想寫一個Feed機制的文章，就來回答一下吧。
樓上各位其實把大致的狀況都已經說的很明白了，我來分享一下咱們目前線上一個feed實現機制，已經在生產環境運行了大半年。理論來講，百萬級別用戶沒有什麼問題。
爲了節省你們流量，全程無圖（實際上是我懶得畫 - - ），但願你們能把省下的流量錢來給我發紅包，鼓掌 。
首先，拋去數據庫這一塊，數據庫我想你們確定知道怎麼設計，可是查詢確定是個麻煩事， 因此我使用了redis進行一個冗餘設計，開始介紹以前，須要瞭解什麼是推拉模式，樓上說的兩篇文章 新浪微博架構和FEED架構分析--人人架構_paper0023_新浪博客 ，還有推拉模式以及時間分區拉模式的分析 微博feed系統的推(push)模式和拉(pull)模式和時間分區拉模式架構探討 其實已經足夠了解了，請各位看官若是未對推拉模式瞭解，那麼請先看文章，再來看個人回答，個人回答只是闡述具體實現，謝謝。
那麼我如今說一下redis這塊怎麼來完成推拉模式，以及內存儘量節省，速度儘量提升吧（固然，只是我理解的節省內存跟速度提升，若是看官們有其餘的意見，我就兩點要求，1、輕噴，2、說完再噴）。
一、實現
首先，先解決發佈跟接收的問題，目前有大致如下幾種方式：
一、推模式
什麼是推模式？推模式就是，用戶A關注了用戶B，用戶B每發送一個動態，後臺遍歷用戶B的粉絲，往他們粉絲的feed裏面推送一條動態。
二、拉模式
與推模式相反，拉模式則是，用戶每次刷新feed第一頁，都去遍歷關注的人，把最新的動態拉取回來。
可是，無論推模式仍是拉模式都存在若關注數量或者粉絲數量過多，致使遍歷時間太長的問題，怎麼去解決 ？這裏就出現了第三種模式，推拉模式。
三、推拉模式
這是一種折中的解決方案，就是在線推，離線拉。粉絲幾百上千萬， 跟你發佈動態同時在線的確定也就只有那麼頂天幾百幾千幾萬，況且這類大V不多，只推給在線的粉絲，離線的粉絲上線後，再去拉取動態便可！可是，無論是什麼模式，每一個用戶都會維護一個相似發件箱跟收件箱的東西，保存本身發過的動態以及Feed動態（具體實現看下面），來完成推與拉。
而這裏講的，確定就是推拉模式，用戶A關注了用戶B ， 用戶B發佈動態則將動態推動用戶A的feed，這裏使用redis的zset實現，sort爲time（記得以毫秒爲時間戳，秒級在數據量達到必定程度後，會有讀取不到的問題，好比以時間戳爲分頁頁碼），value爲具體的動態 ID（爲何是動態ID， 其實很簡單， 就是由於動態的內容能夠進行緩存，在redis裏面所有走ID，修改動態內容也須要修改一處，動態內容能夠保存在hash結構裏）， 每一個用戶維護一個zset保存我發佈的動態，一個zset保存個人feed動態，過時時間3~7天看狀況而定。爲何要設計過時時間後面會細說。
OK，全局維護一個在線用戶列表，怎麼設計這個就本身琢磨了，爲了防止用戶掛後臺致使與服務端爲離線狀態，因此最好是1~3小時未操做或者離線時間不大於3小時的，都當作在線處理，反正這個看狀況定。
那麼，當用戶發了一條動態後，後臺會有如下這些操做：
在線推： 異步遍歷在線的粉絲，將動態ID，添加到粉絲的Feed中。
離線拉： 離線用戶打開APP後，咱們是會請求一個公共的入口接口，主作統計以及其餘初始化操做，在這裏，咱們也開了一個異步線程，對用戶進行Feed更新操做，防止用戶進入APP後等待拉取時間過長，畢竟關注成千上萬的人確定有（其實萬單位如下遍歷都很快）。拉取過程其實就是把本身最後一條Feed的時間戳取出，去遍歷關注的人的feed，將大於該時間的ID所有拉取回來。用戶進入APP後，刷新便可看到最新操做。
另：若是有Feed新消息數提示的需求，能夠在推拉的同時進行增長， 刷新feed時清空便可。
其實到這裏，發佈接收的問題已經解決了，那麼有一個問題，用戶feed裏面過長，佔用內存怎麼辦？
我是這麼處理的，一個用戶的feed第一次拉取的時候，feed長度爲500條，在咱們APP裏，至關於50頁，然後的數據，都走數據庫。大頁碼翻頁其實就是個僞需求並且耗性能的東西，用戶除了第一次用這個APP，纔會翻到底，第一次使用， 能有幾個動態 ？而對於二次使用以上的用戶，通常來說， 翻了幾頁就已經到達上一次看過的地方了，因此500條數據，在關注量通常的狀況下，內容已經足夠消費，甚至達到疲勞，可能有關注量很大的用戶他的Feed天天可能有不少不少動態，可是，不用說，確定是作廣告的，關注一堆人等着回粉，這種人更不會去消費內容，50頁的內容，翻起來都累。固然，並非說放棄了這些人，feed找不到走數據庫嘛~~~~愛走不走，想走就給我翻50頁再說~
還有一個問題，每一個用戶都維護本身的動態跟Feed隊列，當用戶上百萬時，內存的佔有量確定不小，要怎麼釋放內存才合適 ？
這裏就回到上面那個問題了，爲何要給feed的key設計過時時間？爲何是設計3~7天過時時間？
緣由有如下：
1、一個用戶3~7天不打開APP，可能已經對APP失去興趣了，打開概率很小，或者已經被卸載了，沒有存在的意義了。
2、3~7天未登錄APP，關注的人發的動態也很多了，Feed未拉取回來的數據確定也很多，那麼這時候去遍歷其實拉取量很大，那麼還不如直接所有從新拉一邊或者拉取用戶最後登錄時間後產出的數據。
到這裏，其實已經差很少了，大部分業務邏輯已經足夠知足，而且速度也理想，目前咱們線上這種模式走了半年，feed通常都是10~80ms響應完畢。
好了，大概就是這樣了。
最後說一句：
<?php
echo 'php 是世界上最好的語言！！！';
?>
樓上各位其實把大致的狀況都已經說的很明白了，我來分享一下咱們目前線上一個feed實現機制，已經在生產環境運行了大半年。理論來講，百萬級別用戶沒有什麼問題。
爲了節省你們流量，全程無圖（實際上是我懶得畫 - - ），但願你們能把省下的流量錢來給我發紅包，鼓掌 。
首先，拋去數據庫這一塊，數據庫我想你們確定知道怎麼設計，可是查詢確定是個麻煩事， 因此我使用了redis進行一個冗餘設計，開始介紹以前，須要瞭解什麼是推拉模式，樓上說的兩篇文章 新浪微博架構和FEED架構分析--人人架構_paper0023_新浪博客 ，還有推拉模式以及時間分區拉模式的分析 微博feed系統的推(push)模式和拉(pull)模式和時間分區拉模式架構探討 其實已經足夠了解了，請各位看官若是未對推拉模式瞭解，那麼請先看文章，再來看個人回答，個人回答只是闡述具體實現，謝謝。
那麼我如今說一下redis這塊怎麼來完成推拉模式，以及內存儘量節省，速度儘量提升吧（固然，只是我理解的節省內存跟速度提升，若是看官們有其餘的意見，我就兩點要求，1、輕噴，2、說完再噴）。
一、實現
首先，先解決發佈跟接收的問題，目前有大致如下幾種方式：
一、推模式
什麼是推模式？推模式就是，用戶A關注了用戶B，用戶B每發送一個動態，後臺遍歷用戶B的粉絲，往他們粉絲的feed裏面推送一條動態。
二、拉模式
與推模式相反，拉模式則是，用戶每次刷新feed第一頁，都去遍歷關注的人，把最新的動態拉取回來。
可是，無論推模式仍是拉模式都存在若關注數量或者粉絲數量過多，致使遍歷時間太長的問題，怎麼去解決 ？這裏就出現了第三種模式，推拉模式。
三、推拉模式
這是一種折中的解決方案，就是在線推，離線拉。粉絲幾百上千萬， 跟你發佈動態同時在線的確定也就只有那麼頂天幾百幾千幾萬，況且這類大V不多，只推給在線的粉絲，離線的粉絲上線後，再去拉取動態便可！可是，無論是什麼模式，每一個用戶都會維護一個相似發件箱跟收件箱的東西，保存本身發過的動態以及Feed動態（具體實現看下面），來完成推與拉。
而這裏講的，確定就是推拉模式，用戶A關注了用戶B ， 用戶B發佈動態則將動態推動用戶A的feed，這裏使用redis的zset實現，sort爲time（記得以毫秒爲時間戳，秒級在數據量達到必定程度後，會有讀取不到的問題，好比以時間戳爲分頁頁碼），value爲具體的動態 ID（爲何是動態ID， 其實很簡單， 就是由於動態的內容能夠進行緩存，在redis裏面所有走ID，修改動態內容也須要修改一處，動態內容能夠保存在hash結構裏）， 每一個用戶維護一個zset保存我發佈的動態，一個zset保存個人feed動態，過時時間3~7天看狀況而定。爲何要設計過時時間後面會細說。
OK，全局維護一個在線用戶列表，怎麼設計這個就本身琢磨了，爲了防止用戶掛後臺致使與服務端爲離線狀態，因此最好是1~3小時未操做或者離線時間不大於3小時的，都當作在線處理，反正這個看狀況定。
那麼，當用戶發了一條動態後，後臺會有如下這些操做：
在線推： 異步遍歷在線的粉絲，將動態ID，添加到粉絲的Feed中。
離線拉： 離線用戶打開APP後，咱們是會請求一個公共的入口接口，主作統計以及其餘初始化操做，在這裏，咱們也開了一個異步線程，對用戶進行Feed更新操做，防止用戶進入APP後等待拉取時間過長，畢竟關注成千上萬的人確定有（其實萬單位如下遍歷都很快）。拉取過程其實就是把本身最後一條Feed的時間戳取出，去遍歷關注的人的feed，將大於該時間的ID所有拉取回來。用戶進入APP後，刷新便可看到最新操做。
另：若是有Feed新消息數提示的需求，能夠在推拉的同時進行增長， 刷新feed時清空便可。
其實到這裏，發佈接收的問題已經解決了，那麼有一個問題，用戶feed裏面過長，佔用內存怎麼辦？
我是這麼處理的，一個用戶的feed第一次拉取的時候，feed長度爲500條，在咱們APP裏，至關於50頁，然後的數據，都走數據庫。大頁碼翻頁其實就是個僞需求並且耗性能的東西，用戶除了第一次用這個APP，纔會翻到底，第一次使用， 能有幾個動態 ？而對於二次使用以上的用戶，通常來說， 翻了幾頁就已經到達上一次看過的地方了，因此500條數據，在關注量通常的狀況下，內容已經足夠消費，甚至達到疲勞，可能有關注量很大的用戶他的Feed天天可能有不少不少動態，可是，不用說，確定是作廣告的，關注一堆人等着回粉，這種人更不會去消費內容，50頁的內容，翻起來都累。固然，並非說放棄了這些人，feed找不到走數據庫嘛~~~~愛走不走，想走就給我翻50頁再說~
還有一個問題，每一個用戶都維護本身的動態跟Feed隊列，當用戶上百萬時，內存的佔有量確定不小，要怎麼釋放內存才合適 ？
這裏就回到上面那個問題了，爲何要給feed的key設計過時時間？爲何是設計3~7天過時時間？
緣由有如下：
1、一個用戶3~7天不打開APP，可能已經對APP失去興趣了，打開概率很小，或者已經被卸載了，沒有存在的意義了。
2、3~7天未登錄APP，關注的人發的動態也很多了，Feed未拉取回來的數據確定也很多，那麼這時候去遍歷其實拉取量很大，那麼還不如直接所有從新拉一邊或者拉取用戶最後登錄時間後產出的數據。
到這裏，其實已經差很少了，大部分業務邏輯已經足夠知足，而且速度也理想，目前咱們線上這種模式走了半年，feed通常都是10~80ms響應完畢。
好了，大概就是這樣了。
最後說一句：
<?php
echo 'php 是世界上最好的語言！！！';
?>
先不考慮數據的物理分佈，僅討論下業務的設計。
有三種基本思路：
思路1，產生的全部動態，都在同一條索引上，上面承載全部的更新，以及讀取。每一個用戶都有本身的filter規則，這個規則包括「屏蔽了誰，關注了誰，屏蔽了哪一個問題」。
用戶在讀取feeds，即是使用本身的filter，按照時間順序，從頭遍歷這個索引，直到獲得足夠的條目。
優勢：業務邏輯上是最清晰，性能穩定。
缺點：技術難度最大。
思路2，讀擴散。
每一個人有本身產生的feeds隊列，打開本身的首頁時，按照本身的關注列表和屏蔽規則，去讀取其餘用戶的feeds隊列，而後彙總、排序。
優勢：實現最簡單，關注列表 敏感性最高。
缺點：性能最差，並且差的很穩定。
思路3，寫擴散。
每一個人有本身的產生的feeds隊列和 待讀取的feeds隊列。每一個用戶產生動態時，壓入到關注者的 待讀取feeds隊列，壓入前，須要根據屏蔽規則來判斷下是否要壓入。
優勢：每一個用戶頁面打開的速度是最快的，性能最高。
缺點：關注列表變化時，敏感度略低，但讀取隊列的時候，再根據規則過濾一遍，也沒啥太大問題。
我的推薦：思路1 。
根據我的的簡單猜想， 知乎的首頁，貌似是 思路3+思路2 。
猜想的理由：
1-當我取關時，刷新，頁面還會有這個用戶的動態，因此 思路3的可能性很大。
2-當我新關注一我的，刷新，頁面上會有這個用戶的動態，可能針對最近產生的關注行爲作了特殊處理，少許的作了讀擴散。
3-B關注了A。若是A帳號產生一條動態，好比 贊同，而後再取消贊同。此時A帳號的 所有動態 中，是沒有剛纔的贊同記錄的，可是在 B 的首頁上，仍是會有 A 的贊同行爲。
-----------------------
update at 2014-12-08
我今天偶然的發現，我關注的某些人的回答，是沒有出如今個人首頁的。
我反覆對比過，估計 大概是4天前的四、5條動態，沒有出如今個人首頁。
根據這個現象，知乎的首頁應該是 寫擴散更多些。
並且，在寫擴散的時候，貌似寫失敗了，就拉倒了。
有三種基本思路：
思路1，產生的全部動態，都在同一條索引上，上面承載全部的更新，以及讀取。每一個用戶都有本身的filter規則，這個規則包括「屏蔽了誰，關注了誰，屏蔽了哪一個問題」。
用戶在讀取feeds，即是使用本身的filter，按照時間順序，從頭遍歷這個索引，直到獲得足夠的條目。
優勢：業務邏輯上是最清晰，性能穩定。
缺點：技術難度最大。
思路2，讀擴散。
每一個人有本身產生的feeds隊列，打開本身的首頁時，按照本身的關注列表和屏蔽規則，去讀取其餘用戶的feeds隊列，而後彙總、排序。
優勢：實現最簡單，關注列表 敏感性最高。
缺點：性能最差，並且差的很穩定。
思路3，寫擴散。
每一個人有本身的產生的feeds隊列和 待讀取的feeds隊列。每一個用戶產生動態時，壓入到關注者的 待讀取feeds隊列，壓入前，須要根據屏蔽規則來判斷下是否要壓入。
優勢：每一個用戶頁面打開的速度是最快的，性能最高。
缺點：關注列表變化時，敏感度略低，但讀取隊列的時候，再根據規則過濾一遍，也沒啥太大問題。
我的推薦：思路1 。
根據我的的簡單猜想， 知乎的首頁，貌似是 思路3+思路2 。
猜想的理由：
1-當我取關時，刷新，頁面還會有這個用戶的動態，因此 思路3的可能性很大。
2-當我新關注一我的，刷新，頁面上會有這個用戶的動態，可能針對最近產生的關注行爲作了特殊處理，少許的作了讀擴散。
3-B關注了A。若是A帳號產生一條動態，好比 贊同，而後再取消贊同。此時A帳號的 所有動態 中，是沒有剛纔的贊同記錄的，可是在 B 的首頁上，仍是會有 A 的贊同行爲。
-----------------------
update at 2014-12-08
我今天偶然的發現，我關注的某些人的回答，是沒有出如今個人首頁的。
我反覆對比過，估計 大概是4天前的四、5條動態，沒有出如今個人首頁。
根據這個現象，知乎的首頁應該是 寫擴散更多些。
並且，在寫擴散的時候，貌似寫失敗了，就拉倒了。
早在人人火了，UChome出來的時候你們就在研究各類feed流的實現，到微博這會兒應該已經沒啥人在討論了，各類推和拉模式，網上搜搜就知道了。
關於排序又是另外一個問題了，這個方面你們都在探索吧。
（我的觀點不表明公司立場）
關於排序又是另外一個問題了，這個方面你們都在探索吧。
（我的觀點不表明公司立場）
這裏看到一篇新浪微博作的技術分享，值得一看。雖然沒有太多的技術實現細節，不過大的框架已經說明的差很少了。仍是好幾年前的分享，如今應該架構變化又大了不少，不過一個小網站參考的話，這些已經足夠了。
新浪微博架構和FEED架構分析--人人架構_paper0023_新浪博客
另一篇，一名網友對推拉模式以及時間分區拉模式的分析 微博feed系統的推(push)模式和拉(pull)模式和時間分區拉模式架構探討
另一篇，一名網友對推拉模式以及時間分區拉模式的分析 微博feed系統的推(push)模式和拉(pull)模式和時間分區拉模式架構探討
相關文章
- 1. 經常使用Feed流架構實現
- 2. Python爬取微博和知乎熱榜的簡單實現
- 3. 如何實現微服務架構中的服務發現？
- 4. 如何實現微服務架構中的服務發現
- 5. 新浪微博RSS Feed實現中的問題
- 6. 探討微博時間流的實現
- 7. 唯品會架構師是如何實現架構重構的
- 8. 惟品會架構師是如何實現架構重構的
- 9. 基於node.js的微博博客實現
- 10. 如何實現微服務架構
- 更多相關文章...
- • 現實生活中的 XML - XML 教程
- • 使用Redis和Lua的原子性實現搶紅包功能 - 紅包項目實戰
- • ☆基於Java Instrument的Agent實現
- • Spring Cloud 微服務實戰(三) - 服務註冊與發現
相關標籤/搜索
每日一句
-
每一个你不满意的现在，都有一个你没有努力的曾经。
最新文章
- 1. 外部其他進程嵌入到qt FindWindow獲得窗口句柄 報錯無法鏈接的外部符號 [email protected] 無法被([email protected]@[email protected]@@引用
- 2. UVa 11524 - InCircle
- 3. The Monocycle（bfs）
- 4. VEC-C滑窗
- 5. 堆排序的應用-TOPK問題
- 6. 實例演示ElasticSearch索引查詢term,match,match_phase,query_string之間的區別
- 7. 數學基礎知識 集合
- 8. amazeUI 復擇框問題解決
- 9. 揹包問題理解
- 10. 算數平均-幾何平均不等式的證明,從麥克勞林到柯西
歡迎關注本站公眾號,獲取更多信息
相關文章
- 1. 經常使用Feed流架構實現
- 2. Python爬取微博和知乎熱榜的簡單實現
- 3. 如何實現微服務架構中的服務發現？
- 4. 如何實現微服務架構中的服務發現
- 5. 新浪微博RSS Feed實現中的問題
- 6. 探討微博時間流的實現
- 7. 唯品會架構師是如何實現架構重構的
- 8. 惟品會架構師是如何實現架構重構的
- 9. 基於node.js的微博博客實現
- 10. 如何實現微服務架構