当前位置:首页 >> 互联网 >>

分布式搜索引擎设计与实现_图文

中国科学技术大学 硕士学位论文 分布式搜索引擎设计与实现 姓名:李伟 申请学位级别:硕士 专业:模式识别与智能系统 指导教师:朱明 20060501

摘要
在网页如此繁多的今天,人们在互联网上查找各种信息,往往都需要借助互联网搜索引 擎的帮助。本文就是要设计一个针对互联网搜索的大规模分布式搜索引擎。 互联网搜索引擎系统一般由四个主要部分组成:爬虫子系统,存储子系统,索引子系统, 门户子系统。首先爬虫子系统通过网页链接爬行互联网,将网页或者其他Web对象抓取下 来,保存到存储子系统;索引子系统从存储子系统获取未索引的网页,计算索引数据,建立 索引。门户提供一个用户交互界面,用户搜索互联网时,在门户上输入查询关键字,门户建 立查询语句发送到索引子系统,查询关键字对应的网页,然后返回给用户。 本文实现了互联网搜索引擎中的核心功能,完成了一个基本的面向大规模互联网的分布 式搜索引擎平台。在分布式爬虫子系统中,多个爬虫应该避免重复爬行,本文按照URL的 Hash值为每个爬虫分配一个URL空间,互不重叠,并通过调整爬虫爬行的URL空间来进 行负载均衡。另外,本文实现的爬虫系统可以同时支持IPv4和IPv6网络。存储子系统由若 干个存储组构成,每个存储组存储互不重叠的一个URL空间的Web对象,由主服务器发布 这一存储策略。通过扩展存储组可以不断提高整个系统的存储容量。每个存储组又由若干个 存储单元组成,它们存储完全相同的数据,即所有的数据都是多备份的,保证数据安全,并 可以提高数据访问的并发能力。外部客户端访问存储子系统根据主服务器发布的存储策略直 接访问,数据访问过程中,无需主服务器参与,主服务器不再成为频繁数据访问操作下的瓶 颈。索引子系统分为两个部分,索引计算和索引服务。索引计算子系统从存储子系统下载待 索引数据建立索引,并发送给索引服务子系统。为提高索引计算的可靠性,索引计算服务器 与存储子系统的存储组采用多对多的关系,即多个索引计算服务器同时计算多个存储组上的 待索引数据。存储组提供FTP服务,一次只允许一个索引计算服务器下载待数据包,下载 完毕,将该数据包移动到待删除目录,从而避免了多个索引计算服务器同时下载计算相同的 索引。索引服务子系统中各个索引服务器上都存储所有的索引数据,保证索引数据安全性。 本文的各个子系统都采用基于策略的分布式架构,策略描述了系统内部服务分布情况, 以及访问这些服务应该遵守的接口,由主服务器制定和发布系统服务访问策略。系统内部各 个服务器都按照策略规定提供服务,成为一个独立的自治系统,相互之间直接协调工作。外 部客户端访问系统提供的服务也是按照策略直接访问,不需要主服务器参与。这种服务访问 方式极大地提高了系统扩展性,使主服务器不再成为系统瓶颈。同时也提高了系统性能和可 靠性(主服务器宕机时,整个系统仍然可以在一定程度上继续提供服务)。 目前搜索引擎厂商的Web存储系统解决方案都没有公开,只有Google提到它的Web 存储建立在Google文件系统之上,也没有公开详细的Web存储设计。本文详细描述了所实 现的搜索引擎中Web存储系统的解决方案。为了提高性能,简化数据访问模型,本文设计 的Web存储系统不再建立在分布式文件系统之上,而是采用基于策略的分布式架构,由每 个存储组自行存储、组织和维护Web对象,主服务器不维护Web对象元数据,也不参与具 体的数据访问。外部客户端需要访问存储服务,只需要按照访问策略直接访问相应的存储组。 搜索引擎中的所有服务器都是采用廉价的PC机,各种软硬件故障在所难免。为了在不 可靠的软硬件系统上建立一个稳定可靠的搜索引擎,系统中的每个服务器都与其他一些服务 器维持心跳,持续检测各种异常情况,及时处理错误。重要数据都有多个备份,并能通过简 单的数据复制进行快速灾难恢复。 总体上,本文实现的搜索引擎具有很好的可扩展性、高性能和可靠性,解决了分布式互 联网搜索引擎中爬虫系统、存储系统和索引系统中的若干问题。 关键字:搜索引擎网络爬虫Web存储索引分布式


Abstract
Today,people find all kinds of information Internet search engines We
are on

the Intemet usually rely

on

the help of the

designing



large—scale distributed the tnternet search engine here. of four main subsystem components:crawling subsystem, Firstly,crawling subsystem crawl

Generally,]nternet search engine consists storage subsystem,indexing subsystem,portal

WebPages th rough the pages links.and stores them in the storage subsystem.Indexing subsystem
downloads tile crawled pages,calculates index data The It builds up
a users

input several keywords to the portal
user

query,sends

to

index subsystem,gets the hit—pages,and return to the
core

We have implemented the
engine platform.In distributed

cotD,ponent of the

large?scale Internet distributed search


crawling subsystem,we assign

non—overlapped
carl

URL space,

according to URL hash value,to each of the crawlers.The crawlers

keep load—balance by The master

adjusting

the URL space.A number of storage teams constitute the Storage subsystem

ofthe system publishes the storage strategy.The strategy divides the URL space,and assigns each
to
one

storage team.Through expanded the storage teams Several storage cells constitute
ensure on a

can

constantly improve the system

as



whole storage capacity
more

team,and store identical data.They

are

backups ofall data,to
access

data security

It

can

also improve the parallel—aCCeSS capability.

Storage clients
master’s

the data

storage teams di rectly,according the storage strategy,without be


help

Master ceased to

frequent ope ration of the data

access

bottlenecks

Index

subsystem has two parts,the indexing and index service.Indexing subsystem downloads web page package from storage subsystem,calculates index data,and transfer it to index service subsystem. To improve the reliability of index calculation,multi indexers calculates the web pages storage teams.A storage team allows only
one one on

multi

indexer to download data packages through FTP at
not

time

When completed,tire storage team moves them out.The jndexers would
on

download

and calculate same index data The index data stores security ofthe index data. Each subsystem
uses

each index service server,ensuring the

the strategy—based distributed architecture.The strategy describes the
servers

distribution of services within the system,developed and published by the master,All within tire system provide services in accordance with the strategy
as an

independent autonomous
are

system They collaborate directly.Clients directly accessing the services with the strategy,and scalability there is
no

also in accordance system

need for

the nlaster involved.It greatly enhanced

In addition,it also increased system performance and reliability
are

Currently the Web search engine manufacturers thesis gives simpliey data
uses a

not

open storage system solutions.This To improve performance,

solution for internet search engine storing web pages
access

models,the Web storage system

no

longer based

on

distributed file system.It They maintain the

strategy?based distributed architecture,constitutes
master

from storage teams

Web objects all by themselves The
data access.Clients
access

does not maintain

objects

metadata,nor involved in

tile storing service directly according to the strategy.The whole system


eontinunously detects various exceptions,and deals with them in time.By this way,we build high availabi lity system from cheap,unreliable PCs. This thesis implements


reliable,scalable,high performance interact search engine And it

solved several problems in distributed crawling system,web storage system,index service system Keywords:search engine,web crawling,web storing,index,distributed system



j 2 3 4 5

背景与需求…… 目标…………. 重点问题解决方案 架构…………. 接口………….
5.1 5 2

外部接口… 内部接口. ……………………… …… … …… 如蛇钉甜卯 档弛跎”弛




功能与实现………
61 6.2

WSCMaster功能与实现…………
Storage Team Master和Storage

Cell功能与实现…………



系统测试与分析………………………………

第五章


分布式索引系统……………………………………
……


背景与需求 目标……

………………… …… …… …
… …

………… …… …… … … … … …


2 3 4 5

重点问题解决方案…………… 架构………………….. 接口………………
5 l 5.2 5.3 5.4

…………

…………………… ……… …………



索引计算系统的外部接口………… 索引计算系统的内部接口… 索引服务系统的内部接口


……
……… ……

索引服务系统的外部接口……………………

………………………..



功能与实现……………………………………………
6 1 6.2 6.3 6.4

IndexingMaster功能与实现…………………………. ………………………………………… Indexer功能…
Index Index

ServiceMaster功能…………… …………

………… ……

Server功能……………………………………



系统测试与分析………………

旺以∞£苫∞卯钉锯∞加¨ 乃 而"

第六章
I 2

总结……………………………………………
…………一…… …………………… … …… …………
…..

本文主要成果……… 进一步工作…
2.1 2.2 2,3

…… …

需要进一步扩展的工作…………………………… 需要完善的工作………………

需要研究的工作…………………………..………………

蚰∞引引跎昭 踮 % %

参考…………

………………………………………… ………


附录…………………………………………



发表论文………………………………………………………….

图序
图l Wikipedia链接图……………

图2中国搜索引擎用户不满意情况统计图

图3搜索引擎一般结构图……… 图4分布式搜索引擎一般结构图




图5分布式搜索引擎总体架构图…… 图6一般分布式系统架构图…… 图7分离数据流的分布式系统架构图 图8基于策略的分布式系统架构图… 图9爬虫系统在搜索引擎中的位置. 图10爬虫系统构架围……………一 图ll爬虫系统交互序列图……….
图12 Crawler Master系统结构图……

图13 Crawler系统结构图……… 图14爬虫系统下载曲线………… 图15服务器共享DAS设备……… 图16NAS存储系统…………….. 图17 SAN存储系统……………
图18 Web Storage Cluster架构图……

图19WSC交互序列图…………… 图20WSCMaster系统结构图……. 图21
Storage

Team系统结构图……

图22数据上传一对和一对多…… 图23多对多数据上传速度……….. 图24数据下载速度……… 图25索引系统结构图 图26索引系统交互序列图 图28 Indexer系统结构图 …… …… ……. H博悖旧∞丝N巧如弛 ∞“¨"钙铉”∞们:。∞佗乃"% ……………

图27 Indexing Master系统结构图….

图29 Index Service Master系统结构图 图30 Index Server系统结构图……..

表序
表格1爬虫策略发布接口消息格式定义表一
表格2爬虫心跳接口信息格式定义表 …. 表格3爬虫心跳接口消息格式定义表…. 表格4 Crawler之间接口消息格式定义表… 表格5 Web对象文件格式头部定义表 … 表格6 Web对象文件格式数据段定义表… 表格7 Web对象包文件格式头部定义表.… 表格8 Web对象包描述文件格式头部定义表 表格9爬虫实验机器配置表2…………. 表格10多台爬虫计算机测试数据表1…… 表格ll多台爬虫计算机测试数据表1…… 表格】2存储系统测试计算机配置信息表. 卯勰 四巧 %"强弛 鼹


表格13一对一传送速度(单位:lOobps)…………….. 表格14一对多数据传输速度(单位:loobps)…………. 表格1 5多对多数据传输速度(单位:10。bps)…………… 表格16一对一数据下载速度(单位:106bps)…………~ 表格17二对二数据下载速度(单位:100bps)
…………

表格18索引计算任务分配策略发布接口消息格式定义表… 表格19索引计算系统心跳接口信息格式定义表…… 表格20索引服务系统心跳接口信息格式定义表………… ………………… 表格21 10MB量级待索引数据计算 表格22 10MB量级原始数据索引后关键字查询命中数和时间 表格23 100MB量级带索引数据计算…………………一 表格24 100MB量级原始数据索引后关键字查询命中数和时间 招铋”∞ 铝∞加"孺弛为



918285

致谢
首先要感谢我的父母,是他们给了我生命,养育我多年。在我生活有什么不 愉快的时候,他们总是耐心的劝导我,安慰我;在我学习工作忙碌的时候,他们

都一直支持我,甚至劝我少打电话。每每想起父母的点点滴滴,心中总是无比温
暖和感激。而在异地求学的我平常都难得与他们见上一面,尽管我们彼此都非常 挂念。这学期毕业论文一直都非常忙碌,往家里打电话的时间也少了,很多时候 都没有好好跟他们聊聊天,心中很是愧疚。感谢弟弟在我离开的日子照顾父母! 作为兄长,我很少关心他的生活,倒是他总是反过来关心我,真是对不住。 导师朱明教授一直都悉心指导我学习工作,很多时候他的三言两语总是让陷 入迷茫的窝窝茅塞顿开。从他那里不仅仅学习到很多知识,更重要的,我还学习 到很多学习、工作的方法,这将使我受益终身。毕业论文一开始,朱老师就和我 们一起讨论搜索引擎中可能遇到的各种问题,详细讨论系统中各个模块的设计, 可能的难点,解决思路等等。毕业论文能够如期完成与朱老师的指导是密不可分 的。在这里我要说一声,朱老师,谢谢您的指导!感谢您多年来的教诲! 本课题组的王海洋、周家明、蒋澜以及早期参加的刘守群、朱超、徐锦等, 感谢你们的努力工作,也感谢你们在集体讨论中贡献出你们的智慧,有了你们的 帮助,整个搜索引擎才得以实现,本文也才得以完成。 高小波、梁荣龙、庞勇强、王胜,还有胡冰和我一起在这个实验室走过了三 年,平常生活、学习、工作中,都得到你们的大力帮助,我们也互相讨论各种问 题,经历这么多年,我们已经成为最好的朋友。前几天,王胜和他老婆去领结婚 证了。能够找到一个共度~生的伴侣,生命有了归宿,真是大喜啊!真的好羡慕 你们,祝福你们生活幸福,白头偕老。 同实验室的郭春茂、李香、杨扬、钟捷飞:宫涛、戴洪、周军等都给我各种 帮助;室友、很多本科同学以及其他同学,哦,还有身在海外的朋友们,在此一 并感谢你们的关心、帮助与支持。 不久就要离开这个美丽的校园了,在这里,我已经度过了七个春秋;在这里, 我经历了人生最珍贵的一段日子;也是在这里,我学会了很多知识、懂得了做人 的道理。感谢你,我的母校【

第一章绪论

第一章绪论
1互联网搜索引擎的历史与发展
1.1互联网的历史与发展
1958年1月7日,美国政府由于国防需要,在五角大楼成立了国防前沿研究项目 署(ARPA)‘。1960年,ARPA研发了第一个计算机互鞋网络ARPA网,1974年ARPA 的鲍勃-凯思和斯坦福的温登?泽夫提出TCP/IP协议!,并在1983年将ARPA网的核 心协议由NCP。改变为TCP/IP,即现在的互联网基础协议。在J986年,美国国家科学 基金会(National Science Foundation,NSF)建立了大学之间互联的骨干网络NSF net,

这是因特网历史上重要的一步。由于NSF网对全社会开放,得到了极大的发展,迅速
取代ARPA网,成为国际互联网络的主干网4。1994年,NSFNET转为商业运营5。 在互联网发展到同时,1991年8月6日,Tiin Berners—Lee在CERN(欧洲原子能 研究组织,European
Organization for Nuclear

Research)经过两年的努力,终于在新闻
TextMarker

组上发布WorldWideWeb项目,即今天的万维网。万维网通过HTML(Hyper Language)标记语言编写网页,通过超链接把网页组织在一起,如下图:

图l Wikipedia链接图 这是wikipedia网站链接图,从Wikipedia主页出发,会链接到Wikipedia的各种语 言的子网站,以及Yahoo,Google等其他网站。而这些网站也会链接到更多得其他网站, 这样就将整个万维网链接起来,从而可蚪简单方便的互相访问。
‘文献【1


J正文第6页 Program,参看文献【341,网址:http://enwikipediaorg/wiki/Network_Coatrot—Program

:当前互联网的基础协议,参看文献『321,N.kt::http://zhwikipedia org/wiki/TCP/IP
’NetworkControl

4参看文献f3 I] 5参看文献【3 2],网址:http://zhwikipedia org/wiki/%E4%BA%92%E8%81%94%E7%BD%9I

第一章绪论

万维网一经推出就得到了极快的发展,如今已经成为互联网上最重要的应用。各种 传统的应用分分向www整合,比如传统的Email,BBS等网络系统。另一方面,新 的基于WWW的应用也层出不穷,比如Blog,Wiki等等。经历了十几年的发展,WWW 正变得更加繁荣。

1.2搜索引擎分类
随着www内容越来越繁多,人们查找想要的内容也变得越来越困难,互联网搜 索引擎的出现很大程度上解决了这个问题。通常人们把目录检索系统也成为搜索引擎, 比如很著名的雅虎Web目录。但是它与本文所研究的搜索引擎存在着很大的差别,很 多学者也认为它并不是严格意义上的搜索引擎。搜索引擎的一个重要特点是,根据要检 索的内容构造索引倒排表。查询时从倒排表索引中找到相关内容的文档,这是目录检索 系统并不具备的。 搜索引擎的分类方式很多,目前也没有很统一的分类表。本文在参考了很多搜索引 擎分类,并考察了目前广泛应用的搜索引擎系统后,总结出如下分类: 按照搜索的范围,搜索引擎可以分为: ”桌面搜索引擎。桌面搜索引擎的目的为了方便个人电脑用户查找自己计算机 上的文件,通过对个人电脑上的文件建立索引,加快查找速度。目前Google 以及其他几家公司都已经推出,或者正在开发桌面搜索引擎产品。 2)企业搜索引擎。企业搜索引擎主要是针对企业用户对企业局域网和其他共享 资源建立索引,方便企业用户查找内部资源。目前Google、IBM等几家公司 已经推出了相关产品。 3)互联网搜索引擎。面向整个互联网资源的搜索引擎,通常由爬虫机器人自动 从互联网搜集资源,然后建立索引,供用户查询。目前已有一大批互联网搜 索引擎厂商推出了相应产品,如Google,Msn,百度等等。 按照搜索的文档类型,搜索引擎又可以分为:

1)网页搜索。网页搜索是目前互联网搜索引擎最主要的搜索内容,援索内容集
中于互联网页面。 2)图片搜索.图片搜索是近几年出现的针对互联网图片的一种搜索,Iq前技术 能力的限制,图片搜索还不能根据图片画面内容来搜索,只能通过图片所出 现的上下文文字,以及图片所包含的元数据信息来搜索。 3)音频搜索,与图片搜索类似,音频搜索主要检索互联网上出现的各种音频文

件,如mp3等。由于音频文件一般都有元数据信息、,因此建立索引检索比较
容易。另外对于歌曲,往往还会有相应的歌词搜索。 4)视频搜索。视频搜索是最近几年才出现的,与图片搜索和音频搜索类似,搜 索内容集中于视频短片。视频搜索的推出一方面得盏于搜索技术的日益成熟, 另一方面是由于宽带互联网的推广。 5)文档搜索。文档搜索一般应用于桌面或企业搜索引擎中,搜索的内容主要限 于常用的文档类型,比如Word,Excel,PPT,PDF,以及电子邮件等文件。 按照搜索的互联网内容,可以分为: 1)一般网页搜索即针对普通网页的搜索引擎。 2)新闻搜索,主要针对实时新闻内容,搜索引擎往往爬行大量新闻门户网站, 对爬行得到的大量新闻内容建立索引,供用户搜索。另外搜索引擎还往往对 新闻资讯进行聚合,推出新闻服务。


