zoukankan      html  css  js  c++  java
  • 豆瓣技术架构调研

    关键字包括:nginx,lighttpd,quixote,Memcached,mogile FS,Mako,Gentoo Linux,Xapian,spread
    ps:窃以为第一段关于语言的采访,相当[csdn]化 
    你要是愿意,就买一枝三块钱的玫瑰,送给我吧,这城市也是怪让人伤心的,我想死心塌地的爱上你”
       这是一个叫钟童茜的歌手的歌,我在豆瓣网站发现有人评论,才知道了这首有些凄凉的歌曲。你几乎不可能从百度的最流行的mp3的列表中找到它,因为它不是那么有名,也许是这个原因,引发了我采访豆瓣的愿望。接受我采访的是,豆瓣网站的技术总监洪强宁先生和产品经理张贝宁女士。
    本刊记者:好,现在开始,豆瓣是一个非常著名的Web2.0网站,你们的开发语言选择的是Python,我想问的是,为什么选择python
    洪强宁:我们选择Python的理由是它是动态语言,具有动态语言的优点,比如开发特别迅速。我们做的是一个Web2.0的网站,这种网站的特点就是always beta,用户的需求在随时发生变化,我们也不断发现新的价值。所以网站的结构和程序会不断变化,如果用Java做,你的开发量比较大,你就难以做出迅速地改变。Python的特点就是开发迅速,你可以在一两个小时,就做出一个功能。或者说已??上线了,用户反映需要某一功能,也可以比较快地做出来。
    本刊记者:这就是TDD,敏捷开发的思路,和传统的方式有些不同。但是会有另一方面的问题,Python的程序员好找吗?在国内会Python的要比会Java程序员少的多。
    洪强宁:对,确实是。在中国用Python的人确实不多,也给我们寻找开发任何人员带来困难。不过从另一方面说,也有好处,因为没有一个学校去教Python,会Python的人都是自己学的,也就是说他知道自己需要什么技术,而且能够通过自学掌握它,包括Python的资料中文比较少,需要学习者接触第一手资料,这都使得Python程序员的平均水平,要比使用其他热门语言的平均水平要高。另一方面Python也越来越流行,在国外比较流行的动态语言有Perl,和Python,现在Python已经超过了Perl。
    本刊记者:不过,在Web开发这方面有许多选择,比如,Java,.NET,和PHP,在这个格局里Python还是比较弱势。
    洪强宁:对,当然,它是新兴语言。在未来,我相信,至少在在Web2.0网站开发方面,它会有自己的一个位置。
    本刊记者:还有问一个问题,Python与Perl比较怎么样?因为Python的面向对象的特性好一些,代码看起来更容易理解一些吧,我以前是用 Perl写程序的,觉得Perl的程序代码看起来比较乱。
    洪强宁:对,Perl 是write once风格的,一个人写完了,过一段时间,可能自己都不能看懂,它确实很强大,但比较适合当作个人工具使用,不太适合团队的开发。Python的哲学是解决问题的最好方式只有一种,这样同样的功能,每个人写出来的程序样子应该差不太多,比较易于理解,更适合团队开发。
    本刊记者:还有一个问题,,有一种说法,认为Python比较慢,在性能方面会不会有问题?
    洪强宁:这个问题可以分两个方面说,首先,说Python慢,这是和编译语言比,比如与C,C++,Java比,在动态语言中,它并不慢,它比Ruby要快,它和Perl性能相当。如果选择动态语言的话,Python并不是很慢。另一方面,如果做网站开发,语言的不是速度的瓶颈,比如我把我们现在用Python写的程序全部用C写,程序当然会快一点,但是改变不是很大。Web网站一般会有很多对IO的操作,比如对数据库的访问,对硬盘的访问响应用户的请求,80%,90%你的时间都花在IO上,语言的速度,相对而言,不是那么重要。也可以这样说,网站的性能主要取决于架构设计的是否合理。因为网站需要响应大量的并发的请求,如果你的设计的不好,即使你用C写的,也可能无法应付。所以更多的考虑是在架构设计上,要使架构体系不会产生速度瓶颈。
    本刊记者:那您能简要地介绍一下豆瓣的架构吗?
    洪强宁:关于豆瓣的系统架构图,首先我们在Web server上做个划分,把网站内容分为动态内容和静态内容。在豆瓣上所有的html都是动态内容,图片都是静态内容。分成两个Web 服务可以做不同的调优。 对动态内容,我们用的是nginx和lighttpd的混合,nginx做负载的平衡,lighttpd通过 SCGi 与application server相连,application server是基于 quixote这个框架写的。
    application server拿到用户的请求,分析用户的url,并且利用外部的资源,比如数据库,组合成一个html,返回。从数据库存取会比较慢,数据库有大量的IO,我们使用cache,我们使用的是Memcached,这是一个分布式的内存的cache,比如你可以用很多机器,每个机器有两个G的内存,我们自己开发了client端来使用它,另外如果用户有搜索请求,我们会用搜索引擎。Xapian是一个C++写的开源的搜索引擎,我们通过Web service去访问它。其他,我们还提供了另外的Web service接口响应用户的请求,比如要访问某个文件。spread是我们最近加了一部分,用户有的请求可以采用这样的异步服务。
    数据库是这样的,两个MySQL做成一对,一个master ,一个 slave,根据应用划分,使得load不会太高。这个图上??的是两对,实际上有三对。还有一个slave,一方面作为备份,一方面用作数据挖掘,因为不能对线上的数据做直接操作。
    对于静态部分,我们也是用nginx,你注意到豆瓣现在有日记的贴图功能系统,用户可能上传很多图片,我们采用的方案是用了mogile FS ,这是一个分布式的文件系统,同时可以做备份,保持高可用性,可以提高很大的IO。
    关于application server,它都是用Python写的。我们是用的MVC方式,Controller我们用的是quixote ,它接受用户的请求,根据这个URL去找到Model的某个具体的函数来执行,它是一个dispatcher,当中会判断用户的权限等。然后再传给View,View根据模版进行渲染,形成网页。View的模版,我们以前是用的是PTL,PTL很高效,最近引用了mako,这是一个比较现代的开源的模版,用它写出的代码比较好维护,比PTL好维护一些.。同时,在使用mako的同时,我们的工程师做了很多加速的工作,现在mako的代码有很多是豆瓣的人写的。
    你如果注意过Python的Web开发框架的话,你会发现Python的有三个比较著名的框架,Django,Pylons,TurboGears,Pylons默认的模版就是Mako。
    下面的就是Model,业务模块,核心是类是User,因为Web2.0是以人为本,我们肯定会有一个User。只有人也做不了事情,还要有物。豆瓣的物,就是Subject,比如书,比如评论,比如小组等。
    与数据库进行链接,我们一个很轻量级的与数据库进行链接,这也是一个开源项目,SQL Farm Manager。这个Web service,豆瓣中有很多用的都是Web service。
    本刊记者:好,还想问您一个问题,Web2.0会不会也在架构设计中也有所体现呢 ?
    洪强宁: Web2.0用户的反复的操作非常多,你需要一个非常流畅的体现。这需要一些技术来实现,比如Ajax;豆瓣花了很多钱很多精力,来提高性能,比如买好的机器,使用Gentoo linux,为什么使用Gentoo Linux,因为它方便调优。还有,大量的使用cache。在数据库调优方面,我们也花了很大的精力。
    另一方面,Web 2,0是用户提供数据的,用户有很多写操作。这样很多1.0优化方法在2.0中行不通。豆瓣在数据库上用的是分库的方式。除此之外我们还尝试了一些其他的方法。
    本刊记者:我现在想问张贝宁一个问题,您能否谈一下Web2.0社区网站和传统的社区网站的区别?比如天涯论坛,和豆瓣的区别。
    张贝宁:先说一下Web 2.0 的概念,传统网站,用户到这些网站,只是看信息,这些信息是怎么来的呢,比如像Google,它是抓来的,或者像新浪这样的门户网站,是用户给你编好的。你到这样的网站,只是获取信息,你不能创造信息,也不能决定它放的位置。按照业界的理解,Web 2.0相对于Web 1.0,它是以用户为中心的,或者说是以用户创造内容为主,并且可以决定展现方式。你刚才说的传统的社区,在某种程度上,也可以说是2.0的,因为它也由用户提供内容。不过早期的BBS,网站以内容作分类,比如体育,军事,文学等。用户不能形成自己的分类。在豆瓣,用户可以对任何一个话题进行讨论,这完全是用户自主的。这还只是关系到豆瓣的小组的功能,如果拿天涯论坛和豆瓣做比较的话,豆瓣与天涯这样的BBS不同还在于,它首先有一个物的概念,比如书,音乐,和电影。
    本刊记者:我也发现了这点。这样的组织方式,给人的感觉会非常不同。比如我们要查找对余华的小说《活着》的评论,在豆瓣就比较容易找到认真,有质量的评论。而在传统的BBS上,你只能用查找的方式,搜索“活着”这个词,找出的东西,也可能还不是谈论《活着》这本小说的,而只是其中的文本包含了“活着”这个词,而且有很多无意义的吵架帖。豆瓣的组织方式,让人感觉很严肃,雅气。不过,我也发现了一个或许有些不便的地方,比如,我要在讨论德里达的小组回帖,在一般的BBS可以匿名,或具有一个ID就行了,但在豆瓣,我要首先参加德里达这个小组。
    张贝宁:对,是这样的。豆瓣更关心的是人群,就是对同一话题和事物有兴趣的人群,而不是帖子,这与传统的BBS确实有一些区别。
    本刊记者:好,就到这里。谢谢你们两位能够接受我的采访,分享你们的经验与思想。

    ----------------------------------------------------------------

    这次的 QCon 会议,《豆瓣网技术架构的发展历程》这个议题差不多是最受关注的。洪强宁在演讲开始告诫大家期望值不要太高,我还是相信不会有人觉得失望的。

    先说几句题外话,整个演讲听下来,我们会发现豆瓣在发展的过程中也是有点弯路,这些是一个网站发展过程中的宝贵财富,能把自己有周折的地方大大方方的拿出来,是难能可贵的事情。尽管豆瓣批露了很多架构细节出来,也不会(也不可能)有哪个公司一拿到这些东西,就能照猫画虎再做一个豆瓣并且超过豆瓣。从某种程度上来说这体现了豆瓣同学们的气度,这是令国内大多数公司汗颜的。很多公司只愿索取,而不愿奉献哪怕一点点出来,用这样封闭的心态对待技术其实是小家子气,守财奴的思维。技术只有为更多人所用才是大道。

    议论说完,再来叙述。写点对豆瓣架构的体会。戏法人人会变,各有巧妙不同。有些东西大家都在用(Nginx),但是有人的用得好,有人用了比不用还差。所以,需要逐渐总结,改进。学习别人的架构设计,不是要照搬,而是借鉴其思想。

    技术的选择

    一直以来,豆瓣在技术上都给人很前卫的感觉,看起来好像什么新用什么,其实是不是的,他们一直是"用已掌握的技术解决问题",现有的东西如果够用,那么就没必要一定迁移到新的上面去,而转换往往是为了解决当前问题。另外,换用新的东西,要有足够的驾驭能力,从演讲中得知,豆瓣曾有几次在临上线前发现基础库的Bug(比如 Libmemcached 的一致性哈希相关的Bug),技术团队能在第一时间有进行修复并且提交给开源社区。否则的话,就变成了一种错误决策了。

    磁盘转速

    小话题。如果可能,直接买 15000 转的磁盘好了。10000 转的磁盘可能省钱,但这东西部署了之后几乎就不太可能升级。所以,如果是初创公司,我的建议就是买高速磁盘,因为业务如果发展快了的话,先前对机器的定位也可能发生变化。

    杜绝远程 I/O 

    在普通的 TCP/IP 网络的环境下,不要进行远程数据写入操作。跨网络操作的延时看似没什么大不了的,但一旦达到临界点就回天乏术。这个事情基本是不撞南墙不回头,有的技术人员总要亲身体验一把才肯罢休。

    持续保持 URL 友好风格

    演讲中有多次提到一致性 URL ,其实体现了豆瓣对 URL Rewrite 的重视,结构调整,或者应用程序变化的时候,URL 最好做到"用户友好"的。这算是"软技术",但是应该加以最大的重视。

    数据库复制延迟问题

    对于 mysql 复制的环境,如果Slave 上有读取操作,那么有些情况下可能因为 Master 和 Slave 节点数据不一致对用户造成困惑。如果从一致性的角度上考虑,其实也不复杂:,只需要对"知道数据发生了变化的用户"提供一致性就行了(基本上就是发起变更的用户),不知道数据发生变化的用户对数据的不一致有一定的"容忍程度",当然说着简单,实现起来还是需要技巧和精巧的。

    大量小文件同步问题:Merkle tree

    关于大量小文件的同步问题,很多上了规模的网站都会遇到,如果设计得不好或者是比较偷懒,用传统的办法(比如 rsync 之类的老模式)很容易触发问题,也浪费资源。DoubanFS 是用Merkle tree(Hash Tree)的方式进行数据同步的。对这个问题的具体描述可以参见《大量小文件的实时同步方案》。Merkle Tree 是个很精巧的思路,ZFS 在用(refer),Amazon Dynamo 系统也在用。

    不会一会儿又有人留言说:我们早就采用这个思路了...... 我这里预先来句回答:拜托,你早点共享啊?

    豆瓣网架构-国内python语言网站的王者之路

    豆瓣网对互联网用户来说是知名的Web 2.0社区,但对开发者而言,更重要的是一个应用Python打造的非常成功的Web 2.0站点。豆瓣网已经达到了300万注册用户,另外还有千万级的非注册用户。访问量每天则超过两千万。

    豆瓣Python应用开发经验谈

    豆瓣是一个Web 2.0网站,这类网站的特点就是“Always Beta”,不断有新的产品和功能升级来为用户提供更好的服务。作为使用Python进行开发的网站,豆瓣有效的程序开发配置和版本控制值得我们学习。

    豆瓣的主要开发环境配置就是SVN+Trac+Bitten。豆瓣的版本管理系统使用的是Subversion(SVN),使用Trac来管理协同开发,同时使用Trac的Bitten插件进行持续集成。

    在开发模式方面,由于是Always Beta,豆瓣采用的方式是:站点运行在主分支上,开发者在开发新功能时会建立一个子分支,新功能开发并测试完成后,会更新服务器的主分支版本,之后上线。

    在开发框架方面,豆瓣主要使用Quixote(被称之为“堂吉诃德”,一个轻量级的Python Web框架,简单、高效,代码简洁);后台运行的Web服务主要使用Web.py(web.py也是一个Python的Web框架,简单且功能强大)。

    豆瓣网可分割成两大块:一块是前端的Web,也就是用户在浏览器访问的时候会触发一系列的操作,从数据库拿出数据,渲染成HTML页面反馈给用户,这是前端;另外一块是后端,在豆瓣有一个很强的数据挖掘团队,每天把用户产生的数据进行分析,进行组合,然后产生出用户推荐,然后放在数据库里面,前端会实时的抓取这些数据显示给用户。
    豆瓣(架构)设计现在在WEB这一端主要是用这么几种技术:前端是nginx和lighttpd,中间是Quixote的Web框架,后面是MySQL以及我们自己开发的DoubanDB。这些除了Quixote都是一些比较流行的、尖端的技术。Quixote稍微老一点,如果要重新设计的话,可能会在这方面做一些考虑。比如Python社区中的Django、Pylons等等都是可以考虑的,那么在豆瓣的内部的话,我们一般是用web.py,很轻量的一个Web框架来做,也是非常不错的选择,它可能需要自己做的事情多一点。但是,也不太可能完全重新设计了。

    豆瓣网可分割成两大块:一块是前端的Web,也就是用户在浏览器访问的时候会触发一系列的操作,从数据库拿出数据,渲染成HTML页面反馈给用户,这是前端;另外一块是后端,在豆瓣有一个很强的数据挖掘团队,每天把用户产生的数据进行分析,进行组合,然后产生出用户推荐,然后放在数据库里面,前端会实时的抓取这些数据显示给用户。

    豆瓣(架构)设计现在在WEB这一端主要是用这么几种技术:前端是nginx和lighttpd,中间是Quixote的Web框架,后面是MySQL以及我们自己开发的DoubanDB。这些除了Quixote都是一些比较流行的、尖端的技术。Quixote稍微老一点,如果要重新设计的话,可能会在这方面做一些考虑。比如Python社区中的Django、Pylons等等都是可以考虑的,那么在豆瓣的内部的话,我们一般是用web.py,很轻量的一个Web框架来做,也是非常不错的选择,它可能需要自己做的事情多一点。

    豆瓣现在还没有达到数据库分片的程度。最常见的手段是,按照功能分区。我们会把数据表分成几个独立的库,现在是一共有4个库。每个表都是库的一个部分,每个库会有主副两个。通过这种方式来减轻数据库的压力,当然这个是现在的方案,再往后的话,表的行数会增长,到达一定的程度后,还要进行水平分割,这是肯定的。然后我们现在的技术方面,在操作数据库之前,首先获取数据库的游标,有一个方法,这个方法会干所有的事情,我们以后做的时候会从这个方法中进行判断该从哪取东西。这个架构已经在了,只是现在还没有做这一步而已。

    数据库这边主要采用什么解决方案呢?

    在数据库这边,我们主要用的是MySQL。MySQL有一个问题,大文本字段会影响它的性能。如果数据量过大的话,它会挤占索引的内存。那么现在一个行之有效的方法是,我们另外建立一套可伸缩的Key-Value数据库,叫做DoubanDB。我们把不需要索引的大文本字段,放到DoubanDB里面去。MySQL只保存需要索引的Relationship这方面的信息。这样给MySQL数据库降低了压力,也就可以保证它的性能。

    比如说像保证数据的安全性,以及数据库的吞吐量,豆瓣是怎样的策略呢?

    首先DoubanDB会把每个数据在三个节点进行备份,任何一个出现故障都不会影响索取数据。MySQL是通过双Master方案,同时还会带1到2个slave,所以说在MySQL中我们会有三到四个的备份。这点是可以放心的。

    你刚才说到MySQL的双Master方案,这方面会不会存在什么问题?比如说同步的问题,等等?

    在MySQL里面,双Master方案是一个比较经典的方案,我们现在用它很大一部分是为了解决我们同步延迟的问题。在做切换的时候,会出现同步延迟的问题,但其实MySQL的同步速度还是可以的,在切换的时候,我们会忍受几秒钟等待同步的时间。在做脚本的切换的时候,我们会稍微等一下。

    豆瓣的数据表一般是怎么样的规模?

    数据表,这个不好说了,因为不同的表都是不一样的。我们最大的表是“九点”的Entry表,“九点”的爬虫爬过来的所有的文章,现在应该有四千万左右的行数。然后其他的上百万的表也有很多。还有包括收藏表也有千万级的行数。

    在这种海量数据的情况下,对数据表的就结构变更,一定是一个比较麻烦的问题。常见的情况,比如增加一个新的索引,会导致索引好几个小时。像豆瓣之前会存在这样的问题,是怎么解决的呢?

    这个问题曾经让我们吃过苦头,在忽视它的状况下就去改表,然后就锁了很长时间。后来我们意识到这个问题,如果有表的改动的话,我们会先在一个测试的库上试验一下它的时间长短,是不是在可接受的范围,如果是可接受的范围,比如说几分钟,就做一个定时任务,在深夜里面去执行。如果耗时是不可忍受的,就必须通过其他技术手段,我们现在的手段一般是建一个新表,这个新表从旧表同步数据,然后再写数据的时候,也会同步,往两边写,一直到两边完全一样了,再把旧表删掉,大概是这样一个方式。

    刚才您好像提过你们设计了自己的DoubanDB,还有一个是DoubanFS,这两者关系是怎么样的?

    首先是先出来的DoubanFS,我们刚开始的时候用MogileFS来解决我们可扩展图片存储的问题,由于MogileFS有一个重型数据库,这成为了它的性能瓶颈。我们为了解决这个问题,开发了DoubanFS,基于哈希来寻找节点。之后,我们又发现了新的问题,数据库中的大文本字段也会影响性能。所以,我们在DoubanFS的基础上,换了一个底层,做了一些调整,参照Amazon的dynamo思想,搭建了DoubanDB,把文本字段放在DoubanDB里面。做完之后,又反过来用DoubanDB来实现FS,大致是这么一个过程。

    DoubanFS跟DoubanDB的实现,他们在对于内容的安全性,或者内容的冗余性…

    都是(备份)三份。这都是可以配置的,现在的配置是3份。

    DoubanDB就是用什么机制实现的?

    DoubanDB简单来说是这样子:你来一个Key,它是Key-Value数据库,你要写或读的时候,通过这个Key来寻找这个值。拿一个Key对它做哈希,通过Consistent哈希方法去查找它在哪个节点上,然后往这个节点上去写或读。在这个节点上,顺着哈希的wheel顺次的找到第二、三个节点,写的时候会保证这三个节点都写,读的时候是任意一个,如果其中一个读失败了,会自动切换到下一个。

    您刚才提DoubanDB的话,是采用的技术是?

    DoubanDB的底层存储用的是TokyoCabinet,是一个很轻量级、高效的Key-Value数据库。我们在它的基础之上,做了分布式,用这种方式来实现的。

    实际上有一些其他的方案可以解决,比如说像Berkeley DB(简称BDB)、CouchDB等等,你们为什么要选择TokyoCabinet?

    最简单的原因是由于它足够快,实际上BDB跟它比较类似,BDB更加强大一些。对我们而言,我们在这边就是需要一个可靠、高效的Key-Value存储,这两个其实是我们都可以替换的,只要统一下接口就可以。CouchDB的话就是另外一个东西了,它是一个文档型数据库,它不仅仅做了一个Key-Value的工作,它还在这上面做了很多其他的事情,比如它有View的概念,可以进行query。这些TokyoCabinet是没有的,而我们暂时也不需要这些功能。CouchDB是一个很有意思的数据库,我们可能会在其他方面(应用),我们也在研究它。

    在豆瓣专门有一个算法团队,他们的主要工作就是数据挖掘。这边讲技术实现的话,可能就讲不完了。只能讲一些大概,数据挖掘是怎么和前端结合起来的,让用户看见的。每天用户在豆瓣上的操作都会产生很多数据,在豆瓣上面看到的东西,收藏的东西,都会存在数据库或是访问日志。每天这些信息都会传到算法团队的机器上,然后会从这个数据中建立一个稀疏矩阵,你看过什么,干过什么。他们维护了一个很高效的稀疏矩阵运算库,然后用它来做各种各样的尝试,去看是否能得到好的结果,一旦发现这个结果很好,就会把它写到数据库里面。然后用户在访问的时候,前端从数据库中取出推荐给你的数据,然后把这些数据做一些过滤(比如你读过的东西就不再给你展现了)、调整,最后展现给用户。基本上是这么一个逻辑。

    关于Python

    Python语言的历史可以参考《Guido Rossum:打造Google第三大开发语言

    关于Subversion

    Subversion(简称SVN)是一款开源的版本控制管理系统,被认为是CVS的替代者。Subversion的版本库可以通过网络访问,从而使用户可以在不同的电脑上进行操作。从某种程度上来说,允许用户在各自的空间里修改和管理同一组数据可以促进团队协作。

    关于Trac

    Trac是一个开源软件平台,集成了Wiki和问题跟踪管理系统。Trac以简单的方式建立了一个软件项目管理的Web应用,以帮助开发人员更好地写出高质量的软件。Trac采用Python语言开发的,因此Trac的在运行的时候,需要有Python环境的支持。

    关于Quixote

    Quixote是一个Python的Web框架,它基于简单灵活的方案设计,可以进行快速地开发项目,而且使用很多Python第三方模块。通过恰当地配置,可以让Quixote发挥巨大能量,这使得它可以被用于大规模系统当中。

  • 相关阅读:
    组装query,query汇总,query字段
    POJ 1276, Cash Machine
    POJ 1129, Channel Allocation
    POJ 2531, Network Saboteur
    POJ 1837, Balance
    POJ 3278, Catch That Cow
    POJ 2676, Sudoku
    POJ 3126, Prime Path
    POJ 3414, Pots
    POJ 1426, Find The Multiple
  • 原文地址:https://www.cnblogs.com/dhcn/p/7115269.html
Copyright © 2011-2022 走看看