TDDL（taobao distributed data layer ）作數據路由層
淘寶的數據拆分歷程
-
系統剛開始的時候，用戶數量不多，所有的數據都放在了同一個數據庫中，此時因爲用戶少壓力小，一個數據庫完全可以應付的了。但是隨着用戶數量不斷增加，數據庫壓力也與日俱增，它終於在某一天大家都和愜意的時候掛掉啦。此時是到了讀寫分離的時候，這個時候我們會配置一個server爲master節點，然後配幾個salve節點，這樣以來通過讀寫分離，使得讀取數據的壓力分攤到了不同的salve節點上面，系統終於又恢復了正常，開始正常運行了。但是好景還是不長，有一天我們發現master撐不住了，負載很高，隨時都有掛掉的風險，這個時候就需要進行垂直拆分啦（也就是所謂的分庫），比如將商品信息、用戶信息、交易信息分別存儲到不同的數據庫中，同時還可以針對商品信息的庫採用master/salve模式，OK，
通過分庫以後，各個按照功能拆分的數據庫寫壓力被分擔到了不同的server上面，這樣數據庫的壓力終於有恢復到正常狀態。但是不是這樣，我們就可以高枕無憂了呢？NO,通過前輩們的經驗總結顯示，隨着用戶量的不斷增加，你會發現系統中的某些數據表會變的異常龐大，比如好友關係表，店鋪的參數配置表等，此時無論論是寫入還是讀取這些表的數據，對數據庫來說都是一個很耗費精力的事情，因此此時就需要我們進行“水平拆分”了（這就是俗話說的分表，或者說sharding）。
-
上面的闡述，無非就是告訴大家一個事實“數據庫是系統中最不容易scale out的一層”，一個大型的互聯網應用必然會經過一個從單一DB server, 到Master/salve, 再到垂直分區（分庫），然後再到水平分區（分表即sharding）的過程，而在這個過程中，Master/salve 以及垂直分區相對比較容易，對應用的影響也不是很大，但是分表會引起一些棘手的問題，比如不能跨越多個分區join查詢數據，如何平衡各個shards的負載等等，這個時候就需要一個通用的DAL框架來屏蔽底層數據存儲對應用邏輯的影響，使得底層數據的訪問對應用透明化。
-
拿淘寶目前的情況來說，淘寶目前也正在從昂貴的高端存儲（小型機+ORACLE）切換到MYSQL, 切換到MYSQL以後，勢必會遇到垂直分區（分庫）以及水平分區（Sharding）的問題，因此目前淘寶根據自己的業務特點也開發了自己的TDDL框架，此框架主要解決了分庫分表對應用的透明化以及異構數據庫之間的數據複製問題。
tddl的工作流程圖
![]()