第一章绪论

3)BT搜索,由于P2P技术的流行,BT搜索也应运而生,专门针对BT种子发 布的一种搜索引擎,往往会汇集很多BT种子发布网站的种子供用户搜索。
4)

RSS搜索,随着RSS技术的流行,也出现了很多相应的RSS搜索引擎。

5)Blog搜索,由于Blog的流行,很多搜索引擎厂商也推出了相应的Blog搜索 引擎。Blog往往都具有类似的信息结构,并且大部分可以都通过RSS发布, 更新速度陕,因此搜索引擎厂商往往针对Blog推出专门的搜索引擎。 6)学术搜索,很多科研工作者在研究某个课题时,往往需要查阅大量的论文, 学习其他工作者的研究成果。虽然很多杂志社和专门的学术数据中心都有专 门的学术论文搜索引擎,但是下载论文往往需要支付一定的费用,并且这些 系统各不相通,用户往往需要查阅很多个这种数据中心才能得到比较全面的 资料。学术搜索针对这一需求,利用爬虫技术自动从互联网上获取大量论文 资料,建立索引。由于很多论文作者会把自己的论文发布到gt己的个人主页 上,从这些地方就可以免费下载论文了。 按照搜索内容所属的行业.可以分为:通用搜索引擎和行业搜索引擎。通用搜索引 擎即针对普通网页的搜索引擎,而行业搜索引擎则是指针对某一行业信息的专门搜索引 擎,比如工作就业,商品等。 还有一种分类方法是按照搜索结果来源,一般搜索引擎都是从互联网爬行网页,建 立索引,然后查询索引数据库得到搜索结果,返回给用户。元搜索引擎则不同,它本身 不爬行互联网网页,它的搜索结果来源于其他搜索引擎。用户搜索时,它将搜索语句发 送给其他搜索引擎,其他搜索引擎返回结果后,元搜索引擎将这些结果整合在一起返回 给用户。元搜索引擎极大的提高了搜索的查全率,但是搜索效率方面要低一些。

1.3互联网搜索引擎的历史与发展
1990年初,当时万维网(World Wide Web)还未出现,为了查询散布在各个分散的主

机中的文件,曾有过Archie、Gopher等搜索工具,随着互联网的迅速发展,基于H丌P
访问的Web技术的迅速普及,他们就不再能适应用户的需要。在1994年1月,第一个 既可搜索又可浏览的分类目录EINet
Galaxy(Tradewave

Galaxy)上线,它还支持Gopher

和Telnet搜索。同年4月,Yahoo目录诞生,并开始支持简单的数据库查询,获得了巨 大的成功。这就是早期的目录导航系统,网站收录和更新都是要人工维护的。在信息量 剧增的条件下,就变得难以及时更新与维护,运行成本也极高。 1994年7月,Lycos推出了基于robot的数据发现技术。通过机器人程序自动从万 维网上搜集网页。并支持搜索结果相关性排序,并且最先开始在搜索结果中使用网页自 动摘要。1nfoseek也是同时期的一个重要代表,他们是搜索引擎史上一个重要的进步。 1995年12月才登场亮相的AltaVista推出了大量的创新功能使它迅速到达当时搜索 引擎的顶峰,它第一个支持自然语言搜索的搜索引擎,具各了基于网页内容分析,智能 处理的能力,第一个实现高级搜索语法的搜索引擎(如支持AND、OR、NOT等), 同时AltaVista还支持搜索新闻群组(Newsgroups),搜索图片等具有划时代意义的功能。 同时期还有inktomi、HotBot等搜索引擎。 1997年8月Northernlight公司正式推出搜索引擎,它第一个支持对搜索结果进行 简单的自动分类,也是当时拥有最大数据库的搜索引擎之一。 1998年10月,Google诞生。由于它具备很多独特而且优秀的功能,比如优秀的
Page

Rank算法,高效迅速的搜索速度等等,并且在界面等实现了革命性创新,简洁易

第一章绪论

用,支持多种文件格式,支持完整字符串查找,拼写检查等等实用功能,成为目前最流 行的搜索引擎之一。 在中文搜索引擎领域,1996年8月成立的搜狐公司是最早参与作网络信息分类导 航的网站,曾一度有“出门找地图,上网找搜狐的”美誉。由于其仿效雅虎,采用人工 分类提交的方式整理网络信息,随着网络信息的巨增,逐渐被基于robot自动抓取智能 分类的新一代信息技术取代。 北大天网是教育网最流行的搜索引擎,它由北大计算机系网络与分布式系统研究室 开发,于1997年10月29日正式在CERNET上提供服务,2000年初成立天网搜索引 擎新课题组,由国家973重点基础研究发展规划项目基金资助开发,收录网页约6000 万,利用教育网优势,有强大的FTP。搜索功能。 百度中文搜索由超链分析专利发明人、前Infoseek资深工程师李彦宏和好友徐勇 2000年1月创建,目前支持网页信息检索,图片,Flash,音乐等多媒体信息的检索。7 由于多年的中文分析技术积累,目前在中文搜索领域领先于业界最大的搜索引擎
Google。

2004年8月19日,Google在NASDAQ上市,取得了巨大成功,让很多公司重新 认识到搜索引擎市场的重要性,分分进入。IBM和Oracle等巨头都推出了面向企业的 搜索引擎,而Google和Microsoft则展开了桌面搜索引擎的竞争。2005年,Microsoft 投入巨大的人力物力加大搜索引擎的研发,目前己推出beta版本,正在评估。集成很 多新的功能,支持网页、新闻、图片、桌面搜索、本地搜索、词典、百科全书、股票、 电影、购物与音乐等各种信息检索,并引入前卫的自动翻泽搜索。比如用户想搜索“搜 索引擎”,msrl search会同时返回与搜索引擎相关的英文网页。 Web搜索技术的进步极大地提高了人们获取信息的效率,甚至影响了人们使用互 联网的方式。在若干年以前,人们上网通常都是通过Web链接一页一页的浏览自己感 兴趣的文章。用户往往会收藏大量的书签,帮助自己记住喜欢的网站,并花费不少时间 来维护这些书签,规整分类。由此也曾经出现过收藏上千网址的书签软件。而现在,大 多数人在互联网上寻找自己感兴趣的文章时,只需要在搜索引擎里面敲几个关键字,书 签已变得并不是那么重要了。

2互联网搜索引擎的最新现状
2.1

Web最新动态
在进入21世纪的几年里,Web世界发生了巨大的变化,正向着Web 2.0演变。虽
然Web 2 0的相关技术已经有了多年的发展,但是Web

2.0这个概念却是近几年才提出

来的,并且,至今还没有一个被广泛接受的定义。下面列举一些Web2 0的概念或者描 述性文字:
“Web 1.0
was

making theInternet for people;Web 2.0 is making the Internet better for

computers”一Jeff Bezos8 Jeff

Bezos是从Web服务对象的差别上来说明的,Web



0让人们能够使用Internet,

而Web 2.0则是让计算机能够使用Internet,即计算机更容易理解、处理Web信息,从


File+rransttr Protocol,在网络上进行文件传输的一套标准协议,参看文献【4 3l 7参看文献【3 21,网址:http://zh wikipedia org/wiki/%E6%90%9C%E7%B,I%A2%E5%BC%95%E6%93%8E

8文献『3 31

第一章绪论

而给人们提供更加智能、优质的服务。在目标上与语义网络相近了,但是不同的是,
Web 2.0是从传统的Web 1 0开始演化的,虽然吸收了很多语义网络的元素,但至少从

目前来看,Web



0还不能算是真正的语义网络。
to


Web 2.0 generally refe rs

second generation of services available share information experience closer
to

on

the World
to

Wide
first the

Web that lets people collaborate,and generation,Web 2.0 gives
traditional static Web pages。
use rs an

online desktop

In

contrast

the

applications than

上面这段文字出自维基百科词典“1,反应了目前想当一部分人对Web 它从两个方面来说明Web 享:与Web




0的认识。

0的概念:功能上是让万维网更好的方便人们协作与信息共 2.0让万维网的体验更接近桌面应用。本文认为,功能上的


1 0相比,Web

说明是比较正确的,而与Web

0的对比却显得很不足,因为Web 2.0不仅仅只是在

Web 1 0的基础上增加了更好的用户体验。

这里,本文试着描述一下Web 2.0的相关内容。 首先,从名字上看,Web 2.0这种命名方式源自于应用软件开发。在应用软件开发 中,版本是衡量一套软件更新的标志,新版本的软件往往完善了老版本中的不足,并增 加了新的功能。软件版本号越大,往往意味着软件作者认为软件的功能更强大,更完善。 随着软件业的成功,软件开发中很多重要经验逐渐被与之相关的、甚至不相关的各种事 务所吸收,版本管理也是。既然Web采用了版本这种命名方式,就意味着相对于前一 个时期,Web在使用功能上有了比较大的改进。 从功能上看,Web 2.0与前一时期相比,有哪些改进呢?首先来看看一些典型的
Web 2.0实例。人们认为Double Click“是Web 1.0的,而Google AdSense“是Web 2.0

的:Ofoto”是Web 等。我们把Web



0的,而Flickr“是Web 2.0的。Google Map”是Web 2.0的,…等 2.0的实例进行比较,Double Click和Google AdSense都是

l 0和Web

通过Web做广告,DoubleClick主要做用户点击信息的收集统计工作,而GoogleAdSense 则会根据J。‘告所在的Web页面内容生成与之相关的广告能起到更好的广告效果。Ofoto 是柯达提供的Web图片存储服务,允许用户上传自己的图片,并且可以在移动设备中 随时查看自己的图片;而Flickr除了允许用户上传图片外,还允许用户使用Tag进行 分类,添加一些图片信息,方便其他用户检索,不但用户自己可以查看自己的图片,用 户之间也可以进行图片共享。Google Map则是Web 2.0时代新出现的Web应用,这类 应用可以方便用户采用可视化、交互式的方法查找地图,乘车路线,购物,餐饮,住宿 等等。从GoogleAdSense可以看到,Web 2.0更加智能地服务用户;从Ofoto可以看到,
Web 2.0更注重资源共享:从GoogleMap可以看到,Web 2.0更注重用户交互。从Gmail

Talk…可以看到,Web 2.0为用户提供无须安装即可随时随地使用的应用。还有Blog,
SNS(SocialNetwork System),PublicWebServiceAPl…,Live Service(LiveApplication, Live]nstant

Message,etc)等等。综合起来,Web 2.0的功能即,使用Web技术为用户

提供智能的、高度交互性的服务,更注重用户资源共享,提供随时随地即可使用的各种

9文献【3 4】,刚址:http://enwikipedia org/wiki/Web 2.0

“’互联网上基于Wiki系统的百科全书,网址:http://wwwwikipedia org ”DoubleClick是一家提供基于Web的点击广告公司,是业内的领导者。
11

Google推出的广告服务,能够根据Web页面内容自动生成与内容相关的广告。 ”柯达公司推出的Web图片上传服务。 “是一个提供用户图片上传分享的网站。 ”Google公司推出的在线地图搜索服务。 …Gmail是Google公司推出的Email服务,Gmail Talk是在Gmail里面集成的及时消息服务([nstan
Message)。
“API,Application Programming

Interface,应用编程接口

第一章绪论

丰富的、可媲美桌面软件的应用。 从技术上看,Web 2.0采用了一系列新兴的技术。
1 AJAX(Asynchronous JavaScript and

XML)”。AJAX是使用JavaScript语言…


编程,采用XML”表示数据,实现与Web服务器端进行异步数据通信的~套 技术。为了加强用户体验,让Web也能像桌面应用一样,Web 0应用中广泛 使用AJAX技术。在传统的Web交互中,需要Web服务器端支持的操作、 数据访问等都需要卸载当前页面.连接到服务器端,装载新页面这一系列操作。 如果页面较大,则装载新页面需要花费很长时间,给用户带来不快。而采用 AJAX技术则可以不必刷新整个页面,直接在后台与Web服务器端通信,获 取需要的数据(数据采用XML描述),然后再更新页面中相应的区域。AJAX 不但可以给用户带来类似于桌面应用的体验,还可以减少数据交互量,减少带 宽开销,也更快速。
2.

Web Service“。Web Service定义了一套基于XML数据交互,建立在Web访 问的HTTP(Hyper Text Transfer Protoc01)“协议之上的远程服务访问规范。

它的核心内容包括SOAP(Simple Object

Access

Protoc01)“,WSDL(Web

Service Description Language)24,UDDI(Universal Description,Discovery and

Integration)。等协议。Web Service作为良好的跨平台互操作解决方案,得到 了越来越多的厂商支持,很多厂商都发布了自己的Web
Service

API,甚至还

有很多免费的API。通过Web Service方式使用厂商提供的服务,可以简化整 合各种服务,构建复杂的系统,为用户提供更加丰富全面的服务。比如一些厂 商提供旅游景点服务,另一些厂商提供地图服务,还有订票服务,餐饮、住宿 服务等等,那么就可以很方便的整合他们的服务,提供旅游、旅行一条龙的综 合服务。
3.

Blog?o。BIog原名为Web Log,即Web目志,简作Blog。Blog大大简化了人 们在Web上发布自己的言论、文字,形成自己的文集。在Blog出现之前,在 Web上发表白己的言论及其他文字是比较困难的,需要专门的网页制作知识, 以及网站(或者托管的主页空间)维护技能。Blog的出现使得人们只要会上 网,会打字就可以发布自己的文字了。除了能够书写自己的文字外,一般还可 以让阅读者评论、留言,方便作者与读者交流。Blog最大的贡献在于,它使 得任何人都可以方便的发布信息,信息的发布去中心化,不再由少数公司垄断。 目前很多Blog服务提供商推出Blog服务,让成千上万的用户可以撰写自己的 文字,形成Blog社区。服务商通过分析社区中的所有Blog,为社区提供智能 化的聚台、推荐服务。



Wiki。源自夏威夷语的“wee

kee wee

kee”,本是“快点快点”之意。在这里

Wiki指的是一种超文本系统,是支持那些面向社群的协作式写作,同时也包

8参看文献【34】,网址:http://en wikipedia org/wiki/AJAX ”一种处理网页的脚本语言,最初由网景通讯公司所开发,后来提交给ECMA(欧洲计算机制造协会)成 为标准脚本语言.称为ECMAScript。
2。EXtensible

Markup Language,可扩展标记语言。参看文献[27】 ”参看文献[3 6】,网址:http://www.w3 org/2002/ws/ 翌参看文献[3

6】,网址:趣l!主丛婴业丑型坐趔{,!业

D参看文献【36],网址:皿P:童!坐!坠立t!g二Ⅱ蝰盟瞳

l参看文献n6],网址:旦J旺立坠竖蔓必螋。出型蚓』
”参看文献f3 71 ”参看文献『3 21,网址:

http://zh wikipedia orgA~iki/Btog#E488AD E6 96 87 E8AF9l E5 90 8D E4 BA 89 E8AEAE



第一章绪论

括一组支持这种写作的辅助工具。与其它超文本系统相比,Wiki有使用简便 开放的特点,所以Wiki系统可以帮助我们在一个社群内共享某个领域的知识 “。Wiki与Blog在形式上有一些相似,都是允许用户编辑发表自己的文字, 而不需要专门的网页制作知识。目前最成功的Wiki系统应该是维基百科 (Wikipedia)了,它是一个网络上的百科全书,拥有目前几乎所有的常用语 言的子站,其英文主站已有一百万多个词条“,中文子站建立于2002年,也 有6万多个词条“。维基百科在GNU自由文档许可证下发布,任何人都可以 自由的使用甚至修改它所列出的词条,只需要保留它的版权声明即可…。除维 基百科外,还有很多基于Wiki系统的社群,只要有一个对某事物或领域感兴 趣的群体,以及一个Wiki系统,就可以通过协作的方式共享他们的知识。


RSS。RSS是一种用于共享新闻和其他Web内容的数据交换规范,起源于网 景通讯公司“的推”Push”技术,将订户订阅的内容传送给他们的通讯协同格式 (Protoc01)。RSS可以是以下三个解释的其中一个:
?

Really Simple Syndication

?

RDF(Resou rce Description Framework)Site Summary
Rich Site Summary

?

但其实这三个解释都是指同一种Syndication的技术,虽然具体的协议格式有 些不同,但往往都包含文章标题、发布时间、作者、内容摘要等信息。RSS 目前广泛用于Blog、Wiki和网上新闻频道,世界多数知名新闻社网站都提供 RSS订阅支持“。如果网站提供RSS订阅服务(提供的链接往往称为种子 Seed),那么用户就可以不必打开网页,而是通过RSS阅读器就可以了解该网 站的主要内容了。比起浏览网站来,RSS有两个方面的特点:它是一种推送服 务,即RSS阅读器可以在后台更新RSS种子,用户随时都可阻阅读。其次, RSS仅提供文章摘要,下载快速,阅读简洁。由于RSS的流行,大量网站, 特别是一些Blog系统都提供RSS订阅服务,而用户往往会发布很多内容相似 的甚至完全相同的文章,为了节约用户时间,很多服务商提供RSS聚合服务。 RSS聚合不但可以帮助聚合重复的文章,还可以通过统计等方法,将最热点的 文章发送给用户。还有一些厂商推出基于用户兴趣的RSS聚合服务,对用户 兴趣进行建模,将用户最可能感兴趣的文章发送给用户。


在线应用(LiveApplications)。在线应用是近年兴起的一种Web应用模式,它 将传统的桌面软件迁移到Web平台上,从而带来了一系列优点:软件无需安 装和维护;随时随地,只要能上网就可以使用;方便用户西同工作:降低软件 成本,等等。当然也有一些缺点,它要求用户必须能够连接到互联网(在互联 网如此普及的今天,这个条件已经不难满足了);用户界面不如桌面软件友好。 比较著名的在线应用有:writely川,irowsH,Thurnbstacks”,office】ire”,windows

”参看文献[1 9参看文献【3

2】,网址:i盥!!也幽k 12幽!“』!型!!幽!燮l堑

孔参看文献【3 4].网址:M正2迅、!ISlE型19:堕然世L型;业!:a盐
如GFDL(GNU Free Documentation License),详细声明参看文献【3 81

2],网址:皿o!业必K』B翊丝型盟!j燮'一a1.9一%A一6%9~6":;,E…9%A—I㈦一5

“曾经著名的NetscapeNavigator浏览器生产商,网址:http://wwwnetscape ”参看文献f3

一个在线的字处理软件,类似MicrosoftWord,现在己被Google收购,网址:hap://www.writely “一个在线的表格处理软件,类似Microsoft
Excel,网址:httpJ/www irows COl_Iq/
microsoft toni/

21,网址:地必兰丛出血西丛嵝世』主婪

corn/

corn/

”一个在线的幻灯片制作软件,类似Microsoft.PowerPoint,网址:http:ffwwwthumbstacks 如微软推出的在线办公软件,网址:htlp://officelive

corn/

第一章绪论

live”等等。
7.

智能化信息过滤技术。Web 2.0应用中,大量使用各种智能化的信息过滤技术, 减轻用户处理信息的负担,为用户提供更有价值的信息。
?

聚合技术。目前,很多RSS在线阅读系统,新闻聚合服务等,都使用了 智能化的聚合技术,将网络上很多重复的、内容相似的、热点的文章聚合 到一起,供用户阅读。 协同过滤技术。Web上的内容,网上商城的商品等等往往都有着很密切 的关系,用户可能同时关心若干个对象,而某些用户关心的对象,其他很 多用户可能也很关心。针对这一需求,很多网站都开始采用协同过滤技术, 将用户可能关心的对象推荐给用户,而不再是让用户去慢慢寻找。 Amazon”是这一技术应用最成功的网站之一,它通过用户浏览、购买商 品的信息,计算商品之间的关联度,在用户浏览商城的时候为用户推荐他 可能喜欢的商品。 用户个性化建模技术。除了通过用户协同过滤、物品协同过滤等技术外,
Web 2.0网站(或者应用)还常常采用用户个性化建模技术,分析用户行

?

?

为,对用户兴趣进行建模,帮助用户迅速找到感兴趣的信息,去除用户不 感兴趣的信息。目前Google正在推出个性化搜索服务,帮助用户找到感 兴趣的搜索结果。
Web 2.0无疑是近年来Web上最大的变化,除此之外,Internet的其他方面也发生

着巨大的变化:网络条件大幅提高,宽带应用逐渐推广;IPv6”网络稳步发展;多媒体 技术的广泛应用;移动计算无处不在等等。 在电子拍摄、录制设备变得越来越易用,各种图像、音视频处理软件变得越来越强 大,并且都越来越价廉的今天,普通大众的创造力被极大的激发出来,创作了无数的生 动、活泼、优秀的多媒体作品,发布到Web上。优秀的软件作者们也分分将自己的作 品通过共享,或者免费的形式发布到Web上。普通用户也将自己喜爱的电子书籍、文 档发布到Web上。这使得Web的表达能力更强,也变得更加丰富多彩,让用户对Web 内容更感兴趣。 由于IPv6技术与现有的IPv4”技术并不完全兼容,直到近儿年,lPv4地址资源逐 渐枯竭,IPv6应用也开始稳步发展,IPv6资源也逐渐丰富起来。基于IPv6的Web应用 发展得更加迅速,并且很多IPv6站点通常都同时兼容IPv6和IPv4。 虽然Web内容如此丰富多彩,但绝大多数用户都是通过Pc“来访问。Pc通常都比 较笨重,不易携带,并且往往通过固定网络接121连接到互联网,因此移动性很差。即使

现在笔记本电脑和无线网络开始流行,但仍然不够方便。另一方面,移动电话(手机)
在移动性上有着天然的优势。移动电话小巧轻盈,移动服务提供商又往往提供覆盖率极 高的无线网络,通信也成为日常必须,并且目前手机的用户量要远远大于PC的用户量。 如果能将二者很好的结合到一起,不论是对Web内容,还是相关的厂商都将产生极大 的影响。近年来,很多厂商部开始致力于移动计算的开发与研究,让广大的移动用户可 以轻松的访问丰富的Web内容,同时也让强大的Pc计算能够融入移动网络中。无论 是移动网络基础设施上,还是移动网络Web应用上都诞生了一大批新兴厂商。
”微软推出的在线服务平台,集成了多种日常应用。网址:http://www,live
corn

“Amazon是一家著名的网上商城,网址:http://www amazon corn/ ”Internet Protocol Version 6,互联网协议第六版,下一代互联网网络协议,参看文献【4 l】 如]memet Protocol Version 4,互联网协议第匹I版,目前主流的互联网网络层协议,参看文献f4 21
…Personal

Computer,个人电脑

第一章绪论

2.2

Web搜索最新动态
Web搜索的新问题
随着Web资源爆炸式的增长,Web搜索应用越来越多,越来越广,搜索技术的研 究不断深入,Web搜索也突现出越来越多的问题。 在2006年2月iResearch42市场咨询根据Keynote43的数据分析,总结出了目前中国 搜索引擎用户的不满状况“,如下图显示:

2.2.1

中国搜索引擎用户不满意因素及比倒
挺索措果!复

挺宋洁累排序置佳

挺索结果烹杂乱

槌宋涫果下音时宜

广告过予



㈣40再
口比例

图2中国搜索引擎用户不满意情况统计图 如图所示,尽管搜索引擎为用户在网上快速检索信息提供了极大的方便,但仍然存

在着很多问题,难以满足用户需求。并且随着Web的快速增长,这些问题变得越来越
严峻,甚至出现了很多新问题。 由于越来越多的公司或者个人对搜索引擎技术和网络爬虫技术的热衷,网络上出现 了各种各样的爬虫程序,夜以继日的在网络上爬行,获取网页。由于网络爬虫是通过程 寿爬行网页的,会快速的爬行大量网页,普通用户只会慢速浏览。正是由于网络爬虫的 快速爬行,它对网站造成了巨大的冲击,甚至形成DoS”攻击,影响正常用户访问。一 方面网站希望能够被搜索引擎检索到,方便需要访问的用户查询:而另一方面,由于网

络爬虫对网站会造成巨大的压力,影响正常用户,并且加大网站流量,从而影响网站运
营成本。人们试图采取一些方法来解决这个问题: 1)在网站根目录下放置robot.Ixt,给出搜索引擎的爬行策略,降低爬行压力。 2)采用权限管理方法,在网站首页放置登录界面,使搜索引擎无法访问网站内容。

