当搜索引擎访问一个网站时，它首先会检查该网站的根域下是否有一个叫做robots.txt的纯文本文件。Robots.txt文件用于限定搜索引擎对其网站的访问范围，即告诉搜索引擎网站中哪些文件是允许它进行检索(下载)的。这就是大家在网络上常看到的“拒绝Robots访问标准”(Robots Exclusion Standard)。下面我们简称RES。 Robots.txt文件的格式：Robots.txt文件的格式比较特殊，它由记录组成。这些记录通过空行分开。其中每条记录均由两个域组成： 　　 1) 一个User-Agent(用户代理)字符串行； 　　 2) 若干Disallow字符串行。 　　 记录格式为：<Field> “:” <value> 　　 下面我们分别对这两个域做进一步说明。 User-agent(用户代理)： 　　 User-agent行(用户代理行) 用于指定搜索引擎robot的名字，以Google的检索程序Googlebot为例，有：User-agent: Googlebot 　　 一个robots.txt中至少要有一条User-agent记录。如果有多条User-agent记录，则说明有多个robot会受到RES标准的限制。当然了，如果要指定所有的robot，只需用一个通配符”*”就搞定了，即：User-agent: * Disallow(拒绝访问声明)： 　
　在Robots.txt文件中，每条记录的第二个域是Disallow:指令行。这些Disallow行声明了该网站中不希望被访问的文件和(或)目
录。例如”Disallow:
email.htm”对文件的访问进行了声明，禁止Spiders下载网站上的email.htm文件。而”Disallow:
/cgi-bin/”则对cgi-bin目录的访问进行了声明，拒绝Spiders进入该目录及其子目录。Disallow声明行还具有通配符功能。例如
上例中”Disallow:
/cgi-bin/”声明了拒绝搜索引擎对cgi-bin目录及其子目录的访问，而”Disallow:/bob”则拒绝搜索引擎对/bob.html和
/bob/indes.html的访问(即无论是名为bob的文件还是名为bob的目录下的文件都不允许搜索引擎访问)。Disallow记录如果留空，
则说明该网站的所有部分都向搜索引擎开放。 空格 & 注释 　　 在robots.txt文件中，凡以”#”开头的行，均被视为注解内容，这和UNIX中的惯例是一样的。但大家需要注意两个问题： 　
　 1)
RES标准允许将注解内容放在指示行的末尾，但这种格式并不是所有的Spiders都能够支持。譬如，并不是所有的Spiders都能够正确理解
“Disallow: bob
#comment”这样一条指令。有的Spiders就会误解为Disallow的是”bob#comment”。最好的办法是使注解自成一行。 　　 2) RES标准允许在一个指令行的开头存在空格，象”Disallow: bob #comment”，但我们也并不建议大家这么做。 Robots.txt文件的创建： 　
　需要注意的是，应当在UNIX命令行终端模式下创建Robots.txt纯文本文件。好的文本编辑器一般都能够提供UNIX模式功能，或者你的FTP客
户端软件也“应该”能够替你转换过来。如果你试图用一个没有提供文本编辑模式的HTML编辑器来生成你的robots.txt纯文本文件，那你可就是瞎子
打蚊子——白费力气了。 对RES标准的扩展： 　　 尽管已经提出了一些扩展标准，如Allow行或Robot版本控制(例如应该忽略大小写和版本号)，但尚未得到RES工作组的正式批准认可。 附录I. Robots.txt用法举例： 　　 使用通配符”*”，可设置对所有robot的访问权限。 　　 User-agent: * 　　 Disallow: 　　 [...]

