[互联网]Flickr 网站架构研究.doc

Flickr 网站架构研究 原文出处： HYPERLINK /thread/2357486 /thread/2357486 西电鲁丁 一、引言 F 是网上最受欢迎的照片共享网站之一，还记得那位给Windows Vista拍摄壁纸的Hamad Darwish吗？他就是将照片上传到Flickr，后而被微软看中成为Vista壁纸御用摄影师。 F 是最初由位于温哥华的Ludicorp公司开发设计并于2004年2月正式发布的，由于大量应用了WEB 2.0技术，注重用户体验，使得其迅速获得了大量的用户，2007年11月，Flickr迎来了第20亿张照片，一年后，这个数字就达到了30亿，并且还在以加速度增长。 2005年3月，雅虎公司以3千500万美元收购了Ludicorp公司和F。虽然Flickr并不是最大的照片共享网站（Facebook以超过100亿张照片排名第一），但这笔收购仍然被认为是WEB 2.0浪潮中最精明的收购，因为仅仅一年后，Google就以16亿美元的高价收购了YouTube，而2007年10月，微软斥资2.4亿美元收购Facebook 1.6%股份，此举使Facebook估值高达150亿美元。估计Ludicorp公司的创始人Stewart Butterfield和Caterina Fake夫妇现在还在后悔吧。 在2005年温哥华PHP协会的简报以及随后的一系列会议上，Flickr的架构师Cal Henderson公开了大部分Flickr所使用的后台技术，使得我们能有机会来分享和研究其在构建可扩展Web站点的经验。本文大部分资料来自互联网和自己的一点点心得，欢迎大家参与讨论，要是能够起到抛砖引玉的作用，本人将不胜荣幸。 Flickr的用户模型图 二、Flickr 网站架构综述 在讨论Flickr 网站架构之前，让我们先来看一组统计数据（数据来源：April 2007 MySQL Conf and Expo和Flickr网站） 每天多达40亿次的查询请求 squid总计约有3500万张照片（硬盘+内存） squid内存中约有200万张照片 总计有大约4.7亿张照片，每张图片又生成不同尺寸大小的4－5份图片 每秒38,000次Memcached请求 (Memcached总共存储了1200万对象) 超过2 PB 存储，其中数据库12TB 每天新增图片超过 40万（周日峰值超过200万，约1.5TB) 超过8百50万注册用户 超过1千万的唯一标签（tags) 你如果觉得这些过时的数据都已经很惊人了，那么让我们来看看Cal Henderson在2008年9月的一次会议上公布的另一组数据，在短短的一秒钟内： 响应4万个照片??问请求 处理10万个缓存操作 运行13万个数据库查询 下面是Flickr的网站架构图： Pair of ServerIrons － Load Balancer Squid Caches － 反向代理，用于缓存静态的HTML和照片 Net App － NetApp 公司的Filer, NAS存储设备，用于存储照片 PHP App Servers － 运行REDHAT LINUX,Apache上的PHP应用，Flickr网站的主体是大约6万行PHP代码 － 没有使用PHP session, 应用是stateless,便于扩展，并避免PHP Server故障所带来的Session失效。 － 每个页面有大约27～35个查询（不知道为什么这么设计，个人觉得没有必要） － 另有专门的Apache Web Farm 服务于静态文件（HTML和照片）的访问 Storage Manager － 运行私有的，适用于海量文件存储的Flickr File System Dual Tree Central Database － MySQL 数据库，存放用户表，记录的信息是用户主键以及此用户对以的数据库Shard区，从中心用户表中查出用户数据所在位置，然后直接从目标Shard中取出数据。 － “Dual Tree架构是”Master－Master和“Master-Slave的有效结合，双Master 避免了“单点故障”，Master－Slave又提高了读取速度，因为用户表的操作90％以上是读。 Master-master shards － MySQL 数据库，存储实际的用户数据和照片的元数据（Meta Data)，每个Shard 大约40万个用户，120GB 数据。每个用户的所有数据存放在同一个shard中。 － Shard中的每一个server的负载只是其可最大负载的50％，这样在需要的时候可以Online停掉一半的server进行升级或维护而不影响系统性能。 － 为了避免跨Shard查询所带来的性能影响，一些数