跳出資料庫本身：用外部 Cache 與 Search 實現數據服務層水平擴展
本文摘自《MySQL性能調優與架構設計》第 15 章，探討當 MySQL 自身複製、分表已達極限時，如何引入 **分散式記憶體 Cache (Memcached)**、**嵌入式 KV 存儲** 與 **全文搜尋引擎** 組成綜合數據中心，將讀寫壓力從資料庫卸載，實現真正的線性擴展。
15.1 為何要跳出 MySQL 尋求擴展性？
- 資料庫核心職責：持久化 + ACID + SQL 標準介面。
- 高頻熱點資料、全文檢索、大數據分析並非關係型強項，強行在 MySQL 解決會拖垮核心交易處理。
- 策略：**核心交易留 MySQL，其他場景外掛專用組件**，形成「數據服務叢集」。
15.2 成熟第三方 Cache 方案
15.2.1 Memcached：分散式記憶體物件緩存
- 特點：協議簡單、libevent 高併發、全記憶體、BSD 開源。
- 兩種整合架構：
- 純緩存層 (應用維護同步)：應用寫 MySQL 同時寫/刪 Memcached；讀優先命中 Memcached → 回源 MySQL → 回寫緩存。適合緩存物件類型少、數據量大的場景。架構圖見原書。
- 與 MySQL 深度整合 (資料庫維護緩存)：
- Waffle Grid 方案：Patch MySQL (InnoDB)，將 Buffer Pool LRU 列表的乾淨頁外溢到 Memcached 叢集作「二級緩存」。讀取優先檢查 Remote Buffer，再讀磁碟。DBT2 測試顯示吞吐顯著提升。適合難以分表、記憶體受限的單機擴容。
- UDF 觸發同步方案：MySQL 透過 UDF 呼叫 Memcached API，寫入/更新/刪除時自動同步緩存；應用讀取優先查 Memcached。緩存鍵值模型適合單鍵查詢，不支援複雜 SQL。
15.2.2 Berkeley DB：嵌入式高效 KV 存儲庫
- 五大子系統：資料存取、事務管理、鎖管理、共享記憶體、日誌系統。可模組化啟用。
- 支援 Hash、B-Tree、Fixed/Dynamic Length 四種存儲格式，Hash 最高效。
- 整合模式：應用雙寫 (寫 MySQL + 寫 BDB) 或讀時回填；MySQL 更新時通知 BDB 失效。成本低於純記憶體 Memcached，適合預算受限但需高效點查詢的場景。
15.3 自研 Cache 服務：決策框架與避坑指南
- 前提：業務場景極度特殊，現有方案無法覆蓋 80%+ 需求。
- 功能界定：純記憶體/混合磁碟？強一致/最終一致？是否分散式？
- 技術難點：資料同步機制 (同步/異步/觸發器/雙寫)、存儲演算法、通訊協議 (簡單且可演進)。
- 可維護性：管理介面、高可用切換、監控指標。**別小看維護成本**，是項目成敗關鍵。
- 建議：優先在現有開源基礎上二次開發，而非從零造輪子。
15.4 Lucene 實現高效全文檢索
- MySQL MyISAM 全文索引不支援中文、且 5.7+ InnoDB 雖支援但效能有限。
- Lucene (Apache) 提供分詞、索引、查詢完整框架，非爬蟲型搜尋引擎，適合**結構化資料全文檢索**。
- 整合模式：應用寫入 MySQL 同步推送文檔到 Lucene 建索引；查詢走 Lucene API 回傳主鍵，再回 MySQL 取詳情。可控制實時性 (毫秒級 ~ 定時批次)。
- 百 GB 級索引在正確分片、合併策略下效能優異；效能問題多源於錯誤使用 (如未優化查詢、分詞器選型錯誤)。
- 自研 Search：技術門檻高，但可針對特定業務 (如即時推薦、地理空間) 做極致優化。
15.5 分散式並行計算框架 (MapReduce/Hadoop) 概覽
- 本質：任務分解 → 多節點並行計算 → 結果合併。
- 兩大體系：Google (MapReduce + GFS + BigTable) vs Yahoo/Hortonworks (Hadoop + HDFS + HBase)。Hadoop 源自 MapReduce 論文。
- SQL-on-Hadoop 產品：Infobright (MySQL)、Greenplum (PostgreSQL)，提供標準 SQL 介面，適合 OLAP 分析場景，無需大量開發。
15.6 小結：構建綜合數據中心
單一資料庫無法滿足所有存取模式。**MySQL (OLTP) + Memcached/BDB (高頻點查) + Lucene (全文) + Hadoop/Greenplum (OLAP)** 組合，各司其職，透過中間代理層對應用透明化，才能實現真正的高擴展、高性能、高可用數據架構。
