豆瓣技术架构调研

关键字包括: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发挥巨大能量,这使得它可以被用于大规模系统当中。

你可能感兴趣的:(豆瓣技术架构调研)