經常使用社交網絡（微博等）動態新聞（feed、新鮮事）系統淺析（轉）

add by zhj：同時也看看國外牛逼公司是怎麼作的吧

Stream-Framework    Python實現的feed

Twitter 2013 Redis based, database fallback, very similar to Fashiolista's old approach.

Etsy feed scaling (Gearman, separate scoring and aggregation steps, rollups - aggregation part two)

Facebook history

Django project with good naming conventions

Activity stream specification

Quora post on best practises

Quora scaling a social network feed

Redis ruby example

FriendFeed approach

Thoonk setup

Yahoo Research Paper

Twitter’s approach

Cassandra at Instagram

 

 

原文：http://blog.renren.com/share/117462957/15084000902

最近見幾個朋友都在說人人網新鮮事排序的問題，恰巧對這方面也較感興趣，因而打算順便把手頭收集到的資料梳理學習一下。因爲本人也只是新手，不少內容僅僅是參閱資料後的我的猜想與紙上談兵故不免存有錯誤與紕漏，感謝你們指正。

1、 什麼是feed

「Feed，本意是「飼料、飼養、（新聞的）廣播等」，RSS訂閱的過程當中會用到的「Feed」，即是在這個意義上進行引伸，表示這是用來接收該信息來源更新的接口。」----摘自百度百科。

      要說嚴格的feed定義與解釋又得吧啦吧啦說一大堆無趣的話，通俗點說feed系統就是當你登錄進對應網站後：閱讀器收到的一篇篇新文章、人人網上看到的一件件新鮮事、新浪微博上推到你面前的一條條新圍脖、QQ空間中好友的一樁樁新動態等等。

2、 怎樣獲得feed

      feed的獲取方式主要有兩種：push（推）以及pull（拉），簡單說來正如他們字面意思同樣。

      push就是當一條feed產生後交到分發器，它再去查找用戶關係明確出誰應該看到這條feed，再push到這些用戶的feed列表中（新鮮事、好友動 態），用手機短信來比喻的話就是收件箱裏存收到的feed，發件箱裏存發出的feed，產生一條feed就是把它「推」到全部粉絲或好友的收件箱中，而查 看的話直接訪問本身的收件箱就OK，咱們能夠明顯地看到這種狀況下經過前置計算（或者叫offline computation）提早準備好用戶的feed信息，在取數據時無需多餘的計算開銷；但相反在分發的過程當中會產生大量的計算，尤爲是相似於姚晨這種的 明星級人物（1400多萬的粉絲真的不是開玩笑）發送一條圍脖會產生巨大的數據分發量（新浪微薄的具體解決方案貌似是異步發送，具體方案超出本文範圍，感 興趣的同窗能夠去看TimYang的博客看看）。整體來講push的特徵是取輕、發重。使用push方式發送的例圖以下所示：

圖2-1 push發feed例圖

      pull則相反，當一個用戶登陸到網站後，業務邏輯系統會到feed列表裏去查找用戶應該看到的feed，用戶的feed渲染系統再把它們pull出來。 仍是手機短信的例子，pull中發表feed就是把它存入本身的發件箱，用戶查看feed的時候就去讀取全部關注對象的發件箱把內容「拉」進本身的收件 箱。「拉」方案的優勢是隨需計算（或者叫 online computation）節約存儲空間，但相對的缺點也很明顯過大的計算量影響feed數據的讀取速度，尤爲是峯值時段（新浪的號稱1億多用戶可不是開玩 笑的），相對於push來講pull的特徵是取重、發輕。使用pull方式取的例圖以下所示：

圖2-2 pull模式取feed例圖

      針對push和pull的優缺點，實際項目中通常採用混合模式。發佈的時候push給熱點用戶,再把feed存入熱點cache當沒收到push的用戶登 陸後能夠到cache裏快速pull出相關feed；用戶能夠先收到push的新feed消息，當想看之前的消息時再去pull出相關的feed。

