《洪强宁谈豆瓣网技术架构》由会员分享，可在线阅读，更多相关《洪强宁谈豆瓣网技术架构（7页珍藏版）》请在金锄头文库上搜索。
1、洪强宁谈豆瓣网技术架构洪强宁谈豆瓣网技术架构豆瓣（架构）设计现在在 WEB 这一端主要是用这么几种技术：前端是 nginx 和 lighttpd，中间是 Quixote 的 Web 框架，后面是 MySQL以及我们自己开发的 DoubanDB。这些除了 Quixote 都是一些比较流行的、尖端的技术。Quixote 稍微老一点，如果要重新设计的话，可能会在这方面做一些考虑。比如 Python 社区中的Django、Pylons 等等都是可以考虑的，那么在豆瓣的内部的话，我们一般是用 web.py，很轻量的一个 Web 框架来做，也是非常不错的选择，它可能需要自己做的事情多一点。但是，也不太可能
2、完全重新设计了。那如果要缓解高并发所带来的压力，Cache 的利用肯定是一个非常有效的途径。那么豆瓣的缓存命中率一般是多大？这方面的策略是怎样？ Memcache 命中率一般都在 97%左右，应该还算是比较高的。策略其实是比较简单的，如果每次要去执行一个比较耗时耗资源的操作，比如说去数据库查询的话，就会以 Python 的 Object 形式存放在Memcache 里面，下次再拿这个数据的时候就直接从 Cache 中拿就行了。这边选择什么样的东西，尽量有一个 Guideline，必须是要耗时的，耗资源的，而且是重复使用的。比如它是耗资源的，但是只用一次，Cache 也没有意义。差不多用这种方法
3、保证 Cache 的东西都是真正有效的，也提高了命中率。要提高承受高压力的流量，另外一个有效的措施是对数据库来进行分区分片，在这方面豆瓣是怎么做的？ 豆瓣现在还没有达到数据库分片的程度。我们现在最常见的手段是，按照功能分区。我们会把数据表分成几个独立的库，现在是一共有4 个库。每个表都是库的一个部分，每个库会有主副两个。通过这种方式来减轻数据库的压力，当然这个是现在的方案，再往后的话，表的行数会增长，到达一定的程度后，还要进行水平分割，这是肯定的。然后我们现在的技术方面，在操作数据库之前，首先获取数据库的游标，有一个方法，这个方法会干所有的事情，我们以后做的时候会从这个方法中进行判断该从哪取东
4、西。这个架构已经在了，只是现在还没有做这一步而已。数据库这边主要采用什么解决方案呢？ 在数据库这边，我们主要用的是 MySQL。MySQL 有一个问题，大文本字段会影响它的性能。如果数据量过大的话，它会挤占索引的内存。那么现在一个行之有效的方法是，我们另外建立一套可伸缩的 Key-Value 数据库，叫做 DoubanDB。我们把不需要索引的大文本字段，放到 DoubanDB 里面去。MySQL 只保存需要索引的 Relationship 这方面的信息。这样给 MySQL 数据库降低了压力，也就可以保证它的性能。比如说像保证数据的安全性，以及数据库的吞吐量，豆瓣是怎样的策略呢？ 首先 Doub
5、anDB 会把每个数据在三个节点进行备份，任何一个出现故障都不会影响索取数据。MySQL 是通过双 Master 方案，同时还会带1 到 2 个 slave，所以说在 MySQL 中我们会有三到四个的备份。这点是可以放心的。你刚才说到 MySQL 的双 Master 方案，这方面会不会存在什么问题？比如说同步的问题，等等？ 在 MySQL 里面，双 Master 方案是一个比较经典的方案，我们现在用它很大一部分是为了解决我们同步延迟的问题。在做切换的时候，会出现同步延迟的问题，但其实 MySQL 的同步速度还是可以的，在切换的时候，我们会忍受几秒钟等待同步的时间。在做脚本的切换的时候，我们会稍
6、微等一下。豆瓣的数据表一般是怎么样的规模？ 数据表，这个不好说了，因为不同的表都是不一样的。我们最大的表是“九点”的 Entry 表， “九点”的爬虫爬过来的所有的文章，现在应该有四千万左右的行数。然后其他的上百万的表也有很多。还有包括收藏表也有千万级的行数。在这种海量数据的情况下，对数据表的就结构变更，一定是一个比较麻烦的问题。常见的情况，比如增加一个新的索引，会导致索引好几个小时。像豆瓣之前会存在这样的问题，是怎么解决的呢？ 这个问题曾经让我们吃过苦头，在忽视它的状况下就去改表，然后就锁了很长时间。后来我们意识到这个问题，如果有表的改动的话，我们会先在一个测试的库上试验一下它的时间长短，是
7、不是在可接受的范围，如果是可接受的范围，比如说几分钟，就做一个定时任务，在深夜里面去执行。如果耗时是不可忍受的，就必须通过其他技术手段，我们现在的手段一般是建一个新表，这个新表从旧表同步数据，然后再写数据的时候，也会同步，往两边写，一直到两边完全一样了，再把旧表删掉，大概是这样一个方式。 刚才您好像提过你们设计了自己的 DoubanDB，还有一个是DoubanFS，这两者关系是怎么样的？ 首先是先出来的 DoubanFS，我们刚开始的时候用 MogileFS 来解决我们可扩展图片存储的问题，由于 MogileFS 有一个重型数据库，这成为了它的性能瓶颈。我们为了解决这个问题，开发了 Douba
8、nFS，基于哈希来寻找节点。之后，我们又发现了新的问题，数据库中的大文本字段也会影响性能。所以，我们在 DoubanFS 的基础上，换了一个底层，做了一些调整，参照 Amazon 的 dynamo 思想，搭建了DoubanDB，把文本字段放在 DoubanDB 里面。做完之后，又反过来用DoubanDB 来实现 FS，大致是这么一个过程。DoubanFS 跟 DoubanDB 的实现，他们在对于内容的安全性，或者内容的冗余性 都是（备份）三份。这都是可以配置的，现在的配置是 3 份。DoubanDB 就是用什么机制实现的？ DoubanDB 简单来说是这样子：你来一个 Key，它是 Key-V
9、alue 数据库，你要写或读的时候，通过这个 Key 来寻找这个值。拿一个 Key对它做哈希，通过 Consistent 哈希方法去查找它在哪个节点上，然后往这个节点上去写或读。在这个节点上，顺着哈希的 wheel 顺次的找到第二、三个节点，写的时候会保证这三个节点都写，读的时候是任意一个，如果其中一个读失败了，会自动切换到下一个。您刚才提 DoubanDB 的话，是采用的技术是？ DoubanDB 的底层存储用的是 TokyoCabinet，是一个很轻量级、高效的 Key-Value 数据库。我们在它的基础之上，做了分布式，用这种方式来实现的。 实际上有一些其他的方案可以解决，比如说像 Be
10、rkeley DB（简称BDB） 、CouchDB 等等，你们为什么要选择 TokyoCabinet？ 最简单的原因是由于它足够快，实际上 BDB 跟它比较类似，BDB 更加强大一些。对我们而言，我们在这边就是需要一个可靠、高效的Key-Value 存储，这两个其实是我们都可以替换的，只要统一下接口就可以。CouchDB 的话就是另外一个东西了，它是一个文档型数据库，它不仅仅做了一个 Key-Value 的工作，它还在这上面做了很多其他的事情，比如它有 View 的概念，可以进行 query。这些TokyoCabinet 是没有的，而我们暂时也不需要这些功能。CouchDB是一个很有意思的数据
11、库，我们可能会在其他方面（应用） ，我们也在研究它。 从我们刚才的讨论中，Web 前端你用了 nginx 又用了 lighttpd。它们都是非常流行的前端，这两种方案经常打架，豆瓣为什么把它们融合在一块？ 这是历史原因。我们其实没有刻意地去倾向某一个。这两个都是非常优秀的 Web Server，都很轻量，都很高效。最开始的时候我们用的是 lighttpd，然后是因为出现过一些问题，其实不是 lighttpd的问题，但当时我们怀疑可能是 lighttpd 有问题，就尝试了一下nginx，觉得这个也不错，然后这个结构就保留下来了。nginx 对开发者和用户的友好性都更好一些。我举个例子，比如说重启
12、，其实在豆瓣的 Web Server 是经常要重启的，我们会有一个健康检查的脚本，定时的检查网站是不是正常，如果觉得不正常的话，就会做一些保护措施，其中就包括重启。lighttpd 的重启，是一个很粗暴的Kill。Nginx 是一个 reload 的方案，会先把手头的事情做完了再重启。这样会好很多，而且它会在重启之前会帮你做一些好的事情。所以，现在我们用 Nginx 越来越多。Nginx 的配置文件也比lighttpd 写起来更舒服一些。 豆瓣现在有一个庞大的用户群体，针对这样一些海量数据做好数据挖掘，肯定不是一件容易的事情，能从技术这个角度讲讲挖掘的实现吗？ 在豆瓣专门有一个算法团队，他们的
13、主要工作就是数据挖掘。这边讲技术实现的话，可能就讲不完了。只能讲一些大概，数据挖掘是怎么和前端结合起来的，让用户看见的。每天用户在豆瓣上的操作都会产生很多数据，在豆瓣上面看到的东西，收藏的东西，都会存在数据库或是访问日志。每天这些信息都会传到算法团队的机器上，然后会从这个数据中建立一个稀疏矩阵，你看过什么，干过什么。他们维护了一个很高效的稀疏矩阵运算库，然后用它来做各种各样的尝试，去看是否能得到好的结果，一旦发现这个结果很好，就会把它写到数据库里面。然后用户在访问的时候，前端从数据库中取出推荐给你的数据，然后把这些数据做一些过滤（比如你读过的东西就不再给你展现了） 、调整，最后展现给用户。基本
14、上是这么一个逻辑。从刚才你所描述的内容，可以发现豆瓣其实是一个应用非常多的，几乎用的都是开源框架吧？ 全部是开源的。我相信你们从社区的智慧以及各方面都会获取很多东西，我不知道豆瓣对开源社区是不是也做了一些回馈？ 是有的，我们最大的回馈形式是 patch。我们用很多的开源软件，这当中就不可避免的有各种各样的问题，我们会尝试通过自己的努力解决这些问题，把我们的解决方案反馈给开发者。比较典型的像libmemcached，是一个 C 的 memcached 客户端。现在也是非常火的，基本是一个官方的 C 的客户端。它其实有很多 bug，我们在使用的时候发现，去修正它。现在我们的团队成员里面有直接就是它
15、的开发成员。比如说像 Python 的 Mako 模板，也是用的人非常多的模板。我们也在使用，使用起来发现它的性能稍微弱一些，我们也花了精力对它进行了优化，这个优化现在也是被接受了，在 Mako 的后来版本发布出来了。然后豆瓣自己也有一些开源的项目，最主要的开源的项目是豆瓣 API 的访问客户端，这个是在 google code 上面，也有很多志愿者参与进来，帮我们一起修改。然后从另外一个方面来说，豆瓣和国内的开源社区也有紧密的联系。豆瓣的上线通知就是发在开源组织 CPUG 的邮件列表里面的，豆瓣的很多成员也是 CPUG的成员，会在邮件列表里面去帮助回答问题，讨论问题，这也是一种回馈的方式。豆
16、瓣的开发团队是怎么样的？ 我们现在开发团队这边是 11 个人，有全职有兼职，还是比较放松。我们采用的是敏捷的方法，但是也不是完全的一模一样的方式。在豆瓣内部，我们尽可能地去发挥每个人的创造力。比如，在豆瓣作息是自由的，你可以自己决定什么时候来，什么时候走。比如你想在家里面静下心来写 code，你可以往邮件列表里面发条消息说，我今天不过来了，就可以在家里面。每天会有很多的讨论，我们在豆瓣的办公室是一个独立的区域。在这个区域里面有白板，大家可以随时讨论。然后每周我们会有一个技术交流会议，大家轮流来发表一下自己最近在看一些什么东西，有什么心得，跟大家分享一下，这些都促进团队的沟通与发展的，很有用的东西。发表于 2010 年 03 月 12 日 14:49:00