也是一家致力于网络媒体、电子商务等新经济领域研究,提供咨询服务的公司。网址:
http:Hwww iresearch
COlTI

cn/

郫是一家为电子商务、在线业务领域提供服务的公司,嗣址:http://www keynote corn/ “http:/1wwwireseareh com cn/html/search_engine/detail_views_Id-26311.html 盯Deny ofService,网络攻击的一种,极大的降低服务器对正常用户的服务质量.甚至无法提供服务。


第一章绪论

3)使用脚本技术隐藏网页链接。由于普通的网络爬虫都仅仅针对网页链接进行爬 行,在链接被脚本隐藏时,往往变得无能为力。 4)使用蜜罐技术“,捕杀网络爬虫。 5)一些大的搜索引擎厂商开放自己的资源库,让很多企业和普通用户都可以在他 们提供的资源库基础上建立自己的搜索引擎,而不用重复爬行网络、建立索引 等等。 今天,搜索引擎已经成为人们上网必不可少的重要工具。但是用户一般只会查看搜 索结果的前几页,如果找不到需要的信息,用户往往会没有耐心在结果中浏览。如果某 个网站能够在搜索引擎检索相关内容时,出现在搜索结果的前面,无疑对网站起到了很 好的宣传作用。于是很多网站针对搜索引擎的工作机理来设计网站,以期提高网站在搜 索引擎中的排名。比如针对目前搜索引擎采用的两种主要排序策略(相关度4 7和Page Rank算法“),通过在网页中加入很多用户不可见的、并且甚至与网页内容并不相关的 热门关键字,链接等等。甚至出现了一批专门帮助网站提高网页搜索结果排名的公司。 由于搜索结果排名有着如此好的宣传效果,很多搜索引擎厂商提供搜索排名竞价,允许 网站运营商通过购买的方式来提高网站在搜索结果中的排名。而另外一些厂商,比如 Google,则认为竞价排名影响搜索结果的公平性,拒绝这种商业模式。 目前的网络爬虫基本上都不具备网页脚本(JavaScript,VBScript49)的解析能力,

而AJAX技术却越来越流行,对于这种使用脚本点击代替传统链接的页面,网络爬虫
往往无能为力。 由于Web的爆炸式增长,Web咧页数量极大,并且还在飞速的不断增加,网络爬 虫完整的爬行一遍整个互联网都是完全不可能的。即使使用一些爬行策略,放弃一些不 太重要的信息,不进行深度爬行等等,更新爬行到的互联网数据也是十分漫长的。而某 些互联网应用却是变化很快的,比如新闻门户,BBS社区,Blog,Wiki等等。这些应 用每天都会增加很多内容,目前通用搜索引擎对这些应用的更新支持很不好。于是也出 现了一些专门针对这些应用的搜索引擎,比如Google新闻、百度新闻,针对Blog和新 闻门户的RSS搜索等等。 总而言之,随着Web和Web搜索技术的发展,各种新的问题都不断涌现,增加了 信息检索的难度。

2.2.2

Web搜索的新技术
由于搜索如此重要,很多厂商及个人都纷纷研究搜索技术,各种搜索技术的成果越

来越丰富,同时也出现了越来越多的新技术。 随着搜索技术越来越公开,出现了很多开源的搜索引擎系统”,比如开源的爬虫程 序(如JSpider“,Heritrix”等),开源的索引程序(如Lucene53),甚至完整的搜索引擎
拍HoneyBot是一种自动捕捉网络攻击的技术,通过分析攻击方的行为特征进行封杀。 ”指用户输入的查询关键字与网页内容的相关程度 拈一种计算网页排名的算法,基本思想是一个网页被越多的网页所链接,它的重要程度越高。参看文献B 41, 网址:盥E::尘11型b:匹_la:型岂!』kI坐』些.型1k 4。微软公司推出的一种网页处理脚本语言.参看文献『3 9],网址: 且业i“rl型f1.I!l!!!)塑i!.盟【!I二唑型1∑』£I型皿』101幽型曲巡)二《!:_:盐幽I!li§!1]!型幽!墼:Q监:!_!上堑Q!:12:a::(}坚!i曲i !115圭幽! ”狭义的搜索引擎通常指建立索引,提供查询接El;广义的搜索引擎通常包括网络爬虫,剐页存储以厦索 引,甚至前端用户界面。狭义的搜索引擎文中一般都用索引代替。 “一个基于Java的,高可配置性的爬虫程序,网址:http://j.spider.source{brge
net/

”也是一个基于Java的爬虫程序,网址:bJtX’=型。划竖业虹盟2篷厶参看文献【2 l】


第一章绪论

(如Nutch“)。据不完全统计,互联网上开源的各种搜索引擎系统已有数十种之多。虽 然它们在一些方面与商业的专用搜索引擎还有差距,但已经能够满足很多普通用户的需 要了。 从前面iResearch公司的调查”可以看出,尽管搜索引擎的出现给人们带来了极大 的便利,但仍然存在着很多不足之处,甚至有些问题让人难以忍受。围绕着这些新问题, 搜索引擎研究者们正努力寻找着有效的解决方法。尽管内容相关分析与Page Rank算法 取得了很大的成功,但是在面临浩如烟海的网页,搜索引擎还是很难找出用户真正需要 的网页。


比如目前用户最不满意的就是搜索结果重复问题,这主要是因为互联网非常自 由,从而导致很多网站相互引用他人的文章,使得互联网出现大量内容相似, 甚至相同的网页。很多搜索引擎厂商都在努力解决这个问题,研究网页相似度 算法,隐藏部分内容非常相似的网页,已经取得一些成果。



对于搜索结果排序不住主要可能是两个方面的原因:1)网站针对搜索引擎采 取了一系列措施,使得网站排名靠前,但该网站实际并不能提供用户需要的信 息。2)用户千差万别,某些用户可能认为搜索效果很好,对另外一些用户则 可能认为搜索排序混乱,所谓众口难调。针对第一种情况,搜索引擎厂商正在 采取一系列措施解决它,比如Google开发了Web Spam”自动发现技术,并推 出了专门的Web Spare报告网站。对于第二种情况,搜索引擎厂商正在研究用 户个性化搜索,对用户行为进行分析,猜测用户搜索意图,目前己取得~些进 展。同时,搜索引擎厂商也在研究搜索结果自动聚类技术。将搜索结果分为若 干类别,让用户选择自己要搜索的内容所在类别,从而提高搜索的精度。

很多时候,用户由于种种原因,往往会给搜索引擎提交一些错误的关键字,比如英 文的拼写错误,中文的别字等等。针对这个问题,很多搜索引擎都开发了输入纠错技术, 帮助用户更正自己要输入的关键字,查找想要的内容。除了纠错外,有点搜索引擎还提 供查询建议,向用户建议与他当前查询相关的其他关键字,用户可能对此比较感兴趣。 例如用户搜索“软件下载”时,会同时建议搜索“下载软件”,“软件下载免费”,“游戏 软件下载”,“电影下载软件”,“游戏下载”,等相关的关键字。 用户在使用搜索引擎时,除了查找网页蛆外,很多时候是想知道某个问题的答案。 针对这一需求,有些搜索引擎厂商开发出了提问式搜索引擎。将问题分为:什么(what), 是否(whether),为什么(why),哪里(where),何时(when),如何(how)等六个 类别,搜索知识库。目前这种搜索引擎还不成熟,但在有些方面已经取得了较大突破。 例如Google推出的定义搜索,针对第~类问题而研发的。Google搜索框中,用户只需 要在关键字前面添加define,或者就用人们的习惯提问方式输入“what 就会找出含有该关键字定义的网页,效果很不错。 翻译技术近年也被引入到搜索引擎中。用户在搜索某个领域的资料时,通常会检索 到外文的资料,如果能够读懂,可能对用户的研究有很大帮助。通常的做法是找一本词 典,边读边查。当然,互联网上已有很多专业的翻译网站,能够帮助用户翻译很多文档。 而近几年,有些搜索引擎将翻译功能引入.在用户检索到外文资料时,直接就可以利用 搜索引擎提供的翻译服务,方便快捷。例如Google的网页翻译服务,是咀大量互联网 网页材料为基础,通过机器学习方法训练的机器翻译引擎,其翻译效果甚至超过很多专 业的翻译服务网站。Microsof【最近推出的搜索服务Msn Seatch,更会直接搜索与关键
”Apache开源基金会开发的一个索引程序,网址:http://lucene apache or∥ ”Apache开源基金会开发的一个基于Lucene的完整的搜索引擎.网址:http://lucene 茚参看2.21Web搜索的新问题
is XXX”,Google

apache

or∥nutch/

铀Web Spam是指在网页中加入很多与内容无关的隐藏文字.导致搜索'31擎处理不当的网站。

第一章绪论

字相关的其他语言的内容。比如用户输入“搜索引擎”,Msn Search不断会将中文关于 搜索引擎的结果返回给用户,同时还会返回很多包含“Search Engine”的英文网页。 近几年也出现了一些基于用户反馈方式的网页排名算法,通过用户对搜索结果的点 击情况分析搜索结果是否让用户满意,进而调整搜索结果。由于Page Rank算法存在着 一些难以避免的缺陷,例如通过添加一些隐藏文字、链接等方式来提高自己在搜索结果 中的排名。一些研究者开始采用这种用户反馈的方法来改善搜索结果。 P2P搜索也是近年才出现的一个全新的概念。由于P2P系统在资源共享方面取得巨 大成功,能够有效的分散服务器压力,具有很强的健壮’陛等等优点,P2P概念也被引入 到搜索引擎中。P2P搜索是指将P2P技术应用到网页的检索中,通过共享所有硬盘上的 文件目录乃至整个硬盘。各个网站上都有一个自己的小的搜索引擎相互之间可以进行沟 通,用户搜索可达到传统目录式搜索引擎无可比拟的深度。但是这种相互独立又相互链 接的引擎速度如何达到集中式管理的搜索引擎性能是一大技术问题。美国一家搜索引擎 设计公司i5 Digital已正式推出了依据对等搜索理念的商业性搜索引擎Pandango“。但 P2P搜索仍未进入主流搜索引擎阵容”。

2.2.3

Web搜索的新应用
搜索新技术的不断出现的同时,各种新的应用的纷纷诞生:


桌面搜索。计算机逐渐成为人们生活中的重要帮手,人们在计算机上存储的各 种文档也越来越多。工作文档、Email、浏览的网页、即时消息、图片、音频、 视频等等,通常数量巨大,难以规整。即使很好的整理了,很多时候也难以迅 速找到自己需要的文档。桌面搜索就是针对这一需求开发的,它通过对用户文 档建立索引,用户只需要通过简单的关键字描述自己寻找的文档即可迅速找到 它。很多搜索引擎厂商都通过推出桌面搜索软件,将用户桌面搜索与Web搜 索绑定在一起,方便用户使用。 移动搜索。由于种种限制,目前移动电话用户还很难直接使用Web搜索引擎 查找需要的资料。于是很多服务商推出移动搜索服务,通过手机短信将关键字 发送到服务台。服务台则通过Web搜索引擎服务接口获取搜索结果,通过短 信返回给移动电话。这种新的服务极大的方便了移动电话用户通过互联网搜索 引擎获取信息。





站内搜索引擎。Web上比较大的站点已经很多很多了,用户往往需要查找站 点内的信息,就需要使用站内搜索引擎了。虽然有一些搜索引擎提供限定某个 站点内的搜索,但是通用搜索引擎通常无法将一个站点内所有的资源都建立索 引.特别是站内的数据库资源。针对这种需求,很多网站都需要建立自己的搜 索引擎,方便访问者寻找需要的资源。目前已有一些公司提供这种服务,帮助 网站建立自己的站内搜索引擎。



学术搜索引擎。前几年做得比较好的是citeseer”,提供对论文的搜索支持,对 英文论文覆盖很全面,并且提供引用统计等相关信息。citeseer最大的缺点是 对其他语言论文支持很差,例如中文论文。最近Google以及其他几家搜索引 擎厂商推出了类似的搜索服务,不断在搜索效率相对于citeseer有着很大的提

”15

Digit公司推出的新一代P2P搜索引擎。网址:http://wwwpandango
ist psu edu/

com

”参看文献【2 2】

”一个很好的搜索论文网站,网址:http://citeseer

第一章绪论

高,而且支持多种语言,覆盖面更全。


源码搜索引擎。由于互联网上很大一部分用户是软件开发者,在开发过程中往 往希望能够相互学习。于是出现了很多代码共享的网站。在大量的源代码中寻 找需要的一些代码是一件非常困难的事情,于是出现了很多针对这一需求的源 代码搜索引擎,帮助用户迅速找到需要的代码。



