本文介紹的 SmugMug 是一家提供付費圖片託管服務的站點，在 2002 年由 Chris MacAskill 與 Don MacAskill 父子二人創建，最初提供面向遊戲的視頻服務，隨後轉型爲現在的模式。網站流量現在是全球 1800 多，盈利能力自稱良好。
在 MySQL Conf 2009 上，SmugMug 的 Don MacAskill 做了一次關於SmugMug 網站架構 的分享。
SmugMug 整個網站採用 LAMP 架構(其實也有 OpenSolaris)，300 多臺 4 核（或更多）的服務器（大多是 AMD 的 CPU） ，分散在四個機房，兩個運營的人員。SmugMug 充分運用了雲計算服務，是 Amazon 的一個大客戶，圖片和視頻總計達到了 PB 級，託管在 Amazon S3 上，圖片和視頻的處理也在 Amazon EC2 上。使用了 Akamai 的服務做前端的 CDN 加速，主要是 JavaScript/CSS 等文件的加速，此外，DNS 加速也帶來了很好的收益。
結構化數據放在 MySQL 中，存儲引擎多數用的 InnoDB，數據超過 2TB 的空間，數據庫服務器爲 4 核或更高配置，內存多達 64GB。緩存方面，用了 Memcached 做加速，有 1TB 的數據在這裏面，平均命中率達到 96%。Memcached 裏面儘量存放 MySQL 行數據，減小對 DB 的衝擊。數據庫設計思路是儘量做垂直分區，沒有 Sharding。不過在反範式(denormalized)方面做得比較徹底，不用表連接(JOIN)方法者複雜的查詢。多數查詢依賴主鍵，更新或者刪除數據也是單行，依賴主鍵。InnoDB 引擎打了 Percona 的 Patch，併發能力也有了很大增強。
對 DB 的數據完整性與寫能力的要求高，而對於讀的擴展性還是相對比較好解決。Linux 上的文件系統是 SmugMug 不太滿意的地方，備份也成問題。ZFS 倒是能滿足相關的需求，可惜不支持 Linux(媽的，早該支持 Linux了)。所以他們遷移到了 OpenSolaris 上。另外，對於複製中可能出現的風險，嘗試了第三方提供的一些 Patch (參考 Google 發佈的 MySQL Patch )。
採用 OpenSolaris 後，MySQL 放在 Sun Sushi Toro(Storage 7410 ，這個東西也支持 SSD ) 上，走 NFSv3 協議。寫到這裏，發現 SmugMug 的解決方案非常不具有通用行，看起來 Sun 是給了他們不小的硬件優惠，否則一般情況下不會有人這麼搞的，用 NFS 協議走數據庫，除非是測試環境或者是複製(我懷疑只是 Slave 端通過 NFS 走)，產品上真的有人跑麼?
網站架構的進化，其實也是選定一個方向(比如用開源工具解決)，然後一直試錯的過程。
--EOF --