Digg.com 的系統架構

jopen 9年前發布 | 22K 次閱讀 系統架構 軟件架構

    在過去的幾年間,我們一直致力于重構Digg的架構,現在我們稱之為“Digg V4”.本文我們將全面介紹Digg的使用的系統和技術。找出Digg引擎的秘密。 首先,我們來看下Digg給大眾用戶提供的服務吧:

  • 一個社會化的新聞站點
  • 為個人可定制的社會新聞
  • 廣告平臺
  • API 服務
  • 博客和文檔站點
  •     人們通過瀏覽器或者其他應用來訪問這些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請求等服務。

        Digg.com 的系統架構

        我們內部系統的簡單描述如上。我們的API服務代理想內部后端服務進行請求。前端的服務是被虛擬化的(與緩存是有區別的),并且放置在相同的服務層。CMS和廣告系統將在此文章中不做詳細說明,縱覽整個系統,大致可以分為以下兩類:同步和異步。

        1、對用戶進行即時響應的同步操作

        同步操作主要表示對用戶請求(包括API請求)的即時快速響應,包括一些在頁面中通過AJAX方式進行的異步請求。這些操作通常要求最長一兩秒的時間內就能完成。

        2、離線批量進行的異步計算

         除了實時響應的請求外,有時候還需要進行一些批量的計算任務,這些任務可能是間接的被用戶啟動的,但用戶不會等待這些任務的完成。這些異步計算通常可能會花費數秒,數分鐘甚至幾小時。

        上面所說的兩部分如下圖所示:

        Digg.com 的系統架構

        下面就更加深入的了解各個組成部分。

        線上系統

        提供頁面和API請求服務的程序主要以PHP(前端Web頁面,Drupal CMS)和使用的Python(API服務,Tornado)編寫。前端通過Thrift protocol協議來調用后端的服務(Python)。很多數據會被如Memcached 和Redis 這樣的內存緩存系統緩存。

        消息和事件

        線上和離線的信息通過主要數據存儲transient / logging系統這種同步方式連接和使用 RabbitMQ 作隊列系統,將不用同步響應的操作放到隊列異步地進行。比如說”一個用戶Dugg了一個故事“,”計算這個東西“。

        批處理和異步系統

        上面的消息系統是指隊列,而這個指的是具體從隊列取出任務執行的部分。此系統將任務從隊列中取出,進行一定的計算后再對主存儲進行操作,對主存儲的操作在實時系統和異步批量系統中都是一樣的。

        當隊列中發現信息時,一個“工作者”被調用來完成特定的動作。一些信息由事件觸發,有點象cron機制。然后工作者對主存儲設備或者離線存 儲設備的數據進行運算和操作,在HDFS中記錄日志,然后把結果寫回到主存儲設備,這樣在線服務就可以使用他們。舉個例子:比如說索引新的故事,計算故事 提升算法,運行分析工作。

        數據存儲

        Digg根據數據的類型和使用方式的不同,將數據存儲在不同的系統中,當然,有時候還避免不了有一些歷史原因。

  • Cassandra:對諸如文章、用戶、Digg操作 記錄等“類對象(Object-like)”的信息,都是使用Cassandra來存儲的。我們使用的是Cassandra0.6版本,由于0.6版本并 沒有劫持二級索引,于是我們將數據通過應用層處理后再用它進行存儲。比如我們的用戶數據層提供通過用戶名及Email地址來查詢用戶信息的接口。這樣就允 許了服務器能夠查看,比如說,通過用戶的用戶名或者郵件而不是用戶的用戶ID來查詢。這里我們使用了Python Lazyboy wrapper
  • HDFS:來自站點和API事件,用戶活動的日志都在這里。主要用到日志信息存儲及分析計算,利用 Hive 操作 Hadoop,進行MapReduce計算。
  • MogileFS:是一個分布式文件存儲系統,用以存儲二進制的文件,比如用戶頭像,截屏圖片等。當然,文件存儲的上層還有統一的CDN。
  • MySQL:目前我們的文章置頂功能上使用了MySQL存儲一些數據,用來存儲故事提升算法和計算的數據,因為這一功能需要大量的JOIN操作。很自然不適合其他類型的數據存儲。與此同時 HBase 好像也是個不錯的考慮。
  • Redis:由于 Redis 的高性能及其靈活的數據結構,我們用它來提供對 Digg Streaming API 的存儲,存儲每個用戶新聞數據,每個用戶的新聞具有不同和需要及時更新的特征。同時用Redis來提供Digg Streaming APIreal time view and click counts服務。作為一款基于內存存儲的系統,它提供了超低的負載。
  • SOLR:用來構建全文索引系統。以提供對文章內容、話題等的全文檢索。
  • Scribe:日志收集系統,比syslog-ng更強大更簡單。用它收集的日志會被放到HDFS進行分析計算。
  •     操作系統和配置

        digg目前運行在基于GNU/Linux的Debian系統。配置了ClustoPuppet。使用的是Zookeeper做系統協調。

        本文由 標點符 進行翻譯,原文鏈接:http://about.digg.com/blog/how-digg-is-built

     本文由用戶 jopen 自行上傳分享,僅供網友學習交流。所有權歸原作者,若您的權利被侵害,請聯系管理員。
     轉載本站原創文章,請注明出處,并保留原始鏈接、圖片水印。
     本站是一個以用戶分享為主的開源技術平臺,歡迎各類分享!