3、 如何表示feed

       每一個平臺有各式各樣的feed消息，考慮到feed消息最終會展現到平臺自身、擴展應用以及客戶端上，因此對feed格式統一成某種規範而不是發佈者隨意輸出最終展現的文字。同時對圖片、視頻以及鏈接等都統必定義。Facebook的實現方式是這樣的：

• feed是自描述的，即它不是由生產者決定最終格式，也不是前端決定。而是經過template機制來進行。
• template在平臺中能夠由開發者註冊，註冊時須要定義字段及最終展現樣式，如

「{*actor*} 在***遊戲中升到 {*credit*} 級」

• 發佈的feed內容僅包含字段數據，也就是變量的值，json格式。

「{"credit": "80"}」

• 前端須要顯示feed時候調用feed模板，再替換字段獲得feed內容

「Tim 在***遊戲中升到 80 級」

• 模板須要定義兩個，模板標題及模板內容(展現feed詳細內容)，前端根據須要決定只顯示標題仍是所有都顯示。
•  「target」, 「actor」是系統保留字段，表明目標對象和當前用戶，{*actor*}必須放在模板標題開始位置。
• 「images」, 「flash」, 「mp3″, 「video」 是系統保留字段，無需在模板中定義。但這些內容只會在詳細feed界面輸出。即只要feed內容裏面有這個字段值，界面就會自動顯示。
• facebook文檔中沒有規定feed長度限制。
• 每一個開發者最多隻能註冊100個模板。

4、 有效組織feed信息

      如今的網絡是信息大爆炸的展現場，爲了不讓用戶淹沒在雜亂的feed海洋中，如何有效組織這些feed信息就是各大平臺技術較量的一大戰場，當平臺在後 臺爲用戶準備好了屬於他的原始feed信息後，固然各家平臺針對本身業務的特色會有不一樣的方案，但大體都要通過如下幾個步驟才能變成最終展現給用戶的形 態：

一、   聚合：

       根據feed信息的訪問頻率可能會存在不一樣的服務器存儲區域中。借用淘寶網核心系統專家餘峯對各存儲區與讀書的比喻加以修改就是：

       「CPU訪問L0就像是你讀手邊的一本書，訪問L1就像從書桌拿一本書，L2是從書架拿一本書，L3是從客廳桌子上拿一本書，訪問主存就像騎車去社區圖書館拿一本書。」

如下圖新浪微博cache設計圖爲例：

圖4-一、新浪微博cache結構圖

       feed信息依據自身特性分佈於各級存儲中，必需要把他們匯聚到一塊兒。匯聚並不單純只是不一樣級別存儲位置的匯聚，還有牽扯到業務數據的匯聚，好比來自不一樣feed信息源的匯聚如：來自平臺自己，開放應用，第三方外部網站等業務流的匯聚。

二、   去重

      不少時候有些feed信息是有重複性的，好比A發表了一篇日誌，他的好友B和C看後很喜歡選擇分享。當這條feed若是出如今B與C的共同好友裏就會出現 重複feed信息。面對這個問題不一樣的社交平臺針對本身的業務類型選擇了不一樣的處理方式，即便是同一個平臺也在對這種行爲採起了不一樣的應對策略。通過簡單 測試後猜想結果：

                           表4-1 不一樣平臺feed去重說明

平臺名稱		說明
新浪微博		基於微薄輕傳播媒體理論，不覆蓋重複的分享feed記錄下分享傳輸的軌跡
人人網	早期	不處理重複分享，單純按時間排序feed，時間早的天然在feed列表中淘汰
	曾經	消除重複feed信息，只顯示最新一條，但在feed信息的下方顯示擁有類似分享的鏈接，點這裏能夠看到其餘的類似分享以及消重的個數
	如今	有選擇的處理重複分享，按現有高級排序方法對feed排序
