Flickr存儲150億張圖片架構系統之Tripod揭秘

Flickr是著名的在線圖片和短視頻分享的社交網站，它於2005年3月被Yahoo! 以3500萬美金收購。

Flickr的圖片和視頻存儲系統被稱為『Tripod』，對這些多媒體數據進行處理，存儲，管理及提供查詢檢索。Yahoo的技術團隊在傳統網站架構上做了延伸，目前已採用微服務這一流行架構理念，敬請瀏覽。

最初的LAMP架構

Flickr最開始的架構為經典的LAMP平台。

它是從一台伺服器起步的，即Apache/PHP和MySQL是運行在同一台伺服器上。很快MySQL伺服器就獨立出來，成了雙伺服器架構。

隨著用戶和訪問量的快速增長，MySQL資料庫開始承受越來越大的壓力，成為應用瓶頸，導致網站應用響應速度變慢。

Flickr的邏輯架構

一般來說，資料庫的擴展無外是兩條路，Scale-Up和Scale-Out。Scale-Up，簡單的說就是在同一台機器內增加CPU、內存等硬體來增加資料庫系統的處理能力，一般不需要修改應用程序;Scale-Out,就是我們通常所說的資料庫集群方式，即通過增加運行資料庫伺服器的數量來提高系統整體的能力，而應用程序則一般需要進行相應的修改。分別使用了：

PHP

Flickr運行在Redhat Linux上，Web伺服器使用Apache，Flickr網站大約有6萬行PHP代碼;它沒有使用Session, 應用是無狀態stateless,便於擴展，避免PHP故障所帶來的Session失效。

每個P訪問。

MySQL集群

MySQL使用了master-slave結構，各位都知道存在」single point of failure」(單點故障問題)，且只對讀操作有好處。master輪詢，保證同時只有一個master負責寫，從頁解決了單點故障的問題。

Shards

使用Memcached 作為中間緩存層;

使用Squid 作反向代理伺服器(反向代理HTML和圖片)。

Smarty 模板

PHP的一種半編譯模板語言，相當於PHP靜態頁面化。

Perl

用Perl做系統管理，比如日誌分析等。

PEAR

PHP外部優質庫，做XML和Email解析。

ImageMagick

圖像處理，後來轉移到Graphics Magick，處理速度提升了15%。

Java 作為節點服務

Apache SystemImager 作為伺服器部署

Ganglia 布式系統監控

Subcon 用SVN維護伺服器配置文件並且可以部署不同的配置文件到伺服器集群中去。

Cvsup 用做文件分發、更新。

Wackamole前端負載均衡。

Pair of ServerIron』s 做負載均衡方案 。

Flickr物理架構

雙主資料庫集群(Dual Tree Central Database)

- MySQL 資料庫，存放用戶表，記錄的信息是用戶主鍵以及此用戶對以的資料庫Shard區，從中心用戶表中查出用戶數據所在位置，然後直接從目標Shard中取出數據。

- 「Dual Tree」架構是」Master-Master」和「Master-Slave」的有效結合，雙Master 避免了「單點故障」，Master-Slave又提高了讀取速度，因為用戶表的操作90%以上是讀。

雙主集群(Master-master shards)

- MySQL 資料庫，存儲實際的用戶數據和照片的元數據(Meta Data)，每個Shard 大約40萬個用戶，120GB 數據。每個用戶的所有數據存放在同一個shard中。

- Shard中的每一個server的負載只是其可最大負載的50%，這樣在需要的時候可以Online停掉一半的server進行升級或維護而不影響系統性能。

- 為了避免跨Shard查詢所帶來的性能影響，一些數據有在不同的Shard有兩份拷貝，比如用戶對照片的評論，通過事務來保證其同步。

Memcached集群

用來做中間層緩存伺服器，主要是緩存資料庫的SQL查詢等。

大數據搜索引擎

– 複製部分Shard數據(Owner』s single tag)到Search Engine Farm以響應實時的全文檢索。

– 其他全文檢索請求使用了Yahoo的搜索引擎處理。

存儲管理

運行在私有的，適用于海量文件存儲的Flickr 文件。

用了Net App公司的文件NAS存儲設備，用於存儲圖片。其伺服器的硬體配置如下：

– Intel或AMD 64位CPU，16GB 內存

– 6-硬碟 15K RPM RAID-10.

– 2U 伺服器.

伺服器總體數量和角色如下：

166台 資料庫伺服器,244台 Web 伺服器(未包括 Squid), 14台 Memcached 伺服器。

使用System Imager/System Configurator 自動化安裝、軟體分發使用Subcon作為配置管理工具提高部署效率。

使用Ganglia 來進行容量數據的展現。Ganglia主要的優點是管理方便，是Client/Server 結構, 各自跑 Demon 進行數據交互(XML形式)。相比 Cacti + Collectd 需要進行很多手工配置，更加方便。

Flickr技術團隊很強調可測量(measurement)的重要性，對benchmark不甚關心。

無論是對開源軟體比如Cassandra的benchmark，或是自己開發的進程的性能測試，都與上線後運營的負載差異太大，以致對容量規劃幾乎沒幫助。基本上需要在灰度發布後根據實際應用負載才能做靠譜的規劃。

