MySql从一窍不通到入门（九）Sharding的实现和规避

转载：数据库专家：MySQL分片水很深

转载：数据库分库分表(sharding)系列(三) 关于使用框架还是自主开发以及sharding实现层面的考量

转载：数据库Sharding的基本思想和切分策略

一、Sharding的优势

Sharding 是把数据库横向扩展（Scale Out）到多个物理节点上的一种有效的方式，其主要目的是为突破单节点数据库服务器的 I/O 能力限制，解决数据库扩展性问题。

1. Sharding确实有使用低成本硬件或者更廉价的云实例获得潜在性能的优势。

2. Sharding可以突破单点数据库服务器的I/O能力限制，解决数据库扩展性问题。

二、Sharding带来的问题

1.事务问题：

在执行分库分表之后，由于数据存储到了不同的库上，数据库事务管理出现了困难，多点间的数据库如何同时完成不可分割的任务成为了编程的重点和难点。

解决事务问题目前有两种可行的方案：

方案一：使用分布式事务（2PC/3PC）

优点：交由数据库管理，简单有效

缺点：性能代价高，特别是shard越来越多时

方案二：由应用程序和数据库共同控制（1PC/TCC）

原理：将一个跨多个数据库的分布式事务分拆成多个仅处于单个数据库上面的小事务，并通过应用程序来总控各个小事务。

优点：性能上有优势

缺点：需要应用程序在事务控制上做灵活设计。如果使用了spring的事务管理，改动起来会面临一定的困难。

2.跨节点Join的问题

只要是进行切分，跨节点Join的问题是不可避免的。但是良好的设计和切分却可以减少此类情况的发生。解决这一问题的普遍做法是分两次查询实现。在第一次查询的结果集中找出关联数据的id，根据这些id发起第二次请求得到关联数据。

3.跨节点的count,order by,group by以及聚合函数问题

这些是一类问题，因为它们都需要基于全部数据集合进行计算。多数的代理都不会自动处理合并工作。

解决方案：与解决跨节点join问题的类似，分别在各个节点上得到结果后在应用程序端进行合并。和join不同的是每个结点的查询可以并行执行，因此很多时候它的速度要比单一大表快很多。但如果结果集很大，对应用程序内存的消耗是一个问题。

三、Sharding的实现层面

从一个系统的程序架构层面来看，sharding逻辑可以在DAO层、JDBC API层、介于DAO与JDBC之间的Spring数据访问封装层(各种spring的template)以及介于应用服务器与数据库之间的sharding代理服务器四个层面上实现。

1. 在DAO层实现

当团队决定自行实现sharding的时候，DAO层可能是嵌入sharding逻辑的首选位置，因为：

1. 在这个层面上，每一个DAO的方法都明确地知道需要访问的数据表以及查询参数，借助这些信息可以直接定位到目标shard上，而不必像框架那样需要对SQL进行解析然后再依据配置的规则进行路由。

2. 不会受ORM框架的制约。由于现在的大多数应用在数据访问层上会依赖某种ORM框架，而多数的shrading框架往往无法支持或只能支持一种orm框架，这使得在选择和应用框架时受到了很大的制约，而自行实现sharding完全没有这方面的问题，甚至不同的shard使用不同的orm框架都可以在一起协调工作。比如现在的java应用大多使用hibernate，但是当下还没有非常令人满意的基于hibernate的sharding框架，（关于hibernate hards会在下文介绍），因此很多团队会选择自行实现sharding。

简单总结一下，在DAO层自行实现sharding的优势在于：不受ORM框架的制约、实现起来较为简单、易于根据系统特点进行灵活的定制、无需SQL解析和路由规则匹配，性能上表现会稍好一些;劣势在于：有一定的技术门槛，工作量比依靠框架实现要大(反过来看，框架会有学习成本)、不通用，只能在特定系统里工作。当然，在DAO层同样可以通过XML配置或是注解将sharding逻辑抽离到“外部”，形成一套通用的框架，不过目前还没有出现此类的框架。

2. 在ORM框架层实现

在ORM框架层实现sharding有两个方向，

1. 在实现O-R Mapping的前提下同时提供sharding支持，从而定位为一种分布式的数据访问框架，这一类类型的框架代表就是guzz

2. 通过对既有ORM框架进行修改增强来加入sharding机制。此类型的代表产品是hibernate shard

