綜述
大型互聯網架構中,數據存儲會面臨讀寫容量瓶頸問題，像淘寶雙十一活動，核心數據存儲集羣讀寫日訪問量可以達到100億以上,在這種場景下,單機數據庫方式必定面臨極大挑戰,類似的場景也在一些傳統使用IOE的企業中成爲一種制約業務發展的致命要素。而在阿里集團內,TDDL體系就是解決此種場景的利器, 這個體系是基於廉價pc和開源mysql、以客戶端依賴方式、分庫分表爲主要手段、集中化數據庫配置等幾個關鍵要素構建起來, 成爲阿里集團接入mysql的標準，提供整個集團上千個應用的數據庫訪問。
5.1 TDDL
TDDL體系核心作用在於兩個方面,1.直接提供分庫分表，讀寫分離等解決數據庫Scale Out問題的功能. 2.基於配置模型構建的包括數據庫在線擴容、準實時數據同步服務、運維平臺等支撐系統，接下來簡單介紹下幾個重要feature。
分庫分表
TDDL主要部署在ibatis或者其他ORM框架之下，JDBC Driver之上，整個中間件實現了JDBC規範， 所以可以將其當作與普通數據源實例化並且注入到各種ORM框架中使用。
TDDL現時架構分爲了3層，最上層的TDataSource負責分庫分表路由，中間層TGroupDataSource 負責主備切換和讀寫分離，最下層TAtomDataSource一對一對應數據庫連接池，進行動態的數據庫配置信息變更等。3層數據源都可以單獨使用，應對不同的應用場景，如圖5-1所示。
圖5-1-TDDL體系結構
作爲分佈式數據庫，首要工作是解決單機的訪問瓶頸同時儘可能完整保留單機的特性，這也就意味着對於用戶的一個操作，可能分拆到多個數據節點進行數據處理，然後等待節點數據返回再按照sql語義進行合併。
一般分庫分表的具體執行方式可以分爲幾個步驟，包括sql解析，規則計算，表名替換，執行，結果合併。sql解析主要將sql進行詞法解析和語法解析，將其變成程序可識別的語法樹，然後遍歷整棵sql語法樹取出我們所關心的內容，這些內容包括分庫的字段是什麼，對應的值是什麼，是否有limit,order by, max,min等關鍵字，其中前者主要爲了提供相關數據提供給規則進行計算，後者主要是在該sql跨多個表或者庫的時候，在sql返回結果後按照這些關鍵字的語義進行合併。規則計算中，我們將解析得到的字段和值作爲參數傳遞給規則引擎，這些規則引擎會進行類似簡單數字取模, 日期計算,組合計算等操作。規則計算完畢後，我們能夠得到真實的表和數據庫，那麼接下來要做的事情其實是，如果有分表，那麼得把傳入的sql中實際不存在的表替換成真實的表，並且必要情況下對sql做一些改變，這個階段我們稱之爲表名替換。執行階段就是將sql發送到數據庫服務端，這裏有串行和並行兩種模式。如果單個sql最終需要通過多個子sql的形式在節點上執行，返回的結果可能不能直接返回給用戶的，因爲還需要根據原始sql的含義進行合併，這些合併一般遵循逐條流式進行，不能進行這種方式合併的sql一般放棄支持，因爲強行合併，會有極大的內存溢出風險。
圖5-2-TDDL總體流程圖
簡單描述了下整個分庫分表的執行邏輯，這套邏輯經過多年的沉澱，相對比較成熟。但是在這些成熟邏輯的背後，一系列數據庫運維支撐系統在保障數據庫的正常有序運轉，可以想象，如果數據庫機器有成千上萬臺，每天壞個幾臺，上千個應用，隔三差五說數據庫容量不夠，種種挑戰撲向你的時候，沒有相對自動化的運維平臺，那肯定是相當苦逼的。
在線數據庫擴容
TDDL體系中數據庫在線擴容和數據準實時同步是兩個重要的組成部分，這邊簡單介紹下前者。在線數據庫擴容，重點在於在線，也就是不影響業務正常的寫入，因爲數據庫擴容涉及到的數據遷移需要時間，未採取其他措施的情況下，顯然無法實現不影響業務。那麼我們的方案將這個擴容分爲幾個階段，包括全量遷移，增量同步，切換數據庫。全量遷移階段，我們將數據庫數據掃描出來複製到目標，完成後，從事先記錄的增量位點開始追趕，直到趕上當前的進度。 這種動態平衡的過程可以維持一段時間，應用安排某一天業務低谷期，直接切換到新的數據庫即可。
數據準實時同步
如同流動的金錢才能發揮作用一樣，流動的數據也能夠創造出大價值。每天，淘寶的交易訂單，商品，用戶等核心數據通過團隊的數據同步管道進行了流轉，流向搜索，流向廣告，流向大數據等等目的地。這套系統的實現原理基於增量日誌的傳輸與重現，如mysql的binlog,oracle的redo log,hbase的HLog, 系統將這些源系統生成的對應日誌拉到獨立機器進行解析和必要變換，通過有序消息中間件傳遞給多方消費者使用。原理十分簡單,但是在這套系統上面也沉澱了很多的經驗。
5.2、TDDL雙11準備與優化¶
- 數據庫擴容雙十一的數據庫訪問量大過平時訪問量的好幾倍，所以我們必須將數據庫進行大幅度的擴容，阿里的數據庫部署結構主要是單機器多實例方式，在雙十一之前，一些容量不足的數據庫集羣必須將原本在一臺機器上的實例拆分到不同機器上，通過動態推送配置不影響正常的業務訪問，而原本拆分數量不夠的數據庫通過在線數據庫擴容系統在短時間之內resharding,達到雙十一的容量需求。
- 數據準實時同步的擴容雙十一之前, 整個集團有大量的核心應用使用數據準實時同步系統進行多維度的數據同步，而雙十一的寫入量導致該系統的容量需要進一步擴展，而最終這個系統達到了近500臺機器的規模，保證雙十一寫入高峯同步延遲達到期望。
- 前端的鏈接數調整和mysql併發控制patch的使用雙十一之前，應用機器進行了大幅度擴容，而其連接池模型導致單機mysql總鏈接數達到了一個峯值，有可能在零點高峯導致mysql活動鏈接過多而hang住。那麼dba同學通過tddl的動態配置將壓力最大的幾個核心應用單臺機器最大連接池保持在3個以下。另外將這幾個可能出現壓力過大的mysql 集羣打上併發控制patch,在流量超過閥值的時候，對訪問數據庫的鏈接進行排隊處理。
這個解決方案保證了數據庫在雙十一不至於hang住從而產生雪崩效應。
小結
TDDL其實並不是一個產品，它是一個完整的生態系統，這個生態系統以tddl產品爲核心，構建出應用接入層，運維平臺，數據支撐等組件。雙十一中，TDDL整個產品體系支撐着整個業務系統的巨大流量，穩定高效，最高一個數據庫集羣峯值40w/s的寫入，系統也是十分淡定。而未來，TDDL團隊將繼續本着創新務實的心態挖掘分佈式數據庫領域更多有價值的內容。
系列文章：
《中間件技術及雙十一實踐之中間件總體介紹》http://jm-blog.aliapp.com/?p=3359
《中間件技術及雙十一實踐之軟負載篇》http://jm-blog.aliapp.com/?p=3450
《中間件技術及雙十一實踐·服務框架篇》http://jm-blog.aliapp.com/?p=3462
《中間件技術及雙十一實踐·EagleEye篇》http://jm-blog.aliapp.com/?p=3465
《中間件技術及雙十一實踐·消息中間件篇》http://jm-blog.aliapp.com/?p=3483
《中間件技術及雙十一實踐·數據篇》http://jm-blog.aliapp.com/?p=3490
如果覺得內容還行，請分享給更多的人...