《豆瓣网技术架构的发展历程_MySQL》由会员分享，可在线阅读，更多相关《豆瓣网技术架构的发展历程_MySQL（30页珍藏版）》请在金锄头文库上搜索。
1、|电组点 -小九 书: 读乐城我的亩需、友邻豆瓣网技术架构的发展历程豆瓣网技术架构的发展历程洪强宁，2002年毕业于清华大学，现任北京豆瓣互动科技有限公司首席架构 师。洪强宁和他带领的技术团队致力于用技术改善人们的文化和生活品质，在网站架构、性能、可伸缩性上进行深入研究。豆瓣网曾获软件中国2006年度最佳技术应用网站。豆瓣网简介 2005年3月上线以分皐和发现为 核心的社区职音 、同一些数据 2.8M注册用户，约1/4活跃用户千万级非注册用户 20M动态请求/天，峰值500-600/sec 23台普通PC服务器(IU*I5/2U*8) 12台提供线上服务 38G memcached单服务器单台
2、IU服务器(frodo) 单核AMD Athlon 64 1.8GHz IG内存，I60GSATAP Gentoo Linux MySQL 5 Quixote (a Python web framework) Lighttpd 十 SCGI (shire)Memcached (!) InternetMySQL Memcache Static FilesMySQL The worlds most popular open source database写少读釦写多读少= MylSAM读写并发髙= InnoDB Replicate for backupPython幵发迅速 Battery In e
3、luded第三方库成熟社区成长中卢 python CPUG; hg;Dythomun/LIGHTTPDBy 3Lighttpd很好的动态和静态性能原生SCGI支持 SUGI：个简化版本的FastCGI,由 Quixote开发者开发所有的请求都通过80端口的lighttpd进程 分发，动态内容走SCGI到loclhost上的 Quixote 进程。Memcache从上线起就在使用.有效减蛭MySQL负担对libmcmcache做了python封装(使用Pyrox),性能是 纯python版的3x4def gel_S4jbje.t (subject-id):subject me getC 5:*
4、tsubject.id)tf subject Is Mone:砒KXX from Svbjgtsutojgt.ld)subject - SubjcctC1store.fctchaic()3mt.sctfs; tsubjcct-ida subjectreturn subject问题出现 l5M动态请求/天，尚未到性能瓶颈机房不靠谱，频繁故障 IP段分布数据不靠谱，用户反映访问缓慢解决方案换到靠谱的机房，多线单IP(BGP)购买了一台新服务器arwen) 74G lw转 SATA * 3做为数据库服务器开始使用专门的服务器作后台计算问题出现 2M动态请求/天静态文件服务磁盘IO成为瓶颈上百万的小图
5、片（用户头像、封面图 片,etc.）数据库服务器接近瓶颈豆6M叽卿解决方案购买三台服务器，双核，4G, 25OG SATA*3将图口从一个人日录切分成1000：）个文件一个曰录 mod_rewrite 保持 URL 不变独立的图片lighupd进程,启用modmemcache模块, 缓存小图片减小磁盘IO对页面访问的影匝将应用服务从web服务器独立出去把更多的内存分配给静态文件服务增加一个只读数据库InumelMmrMemtatheMySQL SlvrMySQL MasterSlaveStatic Files只读数据库 scored加仙时凤性：为一个可用的只读敏抠库游标 決疼的rephcace
6、 dehy问题辆库复制需更时间更新主阵后.下一个済求往往就是受陕数据（更新数扌居后刷 新页直） 从辅库读会导致cche里存放的是旧数撼灵异事件！編决方法：更新数攥库后.在预期可能会马上用到的情况下.主 动刷新缓存不完美.but it works问题出现 2.5M动态请求/天数据库磁盘空间不够了我上/九点数据量庞大 SATA盘故障率高数据库压力增大解决方案 Scale Up,购买四台IU服务养 I6G 内存，I47G SCSI *2 + 500G SATA SCSI 做 RAID-0用MySQL Slave来保证冗余瑁加mcmcached节点数目所有的M yISAM表都改为InnoDB表提高内存
7、利用效率将全文搜索移至SphinxInen!HTTP 初LigtinpoMrmcarheMmcn 8Guata MiningData MiningMy$QL Slave问题出现 6.4M动态请求/天(5M PV)应用服务器成为瓶颈内存：占用总是增长，似乎有内存泄 露 CPU： memcache对象序列化/反序列化解决方案第二台应用服务器上线 lighttpd 的 mod_xgi 只能 round-robin lighttpd 1,5不稳定 mod_proxy p厂oxy.balance = fair (load based, passive balancing)当进程占用内存超过阈值，当前请求
8、完成后自杀使用spread聚合日志SCGISCSIbahttpcjHrTP ProiYNFTP PrcnySCGIUghttpdMemcqheLogAggregatorSCGILighitpdHlLiqhttpclughttpoStatic FilesMemcacheMemcqqhe问题出现 IIM动态请求/天（3台应用服务器）跨机房写入成为后台计算的瓶颈 Sphinx的定制性不够相册产品开发中，需要解决图片存储问 题灵异现象:网站变慢，积攒了大量连接得不到处理，load却不高豆独加必即解决方案数据库分库九点相关表独立出来数据挖掘相关表独立出来，主库放在 天津，北京只读 Sphinx - Xa
9、pian使用 M ogileFS解决方案（续） libmemcache libmemcathed, 使用consistent has h降低memcache调整代价 MiElibmcmcached&9consistent hash相关bug应用服务器升级至四核CPU修正 libmem cached 的 failover 关 bug 用 ngin*替代lighttpd做load balance 最后发现罪魁祸首是spread,冏改成用nginK记录日志Data Mining丄站71C53l多数据库连接表名全局唯一，维护一个表名至数据库的映射 store.farmr - s to re .get_
10、cu rsor( table=j ect * t ro-ro) cursor.executeC44select from subject5) subject Subject(ecur5or.fetchoneO) mc.setC-t-sid, sufrject)return subject在数据库间挪表变得容易，在主辅库间平衡负 载也变得容易UploaderMogiteFSNleLightpd 1.5HriProOrcctMog iieFS TrackerMogilaFSNodeMogileFSMaster问题出现 I3M动态请求/天计划将所有静态图片都导入M ogileFS文件小，数量大，Tr
11、acker DB可能成为 瓶颈相册产品很受欢迎，存储空间开始紧张豆矽站伽解决方案购买8台新服务器 32G内存，四核CPU (300G SCSI + IT SATA) x 3 (IT SAFA x 3) x 5 6台北京，2台天津开发 DoubanFSDoubanFS没有中心数据库，直接按照文件名hash查找所在节 点，可伸缩性更好按照hash值存成目录树，每个节点负责一组hash值 区域定时同步，基于文件修改时间的Merkle Tree利用cmsisgm hash减少増删节点带来的数抵移动量 WcbDAV作为读写接口读性能为MogileFS的3倍，写性能为50倍Merkle Tree_ 豆陆好伽wgned P06T IwmLlgnttpd 1.5Qihg 如rm qm问题出现 I6M动态请求/天数据库大文本字段严重影响了数据库性 能 DoubanFS中小图片导致IO增高数据库可用性要求提高解决方案开发 DoubanDB更好的伸缩性大文本字段移出后，MySQL的性能得到 增强 MySQL 双 Maste方案 failover更简单 解决replicate delay问题豆狗曲昨否即D
