淘寶TDDL研發歷史和背景

淘寶DRDS/TDDL是阿里巴巴自主研發的分布式數據庫服務。DRDS脫胎于阿里巴巴開源的Cobar分布式數據庫引擎，吸收了Cobar核心的Cobar-Proxy源碼，實現了一套獨立的類似MySQL-Proxy協議的解析端，能夠對傳入的SQL進行解析和處理，對應用程序屏蔽各種復雜的底層DB拓撲結構，獲得單機數據庫一樣的使用體驗，同時借鑒了淘寶TDDL豐富的分布式數據庫實踐經驗，實現了對分布式Join支持，SUM、MAX、COUNT、AVG等聚合函數支持以及排序等函數支持，通過異構索引、小表廣播等解決分布式數據庫使用場景下衍生出的一系列問題，最終形成了完整的分布式數據庫方案。

使用場景

分布式數據庫核心訴求在于解決單機數據庫的瓶頸，單機數據庫在使用過程中不可避免會遇到數據庫容量、連接數、事務數、讀性能瓶頸，突破這些瓶頸的兩種通用的解決模型是單機垂直擴展scale up模型和水平擴展scale out模型。

單機擴展模型和硬件資源強綁定，普遍采用升級單機硬件能力的方式，實現數據庫服務能力擴展，比如原來采用MySQL單機數據庫，遇到訪問瓶頸時更換磁盤，訪問量更高時就需要考慮使用Oracle的商用解決方案、高端的存儲設備、高端小型機，也就是IOE架構，甚至升級IOE設備，以換取更高的擴展和服務能力，這個過程就會存在設備升級和數據遷移的成本。

多機器用水平擴展模型使用大量廉價的PC-Server，通過陣列的方式來實現數據庫的水平擴容，優勢在于成本更低，因為不需要淘汰老設備和系統，不需要頻繁遷移數據，需要時，只需擴容服務集群規模。

使用分布式多機模型也需要付出一定成本，分布式數據庫的架構與單機數據庫的邏輯和物理分布存在比較大差異，因此需要將單機數據庫的數據遷移到分布式架構模型之下，也就是Sharding的數據分片過程，這個過程涉及數據的分布式邏輯設計、數據庫遷移和SQL的優化改造，當然這個遷移一次性的，當架構遷移完成之后，就無需再關心數據庫擴容和數據遷移問題，因為分布式數據庫的服務層已經集成了擴容功能，架構上支持水平能力擴展。

2006年之前我們的核心應用普遍采用Oracle數據庫，但隨著業務快速發展，淘寶的數據量和訪問量急劇增加，數據庫出現嚴重訪問性能問題，導致數據庫頻繁宕機、業務停滯，即使當時已經使用Oracle亞洲最大的RAC集群，單機數據庫的擴展能力已經達到極限，且需要付出巨大的資金和運維成本，因此我們基于自己的實際情況，逐步開始去IOE，研發分布式關系型數據庫服務，實現數據庫的高擴展和成本可控，目前DRDS已經成為我們內部分布式數據庫的標準，并且對外服務于金融、制造、政府機構、電商、社交等各行業。

DRDS的整體架構

DRDS/TDDL是典型的水平擴展分布式數據庫模型，區別于傳統單機數據庫share anything架構，DRDS/TDDL采用share nothing架構，share nothing架構核心思路利用普通的服務器，將單機數據拆分到底層的多個數據庫實例上，通過統一的Proxy集群進行SQL解析優化、路由和結果聚合，對外暴露簡單唯一的數據庫鏈接。整體架構如圖1所示，包含DRDS服務模塊、DRDS管控模塊、配置中心、監控運維、數據庫服務集群、域名服務模塊。

通過分布式集群管理模塊實現對集群節點的管控。在數據安全和服務可用性方面，通過高效的數據同步系統，實現數據庫的擴容和數據庫實例的主備數據同步。同時依賴實例監控模塊和HA模塊實現主備的監控和自動化容災切換。作為成熟的分布式數據庫產品，TDDL也具備完善的運維管控系統，能夠實現分布式數據庫多實例之間的配置管理、變更，以及各種數據同步、擴容等任務管理，降低運維成本。

DRDS/TDDL的功能特性

數據分片

DRDS的基礎原理就是Sharding，也就是數據分片。將單機數據庫的數據拆分到多個單機數據庫上，對外保持邏輯的一致性。后端拆分的數據庫為分庫，對應的表稱為分表，每個分庫負責一份數據的讀寫操作，分散整體訪問壓力。在系統擴容時，只需水平增加分庫數量，并遷移相關數據，即可提高DRDS系統總體容量。

