Fotolog（傳說比 Flickr 更大）在 21 台伺服器部署 51 個 Memcached 實例，共 254GB 快取空間，快取 175GB 內容。本文整理其核心架構策略：資料庫分片、前端快取層、Master-Slave 讀寫分離、為何捨棄 MySQL Query Cache。
核心架構三支柱
1. 資料庫分片解決寫入擴展
- 依業務領域拆分資料庫到不同伺服器
- 避免單一 Master 寫入瓶頸與單點故障
- 盡可能將不相關業務拆分為獨立服務
2. 前端 Memcached 叢集解決讀取擴展
- 應用程式優先從 Memcached 取資料
- 未命中 → 查 MySQL → 回寫 Memcached
- 理想比例：95% Memcached、3% MySQL Query Cache、2% 實際查表
3. MySQL Master-Slave 讀寫分離
- Master 負責寫入，多 Slave 負責讀取
- 應用程式讀操作導向 Slave
為什麼不直接用 MySQL Query Cache？
| 缺點 | 說明 |
|---|
| 單一實例 | 受限單機記憶體，無法水平擴展 |
| 寫入即失效 | 任何寫入（甚至無關資料列）都會清空相關快取 |
| 僅快取資料列 | 無法快取物件、陣列、計算結果、檔案等應用層資料 |
✅ Memcached：分散式、任意物件序列化、寫入不影響快取（需應用層主動失效/更新）。
實戰關鍵策略
- 快取鍵設計：
table:pk、query:hash，含版本號或時間戳支援失效
- 一致性處理：寫入 DB 成功後，先刪快取再更新 DB 或 更新 DB 後刪快取（雙重刪除更保險）
- 熱點保護：對極熱資料設定永不過期，由應用層主動更新
- 單機替代方案：單機環境用 APC、XCache、OPcache 效能優於 Memcached
架構演進建議
- 單機 → 本地快取
- 多機 → Memcached 叢集
- 讀多寫少 → Master-Slave + 讀寫分離
- 寫入瓶頸 → 資料庫分片
- 極大流量 → 分庫分表 + 多級快取（本地 + 分散式）
💡 核心心法：快取是效能加速器，不是資料來源。資料庫永遠是真相來源。
