歡迎光臨
每天分享高質量文章

幾個大型網站的Feeds(Timeline)設計簡單對比

點擊上方“芋道原始碼”,選擇“置頂公眾號”

技術文章第一時間送達!

原始碼精品專欄

 

Facebook起源的NewsFeed,以及Twitter起源的Timeline,核心問題都是如何處理巨大的訊息(活動,activity)分發。“推Push”和“拉Pull”或者“推拉結合”,是主要的處理方式。

以前各大網站陸續透露的文件,以及這次QCon2012 London和深圳的架構師會議,較大程度的公開了各自的實現方式。本文從 訊息分發樣式;內部通信工具、協議;儲存方式 3方面總結。 
各大網站都大量使用的Nginx, memcached, MySQL等開源產品,都標配了,文中不再提。實現技術上,異步訊息佇列的引入,來模塊解耦和尖峰削平;Cache的精良設計等,也都是各家大量使用的技能,可看參看文件,不再詳述。


Push, fan-out, Write-fanout 寫時訊息推送給粉絲。空間換時間
Pull, fan-in, Read-fanout 讀時拉取所有好友的訊息,再聚合。時間換空間
混合 Hybrid 基於推,混入拉;基於拉,加速推。時空平衡

1Facebook

參考《Facebook news-feed QCon12.pdf》。典型的Pull方式,讀時fanout,獲得所有好友的活動,再進行聚合,rank,排序等操作(這幾步後續動作,是feed和timeline的最大不同特點)。Facebook把這種樣式叫做“Multifeed – Multi-fetch and aggregate stories at read time”。 
FB的眾多產品、模塊,通訊協議自然用自家的Thrift,還用到SMC和其他的底層平臺。 
儲存模塊,有自家的“排序”儲存檔案(feed要按時間倒排,還有rank影響排序…記憶體的B樹排序結構,可以預測性的合併到檔案。可能開源)。還大量使用了 Redis 和Google開發的開源持久化KV儲存: LevelDB。 
Feeds相對於Timeline,最大特點是有rank影響排序,需要按型別合併,有推薦演算法的插入,有更複雜的資料結構…這些都是影響架構設計的重要因素,但這些都沒有文件詳細描述。拉樣式下,最重要的是高效穩定、分佈式的Aggregator的設計,也沒有詳細文件說明。 
(Facebook可以說是技術文件最不透明的網站了,特別是相較於他擁有最大的UGC而言。)


2Twitter

參考《TimelinesTwitter-QCon12.pdf》等眾多文件。主要是推樣式。Twitter的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。


3人人網

參考《人人網Feed系統結構淺析.pdf》和《人人網網站架構–服務化的演進》。作為中國的大型SNS網站,設計上也有很多自己的特色。 
從查詢的效率考慮, 人人網採用了推樣式(近似twitter樣式)。但是,人人網的Feeds,又比twitter類的timeline,有更複雜的結構和功能需求,所以在設計上,會有FB和Twitter雙方融合的特點。 

在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 …


4新浪微博

參考TimYang的《 構建可擴展的微博架構 》和《新浪微博cache設計談.pdf》 
雖然來源於Twitter,但不得不說,就資料量、複雜性而言,已經不弱於Twitter;穩定性更是高出了Twitter很多。新浪微博基礎是拉樣式,但是增加了“在線推”,對於在線用戶有“Inbox Cache”加速對timeline的獲取,減少aggregator的性能和時間消耗。結構如下圖: 

首頁timeline獲取步驟是:1.檢查inbox cache是否可用; 2.獲取關註串列; 3.聚合內容, 從 following 關係; 4.根據id list傳回最終feed聚合內容。Sina的這種結合樣式,符合中國的特點:明星海量粉絲(純推送代價巨大),個人用戶關註多(純拉取代價大),且在線用戶能得到極快的響應。 
儲存大量使用了Redis。並且有專門的講演,詳細介紹了Sina在Redis的大規模應該場景。《 Redis介紹》 《 新浪微博開放平臺Redis實踐 》 
但是基於拉樣式的aggragator沒有對外介紹。此外,sina微博的訊息機制、RPC框架,也未介紹。


5騰訊微博

參考《 張松國-騰訊微博架構介紹 08.pdf》。騰訊作為最有技術底子的公司,其架構有很多獨特之處,參考和直接利用國外的網站的樣式最少。騰訊微博採用“拉”樣式,聚合計算aggregator採用了多級樣式: 

同大多的timeline系統一樣,使用佇列來異步化和解耦,不過qq的解耦包括了系統解耦和業務解耦(和Renren網的“中轉單向RPC呼叫的訊息佇列”類似),不但解耦模塊,還使得各模塊開發得以並行,提升開發效率。其主要架構圖: 

騰訊的積累,使得騰訊微博在平臺化做的扎實。整個產品的“接口-服務”感覺清晰。在容災容錯方面更是比其它家(至少從文件上)高出了很多。集群建設,系統維護都沿襲了騰訊的積累,光海量日誌的查詢就用了Sphinx全文搜索。資料挖掘和分析(比如關係鏈分析、圈子挖掘、用戶價值評估)也一直是騰訊的重點能力。 



如果你對 Dubbo 感興趣,歡迎加入我的知識星球一起交流。

知識星球

目前在知識星球(https://t.zsxq.com/2VbiaEu)更新瞭如下 Dubbo 原始碼解析如下:

01. 除錯環境搭建
02. 專案結構一覽
03. 配置 Configuration
04. 核心流程一覽

05. 拓展機制 SPI

06. 執行緒池

07. 服務暴露 Export

08. 服務取用 Refer

09. 註冊中心 Registry

10. 動態編譯 Compile

11. 動態代理 Proxy

12. 服務呼叫 Invoke

13. 呼叫特性 

14. 過濾器 Filter

15. NIO 服務器

16. P2P 服務器

17. HTTP 服務器

18. 序列化 Serialization

19. 集群容錯 Cluster

20. 優雅停機

21. 日誌適配

22. 狀態檢查

23. 監控中心 Monitor

24. 管理中心 Admin

25. 運維命令 QOS

26. 鏈路追蹤 Tracing


一共 60 篇++

原始碼不易↓↓↓

點贊支持老艿艿↓↓

赞(0)

分享創造快樂