Digg网站架构【译】

在Digg过去的一年里，我们一直在不断地重构Digg的架构，我们称之为“Digg V4”。本文给出了高层次的系统架构以和所涉及的技术，以及我们是如何利用这些技术的。读完此文后就让我们来揭开Digg工程师的秘密吧。

首先来看看Digg为大众用户提供的服务吧：

1、面向所有用户的社交新闻网站

2、个性化的社交新闻网站

3、广告服务平台

4、API接口服务

5、博客和文档网站

以上这些站点主要是由用户通过浏览器或者其他应用程序来访问，一些拥有digg帐号并且登录的用户，可以获取个性化的新闻信息，即“我的新闻”。每个用户可以获取所有用户的网站上的信息，我们称之为“热门新闻”。这些产品都可以在“digg.com”和移动站点“m.digg.com”中看到，API服务可以在“services.digg.com”上获取，最后，“about.digg.com”和“developers.digg.com”统一为用户、出版商、广告商和开发商提供博客和文档服务。

这篇文章将主要包括社交新闻产品的高层次技术。

我们在努力做的

我们在努力搭建一个以用户发布新闻和广告商发布广告为基础的社交新闻站点。

故事提交：登录用户可以提交文章，文章包括下面几个字段：标题、段落、媒体、主题和必要的缩略图。这些字段是从包含各种标准元数据的源文件中提取的，当然提交者对这些有着最终的决定权。广告是由出版商提交到一个单独的系统，但如果Dugg不够，有可能成为故事。

故事列表：在“我的新闻“里，你追随的用户发布的所有故事以“故事列表”显示，采用最近发布，媒体类型，故事的主题等方式排列。

故事动作：用户可以对这些故事进行一些操作比如阅读、点击、digg、bury、评论、投票等等，未登录用户只能阅读和点击。

故事推广：有时候每小时我们会决定将故事从最新故事列表中移到热门故事列表中，该算法（我们的秘密武器）是根据用户的操作和内容功能分类决定的。

我们如何去做

让我们来看看用户是如何访问digg来获取内容和服务的，下面是Digg站点的运行图，此图展示了公共视图，并介绍了Digg内部提供页面

我们内部系统的边界已经十分简化明晰，但这确实表明API服务器的代理请求到了我们内部后端服务器，前端服务器几乎是无状态的（除了一些缓存），并依赖于相同的服务层。CMS和广告系统将不会在本文中介绍。

用抽象的方式看内部的高级服务，他们可以分为2个部分：

在线或者互动或者同步

用户直接或者间接发出页面或者API申请，为了提供良好的页面回应，每个服务要在几个百万级秒内做出反应，同时所有服务集合起来不能超过1,2s的反应时间。这些包含了ALAX的异步请求，但是从服务系统来看是请求/回复的服务

离线或者批次或者异步

不交互的服务请求通常是由一个用户间接提出的。这些响应时间可以允许到秒，分，小时（当然很少发生了）

如下图所示：

在线系统：

提供页面和API请求服务的程序主要以PHP（前端，Drupal CMS）和使用Tornado的Python（API服务）编写。前端通过Thrift protocol协议来调用后端的服务（Python）。在线程序（FE和BE）用MEmcached和Redis来做缓存。一些项目也主要存储在Redis中的。下边有描述

信息和事件：

在线和离线的世界通过1：调用主要数据存储，transient / logging系统这种同步方式链接 2 ：用RabbitMQ来队列化事件和工作任务，比如说”一个用户Dugg了一个故事“，”计算这个东西“这种异步方式链接

批处理和异步系统

当队列中发现信息时，一个”工作者“被调用来完成特定的动作。一些信息由事件触发，有点象cron机制。然后工作者对主存储设备或者离线存储设备的数据进行运算和操作，在HDFS中记录日志，然后把结果写回到主存储设备，这样在线服务就可以使用他们。举个例子：比如说索引新的故事，计算故事提升算法，运行分析工作

数据存储：

Digg根据数据的类型和使用方式的不同，将数据存储在不同的系统中，当然，有时候还避免不了有一些历史原因:)（个人认为可能是由于老的系统架构难以或者不值得再做大的更改）

Cassanda:主要要用来存储”类对象“使用方式的数据，比如说项目（故事），用户，Diggs，和相关的索引。因为Cassanda0.6版不支持2级索引，他们被程序计算并存储。这样就允许了服务器能够查看，比如说，通过用户的用户名或者邮件而不是用户的用户ID来查询。这里我们使用了Python Lazyboy wrapper

HDFS：来自站点和API事件，用户活动的日志都在这里。以Map-Reduce和Hive in Hadoop方式运行的批处理工作的数据源和数据终点。很大的数据和很大的计算量！

MogileFS：存储用户的图标，截图，等其他静态集合的二进制存储基地。是CDN的后端存储，可以通过不同的CDN前端来使用（翻译不吃准）

Mysql：用来存储故事提升算法和计算的数据，因为它需要许多大量繁重的操作，很自然不适合其他类型的数据存储，HBase看起来挺有意思的

Redis：存储每个用户新闻数据，每个用户的新闻具有不同和需要及时更新的特征。我们用Redis来提供Digg Streaming API和real time view and click counts服务。作为一款基于内存存储的系统，它提供了超底的负载

SOLR：被用来做文本，时间，主题等查询的搜索索引

Scribe：日志收集服务。这是个主要的存储，日志会定期轮转出系统，并写到HDFS中

操作系统和配置

Digg运行在Debian GNU/Linux稳定版上，配置了Clusto，Puppet。使用的是Zookeeper配置系统