首页 > 代码库 > 豆瓣网技术架构的 发展历程(一)
豆瓣网技术架构的 发展历程(一)
豆瓣简介:
•2005年3月上线
•以分享和发现为核心的社区
•读书、电影、音乐、小组、同城、九点
•我的豆瓣、友邻
一些数据:
•2.8M注册用户,约1/4活跃用户
•千万级非注册用户
•20M动态请求/天,峰值500~600/sec
•23台普通PC服务器(1U*15/2U*8)
•12台提供线上服务
•38G memcached
单服务器:
• 单台1U服务器 (frodo)
• 单核AMD Athlon 64 1.8GHz
• 1G内存,160G SATA*2
• Gentoo Linux
• MySQL 5
• Quixote (a Python web framework)
• Lighttpd + SCGI (shire)
• Memcached (!)
Gentoo Linux
•容易维护
•emerge mysql
•ebuild 便于管理 patch
•只安装需要的东西
•安全性
•GLSA(Gentoo Linux Security Advisories)
MySQL
•The world’s most popular open source database
•写少读多/写多读少 ==> MyISAM
•读写并发高 ==> InnoDB
•Replicate for backup
Python
•开发迅速
•Battery Included
•第三方库成熟
•社区成长中
•CPUG: http://python.cn/
Quixote
•
简单,轻量,易于实现REST风格的URL
•
当时还没有Django, TurboGears, Pylons这些选择,只有一
个笨重的ZOPE
•
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支持
•SCGI: 一个简化版本的FastCGI,由
Quixote开发者开发
•所有的请求都通过80端口的lighttpd进程
分发,动态内容走SCGI到localhost上的
Quixote进程。
Memcache
• 从上线起就在使用,有效减轻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.2M动态请求/天
•磁盘IO成为瓶颈
•需要寻找新机房
解决方案
•购买两台1U服务器
•pippin 和 meriadoc (后改名merry)
•双核, 4G内存,250G SATA*3
•一台作为应用服务器,一台作为数据库服务器
•迁移到双线双IP机房,使用DNS解析不同网段
IP -_-b
•开始多人协作开发,frodo做为开发用机
(subversion, trac, etc...)
几点发现
•数据库的内存分配对性能影响重大•innodb_buffer_pool_size
•磁盘随机寻道速度比吞吐量更重要
•网上找来的IP段分布很不靠谱