http://blog.renren.com/GetEntry.do?id=781732878&owner=232930872

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

一、 什么是feed

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

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

二、 怎樣得到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。

三、 如何表示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個模板。

四、 有效組織feed信息

? ? ? 現在的網絡是信息大爆炸的展示場，為了避免讓用戶淹沒在雜亂的feed海洋中，如何有效組織這些feed信息就是各大平臺技術較量的一大戰場，當平臺在后臺為用戶準備好了屬于他的原始feed信息后，當然各家平臺針對自己業務的特點會有不同的方案，但大致都要經過以下幾個步驟才能變成最終展示給用戶的形態：

1、?? 聚合：

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

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

以下圖新浪微博cache設計圖為例：

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

? ? ? ?feed信息依據自身特性分布于各級存儲中，必須要把他們匯聚到一起。匯聚并不單純只是不同級別存儲位置的匯聚，還有牽扯到業務數據的匯聚，比如來自不同feed信息源的匯聚如：來自平臺本身，開放應用，第三方外部網站等業務流的匯聚。

2、?? 去重

? ? ? 很多時候有些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空間最主要的展示內容都是圍繞著該用戶的一些信息故不太會經常產生過度重復的分享內容。

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

3、?? 排序

? ? ? ?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空間這種應為是輔助與其他產品的工具，所以他關注的是被輔助的產品自身所需求的特點。

4、?? 渲染

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

五、 架構簡介

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

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

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

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

其系統架構如下圖：

? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?圖5-2 微博系統架構

? ? ? ?具體技術方案我自己也在學習中，這里就不再多說了（就不出來丟人了…），有興趣大家一起探討學習吧。

人人網系統架構圖：

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

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

六、 總結

? ? ? ?好久沒寫這么長篇的東西了，終于寫完了。由于個人水平有限系統架構部分寫的有點略顯薄弱，歡迎大家一起討論，爭取以后有機會把這部分單獨完善重寫一篇。

總結

以上是生活随笔為你收集整理的常用社交网络（SNS、人人网、新浪微博）动态新闻（feed、新鲜事、好友动态）系统浅析的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。