Digg.com 的系統架構
在過去的幾年間,我們一直致力于重構Digg的架構,現在我們稱之為“Digg V4”.本文我們將全面介紹Digg的使用的系統和技術。找出Digg引擎的秘密。 首先,我們來看下Digg給大眾用戶提供的服務吧:
人們通過瀏覽器或者其他應用來訪問這些Digg服務。一些有Digg賬戶的用戶,可以得到“我的新聞”。每位用戶可以得到的我們稱之為“熱門新聞”。我們有digg.com和移動版的m.digg.com,API服務的services.digg.com,信息介紹的about.digg.com,為開發者服務的developers.digg.com。這些站點統一為用戶,新聞發布者,開發人員提供了博客和文檔服務。
本文主要介紹Digg在社會化新聞產品中使用的高級技術。
我們努力要做的
我們努力搭建以用戶發布新聞和廣告商發布廣告為基礎 一個社會新聞站點。
故事提交 注冊用戶提交文章,文章包含:一個標題,一篇段落,一個媒體類型,一個主題,或者一個縮略圖。這些內容通過一系列的元字符標準(非死book open graph protocol, OEmbed等)如從文章中解壓出來,當然提交者在提交前最后這些元字符具體是什么。廣告發布商將廣告發布到另外一個獨立的系統,當然如果Dugg夠的話,完全可以成為故事。
故事列表 在個性化新聞產品“我的新聞“里,你追隨的用戶發布的所有故事以“故事列表”顯示,采用最近發布,媒體類型,故事的主題等方式排列。
故事動作 用戶可以對故事進行操作,比如說閱讀,點擊,Digg,掩埋,發表評論,投票等等。沒有注冊登錄的用戶只能閱讀和點擊這些故事。
故事推薦 我們會決定每個小時有一些故事會從最近故事列表轉移到熱門新聞列表。我們的算法(這個是保密的)通過查看用戶的行為和故事內容的分類來決定選擇哪些故事進入熱門新聞。
我們是如何實現它的?
讓我們從宏觀的角度看下如果一個用戶訪問Digg的站點,做一些基于內容的操作。下面的圖片顯示了公眾看到的內容及內部提供的頁面、圖片、API請求等服務。
我們內部系統的簡單描述如上。我們的API服務代理想內部后端服務進行請求。前端的服務是被虛擬化的(與緩存是有區別的),并且放置在相同的服務層。CMS和廣告系統將在此文章中不做詳細說明,縱覽整個系統,大致可以分為以下兩類:同步和異步。
1、對用戶進行即時響應的同步操作
同步操作主要表示對用戶請求(包括API請求)的即時快速響應,包括一些在頁面中通過AJAX方式進行的異步請求。這些操作通常要求最長一兩秒的時間內就能完成。
2、離線批量進行的異步計算
除了實時響應的請求外,有時候還需要進行一些批量的計算任務,這些任務可能是間接的被用戶啟動的,但用戶不會等待這些任務的完成。這些異步計算通常可能會花費數秒,數分鐘甚至幾小時。
上面所說的兩部分如下圖所示:
下面就更加深入的了解各個組成部分。
線上系統
提供頁面和API請求服務的程序主要以PHP(前端Web頁面,Drupal CMS)和使用的Python(API服務,Tornado)編寫。前端通過Thrift protocol協議來調用后端的服務(Python)。很多數據會被如Memcached 和Redis 這樣的內存緩存系統緩存。
消息和事件
線上和離線的信息通過主要數據存儲transient / logging系統這種同步方式連接和使用 RabbitMQ 作隊列系統,將不用同步響應的操作放到隊列異步地進行。比如說”一個用戶Dugg了一個故事“,”計算這個東西“。
批處理和異步系統
上面的消息系統是指隊列,而這個指的是具體從隊列取出任務執行的部分。此系統將任務從隊列中取出,進行一定的計算后再對主存儲進行操作,對主存儲的操作在實時系統和異步批量系統中都是一樣的。
當隊列中發現信息時,一個“工作者”被調用來完成特定的動作。一些信息由事件觸發,有點象cron機制。然后工作者對主存儲設備或者離線存 儲設備的數據進行運算和操作,在HDFS中記錄日志,然后把結果寫回到主存儲設備,這樣在線服務就可以使用他們。舉個例子:比如說索引新的故事,計算故事 提升算法,運行分析工作。
數據存儲
Digg根據數據的類型和使用方式的不同,將數據存儲在不同的系統中,當然,有時候還避免不了有一些歷史原因。
操作系統和配置
digg目前運行在基于GNU/Linux的Debian系統。配置了Clusto,Puppet。使用的是Zookeeper做系統協調。
本文由 標點符 進行翻譯,原文鏈接:http://about.digg.com/blog/how-digg-is-built