一，tddl是什麼
tddl是一套分布式資料訪問引擎，主要解決三個問題：
資料訪問路由，將資料的讀寫請求傳送到最合適的地方；
資料的多向非對稱複製，一次寫入，多點讀取；
資料儲存的自由擴充套件，不再受限於單台機器的容量瓶頸與速度瓶頸，平滑遷移。它遵守jdbc規範，支援mysql和oracle，具有分庫分表、主備切換、讀寫分離、動態資料來源配置等功能。
三層架構（可獨立使用）：
其它結構
二，tddl不支援什麼sql
畫外音：分布式資料庫中介軟體，join都是很難支援的，cobar號稱的對join的支援即有限，又低效。
三，tddl支援什麼sql
畫外音：可以看到，其實tddl很多東西都不支援，那麼為什麼它還如此流行呢？它解決的根本痛點是「分布式」「分庫分表」等。
加入了解決「分布式」「分庫分表」的中介軟體後，sql功能必然受限，但是，我們應該考慮到：mysql的cpu和mem都是非常珍貴的，我們應該將mysql從複雜的計算（事務，join，自查詢，儲存過程，檢視，使用者自定義函式，，，）中釋放解脫出來，將這些計算遷移到服務層。
當然，有些後台系統或者支撐系統，資料量小或者請求量小，沒有「分布式」的需求，為了簡化業務邏輯，寫了一些複雜的sql語句，利用了mysql的功能，這類系統並不是分布式資料庫中介軟體的潛在使用者，也不可能強行讓這些系統放棄便利，使用中介軟體。
層次
說明
其他
matrix
可以理解為資料來源的全部，它由多個group組成
group
可以理解為乙個分組，它由多個atom組成
atom
可以理解為乙個資料庫，可能是讀庫，也可能是寫庫
matrix層
group層
atom層
整個sql執行過程
畫外音：這裡我展開一下這個使用場景。
以電商的買家賣家為例，業務方既有基於買家的查詢需求，又有基於賣家的查詢需求，但通常只能以乙個緯度進行資料的分庫（patition），假設以買家分庫， 那賣家的查詢需求如何實現呢？
如上圖所示：查詢買家所有買到的訂單及商品可以直接定位到某乙個分庫，但要查詢賣家所有賣出的商品，業務方就必須遍歷所有的買家庫，然後對結果集進行合併，才能滿足需求。
所謂的「資料增量複製」「表結構冗餘」「減少網路次數」，是指所有的資料以買家賣家兩個緯度冗餘儲存兩份，如下圖：
採用乙個非同步的訊息佇列機制，將資料以另乙個緯度增量複製乙份，在查詢的時候，可以直接以賣家直接定位到相應的分庫。
這種方式有潛在的資料不一致問題。
繼續tddl最佳實踐：
七、tddl的未來？
畫外音：潛台詞是，在大資料量高併發下，sql不是大勢所趨，no-sql和定製化的協議+儲存才是未來方向？
TDDL 原始碼分析
tddl位於資料庫和持久層之間，它直接與資料庫建立交道 tddl其實主要可以劃分為3層架構，分別是matrix層 group層和atom層。matrix層用於實現分庫分表邏輯，底層持有多個group例項。而group層和atom共同組成了動態資料來源，group層實現了資料庫的master salv...
MySQL調研筆記1 MySQL調研清單
最近公司正在去微軟化，之前使用的sql server oracle將逐步切換到mysql，所以部門也會跟隨公司步伐，一步步將現有業務從sql server切換到mysql，當然上mysql肯定是上集群和分布式。於是，有了這份結合業務資料調研mysql的清單，後面的日子裡將一點點記錄關於調研過程中的發...
分庫分表元件TDDL
tddl所處的位置 tddl通用資料訪問層，部署在客戶端的jar包，用於將使用者的sql路由到指定的資料庫中 很早就對資料進行過分庫的處理，上層系統連線多個資料庫，中間有乙個叫做dbroute的路由來對資料進行統一訪問。dbroute對資料進行多庫的操作 資料的整合，讓上層系統像操作 乙個資料庫一樣...