微博feed系統的push和pull模式和時間分區拉模式架構探討
關於如何構建一個微博型廣播最後這篇文章寫得很不錯的，也基本講清楚了Feed系統的方方面面的考慮了，基本涉及到了一個Feed系統從小發展到大的全過程了！還沒有完全領會到它爲用Cassandra替換Redis的理由，或者他還是考慮把Casandra的作爲半緩存的結構來替換的，加大Cassandr的內存，可以緩存大量的熱數據，當然它的好處是冷熱數據都可以完美的持久化，但是數據的一致性處理起來有些麻煩，毫無疑問他會是採用R+W>N的模式，但是無論寫多份還是讀多份都是有些難於取捨的，Feed系統的寫入量本來就很大，如果寫入多份的話會大大降低寫入的性能，另外，存在Feed的系統，無一例外的是Feed都會是全系統的核心，提高讀的性能會大大提高用戶的體驗，如果讀取的時候讀多份數據會相對降低性能，到底取捨哪一個呢？我這裏光是憑空想象，無法取捨，具體還可以看性能測試來說法，如果有同學做過這方面的壓測，還望留言告知下！
騰訊微博主要使用拉模型，只有未讀的微博數是使用推得模式實現的！拉模型的問題在於一個人跟隨了幾百或者上千的人的時候，去看關注的人所發的消息要進行多個層次的Map/Reduce才能得到結果，需要非常高效的獲取最新Feed的方式以及快速的聚合算法，只用Memcache\Redis之類的從性能上是比較難於實現的，需要從數據層面或者是緩存的層面都進行聚合，再在應用層面進行聚合，技術難度比較大！這個模式屬於知易行難，絕大多數公司不具備構建這種基礎設施的能力！
新浪微博使用推拉結合的方式，大號不推送，小號則推送，看Feeds的時候，需要將推過來的Feeds索引數據與關注的大號的Feed進行聚合，小小的犧牲下拉的性能，不過一下子就將大號的推送問題解決掉了！
對於稍微小些的網站，比如Pinterest和花瓣都使用推的方式來實現，PInterest的直接在Redis中保存500個最新的索引信息，使用Python腳本定時來掃描，保證緩存的索引信息始終只保存最新的500個，老的信息則直接丟棄掉，花瓣則將老索引存儲到LevelDB中去了！
Pinterest網站的內容信息緩存在memcache中，關係信息則緩存到Redis中，持久化方式保存！對於那種大號的粉絲，亦或是關注的人數太多則需要將關係數據拆分之後再緩存起來，對於動態變化的部分則需要獨立存放，在使用的時候需要將兩部分數據聚合，在可變部分達到一定長度的時候，需要與不變的部分進行合併！
當然推送的時候，所有的網站都使用異步的方式來實現！