Tddl分析之一

何为sharding:

随着大数据时代的到来，单一数据库节点已经远远不能满足数据增长的需要。数据量越来越庞大，导致节点臃肿，无论是查询或者更新都带来了很严重的效率问题。于是数据库sharding成为了一个解决方案。说白了就是将单一节点的数据按照一定的方式分布到多节点上，分布式已经成为大数据时代的一个最佳解决方案了。数据sharding 分为分库和分表。

分库即垂直拆分，相对比较容易，将业务上相关不大的表拆开，各自放到另一个节点的数据库上。这样，

数据操作的压力都分散到不同的节点上。

分表即水平拆分，比分库的“sharding nothing”困难些，因为它必须将同一张表的数据根据某个规则分布

到不同的节点上。这个规则本身制定起来就比较困难，后期的维护就更不用说了。

现阶段的shardig 方案，一般是两者结合起来用。分表其实只是针对某些表数据量太大的情况，而分库针对

有很多低耦合的表簇的情况。分表不可能对全部的数据表进行拆分，往往存在一张表的数据量超过单一节点的负荷承载的情况。所以在分库的基础上进行分表才是最佳的选择。

Sharding 当然也会出现很多问题，比如事务问题、分库后表之间无法关联、跨节点join、group by等操作。

由于数据分布分散，涉及到多节点的处理相对降低了效率。

Sharding 的实现：

Sharding 已经有很多的开源产品出现了，比如hibernate shards、cobarclient、mysql proxy、tddl等。每一个

产品都有针对于不同层面进行封装而达到屏蔽上层对底层分库分表的事实。

主要有如下几种方式的解决方案：

1.JDBC API层，通过封装jdbcAPI，实现分库分表逻辑，这个方法比较直接，而且有比较强的可控制性。

2.ORM 框架层，这方面主要是hibernateshards和guzz两个产品。主要是提供ORM的同时，进行分库分表逻辑。

3.DAO层，这一层可能是最容易的，但是不通用。容易是因为在DAO层，你知道你要访问什么数据，所以你不用通过解析你的SQL语句从而定位相应节点的数据库，你只要通过ORM或者jdbc直接进行定位即可，但是工作量较大，因为很多定位都是人肉实现的，但是相对的，它不受底层的制约，可以灵活定制。

4.DAO-jdbc中间的spring层，spring的template已经成为了一个比较通用的数据访问接口。这给我们一个可以加入sharding的中间层。通过封装相应的template，可以实现相应的分表分库逻辑。

5.数据库代理，其实也是一个道理，通过中间的代理，实现相关的sharding逻辑，主要产品有mysql proxy。

Tddl:解析：

tddl小结：

1、不支持join 语句；在查询语句中表明不能多于一个；不支持Between and语句；不支持NOT、comment、For Update、group by、having；

2.路由问题：

在查询分布式表数据问题上，有两个方法：Hash和Tree。两个方法各有好处，用hash效率为O(1)，不需要频繁调整数据分布，但是不支持范围查询。用Tree结构，效率为O(lgN)，支持范围查询，但是要频繁调整数据节点以适应分布。

TDDL有一个规则引擎，基于Groony脚本实现，主要功能是对hash规则的自动推送。内建三种模式的hash:简单、一致性hash和虚拟节点hash。

3.Matrix层：核心是规则引擎，通过解析sql语句，规则引擎进行计算，然后在各个节点上执行处理，最后合并结果。底下有多个GroupDS实例。

4.group层，实现了读写分离和权重逻辑，持有多个AtomDS实例。

5.Atom层，实现数据库的基本信息，单个数据库的抽象。其实这一层主要是依赖了一个从jboss剥离的datasource，主要的职责是将单个数据源配置放到diamond服务器中，实现数据源的集中管理和动态变更。

未完待续：（tddl源码分析）