本文的目的是介绍MySQLCluster——即一套内存中的、实时的、可扩展的、高可用的MySQL版本。在解决题目中提到的每秒2亿次查询处理能力的问题之前，我们先来回顾一下MySQL集群的背景资料和架构，这将有助于大家理解实现上述目标的过程。MySQLCluster简介MySQLCluster是一个可扩展的、实时的、内存中的、符合ACID的事务数据库，它结合了99.999%的高可用性和低开源总拥有成本。在设计思路上，MySQLCluster采用分布式多主架构，彻底杜绝单点故障问题。MySQLCluster可以水平扩展到商用硬件，可以通过自动分区承载读写敏感的工作负载，可以通过SQL和NoSQL接口访问。MySQLCluster最初设计为嵌入式电信数据库解决方案，用于实现运营商级可用性和Intranet应用程序的实时性能，随着众多新功能集的增强，其发展迅速，将用例范围扩展到部署的Web、移动和企业应用程序示例本地或云端包括：大规模OLTP（实时分析）电子商务、库存管理、购物车、支付处理、订单跟踪、在线游戏、金融交易和欺诈检测、移动和小额支付、会话管理缓存、数据流、分析和推荐、内容管理和交付、通信和在线服务、订阅/配置文件管理和补贴等。MySQLCluster架构概述在面向应用的事务流程背后，有三种节点类型负责向应用交付服务。下图显示了一个简单的MySQLCluster架构示例，它由十二组数据节点组成，分为六个节点组。DataNode在MySQLCluster中属于master节点。它们负责提供以下功能：内存和磁盘的数据存储和管理，表的自动和用户自定义分区（即分区），不同数据节点之间的数据副本同步，事务和数据检查，自动故障转移和用户定义的分区。自愈失败后自动重新同步。各种表在多个数据节点之间自动分区，每个数据节点作为一个写操作的接收者，可以轻松地将写敏感的工作负载分发到多个商业节点，同时保证应用程序的完全透明。通过在无共享架构中存储和分发数据——即不使用任何共享磁盘——并且至少将数据同步到一组副本，MySQLCluster可以保证当单个DataNode发生故障时，用户至少还有存储相同信息的另一个数据节点。因此，请求和事务处理继续令人满意地运行而不会中断。任何因数据节点故障导致的故障转移窗口较短（小于秒）而无法正常完成的事务过程将被回滚并重新执行。我们可以选择数据的存储方式，包括将所有数据存储在内存中或者只将部分数据存储在磁盘上（仅针对非索引数据）。内存存储对于需要频繁更改的数据（即活动工作组）很有意义。存储在内存中的数据会定期与本地磁盘进行校验，并与所有数据节点协调，以便在整个系统出现故障（例如断电）时能够完全恢复MySQLCluster。基于磁盘的数据可用于存储性能要求较低的数据集，这些数据集通常大于可用内存空间。与大多数其他数据库服务器一样，MySQLCluster会使用页面缓存机制，将基于磁盘且访问频繁的数据缓存在DataNode的内存中，从而提高其实际性能。应用节点负责提供从应用逻辑到数据节点的连接。应用程序可以使用SQL访问数据库，具体是通过一台或多台MySQL服务器对存储在同一组MySQLCluster中的数据执行SQL接口函数。在MySQLServer中，我们可以使用任何标准化的MySQL连接机制，这意味着每个人都有非常丰富的访问技术可供选择。此外，一组称为NDBAPI的高性能（基于C++）接口可用于额外的控制、改进的实时行为和更好的吞吐量。NDBAPI层支持额外的NoSQL接口绕过SQL层并直接访问集群，从而降低延迟并为开发人员提供更理想的灵活性。现有接口包括Java、JPA、Memcached、带有Node.js的JavaScript和HTTP/REST（通过一组Apache模块实现）。所有应用程序节点都可以从任何数据节点访问数据，因此即使它们发生故障，也不会导致任何服务丢失——因为应用程序可以继续使用其他仍在正常运行的节点。ManagementNode的职责是将集群的配置方案发布到集群中的所有节点，实现节点管理。ManagementNode的有效时间点是集群启动的时间，节点要加入集群的时间，以及系统重新配置的时间。管理节点可以暂停和重新启动，而不会影响数据和应用程序节点的正在进行的操作。默认情况下，ManagementNode还提供裁决服务，例如当某个网络故障触发“裂脑”或集群开始分裂网络时。通过透明分区的可扩展性来自任何给定表的行被透明地分成分区/片段。每个片段都包含一个数据节点，该节点保存所有数据内容并处理对该数据的所有读取和写入。每个数据节点也有伙伴系统，两者共同组成一个节点组；伙伴节点存储数据段的辅助副本，但也有自己的主段。MySQLCluster使用两步提交协议来实现数据同步，从而保证当一个事务被提交时，产生的变化会同时存储在两个数据节点中。默认情况下，会使用表的主键作为shardkey，MySQLCluster会对shardkey进行MD5哈希处理，选择需要保存的分片/分区。如果一个事务或查询需要访问多个数据节点的数据，其中一个数据节点将作为事务协调器，将具体工作分配给其他相关数据节点；然后将访问结果整合并最终提供给应用程序。请注意，我们还可以允许多个事务或查询访问多个分区和表中的数据——与典型的使用分片机制存储数据的NoSQL相比，这无疑成为MySQLCluster的一个显着比较优势。为了实现最佳（线性）扩展，我们需要确保高强度查询/事务只需要在一组数据节点上运行（因为这可以大大减少数据节点之间通信引起的网络延迟）。为了实现这个目标，我们可以让应用程序具有分布感知能力——具体来说，这意味着管理员定义的计划可以覆盖片键需要使用的任何列。例如，上图显示了一组表，这些表配备了由用户ID和服务名称组成的复合主键；通过选择用户ID作为分片键，表中与给定用户相关的所有行将始终容纳在同一段中。更强大的是，如果我们在其他表中使用相同的用户ID列并将其设置为分片键，那么所有表中该给定用户的所有数据都将容纳在同一个分片中——换句话说，所有查询/事务针对该用户的信息将在单个数据节点内处理。#p#使用NoSQLAPI最大化数据访问速度MySQLCluster提供了多种访问存储数据的方式；最常用的方法当然是SQL，但是如下图所示，我们也可以使用各种原生API来帮助应用程序直接从数据库中读写数据，同时可以避免效率低下或者通过转换成SQL来绕过MySQLServer增加开发的复杂度。现有的API面向C++、Java、JPA、JavaScript/Node.js、HTTP和Memcached协议。基准目标：每秒2亿次查询MySQL集群专为两种类型的工作负载而设计：-OLTP（在线事务处理）：内存优化表提供亚毫秒级低延迟和极端级别的OLTP工作负载并发性，同时仍确保良好的持久性性能；此外，它还可以用于处理基于磁盘的表数据。-临时搜索：MySQLCluster提高了并行度上限，在扫描表中非索引数据列时带来显着的速度提升。值得一提的是，MySQLCluster在处理OLTP工作负载方面表现最为突出，尤其是在并发发出海量查询/事务请求时。为此，我们一般使用flexAsynchbenchmark来衡量当更多数据节点加入集群时NoSQL的实际性能扩展效果。该基准测试的每个数据节点都在专用的56线程IntelE5-2697v3（Haswell架构）设备上运行。上图展示了随着数据节点数量的增加，数据吞吐量的变化趋势，具体区间从2个节点增加到32个节点（请注意，MySQLCluster目前最多可以支持48个数据节点）。可以看到，整个伸缩率几乎保持线性，在32个数据中心的情况下，其整体吞吐量达到每秒2亿个NoSQL查询。如果您对本次测试感兴趣，可以点击此处在MySQLClusterbenchmark测试页面中了解相关的详细描述和***结果。2亿QPS基准测试运行在MySQLCluster7.4（目前最常见的版本）上——您可以点击这里了解更多关于MySQLCluster7.4的信息，或者点击这里观看网络研讨会的主题回放视频。原标题：MySQL是如何扩展到2亿QPS的-MySQL集群