RSS搜索。随着RSS的流行,用户可以不必打开网页浏览每天新的消息、文 章,而只需要一个RSS阅读器就可以方便快速的阅读。但是如何找到自己感 兴趣的RSS源呢?RSS搜索就是专门用来搜索RSS源的搜索引擎。用户只需 要输入几个关键字,RSS搜索引擎就会将与之相关的RSS源显示给用户,方 便用户订阅。



P2P“搜索引擎。P2P的出现极大的改变了互联网的结构。在P2P技术广泛应 用以前,用户需要的资源几乎都集中在有限的一些网站之中,类似于新闻网站 一样。P2P技术的出现就像Blog技术一样,使得任何人都可以向其他用户方 便的贡献自己的资源,如电子书籍、图片、音频、视频、软件等等。P2P技术 使资源不再集中于有限的网站之内,并且可以极大的缓解网站压力,降低网站 运营成本。

3分布式搜索引擎概述
3.1分布式系统的必要性
Web搜索引擎通常包括三个部分.网络爬虫、网页存储系统、索引系统。网络爬 虫负责从Web上抓取网页,然后存储到网页存储系统里面,索引系统则负责对爬虫抓 取下来的网页建立索引,并提供检索服务。面向大众服务的搜索引擎还提供一个前端的 Web服务器,供用户查询。 目前互联网上的资源极多,网页数量极其庞大。Google已经收录了80多亿网页, 但仍然远远没有收录完全所有的网页,甚至它所收录的网页仅占全部网页的很小一部 分。特别是近年Blog和Wiki系统的流行,网页数量更是急剧增加,并且在不断的急剧 增加。面对如此之多的网页,如何能迅速从互联网上抓取网页,并迅速建立索引,提供 服务呢?显然采取传统的单机式系统是不可能满足要求的。无论是在抓取速度,存储容 量,还是建立索引的速度上,单机系统都远远无法满足。为了解决这一系列问题,系统 必须采用分布式架构。通过很多计算机协同工作,提高整体性能,己满足系统需求。事 实上,自2003年以后,主流的搜索引擎都采用了分布式架构。 本文的主要目标之一就是要能够面向整个互联网大规模搜索,构建一个搜索引擎。 为了满足这个目标,整个系统将全部采用分布式架构。无论是网络爬虫系统、索引系统 还是网页存储系统都采用分布式架构,以期能够快速的抓取网页,建立索引,提供高效 的检索服务,并能够存储大量网页及其他网络资源。

叫Peerto

Peer,一种基于用户端到端共享的技术。参看嗣站【3 2],网址:http://zhwikipedia

org/wiki/P2P

第一章绪论

3.2分布式搜索引擎的一般架构
如前所述,搜索引擎一般分为三个主要部分:网络爬虫、索引系统、数据存储系统 如下图所示:

图3搜索引擎一般结构图


Crawler,网络爬虫根据网页中的链接以及其他方式对Web进行爬行,获取网 页,并将爬行下来的网页存储到存储系统。

2. 3

Storage,存储系统主要用来网页,以便后期建立索引,以及其他数据分析。 Index,索引系统首先对存储下来的网页进行解析,生成索引数据,然后提供 数据检索服务。

值得说明的是,早期某些搜索引擎是没有存储系统的,爬虫爬行了网页之后,直接 进行解析,建立索引(比如Google第一版)。这种方式有几个缺陷:爬行速度受解析速 度影响较大;难以进行后期的网页数据挖掘工作以及提供其他服务,因为原始网页数据 并没有保存下来。 分布式搜索引擎总体架构与之基本相同,只是各个部分都采用分布式结构,从而提 高系统性能。如下图:

图4分布式搜索引擎一般结构图 如上图,分布式搜索引擎基本结构仍然与普通搜索引擎类似,只是每个部分都采用 分布式结构,由一个集群来协调完成相应的工作:


Crawler

Cluster,网络爬虫集群与原来的网络爬虫任务类似,同样是负责抓取

网页,但是与单机的网络爬虫相比,网络爬虫集群要复杂一些。为了能够更快



第一章绪论

的抓取网页,系统使用多台计算机同时抓取,但带来两个主要问题:
a)

避免重复爬行。需要通过一定的协调机制,尽量使各个网络爬虫不重复爬 行相同的网页,理想情况是没有重复爬行。重复度越高,爬行资源浪费越 严重。 负载均衡。应该避免这样一种情况就是,一部分网络爬虫不停的爬行网页, 而另一部分网络爬虫却长时间没有任务,处于空闲状态。这也是一种爬行 资源的浪费。

b)

充分利用爬行资源,减少浪费,能有效节约系统成本。
2 Storage

Cluster,存储集群主要用来存储爬虫抓取的网页,需要解决的问题主

要有三个方面:
a)

提供极大的存储容量。单机系统相对于互联网上如此之多的网页来说,存 储容量是相当有限的,而专用的存储系统往往过于昂贵,或者存在I/0瓶 颈。采用普通PC机的集群系统刚好能够在提供大存储容量的同时,也能 较大的提升I/0性能。 高效的访问速度。访问速度对于数据存储系统来说往往都是很重要的。相 对于CPU的高速计算来说,I/0访问往往会成为整个系统的瓶颈,因此系 统设计上需要很好的考虑这一点。 数据安全性。爬虫系统和索引系统都依赖于存储系统提供的存储服务,闻 此存储系统必须保证数据安全性,需要有多备份和灾难恢复机制。 Cluster相当于一般搜索引擎中的索引部分,

b)

c1



[ndexing Cluster和Index Service

它实际上是分为两个部分:索引计算部分与索引服务部分。索引部分同样需要 注意索引计算不能重复,也应该让索引计算任务平衡的分配给各个索引计算服 务器。

第二章分布式搜索引擎总体设计

第二章分布式搜索引擎总体设计
1背景
众所周知,.搜索技术在现代信息计算领域有着极其重要的意义。随着人们处理的信息越 来越多,数据量越来越大,传统的通过手动整理资料,然后查找的方式已经很难适应现代大 规模信息处理的需要了。也正因为如此,搜索的应用几乎无处不在。几乎所有的桌面操作系 统都拥有搜索功能,帮助用户查找需要的文档。几乎所有的编辑器也有查找功能,帮助用户 在编辑文档时.迅速找到需要编辑的地方。很多常用的信息管理软件(比如:Outlook Express“,通讯簿”)也有搜索功能。甚至有的应用程序配置选项和帮助系统也提供查找功 能(比如:Eclipse”),帮助用户迅速找到要配置的选项和帮助内容。 在面对网页数量极其庞大的互联网时,搜索显得更有必要。互联网资源极其丰富,各类 信息应有尽有。很多时候,用户使用互联网都是为了查找自己需要的信息。如果没有搜索引 擎,面对浩如烟海的网页,用户恐怕只会感到无所适从。有了搜索引擎之后就不一样了,用 户只需要输入几个跟所需网页相关的关键字,搜索引擎就会迅速把相关网页返回给用户,这 样用户就可以快速找到所需的网页。搜索引擎的出现极大的提高了人们检索互联网信息的效 率,大大的节省了人们的时间,甚至改变了人们使用互联网的方式。 目前,中国实施的中国下一代互联网(CNGI)计划正在大规模布设lPv6骨干网。在不久 的将来,CNGI网络上将会有大量的各类信息资源。为了让用户快速、有效、全面的检索 CNGI网络上的信息,有必要开发下一代基于lPv6的大规模、分布式搜索引擎。目前,CNGI 已经立项IPv6搜索引擎和管理系统应用实验,本实验室正在努力申请该项目。这也是本文 研究面对的问题之一,构建一个大规模、分布式搜索引擎,并且能够同时兼容IPv4与IPv6 网络。 本文研究的另外一个背景是基于本研究室多年以来的研究需要。本研究室已经研究互联 网信息抽取与Web挖掘多年,很多研究需要一个搜索引擎作为基础。而且,很多研究成果 希望能够在一个大规模的搜索引擎上应用,研究它们在大规模搜索引擎系统中的效果。总之, 本文的工作希望为这些研究提供一个基础平台,为以后的研究工作提供更广阔的研究空间。

2设计目标
本文正是在如上背景下,面向大规模应用的互联网搜索而立题。具体说来,设计目标主 要分为如下几个方面:


开发一个完整的搜索引擎。本文的主要目的是设计一个完整的搜索引擎,包括互联 网爬虫、网页存储与索引系统。各个部分都采用分布式架构,以适应大规模应用的 需要,提高系统性能,消除系统瓶颈。 同时兼容IPv6和lPv4网络。当前互联网主要资源还是集中在IPv4网络上,下一

2.

…Microsoft Windows操作系统下的一个Email客户端程序。
们Microsoft

Windows操作系统下的一个联系人管理程序。

”一个开源的、基于Java的优秀集成开发环境,网址:http://www eclipse or∥


第二章分布式搜索引擎总体设计

代IPv6互联网发展也很迅速。可以预见,在不久的将来,IPv6网络资源也会丰富 起来,并远远超过lPv4网络。目前能够兼容IPv6的应用软件是很匮乏的,搜索引 擎也是如此。为此,本文开发的搜索引擎需要同时兼容IPv6网络和IPv4网络。 高可扩展性。分布式系统能够很好的提高系统性能,让系统能够根据需要灵活的扩 展是优秀分布式系统的特点之一。在系统运行初期,可能性能要求不高,但随着时 间迁移,对系统要求会越来越高。比如初期,存储要求并不高,但运行一段时间之 后,系统就会积累大量数据。如果初期就分配很多存储服务器,势必大大增加成本, 并且Web数据量如此之大,总有一天会超出存储限制。如果能够实现灵活的扩展, 在初期仅分配少量计算机,在需要时再添加新的存储服务器,必能大大降低成本。


高可靠性。由于Web数据量巨大,更新很快,需要连续不断的处理。在提供搜索 服务时,也应该能够持续。除了在软件稳定性上要求系统稳定外,还应该提供专门 的机制保证系统的可靠。如采用多备份机制保证一部分服务器宕机时,仍然能够提 供服务;持续的错误自动检测,尽快发现错误,采取适当的方法应对;提供迅速的 灾难恢复机制,在系统出现损坏时,能够迅速恢复到错误之前的状态,并继续提供 服务。



高性能。高性能也是系统设计的重要目标之一。网络爬虫爬行速度越快、爬行的网
页质量越高,爬虫的性能就越高;存储系统提供的存储容量越大,I/0访问速度越 快、越稳定,存储性能越高;索引系统建立索引的速度越快,质量越高,检索速度 越快,索引系统的性能就越高。充分提高各个系统的性能也是降低系统成本的重要 方式。



尽量采用标准的、开放的软硬件平台。采用标准、开放的软硬件平台能带来一系列 优点。采用标准开放的平台通常可以获得更多的支持,因为标准开放系统往往会更 加流行,生产厂商和使用者会很多,很容易在平台的社区得到帮助。也正因为厂商 多,往往成本会比封闭专用平台低很多。而且,标准或者开放的系统因为更多的人 支持,往往生命力更强,开放的系统开发维护起来更加容易。

3系统总述

3.1系统架构
针对以上背景需求与设计目标,本文提出的分布式搜索引擎设计架构如下所示

第二章分布式搜索引擎总体设计

图5分布式搜索引擎总体架构图 如上图所示,系统分为四大部分:爬虫集群(CrawlerCluster)、Web存储集群(Web
Storage

Cluster)、索引计算集群(Indexing Cluster)、索引服务集群(Index

Service

Cluster)。 I.

爬虫集群(CC),负责对Web网络资源的爬行,数据采集,并存储到Web存 储集群。需要同时兼容IPv4网络与IPv6网络。 Web存储集群(WSC),负责存储网络上的资源对象,主要是网页。根据搜索 需要,可能会增加其他资源对象,如Word文档,PDF文档,图片文件等。 索引计算集群(IC),负责解析存储在Web存储集群中的资源对象,计算出索 引数据,并发送给索引服务集群。 索引服务集群([SC),负责存储索引数据,并提供查询服务。

2.





整个系统的运作实际上分为两个流程:


数据采集与整理。爬虫集群在爬行Internet之后,将Web对象存储到Web存 储集群中;索引计算集群从Web存储集群下载Web对象,解析,计算出索引 数据,并将索引数据发送给索引服务集群,由索引服务集群存储。 用户查询。用户将查询语句发送给索引服务集群,索引服务集群根据索引数据, 返回查询结果。



3.2系统特点
首先,本文开发的搜索引擎能够同时兼容IPv4和1Pv6网络,通过网络层封装两种 协议,根据具体爬行的URL自动切换。 本文开发的搜索引擎中各个部分都采用分布式集群,通过并行计算,提高系统各项 能力。一般的分布式系统都是主从结构。如下图所示:



第二章分布式搜索引擎总体设计





曩没

栅删蒜

一。@一
/●{|。警s

爹豁

一1闷。蓬。



>引辫

图6一般分布式系统架构图 外部客户端访问集群都向Master发送服务请求,Master根据内部服务分布情况, 到相应的Slave上获取服务,然后转交给客户端。这种设计的优点是,结构简单,易于 实现。并且由于只能通过Master访问整个集群,将集群内部其他信息都隐藏起来,方 便扩展,即集群内部进行扩展时,完全不影响外部接C:1。但是这种结构的缺点也是显然 的。对集群所有的访问都必须经过Master,在访问比较频繁,数据流比较大的应用中, Master很容易成为整个系统的瓶颈。 为了克服上面结构的困难,一般系统中将数据流与控制流进行分离,从而减轻 Master的压力。如下图所示:

图7分离数据流的分布式系统架构图

外部客户端首先向Master请求服务,Master根据集群内部服务分布情况将某个
Slave的服务信息返回给客户端。客户端就直接与该Slave进行数据交互。这种结构中, Master仅保存有系统的元数据(meta data),提供元数据查询服务,但不直接参与具体 服务。其优点是:比较好地实现了内部信息的隐藏,仅在需要时才暴露内部信息,基本 不影响外部接口,扩展比较方便;由于Master仅提供元数据查询,服务能力与一般主 从式分布式系统有很大的提高,瓶颈效应明显降低。缺点是:在元数据量比较大,难以 存储在内存中,或者访问特别频繁的情况下,仍然存在瓶颈。另一个缺点是:如果系统 可靠性要求很高,需要多备份Master,元数据的更新同步,Master更替都比较复杂。 本文在评估了以上系统设计的优缺点之后,提出一种新的分布式系统结构一一基于 策略的分布式系统。如下图所示:



第二章分布式搜索引擎总体设计

图8基于策略的分布式系统架构图 首先Master通过策略总线(Strategy Bus)将系统内部的服务访问策略发布出来; 客户端向Master订阅服务访问策略,然后根据服务访问箫略直接访问集群中提供所需 服务的服务。Master只需要根据内部情况更新、发布服务策略即可。这种设计的优点有:


高效率。外部客户端在获取服务策略之后,不必再与Master交互,而是直接 与Slave交互。这种直接交互的方式,减少了网络开销,提高了系统效率。 高度并发。各客户端按照服务访问策略进行访问,中间不需要Master参与, 提高了系统的并发能力。 高度自治。系统中各个服务计算机都按照服务访问策略提供服务,并可以根据 该策略,在内部直接进行协调,而不需要Master参与。各服务计算机都是高 度白治的,智能化的服务提供者。 提高Master性能。由于策略信息往往比系统元数据要少得多,并且与Master 的交互量也极大幅度的降低,在这种架构中,Master基本上不再是系统瓶颈”。 由于Master不再维护所有的元数据,仅维护与策略相关的数据,生成访问繁 略,因此,在多Master备份系统中,Master之间的数据同步更新也要简单得 多。
这里.策略总线黾一个逻辑概念,策略管理者(通常是某个集群的主鼹务器)提供一种发 布镱咯的鼹务.需饕该策略的客户端司啦通过请求该强务得弱需要的策略。最略尊线是一个逻 辑上的链路.封装所有策路疆务拍物理通道,



3.



当然,这种设计在提高效率的同时,也带来了一些弊端:


透明性。这种设计在透明性上不如前二者,客户端需要从分布式策略中了解一 些内部信息。在系统扩展时,需要更新第略,以保证系统服务的一致性。 安全-l生。由于系统不再是完全透明的,因此恶意客户端有可能违反策略协议, 侵害系统。要克服安全性问题需要加入客户认证,阻止非法客户端的恶意访问。 对客户端的少量访问系统开销反而增大,这是由于任何访问都需要服务访问策 略。如果只是偶尔一次的短暂访问,却耗费了较多的时间获取、解析访问策略, 显然有些得不偿失。该架构是专门针对大规模、高并发、性能要求很高的系统 设计的。

2.



“在某些极端条件下,也不能完全排除Master成为系统访问瓶颈的可能性,但相比前面两种架构来说 Master负荷大幅度降低,成为瓶颈的几率也要低得多。

第二章分布式搜索引擎总体设计

尽管存在这些问题,但采用基于策略的分布式结构能够大大提高系统性能,避免瓶 颈,并加强系统可靠性。但采取相应的措施能够将这些影响控制在可接受的范围内。 为了使系统满足可靠性方面的要求,本文从主要做以下几个方面的工作:


尽量采用标准的交互接口。各个子系统之间、子系统内部的交互尽量采用使用 广泛的标准协议。使用广泛的标准协议往往有很多第三方的实现,一方面减轻 了本文开发工作的负担,另一方面,第三方的实现往往经过多年的使用,通常 比较完善,可靠。 系统工作多备份,即分布式系统中的从服务器所要负担的工作往往都由若干服 务器同时负责,称之为工作组。在其中一部分服务器意外崩溃的情况下,仍然 能够对外提供服务。 Master多备份,即分布式系统中的主服务器所要负担的工作往往也是由若干服 务器同时负责,在某台主服务器意外崩溃的情况下,可以由另一台主服务器及 时提供服务。 持续的系统错误检测。在每个服务器上都有一个专门的检测程序负责检测该服 务器上的工作进程是否工作正常;在每个子系统中,服务器之间也互相检测与 之交互的服务器是否工作正常;子系统之间的交互错误也会被检测出来。对于 检测到的错误,都要记录日志。检测程序首先试图修复错误,如果无法修复, 将发送错误通知给系统管理员。 快速的灾难废复。对于无法修复的错误,系统在设计上考虑快速灾难恢复机制。 工作进程在工作过程中的每一步都记录日志。在进程崩溃,系统重启之后,可 以通过日志快速找到当前工作点,继续未完成的工作。如果某台服务器由于硬 件损坏,无法重启,并且数据丢失。可以重新安装一台服务器替代它的工作, 丢失的数据可以从它所在工作组同步。









可扩展性是采用分布式的主要目标之一,为了满足可扩展性需求,本文需要做的工 作有


在增加从服务器(Slave)时,增加过程不会影响到原来的从服务器,原来的 从服务器不需要暂停服务来适应新的系统。 增加从服务器时,增加过程不需要中断主服务器(Master)的服务,而是能够 在主服务器提供服务的同时,动态增加。 增加从服务器之后,主服务器更新策略,能够及时发布给需要访问的客户端, 并且保证客户端访问整个系统的平稳过渡。





最后是系统性能方面的特性。由于系统尽量采用标准、开放接1:3,整合优秀的第三 方实现方案,给予性能上最大的支持。比如系统实现中很多数据传输都采用标准FTP 协议,可以使用第三方的FTP服务器端实现和客户端实现,达到磁盘访问的最大速度。 爬虫引擎采用优秀的JSpider,灵活,抓取速度快。索引采用lucene引擎,检索速度很 快。另外系统中大量采用Hash表来优化查询,大大提高数据访问速度。 从系统架构上,由于采用基于策略的分布式架构,客户端对系统都是采用直接访问 模式。没有Maste r参与,从而避免了系统瓶颈,实现了完全的并行计算。理论上,系 统性能与从服务器数量接近线性关系。



第三章分布式爬虫系统

第三章分布式爬虫系统
1背景与需求
无论是构建一个搜索引擎,还是做其他Web挖掘的研究,爬虫系统都是它们的基础设 施,是构建搜索引擎,进行各种数据分析的数据获取通道。搜索引擎以及其他Web挖掘工 作都需要从互联网上获取大量的网页数据,然后建立索引,或者进行其他分析。本文的主要 工作是构建一个面向互联网的大规模搜索引擎,爬虫系统是其基础的系统之一。 虽然基于robot技术的搜索引擎早在1994年就已经推出”,相关研究成果也不断公布, 但针对大规模、分布式、高性能的网页抓取系统的研究工作却是在2000年以后才开始的, 并且随着研究的不断深入,互联网的不断发展,各种新问题层出不穷,新的研究热点也不断 涌现。 WWW自1991年8月一经推出就得到迅猛发展,早在1994年,人们就开始认识到WWW 上的信息资源丰富、数量巨大,同时检索也变得困难。文[2 4】中Brian Pinkenon为了解决这 一问题,开发了WebCrawler,实现了一个简单的搜索引擎。它的爬虫系统仅限于单机系统, 为了提高爬行效率,同时启动多个进程,采用广度优先策略进行爬行,由搜索引擎做出爬行 决策,总体来说效率较低。为了提高爬行效率,人们主要从两个方面进行研究:爬行策略和 软硬件架构的可扩展性。爬行策略方面,文[2 重要程度来设定页面爬行的优先级;文[2
8,2 6,2

71研究了页面重要度策略爬行,根据页面
10,2

9】研究了主题式爬行策略;文『2

11]研究

了时序爬行策略,根据时间来安排爬行,以及页面更新周期等问题。系统架构方面,文『2.5,1 研究了分布式的爬虫系统,使用多个爬虫服务器并行爬行互联网,以提高爬行效率;文f2
2 12.

131研究了基于P2P架构的分布式爬虫集群系统。 本文的主要工作是开发一个面向互联网的大规模搜索引擎,爬虫系统是其基础,它位于

搜索引擎存储系统和www之间,如下图:

图9爬虫系统在搜索引擎中的位置 承担从WWW获取网页的任务。为了适应大规模互联网搜索引擎的需要,爬虫系统必 须是可扩展的,高性能的。

斫1994年7月LvCOS推出

第三章分布式爬虫系统

2目标
针对整个搜索引擎的需要,爬虫系统需满足如下几个目标: 1)同时支持IPv4和IPv6。如前所述,本文所开发的系统需要能够同时支持IPv4和 [Pv6,爬虫系统是与外界交互的第一个接口,所有IPv4网络和IPv6网络的资源都 通过爬虫系统获取。因此,爬虫系统同时支持[Pv4和IPv6是必须的。 2)高性能。由于整个互联网上的网页数目巨大,并且一直都在持续高速增长,还有大 量页面会不断更新,因此爬虫系统需要能够快速从互联网上抓取大量网页。抓取速 度是性能的一个重要指标。另外,所抓取网页的重要程度也是衡量性能的一个指标。 因此全面衡量性能应该是抓取网页数量的重要因子的加权和。系统采用分布式结 构,使用多台计算机同时爬行www,咀提高抓取速度;并且研究网页重要程度, 根据重要因子来调整爬行队列。 3)可扩展性。由于互联网一直在持续高速增长,爬虫系统为了能够与互联网增长同步, 需要不断提高系统爬行性能。因此系统需要很好的可扩展性,能够通过添加新的爬 虫计算机以提高系统’|生能。 4)可靠性。爬虫系统需要一定的可靠性来保证整个搜索引擎系统的数据与互联网上的 数据是一致的。如果爬虫系统长时间不能工作,搜索引擎存储的数据中很大一部分 可能一经过期,无法使用。因此爬虫系统需要能够长期不间断的工作。

3重点问题解决方案
本文的爬虫系统重点解决分布式环境下网页爬行可能出现的两个问题: I)分布式环境下,多个爬虫可能重复爬行相同的网页,造成爬行资源的浪费。 2)负载均衡。多个爬虫可能会出现这样一种情况,一部分网络爬虫不停的爬行网页, 而另一部分网络爬虫却长时间没有任务,处于空闲状态。这也是一种爬行资源的浪 费。 一般爬虫系统中,往往采用一个主控服务器负责URL调度。每个爬虫服务器开始都在 主控服务器获取一些URL进行爬行,从网页中抽取出新的URL,发送给主控服务器。当爬 虫服务器维护的爬行队列少于既定值时,又到主控服务器获取新的URL。这种方式可以很 好的解决重复爬行和负载均衡问题,但是主控服务器的压力很大,无法完成大量爬虫服务器 的爬行调度工作。并且一旦主控根务器宕机,所有的爬虫服务器都无法继续爬行。文[2 12】 提出了一种基于DHT的P2P网络下分布式爬虫系统设计方案,将URL发布到DHT网络中,

每个爬虫节点负责与之Hash表对应的一部分URL的爬行。这种方法很好的解决了重复爬
行问题。文中提出由若干个节点共同负责一部分URL来解决负载均衡,有一定效果。 本文综合了以上两种设计方案,按照基于策略的分布式架构实现爬虫系统。最开始,主 服务器按照爬虫服务器的数量,将URL按照hash值等分为若干区间,每个爬虫服务器指派 一个区间。将该策略发布给爬虫服务器。爬虫服务器爬行下来获取的网页中抽取出新的 URL,按照该策略直接发送给对应的爬虫服务器。每个爬虫之爬行自己负责的URL空间, 不会有重叠爬行。爬虫定期向主服务器反馈爬行队列长度,主服务器判断各个爬虫的负载状 况。对于负载过重的爬虫,缩小它的URL空间;对于负载较轻的爬虫则扩大它的URL空间; 制定新的爬行策略,发布给各爬虫,从而实现负载均衡。 首先设定一个爬行队列长度阀值N,只有队列长度大于N的爬虫URL空间需要缩小。 因为如果爬行队列很短,比如只有10个,爬虫可以在短时间内爬行完毕,爬虫的负载较小,

第三章分布式爬虫系统

没有必要缩小空间。两个爬虫只有队列长度相差很大时,才有必要进行均衡。由于受不确定 的网络条件影响,相差较小的爬行队列长度并不能说明二者负载很不均衡。本文计算二者爬 行队列的比值K,设定阀值a,如果该比值大于a,则进行负载均衡。进行负载均衡时,总 是选择队列最长和队列最短的两个爬虫,从队列长的爬虫划分一部分URL空间到队列短的 爬虫。划分应该保证:比值K达到无穷时,划分一半URL空间;比值K=I时,不划分。本 文设计的计算公式如下:
口=l/2—1/2K

假定原来爬虫的URL空间大小为M,则将该URL空间中最小的M+p划分给爬行队
列短的爬虫。算法伪码如下:

4架构
爬虫的主要功能是从互联网上抓取网页或其他Web对象,并存储到搜索引擎内部的存 储系统。为提高系统性能,适应规模巨大的互联网信息检索需要,本文采用分布式架构,如 下图所示:

图10爬虫系统构架图

第三章分布式爬虫系统

如上图所示,爬虫系统(Crawler Cluster)分为两个主要部分:Master组和Crawler组。 Master组主要功能是负责系统调度管理,协调Crawler工作;Crawler组的主要功能是负责 实际的网络爬行,抓取网页。首先主服务器制订爬行策略,然后发布给爬虫服务器,由爬虫 服务器根据该策略进行爬行,抓取网页:主服务器同时通过策略总线查询存储集群的存储策 略,发布给各个爬虫服务器;爬虫服务器将爬行下来的网页及其他Web对象,根据存储策 略存储到

crawler Mat蒌Ler

Crawler

WSC

WWW ——


№…。…咖k≥竺二二
图11爬虫系统交互序列图 1)Master功能详述。 Master的主要功能有:为爬虫服务器分配任务,协调爬虫工作;维护系统信息,持续监 测系统状态,保证系统可靠性。 首先,Master根据一种简单平均方法将一些种子URL交给各个爬虫服务器,分别爬行。 在系统运行一段时间之后,根据各个爬虫服务器的压力情况,将压力较大的爬虫服务器 中的一些任务分配给压力较小的爬虫服务器。Master的任务分配并不是采用实时的逐 个URL指派方式进行,而是使用策略方式,以减少Master与Crawler之问的交互,减 少网络负担,同时也能减少Crawler的负担,提高性能。 另外,Master还要一直保持与Crawler之间的心跳,监视Crawler运行情况,包括CPU, 内存,网络,磁盘利用情况以及当前爬行队列情况等等。收集这些信息以便调整其工作 压力,平衡各Crawler之问的负载。如果某个Crawler宕机,也能通过心跳检测出来。 可以及时将该Crawler没有执行完的任务交给其他Crawler执行,并通知维护人员及时 排除故障。 除此之外,Master还要查陶存储策略,将它发布给Crawler,以便Crawler将爬行得到的 网页适当的存储到相应的存储服务器中。 2)Crawler功能详述 Crawler主要任务是爬行网页,根据Master制订的爬行策略,建立待爬行URL队列,采 用多线程技术同时从互联网爬行多个URL。Crawler首先从一些初始的种子URL开始爬 行,从爬行的网页中抽取出新URL。然后根据Master制订的策略,从中选取自己的任 务,添加到待爬行队列。Crawler还要一直保持与Master之间的心跳,不断报告运行参 数。这些数据可以供后期分析爬虫的行为特征,以做出更好的爬行策略。同时也能帮助

