剖析淘宝TDDL(TAOBAO DISTRIBUTE DATA LAYER)

剖析淘宝 TDDL （ TAOBAO DISTRIBUTE DATA LAYER ）

注：本文部分内容引用本人博

客/blog/1973591

前言

在开始讲解淘宝的 TDDL(Taobao Distribute Data Layer) 技术之前，请允许笔者先吐槽一番。首先要开喷的是淘宝的社区支持做的无比的烂， TaoCode 开源社区上面，几乎从来都是有人提问，无人响应。再者版本迭代速度也同样差强人意，就目前而言 TDDL 的版本已经全线开源（Group、Atom、Matrix）大家可以在Github上下载源码。

目录

一、互联网当下的数据库拆分过程

二、 TDDL 的架构原型

三、下载 TDDL 的 Atom 层和 Group 层源代码

四、 Diamond 简介

五、 Diamond 的安装和使用

六、动态数据源层的 Master/Salve 读写分离配置与实现

七、 Matrix 层的分库分表配置与实现

一、互联网当下的数据库拆分过程

对于一个刚上线的互联网项目来说，由于前期活跃用户数量并不多，并发量也相对较小，所以此时企业一般都会选择将所有数据存放在一个数据库中进行访问操作。但随着后续的市场推广力度不断加强，用户数量和并发量不断上升，这时如果仅靠一个数据库来支撑所有访问压力，几乎是在自寻死路。所以一旦到了这个阶段，大部分 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 框架诞生也就顺其自然了。

二、 TDDL 的架构原型

淘宝根据自身业务需求研发了 TDDL （ Taobao Distributed Data Layer ）框架，主要用于解决分库分表场景下的访问路由（持久层与数据访问层的配合）以及异构数据库之间的数据同步，它是一个基于集中式配置的 JDBC DataSource 实现，具有分库分表、 Master/Salve 、动态数据源配置等功能。

就目前而言，许多大厂也在出一些更加优秀和社区支持更广泛的 DAL 层产品，比如 Hibernate Shards 、 Ibatis-Sharding 等。如果你要问笔者还为什么还要对TDDL 进行讲解，那么笔者只能很无奈的表示公司要这么干，因为很多时候技术选型并不是笔者说了算，而是客户说了算。当笔者费劲所有努力在 google 上寻找TDDL 的相关使用说明和介绍时，心里一股莫名的火已经开始在蔓延，对于更新缓慢（差不多一年没更新过 SVN ），几乎没社区支持（提问从不响应）的产品来说，除了蜗居在企业内部，必定走不了多远，最后的结局注定是悲哀的。好了，既然抱怨了一番，无论如何还是要坚持讲解完。 TDDL 位于数据库和持久层之间，它直接与数据库建立交道，如图 1-2 所示：

图 1-2 TDDL 所处领域模型定位

传说淘宝很早以前就已经对数据进行过分库分表处理，应用层连接多个数据源，中间有一个叫做 DBRoute 的技术对数据库进行统一的路由访问。 DBRoute 对数据进行多库的操作、数据的整合，让应用层像操作一个数据源一样操作多个数据库。但是随着数据量的增长，对于库表的分法有了更高的要求，例如，你的商品数据到了百亿级别的时候，任何一个库都无法存放了，于是分成 2 个、 4 个、 8个、 16 个、 32 个……直到 1024 个、 2048 个。好，分成这么多，数据能够

存放了，那怎么查询它？这时候，数据查询的中间件就要能够承担这个重任了，它对上层来说，必须像查询一个数据库一样来查询数据，还要像查询一个数据库一样快（每条查询要求在几毫秒内完成）， TDDL 就承担了这样一个工作（其他 DAL产品做得更好），如图 1-3 所示：