# 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.