TDDL调研笔记

一，TDDL是什么

• Taobao Distributed Data Layer，即淘宝分布式数据层，简称TDDL 。它是一套分布式数据访问引擎

• 淘宝一个基于客户端的数据库中间件产品

• 基于JDBC规范，没有server，以client-jar的形式存在

TDDL是一套分布式数据访问引擎，主要解决三个问题：

1. 数据访问路由，将数据的读写请求发送到最合适的地方；
2. 数据的多向非对称复制，一次写入，多点读取；
3. 数据存储的自由扩展，不再受限于单台机器的容量瓶颈与速度瓶颈，平滑迁移。它遵守JDBC规范，支持mysql和oracle，具有分库分表、主备切换、读写分离、动态数据源配置等功能。

三层架构（可独立使用）：

• Matrix（TDataSource）实现分库分表逻辑，持有多个Group实例；
• Group（TGroupDataSource）实现数据库的主备切换，读写分离逻辑，持有多个Atom实例；
• Atom（TAtomDataSource）实现数据库ip，port，password，connectionProperties等信息的动态推送，持有原子的数据源（分离的Jboss数据源）。

其它结构

• tddl-client：应用启动时初始化配置信息(规则信息，各层数据源拓扑结构，初始化是自上而下的Matrix的dsMap，Group的GroupDs，AtomDs),runtime
• tddl-rule：分库分表规则解析
• tddl-sequence：统一管理和分配全局唯一sequence(序列号)
• tddl-druid-datasource：数据库连接池（高效，可扩展性好），类dbcp、c3p0

二，TDDL不支持什么SQL

• 不支持各类join

• 不支持多表查询

• 不支持between/and

• 不支持not（除了支持not like）

• 不支持comment，即注释

• 不支持for update

• 不支持group by中having后面出现集函数

• 不支持force index

• 不支持mysql独有的大部分函数

画外音：分布式数据库中间件，join都是很难支持的，cobar号称的对join的支持即有限，又低效。

三，TDDL支持什么SQL

• 支持CURD基本语法

• 支持as

• 支持表名限定，即"table_name.column"

• 支持like/not like

• 支持limit，即mysql的分页语法

• 支持in

• 支持嵌套查询，由于不支持多表，只支持单表的嵌套查询

画外音：分布式数据库中间件，支持的语法都很有限，但对于与联网的大数据/高并发应用，足够了，服务层应该做更多的事情。

四，TDDL其他特性

• 支持oracle和mysql

• 支持主备动态切换

• 支持带权重的读写分离

• 支持分库分表

• 支持主键生成：oracle用sequence来生成，mysql则需要建立一个用于生成id的表

• 支持单库事务，不支持跨库事务

• 支持多库多表分页查询，但会随着翻页，性能降低

画外音：可以看到，其实TDDL很多东西都不支持，那么为什么它还如此流行呢？它解决的根本痛点是“分布式”“分库分表”等。

加入了解决“分布式”“分库分表”的中间件后，SQL功能必然受限，但是，我们应该考虑到：MYSQL的CPU和MEM都是非常珍贵的，我们应该将MYSQL从复杂的计算（事务，JOIN，自查询，存储过程，视图，用户自定义函数，，，）中释放解脱出来，将这些计算迁移到服务层。

当然，有些后台系统或者支撑系统，数据量小或者请求量小，没有“分布式”的需求，为了简化业务逻辑，写了一些复杂的SQL语句，利用了MYSQL的功能，这类系统并不是分布式数据库中间件的潜在用户，也不可能强行让这些系统放弃便利，使用中间件。

五，TDDL层次结构

TDDL是一个客户端jar，它的结构分为三层：

层次	说明	其他
matrix	可以理解为数据源的全部，它由多个group组成
group	可以理解为一个分组，它由多个atom组成
atom	可以理解为一个数据库，可能是读库，也可能是写库

matrix层

• 核心是规则引擎

• 实现分库分表

• 主要路径：sql解析 => 规则引擎计算（路由） => 执行 => 合并结果

group层

• 读写分离

• 权重计算

• 写HA切换

• 读HA切换

• 动态新增slave（atom）节点

atom层

• 单个数据库的抽象；

• ip /port /user /passwd /connection 动态修改，动态化jboss数据源

• thread count（线程计数）：try catch模式，保护业务处理线程

• 动态阻止某些sql的执行

• 执行次数的统计和限制

整个SQL执行过程

六，TDDL最佳实践

• 尽可能使用1对多规则中的1进行数据切分（patition key），例如“用户”就是一个简单好用的纬度

• 买家卖家的多对多问题，使用数据增量复制的方式冗余数据，进行查询

• 利用表结构的冗余，减少走网络的次数，买家卖家都存储全部的数据

画外音：这里我展开一下这个使用场景。

以电商的买家卖家为例，业务方既有基于买家的查询需求，又有基于卖家的查询需求，但通常只能以一个纬度进行数据的分库（patition），假设以买家分库， 那卖家的查询需求如何实现呢？

如上图所示：查询买家所有买到的订单及商品可以直接定位到某一个分库，但要查询卖家所有卖出的商品，业务方就必须遍历所有的买家库，然后对结果集进行合并，才能满足需求。

所谓的“数据增量复制”“表结构冗余”“减少网络次数”，是指所有的数据以买家卖家两个纬度冗余存储两份，如下图：

采用一个异步的消息队列机制，将数据以另一个纬度增量复制一份，在查询的时候，可以直接以卖家直接定位到相应的分库。

这种方式有潜在的数据不一致问题。

继续tddl最佳实践：

• 利用单机资源：单机事务，单机join

• 存储模型尽量做到以下几点：

  - 尽可能走内存

  - 尽可能将业务要查询的数据物理上放在一起

  - 通过数据冗余，减少网络次数

  - 合理并行，提升响应时间

  - 读瓶颈通过增加slave（atom）解决

  - 写瓶颈通过切分+路由解决

画外音：相比数据库中间件内核，最佳实践与存储模型，对我们有更大的借鉴意义。

七、TDDL的未来？

• kv是一切数据存取最基本的组成部分

• 存储节点少做一点，业务代码就要多做一点

• 想提升查询速度，只有冗余数据一条路可走

• 类结构化查询语言，对查询来说非常方便

画外音：潜台词是，在大数据量高并发下，SQL不是大势所趋，no-sql和定制化的协议+存储才是未来方向？

分布式数据中间件TDDL、Amoeba、Cobar、MyCAT架构比较