MySQL架构设计相关的方式方法和软件介绍

最近，我在学习了解MySQL数据库架构相关的内容，从网上搜索了大量的相关资料和文章，粗粗阅览了一遍，发现架构相关的东西深不可测

前言

最近，我在学习了解MySQL数据库架构相关的内容，从网上搜索了大量的相关资料和文章，粗粗阅览了一遍，发现架构相关的东西深不可测，需要非常丰富的知识阅历和实践经验。

我的阅历和经验明显不够用，所以我把了解到的相关内容作了下分类整理，算作这次学习的一个大致总结吧！这篇文章的大部分内容都来自网络，由于我的水平有限，整理的也并不准确，其中可能有很多错误之处，希望大家能不吝指正！希望这篇文章能抛砖引玉，帮助我们了解数据库架构相关的一些内容。

当数据库比较庞大，读写操作特别是写入操作过于频繁，很难由一台服务器支撑的时候，我们就要考虑进行数据库的切分。所谓数据库的切分，就是我们按照某些特定的条件，将一台数据库上的数据分散到多台数据库服务器上。因为使用多台服务器，所以当一台服务器宕机后，整个系统只有部分数据不可用，而不是全部不可用。因此，数据库切分不仅能够用多台服务器分担数据库的负载压力，还可以提高系统的总体可用性。

数据的切分有两种方式:垂直切分和水平切分。

垂直切分就是按照系统功能模块，将每个模块访问的数据表切分到不同的数据库中。

适用情况：垂直切分适用于架构设计较好，各个模块间的交互点比较统一而且比较少，耦合度较低的系统。

优点：数据库的切分简单明了，规则明确；系统模块清晰明确，容易整合；数据维护方便，定位容易。

缺点：无法在数据库内实现表关联，只能在程序中实现；对于访问量大且数据量超大的数据表仍然会存在性能问题；事物处理会变得更为复杂，跨服务器的分布式事务会增多；过度切分会导致系统过度复杂、无法扩展、维护困难。

水平切分就是对数据量超大的数据表，按照其中数据的逻辑关系，根据某个字段的某种规则，将其中的数据切分到多个数据库上。

适用情况：水平切分适用于有超大数据量的表且有合适的字段和规则进行水平切分的数据库。数据库进行水平切分后的多个数据库不应该存在交互的情况。

优点：可以在数据库内实现表关联；不会存在超大数据量且超高负载的数据表；可以在数据库内实现事务处理，事务处理相对简单；在合理的切分规则下，扩展性较好。

缺点：切分规则一般比较复杂，很难找出一个适合整个数据库的切分规则；数据的维护难度增加，人工定位数据难度增加；系统模块的耦合度较高，数据迁移拆分难度增加。

在实际进行数据切分时，我们首先应该根据系统模块的设计，合理地进行垂直切分。当模块细分到一定程度后，如果继续进行细分，就会使系统架构过于复杂，整个系统面临失控的危险。这时，我们就要利用水平切分的优势，来避免继续进行垂直切分导致的系统复杂化、面临失控的问题。同时，因为数据已经进行了合理的垂直切分，所以水平切分规则相对简单，系统模块耦合度较高的问题也已得到解决。总之，数据切分应该遵循一个原则，那就是“先合理垂直切分，再适时水平切分；先模块化切分，后数据集切分”。

数据在经过垂直和水平切分被存放在不同的数据库服务器上之后，系统面临的最大问题就是如何来让这些来自不同数据库服务器上的数据得到较好的整合。解决这个问题有两种方式，第一种：在系统的每个模块中配置管理该模块需要的一个或者几个数据库及其所在服务器的信息，数据在模块中进行整合；第二种：通过中间代理层来统一管理所有的数据源，数据库集群对系统应用透明。第一种方案在初期开发时所需成本较小，但是长期来看，系统的扩展性会受到较大的限制。第二种方案则刚好相反，短期内付出的成本相对较大，但有利于系统的扩展。第二种方案可以通过一些第三方软件实现。

MySQLProxy可用来监视、分析、传输应用与数据库之间的通信。它可以实现连接路由，Query分析，Query过滤和修改，负载均衡，以及基本的HA机制等。

原理：MySQLProxy 实际上是在应用请求与数据库服务之间建立了一个连接池。所有应用请求都发向MySQLProxy，然后经由MySQLProxy 进行相应的分析，判断出是读操作还是写操作，分发至对应的MySQLServer 上。对于多节点Slave集群，也可以起到负载均衡的效果。

优点：MySQLProxy具有很大的灵活性，我们可以最大限度的使用它。

缺点：MySQLProxy实际上并不直接提供相关功能，这些功能都要依靠自行编写LUA脚本实现。

