- 浏览: 1578712 次
- 性别:
- 来自: 北京
文章分类
最新评论
-
nich002:
原网站失效了。撸主简单粗暴的复制过来,可读性极差!差评!
Apache配置详解(最好的APACHE配置教程) -
107x:
不错,谢谢!
LINUX下查看文件夹下的文件个数! -
Hypereo:
好你妹,连个格式都没有!
Apache配置详解(最好的APACHE配置教程) -
resteater:
代码排版感觉有点乱!收发信息代码可读性不强!请问第一次发服务器 ...
java socket例子 -
resteater:
代码排版感觉有点乱!收发信息代码可读性不强!请问第一次发服务器 ...
java socket例子
From: http://www.cyask.com/question.php?qid=432
Flickr(http://www.flickr.com/)
是国外一个领先的图片分享网站,现在应该在yahoo门下,感觉yahoo还是有很多好东西,奈何资本要抛弃他了。这个轮回其实挺有意思的,起先是做实业
被microsoft郁闷了,说软件是虚的值不能那么多钱,然后microsoft被yahoo郁闷了,说互联网是虚的不值那么多钱,然后是yahoo被
google郁闷了,yahoo比较厚道没说什么,现在microsoft要收购yahoo了(折腾好久了,估计要落听了吧),不知道google将来要
被谁郁闷了。成功建立在相同的失败上,反过来失败都是建立在相同的成功上也成立,进入正题吧。
原文地址是http://highscalability.com/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/
常见的Squid反向代理、PHP App Servers、Net App’s、Storage Manager我在这里就不讲,我们关注一些让人兴奋的特征:
- Mysql的Master-Master结构,mysql的常见的master-slave结构,大家都知道存在”single point of failure”(单点故障的问题),且只对读操作有好处,对于写频繁的网站却不是一个好的解决方案,Flickr的双master方案据我推测用的就是 这个http://code.google.com/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张表呢?需要手工迁移数据,如果程序写的不好,底层 又要大动了。
Flickr采用的方案是一个中心’users’ table(用户表),记录的信息是用户主键以及此用户对以的数据库片区(有点类似Key->Value的设计,这样的数据结构查询起来是非常迅速 的,据说Google的用户登录数据用的就是这样的设计,通过改进版的BDB数据库存储用户名和密码,这样登录起来就不用去查那个大表了),从中心用户表 中查出用户数据所在位置,然后直接从目标位置中取出数据。
- 不要预先去为性能扩展,出现问题之后找到问题再寻扩展;
- 不要想寻找到一个一劳永逸的方案,因为你不知道下一个瓶颈在哪里;
- 访问量大了,出了问题,修改架构,稳定运行,访问量再大了,又出问题了,再修改,这个是解决问题的唯一方案。
- “Statelessness”设计,原文用的是这个词,字面上的意思是“无国家的”,看了一些相关文档,我觉得Statelessness的含 义是“无界限的”设计,一个简单的例子,现在很多架构设计用到分表,比如用户信息表,怎么分呢?直接hash分表,两张表就按奇偶分,n张表就按n的模进 行分,这种设计就是Statelessness的反向,你把你的用户绑定在一张固定的表或者固定的机器上了,如果你的用户里面有付费用户,你希望把他们的 数据单独存储或者用专门的机器处理,你怎么办?你设计的太死了,你的付费用户只能和免费用户绑定在一起,提供一样的服务器支持,当然,你可以骗用户说他们 的服务是有差别的。
- 通过master-save的设计能解决一部分问题,但很快你就会发现不行了,常见的master-slave只能解决读的问题,但存在单点失败故障,而且当负载比较重的时候会存在复制延迟的问题,很多公司都会碰到。
- 搜索功能由专门的服务器群来支持,通过复制需要搜索的内容到搜索服务器去搜索,和App servers分开。
集群
1、分表:按照一定主键拆分数据表,比如按照用户划分;
2、一个用户的所有信息在同一组服务器上
3、数据能够在不同的服务器组上迁移(Statelessness)
4、一组中心服务器负责查询,比如定位某个用户在哪个服务器组
5、不要以用户ID作为分组的依据(Non-Statelessness)
Todd Hoff总结的经验:
- 不要把你的应用简单的看成一个Web应用,可能会有REST APIs, SOAP APIs, RSS feeds, Atom feeds等等的应用
- “无界限”设计,不要把你的用户死死的绑定在某个服务器上
- 产品设计时需要做扩容的计划以及预算
- 慢慢来,不要一开始就买一堆服务器
- 实地考察,不要臆想,获得实际数据之后再做决定
- 内建日志系统,记录服务器和应用日志
- Cache,缓存是必不可少的
- 抽象层,由于你的架构随时可能变,架构的变化必定要带来底层的变化,这就需要你在底层的基础上根据业务封装一层中间层,这样底层的改动不至于影响业务(这个太重要了,不要因为扩展把原来的程序推倒重来)
- 迭代开发,随时改进
- 忘记那些调优的小技巧吧,比如很多人对与PHP里面的require和require_once的性能差别,这些性能的差异和架构上的短板比起来根本不足为道
- 在线上测试你的效果
- 忘记用工具测试出来的结果,这些结果只能给你一个大概的印象而已
- 找出你的系统短板,一台服务器的最大处理能力是多少?现在离最大负载还有多远?mysql的瓶颈在哪里?是不是磁盘IO?memcache的瓶颈在哪里?CPU还是网络传输?
- 注意你的用户使用规律,比如Flickr发现每年的第一个工作日比平时多20%~40%的上传量,周日的访问量比平时要多40%~50%
- 要注意指数型的增长
- 你的计划是为你访问的峰值设计的
Flickr如何存储图片的呢?
标准的Flickr图片Url是这样的http://farm1.static.flickr.com /104/301293250_dc284905d0_m.jpg,其中farm1是Flickr的服务器群,static.flickr.com是 Flickr静态图片服务器,104是服务器ID,301293250是图片ID,dc284905d0是Flickr的加密串,防止盗链,m表示图片的 尺寸。m表示中等尺寸
后记:
终于“翻译”(姑且用这个词)完了,看到原文的一个评论是”Hmm… i can not beleive flickr written on php…”,借用好像也是Flickr的人说的一句话:扩展的不是语言,而是架构。国内很多大的企业都在用PHP(比如我所在的sina),PHP总给人 是草根语言的感觉,是因为没有人肯分享自己的架构,以及程序员写程序的时候不注意自己的结构(设计模式),好的架构只能让你的程序跑的更快,好的结构让你 的程序更易于维护,更容易让别人看的懂,更容易团队合作。
发表评论
-
JVM问题追查与调优
2012-03-27 14:44 1149JDK的几种分析工具 http://liudaoru ... -
NodeJs相关资料
2011-08-18 14:55 3020NodeJs获取参数: proces ... -
jprofiler追踪问题
2011-08-12 18:20 1052Jprofiler下载页: http://www.ej ... -
Linux服务器性能评估与优化【z】
2011-07-01 10:05 1557来自:http://www.itlearner.com/ ... -
Java 理论与实践: 非阻塞算法简介【z】
2011-03-26 20:39 1288From: http://www.ibm.com/develo ... -
Java Crash问题分析[z]
2011-03-23 14:41 5978参考: http://www.ibm.com/develop ... -
Berkeley DB相关
2010-09-25 22:17 1061为什么要使用Berkeley DB,它适合什么场合应用?Ber ... -
熟悉系统方法总结
2010-07-06 14:26 824了解一个陌生的系统是我们经常碰到的事情,下面总结一下自己的一些 ... -
Java缓存框架 EhCache
2010-07-06 14:09 4734From: http://www.oschina.net/p/ ... -
【nio】使用 ServerSocketChannel 实现的 File 服务器[z]
2010-05-21 17:31 3977From: http://www.java2000.net/p ... -
Memcached命令行管理
2010-03-15 11:18 4495From: http://www.exp2up.com/2 ... -
(转)Resin服务器配置指南
2010-01-21 15:35 3470From:http://blog.21cn.com/super ... -
JDK的几种分析工具
2009-12-04 12:13 10909From: http://blog.csdn.net/hant ... -
XMemcached——一个新的开源Java memcached客户端
2009-10-23 09:27 1899From: http://www.infoq.com/cn/ ... -
多线程任务调度学习
2009-10-16 13:58 2308昨天找到一套多线程任务调度的代码,相当的不错,先把思路总结一下 ... -
用HSCALE实现MySQL的数据分布式存储
2009-10-15 12:47 3023From:http://www.ningoo.net/ht ... -
马化腾:搜索、电子商务硬仗一定要坚持打
2009-10-15 12:09 1724From:http://www.techweb.com.c ... -
MySQL分表实现上百万上千万记录分布存储的批量查询设计模式【z】
2009-10-15 09:56 3179From:http://hi.baidu.com/jabber ... -
nginx负载均衡和lvs负载均衡的比较分析【z】
2009-10-13 20:02 1478From:http://www.shouker.com/u ... -
新型的大型bbs架构(squid+nginx)【z】
2009-10-13 19:53 1630From:http://www.fovweb.com/opti ...
相关推荐
标题:"flickr架构" 描述了flickr系统架构的关键组件与设计原则,为读者提供了深入理解这一著名照片分享平台背后的复杂技术体系的机会。 flickr,作为互联网早期的照片分享平台之一,其架构设计不仅支撑了海量用户...
【Flickr架构】是互联网上最著名的照片分享网站之一,其背后的设计和实施是一个复杂的分布式系统,旨在处理海量的照片、用户以及不断增长的流量和功能。以下是对Flickr架构的详细解析: 1. **基础架构** - **操作...
前Flickr员工Mikhail Panchenko在 Strange Loop 2010会议上分享了Flickr架构的演变过程,虽然没有深入技术细节,但他提出了对PHP代码质量的关注,以及对NoSQL技术的见解。他认为,选择数据库技术时,理解需求、监控...
本文档不仅涵盖了Flickr架构和API的基本背景,还深入探讨了Flickr协议的具体细节,并提供了一个紧凑型的照片上传DLL,该DLL在UIQ3和S60第3版之间具有良好的可移植性。 #### 二、Flickr简介 ##### 2.1 Flicker架构 ...
亿万用户网站MySpace的成功秘密、Flickr架构、YouTube网站架构、PlentyOfFish 网站架构学习、WikiPedia技术架构学习笔记。这几个都很典型,我们可以从中获取很多有关网站架构方面的知识,看了之后你会发现你原来的...
大型网站架构flickr网站体系
Flickr API是基于REST(Representational State Transfer)架构,使用HTTP协议进行通信,主要通过XML或JSON格式返回数据。开发者可以通过调用不同的API端点,获取图片信息、用户信息、相册信息等。在.Net环境下,...
常见的模型架构如基于循环神经网络(RNN)的模型,如Seq2Seq(序列到序列)模型,或者结合注意力机制的Transformer模型。 6. **模型训练与评估**:在训练模型时,会将这些数据集分为训练集、验证集和测试集。模型在...
Flickr 架构经验是指使用Flickr的架构经验。 Twitter 运维经验是指使用Twitter的运维经验。 运维经验是指分布式系统的运维经验。 Metrics是指分布式系统的性能Metrics。 配置管理是指分布式系统的配置管理。 ...
Flickr架构经验 Flickr等社交媒体平台使用NoSQL数据库来存储和管理大量的图像、视频等多媒体数据。 ##### 4. Twitter运维经验 Twitter等社交平台利用NoSQL数据库处理实时流数据,实现了高并发下的数据处理。 ####...
- **5.3 Flickr架构经验**:描述了Flickr如何使用NoSQL数据库来支持其图片存储服务。 - **5.4 Twitter运维经验**: - **运维经验**:Twitter在运维过程中积累的最佳实践。 - **代码协同经验**:代码协同过程中遇到...
- **Flickr架构经验**:图片分享网站在大数据处理方面的实践。 - **Twitter运维经验**:社交媒体平台在数据处理与实时分析方面的挑战与应对策略。 #### 运维经验 - **Metrics**:监控系统性能指标的重要性。 - **...
7. **Web应用程序架构**:此工具可能采用客户端-服务器架构,前端负责用户交互,后端处理与Flickr API的通信。 综上所述,这个工具结合了前端开发技术、Flickr服务的集成、以及可能的Flash技术,为用户提供了一个...
Flickr架构经验** - 分享了Flickr在图片存储和检索方面的架构实践。 **4. Twitter运维经验** - **Metrics**: 监控系统性能指标。 - **配置管理**: 系统配置的自动化管理。 - **Dark Mode**: 系统的灰度发布机制...
- **Flickr架构经验**:利用NoSQL数据库存储用户上传的照片元数据。 - **Twitter运维经验**:NoSQL数据库帮助Twitter处理海量的微博消息。 #### 六、总结与展望 NoSQL数据库的发展不仅改变了我们处理大规模数据的...
Flickr的系统架构可以分为以下几个主要部分: 1. **页面逻辑(Page Logic)**:处理用户请求的前端部分,包括页面渲染等。 2. **应用逻辑(Application Logic)**:处理业务逻辑的核心部分,例如认证、权限管理等。 3. ...
本文是关于如何利用Python编程语言来实现针对Flickr图片网站的爬虫程序的详细介绍和实现步骤。Flickr作为雅虎旗下的图片分享网站,拥有大量的高质量图片资源,是一个研究爬虫技术的理想对象。 爬虫技术是数据抓取的...