应该说以hibernate这样主流的地位，行业对于一款面向hibernate的sharding框架的需求是非常迫切的，但是就目前的hibernate shards来看，表现还算不上令人满意，主要是它对使用hibernate的限制过多，比如它对HQL的支持就非常有限。在mybatis方面，目前还没有成熟的相关框架产生。有人提出利用mybatis的插件机制实现sharding,但是遗憾的是，mybatis的插件机制控制不到多数据源的连接层面，另一方面，离开插件层又失去了对sql进行集中解析和路由的机会，因此在mybatis框架上，目前还没有可供借鉴的框架，团队可能要在DAO层或Spring模板类上下功夫了。

3. 在JDBC API层实现

JDBC API层是很多人都会想到的一个实现sharding的绝佳场所，如果我们能提供一个实现了sharding逻辑的JDBC API实现，那么sharding对于整个应用程序来说就是完全透明的，而这样的实现可以直接作为通用的sharding产品了。但是这种方案的技术门槛和工作量显然不是一般团队能做得来的，因此基本上没有团队会在这一层面上实现sharding,甚至也没有此类的开源产品。笔者知道的只有一款商业产品dbShards采用的是这一方案。

4. 在介于DAO与JDBC之间的Spring数据访问封装层实现

在spring大行其道的今天，几乎没有哪个java平台上构建的应用不使用spring，在DAO与JDBC之间，spring提供了各种template来管理资源的创建与释放以及与事务的同步，大多数基于spring的应用都会使用template类做为数据访问的入口，这给了我们另一个嵌入sharding逻辑的机会，就是通过提供一个嵌入了sharding逻辑的template类来完成sharding工作。

这一方案在效果上与基于JDBC API实现的方案基本一致，同样是对上层代码透明，在进行sharding改造时可以平滑地过度，但它的实现却比基于JDBC API的方式简单，因此成为了不少框架的选择，阿里集团研究院开源的Cobar Client就是这类方案的一种实现。

5. 在应用服务器与数据库之间通过代理实现

在应用服务器与数据库之间加入一个代理，应用程序向数据发出的数据请求会先通过代理，代理会根据配置的路由规则，对SQL进行解析后路由到目标shard，因为这种方案对应用程序完全透明，通用性好，所以成为了很多sharding产品的选择。

在这方面较为知名的产品是mysql官方的代理工具：Mysql Proxy和一款国人开发的产品:amoeba。

mysql proxy本身并没有实现任何sharding逻辑，它只是作为一种面向mysql数据库的代理，给开发人员提供了一个嵌入sharding逻辑的场所，它使用lua作为编程语言，这对很多团队来说是需要考虑的一个问题。

amoeba则是专门实现读写分离与sharding的代理产品，它使用非常简单，不使用任何编程语言，只需要通过xml进行配置。不过amoeba不支持事务(从应用程序发出的包含事务信息的请求到达amoeba时，事务信息会被抹去，因此，即使是单点数据访问也不会有事务存在)一直是个硬伤。当然，这要看产品的定位和设计理念，我们只能说对于那些对事务要求非常高的系统，amoeba是不适合的。

四、Sharding的避免

在采用分片前应该采用的策略：

1. MySQL性能调优和版本升级

更新操作系统和MySQL的版本，更改MySQL的配置参数，解决第一步能够解决的问题。

2. 评估和升级硬件

评估硬件的有限升级是否能够满足需求，以避免软件和架构的大量修改。

3. 优化查询语句

更换MySQL引擎、使用索引和PreparedStatement 以提升查询性能。

4. 分区

单数据库下的分区有助于提升I/O访问性能，降低并发次数。

5. 读写分离

主从复制（还有MySQL集群的同步复制）和读写分离可以极大提升系统性能。

6. 缓存和队列

缓存是降低数据库读取量的出色技术，队列是用来优化写操作的。通过合并多次写操作提高了对数据库操作的效率。Memcached和Redis是MySQL领域非常流行的两种缓存技术。对于队列，最流行的技术是ActiveMQ和RabbitMQ。

7. 外部支持技术

MySQL在很多方面都很出色，但也不是所有方面都强。如果你需要高性能全文检索，应该考虑ElasticSearch、Sphinx或者 Lucene。如果你想做大规模数据分析，可以考虑基于Hadoop的基础架构或者Vertica也是不错的选择。你应该让MySQL处理它擅长的事，把其它事留给外部支持工具来做。