第三章分布式爬虫系统

Master及时做出爬行策略调整,平衡各个Crawler之间的负载。对于新发现的URL,不 是自己任务的,根据爬行策略,可以直接发送给对应的Crawler。 另外,Crawler还要通过Master查询数据存储策略,以便能够将爬行下来的数据存储到 存储服务器中。 为保证系统的可靠性,Master采用双备份方式。所有Master需要维护的数据都在两台 (或多台)Master之间进行同步,两台Master对外提供完全相同的服务。由于采用了策略 方式Crawler分配任务,而不是采用直接分派URL的方式,减少了很多数据量,Master之 间的数据同步压力并不大。 在系统工作过程中,Master与Crawler之间一直保持心跳,维护系统内部信息,检测系 统故障。在系统心跳过程中,如果某一Master宕机,爬虫可以直接连接到另一台Master, 保证工作继续进行,同时报警,通知维护人员来排除故障。如果某一Crawler宕机,Master 会将分配给它的爬行任务分配给其它Crawler,并报警,通知维护人员排除故障。 在系统爬行能力不能满足系统要求,爬行队列长度一直增加时,可以通过添加新的 Crawler来扩展系统,提高系统的爬行能力。在添加了新的爬虫后,Master会将原来其他 Crawler的一些任务分配给新增加的Crawler,以达到整个系统的负载平衡。

5接口 5.1外部接口
外部接口定义了爬虫系统与外部其他系统通信,交换信息的内容和需要遵守的规 范,包括如下几个方面: 1)爬虫系统Master获取存储策略的接口。 整个搜索引擎系统中的策略发布都通过策略总线发布。存储策略的发布采用标 准的HTTP协议,由存储系统的Master服务器提供HTTP服务。爬虫Master发送 HTTP请求,使用Get方法。在请求中要包含自己的ID(CRAWLER—MAS'I、ER), 当前所拥有的存储策略版本”,以及请求的存储服务类型“。存储系统的Master服 务器返回保存数据的存储策略文件”。 发送请求的示例如下:

兰兰三塑!羔兰里坚三:羔土翌旦型鎏三!三11二—!蛩拿曼i兰璺蔓望兰—兰呈竺三呈
采用标准的HTTP协议可以减少开发系统的工作量,并提高系统可靠性、安全 性以及性能。因为已有很多Web Server实现(如Apache等),并且它们通常对HTTP 服务做了很多优化工作。 2)爬虫在Internet上爬行的接口。 爬虫在Internet上爬行,主要是通过HTTP协议抓取网页及其他Web对象。关

于H丌P协议的具体内容参看HTTP/1
RFC2616)。

0(RFCl945),HTTP/1l(RFC2068,

3)爬虫保存爬行数据到存储服务器的接口。
66参见第四章分布式存储系统4接口,存储策略版本管理。 盯参见第四章分布式存储系统4接口,存储服务类型定义。 们参见第四章分布式存储系统4接口,策略文件定义。
26

第三章分布式爬虫系统

该接口描述了爬虫如何将从互联网上爬行下来的数据存储到存储系统。由于网 页或其他Web对象一般都比较小(<IM),通常只有几KB到几十KB。如果每爬 行下来一个都直接存储到WSC(Web
Storage

Cluster),会极大影响系统性能。这

是因为操作系统访问文件,以及创建网络连接的开销比较大。频繁的创建文件,打 开网络连接会消耗大量的系统资源(CPU,时间)。而传送大文件,操作系统只需 要创建一个文件,和少量网络连接即可。因此本文在存储时,并不是直接将每个 Web对象直接存储到WSC,而是将大量的Web对象打包到一个文件中,形成一个 大文件,然后再存储到WSC,以提高系统性能。 爬虫到WSC之间的网络连接采用标准的FTP协议。采用该协议的优点是:
a)

FTP协议是专门针对文件传输的标准网络协议,有很多客户端、服务器端 实现,以及开发包。 它们针对FTP传输做了很多优化工作。传输效率高,资源占用少(CPU, 内存),稳定可靠。

b)

爬虫可以从存储策略中获取对应WSC服务器的IP地址、端口、用户名、密 码、路径、模式、传输方式等FTP参数。

5.2内部接口
内部接口定义了爬虫系统内部各组件之间互相通信的内容和方式,包括: 1)Master与Crawler之间的接口。 Master与Crawler之间的需要交换的消息有:Master向Crawler发布爬行策略, Master向Crawler发布存储策略;Crawler定时向Master报告内部状态,保持 心跳。 内部接口都采用TCP协议,Master和Crawler都各自侦听一个固定端口,等 待其他服务器给自己发送消息。如果有消息要发送给其他服务器,同样发送到 对方对应的端口上。发送和接收消息可以同时进行,而无需等待,因此,爬虫 系统内部通信都是全双工的。 策略发布接口。 策略接口发布两种策略:爬行策略和存储策略。发送消息格式如下:

[cor衄and![E\n珥Hea璺t(\工瑚婆^域Ⅱ℃。n馨尊鳞BX}\曼l¨
类似于HTTP协议中使用POST方式发送数据的格式,其中【12-间是特殊意义 内容标记(之外的都是ASCII字符),定义如下: 表格1爬虫策略发布接口消息格式定义表 标记
1rIn Command Head

意义 回车换行符,二进制表示,值:0xODOA 命令,常值:POST
STRATEGY

头部信息,包括MASTER—ID,TYPE,CONTENT—LENGTH。 采用name-value形式。

Content

策略数据

MASTER—ID

Master编号 策略类型:CRAWL,STORE 策略数据的大小,10进制可读字符串

TYPE CONTENT—LENGTH

第三章分布式爬虫系统

Master在策略更新,或者Crawler刚启动的时候,建立}岛时连接,将策略发送 给C rawler侦听的端口。Crawler无需回复,接收该信息后存储到本地,并交 给内部的数据存储驱动以存储到WSC上。 存储策略具体内容见第四章分布式存储系统4 1内部接口。 爬行策略的具体内容见5.1 Master功能与实现3)策略生成器。 心跳接口。 心跳接口包含三种类型的消息:空消息,发送信启。,发送错误。心跳接口中, 由Crawler建立临时连接,向Master侦听的端口发送信息,Master无需回复。
?

空消息格式:
[CrawlerID】[\n]NOOP[\n\n]

该消息长11字节,各格式字段定义见图表14。
?

发送信息格式: [erawlerIDH\nJ}工NF9n五】i[i毋fo薯旱on臻no】11【^4~n】 该消息不定氏,根据发送内容而改变。需要发送的信息内容包括CPU利 用率、内存利用率、网络利用率、硬盘利用率,以及爬行队列的长度等。 具体内容定义见图表1 3。 表格2爬虫心跳接口信息格式定义表 项目
CPU

格式
CPU=『ratiO]

说明 CPU利用率,cPu=80即CPU利用率为
80%

MEM

MEM=[ratiO]

内存利用率,MEN=l 40即使用了40%的 虚拟内存 网络利用率,NET=85即使用了85%的 网络连接传输速率 硬盘利用率,DISK=30即使用了30%的 硬盘空间。 队列长度,QUEUE 521即有

NET

NET=[ratiO]


QUEUE

DISK=[ratio]

QUEUE—LENGTH=le“gth

LENGTH=3

3521个URL等待爬行。 为了提高传送效率,也可以将若干信息同时发送,用”{r括起来,各个项 目之间用”;”分隔,具体格式如下:

暾菇h鳓瓢鬻馘誊釜磁《籁瓣巍越糍l籀菊簸曝瑶l
错误消启、格式:

睫;蠢i矗ID“、最箍蘸蠊【X爵隧镒露萋i;鬻蘸b醛%端1t
该消息不定长,根据发送内容而改变。错误描述发送给Master之后,Master 会试图处理,如果无法处理则发出警告,由维护人员处理。 表格3爬虫心跳接口消息格式定义表 标记
CrawlerID

意义 Crawlet在爬虫系统中的唯一编号,16bit, 使用16进制可读方式表示。

例子
00FA,284 8

\n 1nfo—content
error—content

回车符,二进制表示,值:0x0A Crawler要发送的信息内容 错误信息描述

2)Master之间的数据同步接口

第三章分布式爬虫系统

为了保证系统可靠性,系统采用多Master备份。与搜索引擎中其他子系统, 以及Crawler交互,都由其中一个Master进行。如果该Master宕机,各份Master 将启用。在发布给Crawler的爬行策略中包含备份Master的信息,Crawler在 心跳中发现Master宕机之后就可以连接备份Master。 Master之间需要同步的数据有:存储策略,爬行策略。接口消息与策略发布接 口相同,发送端口复用Master侦听的心跳端口。这里采用端口复用方式,以 节省网络资源,并简化程序设计。 3)Crawler之间的接口 Crawler之间的接口时Crawler之间交换信息使用的。每个Crawler在爬行过程 中,从网页中提取大量的URL待爬行。按照爬行策略,其中有些URL应该交 给其他Crawler爬行,因此,需要定义该交互方式。具体格式定义如下 [Command][\r\n】[Head]t\r\n“∈o矗tent"XrⅦt 同样类似于HTTP协议的POST方法数据格式,各字段定义如下: 表格4 Crawler之间接口消息格式定义表 标记
corfLrflcand
Head

意义 命令,常值为:POST
URL

头部信息,包括FROM,CONTENT LENGTH。采用 name=value\r\n方式。 内容,要发送的URL

Content

FROM CONTENT—LENGTH

发送方的Crawlet

ID

要发送的URL数据的长度,10进制可读字符串


URL数据格式定义如下: [uRLl]L\芒№nugL2 m、罨啊Etu髓瓤匮琴、挪_ 而不是每次仅传递一个,以提高效率。

。’一

5"“r“,

“6

。∞“+

即在每个URL后面用回车换行符分隔,通过这种方式可以一次传送多个URL

6功能与实现
6.1

Master功能与实现
Master所要提供的功能有:查询存储策略,制订爬行策略,向Crawler发布策略,维护

与Crawler之间的心跳,用户交互接口,Master之间数据同步。系统结构图如下:

29

第三章分布式爬虫系统

图12

Crawler

Master系统结构图

如图所示,Master中主要有五个进程”分别实现以上所需的功能。 1)存储策略查询(Storage
Strategy Query)。