QQ空間	舊版	不處理重複分享，根據舊版匯聚在一個大的用戶最新動態之中
	新版	不處理重複分享，根據新版方式排序在feed列表裏

通過測試發現：

       對於新浪微博來講因爲他的定位是一種媒體工具，因此關注的點是信息的傳輸，故而並未太注重去重的分析。他只是單純的記錄信息傳輸過程新產生的信息，能夠說針對同一條信息每一次不一樣人的轉發都是在完善這條媒體信息。

       人人網因爲是這裏面最純粹的社交網絡，饋贈型經濟驅動下的社交網絡更關注的是如何產生分享這一行爲，如何激勵用戶的互動是他首要關注的目標。於是咱們可 以看出人人網對於去重的技術關注較其餘平臺更深，其自身去重的方法也在不斷修改，一開始確實是沒有關注到相關問題，在用戶數量增長後，對於一些熱點分享就 會出現很嚴重的重複feed，當用戶登錄網站會發現排在feed列表前的都是重複的熱點信息。針對這點人人推出了消除重複feed的功能，將許多類似分享 合併到一個feed中只顯示最新的分享條目。但這樣一來有些用戶發現本身分享的東西，只能在好友feed中生存一小段時間，一旦有共同好友也分享這條信息 就會覆蓋掉本身的分享。這樣一來用戶的分享不能被其餘人徹底看到，抑制了饋贈型經濟的產生條件。好在以後隨着推薦引擎的技術發展解決了這個問題，人人網 feed排序方式的改進，徹底能夠避免熱點信息重複出如今feed列表的前面，並且能夠有針對性的將你的分享自動投遞到你指望的讀者面前，具體的排序方案 在下一節會詳細分析。

      QQ空間做爲騰訊QQ IM的一個擴展並不算一個純粹的社交分享型網絡，他只是完善QQ IM不能觸及的一些方面，使用戶更加全面的瞭解IM交流的對象。他更像是一個用戶的展現平臺，因此重複分享現象在QQ空間中並不嚴重。QQ空間最主要的展 示內容都是圍繞着該用戶的一些信息故不太會常常產生過分重複的分享內容。

      從趨勢上看隨着排序算法更加智能化的發展，重複的熱點消息問題會獲得更有的解決。

三、   排序

       feed排序算法能夠說是SNS發展最重要的技術之一，也是各家平臺的核心技術。因爲看過的相關資料較少，如下的一些分析僅僅是我的紙上談兵的一點淺析，歡迎你們指正。

不一樣平臺有着不一樣的排序方案（經測試和我的使用總結）：

                               表4-2 不一樣平臺排序說明

平臺名稱		說明
新浪微博		單純按照feed發生時間排序
人人網	早期	按feed發佈時間順序排序
	曾經	有段時間相冊是按最後評論時間排序
	如今	綜合的推薦引擎方式排序
