大型网站架构: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%負載 。對用戶指數級的增張要求敏感。更多的用戶意味著更多的內容，更多的內容意味著更多的連接，更多的連接意味著更多的請求。
負載高峰備用。要有能夠處理高峰負載的計劃
原文的url ： http://highscalability.com/flickr-architecture
總結
以上是生活随笔為你收集整理的大型网站架构:Flickr网站体系结构分析（转）的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： mtk blog --MTK Andro
- 下一篇： 用VB制作自己的IE网页浏览器