TDDL

1. 互聯網當下的數據庫拆分過程

對於一個剛上線的互聯網項目來講，因爲前期活躍用戶數量並很少，併發量也相對較小，因此此時企業通常都會選擇將全部數據存放在 一個數據庫 中進行訪問操做。但隨着後續的市場推廣力度不斷增強，用戶數量和併發量不斷上升，這時若是僅靠一個數據庫來支撐全部訪問壓力，幾乎是在 自尋死路 。因此一旦到了這個階段，大部分Mysql DBA 就會將數據庫設置成 讀寫分離狀態 ，也就是一個 Master 節點對應多個Salve 節點。通過 Master/Salve 模式的設計後，徹底能夠應付單一數據庫沒法承受的負載壓力，並將訪問操做分攤至多個 Salve 節點上，實現真正意義上的讀寫分離。但你們有沒有想過，單一的 Master/Salve 模式又能抗得了多久呢？若是用戶數量和併發量出現 量級 上升，單一的 Master/Salve 模式照樣抗不了多久，畢竟一個 Master 節點的負載仍是相對比較高的。爲了解決這個難題， Mysql DBA 會在單一的 Master/Salve模式的基礎之上進行數據庫的 垂直分區 （分庫）。所謂垂直分區指的是能夠根據業務自身的不一樣，將本來冗餘在一個數據庫內的業務表拆散，將數據分別存儲在不一樣的數據庫中，同時仍然保持 Master/Salve 模式。通過垂直分區後的 Master/Salve 模式徹底能夠承受住不可思議的高併發訪問操做，可是否能夠永遠 高枕無憂 了？答案是否認的，一旦業務表中的數據量大了，從維護和性能角度來看，不管是任何的 CRUD 操做，對於數據庫而言都是一件極其耗費資源的事情。即使設置了索引， 仍然沒法掩蓋由於數據量過大從而致使的數據庫性能降低的事實 ，所以這個時候 Mysql DBA 或許就該對數據庫進行 水平分區 （分表， sharding ），所謂水平分區指的是將一個業務表拆分紅多個子表，好比 user_table0 、 user_table1 、 user_table2 。子表之間經過某種契約關聯在一塊兒，每一張子表均按段位進行數據存儲，好比 user_table0 存儲 1-10000 的數據，而 user_table1 存儲 10001-20000 的數據，最後 user_table3 存儲20001-30000 的數據。通過水平分區設置後的業務表，必然可以將本來一張表維護的海量數據分配給 N 個子表進行存儲和維護，這樣的設計在國內一流的互聯網企業比較常見，如圖 1-1 所示：

圖 1-1 水平分區

上述筆者簡單的講解了數據庫的分庫分表原理。接下來請你們認真思考下。本來一個數據庫可以完成的訪問操做，如今若是按照分庫分表模式設計後，將會顯得很是麻煩，這種麻煩尤爲體如今 訪問操做 上。由於持久層須要判斷出對應的數據源，以及數據源上的水平分區，這種訪問方式咱們稱之爲訪問 「 路由 」 。按照常理來講，持久層不該該負責數據訪問層 (DAL) 的工做，它應該只關心 one to one 的操做形式，因此淘寶的 TDDL 框架誕生也就順其天然了。

2、TDDL 的架構原型

TDDL 就是淘寶的分佈式數據層。主要解決了分庫分表對應用的透明化以及異構數據庫之間的數據複製（或者說分庫分表場景下的訪問路由（持久層與數據訪問層的配合）以及異構數據庫之間的數據同步 ），它是一個基於集中式配置的 jdbc datasource實現，具備主備，讀寫分離，動態數據庫配置等功能。

額外話：就目前而言，許多大廠也在出一些更加優秀和社區支持更普遍的 DAL 層產品，好比Hibernate Shards 、 Ibatis-Sharding 等。

淘寶很早就對數據進行過度庫的處理， 上層系統鏈接多個數據庫，中間有一個叫作DBRoute的路由來對數據進行統一訪問。DBRoute對數據進行多庫的操做、數據的整合，讓上層系統像操做 一個數據庫同樣操做多個庫。可是隨着數據量的增加，對於庫表的分法有了更高的要求，例如，你的商品數據到了百億級別的時候，任何一個庫都沒法存放了，因而 分紅2個、4個、8個、16個、32個……直到1024個、2048個。好，分紅這麼多，數據可以存放了，那怎麼查詢它？這時候，數據查詢的中間件就要能 夠承擔這個重任了，它對上層來講，必須像查詢一個數據庫同樣來查詢數據，還要像查詢一個數據庫同樣快（每條查詢在幾毫秒內完成），TDDL就承擔了這樣一 個工做。在外面有些系統也用DAL（數據訪問層） 這個概念來命名這個中間件。

下圖展現了一個簡單的分庫分表數據查詢策略：

主要優勢：
1.數據庫主備和動態切換
2.帶權重的讀寫分離
3.單線程讀重試
4.集中式數據源信息管理和動態變動
5.剝離的穩定jboss數據源
6.支持mysql和oracle數據庫
7.基於jdbc規範，很容易擴展支持實現jdbc規範的數據源
8.無server,client-jar形式存在，應用直連數據庫
9.讀寫次數,併發度流程控制，動態變動
10.可分析的日誌打印,日誌流控，動態變動
TDDL必需要依賴diamond配置中心（diamond是淘寶內部使用的一個管理持久配置的系統，目前淘寶內部絕大多數系統的配置，由diamond來進行統一管理，同時diamond也已開源）。
TDDL動態數據源使用示例說明：http://rdc.taobao.com/team/jm/archives/1645
diamond簡介和快速使用：http://jm.taobao.org/tag/diamond%E4%B8%93%E9%A2%98/
TDDL源碼：https://github.com/alibaba/tb_tddl 
TDDL複雜度相對較高。當前公佈的文檔較少，只開源動態數據源，分表分庫部分還未開源，還須要依賴diamond，不推薦使用。