數據分片需要選擇一個分片的拆分緯度，也就是數據分布的依據。比如一個用戶訂單信息表，如果按照訂單ID做數據拆分，那么相同訂單ID的數據就會被拆分到同一個數據庫存儲節點，如果按照用戶ID做數據拆分，那么同一個用戶的訂單就會分布到同一個數據庫存儲實例的存儲節點。

拆分緯度的選擇非常重要，一般來說要根據實際業務的場景選擇拆分鍵，總體指導原則是盡量保證每一個數據庫節點的數據量和負載更均衡，單條SQL操作盡量落到單個數據庫節點執行，不同SQL的查詢落到不同的數據庫節點。這樣可以減少多個節點之間的網絡傳輸，保持分布式查詢的效率，均衡負載的同時也便于擴展。

平滑擴容

數據庫的擴容是數據庫運維的常見操作，當數據庫的數據存儲容量不足時，傳統的單機數據庫需要提升單機的存儲空間來支持更大的數據寫入量，而隨著數據量膨脹，同樣的SQL查詢語句，查詢的基礎數據量增加必然會降低查詢效率;同時隨著數據量增加，數據庫的訪問壓力通常也會成倍提升，造成單機數據庫連接數到達極限，此時單機數據庫就需要通過升級硬件規格，使用磁盤陣列，使用高端的存儲介質設備和更高端的小型機服務器來承載數據量和訪問量的增加，這個過程會伴隨大量的數據遷移，為了保證數據的一致性通常需要停機數據遷移，對業務影響較大。

DRDS的分布式架構采用平滑擴容的方式來解決上述問題，通過增加更多的底層數據庫實例來完成整體集群擴容。

平滑擴容的前提是用戶需要按照前述的分庫分表邏輯，將邏輯數據庫拆分為多個物理分庫，不同的分庫落在不同的底層物理數據庫機器上。分庫分表的數量通常建議用戶預估未來3-5年的數據量增長情況，按照這個數據量計算總體數據應該拆分為多少個分庫，因為單個分庫的數據量通常會有一個建議值，超過這個閾值就會造成單個節點性能下降。有了具體的分庫數量后，就可以按照分庫的邏輯將數據拆分到不同的存儲實例節點上，當承載分庫的物理數據庫機器出現容量和連接數不足等瓶頸問題時，就可以新增物理數據庫節點，將原有的分庫遷移到新的物理數據庫節點上，實現整體邏輯數據庫的擴容。

擴容過程實際是物理數據遷移的過程，引擎層按照分庫遷移后的邏輯先在物理節點上建立新的分庫，然后保留一個時間點進行全量的數據遷移。完成全量遷移后，開始基于先前保留的時間點進行增量的數據追趕。當增量數據追趕到兩邊的數據幾乎一致時，對數據庫進行瞬時停寫，將最后的數據追平，引擎層進行分庫邏輯的路由切換，路由規則切換完成后就完成了核心的擴容邏輯，整個切換過程在毫秒級別完成。

為了保證數據本身的安全，便于擴容回滾，在路由規格切換完成后，遷移前后的邏輯分庫數據還會進行實時同步，直到業務確認后，才可清理原有分庫數據。

整個擴容過程對上層的業務訪問幾乎無感知，是完全平滑的擴容，但仍需注意擴容的操作盡量選擇在數據庫訪問，尤其是寫入的低谷期進行，避免切換時過多的數據追趕時間。

分布式MySQL執行引擎

分布式數據庫的數據有規律地存儲在多個底層存儲實例上，數據物理存儲的變化會造成與原生的數據庫引擎不兼容，單機數據庫所有的數據讀取、寫入、計算都在單一的物理機上執行，數據狀態維持在單機上，主要的性能消耗在于磁盤的數據讀取;而分布式架構下，數據和狀態需要在多個數據庫實例之間以及底層實例和Proxy之間進行傳輸，這會造成網絡I/O消耗，而網絡I/O對性能造成消耗相較于本地磁盤I/O和本地計算的性能開銷而言要大得多。

因此分布式SQL引擎主要目標是實現與單機數據庫SQL引擎的完全兼容，實現SQL的智能下推。能夠智能分析SQL，解析出哪些SQL可以直接下發，哪些SQL需要進行優化改造，優化成什么樣，以及路由到哪些實例節點上執行，充分發揮數據庫實例的全部能力，減少網絡之間的數據傳輸量，最終對不同實例處理后的少量結果數據進行聚合計算返回給應用調用方。這就是分布式SQL引擎的智能下推功能。

分布式引擎的職責包含SQL解析、優化、執行和合并四個流程，如圖4所示。

智能下核心原則有如下幾個：

