TDDL

1. 互联网当下的数据库拆分过程

对于一个刚上线的互联网项目来讲，因为前期活跃用户数量并很少，并发量也相对较小，因此此时企业通常都会选择将全部数据存放在 一个数据库 中进行访问操做。但随着后续的市场推广力度不断增强，用户数量和并发量不断上升，这时若是仅靠一个数据库来支撑全部访问压力，几乎是在 自寻死路 。因此一旦到了这个阶段，大部分Mysql DBA 就会将数据库设置成 读写分离状态 ，也就是一个 Master 节点对应多个Salve 节点。通过 Master/Salve 模式的设计后，彻底能够应付单一数据库没法承受的负载压力，并将访问操做分摊至多个 Salve 节点上，实现真正意义上的读写分离。但你们有没有想过，单一的 Master/Salve 模式又能抗得了多久呢？若是用户数量和并发量出现 量级 上升，单一的 Master/Salve 模式照样抗不了多久，毕竟一个 Master 节点的负载仍是相对比较高的。为了解决这个难题， Mysql DBA 会在单一的 Master/Salve模式的基础之上进行数据库的 垂直分区 （分库）。所谓垂直分区指的是能够根据业务自身的不一样，将本来冗余在一个数据库内的业务表拆散，将数据分别存储在不一样的数据库中，同时仍然保持 Master/Salve 模式。通过垂直分区后的 Master/Salve 模式彻底能够承受住不可思议的高并发访问操做，可是否能够永远 高枕无忧 了？答案是否认的，一旦业务表中的数据量大了，从维护和性能角度来看，不管是任何的 CRUD 操做，对于数据库而言都是一件极其耗费资源的事情。即使设置了索引， 仍然没法掩盖由于数据量过大从而致使的数据库性能降低的事实 ，所以这个时候 Mysql DBA 或许就该对数据库进行 水平分区 （分表， sharding ），所谓水平分区指的是将一个业务表拆分红多个子表，好比 user_table0 、 user_table1 、 user_table2 。子表之间经过某种契约关联在一块儿，每一张子表均按段位进行数据存储，好比 user_table0 存储 1-10000 的数据，而 user_table1 存储 10001-20000 的数据，最后 user_table3 存储20001-30000 的数据。通过水平分区设置后的业务表，必然可以将本来一张表维护的海量数据分配给 N 个子表进行存储和维护，这样的设计在国内一流的互联网企业比较常见，如图 1-1 所示：

图 1-1 水平分区

上述笔者简单的讲解了数据库的分库分表原理。接下来请你们认真思考下。本来一个数据库可以完成的访问操做，如今若是按照分库分表模式设计后，将会显得很是麻烦，这种麻烦尤为体如今 访问操做 上。由于持久层须要判断出对应的数据源，以及数据源上的水平分区，这种访问方式咱们称之为访问 “ 路由 ” 。按照常理来讲，持久层不该该负责数据访问层 (DAL) 的工做，它应该只关心 one to one 的操做形式，因此淘宝的 TDDL 框架诞生也就顺其天然了。

2、TDDL 的架构原型

TDDL 就是淘宝的分布式数据层。主要解决了分库分表对应用的透明化以及异构数据库之间的数据复制（或者说分库分表场景下的访问路由（持久层与数据访问层的配合）以及异构数据库之间的数据同步 ），它是一个基于集中式配置的 jdbc datasource实现，具备主备，读写分离，动态数据库配置等功能。

额外话：就目前而言，许多大厂也在出一些更加优秀和社区支持更普遍的 DAL 层产品，好比Hibernate Shards 、 Ibatis-Sharding 等。

淘宝很早就对数据进行过度库的处理， 上层系统链接多个数据库，中间有一个叫作DBRoute的路由来对数据进行统一访问。DBRoute对数据进行多库的操做、数据的整合，让上层系统像操做 一个数据库同样操做多个库。可是随着数据量的增加，对于库表的分法有了更高的要求，例如，你的商品数据到了百亿级别的时候，任何一个库都没法存放了，因而 分红2个、4个、8个、16个、32个……直到1024个、2048个。好，分红这么多，数据可以存放了，那怎么查询它？这时候，数据查询的中间件就要能 够承担这个重任了，它对上层来讲，必须像查询一个数据库同样来查询数据，还要像查询一个数据库同样快（每条查询在几毫秒内完成），TDDL就承担了这样一 个工做。在外面有些系统也用DAL（数据访问层） 这个概念来命名这个中间件。

下图展现了一个简单的分库分表数据查询策略：

主要优势：
1.数据库主备和动态切换
2.带权重的读写分离
3.单线程读重试
4.集中式数据源信息管理和动态变动
5.剥离的稳定jboss数据源
6.支持mysql和oracle数据库
7.基于jdbc规范，很容易扩展支持实现jdbc规范的数据源
8.无server,client-jar形式存在，应用直连数据库
9.读写次数,并发度流程控制，动态变动
10.可分析的日志打印,日志流控，动态变动
TDDL必需要依赖diamond配置中心（diamond是淘宝内部使用的一个管理持久配置的系统，目前淘宝内部绝大多数系统的配置，由diamond来进行统一管理，同时diamond也已开源）。
TDDL动态数据源使用示例说明：http://rdc.taobao.com/team/jm/archives/1645
diamond简介和快速使用：http://jm.taobao.org/tag/diamond%E4%B8%93%E9%A2%98/
TDDL源码：https://github.com/alibaba/tb_tddl 
TDDL复杂度相对较高。当前公布的文档较少，只开源动态数据源，分表分库部分还未开源，还须要依赖diamond，不推荐使用。