存储策略查询的作用是保持存储策略的及时更新,通过策略文件中定义的发布时 间,定期从wsc策略发布者查询新的策略。查询采用HTTP协议,请求查询URL即 可。该功能采用Java实现,可以直接使用Java核心库中提供的HTTP访问方法。具体 实现伪码如下:

2)心跳系统(Heart Beat)。 心跳系统的作用是持续检测爬虫的运行情况,接受爬虫定期的信息报告。爬虫定期 向Master发送内部信息,在没有信息需要发送时,爬虫需要发送空消息,以便Master 确认它没有宕机。 心跳系统侦听一个固定端口,等待接收爬虫发送信息,提取其中重要的状态信息(队 列长度等),并更新爬虫活跃时间点。系统设定一个爬虫最长不活跃时间T,Master心 跳系统中维护一个爬虫活跃表,记录每个爬虫最后活跃的时间点(,astActiveTime)。 心跳系统定时扫描该表,检查不活跃爬虫(1astActivenme+T<currentTime)。如 果发现不活跃爬虫,则向系统管理员发出警告。 3)策略生成器(Strategy Generator)。 策略生成器的作用是生成爬行策略。爬行策略的生成可以是由系统管理员通过用户 界面设定来生成,也可以由心跳系统自动生成。

6。这里的进程是指一个独立的执行过程.而不是操作系统中严格定义的进程。在实际实现中.使用的是线
程。
30

第三章分布式爬虫系统

目前的爬行策略主要有:站点Hash值区间爬行,指定站点爬行,URL模式爬行, 不爬行。
a)

站点Hash值区间爬行是将站点按照Hash值划分区间,每个区间由~个爬虫 专门负责爬行。 指定站点爬行即专门将某个站点指定到一个爬虫负责爬行。 URL模式爬行是按照正则表达式的方式指定URL模式,符合该模式的URL 交给某个爬虫进行爬行。 不爬行是为了禁止对某些URL进行爬行,按照以上策略进行定义,但在策略 里面明确声明不允许爬行这些URL。 多个策略可以一起使用,采用过滤方式,即依次遍历各个策略,找到匹配 的策略,即将URL交给相应的爬虫进行爬行:如果不符合,则试图匹配下一 条策略,直到找到符合的策略,或者遍历完所有策略。如果遍历完所有策略, 仍然没有可以匹配的(这种情况应该在生成策略的时候避免),则向Master发 送错误信息。 在有爬虫宕机或者新爬虫加入系统之后,一段时间内…,系统管理员没有 重新发布爬行策略时,策略生成器将根据系统当前情况自动生成新的策略。如 果是某个爬虫宕机,策略生成器会挑选若干台负载相对较小的爬虫,将宕机爬 虫所负担的工作分解,分别指派给它们,生成新的爬行策略,并保存上一次爬 行策略的副本。

b) c)

d)

爬行策略文件具体格式见附录f11。 4)策略发布者(Strategy
Publisher)。

策略发布者的作用是将存储访问策略、爬行策略发布给爬虫和其他备份主服务器。 策略发布者按照发布接口,采用TCP协议,连接爬虫系统侦听的端口,并将策略按照 接口定义发送给爬虫,随后关闭连接。与备份Master数据同步时,采用同样的方式发 送给备份Master侦听的心跳接口。 5)用户接口(User
Interface)。

用户接口主要作用是提供系统与管理员的交互能力,让系统管理员能够随时了解系 统运行的一些状况,并能够调整系统运行。 系统管理员可以随时查看Master收集的各个爬虫当前的状态信息,包括:CPU利 用率、内存利用率、网络资源利用率、硬盘利用率、当前爬行队列长度等等。另外,系 统运行中的各种错误警告都及时显示在屏幕上,咀便管理员能够及时发现。 系统管理员还可以根据系统当前状况,设定爬行策略。用户接口将根据策略生成器 将用户设定生成策略,然后由策略发布者发布出去。 由于目前开发时间紧迫,暂不提供非常友好的GUl71界面,而只提供简单的命令行 调用。 6)守护进程(Daemon Process)。 守护进程的作用是监视以上进程运行情况,在发现某个进程崩溃时,能够及时做一 些恢复工作(重启进程),记录日志,帮助诊断。系统启动之后,首先启动守护进程, 然后由守护进程启动其他进程,并一直监视它们的运行状况。 Master全部功能都使用Java实现,基于Java
SE

5平台。Java拥有很好的跨平台特

性,程序发布之后可以直接在多种主流计算机平台上直接运行。并且Java还拥有很多 其他优点帮助快速开发,具有良好的运行效率(虽然比C稍差,但还是能够足以应付

70这段时间留给管理员维护,如果该时间段内管理员不能完成维护工作,应该重新设置爬行策略。
”Graphical User

Interface,图形化用户界面,其优点是直观形象,易于操作。

第三章分布式爬虫系统

这种应用的)。

6.2

Crawler功能与实现
Crawler的功能主要有:接收Master发布的策略,爬行网页,维持与Master的心跳,把

爬行下来的网页存储到WSC,以及与其他Crawler之间的协调。系统结构如下图:

图l 3 Crawler系统结构图

如图所示,系统由五个模块构成:命令接收者(Command Receiver),心跳系统(Heart Beat),爬行机器人(Robot),存储驱动(Storing Driver)和URL验证器(URL Validator)。 划分为三个进程,最后三个模块在一个进程中运行,另外与Crawler Master类似,还增加一

个守护进程。
1)命令接收者(Command
Receiver)。

主要作用是实现:Master的策略发布接口,接收Master发布的策略;Crawler之间 的协调接口,接收其他Crawler发送过来的待爬行URL。命令接收者启动后侦听一个固 定端口,等待接收Master或者其他Crawler发送的命令。这里,两个接12J复用同一个端 口,命令接收者根据接收的消息进行解析。将发布的策略和待爬行URL都发送给Robot 模块,由Robot根据簧略进行爬行。 命令接收者使用Java实现,Java核心库中提供的类1ava.net ServerSocket良好的封 装了TCP服务器端的网络访问接口。 2)心跳系统(Heart Beat)。 主要是向Master发送Crawler运行状态信息。心跳系统定期收集系统内部的各种状

第三章分布式爬虫系统

态参数(CPU,内存,硬盘,网络等),错误信息,按照Master与Crawler交互的心跳 接口的规定,建立TCP连接,格式化消息,发送到Master侦听的端口,然后关闭连接。 在没有信息需要发送时,心跳系统也要定时发送空消息,让Master知道自己没有宕机。 3)URL验证器(URL
Validator)。

在Robot爬行某个URL之前,需要验证该URL是否应该爬行。这主要有两个原因:
?

按照爬行策略,检查该URL是否属于本机爬行任务。爬行策略可以设定多个, 在检查爬行策略时,按照策略设定的顺序,逐个匹配。找到匹配的项,如果是 本机爬行,则交给Robot爬行。如果不是本机爬行,而是其他爬虫,则交给心 跳系统,由它发往所属的爬虫。如果没有匹配的,则认为爬行策略有错误,记 录错误日志,由心跳系统发送给Master。 检查该URL是否应该爬行。有些URL虽然归属本机爬行,但是有一些特殊情 况是不应该爬行的。比如有的URL已经爬行过了,不应该重复爬行,否则可 能会出现循环,从而导致大量重复爬行,甚至形成死锁,这对系统是十分有害 的。因此要建立URL爬行记录数据库,标记每个URL爬行的时间和该URL 的更新周期。下次要爬行该URL时先查询一遍数据库,检查该URL是否需要 更新。

?

4)爬行机器人(Robot)。 爬行机器人专门负责爬行互联网,其爬行核心本文采用JSpider”。JSpider是一个 完全用Java编写的开源爬虫程序,使用LGPL版权“发布,具有高度的可配置性,灵活 性以及很高的爬行性能。采用己有的开源爬虫可以减轻系统开发的负担,并且由于 JSpider开发组经过多年开发,相对来说,系统比较稳定、可靠,性能较高。在基于Java 的JSpider上开发爬虫系统,开发效率高,可移植性好,运行性能也很好。爬行机器人 的实现伪码如下:

71网址:http://j—spider sourceforge ned

73是GNU发布的一种供开源软件使用的版权协议,它允许其他软件作者使用LGPL软件,而不用公开源 码。详细说明参看:hltp://wwwgnu org,copylcn化sser
html

第三章分布式爬虫系统

5)存储驱动(Storing

Driver)。

爬行机器人如果没下载一个网页都直接存储到WSC,那么整个爬行的效率会大幅 降低。这是因为一方面会频繁的处理网络连接,占用大量CPU;另一方面操作系统不 停的处理小文件,效率很低。因此本文设计中,爬虫系统在存储之前先将很多网页打包 成一个大文件,然后再一次性传送到WSC。为此,本文设计了存储驱动,供爬虫系统 存储网页。爬行机器人启动存储驱动之后,只需要调用存储驱动的保存接口,传递当前 下载网页的相关参数即可。后面将详细说明存储驱动的设计。 6)守护进程(Daemon
Process)。

与Master类似,以上五个模块,三个进程都由守护进程启动,并且一直监视其运 行情况。在某些进程意外终止时,试图重新启动他们,保证系统的可靠性。

6.3存储驱动设计与实现
存储驱动将多个网页打包成Web Object Package文件,WSC数据存储驱动接收Crawler 发送的Web object,将它按照过期时间打包成Web object Package,并提供Package描述文 件。当WebObject Package达到一定大小,或者存放了一定数量的WebObject对象后,将二 者按照标准的zip方式压缩,然后上传到WSC提供的FTP空间。

约定
1)数字二进制存储。数字采用从高位到低位二进制存储。 2)字符utf-8编码存储,基本字符兼容ASCII编码。
3)

日期二进制存储。采用8字节长整型数字表示从1970—0l—01

00:00:00

000开始的毫

第三毒分布式爬虫系统

秒数,数字二进制存储。

Web对象文件(Web Object File)

概述(General)
Web对象文件用来存储单个Web对象,通常只在解析处理时暂时使用,而不作为 持续存储使用。它主要包含如下信息:Web对象的url,Web对象的MIME类型,Web 对象的下载时间,下载消耗时问,Web对象预计的过期时间以及Web对象数据。

Web对象的预计过期时间是指,爬虫预计在这个时间之前,Web对象会更新,爬
虫会在这个时间之前重新下载Web对象。因此,通常在这个时间以后,该Web对象可 删除。

规范(Specification)




扩展文件名为webo。例如:—20 6030512 —5 43 5.webo。
结构。Web对象文件分为头部和数据两部分。
2 1

命名。Web对象文件分为主文件名和扩展文件名。主文件名根据应用需要命名

头部定长14字节.定义如下: 表格5 Web对象文件格式头部定义表

I-5



7—8

9.10

11一14

格式标识(WEBO)
0xFF5745424F
2 1

版本
0x01

Mime类型长度
l5

URL长度
357

数据长度
.56,070

1格式标识及版本。6字节:0xFF(1字节),WEBO(4字节)为格式标 识,版本用I字节表示可表示200多个版本。 MIME类型长度(Mime Size)。2字节,数字二进制存储,最长可达65535。 通常的MIME TYPE都在二十字节以内。 URL长度(Url Size)。2字节,数字二进制存储,最长可达65535。通 常URI。长度都在数百字节以内。

2】2

2 1‘3



1,4数据氏度(Data Size)。4字节,数字二进制存储,最大可达40亿,通 常下载的Web对象都会在几十M以内。

2 2

数据部分前面20字节定长,后面不定长,结构如下: 表格6 Web对象文件格式数据段定义表



5.18

19.26

27.34

下载开销时间

下载时间
MIME TYPE URL

预计过期时间

数据
2.2

l下载开销时间。4字节,Web对象下载所花费的时间(毫秒数),数字 二进制存储。 2下载时间。8字节,日期二进制存储。





第三章分布式爬虫系统

2 2 3 2.2 4

预计过期时间。8字节,日期二进制存储。
MIME

TYPE。不定长,长度由头部Mime Size确定,字符utf-8编码存

储。
2 2 5 2 2 6

URL。不定长,长度由头部Url Size确定,字符utf-8编码存储。 数据(Data)。不定长,长度由Data Size确定,

Web对象包文件(WO Package File)

概述(General)
Web对象包文件将若干个W'eb对象打包存储,是一种可以作为持续存储的文件格 式,用来存储大量Web对象。

规范(Specification)


命名。WOP文件名分为主文件名与扩展文件名。主文件名根据应用需要设定,扩 展文件名为webop。例如:4二2 2QQ§Q3 12】22盟Q5鲤.型曲蛆。 结构。WOP文件分为头部和数据两部分。格式如下: 表格7 Web对象包文件格式头部定义表



1.5



7.8

文件格式标识(WOP)
0xFF FF 57 4F 50

版本
Ox01

分割符
0x0D 0A

WebObiect 1 WebOblect 2