Apache系统中的.htaccess文件(或者”分布式配置文件”提供了针对目录改变配置的方法， 即，在一个特定的文档目录中放置一个包含一个或多个指令的文件， 以作用于此目录及其所有子目录。作为用户，所能使用的命令受到限制。管理员可以通过Apache的AllowOverride指令来设置。
子目录中的指令会覆盖更高级目录或者主服务器配置文件中的指令。
.htaccess必须以ASCII模式上传，最好将其权限设置为644。
错误文档的定位
常用的客户端请求错误返回代码：
401 Authorization Required
403 Forbidden
404 Not Found
405 Method Not Allowed
408 Request Timed Out
411 Content Length Required
412 Precondition Failed
413 Request Entity Too Long
414 Request URI Too Long
415 Unsupported Media Type
常见的服务器错误返回代码：
500 Internal Server Error
用户可以利用.htaccess指定自己事先制作好的错误提醒页面。一般情况下，人们可以专门设立一个目录，例如errors放置这些页面。然后再.htaccess中，加入如下的指令：
ErrorDocument 404 /errors/notfound.html
ErrorDocument 500 /errors/internalerror.html
一条指令一行。上述第一条指令的意思是对于404，也就是没有找到所需要的文档的时候得显示页面为/errors目录下的notfound.html页面。不难看出语法格式为：
ErrorDocument 错误代码 /目录名/文件名.扩展名
如果所需要提示的信息很少的话，不必专门制作页面，直接在指令中使用HTML号了，例如下面这个例子：
ErrorDocument 401 “你没有权限访问该页面，请放弃！”
文档访问的密码保护
要利用.htaccess对某个目录下的文档设定访问用户和对应的密码，首先要做的是生成一个.htpasswd的文本文档，例如：
zheng:y4E7Ep8e7EYV
这里密码经过加密，用户可以自己找些工具将密码加密成.htaccess支持的编码。该文档最好不要放在www目录下，建议放在www根目录文档之外，这样更为安全些。
有了授权用户文档，可以在.htaccess中加入如下指令了：
AuthUserFile .htpasswd的服务器目录
AuthGroupFile /dev/null （需要授权访问的目录）
AuthName EnterPassword
AuthType Basic （授权类型）
require user wsabstract （允许访问的用户，如果希望表中所有用户都允许，可以使用 require valid-user）
注，括号部分为学习时候自己添加的注释
拒绝来自某个IP的访问
如果我不想某个政府部门访问到我的站点的内容，那可以通过.htaccess中加入该部门的IP而将它们拒绝在外。
例如：
order allow,deny
deny from 210.10.56.32
deny [...]

搜索引擎公司经常说核心竞争是技术，实际上这个技术是宽泛的概念，应该包括了对用户的理解、对产品的理解、技术水平。Google：“完美的搜索引擎需要做到确解用户之意，切返用户之需”。搜索做得好不好不仅仅是算法的事情，更重要的是对用户意图的理解，所以搜索引擎的竞争有两个点：1.破解用户之意 2.切返用户之需。破解用户之需是产品部门的工作。从产品经理的角度来看，对一个产品有三个工作1.需求分析 2.产品决策 3.产品的跟踪、强化。(前两个工作做好了，才能把后面的工作做好)需求分析：就是针对用户的意图，需求做分析，确解用户之意。产品决策：根据需求分析，结合技术可行性对产品做设计以最恰当的方式满足用户的需求。技术实现：根据产品需求文档，完成产品的研发。

产品管理竞争：

在搜索产品理念上做得最好的公司就是google（本文均指美国google）和百度。Google要比百度更理解搜索，百度做为追随者只需要去理解google，在此基础上再建立本地化和社区化的差异化壁垒。

百度：百度的产品部门对百度的成功起到了非常大的作用。策略方面：根据市场情况和用户需求03年前是跟随策略，大量的获取新增互联网用户和新增的搜索用户。04年后社区化策略粘住获得用户，强化产品获取早期的搜索引擎用户。执行方面：百度的主要产品设计都非常到位，抓住了用户最大的需求、产品的核心竞争力、同竞争对手产品的差异化、建立良好机制来运作产品，建立内部的产品管理流程（发现问题解决问题的流程）。内部沟通：百度产品部门不仅仅把对搜索的理解灌输到每个产品经理，还将产品意识、理念影响到了高层、项目经理、工程师、市场人员身上，在产品的设计、研发、运营整个流程上时时刻刻都具有对用户需求的理解和搜索的理念。中搜：最失败的案例。好像没有专门产品部门，很多产品都是是领导拍脑袋做产品决策。关于中搜只能用“可惜”两个字了。雅虎中国：基本上没有产品决策权，申请做一antispam都要几个月，中国雅虎只是维护yapache，程序离开yapache就都不能用了。Yisou在王航的带领下把mp3做得的确不错，可惜内部的机制决定了雅虎中国不可能有任何前景。据说雅虎在等待百度不能跨越100亿数据量索引瓶颈，实在是……谷歌：具体不清楚。但是从这一年多的表现来看和雅虎中国没有太大区别。搜狗：在叫嚷100亿数据量，唉…；对搜索的理解还停留在03年。奇虎：以前不行，近期明显感觉到产品管理能力在增强。

百
度在产品管理领域已经远远领先于竞争对手，百度拥有最强大的百度知道，可以在“发现问题”方面有各种专业用户基础、有庞大的用户群时时刻刻在监测他们的产
品的每一个细节可以最快速有效的在细节方面“发现问题”、有强大的产品部门集中了几乎中国对搜索理解最深的人才、流畅的链式管理机制可以用最快的方式解决
问题强化产品……只要百度持续把这些优势发挥，那么在这个方面无以伦比，不存在一个级别的竞争对手。

技术之争：

网页搜索技术上现在进入了一个技术的相对瓶颈期，很难在理论上和技术上有大的突破（当然也有可能在任何一天有某个人提出一种新的理论颠覆了“超链接、PR”）。所以在网页搜索的技术上最关键的是如何能够针对发现的问题去解决问题。在“网页搜索引擎的发展方向http://www.fullsearcher.com/n2006227185235735.asp”一文中有些个人的看法。其中最重要的一个方面是在自然语言处理方面，这是很多工作的基础。

网
页搜索引擎产品的一个方向就是垂直化针对不同的词汇，体现不同的维度，返回不同的结果。如在百度搜索“北京
天气”会体现一个提示性的链接、搜索软件你会发现百度做了专门的优化。在google搜索股票代码、手机号码等会有不同的提示性链接，有些词汇是有新闻链
接的有些是没有的。随着宽带的普及，这些垂直信息拼接会被网页搜引擎公司应用到网页搜索产品中，很明显这主要又是产品部门和技术部门协同才能很好完成的工
作。网页搜索会发展到越来越细节。
网页搜索引擎的存在有他存在的土壤，土壤环境是怎么样的呢？1.海量的数据，互联网上有海量的数据，并且这些数据在快速增长、不断更新2.分散的数据，这些数据存在于成千上万个网站中3.多样化的数据4.用户多样化的数据搜索需求5.用户对搜索数据的实时性要求不是非常强6.用户对这些数据有整合使用的需求，并且这种需求量很大7.能够很好的对整合来的数据进行处理，能够完整的满足用户的这种需求，提供完整的信息检索体验
垂直搜索引擎存在的土壤：1.网页搜索引擎无法对某类数据进行深度加工，提供更多的细化的服务2.网页的数据实在是太多样化了（数据种类、数据类型等），不利于满足用户细分的服务3.用户有对互联网数据进行深度采集，数据的深度加工提供更细化的服务的需求，这种需求量非常巨大4.用户对某类信息的实时性的要求比较高5.针对某类信息提供更简洁、更快速，更可依赖性更强的服务6.行业性优化
垂直搜索存在的必备条件：1.海量的数据，所选择的垂直搜索的数据必须是海量的数据，数据量和增长速度、增长量都比较大。符合搜索引擎的基本条件2.分散的数据，这种数据必须要分散在很多个不同网站。不能是仅存在于几个网站。如果仅存在于几个网站不如做元搜索了（如果信息集中在几个网站，用户可以直接去使用）3.用户对这些数据的实时性有一定要求，但是又不能是对实时性要求极高（显然，春运期间的二手火车票信息就不适合做垂直搜索，因为等采集处理完毕，那票说不定已经卖掉了。拍卖的价格信息不适合做垂直搜索，有可能还没有采集处理完毕，价格已经变化了。）4.用户对这类数据的需求量是很大的，而且需要长期使用。（搜索是需要学习、长期使用才能很好的驾驭的一种应用）5.技术上能够很好的完成信息的整合、深度加工，并且加工后能够完整的满足用户对这类数据的搜索需求，提供完整的应用体验。6.这种信息的深度采集、深度加工是网页搜索引擎完全不可以替代的。
垂直搜索选型的步骤：1.选定适合您的，您熟悉的，有一定的资源背景的几个垂直搜索的被选方案。2.查看google或百度（其它搜索引擎不行）检索关键词数据。最好能搞到连续一段时间的全部词汇（按照检索频率排序），当然这几乎不可能，进行详细的分析、统计、挖掘。搞不到只要看风云榜和百度指数了，这估计就有很大偏差了。对这些用户需求数据库进行深度分析找出用户到底要什么、互联网上缺什么。（第1步和第2步交替进行）3.分析相关行业的网站，评估用户需求、数据情况、横向竞争、纵向竞争、潜在竞争情况和可能遇到的其它问题。4.如何满足用户的需求？如何保持产品和门户网站、搜索门户等的差异化和挖掘出用户潜在的最大的需求？5.评估技术上的可行性，能否实现完整用户体验。6.如何保证产品的领先性（资源、效果、市场、技术、销售……）7.产品的市场推广方式(这点非常非常重要，如何在竞争对手反应过来之前低成本的快速抵达有效用户群是成败的关键)8.盈利模式；收入模型、成本模型第一步完成到什么程度，达到什么目标。需要多少成本第二步完成到什么程度，是否可以收支平衡或者获得投资…………9.产品的不足和先天的缺陷如何克服弥补。产品的生命周期的每一步可能出现的紧急问题如何应对。10.不要认为自己很聪明，这世界上聪明人太多了，你能想到的肯定有n个人已经想到了。 关键在于您能不能充分利用自己的资源，做好前期的调查后专注的执行。11.务必要找百度和google这类搜索引擎不愿意花大功夫去做（市场暂时不够大）、或者不可能能做的应用（受制约、有更重要的事情要做），不要把你的模式和意图暴露得太早，这个市场的竞争实在是太激烈了，中国人也都太聪明了。 务必要找和门户网站、网页搜索引擎有很大差异化，并且用户有持续的很大的需求的。理由很简单：搜索是需要持续使用才能熟练的一种产品、从门户和网页搜索引擎到您的垂直引擎的门槛很高（比多点击10次的门槛还高很多）。

网页搜索引擎的存在有他存在的土壤，土壤环境是怎么样的呢？1.海量的数据，互联网上有海量的数据，并且这些数据在快速增长、不断更新2.分散的数据，这些数据存在于成千上万个网站中3.多样化的数据4.用户多样化的数据搜索需求5.用户对搜索数据的实时性要求不是非常强6.用户对这些数据有整合使用的需求，并且这种需求量很大7.能够很好的对整合来的数据进行处理，能够完整的满足用户的这种需求，提供完整的信息检索体验
垂直搜索引擎存在的土壤：1.网页搜索引擎无法对某类数据进行深度加工，提供更多的细化的服务2.网页的数据实在是太多样化了（数据种类、数据类型等），不利于满足用户细分的服务3.用户有对互联网数据进行深度采集，数据的深度加工提供更细化的服务的需求，这种需求量非常巨大4.用户对某类信息的实时性的要求比较高5.针对某类信息提供更简洁、更快速，更可依赖性更强的服务6.行业性优化
垂直搜索存在的必备条件：1.海量的数据，所选择的垂直搜索的数据必须是海量的数据，数据量和增长速度、增长量都比较大。符合搜索引擎的基本条件2.分散的数据，这种数据必须要分散在很多个不同网站。不能是仅存在于几个网站。如果仅存在于几个网站不如做元搜索了（如果信息集中在几个网站，用户可以直接去使用）3.用户对这些数据的实时性有一定要求，但是又不能是对实时性要求极高（显然，春运期间的二手火车票信息就不适合做垂直搜索，因为等采集处理完毕，那票说不定已经卖掉了。拍卖的价格信息不适合做垂直搜索，有可能还没有采集处理完毕，价格已经变化了。）4.用户对这类数据的需求量是很大的，而且需要长期使用。（搜索是需要学习、长期使用才能很好的驾驭的一种应用）5.技术上能够很好的完成信息的整合、深度加工，并且加工后能够完整的满足用户对这类数据的搜索需求，提供完整的应用体验。6.这种信息的深度采集、深度加工是网页搜索引擎完全不可以替代的。
垂直搜索选型的步骤：1.选定适合您的，您熟悉的，有一定的资源背景的几个垂直搜索的被选方案。2.查看google或百度（其它搜索引擎不行）检索关键词数据。最好能搞到连续一段时间的全部词汇（按照检索频率排序），当然这几乎不可能，进行详细的分析、统计、挖掘。搞不到只要看风云榜和百度指数了，这估计就有很大偏差了。对这些用户需求数据库进行深度分析找出用户到底要什么、互联网上缺什么。（第1步和第2步交替进行）3.分析相关行业的网站，评估用户需求、数据情况、横向竞争、纵向竞争、潜在竞争情况和可能遇到的其它问题。4.如何满足用户的需求？如何保持产品和门户网站、搜索门户等的差异化和挖掘出用户潜在的最大的需求？5.评估技术上的可行性，能否实现完整用户体验。6.如何保证产品的领先性（资源、效果、市场、技术、销售……）7.产品的市场推广方式(这点非常非常重要，如何在竞争对手反应过来之前低成本的快速抵达有效用户群是成败的关键)8.盈利模式；收入模型、成本模型第一步完成到什么程度，达到什么目标。需要多少成本第二步完成到什么程度，是否可以收支平衡或者获得投资…………9.产品的不足和先天的缺陷如何克服弥补。产品的生命周期的每一步可能出现的紧急问题如何应对。10.不要认为自己很聪明，这世界上聪明人太多了，你能想到的肯定有n个人已经想到了。 关键在于您能不能充分利用自己的资源，做好前期的调查后专注的执行。11.务必要找百度和google这类搜索引擎不愿意花大功夫去做（市场暂时不够大）、或者不可能能做的应用（受制约、有更重要的事情要做），不要把你的模式和意图暴露得太早，这个市场的竞争实在是太激烈了，中国人也都太聪明了。 务必要找和门户网站、网页搜索引擎有很大差异化，并且用户有持续的很大的需求的。理由很简单：搜索是需要持续使用才能熟练的一种产品、从门户和网页搜索引擎到您的垂直引擎的门槛很高（比多点击10次的门槛还高很多）。

网络蜘蛛现在开源的已经有好几个了，Larbin，Nutch，Heritrix都各有用户之地，要做一个自己的爬虫要解决好多个问题，比如调度算法、更新策略、分布式存储等，我们来一一看一下。
一个爬虫要做的事主要有以下这些

从一个网页入口，分析链接，一层一层的遍历，或者从一组网页入口，或者从一个rss源列表开始爬rss；
获取每个页面的源码保存在磁盘或者数据库里；
遍历抓下来的网页进行处理，比如提取正文，消重等；
根据用途把处理后的文本进行索引、分类、聚类等操作。

以上是个人理解哦，呵呵。这些过程中，大约有如下问题
如何获取网页源或者RSS源？如
果是一般的爬虫的话，就是给几个入口页面，然后顺着超链接以遍历图的算法一个页面一个页面的爬，这种情况网页源很少，可以选择从hao123等网址大全的
网站为入口开始爬。如果做垂直搜索的话就人工去收集一些这个行业的网站，形成一个列表，从这个列表开始爬。如果是爬RSS的话，需要先收集RSS源，现在
大的门户的新闻频道和主流的博客系统都有rss的功能，可以先爬一遍网站，找出rss的链接，要获取每个链接的内容，分析是否是rss格式，如果是就把这
个链接保存到rss源数据库里，以后就专门爬这个rss源的rss。还有一种就是人工来整理，一般blog的rss都是有规律的，主域名跟一个用户名后面
再跟上一个rss的固定页面，比如http://www.abc.com/user1/rss.xml，这样就弄一个用户字典，拼接rss地址，然后用程
序去探测是否有这个页面来整理出每个网站的rss源。整理出rss源后再人工设置rss源的权重及刷新时间间隔等。
如果源页面很多，如何用多线程去有效的调度处理，而不会互相等待或者重复处理？如
果现在有500万个页面要去爬，肯定要用多线程或者分布式多进程去处理了。可以把页面进行水平分割，每个线程处理一段儿，这样每个线程之间不需要同步，各
自处理各自的就行了。比如给这500W个页面分配一个自增ID,2个线程的话就让第一个线程去爬1，3，5的网页，第二个线程去爬2，4，6的网页，这样
做多个线程间基本上能均衡，而且不会相互等待，而且不会重复处理，也不会拉掉网页。每个线程一次取出1w个页面，并记录最高的源页面ID号，处理完这一批
后再从数据库里提取大于这个源页面ID号的下1W个页面，直到抓取完本线程要处理的所有页面。1w这个值根据机器的内存可做适当的调整。为了防止抓了半截
儿死机，所以要支持断点续抓，要为每个线程的处理进度保存状态，每取一批网页都要记录本线程最大的网页ID，记录到数据库里，进程重启后可以读取这个
ID，接着抓后面的页面。
如何尽量的利用CPU，尽量的不让线程处于等待、休眠、阻塞等空闲状态？而且要尽量用少的线程以减少上下文切换。爬
虫有两个地方需要IO操作，抓网页的时候需要通过网卡访问网络，抓到网页后要把内容写到磁盘或者数据库里。所以这两个部分要用异步IO操作，这样可以不用
线程阻塞在那里等待网页抓过来或者写完磁盘文件，网卡和硬盘都支持内存直接读取，大量的IO操作会在硬件驱动的队列里排队，而不消耗任何CPU。.net
的异步操作使用了线程池，不用自己频繁的创建和销毁线程，减少了开销，所以线程模型不用考虑，IO模型也不用考虑，.net的异步IO操作直接使用了完成
端口，很高效了，内存模型也不需要考虑，整个抓取过程各线程不需要访问共享资源，除了数据库里的源页面，各管各的，而且也是每个线程分段处理，可以实现无
锁编程。
如何不采集重复的网页？去重可以使用king总监的布隆过滤器，
每个线程使用一个bitarray，里面保存本批源页面上次抓取的页面的哈希值情况，抓取下来的源页面分析链接后，去这个bitarray里判断以前有没
有抓过这个页面，没有的话就抓下来，抓过的话就不管了。假设一个源页面有30个链接把，一批10W个源页面，300w个链接的bitarray应该也不会
占太大内存。所以有个五六个线程同时处理也是没问题的。
抓下来的页面更快的保存？保存到分布式文件系统还是保存在数据库里？如
果保存到磁盘，可以每个域名创建一个文件夹，凡是这个网站的页面都放到这个文件夹下，只要文件名不一样，就不会出现冲突。如果把页面保存到磁盘，数据库有
自己的一套锁管理机制，直接用bulk
copy放数据库就行了。一般频繁的写磁盘可能会引起CPU过高，而频繁的写数据库CPU还好一些。而且sqlserver2008支持filestream类型的字段，在保存大文本字段的时候有很好的性能，并且还能使用数据库的API来访问。所以我觉得如果没有GFS那样高效成熟的分布式文件系统的话还不如存sqlserver里面呢。
如何有效的根据网页的更新频率来调整爬虫的采集时间间隔？做爬虫要了解一些HTTP协议，如果要抓的网页支持Last-Modified或者ETag头，我们可以先发个head请求来试探这个页面有没有变化来决定是否要重新抓取，但是好多网站根本就不支持这个东西，所以让爬虫也很费劲，让自己的网站也会损失更多的性能。这样我们就要自己去标注每个源页面的更新时间间隔及权重，再根据这两个值去用一定的算法制定蜘蛛的更新策略。
采集下来的数据做什么用？可以抓取一个行业的网站，在本地进行分词和索引，做成垂直搜索引擎。可以用一定的训练算法对抓取下来的页面进行自动分类，做成新闻门户。也可以用死小风行的文本相似度算法处理后进行文本聚类处理。
如何不影响对方网站的性能？现在好多网站都被爬虫爬怕了，因为有些蜘蛛弄住一个网站可劲儿的爬，爬的人家网站的正常用户都无法访问了。所以好多站长想了好多办法来对付爬虫，所以我们写爬虫也要遵循机器人协议，控制单位时间内对一个网站的访问量。

碰到的问题列表：

内容的编码问题是一个问题，需要很多功夫进行调整
HTTP访问协议的问题，譬如路径重定向，以及各种错误
robots协议支持的问题
垃圾信息处理的问题（譬如feedburner出来的RSS可能包含广告内容）
运行效率问题（用Java+JDBC在并发不多的情况下已经出现OutOfMemoryError了）
一些知名blog的历史文章尚未反向收集
在日期时间格式标准方面，有很多非标准的格式需要处理
未能很好地记录不同blog之间的引用关系
如何有效地控制RSS feed源头是一个问题
更新频率是写死的一天，没有频率计算调度
尚未提供添加新的RSS feed的界面接口
尚未实现全文检索，也没有对tag支持