1. 減少網絡傳輸;
2. 減少計算量，盡量將計算下推到下層的數據節點上，讓計算在數據所在的機器上執行;
3. 充分發揮下層存儲的全部能力。

基于以上原則實現的SQL引擎，就可以做到服務能力線性擴展。比如一個簡單的AVG操作，對于一些比較初級的分布式數據庫模型而言，常見做法是把AVG直接下發到所有的存儲節點，這樣造成的結果就是語法兼容，語意不兼容，最終拿到的是錯誤結果。而DRDS的智能下推引擎，對SQL的語法做充分的語意兼容性適配，針對AVG操作，只能由引擎將邏輯AVG SQL解析優化為SUM和COUNT的SQL然后進行下推，由底層的數據庫實例節點完成SUM和COUNT計算，充分利用底層節點的計算能力，在引擎層將各個存儲節點的SUM和COUNT結果聚合計算，最終計算出AVG。這只是一個非常典型的案例，在分布式數據庫模型下，多數據表的Join操作，歸并排序的兼容性非常復雜，下文會針對典型的場景解析TDDL/DRDS如何解決分布式場景下的具體問題。

彈性擴展

TDDL/DRDS采用服務和存儲分離的架構，DRDS實例服務層通過集群方式部署，由多個服務節點構成一個服務實例，通過負載均衡以及域名服務對外提供服務，多個服務節點之間無狀態同步，平均負載處理用戶請求。服務集群處理能力不足時，可隨時擴充服務節點，增加服務處理能力。同樣，業務低谷期也可適當降低集群規模，做到彈性的服務能力擴展。

對于一些大數據量OLAP的場景，對于單個Server節點的內存資源需求高時，也可通過提升單個Server節點的規格，做到垂直的能力擴展。

分布式Join和小表廣播

分布式場景下的Join操作和單機不同，單機數據的Jion操作發生在單機上，不存在內部網絡數據傳輸。

在分布式架構下的多個數據表Jion，如果參與Join的多表數據切分緯度不同，數據則按照不同的拆分緯度分散在不同的數據庫實例上，Join操作可能產生跨多個物理分庫的Join，就需要進行多個底層實例的大量數據傳輸，SQL的執行效率就得不到保證，因此要參與Join操作的數據表要盡量保持拆分緯度統一，讓Join操作盡量發生在單機上，減少跨庫Join。如果不能保持拆分緯度的統一，存在跨庫Join操作，那么原則就是盡量減少Join操作的輸出傳輸。

DRDS通常使用的Join算法基于Nested Loop，對于Join的左右兩個表，首先從Join的左表(驅動表)取出數據，然后將所取出數據中Join列的值放到右表并進行IN查詢，從而完成Join過程。因此，Join的左表數據量越少，DRDS對右表做IN查詢就次數就越少，如果右表的數據量也很少或建有索引，則Join的速度更快。故而在DRDS中，Join驅動表的選擇對于Join的優化非常重要。

而在實際數據庫場景中，經常有一些源信息表，數據量較小，更新頻度也很低，這些表無需拆分，類似這些源信息表通常采用單表模式，單表模式下一個邏輯表的數據統一存儲在一個分庫中，通常存儲在“0”庫，將這些表定義為“小表”，而其他業務數據量大、更新頻率高的表仍舊采用分庫分表的拆分模式。那這些“小表”和分庫分表進行Join時，基于Nested Loop算法的原則，小表作為Join的驅動表會大大減少右表的IN查詢次數，同時DRDS提供的小表廣播功能，通過數據實時復制，將“小表”的全量數據和增量變更實時復制到分庫分表上，將跨庫的Join轉化為單機Join操作，減少Server節點的計算，降低數據在多個底層實例之間的傳輸，Jion的效率提升會非常明顯。

異構索引

異構索引是DRDS提升分布式查詢效率的解決方案之一，能夠解決分布式場景下數據拆分緯度和數據查詢使用緯度不一致導致的低效問題。

當數據表被拆分為多個分庫分表時，數據在分庫分表的分布規則就固定了。但是通常數據的業務使用場景非常復雜，如果數據的查詢緯度和數據拆分分布的規則一致，單條SQL會在一個分庫分表上執行;如果數據的查詢使用緯度和數據拆分分布的規格不一致，單條SQL就很有可能在多個分庫分表上執行，出現跨庫查詢，跨庫查詢會增加網絡I/O的成本，查詢效率必然下降。

解決這個問題的思路還是分布式數據庫的一貫原則，讓SQL執行在單庫上完成，實際采用的方式就是用“空間換效率”的方案，也就是將同一份數據表，冗余存儲多份，按照不同的業務使用場景進行拆分，保持拆分緯度和使用緯度統一，而多份數據之間會實時數據復制以解決數據一致性問題，這就是“異構索引”方案。當然異構索引表不能無限制濫用，過多的異構索引表會影響同步效率，對源數據表造成同步壓力。