隨著網站的快速發展技術團隊並沒有增加大量人手，個人生產力的產出是相當的高。如何做到的呢，有如下四個非常有趣的原則：

機器自動構建 (Teach machines to buildthemselves)

機器自監控(Teach machines to watch themselves)

機器自修復(Teach machines to fix themselves)

流程減少 MTTR (Reduce MTTR by streamlining)

在自動構建上，Flickr 還使用了OpsCode 、Puppet 以及 System Imager/Configurator 等工具。

Flickr第一代網站架構全圖

可以說，這個網站架構時至今日仍值得我們關注和學習。

Tripot之新架構

Tripot 近日在雅虎郵箱引入了一個功能，允許自動同步手機照片到雅虎郵件，以便用戶在寫電子郵件的時候可以隨時引用照片。也提供了一個很好的機會，把 Flickr 功能帶到Yahoo其它的網站產品。

Tripod 三大服務包括：

存儲及轉碼服務(Pixel Service) ：用於上傳，存儲，調整大小，修改照片和視頻。

增強服務(Enrichment Service) ：用於圖像識別演算法完善媒體元數據。例如，演算法可以識別和標記場景，動作和對象。

聚合服務(Aggregation Service) ：用於應用程序和跨應用程序元數據聚合，過濾和搜索。

這三種服務的組合使得 Tripod 成為新一代圖片服務平台。還有一個管理控制台，用於配置應用程序與Tripod的集成，以及身份服務，用於身份驗證和授權。

Tripod新架構圖

Pixel服務

Flickr 具有高可擴展性的圖片上傳和轉碼等流水線。

在大規模處理海量照片和視頻的情況下，Flickr 的移動和API團隊對技術進行了大量調優，比如斷點上傳和防重機制，以便創建高品質的照片上傳體驗。解決了優化存儲而不影響照片質量的挑戰，並添加了動態調整大小，以支持不同的客戶端圖片布局功能。

目前，Flickr 可以支持每秒上傳超過 500 張+圖片，這一系列流水線包括了 PHP 上傳介面，後端 Java 服務(圖片監控，主存儲)，美國西部和東部海岸的上傳熱點，以及五個全球圖片緩存節點以及大量的 CDN 。

Enrichment Service

2013 年，Flickr 開始了開始了更令人興奮的前進，Yahoo!收購了計算機視覺技術公司 IQ Engines 和 LookFlow，並將這些團隊轉到 Flickr。使用這些圖像識別演算法，增強了 Flickr 搜索和 Flickr Magic View。

The Aggregation Service

Aggregation 服務允許應用程序(如Yahoo Mail)根據任何條件查找媒體。例如，它可以返回屬於特定地址中的特定人的所有照片(例如，2015年3月1日之前的舊金山)

API和 SDK

每類服務合并為一組 API。Flicker升級了 API 技術棧，從 PHP 切換到 Spring MVC，並利用最新 Spring 特性，例如 Spring Data，Spring Boot 和 Spring Security 以及 OAuth 2.0。使用 Swagger ( http://swagger.io /) 定義和記錄 Tripod 的 API。每個服務都是從獨立的 Git 存儲庫獨立地開發和部署的，具有獨立的構建生命周期和微服務容器。

Tripod API

Swagger 編輯器可以根據 Yahoo 開發人員的需要，輕鬆自動生成各種語言的 SDK。iOS 和 Android SDK 是移動開發最常用的，JS SDK 是 Web 常用的,通過 SDK 可以實現移動及 Web 端輕鬆與 Tripod 集成。 Buckets and API Keys

Tripod 數據模型與 Flickr 數據模型不盡相同。Tripod 應用程序，存儲桶和 API 加入了多租戶的概念，具有強大的訪問控制能力。應用程序是 Tripod 服務的使用方，如 Yahoo Mail;存儲桶是應用程序存儲的邏輯容器，應用程序中的媒體(media)受到存儲桶設置(例如壓縮率，容量，TTL 生存時間以及其他選項)的影響。

除了 Tripod 的通用屬性，存儲桶還可以由應用開發人員自定義組織屬性。由 API key 控制對存儲桶的讀取/寫入許可權，生成的 OAuth 令牌對存儲桶進行認證訪問。

開發人員使用 Tripod 控制台，可以：

創建存儲桶和 API key

定義每個 API key 的存儲桶設置和訪問控制規則

與 Flickr API 的另一個不同的是 Tripod 可以處理非用戶生成的內容(UGC)的媒體——這是許多 Yahoo 應用所要求的。 架構和實現

從單一架構到微服務架構面臨很大挑戰。特別是需要在服務之間找到合適的通信方式，其核心是我們的 Pulsar 事件匯流排，通過匯流排發送 Avro 消息。這讓每個 Tripod 團隊迅速開發，而不會引發不兼容的修改。

對於 Enrichment 服務，Flickr廣泛使用了 Storm 和 HBase 進行實時處理 Tripod 視覺演算法。最後還使用了 PIG，Oozie 和 Hive 在Yahoo!基礎大數據平台上運行大量的計算任務。

在2017 年，Tripod 新架構將布署在 Flickr 系統 50%以上，Tripod 將支撐更多Yahoo應用的多媒體內容引用，為移動和PC版10億以上用戶提供堅實服務。

編譯：21CTO社區

原文： https://yahooeng.tumblr.com/po ... tored