Flickr是我個人喜愛的網(wǎng)站之一，也是互聯(lián)網(wǎng)上最主要的圖片共享網(wǎng)站。Flickr網(wǎng)站后臺有許多非常復(fù)雜的問題需要處理，它們需要處理海量的新增的內(nèi)容，管理大批的用戶，不斷保持新的功能特征，與此同時，還要提供一流的性能。它們是如何做到的呢？
??? Flickr網(wǎng)站的網(wǎng)址是：http://www.flickr.com/

參考文獻
Flickr and PHP（一個早期的文檔）
LAMP容量規(guī)劃
Flickr聯(lián)盟：Flickr網(wǎng)站體系結(jié)構(gòu)指南
來自Flickr網(wǎng)站工程師Cal Henderson所寫的文章：如何構(gòu)建可伸縮web站點
Cal Henderson的談話記錄，在許多幻燈片中陳述對一些web技術(shù)的看法

平臺
PHP
MySQL
Shards
Memcached高速緩沖層
Squid反向代理（reverse-proxy）
Linux（紅帽子）操作系統(tǒng)
Smarty模板
Perl腳本語言
使用PEAR進行XML和Email分析
ImageMagick圖像處理
Java節(jié)點服務(wù)程序
Apache服務(wù)器
SystemImager部署
Ganglia分布式監(jiān)控系統(tǒng)
Subcon存儲系統(tǒng)配置文件
使用Cvsup來分布和更新文件集
下面附上Flicker站點系統(tǒng)構(gòu)架
1

?

統(tǒng)計情況
每天超過4百萬請求
Squid高速緩存中大約35M的照片
Squid RAM中大約2M照片
memcached每秒38k個請求（12M）
2 PB原始數(shù)據(jù)存儲器（在星期天消耗大約1.5TB）
每天增加400,000張照片以上

系統(tǒng)結(jié)構(gòu)
??? 關(guān)于Flickr站點體系結(jié)構(gòu)的一組圖像化的展示，如圖一所示，更多關(guān)于Flickr站點體系結(jié)構(gòu)的描述，你可以在這個頁面查到。進行簡單的描述就是：
—一對ServerIron
—Squid Caches
—Net應(yīng)用程序
—PHP應(yīng)用程序服務(wù)器
—存儲管理器
—Master-master碎片
—雙樹形中心數(shù)據(jù)庫
—Memcached Cluster
—大型搜索引擎

??? 雙重樹形系統(tǒng)結(jié)構(gòu)是一項對MySQL常規(guī)配置，通過增加masters，而不是環(huán)形體系結(jié)構(gòu)來增加伸縮性。比起需要兩倍硬件的master-master安裝來說，這種方式你只需要較少的硬件，因此節(jié)約了提高網(wǎng)站伸縮性的費用。

?系統(tǒng)結(jié)構(gòu)中的中心數(shù)據(jù)庫包括想用戶表這樣的數(shù)據(jù)，這個表包括主要的用戶信息，主鍵，和指向用戶相關(guān)的數(shù)據(jù)。
對于靜態(tài)內(nèi)容使用的專門服務(wù)器
研究如何支持Unicode
不要使用共用的結(jié)構(gòu)系統(tǒng)
所有的東西（除了照片）都要存在數(shù)據(jù)庫中
創(chuàng)建一個搜索農(nóng)場（search farm），復(fù)制部分需要進行搜索的數(shù)據(jù)庫
使用橫尺度，保證更多所必需的的機器
分析每封郵件，處理用戶通過郵件發(fā)送的圖片。
早期曾經(jīng)遭受Master-Slave延遲。太多負載會有出現(xiàn)單點故障
保證網(wǎng)站一直開通，不斷修復(fù)數(shù)據(jù)等等，不要讓網(wǎng)站關(guān)閉
進行好的容量規(guī)劃。獲取更多的信息查看文章前面部分的參考文獻。
使用統(tǒng)一的方法以便為了以后進行伸縮擴展
碎片：我的一些數(shù)據(jù)存儲在我擁有的磁盤碎片上，但是進行對你的一些評論，存儲在你的碎片空間上。如當(dāng)你對其它人的博客進行評論的時候，這種情況就會發(fā)生。
Global Ring:像DNS，你需要知道頁面往哪里鏈接，誰來控制方向。每一個頁面的瀏覽，都要計算當(dāng)前你的數(shù)據(jù)在哪里。

PHP 邏輯來連接那些碎片空間，保持數(shù)據(jù)的一致性（帶注釋的10行代碼）

碎片
—主要數(shù)據(jù)庫的一個小部分
—活動的Master-Master Ring Replication：MySQL 4.1中的小缺點，而在Master-Master—確是光環(huán)。ID自動增加能保持有效。

對于新的用戶，碎片的分配是一個隨機數(shù)。

??? 遷移是時不時要發(fā)生的，因此你可以刪除一些用戶。當(dāng)有很多的照片的時候，你需要均衡。192,000張照片，700,000標簽的遷移需要大約3-4分鐘。遷移時人工完成的。

移出Cache中的照片擁有帳戶，給他們分配一個碎片空間地址。從cache中移出我的信息，將它們加到我的碎片地址中去。

??? 如果當(dāng)前主機宕機，訪問列表中的下一個主句，如果所有的主機宕機，顯示一個錯誤頁面。他們不會使用持久性連接。每一個頁面加載，都要測試連接。

