MySQL架構方案

Scale Out：橫向擴充，增加處理節點提高整體處理能力
Scale Up：縱向擴充，通過提升單個節點的處理能力達到提升整體處理能力的目的

Replication

MySQL的replication是非同步，適用於對資料即時性要求不是特別關鍵的情境。slave端的IO線程負責從master讀取日誌，SQL線程專門負責在slave端應用從master讀過來的日誌（早期MySQL用一個線程實現，效能問題比較明顯）。使用replication必須啟用binary log，MySQL用binary log向slave分發更新

複製層級
1. Row Level：5.1.5開始支援。mater記錄每行資料的變更記錄檔，slave根據日誌逐行應用。優點：資料一致性更有保障。缺點：可能造成記錄檔比較大
2. Statement Level：master記錄每個執行的query語句以及一些上下文資訊，slave節點根據這些資訊重新在slave上執行。優點：binary log比較小。缺點：某些情況下資料一致性難以保障
3. Mixed Level：MySQL根據情況選擇哪種複製方式。5.1.8開始支援

常用架構
1. Master-Slaves：通常都採用這種方式
2. Dual Master(Master-Master)：2個master節點互相同步更新。因為MySQL的非同步複製方式，為了防止資料衝突造成的不一致性，一般僅將其中一台用於寫操作，另一台不用或僅用於讀操作。目的是其中一台master停機維護或者故障中斷時可以使用另一台master
3. 級聯複製(Master-Slaves-Slaves)：在Master Slaves中，如果slaves過多replication將增加master的負載，這時可以讓master只向其中幾台slave分發更新日誌，這幾台slave作為一級節點再向下級節點分發更新日誌

Cluster

主要通過NDB Cluster儲存引擎實現，是一個Share Nothing的架構，各個MySQL Server之間並不需要共用任何資料。可以實現冗餘（可靠性）以及負載平衡。剛開始MySQL需要所有資料和索引都能夠載入到記憶體中才能使用Cluster，對記憶體要求高，目前通過改進只要求索引能全部載入到記憶體

   
                  MySQL Clusrer架構，圖片來自MySQL官方文檔
1. SQL Nodes：負責儲存層之外的事情，例如串連管理、query處理和最佳化、cache管理等，即剝離了儲存層的MySQL伺服器
2. Data Nodes：儲存層的NDB節點，即Cluster環境下的儲存引擎。每個cluster節點儲存完整資料的一個分區，視節點數目和配置而定，一般data nodes被組織成為一個個group，每個group存有一份完全相同的物理資料（冗餘）。NDB儲存引擎首先按照冗餘參數配置來使用儲存節點，然後根據節點數目對資料進行分段
3. Management Server：負責整個clsuter叢集中各個節點的管理工作，它儲存了整個cluster環境的配置，啟動關閉各個節點，實現對各節點的常規維護、備份恢複等，它擷取各個節點的狀態和錯誤資訊，並反映給整個叢集中所有節點

Cache
1. 應用程式層cache：最普通的cache方式，應用程式層自己管理cache，與資料庫無關
應用程式層cache的選擇方案很多
a). Memcached：分布式的緩衝，本身效能優秀，擴充性比較好；雖然比本機快取方案慢，但具備共用快取效果
b). Berkeley DB：與Memcached相比，BDB實現本機快取；Memcached是記憶體式的緩衝，而BDB使用磁碟，成本不一樣；Memcached僅支援hash索引，而BDB支援hash索引和B-Tree索引；MySQL資料庫方案下使用BDB，主要出於擴充性方面考慮，以及BDB的hash索引可以比MySQL更有效

