資料庫中介軟體TDDL調研筆記
轉自:https://mp.weixin.qq.com/s/dVGSvUR9UCA-dIYVtr_G_w 架構師之路
前篇：
13年底負責資料庫中介軟體設計時的調研筆記，拿出來和大家分享，輕拍。
一，TDDL是什麼
-
TDDL是Taobao Distribute Data Layer的簡稱
-
淘寶一個基於客戶端的資料庫中介軟體產品
-
基於JDBC規範，沒有server，以client-jar的形式存在
畫外音：資料庫中介軟體有基於服務端的，也有基於客戶端的，TDDL屬於後者；而cobar是一箇中間層服務，使用mysql協議，屬於前者。
二，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層次結構
對應上面圖例：matrix資料水平分為了兩個group，每個group有主備atom組成。
matrix層
-
核心是規則引擎
-
實現分庫分表
-
主要路徑：sql解析 => 規則引擎計算（路由） => 執行 => 合併結果
group層
-
讀寫分離
-
權重計算
-
寫HA切換
-
讀HA切換
-
動態新增slave（atom）節點
atom層
-
單個數據庫的抽象；
-
ip /port /user /passwd /connection 動態修改，動態化jboss資料來源
-
thread count（執行緒計數）：try catch模式，保護業務處理執行緒
-
動態阻止某些sql的執行
-
執行次數的統計和限制
整個SQL執行過程
-
BEGIN(sql+args)，輸入是sql和引數
-
sql解析
-
規則計算
-
表名替換
-
選擇groupDS執行sql
-
根據權重選擇atomDS
-
具備重試策略的在atomDS執行sql
-
讀寫控制，併發控制，執行sql，返回結果
-
合併結果集
-
END(ResultSet)，輸出是結果集
畫外音：感覺難點在SQL的解析上。
六，TDDL最佳實踐
-
儘可能使用1對多規則中的1進行資料切分（patition key），例如“使用者”就是一個簡單好用的緯度
-
買家賣家的多對多問題，使用資料增量複製的方式冗餘資料，進行查詢
-
利用表結構的冗餘，減少走網路的次數，買家賣家都儲存全部的資料
畫外音：這裡我展開一下這個使用場景。
以電商的買家賣家為例，業務方既有基於買家的查詢需求，又有基於賣家的查詢需求，但通常只能以一個緯度進行資料的分庫（patition），假設以買家分庫， 那賣家的查詢需求如何實現呢？
如上圖所示：查詢買家所有買到的訂單及商品可以直接定位到某一個分庫，但要查詢賣家所有賣出的商品，業務方就必須遍歷所有的買家庫，然後對結果集進行合併，才能滿足需求。
所謂的“資料增量複製”“表結構冗餘”“減少網路次數”，是指所有的資料以買家賣家兩個緯度冗餘儲存兩份，如下圖：
採用一個非同步的訊息佇列機制，將資料以另一個緯度增量複製一份，在查詢的時候，可以直接以賣家直接定位到相應的分庫。
這種方式有潛在的資料不一致問題。
繼續tddl最佳實踐：
-
利用單機資源：單機事務，單機join
-
儲存模型儘量做到以下幾點：
- 儘可能走記憶體
- 儘可能將業務要查詢的資料物理上放在一起
- 通過資料冗餘，減少網路次數
- 合理並行，提升響應時間
- 讀瓶頸通過增加slave（atom）解決
- 寫瓶頸通過切分+路由解決
畫外音：相比資料庫中介軟體核心，最佳實踐與儲存模型，對我們有更大的借鑑意義。
七、TDDL的未來？
-
kv是一切資料存取最基本的組成部分
-
儲存節點少做一點，業務程式碼就要多做一點
-
想提升查詢速度，只有冗餘資料一條路可走
-
類結構化查詢語言，對查詢來說非常方便
畫外音：潛臺詞是，在大資料量高併發下，SQL不是大勢所趨，no-sql和定製化的協議+儲存才是未來方向？
13年底的調研筆記，文中的“畫外音”是我當時的批註，希望能讓大家對TDDL能有一個初步的認識，有疑問之處，歡迎交流。
相關文章：