??? 每個用戶的讀寫都放在一個碎片中。不存在什么復(fù)制延遲的事情。

??? 平均請求每個頁面，用到 27-35 SQL語句。API訪問數(shù)據(jù)庫都是實時的。完成實時處理需求

??? 每秒超過3600個請求，在容量極限范圍之內(nèi)。在高峰期爆發(fā)時，會達到兩個36000每秒的請求數(shù)。

每個碎片能持有400K以上的數(shù)據(jù)

??? 許多數(shù)據(jù)存儲了兩次。舉個例子，一個評論關(guān)系到評論者和被評論者。評論存儲在什么地方？是不是在兩個地方都存儲了?事務(wù)處理機制用來阻止同步數(shù)據(jù)：打開事務(wù)1，寫入一些命令，打開事務(wù)2，寫入一些命令，提交第一個事物后，如果第一個提交，再提交第二個事務(wù)。但是這還有存在失敗的可能性，可能提交了兩次。

硬件：
- EMT64 w/RHEL4, 16GB RAM
- 6-disk 15K RPM RAID-10.
- 2U 邏輯單元。每個碎片空間存儲~120GB數(shù)據(jù)

備份過程：
??? 每天晚上對整個數(shù)據(jù)庫集群進行快照
??? 當(dāng)在進行復(fù)制備份文件時，在復(fù)制文件存儲中一次寫入或者刪除幾個大的備份文件會損害性能。對圖片存儲文件進行這種操作時非常壞的主意。

??? 雖然將你所有的數(shù)據(jù)進行備份很多天使非常耗費資源的，但是這么做是值得的。保持錯列的備份時很有用的，特別是當(dāng)你在幾天后發(fā)現(xiàn)出現(xiàn)問題的時候。你可以做1，2，10，30天的備份。

??? 圖片是存儲在文件夾中。當(dāng)你上傳的時候，會處理圖片，供給你不同的尺寸選擇。元數(shù)據(jù)和指向文件夾的路徑會保存在數(shù)據(jù)庫中。
??? 每個shard max_connections = 40的連接數(shù)，或者每個server & shard加起來等于800的連接數(shù)。線程高速緩沖器設(shè)置為45，因為你不會有超過45個用戶同時在活動。

標簽
??? 對于傳統(tǒng)的關(guān)系型數(shù)據(jù)庫管理系統(tǒng)設(shè)計，標簽是不太適合的。方向規(guī)格化或者重型高速緩沖器是唯一的方法來生成標簽，一毫秒能產(chǎn)生上百萬的標簽。

未來的方向：
??? 使用實時BCP，能夠運行的更快，因此所有的數(shù)據(jù)中心一直都能夠接受寫入信息。所有的資源都是使用中的，沒有一個將會在空閑。

學(xué)到的經(jīng)驗：
??? 不僅僅把你的應(yīng)用程序看作一個web應(yīng)用程序。你將會有使用到REST APIs,、SOAP APIs、 RSS feeds、 Atom feeds等；

?? 無界限化。無界限化能夠讓你的系統(tǒng)更加魯棒，毫無顧慮的進行升級。

?? 高速緩存。盡量高速緩存和RAM來響應(yīng)每個請求

??? 抽象化。在數(shù)據(jù)庫，業(yè)務(wù)邏輯，頁面邏輯，頁面標簽，和表現(xiàn)層之間創(chuàng)建很清晰的抽象層次。在迭代開發(fā)中將會很靈活好用。?
??? 分層。分層設(shè)計能夠讓開發(fā)者處理業(yè)務(wù)邏輯，而設(shè)計者能夠進行用戶體驗頁面設(shè)計。設(shè)計者還能在需要時請求頁面邏輯。這兩層之間有一個很好的協(xié)商。

??? 釋放頻率。每30分鐘一次。

??? 忽略微小性能改善，不成熟的優(yōu)化將災(zāi)難的根源。

??? 應(yīng)用程序測試。要能輕松的在你的應(yīng)用程序體系結(jié)構(gòu)機制（如設(shè)置標簽，負載均衡等）中插入或者移除新的硬件。

??? 忘記基準。對于獲得容量的一般觀念設(shè)置一個基準是很好的，但是，對于規(guī)劃來說，設(shè)置基準并不好，人工測試會提供一個測試結(jié)果，對真實情況進行一個測試會是一個更好的方法。
確定最高限額

每個服務(wù)器能夠達到的最大極限服務(wù)是多少？

每個服務(wù)器接近到最大極限有多近？這個趨勢又是怎么樣的？MySQL（disk IO）情況又是怎樣的？SQUID (disk IO 或者 CPU )的情況又是怎樣的呢？memcached(CPU 或者 network )情況又是如何的？

對用戶的使用規(guī)律要敏感

??? 與上一年的第一個工作日相比，Flickr網(wǎng)站在今年的第一個工作日會增加20-40%的負載每周日平均要比這一周其它天增加40-50%負載 。對用戶指數(shù)級的增張要求敏感。更多的用戶意味著更多的內(nèi)容，更多的內(nèi)容意味著更多的連接，更多的連接意味著更多的請求。

負載高峰備用。要有能夠處理高峰負載的計劃

原文的url ： http://highscalability.com/flickr-architecture

總結(jié)

以上是生活随笔為你收集整理的大型网站架构:Flickr网站体系结构分析（转）的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。