讓我們來看看現在學習的產物：Flickr 和LAMP

　　最近其實發現了不少可以和大家一起學習的好內容。Flickr 的 John Allspaw 在 MySQL Conf 2007 作了一個題為 Capacity planning for LAMP (下載PDF文件) 的技術報告，說起容量規劃，多少有點空對空的意思，不過這個 PPT 還是介紹了不少 Flickr 的網站運維經驗。

　　Flickr 的數據量的確越來越驚人了，根據文檔中透漏的數據：

　　Squid Cache 中共有 3500 萬張圖片;

　　在 Squid RAM 中有 200 萬張圖片;

　　4.7億的圖片，每張圖片有4到5種尺寸;

　　每秒鐘 38000 個到 memcached 的請求;

　　2 PB 裸存儲容量(周日需要消耗1.5T 的空間)

　　三個主要步驟：

　　計劃

　　基于實際業務，而不是抽象的理論。John Allspaw 認為基準測試(Benchmark) 作用并不大，這一點我也很贊同。在業務頻繁變化的環境中，Benchmark 根本不能與實際業務情況匹配。

　　部署

　　Flickr 使用SystemImager/SystemConfigurator(自動化安裝、軟件分發)，CVSup(網絡中的文件分發、更新)，Subcon(配置管理工具)提高部署效率。

　　度量(圖形化展現)

　　Flickr 使用了 Ganglia 來進行容量數據的展現。Ganglia 最初設計是用于高性能集群計算的監控上面，也是以 RRDTool 為基礎來進行圖形展示。Ganglia 最主要的優點還是管理的方便性: Client/Server 結構, 各自跑 Demon 進行數據交互(XML形式)。相比起來， Cacti + Collectd 需要進行很多手工配置，在面對大量需要監控的主機的時候的確不那么方便。

　　Web 2.0 站點的運維似乎大家都在摸索著走。期望這次阿里巴巴組織的俠客行大會上也有有朋友坐下來聊聊這個話題(Flickr 的架構師本來可以來的，因為時間的問題不能成行，挺遺憾的)。

通過文章，我們學習到了不少關于LAMP和Flickr方面的知識，希望大家喜歡！

【編輯推薦】

1. Redhat Linux AS4下的LAMP與Discuz裝置
2. lamp solutions
3. LAMP的安裝和配置講解
4. node.js、MongoDB下一代的LAMP
5. 確保安全使用LAMP開源開發工具的四步曲
6. Linux將繼續留在LAMP中
7. 當開源LAMP遭遇WindowsAMP