<tt-image data-tteditor-tag=”tteditorTag” contenteditable=”false” class=”syl1557301477375″ data-render-status=”finished” data-syl-blot=”image” style=”box-sizing: border-box; cursor: text; color: rgb(34, 34, 34); font-family: “PingFang SC”, “Hiragino Sans GB”, “Microsoft YaHei”, “WenQuanYi Micro Hei”, “Helvetica Neue”, Arial, sans-serif; font-size: 16px; font-style: normal; font-variant-ligatures: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; orphans: 2; text-align: left; text-indent: 0px; text-transform: none; white-space: pre-wrap; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px; background-color: rgb(255, 255, 255); text-decoration-style: initial; text-decoration-color: initial; display: block;”>
image

<input class=”pgc-img-caption-ipt” placeholder=”图片描述(最多50字)” value=”” style=”box-sizing: border-box; outline: 0px; color: rgb(102, 102, 102); position: absolute; left: 187.5px; transform: translateX(-50%); padding: 6px 7px; max-width: 100%; width: 375px; text-align: center; cursor: text; font-size: 12px; line-height: 1.5; background-color: rgb(255, 255, 255); background-image: none; border: 0px solid rgb(217, 217, 217); border-radius: 4px; transition: all 0.2s cubic-bezier(0.645, 0.045, 0.355, 1) 0s;”></tt-image>

Python学习交流群：1004391443，这里是python学习者聚集地，有大牛答疑，有资源共享！小编也准备了一份python学习资料，有想学习python编程的，或是转行，或是大学生，还有工作中想提升自己能力的，正在学习的小伙伴欢迎加入学习。

image

豆瓣网对互联网用户来说是知名的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份。