Flickr架构免费下载.docVIP

Flickr(/)是国外一个领先的图片分享网站，现在应该在yahoo门下，感觉yahoo还是有很多好东西，奈何资本要抛弃他了。这个轮回其实挺有意思的，起先是做实业被microsoft郁闷了，说软件是虚的值不能那么多钱，然后microsoft被yahoo郁闷了，说互联网是虚的不值那么多钱，然后是yahoo被google郁闷了，yahoo比较厚道没说什么，现在microsoft要收购yahoo了（折腾好久了，估计要落听了吧），不知道google将来要被谁郁闷了。成功建立在相同的失败上，反过来失败都是建立在相同的成功上也成立，进入正题吧。 原文地址是/flickr-architecture，本文不是原文的严谨翻译，带有我的理解以及补充，由于水平有限，文中的错误请各位斧正。Flickr处理的数据： 多达40亿次的请求（http request or database query?不知道了，不管是哪个，都够大的吧。） squid总计约有3500万张图片（硬盘+内存） squid内存中约有200万张图片 总计有大约4亿7000万张图片，每张图片大概4~5MB 每秒3,8000次请求 (存储了1200万对象在里面) 2 PB 存储(星期天要消费~1.5TB) 每天新增图片超过 400,000 吓死人不偿命…. Flickr用到的技术： PHP MySQL Shards Memcached 作为中间缓存层，memcached在web2.0网站中可能是引用最广泛的产品之一，开源强大. Squid 作反向代理服务器(reverse-proxy for html and images). Linux (RedHat),如果你想用RedHat企业版又不想付费，试试这个CentOS，基本上100%克隆RedHat企业版（估计传说中1%的RedHat代码没有），我用的就是这个。 Smarty 作为模板解析，很多人在讨论smarty这不好那不好，但是大网站都在用，稳定而且功能强大，系统的瓶颈从来不会再smarty这里，我保证。 Perl 估计用perl做一些系统层面的东西吧，比如日志处理（猜测） PEAR 做XML和Email解析，和我们一样，Flickr用的也是PHP4，不过新项目还是用PHP5吧 ImageMagick 图像处理的不二选择 Java, for the node service，Java就不太了解了，希望读者补充 Apache 大家都在用，尝鲜的用户nginx或者lighttpd（适合静态文件，youtube用它做媒体文件服务器），出了问题你会抓狂的。 SystemImager 作为服务器部署 Ganglia 分布式系统监控，或者你可以试试nagios，据我所知也很多公司在用 Subcon 用SVN维护服务器配置文件并且可以部署不同的配置文件到服务器集群中去（这个我没用过，系统运维的可能会喜欢） Cvsup 文件分发，是否类似rsync? Wackamole前端负载均衡，类似的产品有http://haproxy.1wt.eu/ Flickr架构 常见的Squid反向代理、PHP App Servers、Net App’s、Storage Manager我在这里就不讲，我们关注一些让人兴奋的特征: Mysql的Master-Master结构，mysql的常见的master-slave结构，大家都知道存在”single point of failure”(单点故障的问题)，且只对读操作有好处，对于写频繁的网站却不是一个好的解决方案，Flickr的双master方案据我推测用的就是这个/p/mysql-master-master/，原理就是master轮询，保证同时只有一个master负责写，解决了单点故障的问题。 ?Dual Tree Structure，看看下面的图就知道什么是“双树结构”(姑且这么翻译)示例图中上方的2台机器为master，下方的4台为slave，这种“双树结构”的设计保证一个slave只有一台master，易于扩展也不会形成环路。原文中说这种设计是1＋1＝200％的设计，简单高效。为了防止自增长冲突，数据表中无自增长列。补充：对于大型应用的分表设计，防止自增长冲突是个问题，有个简单的方案：比如分3张表，可以设第一张表从1开始以3跳跃递增，那么第一张表存储的序列为1，4，7，10……，第二张表从2开始也以3跳跃递增，第二张表存储的序列为2，5，8，11……，第三张表从3开始以3跳跃递增，第三张表存储的序列为3，6，9，12……，保证不会有重复的序号，但这种方案的缺点是如果数据爆炸，3张表不够，你分4张表呢？需要手工迁移数据，如果程序写的不好，底层又要大动了。Flic