2. MySQL-Memcached整合：有2種方式
a). 直接用Memcached作為MySQL的二級緩衝。這可以增加MySQL的緩衝容量，而Memcached對於應用端是不可見的。這種方案適用於一些特定情境，例如資料實在難以切分、很難對應用程式進行改造等
這種方案目前有Waffle Grid開源項目，僅支援InnoDB儲存引擎。其原理是當MySQL在Local Buffer Pool中找不到資料時則從磁碟讀取，而Waffle Grid在這裡加入一段處理，先嘗試從Memcached Server讀取，如果Memcached Server中不存在，才通過磁碟IO讀取，將讀取的資料會存入Memcached，並記錄在InnoDB Buffer Pool的LRU List中，如果資料變成dirty或者緩衝管理將其清出時，InnoDB將對應的LRU List移入FLUSH List，此時Waffle Grid從Mamcached Server刪除資料。從上面可以看出，緩衝機制仍然由MySQL管理，Memcached中存放的僅為有效（不是髒資料）、僅作為緩衝目的的資料，Memcached Server崩潰停機等不影響MySQL資料
架構（《MySQL效能調優與架構設計》）：
   
Waffle Grid是否會因為網路訪問開銷導致查詢效能下降呢？可以參考Waffle Grid DBT2的測試結果，以及實際測試進行評估

b). 使用MySQL的UDF功能與Memcached進行整合。Memcached的資料由MySQL和應用端程式共同維護，應用端先從Memcached讀取資料，讀取不到時則從MySQL Server讀取，並把資料寫入Memcached中，而資料有更新、刪除導致Memcached資料失效時，MySQL負責將Memcached中相應資料清除
架構（《MySQL效能調優與架構設計》）：
   
MySQL Memcached UDFs下載和使用參考Using the MySQL memcached UDFs

資料切分、Sharding

分為垂直切分和水平切分，垂直切包括將一個表按不同欄位切分成多個表、將不同表建在不同的MySQL Server中，水平切分指將同一個表的資料切分到多個表中儲存
1. 表結構設計垂直切分。常見的一些情境包括
a). 大欄位的垂直切分。單獨將大欄位建在另外的表中，提高基礎資料表的訪問效能，原則上在效能關鍵的應用中應當避免資料庫的大欄位
b). 按照使用用途垂直切分。例如企業物料屬性，可以按照基本屬性、銷售屬性、採購屬性、生產製造屬性、財務會計屬性等用途垂直切分
c). 按照訪問頻率垂直切分。例如電子商務、Web 2.0系統中，如果使用者屬性設定非常多，可以將基本、使用頻繁的屬性和不常用的屬性垂直切分開

2. Sharding
Sharding指一種"shared nothing"形式的垂直切割，將切割後的部分部署在不同的伺服器上。關於sharding和partition的區別可參考DBA Notes馮大輝的開來源資料庫 Sharding 技術 (Share Nothing)
    

                             圖片來自DBA Notes: http://www.dbanotes.com
Sharding方案可以考慮：
a). Session-based sharding，只需在建立session時確定處理節點，隨後的請求都直接定向到該節點進行處理
b). Statement-based sharding，每個語句都需要確定處理節點
c). Transaction-based sharding，根據事務中第一條語句確定處理節點
Sharding潛在問題：
a). 被分割開的部分之間無法使用資料庫層級的join操作（cross-shard joins，可以考慮將一些公用的、全域的表部署到每一個節點上，使用replication機制分發）
b). 被分割開的部分之間交易處理複雜
c). 對自增長鍵的管理（主要出現在混合了水平切分的Sharding情況下）

3. 水平切分
樣本：
a). 比如線上電子商務網站，訂單表資料量過大，按照年度、月度水平切分
b). Web 2.0網站註冊使用者、線上活躍使用者過多，按照使用者ID範圍等方式，將相關使用者以及該使用者緊密關聯的表做水平切分
c). 例如論壇的置頂文章，因為涉及到分頁問題，每頁都需要顯示置頂貼，這種情況可以把置頂貼水平切分開來，避免取置頂文章時從所有文章的表中讀取

痛點之一，邏輯、關聯關係的複雜性阻礙水平切分。這樣的情境難在如何確定切分的範圍和策略，例如SAP這樣的大型ERP，模組、表非常多，之間的邏輯複雜，SAP按每Client（公司、集團）將整個業務資料完全切分開，如果粒度需要再細化難度就非常大。方案一般有：a). 按主鍵切分；b). 維護一個主切割索引表，這種方案擴充性非常好，但是需要尋找主索引表
第二點是如何使得水平切分具備擴充性。以Web 2.0網站為例，如果按照會員ID範圍進行切分，假如現在決定水平切分為5份，如果使用user_id % 5的值確定該使用者屬於哪個部分，這樣在將來隨著使用者量的增長，如果以後需要再切分成為20份就會相當麻煩
水平切分和Sharding的混合模式，理論上可以實現線性伸縮，但受限於應用程式的狀況、設計以及切分、Sharding實現方案