Amoeba是一个基于Java开发的Proxy程序开源框架，致力于解决分布式数据库的数据整合问题。它具有Query路由，Query过滤，读写分离，负载均衡功能以及HA机制等。Amoeba可以整合数据切分后的复杂数据源，降低数据切分给整个系统带来的影响，降低数据库与客户端的连接数，实现数据的读写分离。

原理：Amoeba相当于一个SQL请求的路由器，它集中地响应应用的请求，依据用户事先设置的规则，将SQL请求发送到特定的数据库服务器上执行。据此实现负载均衡、读写分离、高可用性等需求。

优点：基于XML的配置文件，用SQLJEP语法编写规则，配置比较简单

缺点：目前还不支持事务；对返回大数量的查询并不合适；不支持分库分表，只能做到分数据库实例。

HiveDB也是一个基于Java开发，针对MySQL数据库提供数据切分及整合的开源框架。但是，目前的HiveDB仅支持数据的水平切分。HiveDB主要解决大数据量下数据库的扩展性及数据的高性能访问问题，同时支持数据的冗余及基本的HA机制。

原理：HiveDB通过用户自定义的各种Partition keys将数据分散到多个数据库服务器上，访问时解析query请求，自动分析过滤条件，并行从多个数据库上读取数据后合并结果集返回给客户端应用程序。HiveDB的实现机制与Amoeba和MySQLProxy不同，它不用借助其他复制同步技术即可自行实现数据的冗余。其底层主要是基于Hibernate Shards 来实现的。Hibernate Shards是Google 技术团队在对 Google 财务系统数据 Sharding 过程中诞生的。Hibernate Shards是在框架层实现的，有其独特的特性：标准的 Hibernate 编程模型，会用 Hibernate 就能搞定，技术成本较低；相对弹性的 Sharding 策略以及支持虚拟 Shard 等。

优点：有商业公司支持，可自行实现数据冗余。

缺点：仅支持水平分区

在数据的整合过程中，还存在一些问题，比如：分布式事务的问题，跨节点JOIN的问题，跨节点排序分页的问题等。对于分布式事务的问题，我们需要将其拆分成多个单数据库内的小事务，由应用程序进行总控；跨节点JOIN的问题，我们需要先从一个节点中取出数据，然后由应用程序去其他节点进行JOIN或者使用Federated引擎；跨节点排序分页时，我们可以并行地从多个节点中读取数据，然后由应用程序进行排序分页。

任何设备或服务，只要是单点，就存在着很大的安全隐患。因为一旦这台设备或服务宕机之后，在短时间内就很难有备用设备或服务来顶替其功能。数据库作为系统的核心，必须存在一个备份以在出现异常时能够快速顶替原有服务，实现高可用性。同时，要实现数据库的读写分离，也必须采用复制技术保持多数据库节点的数据同步。实现数据同步的方式有很多，下面简要介绍常用的几个。

MySQL Replication是MySQL自带的一个异步复制的功能。复制过程中一个服务器充当主服务器，而一个或多个其它服务器充当从服务器，也就是主从模式。

原理：MySQL使用3个线程来执行复制功能。当开始复制时，，从服务器会创建一个I/O线程连接主服务器并要求主服务器发送记录在其上的二进制日志中的语句。主服务器会创建一个线程将二进制日志中的内容发送到从服务器。从服务器I/O线程读取主服务器线程发送的内容并将该数据复制到从服务器数据目录中的本地文件中，这个文件称为中继日志。第三个线程是SQL线程，是由从服务器创建的，用来读取中继日志并执行日志中包含的更新。常用的架构方式为：主-从、主-主、主-从级联、主-主-从级联等。

优点：部署简单、实施方便，是MySQL自动支持的功能，主备机切换方便，可以通过第三方软件或者自行编写简单的脚本即可自动完成主备切换。

缺点：实际使用时，只能单主机进行写入，不一定能满足性能要求；服务器主机硬件故障时，可能会造成部分尚未传输至从机的数据丢失。

MySQL Cluster 是MySQL适用于分布式计算环境的高可用、高冗余版本，采用了NDB Cluster 存储引擎(“NDB”是一种“内存中”的存储引擎，它具有可用性高和数据一致性好的特点)，允许在1个 Cluster 中运行多个MySQL服务器。

原理：MySQL Cluster将标准的MySQL服务器与NDB Cluster存储引擎集成了起来。MySQL Cluster由一组计算机构成，每台计算机上均运行着多种进程，包括MySQL服务器，NDB Cluster的数据节点，管理服务器，以及（可能）专门的数据访问程序。所有这些程序一起构成了MySQL Cluster。将数据保存到NDB Cluster存储引擎时，表（结构）被保存到了数据节点中，应用程序能够从所有其他MySQL服务器上直接访问这些表。 参见下图：