豆瓣網技術架構的 發展歷程(一)

豆瓣簡介：

•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段分佈很不靠譜