切分和整合方案
主要2種實現思路：
1. 每個應用程式模組組態管理自己需要的一個或多個資料來源，直接存取各個資料庫
2. 通過中間代理層統一管理所有的資料來源，後端資料庫叢集架構對前端應用透明

使用MySQL Proxy：
這是MySQL官方提供的，位於用戶端程式與MySQL Server之間，能夠監控、分析、轉換他們之間的通訊。常用的情境有負載平衡、故障恢複、查詢分析、查詢過濾和修改，以及基本的HA機制，目前在實現讀寫分離方面仍存在一些問題，架構（《MySQL效能調優與架構設計》）：
   
MySQL Proxy提供一個基礎的架構，其他功能需要編寫LUA指令碼實現（犧牲一定效能，帶來靈活性）
HSCALE是MySQL Proxy的一個LUA模組，他透明的分析和重寫查詢，切分、分區邏輯從應用程式層轉移到代理層
HSCALE項目官方網站：http://www.hscale.org，作者部落格網站：http://pero.blogs.aprilmayjune.org/

使用Amoeba：
Amoeba是基於Java開發的分散式資料庫資料來源整合Proxy程式的開源架構，Amoeba 開發人員部落格，項目首頁
主要解決以下問題：
a). 資料切分後複雜資料來源整合
b). 提供資料切分規則並降低資料切分規則給資料庫帶來的影響
c). 降低資料庫與用戶端串連
d). 讀寫分離路由
Amoeba For MySQL是專門針對MySQL資料庫的方案，架構：
   
                圖片來自《MySQL效能調優與架構設計》
Amoeba For Aiadin是個更通用的方案，他前端接收MySQL協議的請求，後端可以使用MySQL、Oracle、PostGreSql等其他資料來源，這些對應用程式是透明的。架構：
   
                圖片來自《MySQL效能調優與架構設計》

使用HiveDB
HiveDB也是基於Java的開源架構，有商業公司支援，目前僅支援水平切分，同時支援資料的冗餘及基本的HA機制。他使用Hibernate Shards實現資料水平切分，自行實現資料冗餘機制。HiveDB中通過使用者自訂的各種Partition keys將資料分散到多個MySQL Server，訪問時解析query請求，自動分析過濾條件，並行從多個MySQL Server讀取資料，合并結果集返回給用戶端應用程式。架構：
   
            圖片來自HiveDB官方網站: http://www.hivedb.org/
Hibernate Shards由Google貢獻，他使用標準的Hibernate編程模型，會用Hibernate就會用Hibernate Shards；可擴充的sharding策略；支援virtual shards，用於簡化resharding時的處理

Spock Proxy
由實際項目產生的一個開源項目（Spock是Rails的應用，Speck Proxy應當可用於Rails之外的，例如PHP或.NET），基於MySQL Proxy開發，是MySQL Proxy的一個分支，支援range-based horizontal paritioning，他對MySQL Proxy所做的改進包括：
a). 不使用LUA指令碼，提升效能。例如將多個資料來源返回的結果集合并期間還要與LUA指令碼互動，這樣的效能開銷比較大
b). 用戶端登入驗證。MySQL Proxy支援用戶端與各個伺服器直接進行登入驗證，Spock Proxy則將其統一管理，分離用戶端與伺服器的串連
c). 動態串連池。受益於用戶端登入認證機制的改善
d). 目前的MySQL Proxy無法做到讀寫分離，Spock Proxy實現了這一點，並且非同步並存執行
架構：
   
             圖片來自Spock Proxy官方網站：http://spockproxy.sourceforge.net/

Pyshards
基於Python的Sharding方案，是一個個人研究開源項目，他的目標想實現自動re-balancing（re-sharding），比較有挑戰。目前僅支援MySQL。http://code.google.com/p/pyshards/

參考：《MySQL效能調優與架構設計》