Flickr是我個人喜愛的網站之一，也是互聯網上最主要的圖片共享網站。Flickr網站后臺有許多非常復雜的問題需要處理，它們需要處理海量的新增的內容，管理大批的用戶，不斷保持新的功能特征，與此同時，還要提供一流的性能。它們是如何做到的呢？ ??? Flickr網站的網址是： http://www.flickr.com/ 參考文獻 Flickr and PHP（一個早期的文檔） LAMP容量規劃 Flickr聯盟：Flickr網站體系結構指南 來自Flickr網站工程師Cal Henderson所寫的文章：如何構建可伸縮web站點 Cal Henderson的談話記錄，在許多幻燈片中陳述對一些web技術的看法 平臺 PHP MySQL Shards Memcached高速緩沖層 Squid反向代理（reverse-proxy） Linux（紅帽子）操作系統 Smarty模板 Perl腳本語言 使用PEAR進行XML和Email分析 ImageMagick圖像處理 Java節點服務程序 Apache服務器 SystemImager部署 Ganglia分布式監控系統 Subcon存儲系統配置文件 使用Cvsup來分布和更新文件集 下面附上Flicker站點系統構架 1 統計情況 每天超過4百萬請求 Squid高速緩存中大約35M的照片 Squid RAM中大約2M照片 memcached每秒38k個請求（12M） 2 PB原始數據存儲器（在星期天消耗大約1.5TB） 每天增加400,000張照片以上 系統結構 ??? 關于Flickr站點體系結構的一組圖像化的展示，如圖一所示，更多關于Flickr站點體系結構的描述，你可以在這個頁面查到。進行簡單的描述就是： —一對ServerIron —Squid Caches —Net應用程序 —PHP應用程序服務器 —存儲管理器 —Master-master碎片 —雙樹形中心數據庫 —Memcached Cluster —大型搜索引擎 ??? 雙重樹形系統結構是一項對MySQL常規配置，通過增加masters，而不是環形體系結構來增加伸縮性。比起需要兩倍硬件的master-master安裝來說，這種方式你只需要較少的硬件，因此節約了提高網站伸縮性的費用。 ?系統結構中的中心數據庫包括想用戶表這樣的數據，這個表包括主要的用戶信息，主鍵，和指向用戶相關的數據。 對于靜態內容使用的專門服務器 研究如何支持Unicode 不要使用共用的結構系統 所有的東西（除了照片）都要存在數據庫中 創建一個搜索農場（search farm），復制部分需要進行搜索的數據庫 使用橫尺度，保證更多所必需的的機器 分析每封郵件，處理用戶通過郵件發送的圖片。 早期曾經遭受Master-Slave延遲。太多負載會有出現單點故障 保證網站一直開通，不斷修復數據等等，不要讓網站關閉 進行好的容量規劃。獲取更多的信息查看文章前面部分的參考文獻。 使用統一的方法以便為了以后進行伸縮擴展 碎片：我的一些數據存儲在我擁有的磁盤碎片上，但是進行對你的一些評論，存儲在你的碎片空間上。如當你對其它人的博客進行評論的時候，這種情況就會發生。 Global Ring:像DNS，你需要知道頁面往哪里鏈接，誰來控制方向。每一個頁面的瀏覽，都要計算當前你的數據在哪里。 PHP 邏輯來連接那些碎片空間，保持數據的一致性（帶注釋的10行代碼） 碎片 —主要數據庫的一個小部分 —活動的Master-Master Ring Replication：MySQL 4.1中的小缺點，而在Master-Master—確是光環。ID自動增加能保持有效。 對于新的用戶，碎片的分配是一個隨機數。 ??? 遷移是時不時要發生的，因此你可以刪除一些用戶。當有很多的照片的時候，你需要均衡。192,000張照片，700,000標簽的遷移需要大約3-4分鐘。遷移時人工完成的。 移出Cache中的照片擁有帳戶，給他們分配一個碎片空間地址。從cache中移出我的信息，將它們加到我的碎片地址中去。 ??? 如果當前主機宕機，訪問列表中的下一個主句，如果所有的主機宕機，顯示一個錯誤頁面。他們不會使用持久性連接。每一個頁面加載，都要測試連接。 ??? 每個用戶的讀寫都放在一個碎片中。不存在什么復制延遲的事情。 ??? 平均請求每個頁面，用到 27-35 SQL語句。API訪問數據庫都是實時的。完成實時處理需求 ??? 每秒超過3600個請求，在容量極限范圍之內。在高峰期爆發時，會達到兩個36000每秒的請求數。 每個碎片能持有400K以上的數據 ??? 許多數據存儲了兩次。舉個例子，一個評論關系到評論者和被評論者。評論存儲在什么地方？是不是在兩個地方都存儲了?事務處理機制用來阻止同步數據：打開事務1，寫入一些命令，打開事務2，寫入一些命令，提交第一個事物后，如果第一個提交，再提交第二個事務。但是這還有存在失敗的可能性，可能提交了兩次。 硬件： - EMT64 w/RHEL4, 16GB RAM - 6-disk 15K RPM RAID-10. - 2U 邏輯單元。每個碎片空間存儲~120GB數據 備份過程： ??? 每天晚上對整個數據庫集群進行快照 ??? 當在進行復制備份文件時，在復制文件存儲中一次寫入或者刪除幾個大的備份文件會損害性能。對圖片存儲文件進行這種操作時非常壞的主意。 ??? 雖然將你所有的數據進行備份很多天使非常耗費資源的，但是這么做是值得的。保持錯列的備份時很有用的，特別是當你在幾天后發現出現問題的時候。你可以做1，2，10，30天的備份。 ??? 圖片是存儲在文件夾中。當你上傳的時候，會處理圖片，供給你不同的尺寸選擇。元數據和指向文件夾的路徑會保存在數據庫中。 ??? 每個shard max_connections = 40的連接數，或者每個server & shard加起來等于800的連接數。線程高速緩沖器設置為45，因為你不會有超過45個用戶同時在活動。 標簽 ??? 對于傳統的關系型數據庫管理系統設計，標簽是不太適合的。方向規格化或者重型高速緩沖器是唯一的方法來生成標簽，一毫秒能產生上百萬的標簽。 未來的方向： ??? 使用實時BCP，能夠運行的更快，因此所有的數據中心一直都能夠接受寫入信息。所有的資源都是使用中的，沒有一個將會在空閑。 學到的經驗： ??? 不僅僅把你的應用程序看作一個web應用程序。你將會有使用到REST APIs,、SOAP APIs、 RSS feeds、 Atom feeds等； ?? 無界限化。無界限化能夠讓你的系統更加魯棒，毫無顧慮的進行升級。 ?? 高速緩存。盡量高速緩存和RAM來響應每個請求 ??? 抽象化。在數據庫，業務邏輯，頁面邏輯，頁面標簽，和表現層之間創建很清晰的抽象層次。在迭代開發中將會很靈活好用。? ??? 分層。分層設計能夠讓開發者處理業務邏輯，而設計者能夠進行用戶體驗頁面設計。設計者還能在需要時請求頁面邏輯。這兩層之間有一個很好的協商。 ??? 釋放頻率。每30分鐘一次。 ??? 忽略微小性能改善，不成熟的優化將災難的根源。 ??? 應用程序測試。要能輕松的在你的應用程序體系結構機制（如設置標簽，負載均衡等）中插入或者移除新的硬件。 ??? 忘記基準。對于獲得容量的一般觀念設置一個基準是很好的，但是，對于規劃來說，設置基準并不好，人工測試會提供一個測試結果，對真實情況進行一個測試會是一個更好的方法。 確定最高限額 每個服務器能夠達到的最大極限服務是多少？ 每個服務器接近到最大極限有多近？這個趨勢又是怎么樣的？MySQL（disk IO）情況又是怎樣的？SQUID (disk IO 或者 CPU )的情況又是怎樣的呢？memcached(CPU 或者 network )情況又是如何的？ 對用戶的使用規律要敏感 ??? 與上一年的第一個工作日相比，Flickr網站在今年的第一個工作日會增加20-40%的負載每周日平均要比這一周其它天增加40-50%負載 。對用戶指數級的增張要求敏感。更多的用戶意味著更多的內容，更多的內容意味著更多的連接，更多的連接意味著更多的請求。 負載高峰備用。要有能夠處理高峰負載的計劃

總結

以上是生活随笔為你收集整理的Flickr网站体系结构分析的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。