QQ空間	舊版	將用戶最近feed信息框入一個大的feed中，按用戶最新動態時間對這個大feed總體排序
	新版	相似於新浪微薄的單純按照feed發生時間排序

       如前所述因爲新浪微薄的定位是媒體功能，因此它的時效性要求較高。再加上原來140個字的限制都代表他輕量級的信息定位應該更專心於時效性，故新浪採起 產生時間排序無可厚非，微博的原理是假設有價值的微博會不斷被轉發從而反覆出如今用戶的feed列表中，但這種方法也產生了微博的「15分鐘定理」——如 果一條微博在最初的15分鐘內沒有被大量關注與轉發則它會被汪洋「博」海所淹沒，最終傳播不了多遠。根據長尾理論可能存在一些小型的細分用戶羣體話題存 在，因而一些有價值的微博因爲初期沒有被發現，或是做者的粉絲過少，都有可能致使做品沒法傳播開去。我的預測新浪也可能會引入推薦引擎系統，經過對用戶興 趣和微博數據庫的深度數據挖掘進行微博推薦，在時間單維排序的基礎上加入興趣維度。

       單看國內SNS人人網如今的排序系統貌似是最複雜的（facebook的算法智能與變態程度就不考慮了）。根據人人網張鐵安在《程序員》與CSDN舉辦 的TUP第二期上的演講以及我的使用狀況來看，首先人人網會對用戶的資料和行爲進行挖掘而後按興趣分類生成興趣向量，再根據用戶與好友的互動行爲挖掘生成 社會關係向量。當一條feed由好友產生了會挖掘這條消息的興趣分類向量，該分類向量與你的興趣分類向量計算距離獲得興趣權值，再經過做者與你的社交向量 作計算得出關係權值。最終一條feed的排序權值會來自於最少如下幾個方面【生成時間、消息熱度（最近活躍程度）、興趣權值、關係權值、商業權值】。其中 商業權值應該是針對一些商業推廣活動類feed，好比說你參加了在人人網作廣告的某些活動，系統會將這條feed發送給你的好友面前，可能根據廣告主付錢 多少採起不一樣的權值會在好友的feed列表前面排列好久。

       QQ空間在前面已經分析過是針對QQ IM的一個拓展，他的核心是展現用戶信息平臺，因此他較老版本的排序是以某一用戶的最新動態排序，而後將該用戶最近的動態打包合併到一個大的feed中向 用戶展現。他的核心是針對於一個用戶的信息產生的。在新版QQ空間中多是爲了和麪向媒體的騰訊微博以及面向社交的朋友網進行整合，修改爲面對單一每條 feed的排序。

       整體來講SNS因爲業務類型的不一樣，各個平臺針對產生feed的這一行爲的關注點各有不一樣，進而致使了排序行爲的不一樣。新浪微博這種媒體平臺關注的是 feed自己的內容以及由轉發與評論引出的新內容；人人網這種純粹社交網絡關注的是由feed內容引起的用戶間的互動行爲；而QQ空間這種應爲是輔助與其 他產品的工具，因此他關注的是被輔助的產品自身所需求的特色。

四、   渲染

       渲染階段比較易於理解，經過第三部分的描述咱們瞭解到feed最初是由變量名與變量值組成的，渲染就是經過將feed套入對應模版並依據以前幾個步驟通過聚合、去重、排序後的結果最終生成爲用戶所看到的feed列表。

5、 架構簡介

       這部分只是簡單給你們展現下新浪和人人網的系統架構，具體技術和原理我的還正在學習中（就不說出來丟人了）

新浪微博的功能性架構圖以下所示：

                        圖5-1 新浪微博功能架構

       這個是新浪微博的第三代架構圖了，首先在最底層是實現一些存儲同步等基礎性需求。再上面是平臺面向業務的服務與提供應用的服務，最上層是做爲第三方開發的API提供給app開發者。

其系統架構以下圖：

                               圖5-2 微博系統架構

       具體技術方案我本身也在學習中，這裏就再也不多說了（就不出來丟人了…），有興趣你們一塊兒探討學習吧。

人人網系統架構圖：

                         圖5-3 人人網feed系統架構圖

       簡單說一下這圖，笑臉表示某個用戶很開心寫了篇日誌，是先交給分發器（Dispatcher）,通過一些處理後發往三個不一樣的地方，第一個是 newsfeed這是完整的一個feed信息與索引；第二個是minifeed這是一個feed的短摘要信息，你在人人網上看到的某個用戶寫了篇日誌的新 鮮事，在它的標題下面會有一小段摘要，這個短摘要就是minifeed；第三是要把新鮮事自己cache起來，會把feed發到集羣裏面最後進行存儲持久 化。

6、 總結

       很久沒寫這麼長篇的東西了，終於寫完了。因爲我的水平有限系統架構部分寫的有點略顯薄弱，歡迎你們一塊兒討論，爭取之後有機會把這部分單獨完善重寫一篇。