一，TDDL是什么
-
Taobao Distributed Data Layer，即淘寶分布式數據層，簡稱TDDL 。它是一套分布式數據訪問引擎
-
淘寶一個基於客戶端的數據庫中間件產品
-
基於JDBC規范，沒有server，以client-jar的形式存在
TDDL是一套分布式數據訪問引擎，主要解決三個問題：
- 數據訪問路由，將數據的讀寫請求發送到最合適的地方；
- 數據的多向非對稱復制，一次寫入，多點讀取；
- 數據存儲的自由擴展，不再受限於單台機器的容量瓶頸與速度瓶頸，平滑遷移。它遵守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架構比較