头部固定6字节,0xFFFF(2字节),WOP(3字节),字符ASC[[存储,版本I字节, 分割符(\^n)2字节。后面添加Web对象的二进制存储,即按照Web对象文件存储格式 存储。

Web对象包描述文件(WOP

Description

File)

概述(General)
WOP描述文件用来描述WOP文件信息,将数据对象打包存储与WOP描述信息分 开,便于维护、解析与处理。缺点是文件独立性不强。WOP描述文件由以下信息组成: WOP过期基数,指数,过期时间,各个Web对象在WOP中的位置、大小等。

规范(Specification)
命名。WOP描述文件名是在它所对应的WOP文件名后添加扩展文件名.desc。例

36

第三章分布式爬虫系统

如:4.:2 2QQ§塑1 2】22塑Q5鲤:型£bQP:d!望。


结构。Web Object Package描述文件分为头部和内容两部分。头部描述整个Package 的一些信息,内容部分描述Package中各个Web Object所在位置和大小。
2.1

头部定长28字节,定义如下: 表格8 Web对象包描述文件格式头部定义表

【1.5
【格式标识
【0xFFWOPD




7.8

9.10

11。18

19.26

27—28

版本
Ox01

基数


指数
?2

建立时间
3568987465100000

过期时间
3568987465 l 35764

分割符
;r锄

11格式标识及版本。6字节,0xFF(1字节),WOPD为文件格式标识(4 字节,ASCII编码),版本用1字节标识,可表示200多个版本。 1.2基数和指数。均2字节,有符号数字二进制存储(从高位到低位)。Web 对象的有效期通过基数和指数来确定,基数的单位是天(24小时)。 000开始的毫 000开始的



2】3建立时间。8字节,时间长整型表示法,从1970_l-1

0:0:0

秒数,从高位到低位二进制存储。表示Web对象包创建的时间。


1.4过期时间。8字节,时间的长整型表示法,从1970—1一1 5分割符。2字节,回车、换行。

0:0:0

毫秒数,从高位到低位二进制存储。表示Web对象包最后过期的时间。
2 I 2 2

内容定义如下:

旧醚】?豫、n1[d£fs鳢褂嚆i臻嬲≮藓箍
内容部分由多条记录组成,一条记录包括Web对象url,在WOP中的位置 (offset),大d、(size)等信息,可读字符串,采用uff-8编码存储。例如: c:2i:E兰曼二兰塑l墨曼蔓曼二羔l曼

h=:童:/,’删.舱‘_*tu.三j.j:弛?Lrl,i
存储包文件(Storage

Package File)

概述(General)
Storage Package

File文件格式是发送到WSC进行存储的文件格式,由存储驱动

(Storage Driver)将爬虫(Crawler)爬行得到的Web对象(Web Object)打包而成。

WSC解析Storage Package文件后,存储到本地磁盘。

规范(Specification)


命名。文件名由两部分组成:主文件名和扩展文件名(后缀)。主文件名与Web Object Package¨e相同,由基数,指数,时间组成,扩展文件名为‘spf’。例如:
4-2 200603 1 2 1 22030564.spf。



结构。SPF是标准的zip格式,由Web对象包(Web Object Package)文件和Web 对象包描述(Web Object
Package

Description)文件组成。

第三章分布式爬虫系统

7系统测试与分析
由于实验条件的限制,本文爬虫系统的测试只有三台爬虫服务器,配置分别如下: 表格9爬虫实验机器配置表2 编号
1 2 3 CPU
AMD Semprom 2500+2 IG lriteI Pentium M 1 6G

内存
DDR 5l 2MB DDR 5l DDR

操作系统
WInXP Pro SP2 W1nXP HOME SP2 W1N2K Pro SP4

Java环境
JREl 5 06 JREl 5 O JREl 5 06

其他
兼容机
Del】600m

2MB

AMD Semprom 2200+1 5G

756MB

兼容机

由于计算机配置并不统~,因此测试时,可能有的计算机性能较其他计算机差距较大。 并且由于网络条件的不确定性,也很难测出爬虫数据与爬行性能之间的精确关系,但也能从 测试数据得出大致的关系。 测试数据如下: 表格10多台爬虫计算机测试数据表 I测试编号
1 2 3

计算机


测试时间(min)
35 39
43

网页数目
577 658/834 765/699/339

字节数(KB)
27,409 35.56】/44、012 37,022/43,584119,789

l,2 1,2,3

按时间取平均如下 表格}f多台爬虫计算机测试数据表 测试编号
l 2 3

网页数/min
16 17/2l 18/|6/8

网页总数/min
16 38 42

字节数/min(KB/min)
783 912/1129 861门014/460

字节总数(KB/min)
783 2041 2335

从以上表格可以看出,通过扩展爬虫,基本上并不影响爬虫的爬行性能,计算机{三次 爬行下载速度变化并不大.计算机2两次爬行的下载速度变化也不大。二者性能相当,后者 略强于前者。计算机3只爬行了一次,但是性能上明显弱于前两台计算机。该结果也符合 CPU-|生能情况。

。卜ki一*
l一


,i

..㈣㈣m∞d、



。剥婆姿蓄,Z……;,







二:二茹—一

图14爬虫系统下载曲线 从图中可以明显看出,爬虫性能随着爬虫数目增加并没有明显下降,系统扩展性很好。 随着爬虫数目增加,系统总体性能增加不是直线,主要原因是第三台计算机性能较弱。后两

第三章分布式爬虫系统

次测试中,前两台计算机总体爬行性能分别是:(1 7+21)/08+16)=38/34,
(912+1 129)/(861+1014)=204I/1 875。可能第二台计算机因为网络或者其他原因性能略有所降

低,总体上并没有很明显的性能下降,因此仍然可以认为系统整体性能与爬虫数量成线性关
系。

总体说来,整个系统的性能基本等于所有爬虫性能之和,可以认为整体性能随着爬虫数 量增加,也成线性增加。

第四章分布式存储系统

第四章分布式存储系统
1背景与需求
在早期,很多搜索引擎的设计中,都很少提及存储。其原因主要有:很多搜索引擎在只 需要索引数据就可以提供查询服务,并不需要把所有下载的网页及其他Web对象保存起来。 另一个原因是Web上网页数量庞大,难以存储、组织和管理。即使是目前最强大的数据库 系统,也无法管理如此海量的数据:即使是自己开发管理系统,也可能需要够买很贵的专用 存储设备。还有一个原因是当时人们并没有认识到这些下载的网页除了建立索引以外,还可 以从中挖掘很多有价值的东西。比如提供网页快照功能;建立图片搜索,提供图片缓存;网 页内容相似度研究;自动网页聚类等等。 目前虽然很多搜索引擎都会存储大量的Web对象,提供多种服务,进行多种数据挖掘 工作。但本文却没有找到一个搜索引擎的相关研究详细描述了搜索引擎中如何存储Web对 象。只有Google在~些论文和演讲中提及过他们采用Google文件系统,他们也有一篇专门 介绍Google文件系统的论文,比较详细的介绍了Google文件系统的设计。 大容量、高性能存储服务不但是搜索引擎系统所需要的,而且在很多其他系统中,也有 着广泛的应用(比如:视频点播系统,公共电子图书馆,大型的网上音乐商店等等)。针对 这种需求,很多厂商及开发者已经提出了多种解决方案。有基于专用设备的存储系统,比如:
DAS,SAN和NAS。


DAS(直接存储系统,DirectAttached Storage)采用独立的外接设备并通过标准接13与 服务器相连。存储设备可咀与多个服务器相连,如果一个服务器出现故障,仍然可以通 过其他服务器访问。如下图所示,由于DAS设备与服务器之间的连接链路数量有限, 因此很难进行大容量扩展。


图l 5服务器共享DAS设备

p景熊》

第四章分布式存储系统

p萝蹉妙∈№+鸪 圉—毋
图16NAS存储系统


NAS(网络存储系统,NetworkAttached Storage)。NAS将存储设备直接连接到网络上, 很好的解决了存储扩展问题。客户端请求存储服务时首先连接到服务器,然后由服务器 向NAS设备发送Io指令,NAS将数据传递给服务器,然后服务器再将数据发送给客 户端。在大型网络中,数据经过多次往返,将消耗大量的网络带宽,降低了系统的响应 速度。

3.

SAN(存储区域网络,Storage

Area

Network)。SAN是NAS的进一步发展,SAN有自

己单独的数据访问网络,不占用客户端应用的网络带宽。如下图所示,SAN网络采用

光纤传输,带宽可达10Gb/s。

图17 SAN存储系统

还有很多基于SAN和NAS的分布式文件系统,如:惠普公司开发的DiFFS和SGI开
发的CXFS等等。这些专用系统通常价格昂贵,并且在它们上面进行灵活的开发、应用扩展 都比较困难。也有基于普通计算机的各种分布式文件系统,比如:Network
File System, Andrew File System,Coda File System,GIobal File System,General Parallel File System,以

及近几年Google推出的Google

File System。

分布式文件系统虽然已经有约20年的历史,很多分布式文件系统在它们针对的应用中 都已经很成熟了。但在针对海量的Web存储来说,在性能上、可靠性等方面仍然难以满足 需求。Google文件系统针对自己的需求,在学习已有分布式文件系统的经验基础上,充分 优化了系统,极大的提高了系统的可靠性和性能。GFS(Google File System)构建在廉价的 PC系统之上,包括单一的GFS Master,多个GFS Chunk Server。GFS不是完全在操作系统 层设计的分布式文件系统,而是在已有的Linux文件系统之后再封装的分布式文件系统,因 此它依赖传统的Linux文件系统。GFS将一个大文件分割成若干个固定大小的chunk,存储 到不同的Chunk Server上。GFS Master中存储三种重要的元数据:文件和chunk的命名空 间、文件到chunk的映射表以及chunk及其备份的位置信息(为了提高文件存储的可靠性, GFS中对同一份数据一般存储在三台不同的主机上)。Chunk Server中每个chunk大小为



第四章分布式存储系统

64MB,关于每个chunk大小的具体数值选择并不是随意的,而是很有技巧。ors中执行一 个简单的数据读取操作工作流程如下:首先,客户端把要访问数据在文件中的偏移量转换成 chunk索引号,向GFS Master发送请求文件名和chunk索引号;GFS Master收到请求后查 询元数据表,反馈给客户端该chunk所在位置;之后,客户端就可以直接与存储该chunk的
Chunk

Server请求数据了。

本文所开发的搜索引擎中需要一个针对Web对象存储的,能够提供极大容量,高性能, 高可靠性,可扩展的,比较灵活的存储系统。由于Google文件系统已经成功运用在Google 开发的很多系统中,并且有一个比较详细的设计,本文在参考了以上多种系统之后,决定采 用Google文件系统的设计来实现分布式Web存储。然而在进一步考察了Google文件系统 之后,发现Google文件系统仍然存在诸多不足,难以应用到我H J的系统中。 1)Google文件系统是一种基础的文件系统,专门针对大文件存储和大数据量的访问 而设计,而不是直接针对Web对象存储。为了存储Web对象,需要将Web对象打 包成大文件,然后再存储到Google文件系统。也就是说,需要在Google文件系统 基础之上再建立一个Web对象管理系统。Google文件系统本来就是二层构架的, 再加上Web对象管理系统,应用客户端,则会形成四层构架。虽然在逻辑上划分 为四层,但是为了提高数据访问效率,在数据交互上却并不是按照分层而隔离,应 用客户端仍然要与最底层的GFS 度大,可靠性难以保证。 2)Google文件系统为了简化设计,采用单Master方式。但是为了保证系统可靠性, 除了主服务Master之外,往往还需要若干备份Master。在主服务Master宕机之后, 备份Master需要能够及时代替主服务Master,因此主服务Master与备份Master 之间需要完全的数据同步。虽然GFS Master只管理元数据(meta data),并使用比 较大的chunk(64MB)来分隔大文件,以减少元数据,但元数据量仍然很大,各 Master之间的数据同步还是很复杂。 本文在借鉴了Google文件系统中若干设计思想的同时,为了解决蛆上两个重要问题, 提出了基于策略的分布式Web存储系统。在基于策略的分布式系统中,Master只制订和发 布分布式策略,完全不再参与数据访问。而每个Slave都按照策略来提供服务,客户端按照 策略直接访问Slave提供的服务,Slave成为一个高度自治的系统,简化了Master的管理。 Master不再是系统中的焦点,极大的提高了系统的服务效率和可靠性,甚至在Master宕机 的时候,系统仍然能够在一定程度上提供服务。 本文通过分布式桨构提高系统的容量,通过扩展可咀提供海量存储服务;按照策略模式 访问,保证系统的高效访问和可靠性;吸取Google文件系统中持续的错误检测,多备份存 储,快速数据恢复,一致陛数据维护等机制保证系统可靠性,
Chunk

Server交互。整个系统过于复杂,开发难

2目标
针对如上需求,本文设计Web存储系统的目标有: 1)极大的存储容量。目前常见搜索引擎的容量已经达到亿量级(页面),Web页面的 大小约为10KB量级,即存储容量要求至少是l×105×10KB=ITB量级。考虑到 为了保证系统的冗余备份、可用性、扩展性等,存储系统容量至少应在10TB量级。 2)高性能。高性能包括以下两个方面的内容:
a)

爬行系统对存储系统的高性能要求。爬行系统在短时间内抓取大量的Web对 象,然后存储到存储系统。为了提高效率,往往是进行批量存储大量Web对 象。并且爬虫系统往往是由若干独立的Crawler服务器同时进行爬行,因此,
42

第四章分布式存储系统

存储系统需要满足并发的大数据量存储需求,提供稳定的带宽。 b) 索引系统及其他分析系统对存储系统的高性能要求。分析系统往往一次性读取 大量Web对象,进行分析处理。因此存储系统需要支持高性能的并发大数据 量读取,提供稳定的带宽。 3)可靠性。存储系统是整个分布式搜索引擎中的后端核心部分,所有其他系统都依赖 它提供的存储服务。系统应保证极小的出错概率,保证极高的可用性。然而错误 总是不可避免的,出错之后,应该能够保证尽量少的数据丢失,并且能够快速恢复。 4)可扩展性。在搜索引擎运行的初期,由于数据量较少,只需要少量存储服务器就可 以应付。但随着时间的积累,以及可能开展新的研究和服务,存储量会越来越大。 系统需要良好的可扩展性,能够通过添加新的存储服务器来不断提高系统的存储能 力。 5)兼容性。系统尽量不要构建在特殊的、专有的、接口封闭的软硬件上,而是尽量采 用比较通用的、标准的、比较开放的软硬件系统,使系统更有生命力。能够进行持 续开发升级。

3重点问题解决方案
本文分布式Web存储系统主要解决Web存储中的两个问题: ”海量数目存储问题。 目前网页数量已经超过百亿,即使只存储其中1%也需要10TB量级的数据存储能 力,随着网页数量不断增长,网络爬虫系统不断下载新的网页,系统存储容量应达到几 十TB,甚至上百TB。因此系统必须具有非常好的可扩展性,能够使上百甚至上千的 存储服务器协同工作。 本文实现的Web存储系统采用基于策略的分布式架构。整个存储系统由若干存储 组构成,每个存储组又由若干存储单元构成。同属于一个存储组的存储单元存储完全相 同的Web对象,即所有要存储的数据都有若干备份,保证数据的安全性,也提高了系 统的可靠性。Web对象根据URL划分为不同的区间,每个存储组负责其中一部分的存 储。主服务器制订存储策略,它描述整个存储系统中的各个存储组所存储的Web对象 空间。外部系统需要访问存储服务时,首先向主服务器查询存储策略。然后根据存储策 略直接访问存储数据的存储组。与一般基于文件系统的分布式存储系统不同,主服务器 不存储任何元数据,只负责存储策略的制定。只要存储策略没有变更,所有的数据访问 就不需要主服务器参与,从而将主服务器从数据访问中解脱出来,极大地提高了系统的 可扩展性,即使整个存储系统由上千台存储服务器组成,并且不断进行频繁的数据访问, 主服务器也不会成为数据访问的瓶颈。 随着爬虫系统不断爬行互联网,某些存储组的存储容量可能不足以存储分配给它的 URL空间的数据,此时应该扩展该存储组。存储扩展需要三个步骤:首先增加新的存 储组到系统中;然后将原来存储组的存储URL空间分割一半给新的存储组,也可以由 管理员来设定;最后新存储组从原存储组下载所有数据。完成以上三个步骤之后,两个 存储组的存储的数据就是一样的了,但是爬虫系统会按照新的存储策略将相应的网页分 别发送给它们。虽然两个存储组此时的存储空间都很紧张,但是随着时间的推移,一部 分过期的Web对象将不再保留,存储组会定期清理,从而得到很多新的空闲存储空间。 这种方法保证了在系统扩展时,数据的一致性。即存储策略更新期间,外部系统访问存 储服务时,无论访问哪个存储组都可以得到相应的数据,系统不会中断存储服务。 主服务器无论是在数据访问期间还是在存储策略更新期间都只参与很少量的工作,
43

第四章分布式存储系统

即更新和发布存储策略,相对于传统的分布式系统,本文中的Web存储系统极大地提 高了系统的可扩展性,能够管理数量庞大的存储服务器。 2)数据访问性能。 传统的分布式系统存储海量数据,如果提供频繁的数据访问,系统性能往往会急剧 下降,主服务器很容易成为系统瓶颈。 本文的存储系统采用基于策略的分布式架构,外部系统访问存储服务只需要按照策 略规定,直接访问存储组中的某台服务器即可,中间不需要主服务器的参与,避免了系 统瓶颈。另外,Web存储系统在存储Web对象时,都是将大量Web对象打包到一个文 件中,一是操作系统难以管理数目庞大的文件,二是在进行网络传输时,可以提高效率。 本文的Web存储系统与爬虫系统和索引系统的数据传输都采用标准的FTP协议,Web 存储系统提供FTP服务。有很多厂商和软件作者开发了性能优异的FTP服务器软件, 在进行数据传输时,速度快,占用资源少。采用专门的文件传输协议和优秀的FTP软 件也是提高系统性能的一个重要方面。 3)可靠性。 首先每个存储组都由若干存储单元组成,即所有存储的数据都由若干备份,在某个 存储单元数据损坏时,可以查询同组其他存储单元上的数据,通过FTP协议下载到本 地。整个系统中存储组内、存储组与主服务器之间都维持心跳,持续检测系统内部的各 种异常情况,如果某些服务器宕机,就能及时发现,通知系统管理员维修。主服务器也 采用多备份。由于主服务器不再维护元数据,主服务器之间的数据同步也变得非常简单, 基本上只需要同步存储策略即可,这样在~台主服务器宕机时,仍然可以通过备份主服 务器查询存储策略。在程序设计上,每台服务器上都有一个守护进程,持续检测各个服 务进程是否正常工作。在某个进程意外崩溃时,守护进程将重新启动该进程,并记录错 误臼志,帮助修正程序中的错误。

4架构
Web存储系统的作用是为搜索引擎提供大容量的存储服务。本文Web存储系统采用分 布式架构,如下图:

第四章分布式存储系统

图18 Web

Storage

Cluster架构图

Web存储系统分为两个主要部分:Master和Storage Team。Master的主要功能是管理整 个存储系统,制订存储策略,监视整个系统运行情况。Storage Team的作用是提供存储数据 服务。首先Master制订存储策略,通过策略总线发布。爬虫系统通过策略总线查询存储策 略,然后将爬行下来的Web对象按照存储策略存储到相应的Storage Team中。索引系统查 询策略,然后根据策略下载数据,计算索引。交互过程如下图
'1

Crawler

Cluste4|lndexina Cluste十
11

WSC

Maste ri

WSC

Storaae

Tear|『


。l, 、

GeIsl。ra6eStralegY
storage.;trategy Store

、广



]GetSt。fageStrategly

l,3””geStrategy] T、 GetSt4‘£ ,gePackage

;I, J、

810‘。geIPaLc“88985“8

廿

’.一



图19WSC交互序列图

45

第四章分布式存储系统

在WSC中,一个Storage Team由若干个Storage Cell组成。一个Storage Cell是一个独 立自治的工作单元,提供完整的存储服务。Storage Team中的所有Storage Cell对外提供的 服务完全相同,一来可以多备份,提高可靠性;二来可以提高系统并发处理能力。StorageTeam 中的所有成员根据选举规则选定~个Team Master,Team Master检测Team内部状态信息, 并与WSC Master交互,其他Team成语不直接与WSC Master交互。 详述 1)WSCMaster功能详述。
WSC Master的主要功能有:帮助Storage Team组态;为Storage Team制订存储策

略;持续监测系统运行状态,保证系统可靠性。 最开始,同一个Storage Team中的各个成员Storage Cell并不知道其他Storage 的存在,它们都认为Team中只有自己一个成员,自己作为Team Master与WSC
Cell

Master

交互。WSC Master返回它们其他Team成员的信息。每个Storage Cell就可以根据Team Master的选举规则选举出Team Master,之后只与Team Master交互,由Team Master 与WSC Master交互,报告Team内部信息。
WSC Master还要根据Storage Team情况设定存储策略,使需要存储的Web对象可

以根据该策略存储到不同的Storage Team中。WSC Master制订了存储策略之后,通过 策略总线发布.Crawler Cluster和Indexing Cluster都可以从策略总线查询该策略。
2)WSC Storage Team功能详述。
Storage

Team由若干Storage Cell组成,作为一个整体对外提供存储服务。对外根

据存储策略提供存储、读取等功能。内部需要收集内部信息,通过心跳系统提交给WSC Master,维护内部数据一致性。
3)WSC Storage Team Master功能详述。
Storage

Team内部信息提交给WSC Master,如果每个Storage Cell都直接与WSC

Master交互,在Storage Cell很多的情况下.必然对WSC Master造成压力,可能限制 WSC的可扩展性。在Storage Team内部选举出一个Storage Cell作为Team Master, StorageCell与TeamMaster保持心跳,发送内部状态信息。TeamMaster收集内部信息, 承担一部分管理任务。Team Master只将Team内部必要的信息发送给WSC Master,而 不必在内部状态变化不大的时候就将全部信息发送给WSC Master。这样可以有效的减 少WSC Master的压力,提高系统的可扩展性,也易于管理。
4)WSC Storage Cell功能详述。 WSC Storage Cell是WSC中最小的工作单元,对外提供完整的存储、读取等数据

访问服务,对内保持与Team Master的心跳,并维护Team内部数据一致性。保证在某 些StorageCell宕机重启,或者新增加StorageCell的时候,数据能够保持一致。 数据是一个系统中的核心,数据的可靠性关系到整个系统的正常运行,因此WSC的可 靠性要求相对来说是最重要的。为了提高系统的可靠性,架构上从三个方面保证:
?

WSC Master双备份。虽然基于策略的分布式架构保证了即使在WSC Master宕机的情

