本篇文章的目的在于介紹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列并將其設定為分片鍵，那么該給定用戶在所有表內的全部數據都會被容納在同一片段之內——換言之，指向該用戶的查詢/事務都將在單一數據節點內進行處理。

本篇文章的目的在于介紹MySQL Cluster——也就是MySQL的一套內存內、實時、可擴展且具備高可用性的版本。在解決標題中所提到的每秒2億查詢處理能力問題之前，我們先對MySQL集群的背景信息及其架構進行一番回顧，這將有助于大家理解上述目標的實現過程。

利用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版本相關的信息，或者點擊此處觀看主題網絡研討會的重播視頻。

原文標題：How MySQL Is Able To Scale To 200 Million QPS - MySQL Cluster