豆瓣网技术架构的发展历程
豆瓣 案例分析 (最美ppt版本)
Part
4
经营模式
4.1 提供的服务
4.1.1 品味系统
Top 榜单
产品资料 相关推荐 热门标签
成员评论
购买链接
4.1.2 表达系统
发布信息汇总
用户“我的豆瓣”页面右边是用户站内发布信息汇总，发表评论、回应 评论、讨论话题从上而下分列。
个人主页
左边是用户对站内“物”的行为记录，包括收藏、评论。右边是交友信 息，有用户个人信息（所在城市、外部BLOG地址、自我介绍等），沟通 功能键（加为友邻、发豆邮）、用户状态栏（是否为友邻），此外还有 用户对站内“人”的行为记录，包括小组和友邻。
个人主页
4.1.3 交流系统
话题讨论
小组中，会有新发话题的提取，显示的是话题标题、小组名、发帖人名、回应 数和最后回应时间，即时更新。用户可以及时浏览并参与讨论。
交友
网站推荐“人”的信息，包括即时性的网站新成员显示和豆瓣通过用 户已有行为计算出的兴趣相仿用户——“豆瓣认为和你口味最像的” 。这些用户列在豆瓣“我的友邻”页面右下角，用户可以详细浏览他 们看过的书和电影，决定是否将其列为自己的友邻。一旦这些成员成 为友邻，用户可以很方便了解到他们的动态信息：比如他们正在看的 书、想看的书，添加的书评等。用户间的联系方式主要是通过“豆邮 ”，类似碰碰“小纸条”的站内信息交互方式。
3.2网站建设技术构架
3.3豆瓣的技术架构与主要组件
豆瓣整个基础架构可以粗略的分为在线和离线两大块。在线的部分和大部分网站类似：前面用 LVS做HA，用Nginx做反向代理， 形成负载均衡的一层；应用层主要是做运算，将运算结果返回给前面的用户，DAE平台是这两年建起来的，现在大部分豆瓣的应 用基本都跑在DAE上面了；应用后面的基础服务也跟其他网站差不多，MySQL、memcached、redis、beanstalkd，不一样的是 NoSQL的选择——BeansDB，这是我们在几年前开源的KV数据库，也是国内比较早开源的KV数据库。 豆瓣作为一个早期就选择以Python为主要编程语言的公司，网站所使用到的技术很多都与Python相关，包括主要框架quixote 、 自行实现的DPark等等。在其它技术的选择上，并没有太大不同：nginx、MySQL、memcached、BeansDB、redis……都是知名 开源项目。在这些开源项目之上，豆瓣根据自己产品的特性，针对性地做了配置与部署设置。 除了使用开源项目，豆瓣也根据自身需要自主研发或实现了一些产品，比较有特色的如DAE、DPark等等。
技术架构发展历程
技术架构发展历程
技术架构发展历程大致分为以下四个阶段：
1.单应用架构。
网站初期，所有软件和应用都部署在一台机器上，这个阶段讲究效率。
2.应用服务器和数据库服务器分离。
随着网站上线，访问量逐步上升，单台机器的负载慢慢提高，在单台机器还没有超载时，讲web服务器和数据库服务器拆分，这样不仅提高了单机的负载能力，也提高了容灾能力。
3.分布式文件系统和分布式数据库系统。
数据库经过读写分离后，从一台服务器拆分成两台服务器，但是随着网站业务的发展依然不能满足需求，需要使用分布式数据库，文件系统也是一样，需要使用分布式文件系统。
4.微服务架构。
将整个系统根据业务拆分成不同的产品线，不同的业务团队负责不同的产品线。
豆瓣网案例分析
一、豆瓣网的创建及介绍.2005年3月，一家名为豆瓣网的Web2.0网站出现在人们视野，而后如一匹黑马迅速壮大，占据了阅读者、影迷、音乐爱好者以及图书音像商阵营中一个举足轻重的位置。
创建人为杨勃，起初创建之时，杨勃只是为“想看看有多少人和自己读同样的书”而编写了一个简单的程序，并以其工作所在地点——北京“豆瓣胡同”为其命名。
豆瓣网的建立与网络Web2.0技术的兴起和发展有莫大关系。
Web2.0是对Web1.0的信息进行扩展，丰富，使其更加多元化和个性化。
主要的Web2.0的元素有如博客、播客、社区、P2P下载服务等，其特征是资源由多人共同创建，共同分享，豆瓣网正是这样一个Web2.0网站。
信息的共享使豆瓣成为一个以青年知识分子为主要受众群体的书影音信息资料汇集地和评论交流社区。
豆瓣提供了书籍、影片、音乐的评论，但是没有任何不利于版权保护的下载服务，是一家以健康为网站主题之一的Web2.0网站。
截止到2010年底，豆瓣已经有注册用户超过4600万，其中活跃用户数2000万，人均访问停留时间：9.9分钟。
Alexa排名约为全球160已经成为全球为数不多的web 2.0的领头企业。
毋庸置疑，豆瓣已经在某些程度成为中国web 2.0的典型代表，在中国、美国，甚至全球的互联网上，豆瓣都是第一家以算法来推算用户的需求这样的模式存在的网络公司。
二、豆瓣网的功能（一）信息共享平台与其他书评、影评网站不同，豆瓣网的书籍、影视、音乐条目都由用户自行添加补充完整，例如对于影视条目，可以补充同一作品的不同海报和剧照，这充分体现了Web2.0时代的资源共享，充分交互的特性，打破了以往一对多传播的规律，开启多对多传播的方向。
这一方面使信息资源的容量不断扩充丰富，给于更多用户的信息查询获取，另一方面也极大的调动用户的积极性，使之不仅成为信息资源的获益者，更成为主动参与者、创造者，共同推动数据库的更新扩容，推动信息资源的传播共享。
CTO谈豆瓣网和校内网技术架构变迁
CTO谈豆瓣网和校内网技术架构变迁豆瓣网CTO洪强宁讲述网站架构变迁罗马不是一天建成的，豆瓣的技术架构也是随着用户规模的增长一直在持续变化中。
洪强宁，2002年毕业于清华大学，现任北京豆瓣互动科技有限公司首席架构师。
洪强宁和他带领的技术团队致力于用技术改善人们的文化和生活品质，在网站架构、性能、可伸缩性上进行深入研究。
豆瓣网曾获软件中国2006年度最佳技术应用网站。
校内网CTO黄晶讲述网站架构变迁每个网站的发展都会按照一个大致相同的路线去完成，当然这里说的是每个相对成功的网站。
第一阶段：这一阶段没有太大的访问量，甚至只有一台服务器就搞定了所有的访问。
DB和前端的代码全都在一起，压力不高。
忆者注：我觉得在alexa没进五万的时候，只要不是特殊的应用，基本都在此列吧。
第二阶段：网站初具规模，DB压力大增，单独的一台DB已经满足不了现在的访问量，开始考虑读写分离的Master-slave库，使用三个及以上的服务器。
忆者注：这时网站的alexa基本上会在1-3万的位置，每天的ip在5-10w的样子，当然，DB我们都认为是MySql。
第三阶段：访问量继续增加，增加到了DB的压力在Master的机器上非常的明显了，Master开始出现吃不消的情况，出现写耗尽。
主从也已经不能满足要求，需要进一步解决负载问题，此时要引入Mysql Proxy 程序，进行中间层代理，实现负载均衡，易于扩展。
忆者注：这时网站已经不可限量了，先恭喜下你的网站能用到这段。
第四阶段：网站继续发展，进而出现了数据量的成倍增长，原来的N台DB都出现了一个问题，数据量巨大，无法完成正常速度的读写。
此时，需要对网站按功能进行垂直划分，比如用户注册登录是一部分、UGC 又是另一部分。
与此同时，对数据本身进行水平划分，也就是Hash散表或者是散库。
第五阶段：真的没了。
再往下玩就灭了。
其实再进一步第五第六阶段，就是无法预想的未来了，也许有什么突飞猛进的科学技术发明也说不好。
解密豆瓣运营全过程
关于豆瓣网的调查分析解密豆瓣运营全过程作者：佚名一、什么是豆瓣？豆瓣网由前某物流咨询公司CTO杨勃于2005年3月创办，启动资金是杨勃几个朋友共计不到20万人民币的天使投资，以独到的书评、影评、乐评主题社区著称，因为开创了国内Web2.0新模式而闻名。
从构想到技术实现均由杨勃一人完成，业内对此有“一个人的豆瓣”的评价。
豆瓣的得名来自于杨勃曾经居住的北京朝阳门附近的豆瓣胡同。
（一）alexa数据1.alexa排名：1699（3月平均）2. 每百万用户登陆数：391（3月平均）3. 单个用户页面浏览量：9.1（3月平均）（二）网站相关数据官方页面数据：1. 成立于2005年3月6日2. 注册成员数：1450443. 城市居民数：22258（注册成员中按城市自主分类者）4. 成立小组数：5981备注：以上具体数据均为2006/4/18页面即时数据。
页面观察数据：1．平均每天增加注册成员900人左右2．平均每天增加城市居民数150人左右3．平均每天增加小组数50个左右4．小组数据：超过1500个小组是10人以上，最多人数小组为“爱看电影”（5537人）；60%的小组为5人（含5人）小组，其中1人小组占40%。
备注：以上观察数据均为2006/4/7—2006/4/18时间段内页面观察所得。
从以上数据，豆瓣的用户发展数目比起同级别排名的网站并不算突出；从数据图表可见，它的用户曲线和访问曲线都是比较平缓的，考虑到它的网站性质和经营策略，豆瓣的用户基数和用户上升幅度虽然不高，但目标用户比例较高，用户的流失相对减少。
（三）网站发展状况以下为引用的内容：●2004年9月杨勃为自己的旅行网站制作了商业计划书，并且将这个网站命名为“驴宗”，在论证这个商业计划时朋友的建议让杨勃放弃了“驴宗”，将眼光投到“书”这个更宽广的领域。
●从2004年10月开始开发，经历了5个月，2005年3月6日，杨勃的豆瓣网开张了，并且第一天就有用户注册。
豆瓣首席架构师洪强宁 谈豆瓣网技术架构
如果能达到这样的访问量，确实说明豆瓣高并发的能力是相当强，我想请您从技术这个角度介绍
如果是这样子，要是让你重新设计的话，就是说你会觉得有必要改进里面哪些部分吗？
那如果要缓解高并发所带来的压力，
要提高承受高压力的流量，另外一个有效的措施是对数据库来进行分区分片，在这方面豆瓣是怎比如说像保证数据的安全性，以及数据库的吞吐量，豆瓣是怎样的策略呢？
在这种海量数据的情况下，对数据表的就结构变更，一定是一个比较麻烦的问题。
常见的情况，
DoubanDB
实际上有一些其他的方案可以解决，比如说像从我们刚才的讨论中，
我相信你们从社区的智慧以及各方面都会获取很多东西，我不知道豆瓣对开源社区是不是也做了
那现场的观众有没有什么问题？其他记者：我是接着社区那个话题问一下，豆瓣现在有了很多的非常感谢强宁接受我们的采访，也恭喜今天在大会的演讲上面取得了非常圆满的成功。
豆瓣发展历程
豆瓣发展历程豆瓣是中国最大的综合性社交网站之一，致力于为用户提供图书、电影、音乐、创作、吃喝玩乐等各个领域的分享与交流平台。
下面就让我们一起回顾一下豆瓣的发展历程吧。
豆瓣成立于2005年3月6日，创始人是理查·刘易斯和他的几位大学同学。
当时，豆瓣定位为一个图书推荐网站，用户可以在上面给图书评分、撰写书评和分享阅读心得。
由于精心设计的界面和丰富的内容，豆瓣很快吸引了大量的读者和活跃用户。
这也为豆瓣在后来的发展打下了坚实的基础。
2007年，豆瓣决定扩展到新的领域，推出了电影频道。
用户可以通过对电影进行评分、影评和讨论，以及观看豆瓣电影库中的免费电影。
这一举措引起了广泛的关注和讨论，使得豆瓣成为了中国最权威的电影评分网站之一。
随着用户数量的不断增加，豆瓣开始尝试推出更多的功能和服务。
2009年，豆瓣音乐上线，用户可以在上面发现新的音乐、组建音乐小组并参与音乐讨论。
2011年，豆瓣小组上线，用户可以加入他们感兴趣的小组，与志同道合的人交流和分享。
由于这些新功能的引入，豆瓣的用户活跃度进一步提升，社群效应逐渐显现。
2011年后，豆瓣逐渐开始了扩张的步伐。
他们推出了豆瓣阅读、豆瓣电台、豆瓣同城等功能模块，以满足用户在不同领域的需求。
豆瓣阅读提供了丰富的图书资源和阅读活动，豆瓣电台则提供了个性化的音乐推荐和广播节目。
豆瓣同城则帮助用户找到身边有趣的活动和朋友，提供了一个线下社交的平台。
目前，豆瓣已经发展成为一个涵盖图书、电影、音乐、读书、电视剧、音乐人、艺术、设计等多个领域的综合性社交平台。
除了用户生成的内容，豆瓣还与众多的文化机构、媒体和品牌合作，提供独特的活动和推广。
豆瓣还推出了豆瓣FM、豆瓣时间等移动端应用，方便用户随时随地进行分享和交流。
豆瓣的发展历程充满了创新和变革。
它从一个简单的图书推荐网站逐渐演变成为中国最大的综合性社交平台之一，影响着数以千万计的用户。
豆瓣的成功不仅在于提供了优质的内容和功能，更在于培养了一个活跃的用户社区，让用户可以互相交流、互相启发。
解密豆瓣运营全过程
解密豆瓣运营全过程豆瓣是中国最大的文化社区之一，涵盖了电影、音乐、读书、电视剧、活动等多个领域。
作为一个网络平台，豆瓣的运营过程可以分为三个主要阶段：起步阶段、发展阶段和成熟阶段。
在起步阶段，豆瓣的运营团队主要关注平台的建设和内容的积累。
团队会投入大量的资源和人力来建设网站的基础框架，包括用户注册和登录、信息发布和交流等功能。
同时，团队还会选择一些优质的内容，并邀请一些有影响力的用户加入平台，以吸引更多的用户加入。
此外，还会利用一些推广手段，比如线下活动、线上宣传等，来提高平台的知名度和用户粘性。
随着用户数量和内容积累的增长，豆瓣进入了发展阶段。
在这个阶段，豆瓣的运营团队开始重视用户需求和体验，他们会根据用户的反馈和行为数据来不断调整和优化平台功能和内容。
同时，团队还会开设一些专题活动，如电影、音乐、读书等主题推荐，以及用户评分和评论等互动功能，来增加用户参与度和粘性。
此外，团队还会与一些内容提供商合作，比如影视公司、出版社等，以获取更多优质的内容资源，并通过付费会员等方式来实现商业化。
到了成熟阶段，豆瓣已经积累了大量用户和内容，成为一个庞大的社区。
在这个阶段，豆瓣的运营团队主要关注平台的运营和维护。
他们会加强社区管理，以维护用户秩序和内容质量，比如打击垃圾信息、处理用户投诉等。
同时，团队也会开展更多的活动，比如豆瓣电影节、豆瓣图书节等，以提升平台影响力和用户参与度。
此外，团队还会继续改进和创新平台功能，以适应用户需求的变化和新兴的社交趋势。
在整个运营过程中，数据分析和反馈是非常重要的环节。
豆瓣的运营团队会通过各种数据统计工具来监测用户行为和反馈，并根据数据分析来调整运营策略。
比如，团队会根据用户投票和评论来精选推荐内容，提高平台的个性化推荐效果；同时，团队也会根据用户的需求和行为来引入新功能，比如豆瓣FM、豆瓣阅读等，以满足用户对多样化内容的需求。
总的来说，豆瓣的运营过程是一个不断完善和创新的过程。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
Python
• • • •
开发迅速 Battery Included 第三方库成熟 社区成长中
•
CPUG: /
Quixote
• 简单，轻量，易于实现REST风格的URL • 当时还没有Django, TurboGears, Pylons这些选择，只有一
个笨重的ZOPE
Internet
Lighttpd
SCGI
App
FS
MySQL
Memcache
Static Files
问题出现
• 1.2M动态请求/天 • 磁盘IO成为瓶颈 • 需要寻找新机房
解决方案
• • • •
购买两台1U服务器
• •
pippin 和 meriadoc (后改名merry) 双核, 4G内存，250G SATA*3
露
• CPU：memcache对象序列化/反序列化
解决方案
•
第二台应用服务器上线
• • •
lighttpd的mod_scgi只能round-robin lighttpd 1.5不稳定 mod_proxy
•
proxy.balance = fair (load based, passive balancing)
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
问题出现
• 2.5M动态请求/天 • 数据库磁盘空间不够了 • 我上/九点数据量庞大 • SATA盘故障率高 • 数据库压力增大
解决方案
• • • • •
Scale Up，购买四台1U服务器
• •
16G内存，147G SCSI *2 + 500G SATA SCSI 做 RAID-0
用MySQL Slave来保证冗余 增加memcached节点数目 所有的MyISAM表都改为InnoDB表
单服务器
• • • • • •
单台1U服务器 (frodo)
• •
单核AMD Athlon 64 1.8GHz 1G内存，160G SATA*2
Gentoo Linux MySQL 5 Quixote (a Python web framework) Lighttpd + SCGI (shire) Memcached (!)
Memcache
Web Service
store.farmr
Lighttpd WebDAV Static Files
MySQL Slave Spiders Memcache
Memcache
问题出现
• 5.2M动态请求/天 • 图片流量费用成为最大成本 • Web服务器的磁盘IO还是会影响动态页
面性能
Lighttpd
• 很好的动态和静态性能 • 原生SCGI支持 • SCGI: 一个简化版本的FastCGI，由
Quixote开发者开发
• 所有的请求都通过80端口的lighttpd进程
分发，动态内容走SCGI到localhost上的 Quixote进程。
Memcache
• •
从上线起就在使用，有效减轻MySQL负担 对libmemcache做了python封装（使用Pyrex），性能是 纯python版的3x+
•
提高内存利用效率
将全文搜索移至Sphinx
Internet Sphinx MySQL Master
Replicate SCGI HTTP Proxy
Web Service
store.farm
Lighttpd App Memcache Lighttpd (w/ mod_memcache)
WebDAV
store.farmr Replicate
Lighttpd
HTTP Proxy WebDAV Web Service
Lighttpd (w/ mod_memcache) MySQL Slave Memcache Static Files !"#$% read MySQL Slave
Replicate
Static Files
Memcache
MySQL
几点发现
• 数据库的内存分配对性能影响重大 • innodb_buffer_pool_size • 磁盘随机寻道速度比吞吐量更重要 • 网上找来的IP段分布很不靠谱
问题出现
• 1.5M动态请求/天，尚未到性能瓶颈 • 机房不靠谱，频繁故障 • IP段分布数据不靠谱，用户反映访问缓慢
•
mod_rewrite保持URL不变
独立的图片lighttpd进程，启用mod_memcache模块， 缓存小图片
• • • •
减小磁盘IO对页面访问的影响 把更多的内存分配给静态文件服务
将应用服务从web服务器独立出去 增加一个只读数据库
Internet App
SCGI store.farm
MySQL Master Memcache
一台作为应用服务器，一台作为数据库服务器 迁移到双线双IP机，使用DNS解析不同网段 IP -_-b 开始多人协作开发，frodo做为开发用机 (subversion, trac, etc...)
Internet
Lighttpd (#$)
SCGI HTTP Proxy
DNS
App
FS
Lighttpd (!")
• •
当进程占用内存超过阈值，当前请求完成后自杀 使用spread聚合日志
Internet
Lighttpd
SCGI HTTP Proxy
Lighttpd
HTTP Proxy spread
App
Memcache
Lighttpd
HTTP Proxy
Log Aggregator
spread
Lighttpd
豆瓣网技术架构的 发展历程
2009.4 洪强宁 hongqn@
豆瓣网简介
• • • •
2005年3月上线 以分享和发现为 核心的社区 读书、电影、音 乐、小组、同 城、九点 我的豆瓣、友邻
一些数据
• 2.9M注册用户，约1/4活跃用户 • 千万级非注册用户 • 23M动态请求/天，峰值500~600/sec • 23台普通PC服务器(1U*15/2U*8) • 12台提供线上服务 • 38G memcached
解决方案
• 数据库分库 • 九点相关表独立出来 • 数据挖掘相关表独立出来，主库放在
天津，北京只读
• Sphinx -> Xapian • 使用MogileFS
!" Master
replicate replicate
%&'() #$ Master
Replicate
MySQL Slave
问题出现
• 2M动态请求/天 • 静态文件服务磁盘IO成为瓶颈 • 上百万的小图片（用户头像、封面图
片, etc...）
• 数据库服务器接近瓶颈
解决方案
• • •
购买三台服务器，双核，4G，250G SATA*3 将图片从一个大目录切分成10000个文件一个目录
write
Lighttpd WebDAV
Spiders
Data Mining
只读数据库
• •
store增加farmr属性，为一个可用的只读数据库游标 头疼的replicate delay问题
• • • •
辅库复制需要时间 更新主库后，下一个请求往往就是要读数据（更新数据后刷 新页面） 从辅库读会导致cache里存放的是旧数据
• 应用服务器进程数不够了 • 机柜空间不够了
解决方案
•
天津的机房便宜一些 :)
• • •
• • • • •
承担图片流量 后台数据挖掘计算 容灾备份
购买3台1U服务器：4核，32G内存，1T SATA * 3 优化前端，启用 和 域名 lighttpd 1.5 with aio support 部署LVS
• /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)
解决方案
• 换到靠谱的机房，多线单IP(BGP) • 购买了一台新服务器 (arwen) • 74G 1w转 SATA * 3 • 做为数据库服务器 • 开始使用专门的服务器作后台计算
Internet
Lighttpd
SCGI write
Data Mining
read
App MySQL Master Static Files Memcache
Gentoo Linux
• 容易维护 • emerge mysql • ebuild 便于管理 patch • 只安装需要的东西 • 安全性 • GLSA(Gentoo Linux Security Advisories)