Flickr构架 | iJohn.org
25th
一月 2008

Flickr构架
爱因万江斯坦@2008年01月25日 22:36 Post in 系统构架 评论 »

相关资料:
http://www.bytebot.net/blog/archives/2007/04/25/federation-at-flickr-a-tour-of-the-flickr-architecture
http://www.niallkennedy.com/blog/uploads/flickr_php.pdf
http://qcon.infoq.com/sanfrancisco/file?path=/QConSF2007/slides/public/IanFlint_YahooCommunitiesArchitecture.pdf
http://gocom.primeton.com/modules/newbb/item43643_43643.htm
还推荐一本fickr的资深构架师 Cal Henderson 的大作《Building Scalable Web Sites

截止到2007年11月13日,Flickr 用户上传的图片已经达到20亿,Flickr必须每天处理海量更新的图片,还有不断增加的用户,竟然还能不断发布新的功能,同时也保持着良好的应用性能。从Cal Henderson 的书中,我能感觉Flickr的成功是与他们坚实的技术和构架密不可分的。

flickr-4
平台
ok,先来看看他们的平台:
PHP
MySQL
Shards (这是个新名词,还是叫”碎片”吧,”指的是将应用的数据横向拆分,也就是说如果有几千万的用户信息,那么这些用户信息可以被分布在多个数据库服务器上“)
用Memcached做缓存layer
对Html和图片用squid反向代理
RedHat Linux
Java,Perl,用Pear处理xml和email
Apache
ImageMagick ,SystemImager ,Ganglia(分布式监控程序),Subcon(用于管理和发布集群机器的配置文件),Cvsup(用于在网络中分发和更新文件)

flickr-2

数据库  

dualtree中心数据库中存储像user这样的表,但只存储它们里的主键id和具体应该指向哪个分布数据库的指向信息。每个 Shard存储40W的用户数据,大多数数据会存储两次,比如,一个评论的发表,它是介于被评论对象和发起评论对象之间的数据,这种数据,flickr会存储两次,通过事务来同步执行:打开第一个事务(transaction),写数据,打开第二个事务,写数据;如果两个事务都正常执行了,则第一个事务提交(commit),如果第一个事务提交成功,则第二个事务提交。这个流程,如果遇到服务器down机,其实还是有可能出现只提交了一次的情况。

Flickr的搜索功能有两个结果返回来源,一个是Flickr自身的Shards机器,另一个是Yahoo的web搜索,用户自己的tag搜索走的是Flickr自己的Shards方式,其它的就是走的Yahoo的web搜索了,这个改进肯定是在被Yahoo收购之后的事了。

看资料,Flickr的服务器确实够强:EMT64 w/RHEL4, 16G的内存,6块15K RPM硬盘组成的RAID-10盘阵(羡慕…)。用户数据目前有12TB,当然这不包括图片,图片内容比这点数据要多的去了。都是2U的机器,每个数据库shard存有120G的数据,也就是说Flickr有10台数据库shard机器。

 

flickr-3

 

 

 数据备份

Flickr这种提供图片服务的web2.0网站,数据尤其重要,所以他的备份工作显的格外重要:
采用定时任务,从各个数据库shard机器中非并行的备数据(也就是避免同时开始备份任务),当然也有热备份。每天晚上会扫描数据库集群生成快照(Snapshots),Flickr给出的经验中告诫,备份数据时,不要在删除(写入)大文件的时候立即进行写(删除)操作,这会损害性能。

图片是以文件的形式存储。一旦文件上传,应用服务会生成几种不同的size文件,完成之后,这些图片信息和图片的指向信息就被存进数据库。汇集数据也相当快,因为是在各自的shard上并行执行,10台shard并行响应速度可想而知。每个shard的最大连接数的是400个每秒,或者是设置成每个服务器+其相应的shard共 800个连接。最大45线程,因为目前还不会出现有超过45个用户同时并发的情况。

Tag标签

Tag是web2.0的特征,但tag不适合用传统的关系数据库来描述,Denormalization(反向规格化)和缓存是解决生成大量tag以控制在毫秒级的唯一方法 (Cal Henderson 的结论),为了实现毫秒级的大量tag生成,flickr的数据增加了一倍;还要写额外的程序去产生这些资料,而且还有额外的程序来保证数据间的一致性。可见高性能是和离复杂度分不开的。

他们的一些数据视图是后台离线计算的,把结果存储到MySQL中。因为其中有一些关系很复杂的运算,他们采取了利用服务器空闲的cpu来执行这些耗资源的程序。这可又是一复杂的处理。

另外,Flickr还实现了业务连贯性计划(Business Continuity Planning),以保证业务的不间断,让所有的数据都及时能写到数据层(db,memcache等),不会有服务挂起的情况。这个涉及到具体的业务流程了,但应该也属于构架很重要的一部分,但关于这方面的资料Flickr透露的还太少,可以因为这个太涉及业务流程了吧。

总结
我在这里只是总结了Flickr构架的整体概念,他们本身的发展历程就是一个很好的学习素材。我相信任何一个做web2.0的有志人士,都不会是想只停留在一个原始的无序阶段,无论您的模式怎样,最终都得有一个好的构架来支撑。好的构架就好比肥沃的土壤,业内各种乱飞的模式也只是一个个的种子而以。我曾听一个朋友提到过当年联众怎么没有独霸国内的在线小游戏市场的事,我想和他当年土壤很有关系吧。

      (图片来源于前面提到的资源中ppt截图)

Leave a Reply