本篇文章的目的在于介绍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列并将其设定为分片键，那么该给定用户在所有表内的全部数据都会被容纳在同一片段之内——换言之，指向该用户的查询/事务都将在单一数据节点内进行处理。
#p#
利用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
