SpiderDuck与NoSQL – Twitter实时URL抓取服务架构

原文：http://blog.nosqlfan.com/html/3457.html

最近Twitter开发者博客上发表了一篇文章，向大家介绍了Twitter的URL抓取服务SpiderDuck，其中用到了Cassandra，HDFS和Memcached作为存储部件。是一个了解NoSQL使用方法的好例子。

SpiderDuck的架构如下图所示：

其分为下面几个部分：

• Kestrel: 是一个Twitter在使用的队列服务，这里将所有需要抓取的URL放入此队列中。
• Schedulers（调度器）：调度器主要负责如下一些工作：在抓取前决定这个URL是否抓取（在最近N天内抓取过的不再进行抓取），在抓取中对跳转进行处理、以及对抓取工作进行调度，在抓取工作完成后，解析抓取内容，分析出其metadata信息，然后将此信息存入Metadata Store，并将抓取到的内容存到Content Score中。调度器是队列的处理程序，所以调度器之间互不依赖，能够很好的进行横向扩展。
• Fetchers（抓取器）: 这是一个提供 Thrift 接口的抓取服务，主要工作是抓取URL内容，同时其会通过对网站的robots.txt进行分析，从而进行抓取频率控制，以使通过频率变化进行相应的横向扩展。
• Memcached： 这是一个用Memcached构建的分布式缓存系统 ，主要是为抓取器缓存robots.txt文件内容。
• Metadata Store：这是一个基于Cassandra的分布式hash table，用于存储URL内容的meta信息与URL的映射关系。同时对外提供实时的对metadata的请求服务。
• Content Store: 这是一个 HDFS 集群，用于保存所有抓取到的内容实体，协调器通过Scribe将数据写入HDFS中。

NoSQLFan后记：Cassandra曾因Twitter而一夜成名，尔后Twitter因为架构变迁放弃了Cassandra的使用，再到后面使用Cassandra的一些大公司相继出现一些问题，导致Cassandra最近一直不温不火。此次在实时URL抓取服务SpiderDuck中，Twitter使用了Cassandra来存储重要的metadata信息，相信对各位持观望态度的同学又是一记强心针。

SpiderDuck的详细介绍，可以参见原文：engineering.twitter.com