本篇文章的目的在於介紹MySQL Cluster——也就是MySQL的一套記憶體內、實時、可擴充套件且具備高可用性的版本。在解決標題中所提到的每秒2億查詢處理能力問題之前，我們先對MySQL叢集的背景資訊及其架構進行一番回顧，這將有助於大家理解上述目標的實現過程。
MySQL Cluster介紹
MySQL Cluster是一套具備可擴充套件能力、實時、記憶體內且符合ACID要求的事務型資料庫，其將99.999%高可用性與低廉的開源總體擁有成本相結合。在設計思路方面，MySQL Cluster採用一套分散式多主架構並藉此徹底消滅了單點故障問題。MySQL Cluster能夠橫向擴充套件至商用硬體之上，能夠通過自動分割槽以承載讀取與寫入敏感型工作負載，並可通過SQL與NoSQL介面實現訪問。
作為一套最初被設計為嵌入式電信資料庫、用於實現內網應用運營商級可用性及實時效能的解決方案，MySQL Cluster已經通過眾多新型功能集的強化而得到快速發展，從而將用例範圍擴充套件到Web、移動以及企業級應用程式等部署在內部或者雲環境下的例項當中，具體包括：大規模OLTP(實時分析)電子商務、庫存管理、購物車、支付處理、訂單追蹤、線上遊戲、金融交易與欺詐檢測、移動與微支付、會話管理與快取、資料流供應、分析與建議、內容管理與交付、通訊與呈現服務、訂閱/使用者配置管理與補貼等等。
MySQL Cluster架構概述
在面向應用程式的事務流程背後，存在著三種負責將服務交付至應用程式的節點型別。下圖所示為一套簡單的示例型MySQL Cluster架構，其由十二套被劃分為六個節點組的Data Node構成。
Data Node屬於MySQL Cluster當中的主節點。它們負責提供以下功能：記憶體內與基於磁碟資料的儲存與管理、表的自動化與使用者定義型劃分(即分割槽)、在不同資料節點間進行資料副本同步、事務與資料檢查、自動故障轉移以及用於實現自我修復的故障後自動重新同步。
各種表會在多個資料節點當中進行自動分割槽，而且每個資料節點作為一個寫入操作的接收主體，這就使其能夠輕鬆將寫入敏感型工作負載分佈至多個商用節點之上，同時保證應用程式的完全透明化。
通過將資料儲存並分發至一套無共享架構——也就是不使用任何共享磁碟——當中，並至少為資料同步至一套副本內，MySQL Cluster能夠保證在單一Data Node出現故障時、使用者至少還擁有另一個儲存有相同資訊的Data Node。如此一來，請求與事務處理流程將以無中斷方式繼續提供令人滿意的運作效果。任何由於Data Node故障所引發的短暫故障轉移視窗(時間在秒以下)而無法正常完成的事務流程都將被回滾並重新執行。
我們可以為資料選擇儲存方式，包括全部儲存在記憶體內或者將一部分資料只在在磁碟之上(僅限於非索引資料)。記憶體記憶體儲對於那些需要經常進行變更的資料(也就是活躍工作組)而言意義重大。儲存在記憶體內的資料會定期進行指向本地磁碟的檢查，並與全部Data Node進行協調，這樣MySQL Cluster就能夠在整體系統發生故障時——例如供電中斷——得以全面恢復。基於磁碟的資料能夠被用於儲存對效能要求較低的資料，而這類資料集往往大於可用記憶體空間。正如其它大部分資料庫伺服器一樣，MySQL Cluster會利用頁面快取機制將基於磁碟且訪問頻率較高的資料快取在Data Node的記憶體當中，從而增加其實際效能表現。
Application Node負責提供由應用程式邏輯到資料節點的連線。應用程式可以利用SQL訪問該資料庫，具體而言通過一臺或者多臺MySQL伺服器向處於同一套MySQL Cluster內的儲存資料執行SQL介面功能。在MySQL Server當中，我們可以使用任何一種標準化MySQL連線機制，這意味著大家擁有非常豐富的訪問技術可供選擇。另外，一套名為NDB API的高效能(基於C++)介面可被用於實現附加控制、改善實時行為並帶來更理想的吞吐能力。NDB API的層能夠幫助額外NoSQL介面繞過SQL層而直接訪問該叢集，如此一來不僅延遲有所降低、開發人員也有獲得更理想的靈活性水平。現有介面包括Java、JPA、Memcached、JavaScript with Node.js以及HTTP/REST(通過一套Apache Module實現)。所有Application Node都能夠訪問到來自任意Data Node的資料，所以即使出現故障、它們也不會導致任何服務丟失——因為各應用程式能夠繼續使用其它尚能正常運轉的節點。
Management Node的職責在於該叢集的配置方案發布到叢集內的所有節點當中以實現節點管理。Management Node的起效時間點分別為叢集啟動時、某個節點希望加入叢集時以及系統進行重新配置時。Management Node能夠在不影響到當前正在進行的Data及Application Node執行操作的前提下進行中止以及重啟。在預設情況下，Management Node同時提供裁定服務，例如某種網路故障引發“裂腦(即split-brain)”或者某信叢集開始進行網路劃分的情況。
通過透明化劃分實現可擴充套件性
來自任何給定表的行都會以透明化方式被拆分成多個分割槽/片段。在每個片段中會包含一個單獨資料節點，負責保留全部資料內容並處理指向該資料的所有讀取及寫入操作。每個資料節點還擁有一套搭檔體系，二者共同構成一個節點組; 搭檔節點中儲存有該資料片段的輔助副本，但同時也擁有著自己的主片段。MySQL Cluster利用兩步式提交協議實現資料同步，從而確保當某項事務被提交之後、所引發的變更將被同時儲存在兩個資料節點當中。
在預設情況下，表的主鍵會被作為分片鍵使用，而MySQL Cluster將對該分片鍵執行MD5雜湊處理、從而選擇需要儲存哪個片段/分割槽。如果某一事務或者查詢需要訪問來自多個資料節點的資料，那麼其中一個資料節點會充當事務協調方的角色，並將具體工作分配給其它相關資料節點; 接下來訪問結果會得到整合，並最終提供給應用程式。請注意，我們同樣可以讓多個事務或者查詢訪問來自多個分割槽及表的資料——相較於利用分片機制儲存資料的典型NoSQL，這無疑成為MySQL Cluster的一大顯著比較優勢。
要實現最理想的(線性)規模縮放效果，我們需要確保將高強度查詢/事務只需執行在單獨一套資料節點之上(因為這能夠大大降低由資料節點間通訊所帶來的網路延遲)。為了實現這個目標，我們可以讓應用程式獲得分佈識別能力——具體而言，這意味著由管理員定義的規劃能夠涵蓋分片鍵所需要使用的任意列。舉例來講，上圖所示為一套配備有由使用者ID與服務名稱組成的複合主鍵的表; 通過將使用者ID選定為分片鍵，表內與給定使用者相關的所有行將始終被容納在同一片段當中。更為強大的是，如果我們在其它表中使用同樣的使用者ID列並將其設定為分片鍵，那麼該給定使用者在所有表內的全部資料都會被容納在同一片段之內——換言之，指向該使用者的查詢/事務都將在單一資料節點內進行處理。
利用NoSQL API最大程度提升資料訪問速度
MySQL Cluster提供多種方式對儲存資料進行訪問; 最常見的方法當然是SQL，不過正如下圖所示，我們還可以利用多種原生API幫助應用程式直接從資料庫當中讀取及寫入資料，同時又能通過轉換為SQL以繞過MySQL Server的方式防止效率低下或者拉高開發複雜程度。現有API面向C++、Java、JPA、JavaScript/Node.js、HTTP以及Memcached協議。
基準目標：每秒2億次查詢
MySQL Cluster在設計當中主要面向兩種工作負載型別：
-OLTP(即聯機事務處理)：記憶體優化型表提供次毫秒級低延遲與堪稱極端水平的OLTP工作負載併發能力，同時仍然保證良好的耐久性表現; 此外，其也能夠被用於處理基於磁碟的表資料。
-臨時性搜尋：MySQL Cluster增加了並行數量上限，從而在對錶內非索引資料列進行掃描時帶來顯著的速度提升。
值得一提的是，MySQL Cluster在處理OLTP工作負載方面的表現最為突出，特別是在以併發方式發出海量查詢/事務請求的情況下。為此，我們一般會使用flexAsynch基準測試來衡量將更多資料節點新增到叢集當中後，NoSQL所獲得的實際效能擴充套件效果。
此次基準測試所面向的每個資料節點都執行在採用專用56執行緒英特爾E5-2697 v3(Haswell架構)裝置之上。上圖所示為資料吞吐能力隨資料節點數量增長的變化趨勢，具體區間由2節點最終增加到32節點(請注意，MySQL Cluster目前最多能夠支援48個資料節點)。如套大家所見，整個擴充套件比例幾乎保持線性，而且在32資料中心情況下其整體吞吐能力達到了每秒2億次NoSQL查詢。
如果大家對這次測試感興趣，可以點選此處在MySQL Cluster基準測試頁面內瞭解與之相關的詳盡描述與最新結果。
此次2億QPS基準測試執行在MySQL Cluster 7.4版本之上(為目前最新的通用版本)——大家可以點選此處瞭解更多與MySQL Cluster 7.4版本相關的資訊，或者點選此處觀看主題網路研討會的重播視訊。