况下.系统仍然可以正常提供服务(只要其他Storage Team能够正常服务)。但仍然无 法保证系统真正可靠,只有采用Master多各份机制解决。与Crawler Cluster类似,主 Master服务器与备份Master服务器对外提供完全相同的服务,内部进行数据同步。由 于使用Team Master来承担一部分管理工作,Master需要维护的系统数据很少,Master 之间同步数据也很容易了。通过多Master架构,保证了系统的可访问性。
?

Storage

Cell多备份。WSC的主要功能是存储数据,因此数据的可靠性也是WSC可靠
Cell

性的核心内容。系统通过多Storage Cell方式,在同一个Storage Team中Storage

第四章分布式存储系统

所保存的数据完全一致,保证数据是可靠的矗E某个Storage Cell宕机,或损坏时,Storage Team内部会及时采取数据同步措施,进行快速数据恢复。Storage Cell的多备份,保证 了存储数据的可靠性。
?

心跳系统。在每个Storage Team内部,Storage Cell保持与Team Master的心跳,不断报 告内部信息。在Storage Cell出现错误时,Team Master即可检测到,然后提交给WSC
Master,由WSC Master通知系统管理员,及时处理错误。如果Storage Cell宕机,Team

Master在心跳过期时即可检测到。在WSC内部,每个Storage Team都通过Team Master 保持与WSC Master的心跳,如果Team Master宕机,WSC Master和该Team内部的
Storage WSC

Cell都可以检测到。Storage Cell会根据选举规则选举出新的Team Master与 Master继续保持心跳。同时WSC Master通知系统维护人员处理原来的Team

Master故障。 在系统存储容量不够时,Storage Team会向WSC Master发送警告,WSC通知系统维护 人员,准备添加新的Storage Team以扩充系统容量。WSC在扩充时是以Storage Team为单 位的,增加新的Storage Team可以增加整个系统的存储容量(如果只是在一个Storage
Team

中增加Storage Cell只会增加该Storage Team的备份数,可以提高数据可靠性和数据访问并 发能力)。在增加了新的Storage Team之后,WSC Master需要重新制订存储策略,将存储任 务分配到新增加的Storage Team中。 由于WSC Master不直接参与数据访问,应用客户端都按照访问策略从Storage Team中 选择一个Storage Cell,直接访问数据,因此在网络条件允许的情况先,系统的性能基本上 可以认为与StorageTeam和StorageCell的数量成线性关系a StorageTeam和StorageCell数 量越多.数据访问能力越强。

5接口 5.1外部接口
外部接口定义了WSC与爬虫系统、索引系统之间互相通信,交互信息的内容和需 要遵守的协议、规范。包括如下几个方面: 1)WSC存储策略发布接口。 存储策略通过策略总线发布,客户端通过策略总线查询需要的策略。WSC的 存储策略由WSC Master采用HTTP协议发布。爬虫系统和索引系统都发送HTTP 请求.使用Get方法。客户端应在请求报文中.包含自己的1D(CRAWLER
INDEXING MASTER.

MASTER),当前己拥有的存储策略版本,以及请求存储服务类型。

WSC Master返回相应的存储策略文件。

为了管理存储策略的更新,存储策略采用版本管理机制。每个存储策略都有一 个版本号,存储策略更新后,版本号增加。版本号采用32位有符号整数的正数域。 客户端最开始请求时,初始版本号为0,WSC Master返回最新版的存储策略。随 后存储策略若更新,客户端请求时,发送的版本号比当前版本号低,则返回新版存 储策略;如果未更新,则版本号相同,WSC 策略文件。 存储服务类型目前只有爬虫系统存储服务和索引系统数据读取服务两种,类型 定义分别为:Crawler Store和Indexer Read。存储策略采用XML Schema定义。存 储策略需要包含如下信息:
Maste r返回一个空网页,而不是存储

第四章分布式存储系统

a)

存储策略版本。为了简化存储策略的更新与同步,存储策略引入版本管理方式。 存储策略改变时,版本号增加,因此版本号越大,则存储策略越新。每一个存 储策略版本定义如下信息:存储策略版本号,存储策略生效时间,存储策略有 效时间,下一存储策略发布时间。

b)存储工作组(StorageTeam)信息。包括所有的StorageTeam,以及StorageTeam 中的各个存储单元列表,以及它们的访问接口配置信息。
c)

策略组。策略组可以包含多个存储策略。存储访问时根据若干个存储策略形成 一个存储策略过滤器。客户端首先用第一个存储策略匹配要访问资浦所在位 置,如果找到则匹配完成。如果找不到,客户端用下一个存储策略匹配,如此 进行,直到找到匹配的策略,然后访问该资源。如果匹配完所有的存储策略, 仍然找不到匹配项,则记录错误日志。这种情况时存储策略应该避免的。

存储策略具体定义参见附录[2]。 2)爬虫系统的web对象存储接口。 如前所述,Crawler将爬行下来的Web对象发送给存储驱动程序,存储驱动程 序根据存储策略将Web对象打包成存储包文件(Storage
Package

Pile),然后按照

FTP协议将数据上传到WSC。存储驱动根据存储策略选择相应的存储工作组
(Storage

Team),并在Storage Team信息中找到给Crawler提供FTP服务的Storage

Cell以及其他FTP参数信息(jP地址、端口、用户名、密码、路径、模式等),然 后存储数据。 3)索引系统的Web对象下载接口。 首先索引系统的Indexing Master通过策略总线查询存储策略,然后根据存储 策略给Indexer分配索引任务。indexer按照存储策略中说明的FTP参数,从Storage Team中下载存储包文件。由于为了提高系统可靠性和伸缩性,Storage Team与 Indexer采用的多对多关系,以便在一些Indexer宕机时.仍然能够保证每个Storage Team上的数据都能够建立索引。也能通过多个Indexer同时对一个Storage‘Feam上 的数据建立索引,以提高索引计算的效率。但采用多对多的方式会引来另一个问题: 可能对相同的数据重复计算索引。多个Indexer可能从同一个Storage Team上下载 了相同的存储包文件。建立了相同的索引,虽然不会损坏系统数据的一致性,但却 浪费了索引计算资源。为了解决这个问题,本文在配置FTP服务器时,对于Indexer 一次只允许一个Indexer登录,从而避免重复建立索引。然而在数据下载过程中 Indexer宕机,则仍然有可能出现重复下载,并计算索引的情况,为了避免这一现 象的发生,本文在Indexer内部功能中实现了其解决方案。

5.2内部接口
内部接口定义了WSC内部StorageTeam内部、StorageTeam之间,以及StorageTeam
与WSC Master之间进行通信的内容和通信方式,包括心跳系统和数据一致性维护两方

面的内容。系统通过心跳系统来持续收集、检测系统信息与故障,使系统协调工作,并 及时做出故障处理,是系统可靠性的重要保证。数据一致性维护是针对:在系统扩展时, 新增加的服务器数据不一致;工作过程中,某些服务器出现故障,修复故障后,数据不 一致,这两种情况,进行系统数据一致性检查与维护。

第四章分布式存储系统

5.2.1心跳系统接口
)StorageTeam内部Team Master与StorageCell之间的接口。
General:

a)采用TCP连接。每个Cell都侦听一个端口,连接其他Cell时使用临时端口,但消 息都发送到Cell的侦听端口,而不是连接过来的临时端口。
b)

每个Team有一个唯一的Team ID,同一个Team里面每个Cell有一个唯一的Cell ID。不同Team中的不同Cell可以有相同的Cell 字节ASCI【码存储16进制数字。 消息都以\n\n为标识符结束。
ID。Team

ID和Cell ID都使用4

c)

各种具体消息格式
a)

建立Team时,Cell与Master的连接,:__i}:发送引j}_融港息。通过其他消息中的Cell
ID,即可判断。按照选举规则,Cell ID小的作为Master。连接方如果比被连接方 的Cell ID大,则连接方作为普通Cell,被连接方认为是Master。 Cell向Master发送空消息。 消息格式:

b1

该消息共】3字节,TeamID,CellID各4字节,\n l字节,NOOP 4字节。
c)

Cell向Master发送信息格式。 消息格式:

l[TeamlDl[CellID][in】INFO【\nl[信息内容][\n\nl

头部14字节,信息内容不定长。
?

CPU、内存利用率信息格式:
CPU2[ratio]\nMEM2【ratio]\n

完整消息格式:
l[TeamID][CellID]【、n】INFO[\n]CPU=[ratio]【in】MEM-【ratio】[\nhn\n】
?

磁盘使用率信息格式:
DISK=/USED:[己使用字节数];LEFT:[未使用字节数]}[\n\n]

完整消息格式:
I【TeamID】【CellID]\nlNFOknDISK=fuSED:[已用字节数】iLEFT:[未用字节数]}\nkn 例子:
00FA00FB\nINFOknDISK=(USED:9371530;LEFT:1554 415616}in\n

d)

Cell向Master发送警告、错误信息格式。 消息格式:

?

磁盘警告格式:
DISK={USED:【己用字节数】;LEFT:[未用-7-节数¨\n\n

完整消息格式: l[TeamID】[CellID]\nWARNknDISK=fUSED:[己用字节数];LEFT:[未用7-节数】)\n\n 例子:

L-——---------------------------------------------—————.....,.....—,......................一......——、.....................—.,...........................................—,,.,—J
?

磁盘错误格式:DISK={[错误描述】}
49

——笙塑兰坌塑茎堡堕墨竺
例于:
ooFAooFB\nERRR\nDIsK—INO SPACE LEFT!Write
disk error)\n\n

e)

————————————————————————————————————————————————————————————————————————————————一一 Cell 2向Cell 1发送重定向信息。不直接发送重定向信息,而是发送Team成员信
息。Cell 2将它所在Team的成员信息发送给Cell 动计算出当前Team Master,与它连接即可。
I,Cell

1根据Team成员信息自



Master向Cell发送Team成员信息格式。有两种消息格式:一种是全量式消息格式, 另一种是增量式消息格式。全量式消息格式,在一个报文里面发送所有组员信息: 增量式消息格式,报文中只包含新增加/减少的成员信息。 全量式消息格式:

发送增量式消息a在发送全量式消息之后,接收方应该将当前所存储的Team成员 重置,然后加入发送方通知的新的Team成员。 成员信息格式:
l[CellID]I[Cell IP】

008A。083、“”B8R、。A2{。o。B‘2。。1:da8:d800:1。o:ecdc:d1 4:f2d7:945f}\n\n 2) Storage Team与WSC General
Ol:da8:d,800:lOO:ecdc:d14



4:f2d7:9日5ej OOFC=20



Maser之间的接/:3。

a)采用TCP协议。WSCMaster侦听固定端口,Cell还是侦听与cell之间通信的端口。

通信模式与Cell之间的通信相同。
b) WSC Master与Team Master通信格式与Team成员之间的通信格式基本相同。WSC

Master的Team ID为0000~000F,Cell lD为0000~000F,该区段ID不可以分配 给Storage Team。
c)

所有Storage Cell向WSC Master发送的消息都认为Storage Cell以所在Team的 Master身份发送。

各种具体消息格式
a)Team Master向WSC Master发送空消息格式。

消息格式:

b)Team Master向WSC Master发送Team成员信息。

消息格式同Storage Team内部通信中的消息格式n。 c)Team Master向WSC Master发送Team配置信息。 消息格式: l[TeamID】[Cellid】\nCNFG\n【配置描述】\n\n
?

FTP配置格式:

FTP。{[Name】2[u3er】:fpswd]0:[port][pathjj}

例如Team中Crawler FTP和Indexer

FTP:

00FA00E3\nCNFG\nFTP2{Crawl-c:cO:102l/crawljIndex=i:10:202l/index】\n\n

d)Team Master向WSC Master发送一般信息和警告、错误信息。

50

第四章分布式存储系统

消息格式

其中,TeamlD和CelllD是发送方,即Team Master的编号,而警告描述和错误描 述都是原来Teem中slor89e Cell向Team Master发送的消息,参看1)一d)。即对原来的 消息做封装,然后再发送到WSC Master。例如在OOFAOOFB上发生磁盘写错误,先发 送到Team Master

00FA00E3上,然后Team

Masler报告给wsc Ma.qer,消息如下:
SPACE
LEFT!

00FA00E3 knERRRkn00FA00FB\nERRR\nDISK-,Ⅳ。

Write

d2sk}

1:竺:!!!!!!!!!
e)WSC Master向Team Ma.,ter发送Master重定向信息。

阿忑五百匠五五忑面而函面五i五百i不面忑i—百ii——~——] l——.,....,....,..............—,.。.,,.............——..。—.......,.—.—,...........,......——...........。。,....,.......,...—————...........———.—,....,..,..————,...一———,.......。..、—,........—..,—........J
示例:
3)WSC Master之间的数据同步接口 wsc Master之间的数据同步包括两方面的内容,一个是存储策略的同步,一个是Storage

消息格式:

Team状态信息的同步。 存储策略的同步仍然使用策略总线接口,wsc备份Master通过策略总线查询获取最新 的存储策略。 Team状态信息的同步复用Heart Beat使用的端口。WSC Master向WSC备份
Team

r——一———————————————]
Master发送信息包括Storage Master发送给WSC Master的信息中的2)一b,c,d)。发送 b,c)两类消息时,采用类似Tean MaYer封装Storage Cell警告、错误信息的方式封装原来Team Master发送给WSC Master的消息。而d)类消息需要先拆封,然后用WSC Master的编号封 装,再发送给WSC各份Maste r。例如: Team成员列表: Team配置信息 Team内部错误信息:
00000000\nERRR\nOOFAOOFB\nERRR\nOISK--{.|NO SP;CS.LEFT Wri£e disk

Storage

errorl、叭n\n\n

5.2.2数据一致性维护接口
数据一致性维护分两种情况:同一个Team中,某个Storage Cell上面的数据有错误或 者不完整:新增加一个Storage Team,分担某个Storage Team上的存储任务,需要将原来
Storage

Team上的数据复制到本地。本文中,这两种情况都采用相同的接口,使用FTP协议,

允许其他Storage Cell下载所有数据。在FTP的根目录,有一个列表文件,列出了所有的数 据包以及它们的相关信息,以便其他Storage Cell可以选择下载。

第四章分布式存储系统

6功能与实现
6.1

WSC Master功能与实现
WSC Master的主要功能有:发布存储策略,维护与Storage Team的心跳,帮助组建

StorageTeam,用户交互接口,WSCMas

相关文章:
分布式搜索引擎的设计与实现.pdf
分布式搜索引擎设计与实现 - 在一个分布各地的网站群组成的大系统中,不设立中心
分布式搜索引擎设计与实现.pdf
分布式搜索引擎设计与实现_互联网_IT/计算机_专业资料。中国科学技术大学 硕士学位论文 分布式搜索引擎设计与实现 姓名:李伟 申请学位级别:硕士 专业:模式识别与智能系...
分布式企业搜索引擎的设计与实现.pdf
分布式企业搜索引擎设计与实现 - 随着互联网的飞速发展,企业内部信息建设的速度
基于Hadoop的垂直搜索引擎的设计与实现_图文.pdf
基于Hadoop的垂直搜索引擎设计与实现 - ADissertationSub
Web服务搜索引擎的设计与实现_图文.pdf
Web服务搜索引擎设计与实现 - 第 28卷第 1期 2011年 1月 计算机
一种基于局域网的分布式搜索引擎设计与实现.doc
一种基于局域网的分布式搜索引擎设计与实现 - 龙源期刊网 http://www.qikan.com.cn 一种基于局域网的分布式搜索引擎设计与实 现 作者:黄宏博 冯温迪 王思远 ...
“天网”高性能分布式检索系统设计与实现_图文.pdf
“天网”高性能分布式检索系统设计与实现 - 本文以“天网”搜索引擎为应用背景,首
分布式视频搜索爬虫系统的设计与实现_图文.pdf
分布式视频搜索爬虫系统的设计与实现 - 大连理工大学 硕士学位论文 分布式视频搜索爬虫系统的设计与实现 姓名:袁理锋 申请学位级别:硕士 专业:软件工程 指导教师:李明...
基于Hadoop的分布式商品搜索引擎设计与实现.pdf
基于Hadoop的分布式商品搜索引擎设计与实现 - 近年来,在电商领域中各种各样
大数据分布式全文检索系统的设计与实现.pdf
大数据分布式全文检索系统的设计与实现 - 论文是基于一种开源企业搜索引擎Solr实现对大数据分布式数据库HBase中数据的检索.论文简单地介绍了分布式存储技术HBase和...
基于分布式的新闻爬取和推荐系统的设计与实现_图文.pdf
基于分布式的新闻爬取和推荐系统的设计与实现_计算机软件及应用_IT/计算机_专业......393.7.1Solr搜索引擎Schema设计………393.7.2新闻检索子系统接口设计……...
基于Lucene的全文搜索引擎的设计与实现_图文.pdf
基于Lucene的全文搜索引擎设计与实现 - 基于Lucene硇茔文搜索引擎硇设计与实坝 TheResearchofLuceneSearch * 何 伟1 薛素静2 孔梦荣3...
分布式存储平台的设计与实现_图文.pdf
科学论坛 q●I 分布式存储平台的设计与实现曹挹芬(湖南大学计算机与通信学院湖南...目前流行的数据管理系统如关系数据库、文件系统、搜索引擎等,各有 不足,尚不能...
主要分布式搜索引擎技术的研究_图文.pdf
框架的基本原 理 ,重点给出了基于 M ap /Reduce技术分布式搜索引擎的实现 。...现 ,同时给出了一种基于 M ap /Reduce 技术的搜索 引擎的具体设计和实现 。...
校园网搜索引擎系统的设计与实现_图文.pdf
校园网搜索引擎系统的设计与实现 - 山东大学 硕士学位论文 校园网搜索引擎系统的设计与实现 姓名:刘琳 申请学位级别:硕士 专业:软件工程 指导教师:马军 20070420 ...
一种分布式搜索引擎设计.pdf
一种分布式搜索引擎设计 - This paper presents a dist
基于JAVA技术搜索引擎的设计与实现.doc
基于JAVA技术搜索引擎设计与实现 - 龙源期刊网 http://www.qikan.com.cn 基于 JAVA 技术搜索引擎设计与实现 作者:刘智勇 来源:《数字技术与应用》2017 ...
基于内容的分布式FTP搜索引擎的设计与实现.pdf
与技术国家实验室(筹)学科交叉基金项目;国家核高基科技重大专 项基金项目(2010ZX0104200200201) 万方数据 许君等:基于内容的分布式FTP搜索引擎设计与实现 431...
一种高性能分布式Web+Crawler的设计与实现_图文.pdf
并提供了现阶段的设计实现方法和分布式无损链接分析算法. 关键词:weh信息搜集器;分布式系统;搜索引擎中图分类号:TP391 文献标识码:A DesignandImplementatiOnOf...
主要分布式搜索引擎技术的研究_图文.pdf
主要分布式搜索引擎技术的研究 - 第 7卷 第 10期 2007年 5月 167