幾個大型網站的Feeds(Timeline)設計簡單對比
非死book起源的NewsFeed，以及推ter起源的Timeline，核心問題都是如何處理巨大的消息(活動,activity)分發。“推Push”和“拉Pull”或者“推拉結合”，是主要的處理方式。
以前各大網站陸續透露的文檔，以及這次QCon2012 London和深圳的架構師會議，較大程度的公開了各自的實現方式。本文從 消息分發模式；內部通信工具、協議；存儲方式 3方面總結。
各大網站都大量使用的Nginx, memcached, MySQL等開源產品，都標配了，文中不再提。實現技術上，異步消息隊列的引入，來模塊解耦和尖峰削平；Cache的精良設計等，也都是各家大量使用的技能，可看參看文檔，不再詳述。
| 推 |
Push, fan-out, Write-fanout |
寫時消息推送給粉絲。空間換時間 |
</tr>
| 拉 |
Pull, fan-in, Read-fanout |
讀時拉取所有好友的消息，再聚合。時間換空間 |
</tr>
| 混合 |
Hybrid |
基于推，混入拉；基于拉，加速推。時空平衡 |
</tr>
</tbody>
</table>
①非死book
參考《非死book news-feed QCon12.pdf》。典型的Pull方式，讀時fanout，獲得所有好友的活動，再進行聚合，rank，排序等操作（這幾步后續動作，是feed和 timeline的最大不同特點）。非死book把這種模式叫做“Multifeed – Multi-fetch and aggregate stories at read time”。
FB的眾多產品、模塊，通訊協議自然用自家的Thrift，還用到SMC和其他的底層平臺。
存儲模塊，有自家的“排序”存儲文件（feed要按時間倒排，還有rank影響排序…內存的B樹排序結構，可以預測性的合并到文件。可能開源）。還大量使用了 Redis 和Google開發的開源持久化KV存儲： LevelDB 。
Feeds相對于Timeline，最大特點是有rank影響排序，需要按類型合并，有推薦算法的插入，有更復雜的數據結構…這些都是影響架構設計的重要 因素，但這些都沒有文檔詳細描述。拉模式下，最重要的是高效穩定、分布式的Aggregator的設計，也沒有詳細文檔說明。
(非死book可以說是技術文檔最不透明的網站了，特別是相較于他擁有最大的UGC而言。)
②推ter
參考《Timelines推ter-QCon12.pdf》等眾多文檔。主要是推模式。推ter的Timeline這種應用，和FB的Feed最大的區別，就是要解決fan-out的效率和全文搜索的效率。整體模塊劃分圖：
主要特點是對fanout的處理：隊列化(有自己用Scala語言實現的Kestrel隊列)，并發處理推送等大消耗業務，各級緩存(包括In-Proc)…
通訊協議上， Kestrel 復用了MemCached協議；而Timeline API模塊使用了FB的Thrift。通信框架是大量使用的自己開發的（已開源）RPC框架 Finagle （A fault tolerant, protocol-agnostic RPC system）。
搜索引擎使用了Lucene。存儲也大量使用了Redis。
③人人網
參考《人人網Feed系統結構淺析.pdf》和《人人網網站架構–服務化的演進》。作為中國的大型SNS網站，設計上也有很多自己的特色。
從查詢的效率考慮, 人人網采用了推模式(近似推ter模式)。但是，人人網的Feeds，又比推ter類的timeline，有更復雜的結構和功能需求，所以在設計上，會有FB和推ter雙方融合的特點。
在Cache上，人人有自己實現的Server來支持。特別是在IndexCache上，基本數據結構和FB一樣，使用了C++ Boost multi-index container；序列化和壓縮采用Protobuf和QuickLZ。特別是有專門實現的解決feed索引持久化難題的Feed Index DB。
最后用模板渲染引擎(也是C++實現)來顯示復雜的Feed。
Renren在網絡通信上大量使用 ICE框架 ，協議上多用Protobuf，實現緩存等中間層、新鮮事兒等系統。大量自己開發的server集群，通過他們高效通信。
在高性能計算上，Renren網傾向用C/C++編寫定制性Server，保證數據中心存儲，大規模數據盡量在進程內訪問。像IndexCache Server（海量的Feed數據裝載在單一Server內，實現“數據盡可能靠近CPU”的原則），實現高速排序等計算需求；此外還有文檔里提及的渲染 Server…都是用C寫的專用Server。好處自然是本地內存的納秒級訪問速度，遠遠高于網絡IO，可實現極高的性能。
現在，人人網的架構也在向Service化方向發展，并封裝成了XOA，基礎總線使用了Thrift，消息隊列用了 ZeroMQ …
④新浪微博
參考TimYang的《 構建可擴展的微博架構 》和《新浪微博cache設計談.pdf》
雖然來源于推ter，但不得不說，就數據量、復雜性而言，已經不弱于推ter；穩定性更是高出了推ter很多。新浪微博基礎是拉模式， 但是增加了“在線推”，對于在線用戶有“Inbox Cache”加速對timeline的獲取，減少aggregator的性能和時間消耗。結構如下圖：
首頁timeline獲取步驟是：1.檢查inbox cache是否可用; 2.獲取關注列表; 3.聚合內容, 從 following 關系; 4.根據id list返回最終feed聚合內容。Sina的這種結合模式，符合中國的特點：明星海量粉絲(純推送代價巨大)，個人用戶關注多(純拉取代價大)，且在線 用戶能得到極快的響應。
存儲大量使用了Redis。并且有專門的講演，詳細介紹了Sina在Redis的大規模應該場景。《 Redis介紹 》 《 新浪微博開放平臺Redis實踐 》
但是基于拉模式的aggragator沒有對外介紹。此外，sina微博的消息機制、RPC框架，也未介紹。
⑤騰訊微博
參考《 張松國-騰訊微博架構介紹 08.pdf》。騰訊作為最有技術底子的公司，其架構有很多獨特之處，參考和直接利用國外的網站的模式最少。騰訊微博采用“拉”模式，聚合計算aggregator采用了多級模式：
同大多的timeline系統一樣，使用隊列來異步化和解耦，不過qq的解耦包括了系統解耦和業務解耦(和Renren網的“中轉單向RPC調用的消息隊列”類似)，不但解耦模塊，還使得各模塊開發得以并行，提升開發效率。其主要架構圖：
騰訊的積累，使得騰訊微博在平臺化做的扎實。整個產品的“接口-服務”感覺清晰。在容災容錯方面更是比其它家（至少從文檔上）高出了很多。集群建設，系統 維護都沿襲了騰訊的積累，光海量日志的查詢就用了Sphinx全文搜索。數據挖掘和分析（比如關系鏈分析、圈子挖掘、用戶價值評估）也一直是騰訊的重點能 力。
本文由用戶
ygfb 自行上傳分享，僅供網友學習交流。所有權歸原作者，若您的權利被侵害，請聯系管理員。
轉載本站原創文章，請注明出處，并保留原始鏈接、圖片水印。
本站是一個以用戶分享為主的開源技術平臺，歡迎各類分享！
sesese色