《豆瓣网技术架构的发展历程》由会员分享，可在线阅读，更多相关《豆瓣网技术架构的发展历程（54页珍藏版）》请在金锄头文库上搜索。
1、豆瓣网技术架构的 发展历程2009.4 洪强宁 豆瓣网简介2005年3月上线以分享和发现为 核心的社区读书、电影、音 乐、小组、同 城、九点我的豆瓣、友邻一些数据2.9M注册用户，约1/4活跃用户 千万级非注册用户 23M动态请求/天，峰值500600/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
2、+ SCGI (shire) Memcached (!)Gentoo Linux容易维护 emerge mysql ebuild 便于管理 patch 只安装需要的东西 安全性 GLSA(Gentoo Linux Security Advisories)MySQLThe worlds most popular open source database写少读多/写多读少 = MyISAM读写并发高 = InnoDBReplicate for backupPython开发迅速Battery Included第三方库成熟社区成长中CPUG: http:/ 当时还没有Django, TurboGear
3、s, Pylons这些选择，只有一 个笨重的ZOPEhttp:/ 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) “%s” % subject.title site_footer(request)Lighttpd很好的动态和静
4、态性能 原生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 f
5、rom subject where id=%s”,subject_id)subject = Subject(*store.farm.fetchone()mc.set(s:+subject_id, subject)return subjectInternetMySQLLighttpdAppSCGIMemcacheStatic FilesFS问题出现1.2M动态请求/天 磁盘IO成为瓶颈 需要寻找新机房解决方案购买两台1U服务器 pippin 和 meriadoc (后改名merry) 双核, 4G内存，250G SATA*3 一台作为应用服务器，一台作为数据库服务器 迁移到双线双IP机房，使用D
6、NS解析不同网段 IP -_-b 开始多人协作开发，frodo做为开发用机 (subversion, trac, etc.)InternetDNSLighttpd (!“)Lighttpd (#$)AppMySQLHTTP ProxyMemcacheStatic FilesFSSCGI几点发现数据库的内存分配对性能影响重大 innodb_buffer_pool_size 磁盘随机寻道速度比吞吐量更重要 网上找来的IP段分布很不靠谱问题出现1.5M动态请求/天，尚未到性能瓶颈 机房不靠谱，频繁故障 IP段分布数据不靠谱，用户反映访问缓慢解决方案换到靠谱的机房，多线单IP(BGP) 购买了一台新服
7、务器 (arwen) 74G 1w转 SATA * 3 做为数据库服务器 开始使用专门的服务器作后台计算InternetLighttpdAppMemcacheData MiningMySQL MasterMySQL SlaveReplicateStatic FilesSCGIreadwrite问题出现2M动态请求/天 静态文件服务磁盘IO成为瓶颈 上百万的小图片（用户头像、封面图 片, etc.） 数据库服务器接近瓶颈解决方案购买三台服务器，双核，4G，250G SATA*3 将图片从一个大目录切分成10000个文件一个目录 mod_rewrite保持URL不变 独立的图片lighttpd进程
8、，启用mod_memcache模块， 缓存小图片 减小磁盘IO对页面访问的影响 将应用服务从web服务器独立出去 把更多的内存分配给静态文件服务 增加一个只读数据库Web ServiceInternetLighttpdAppMemcacheMySQL MasterMySQL SlaveReplicateStatic FilesLighttpd WebDAVWebDAVSCGI!“#$%MemcacheSpidersData Mining MySQL SlaveReplicateLighttpd (w/ mod_memcache)HTTP Proxystore.farmstore.farmrwr
9、iteread只读数据库store增加farmr属性，为一个可用的只读数据库游标 头疼的replicate delay问题 辅库复制需要时间 更新主库后，下一个请求往往就是要读数据（更新数据后刷 新页面） 从辅库读会导致cache里存放的是旧数据 灵异事件！ 解决方法：更新数据库后，在预期可能会马上用到的情况下，主 动刷新缓存 .不完美，but it works避免replicate delay引 起的灵异事件def get_subject(sid): sbj = mc.get(s:+sid) if sbj is None: sbj = flush_subject(sid, store.far
10、mr) return sbjdef flush_subject(sid, cursor=None): cursor = cursor or store.farm cursor.execute(“select . from subject”) subject = Subject(*cursor.fetchone() mc.set(s:+sid, subject) return subject def update_subject(subject, props): store.farm.execute(“update subject .”) mit() flush_subject(subject.
11、id, store.farm)问题出现2.5M动态请求/天 数据库磁盘空间不够了 我上/九点数据量庞大 SATA盘故障率高 数据库压力增大解决方案Scale Up，购买四台1U服务器 16G内存，147G SCSI *2 + 500G SATA SCSI 做 RAID-0 用MySQL Slave来保证冗余 增加memcached节点数目 所有的MyISAM表都改为InnoDB表 提高内存利用效率 将全文搜索移至SphinxInternetLighttpdAppMemcacheMySQL MasterMySQL SlaveReplicateStatic FilesLighttpd WebDAV
12、WebDAVSCGIMemcacheSpidersLighttpd (w/ mod_memcache)HTTP Proxystore.farmstore.farmrSphinxWeb ServiceMemcacheMemcacheWeb Service问题出现5.2M动态请求/天 图片流量费用成为最大成本 Web服务器的磁盘IO还是会影响动态页 面性能 应用服务器进程数不够了 机柜空间不够了解决方案天津的机房便宜一些 :) 承担图片流量 后台数据挖掘计算 容灾备份 购买3台1U服务器：4核，32G内存，1T SATA * 3 优化前端，启用 和 域名 lighttpd 1.5 with a
13、io support 部署LVS Scale Up: 应用服务器内存升级 4G - 8GInternetLighttpdStatic FilesLighttpd WebDAVLighttpdHTTP ProxyLighttpd 1.5 (w/ mod_cache)Lighttpd 1.5 (w/ mod_cache)LVS LB (Master)LVS LB (backup)KMySQL MasterMySQL SlaveReplicate!“#$%Data Mining!“#$%Data Mining MySQL Slavereplicatereadread writewrite问题出现6.
14、4M动态请求/天 (5M PV) 应用服务器成为瓶颈 内存：占用总是增长，似乎有内存泄 露 CPU：memcache对象序列化/反序列化解决方案第二台应用服务器上线 lighttpd的mod_scgi只能round-robin lighttpd 1.5不稳定 mod_proxy proxy.balance = fair (load based, passive balancing) 当进程占用内存超过阈值，当前请求完成后自杀 使用spread聚合日志LighttpdStatic FilesLighttpd WebDAVLighttpdHTTP ProxyAppMemcacheLighttpdA
15、ppMemcacheLighttpdInternetSCGISCGIHTTP ProxyHTTP ProxyLog Aggregatorspreadspread问题出现11M动态请求/天（3台应用服务器） 跨机房写入成为后台计算的瓶颈 Sphinx的定制性不够 相册产品开发中，需要解决图片存储问 题 灵异现象： 网站变慢，积攒了大量连接 得不到处理，load却不高解决方案数据库分库 九点相关表独立出来 数据挖掘相关表独立出来，主库放在 天津，北京只读 Sphinx - Xapian 使用MogileFS!“ Master#$ Master%&()Data Mining%&()Data Mining#$ Slave!“ Slave*+,- Slave!“ Slave#$ Slave*+,- Masterreplicatewritewritereplicatereplicatereadreadreplicatereplicate多数据库连接表名全局唯一，维护一个
