硬件部分。机器不停的提供服务,但是,不能指望他们可以忙一辈子。他们是有寿命的。比如说,损耗的 最快的东西是什么?硬盘。搜索引擎一般采用1.4万转的硬盘。不停的读写对他们的寿命造成了很大的损害。呵呵。一般搜索引擎公司买硬盘都是上百块的 买。当然,硬件7*24小时的服务需要软件的支持。比如说,搜索程序在写的时候就需要考虑到硬件当机的情况。当这台服务机器不能正常工作,监控程序需要及 时报告维护人 员,让他们及时维修;还有重要的一点是,或者是常用的做法是,一份数据,两个到三个相同的镜像。平时是几个镜像同时提供服务,紧急时刻,如果一个镜像不能 联系,那么把流量导入另外的镜像。一般两台机器同时出现错误的概率是很低的。出现错误也要快修,别忘了我们的木桶理论。 有一个特殊的东西,叫做GFS。就是google的分布式文件系统。为什么把它单独的提出来,因为他这两年实在是太火了。搜索引擎需要的数据实在是 太大了,需要大量的硬盘来存储;他对数据处理的要求又很高,需要分布式的并行的处理。Google利用一批刀锋式PC,成功用低成本解决了这个问题。所说 的低成本是每存储1G数据需要的花费的资金,以及能处理如此规 模的用户请求的基础上每处理一个用户请求花费的资金。呵呵。说的有点绕口。从外边看来,就是人家把一堆普通PC机,一堆硬盘变成了一个巨大的机器。而且 各个节点非常非常的便宜。比廉价磁盘阵列都便宜,也好用(当然是软件的支持)。单说一点,这个机器的内存和硬盘是?差不多是各个节点的内存以及相应硬盘的 和。诱人吧。不过,没有钱往里边砸,还是不要做这样的系统。他的论文是公开的,看了之后谁都有点。。。那个蠢蠢欲动。。。呵呵。。。因为,看起来,不是很 难嘛! 不过,你是否发现,论文上所说的东西都是原理,一个错误报告都没 有。文件系统是一个底层的服务,没有千锤百炼谁敢把自己的系统放到一个不稳定的文件系统上运行?与原理相比,我更感兴趣的是,按照这种思路进行软件编写, 他们在运行的过程中碰到的意外问题是什么?怎么解决的。而且,谁又有这么多的财力向redhat公司定制自己的单机文件系统。呵呵。这样想来,这样的一个 程序需要多长的时间去完善?一般的真是耗 不起。不过,现在有个开源的东西,Nutch。有时间需要好好看看。 2. 多个机器之间的合作 多个机器一块去处理这么一大堆数据,相应服务请求,总得有个指挥,以便可以做到此起彼落,默契配合。这就是控 制和监控做的。说起来也是平平无奇,每一个工作的机器都是服务器端,然后总控程序是一个客户端,他告诉服务器端什么时间,应该做什么。这个时候,一组机器 都是统一去做的,你就得将就那个最“无能的”。呵呵。典型的木桶理论的诠释。 不过控制需要注意的是,一组机器作为一个控制单元,如果他们没有都做完你指定动作,你就不能要求他们做下一步 动作。他们是一个完整的整体,就把他们看作一台机器好了,一荣不能俱荣,但是一废俱废。 监控端,关于他的有个名词叫做心跳。你在看其他的资料的时候会看到这个。每一个间隔都向服务器端报 告自己的状态(通过socket)。一般是间隔一秒。呵呵。其他的也没有什么可以说的,本来是一个简单的东西。 3. cache 很多地方都用到了cache技术。依据数据访问的时间局部性 和内容局部性原理,cache的出现极大的提高了数据访问的效率。特别是互联网上的搜索。扎堆的现象更为严重。这就是为什么会有搜索排行榜的原因了。前两 天弄得沸沸扬扬的 白领裸照事件。。。很多人搜的都是相同的关键词。在搜索引擎里边,cache作为独立的一部分出现,它能挡住75%以上的访问?也就是说,能进入到后台需 要检索的访问占很小的一部分。大部分都在cache里边命中了。 Cache的应用当然不止这一点。在 所有你认为有数据需要缓冲访问的地方都可以用。用点内存换来访问的高效率有的时候还是很值得的。不过需要注意cache里边的数据的及时更新的问题,不能 访问过时的数据。也就是数据何时更新的问题。 排序,归并,排重。在这里, 计算机恢复到了本来的面目,排序。你还记得数据结构和算法里边关于排序的介绍吗?我曾经问过一个面试的兄弟。他已经什么都记不起来了。只记住一个冒泡和快 排。我以前听过小乔(中搜架构师)讲解数据结构和算法,让我大开眼界,终于知道什么时候,为什么用这些玩意了。前两天公司面试的时候,一个兄弟做排序,写 了一个冒泡。我问他,能不能快点,他说快排。我说还能不能在快点,他说没有了。呵呵,把常数时间的排序都扔了(不过,也可能真的没有学)。下边这个程序是 前段时间我在看基数排序的时候写的。工作的变更,一直都没有把它派上用场(以后说不定)。现在,这不会涉及到任何公司的机密,可以给大家看。他用了两倍于 快排的内存,但是,我的测试是,可以有将近一倍的排序速度。 平衡二叉树和快排有什么区别 吗?从cpu的利 用率上说。前者对cpu的使用基本上是平的;后者,在一个段时间把cpu用到{bfb},如果同一台机器上还有别人的程序在跑,那么他们都得等你,也就是你 的资源利用不合理,造成了这段时 间,cpu是程序 的瓶颈;从动静方面来说,一个是动态的,可以边建,边检索,另外一个是静态的;从内存利用上说,前者耗费的远大于后者,大约一倍多点。 哈希表,基本上算是最快的查找办法。每一个单元下边挂指 针,解决冲突。而且,还有很多变体,你可以用内存中的一位表示一个桶。呵呵。这是一个非常好的利用内存的办法。数据量的增大,让我们每省一个字节都是非常 有意义。我们称他为内存位图。其实,数组就是一个用下标做的不会有冲突的哈希。 没有一个方法可以包打天下,但是,你要知道他们在什么样 的环境下使用才是更合适的,什么样的环境下是无所谓的。让我现在默写一个快排,我会出错,也得调试一段时间。总是不能xx的记住每一个语句。呵呵。不过, 我认为这不重要。这样的函数库我都已经写好了,或者是有现成的了,我只需要记住何时选用他们就好了。直接调用不就得了。单纯的记住,没有作用。但是,你要 知道他的思想。 Strlen. Strlen函数是用的很多的函数,你可测试过他的时间耗费?每调用一次,程序都需要遍历一次你的字符串,直到碰 到0为止。字符串 短,次数少的时候还看不出来,相反的情况下尽量少用,为什么不能一次调用,保存结果,到处使用那? 你可以注意一下你的那些函 数。关注的不只是功能,而是他们耗费的时间本身(很多时候我们对时间的要求大于对内存的要求)。能不能让你的程序更快点(当然是在程序稳定运行的基础 上),而这种快xx于对算法的选择,不包括语言的换用。你能把所有的C程序都改成汇编?没有必要。投入产出比太低了。不过这种追求也要看环境和用途。不可 太过。过犹不及! 什么东西都是这样,选择最合适,达到要求就好。过犹不及。还有很多需要做的东西,不是仅仅这一个玩意。 如果你说自己精通c,c++,那么如果你不知道,不了解STL,那是不可想象的。以前我也曾犯过这样的错误,认为靠我们自己写的那些类,就不用看STL 了。其实不然。如果你跳槽来到另外一家公司,原来的代码统统原封不动的搬过来?如果,这家公司没有 太多的技术积累,能够直接利用的、效率比较高的就是STL了。当然,没有你为特定的应用编写的效率高;另外,STL之所以能够受到大家的交口称赞,他的设 计思路还的确是有一套的。理解了会非常的有意义! 好了,罗里罗嗦讲了很多,其实也还没有做到点到为止。上 面涉及到的每一个部分,仔细写写估计都可以写一本书,至少也是一章。只是希望给对这个行业、开发不熟悉的人介绍一下相应的东西。没有任何的东西是可以速成 的,经验只会来自于对实际开发的例子的体会,介绍的内容只会让你有一个印象。你如果确实想进入这个行业的话,把涉及到的各个部分起码应该大体看看吧。只有 大公司才有耐心慢慢的培养你,等你起来,很多小点的公司都是需要较短时间内能够接手工作的(我进中搜的一个星期后,开始负责外链处理程序,是同时进入公司 的人中接手最快的,我一直都是很骄傲这个事情,虽然在进中搜之前没有做过搜索引擎开发)。我出来找工作的时候,工作很好找,原因在于我的经验。公司是花钱 买断我们的经验。呵呵。不过,关于基础知识部分,没有什么好说的。 做的越多,你就会越来越发现其中包含的那个叫做“数学的美”。Googl的黑板报上就出了这么一系列文章叫做“数学的美”。我的大学数学学的不好,基本没 有听课,有时间得 补补。呵呵。其他的各个搜索引擎多半都会做一个他自己的博客,发布一下自己的消息,散布一些自己的论文和研究成果,有时间得看看。 每次写关于一点关于搜索引擎的东西的时候,都会提起中搜 (爱之深,恨之切,虽然我已经离开),人总是需要感恩的。能从在中搜锻炼两年,与很多技术人员相比,我是非常幸运的。在这里,我发现了和以前做应用{jd1}不 同的技术世界,我在这里见识了大规模数据的处理,学会了计算自己的硬、软、人资源的需求,学会了处理多个人之间的接口,和很多人通力合作:你需要相信你的 队友,相信他们能和你一样的努力,相信他们可以和你做的同样的好,如果你干的不错,你需要努力的多做一点,就如同篮球队里边的协防,是的,你的队友有时需 要你的协防,我们都多为他人、多为项目想一点,接口问题、配合问题将不成为问题。一个项目的完成、胜利才是我们想要的。。。。。。。。。我们同时又是不幸 的,我们努力过,非常非常的努力过,却没有看到中搜如百度般的成功。向现在仍能坚守在中搜的人致敬! 关于涉及到的内容,如果以后 时间允许,我会各个多总结一点。 不过,写的越具体详细,离不能说的东西 也就越近(不过,随着这个行业规模的扩大,不能说的越来越少,呵呵,这是我们大家都希望看到的)。我上边所提到的大多是我的思想和思考,总结,这样省下很 多的麻烦!好在很多的基础知识都是相同的,从那些方面入手,不会给人造成误解。 pre: |