最佳實踐

分布式SQL優化

SQL優化是數據庫使用和運維的日常操作，分布式數據庫針對SQL的優化不僅要考慮磁盤I/O的開銷，更要關注網絡I/O開銷。為了優化SQL執行，其核心的優化思想就是減少網絡I/O。為此，DRDS會盡量將原本DRDS這一層的工作均衡下發到其底層的各個分庫(如RDS 等)來做。這樣就可以將原本需要走網絡的I/O開銷轉換為單機的磁盤I/O開銷，從而提升查詢執行效率。因此，我們在使用DRDS時若遇到了慢SQL，則需針對DRDS的特點將適當改寫SQL。

首先是條件查詢優化，DRDS的數據按拆分鍵進行水平切分，查詢中若帶上拆分鍵對于減少SQL在DRDS的執行時間很有意義。查詢條件盡量帶分庫鍵，就可以讓DRDS根據分庫鍵的值將查詢直接路由到特定的分庫，這有助于避免DRDS做全庫掃描。含分庫鍵的條件精度越高，越有助于提高查詢速度，也只有這樣的優化才能充分發揮分布式架構查詢的優勢，便于后續查詢能力的擴展。

其次針對Join的優化，選擇條件查詢數據量少的Join表作為左表(驅動表)，降低右表IN查詢的次數;在數據量少且變更量少的“廣播表”參與的Jion操作，將“廣播表”作為驅動表。

針對LIMIT OFFSET、COUNT語句，DRDS實際SQL執行是依次將OFFSET之前的記錄數據讀取出來，并丟棄，只保留OFFSET之后的數據，這樣當OFFSET非常大時，讀取的數據記錄數很少，效率也很低，因為OFFSET之前的數據讀取需要執行大量的磁盤I/O讀取操作。優化方式是將SQL優化為對key的OFFSET讀取和IN操作兩個步驟，先讀取OFFSET之后的記錄key，內存中緩存這些key，然后再通過IN查詢獲取完整的記錄信息，這樣會大大減少磁盤I/O，效率提升非常明顯。

分布式事務優化

分布式數據庫的事務和SQL查詢優化的邏輯是一樣的原則，盡量讓事務在單庫中執行，只有在單庫中執行，才可以在保持事務ACID特性的同時，還能線性地擴展事務能力。這種單庫事務通常稱為“強事務”。

實際業務也經常會面臨分布式數據庫架構下，數據庫事務不可避免出現跨庫執行。跨庫事務必然涉及到一個事務在多個分庫上進行事務分支的執行和狀態同步，相比單機事務，分布式跨庫事務的吞吐量和延遲會大大增加。而事務涉及的分庫越多，事務邊界越大，事務的延遲也會相應增加，性能就會出現線性衰減。

遇到跨庫事務，通常的實踐優化方式是通過“最終一致”事務保證事務執行的吞吐量。“最終一致”事務的原理是優先保證核心事務分支的正向執行，然后保存事務中間狀態，其他事務分支異步執行，執行完成后達到最終的事務一致，避免跨庫事務時間序列執行阻塞，提升事務吞吐量。如圖8所示，事務3和事務5是跨庫事務，事務分支先在左邊庫進行，異步的事務分支在右邊分庫執行，分別在自己所在的分庫順序執行，最終達到事務一致性。

單機數據庫遷移到DRDS的流程

單機數據庫遷移到分布式數據庫要保證的就是業務正常運轉、平滑過渡、減少運維，整個遷移分為三個步驟。

• 第一步，讀寫保持在原有的數據庫上，數據通過復制機制寫入分布式數據庫，前提是分布式目標庫表已經建好;
• 第二步，驗證云上數據是否正確，切部分讀取流量到目標的分布式數據庫上讀取線上壓力驗證(測試環境提前驗證也可保證);
• 第三步，業務聽寫幾分鐘，讀寫的流量切換到目標庫，數據反向復制到源單機數據庫，保證隨時可切換回單機數據庫，同時也可做云下數據備份。

未來的發展

DRDS作為分布式數據體系中的數據庫服務中間層，未來會適配更多底層存儲引擎，在充分利用底存儲節點的計算能力的同時，優化本身服務的計算能力，解決OLAP場景，成為能夠完整覆蓋OLTP和OLAP以及其他一些數據庫服務場景的完備的分布式數據庫服務體系。同時完備分布式數據庫邏輯層的運維支持和分布式強一致事務的支持。