【技术架构】豆瓣网技术架构变迁

Posted on Wed 01 July 2009 in it

演讲人 洪强宁 发布于 2009年6月25日 下午9时20分 讲述随着用户规模的增长,系统由上线时的单台服务器架构的持续变化演进。

视频:http://www.infoq.com/cn/presentations/hongqn-douban

摘录讲稿《豆瓣技术架构的发展历程》 1. 豆瓣网简介 2005年3月上线 以分享和发现为核心的社区 读书、电影、音乐、小组、同城、9点 我的豆瓣、友邻

  1. 现在的一些数据 用户: 2.8M注册用户,约1/4活跃用户 千万级非注册用户 请求数: 20M个动态请求/天,峰值500~600个/sec 服务器: 23台普通PC服务器(1U15/2U8) 前端12台 后台(数据/数据备份/数据挖掘) 38G memcached 开发团队: 11人(全职+兼职)

  2. 单服务器架构(2005年) 单台1U服务器 (frodo)--使用指环王中的名词来命名 单核AMD Athlon 64 1.8GHz 1G内存,160G SATA*2 Gentoo Linux 一个以源码形式发布的linux 依赖关系管理:emerge mysql patch管理:ebuild 安全性:GLSA(Gentoo Linux Security Advisories) MySQL 5 The world’s most popular open source database 写少读多/写多读少 ==> MyISAM 读写并发高 ==> InnoDB Replicate for backup Python: 开发迅速 Battery Included 第三方库成熟 社区CPUG: http://python.cn/ Quixote (a Python web framework) 简单,轻量,易于实现REST风格的URL 当时还没有Django, TurboGears, Pylons这些选择,只有一个笨重的ZOPE 演示RESTful:http://www.douban.com/subject/1000001

luz/subject/init.py

def _q_lookup(request, name): subject = get_subject(name) return lambda req: subject_ui(req, subject)

luz/subject/subject_ui.ptl

def subject_ui [html] (request, subject): site_header(request) “<h1>%s</h1>” % subject.title site_footer(request) Lighttpd + SCGI (shire) 很好的动态和静态性能 原生SCGI支持 SCGI: 一个简化版本的FastCGI,由Quixote开发者开发 所有的请求都通过80端口的lighttpd进程分发,动态内容走SCGI到localhost上的Quixote进程。 Memcached (!) 从上线起就在使用,有效减轻MySQL负担 对libmemcache做了python封装(使用Pyrex),性能是纯python版的3x+ def get_subject(subject_id): subject = mc.get(‘s:’+subject_id) if subject is None: store.farm.execute(“select xxx, xxx from subject where id=%s”, subject_id) subject = Subject(*store.farm.fetchone()) mc.set(‘s:’+subject_id, subject) return subject

  1. 问题出现(2006年) 1.2M动态请求/天 磁盘IO成为瓶颈 需要寻找新机房

  2. 解决办法 购买两台1U服务器 pippin 和 meriadoc (后改名merry) 双核, 4G内存,250G SATA*3 一台作为应用服务器,一台作为数据库服务器 迁移到双线双IP机房,使用DNS解析不同网段 开始多人协作开发,frodo做为开发用机(subversion, trac, etc...)