# Flickr 架构 > 原文： [http://highscalability.com/blog/2007/11/13/flickr-architecture.html](http://highscalability.com/blog/2007/11/13/flickr-architecture.html) **更新：** Flickr 击中[提供了 20 亿张照片](http://www.webware.com/8301-1_109-9816461-2.htm)。 那是很多汉堡包。 Flickr 既是我最喜欢的[鸟](http://www.birds.cornell.edu/AllAboutBirds/BirdGuide/Northern_Flicker.html)，也是网络上领先的照片共享网站。 Flickr 面临着巨大的挑战，他们必须处理浩如烟海的内容，包括不断扩展的新内容，不断增长的用户群以及不断涌现的新功能，同时还要提供出色的性能。 他们是如何做到的呢？ 网站：http：//www.flickr.com ## 信息来源 * [Flickr 和 PHP](http://www.niallkennedy.com/blog/uploads/flickr_php.pdf) （早期文档）* [LAMP](http://www.kitchensoap.com/talks/MySQLConf2007-Capacity.pdf) 的容量规划* [Flickr 的联合会：每天进行数十亿次查询](http://mysqldba.blogspot.com/2008/04/mysql-uc-2007-presentation-file.html)，作者 Dathan Pattishall。* [构建可扩展网站](http://www.amazon.com/Building-Scalable-Web-Sites-Applications/dp/0596102356)，来自 Flickr 的 Cal Henderson。* [数据库战争故事＃3：Flickr [Tim O'Reilly]](http://radar.oreilly.com/2006/04/database-war-stories-3-flickr.html)* [Cal Henderson 的演讲](http://www.iamcal.com/talks/)。 很多有用的 PowerPoint 演示文稿。 ## 平台 * 的 PHP* 的 MySQL* 碎片* Memcached 用于缓存层。* 乌贼在反向代理为 HTML 和图像。* Linux（RedHat）* 聪明的模板* 佩尔* 用于 XML 和电子邮件解析的 PEAR* ImageMagick，用于图像处理* Java，用于节点服务* 阿帕奇* 用于部署的 SystemImager* Ganglia 用于分布式系统监控* Subcon 将重要的系统配置文件存储在 Subversion 存储库中，以便轻松部署到群集中的计算机上。* Cvsup for distributing and updating collections of files across a network. ## 统计资料 * 每天超过 40 亿个查询。* 鱿鱼缓存中约有 3500 万张照片（总计）* 鱿鱼的 RAM 中有约 200 万张照片* 约 470M 张照片，每张 4 或 5 个尺寸* 38k req / sec 到 memcached（1200 万个对象）* 2 PB 原始存储（周日消耗约 1.5 TB* 每天要添加超过 40 万张照片 ## 架构 * 在此[幻灯片](http://www.slideshare.net/techdude/scalable-web-architectures-common-patterns-and-approaches/138)上可以找到 Flickr 架构的漂亮图片。 一个简单的描述是： -ServerIron 的 ---- Squid 缓存对 ------ Net App 的 ---- PHP App Server ---- -存储管理器 ------主-主分片 ------双树中央数据库 ------内存缓存群集 ------ 大型搜索引擎 -双树结构是对 MySQL 的一组自定义更改，它允许通过增量添加没有环体系结构的母版进行缩放。 这样可以进行更便宜的扩展，因为与主-主设置相比，您需要的硬件更少，而主-主设置始终需要两倍的硬件。 -中央数据库包含“用户”表之类的数据，该数据包括主用户 键（一些不同的 ID）以及可以在其上找到用户数据的指针。 * 使用专用服务器获取静态内容。* 讨论如何支持 Unicode。* 使用无共享架构。* 一切（照片除外）都存储在数据库中。* 无状态意味着他们可以在服务器周围弹跳人，并且更容易制作他们的 API。* 首先通过复制进行扩展，但这仅有助于读取。* 通过复制他们要搜索的数据库部分来创建搜索服务器场。* 使用水平缩放，因此他们只需要添加更多计算机即可。* 通过解析每封电子邮件（用 PHP 交付）来处理从用户发送的图片。 电子邮件被解析为任何照片。* 早些时候他们遭受了奴隶主的滞后。 负载太多，它们只有一个故障点。* 他们需要能够进行实时维护，修复数据等功能，而又不会导致站点停机。* 关于容量规划的许多优秀资料。 请查看信息源以获取更多详细信息。* 采取联合方法，以便它们可以扩展到更远的将来： -分片：我的数据存储在我的分片上，但是对您的评论执行操作的记录却在您的分片上。 在他人的博客 -Global Ring 上发表评论时，就像 DNS 一样，您需要知道该去哪里，以及谁来控制您的去向。 在每个页面视图中，计算当时的数据位置。 -用于连接至分片并保持数据一致的 PHP 逻辑（带有注释的 10 行代码！）* 碎片： -主数据库的一部分 -主动主-主环复制：MySQL 4.1 中的一些缺点，因为尊重主-主中的提交。 AutoIncrement ID 自动执行，以使其保持活动状态。 -分片分配来自新帐户的随机数。 -迁移会不时进行，因此您可以删除某些超级用户。 如果您有很多照片，则需要平衡…192,000 张照片，700,000 个标签将花费大约 3-4 分钟。 迁移是手动完成的。* 单击收藏夹： -从缓存中提取照片所有者帐户，以获取分片位置（例如，在分片 5 上） -从缓存中提取我的信息，以获取我的分片位置（例如，在分片 13 上） -开始“分布式交易”-回答以下问题：谁收藏了照片？ 我最喜欢什么？* 可以从任何分片提问，并恢复数据。 它绝对多余。* 要消除复制滞后… -每个页面加载，都会为用户分配一个存储桶 -如果主机关闭，请转到列表中的下一个主机； 如果所有主机都关闭，则显示错误页面。 他们不使用持久连接，而是建立连接并将其拆除。 这样，每个页面加载都会测试连接。* 每个用户的读写都保存在一个分片中。 复制滞后的概念消失了。* 分片中的每个服务器已加载 50％。 关闭每个分片中的 1/2 台服务器。 因此，如果该碎片中的一台服务器关闭或处于维护模式，则该碎片中的一台服务器可以承担全部负载。 要升级，您只需要关闭一半的碎片，升级一半，然后重复该过程即可。* 在流量激增的一段时间内，它们违反了 50％的规则。 他们每秒执行 6,000-7,000 个查询。 现在，其每秒最多可查询 4000 个查询，以使其保持 50％的负载。* 每页平均查询为 27-35 条 SQL 语句。 收藏夹计数是实时的。 API 对数据库的访问都是实时的。 达到了实时要求，没有任何缺点。* 每秒超过 36,000 个查询-在容量阈值内运行。 流量爆裂，两倍 36K / qps。* 每个碎片可容纳 40 万多个用户数据。 -很多数据被存储两次。 例如，评论是评论者和被评论者之间关系的一部分。 评论存储在哪里？ 两个地方怎么样？ 事务用于防止数据不同步：打开事务 1，写命令，打开事务 2，写命令，如果一切都很好，则提交第一个事务，如果第一次提交，则提交第二个事务。 但是在第一次提交期间出现故障时，仍然有失败的可能。* 搜索： -两个搜索后端：几个分片上的分片 35k qps 和 Yahoo!的（专有）网络搜索 -所有者的单个标签搜索或批量标签更改（例如，通过 Organizr） 碎片由于实时性的要求，其他一切都归 Yahoo!的引擎处理（可能比实时性差 90％） -考虑一下，这样您就可以进行类似 Lucene 的搜索* 硬件： -带 RHEL4 的 EMT64，16GB RAM -6 磁盘 15K RPM RAID-10。 -数据大小为 12 TB 用户元数据（这些不是照片，这只是 innodb ibdata 文件-这些照片要大得多）。 -2U 盒子。 每个分片都有〜120GB 的数据。* 备份过程： -在 cron 作业上进行 ibbackup，该备份在不同时间跨各种分片运行。 热备份到备用。 -快照是每晚在整个数据库集群中拍摄的。 -在一次复制复制文件存储库中一次写入或删除多个大备份文件时，由于复制备份文件，可能会在接下来的几个小时内破坏该文件存储库的性能。 对生产中的照片存储文件管理器执行此操作不是一个好主意。 -保留所有数据多天备份的成本不菲，这是值得的。 几天后发现有问题时，保留交错备份非常有用。 例如 1 天，2 天，10 天和 30 天的备份。* 照片存储在文件管理器中。 上传后，它会处理照片，为您提供不同的尺寸，然后完成。 元数据和指向文件管理器的点都存储在数据库中。* 聚合数据：非常快，因为它是每个分片的一个过程。 将其粘贴到表中，或从其他用户分片的另一个副本中恢复数据。* max_connections =每个分片 400 个连接，或每个服务器&分片 800 个连接。 大量的容量和连接。 线程缓存设置为 45，因为您同时进行活动的用户不超过 45 个。* 标签： -标签与传统的标准化 RDBM 架构设计不太匹配。 非规范化或繁重的缓存是在数毫秒内为数亿个标签生成标签云的唯一方法。 -它们的某些数据视图是由专用处理集群离线计算的，这些集群将结果保存到 MySQL 中，因为某些关系计算起来非常复杂，以至于会吸收所有数据库 CPU 周期。* 未来方向： -使用实时 BCP 使其速度更快，因此所有数据中心都可以同时接收对数据层（db，memcache 等）的写入。 一切都处于活动状态，不会有任何闲置状态。 ## 得到教训 * **不仅将您的应用程序视为 Web 应用程序**。 您将拥有 REST API，SOAP API，RSS feed，Atom feed 等。 * **进入无状态**。 无状态使系统更简单，更健壮，可以处理升级而不会退缩。 * 重新架构数据库很烂。 * **容量计划**。 尽早将容量规划纳入产品讨论中。 从$$美元的人员（和工程管理人员）那里买到值得关注的东西。 * **缓慢启动**。 不要仅仅因为害怕/高兴您的网站会爆炸而购买过多的设备。 * **测量真实度**。 容量规划数学应该基于真实事物，而不是抽象事物。 * **内置日志记录和指标**。 使用情况统计信息与服务器统计信息一样重要。 内置自定义指标，以衡量基于服务器统计信息的实际使用情况。 * **缓存**。 缓存和 RAM 是一切的答案。 * **摘要**。 在数据库工作，业务逻辑，页面逻辑，页面标记和表示层之间创建清晰的抽象层。 这支持快速完成迭代开发。 * **层**。 分层使开发人员可以创建页面级逻辑，设计人员可以使用这些逻辑来构建用户体验。 设计人员可以根据需要询问页面逻辑。 这是双方之间的谈判。 * **经常释放**。 甚至每 30 分钟一次。 * **大约 97％的时间都忘了小效率**。 过早的优化是万恶之源。 * **生产中测试**。 内置于体系结构机制（配置标志，负载平衡等）中，通过这些机制，您可以轻松地将新硬件部署到生产中（或从生产中删除）。 * **忘记基准**。 基准可以很好地了解功能，但不适用于规划。 人工测试可以提供人工结果，并且时间可以更好地用于真实测试。 * **找出上限**。 -每个服务器最多可以做些什么？ -您离该最大值有多近？趋势如何？ -MySQL（磁盘 IO？） -SQUID（磁盘 I 或 CPU？） -内存缓存（CPU？或网络？） * **对您的应用程序类型**的使用模式敏感。 -您有与事件相关的成长吗？ 例如：灾难，新闻事件。 -Flickr 在一年的第一个工作日获得的上传数量比上一年的任何前一个高峰多 20-40％。 -周日的上载次数比一周的其余时间平均多 40-50％ * **对指数增长的需求敏感**。 更多的用户意味着更多的内容，更多的内容意味着更多的连接，更多的连接意味着更多的使用。 * **计划峰**。 能够处理上下堆叠的峰值负载。 Flickr 仅在其数据库中存储对映像的引用，实际文件存储在网络上其他位置的单独存储服务器上。 Flickr 图像的典型 URL 如下所示： `[http://farm1.static.flickr.com/104/301293250_dc284905d0_m.jpg](http://farm1.static.flickr.com/104/301293250_dc284905d0_m.jpg)` 如果将其拆分，我们将得到： `farm1` -显然是图像存储所在的服务器场。 我还没有看到其他的价值。 `.static.flickr.com` -相当自我解释。 `/104` -服务器 ID 号。 `/301293250` -图像 ID。 `_dc284905d0` -图像“秘密”。 我认为这是为了防止在未首先从 API 获取信息的情况下复制图像。 `_m`-图像的尺寸。 在这种情况下，“ m”表示中等，但是可以很小，例如拇指。对于标准图像大小，URL 中没有此格式的大小。 嗨， 很棒的文章。 我想看看每个点上不同的“选项”在您面前的位置会很有趣。 然后，简短解释为什么选择某些“答案”可能会很有用。 再次感谢您的好东西... 我们将进行很多更改，以通过实时 BCP 使其更快，以便所有数据中心都可以同时接收对数据层（db，memcache 等）的写操作，即所有活动的对象都不会处于空闲状态 。 >我们将进行很多更改，以使实时 BCP 更快 很有意思，下一次进化就开始了。 我想知道您如何处理复制。 是在事务上下文中在客户端库中还是在后端服务中进行复制？ 似乎您将有一个主动-主动计划，一个人的家庭数据将驻留在哪里，以及您将如何处理来自多个数据中心的更新中的合并数据？ 数据中心是否有足够的能力来处理所有负载，以防万一发生故障？ 您将如何确定数据中心何时瘫痪以及如何在数据中心之间负载均衡流量？ 进入多个数据中心是系统复杂度的巨大飞跃。 听到您对这些问题以及您所面临的其他问题的思考会很有趣。 嗯...我不能相信写在 php 上的 flickr ... 托德- 首先-很棒的博客！ 很高兴在一个地方看到很多这样的东西。 关于 Flickr 和 BCP： BCP 的数据库部分确实很有趣。 在存储和提供照片方面，我们当然已经拥有 BCP（多个数据中心），因此我们可以为 farmX.static.flickr.com 平衡许多不同数据中心之间的流量。 干杯！ 好的通道！ 如何理解主-主环复制？ 这个结构是稳定的吗？ 谢谢 <cite>最大的图片网站？</cite> 不。 据 TechCrunch 报道，Facebook 拥有 40 亿张照片； flickr 有 20 亿美元。 每天有 40 亿个查询，并且仍在增长。 建立社区的速度比老牌收集亲朋好友的速度还要快... Flickr 真是一个奇观！ 谢谢，在幕后进行了一次有趣的窥视！ 我很高兴阅读 Flickr 使用 SystemImager 进行部署。 我是该软件的拥护者-它是简单性和功能性的完美结合。 基于 rsync 或 TFTP / DHCP 等知名工具构建。 我记得在不到一个小时的时间内从头开始安装了约 100 台服务器（为此，我们甚至没有使用 systemimager / flamethrower）。 易于安装且非常灵活（如果您有奇特的硬件，只需自行准备内核或手动修复新节点的安装脚本，SI 对此将非常满意）。 还可以看一下 GUI 监视守护程序/工具（si_monitor / si_monitortk）。 如何下载图像。 静态服务器上的 apache 吗？ 显示您对 php 的了解 每天有 40 亿个查询，并且仍在增长。 建立社区的速度比老牌收集亲朋好友的速度还要快... Flickr 真是一个奇观！ 谢谢，在幕后进行了一次有趣的窥视！ How to download the images. An apache on static servers ? 似乎将您的图像存储在数据库中可能会使站点速度变慢。 似乎将您的图像存储在其中？ shows what you know about php 毫无疑问，Flicr 的架构很棒。 只是想说，聪明人可以由 Blitz 更改，有一些比较表 [http://alexeyrybak.com/blitz/blitz_en.html](http://alexeyrybak.com/blitz/blitz_en.html) 是否有更简单的解决方案来管理数据库和文件的组合图像？ 很好 精彩 We are going to change a lot of things, to make it faster with real-time BCP, so all datacenters can receive writes to the datalayer (db, memcache, etc) all at the same time i.e. everything is active nothing will ever be idle. 本文档确实对希望建立大型站点的新手有所帮助。 显示您对 php 的了解 Flickr only store a reference to an image in their databases, the actual file is stored on a separate storage server elsewhere on the network.