🕸️ 《深入浅出：图解淘宝分布式数据库 TDDL（及开源替代方案）》

“去 IOE” 运动的关键拼图 —— TDDL 是阿里巴巴早期解决数据库扩展性的核心中间件。

一、为什么需要 TDDL？（痛点分析）

二、TDDL 核心架构图解

1. 总体架构（逻辑视图）

┌─────────────┐
│ Application │  (Java Code)
└──────┬──────┘
       │ JDBC
┌──────▼──────────────────────────┐
│        TDDL (Client Side)        │
│ ┌──────────┐  ┌───────────────┐ │
│ │ SQL Parser│→│ Rule Engine   │ │  ← 规则配置
│ └──────────┘  └───────────────┘ │
│        ↓           ↓             │
│ ┌─────────────────────────────┐ │
│ │ Connection Manager & Pool   │ │  ← 管理物理连接
│ └─────────────────────────────┘ │
└──────┬─────────────┬───────────┘
       │             │
┌──────▼──────┐ ┌────▼──────────┐
│ MySQL DB 01  │ │ MySQL DB 02   │  ← 物理分库
│ (Shard 0)   │ │ (Shard 1)    │
└─────────────┘ └──────────────┘

2. SQL 执行全流程（时序图）

App
 |
 | execute("SELECT * FROM orders WHERE user_id=1001")
 |
 v
TDDL
 |
 | 1. SQL 解析 (AST)
 |    -> 提取表名: orders, 条件: user_id=1001
 |
 | 2. 规则计算 (Sharding Rule)
 |    -> user_id % 2 = 1 → 路由到 DB_1
 |
 | 3. SQL 改写
 |    -> 原SQL → 发送到DB_1的实际SQL
 |
 | 4. 执行 & 结果归并
 |    -> 如果是跨库查询，合并ResultSet
 |
 v
MySQL Shard

三、TDDL 核心功能拆解

1. 分库分表（Sharding）

shardingRule:
  tables:
    orders:
      actualDataNodes: ds${0..1}.orders_${0..15}
      databaseStrategy:
        standard:
          shardingColumn: order_id
          preciseAlgorithmClassName: com.taobao.DbShardingAlgorithm
      tableStrategy:
        standard:
          shardingColumn: create_time
          preciseAlgorithmClassName: com.taobao.TblShardingAlgorithm

// 库路由：order_id % 2
public String doSharding(Long orderId) {
    return "ds" + (orderId % 2);
}

2. 读写分离（Read/Write Splitting）

Application
   |
   | Write
   v
Master DB (ds_0_master)
   |
   | Binlog
   v
Slave DB (ds_0_slave_1, ds_0_slave_2)
   ^
   | Read (Hint 或 自动路由)
   |
TDDL

• 写操作：强制走 Master

• 读操作：根据负载均衡策略选择 Slave

• Hint 强制读主：/*+TDDL:MASTER*/ SELECT ...（解决主从延迟）

3. 柔性事务（弱 XA）

1. 本地事务扣款

2. 记录异步任务到 message_log表

3. 后台线程扫描日志，重试失败操作

⚠️ 注意：TDDL 不提供强一致性分布式事务，这是它与 Seata 的最大区别。

四、TDDL 的局限性与演进

五、开源替代方案全景对比

方案矩阵

六、ShardingSphere：TDDL 的最佳继任者

1. 架构对比（TDDL vs ShardingSphere-JDBC）

TDDL (Client)          ShardingSphere-JDBC (Client)
┌──────────────┐       ┌─────────────────────────┐
│ App          │       │ App                     │
├──────────────┤       ├─────────────────────────┤
│ TDDL Client  │  ≈≈≈  │ ShardingSphere-JDBC     │
├──────────────┤       ├─────────────────────────┤
│ MySQL        │       │ MySQL                   │
└──────────────┘       └─────────────────────────┘

2. ShardingSphere 三大优势

3. 快速示例（YAML 配置）

spring:
  shardingsphere:
    datasource:
      names: ds0, ds1
      ds0: {type: HikariCP, jdbc-url: jdbc:mysql://...}
      ds1: {type: HikariCP, jdbc-url: jdbc:mysql://...}
    rules:
      sharding:
        tables:
          t_order:
            actual-data-nodes: ds$->{0..1}.t_order_$->{0..15}
            database-strategy:
              standard:
                sharding-column: order_id
                sharding-algorithm-name: db-inline
            table-strategy:
              standard:
                sharding-column: order_id
                sharding-algorithm-name: tbl-inline

七、终极选择：分库分表 vs NewSQL

决策树

是否需要强一致性事务？
    |
    ├─ 是 → 选 NewSQL (TiDB / OceanBase)
    |
    └─ 否
        |
        ├─ 数据量 < 1TB → 单机 MySQL + 优化
        |
        └─ 数据量巨大 → ShardingSphere + MySQL

八、面试高频考点（TDDL 篇）

A：通过 SQL 解析提取分片键，根据预设规则（Hash/Range）计算目标库表，改写 SQL 后路由执行。

A：TDDL 不支持跨库 JOIN，需在应用层通过多次查询组装，或使用全局表（广播表）。

A：TDDL 是 Client 模式（Jar 包），性能好但耦合应用；MyCAT 是 Proxy 模式，对应用透明但多一层网络开销。

九、总结

TDDL 是阿里电商崛起的基石，而今天，ShardingSphere 是它的开源继承者，TiDB 则是架构演进的下一站。