如果能达到这样的访问量,确实说明豆瓣高并发的能力是相当强,我想请您从技术这个角度介绍一下豆瓣网的架
构。
这个话题比较大一点,我刚才在演讲的时候,已经表述这方面的问题了。可以这么说,最简单的方法来说,豆瓣网可分割成两大块:一块是前端的Web,也就是用
户在浏览器访问的时候会触发一系列的操作,从数据库拿出数据,渲染成HTML页面反馈给用户,这是前端;另外一块是后端,在豆瓣有一个很强的数据挖掘团
队,每天把用户产生的数据进行分析,进行组合,然后产生出用户推荐,然后放在数据库里面,前端会实时的抓取这些数据显示给用户。
如果是这样子,要是让你重新设计的话,你会觉得有必要改进里面哪些部分
吗?
豆瓣(架构)设计现在在WEB这一端主要是用这么几种技术:前端是nginx和lighttpd,中间是Quixote的Web框架,后面是MySQL以
及我们自己开发的DoubanDB。这些除了Quixote都是一些比较流行的、尖端的技术。Quixote稍微老一点,如果要重新设计的话,可能会在这
方面做一些考虑。比如Python社区中的Django、Pylons等等都是可以考虑的,那么在豆瓣的内部的话,我们一般是用web.py,很轻量的一
个Web框架来做,也是非常不错的选择,它可能需要自己做的事情多一点。但是,也不太可能完全重新设计了。
那如果要缓解高并发所带来的压力,Cache的利用肯定是一个非常有效
的途径。那么豆瓣的缓存命中率一般是多大?这方面的策略是怎样?
Memcache命中率一般都在97%左右,应该还算是比较高的。策略其实是比较简单的,如果每次要去执行一个比较耗时耗资源的操作,比如说去数据库查询
的话,就会以Python的Object形式存放在Memcache里面,下次再拿这个数据的时候就直接从Cache中拿就行了。这边选择什么样的东西,
尽量有一个Guideline,必须是要耗时的,耗资源的,而且是重复使用的。比如它是耗资源的,但是只用一次,Cache也没有意义。差不多用这种方法
保证Cache的东西都是真正有效的,也提高了命中率。
要提高承受高压力的流量,另外一个有效的措施是对数据库来进行分区分
片,在这方面豆瓣是怎么做的?
豆瓣现在还没有达到数据库分片的程度。我们现在最常见的手段是,按照功能分区。我们会把数据表分成几个独立的库,现在是一共有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是一个很有意思的数据库,我们可能会在其他方面(应用),我们也在研究它。
从我们刚才的讨论中,Web前端你用了nginx又用了
lighttpd。它们都是非常流行的前端,这两种方案经常打架,豆瓣为什么把它们融合在一块?
这是历史原因。我们其实没有刻意地去倾向某一个。这两个都是非常优秀的Web
Server,都很轻量,都很高效。最开始的时候我们用的是lighttpd,然后是因为出现过一些问题,其实不是lighttpd的问题,但当时我们怀
疑可能是lighttpd有问题,就尝试了一下nginx,觉得这个也不错,然后这个结构就保留下来了。nginx对开发者和用户的友好性都更好一些。我
举个例子,比如说重启,其实在豆瓣的Web
Server是经常要重启的,我们会有一个健康检查的脚本,定时的检查网站是不是正常,如果觉得不正常的话,就会做一些保护措施,其中就包括重启。
lighttpd的重启,是一个很粗暴的Kill。Nginx是一个reload的方案,会先把手头的事情做完了再重启。这样会好很多,而且它会在重启之
前会帮你做一些好的事情。所以,现在我们用Nginx越来越多。Nginx的配置文件也比lighttpd写起来更舒服一些。
豆瓣现在有一个庞大的用户群体,针对这样一些海量数据做好数据挖掘,
肯定不是一件容易的事情,能从技术这个角度讲讲挖掘的实现吗?
在豆瓣专门有一个算法团队,他们的主要工作就是数据挖掘。这边讲技术实现的话,可能就讲不完了。只能讲一些大概,数据挖掘是怎么和前端结合起来的,让用户
看见的。每天用户在豆瓣上的操作都会产生很多数据,在豆瓣上面看到的东西,收藏的东西,都会存在数据库或是访问日志。每天这些信息都会传到算法团队的机器
上,然后会从这个数据中建立一个稀疏矩阵,你看过什么,干过什么。他们维护了一个很高效的稀疏矩阵运算库,然后用它来做各种各样的尝试,去看是否能得到好
的结果,一旦发现这个结果很好,就会把它写到数据库里面。然后用户在访问的时候,前端从数据库中取出推荐给你的数据,然后把这些数据做一些过滤(比如你读
过的东西就不再给你展现了)、调整,最后展现给用户。基本上是这么一个逻辑。
从刚才你所描述的内容,可以发现豆瓣其实是一个应用非常多的,几乎用
的都是开源框架吧?
全部是开源的。
我相信你们从社区的智慧以及各方面都会获取很多东西,我不知道豆瓣对
开源社区是不是也做了一些回馈?
是有的,我们最大的回馈形式是patch。我们用很多的开源软件,这当中就不可避免的有各种各样的问题,我们会尝试通过自己的努力解决这些问题,把我们的
解决方案反馈给开发者。比较典型的像libmemcached,是一个C的memcached客户端。现在也是非常火的,基本是一个官方的C的客户端。它
其实有很多bug,我们在使用的时候发现,去修正它。现在我们的团队成员里面有直接就是它的开发成员。比如说像Python的Mako模板,也是用的人非
常多的模板。我们也在使用,使用起来发现它的性能稍微弱一些,我们也花了精力对它进行了优化,这个优化现在也是被接受了,在Mako的后来版本发布出来
了。然后豆瓣自己也有一些开源的项目,最主要的开源的项目是豆瓣API的访问客户端,这个是在google
code上面,也有很多志愿者参与进来,帮我们一起修改。然后从另外一个方面来说,豆瓣和国内的开源社区也有紧密的联系。豆瓣的上线通知就是发在开源组织
CPUG的邮件列表里面的,豆瓣的很多成员也是CPUG的成员,会在邮件列表里面去帮助回答问题,讨论问题,这也是一种回馈的方式。
豆瓣的开发团队是怎么样的?
我们现在开发团队这边是11个人,有全职有兼职,还是比较放松。我们采用的是敏捷的方法,但是也不是完全的一模一样的方式。在豆瓣内部,我们尽可能地去发
挥每个人的创造力。比如,在豆瓣作息是自由的,你可以自己决定什么时候来,什么时候走。比如你想在家里面静下心来写code,你可以往邮件列表里面发条消
息说,我今天不过来了,就可以在家里面。每天会有很多的讨论,我们在豆瓣的办公室是一个独立的区域。在这个区域里面有白板,大家可以随时讨论。然后每周我
们会有一个技术交流会议,大家轮流来发表一下自己最近在看一些什么东西,有什么心得,跟大家分享一下,这些都促进团队的沟通与发展的,很有用的东西。
看来豆瓣是一个相当开放、技术和兴趣驱动的团队。
我们希望一直保持这样的样子。
阅读(915) | 评论(0) | 转发(0) |