分佈式數據庫中間件DDM的實現原理

隨着數據量不斷增大，傳統的架構模式難以解決業務量不斷增加所帶來的問題，特別是在業務成線性、甚至指數級上升的狀況。此時咱們不得不經過水平擴展，把數據庫放到不一樣服務器上來解決問題，也就是咱們說的數據庫中間件。

做爲數據庫中間件，分佈式數據庫中間件DDM將底層數據庫存儲引擎以集羣方式管理起來，用戶使用很是方便。應用程序不須要關心具體有多少分片。相似操做單機數據庫，用戶經過DDM管理控制檯進行數據庫運維，使用JDBC等驅動服務或SQL客戶端鏈接數據庫，進行數據讀寫。

DDM服務的業務架構圖示

分片是解決數據庫存儲容量限制的直接途徑。分片包括垂直分片與水平分片兩種方式。

垂直分片

垂直分片又叫縱向分割，即以邏輯表爲單位，把原有數據庫切分紅多個數據庫。切分後不一樣的表存儲在不一樣的數據庫上。

垂直分片與業務架構設計有密切的聯繫。好比從業務領域對系統進行架構優化，分紅多個子業務系統，各個子業務系統耦合度較低。子業務系統間以接口方式進行數據通訊和數據交換。垂直拆分後業務清晰，拆分規則明確，系統之間容易整合與擴展。通常用於數據庫上層架構設計。

垂直分片示意圖

水平分片

水平分片又叫橫向分割，即以邏輯表中的數據行記錄爲單位，把原有邏輯數據庫切分紅多個物理數據庫分片，表數據記錄分佈存儲在各個分片上。

水平分片主要用業務架構沒法繼續細分，而數據庫中單張表數據量太大，查詢性能降低的場景。經過水平分片，即解決單庫容量問題，同時提升併發查詢性能。

水平分片示意圖

DDM實現了自動水平分片，應用無需關心某個數據該存儲在哪一塊分片上。對邏輯表水平分片須要依據必定的分片規則，例如一個訂單跟蹤系統（見上圖），咱們選取訂單號(OrderId)做爲拆分鍵，分別對「訂單流水錶」、「訂單詳情表」以及「物流跟蹤表」進行水平拆分，拆分規則爲對鍵值Hash後求模，則分片計算規則以下：

H(Key(OrderId)) = Hash(Key(OrderId))%N

其中，N表示一共有N個數據分片，H(Key(OrderId))表示該訂單通過訂單號Hash並求模後存儲的分片編號。

分片後數據存儲示意圖

路由分發

路由分發與水平分片同爲DDM的基礎功能。在分佈式數據庫中，路由的做用即將SQL語句進行解析，並轉發到正確的分片上，保證SQL執行後獲得正確的結果，而且節約QPS資源。例如：訂單支付系統包含了shard0、shard一、shard2三個分片，訂單號2017010112345678的訂單數據存儲在shard0分片上，則應該將如下語句路由分發到shard0分片上執行。

select Customer, OrderStatus, CreateDate from Order

where OrderId = '2017010112345678';

若是同時路由到shard0、shard一、shard2三個分片，會形成多餘的查詢，浪費資源；若是路由到shard一、shard2分片，則得不到正確的返回結果。

DDM對單張表的路由解析流程以下：

單張表的路由解析流程

讀寫分離

數據庫中對計算和緩存資源消耗較多的每每是密集或複雜的SQL查詢。當系統資源被查詢語句消耗，反過來會影響數據寫入操做，進而致使數據庫總體性能降低，響應緩慢。所以，當數據庫CPU和內存資源佔用居高不下，且讀寫比例較高時，能夠爲數據庫添加只讀實例。

添加只讀實例的做用有如下：

一、將查詢非事務性查詢SQL路由到只讀實例中執行，主實例上執行事務性SQL，在很大程度上緩解主實例上的S鎖與X鎖的競爭。

二、對只讀實例上的表可配置不提供事務支持的數據庫引擎，進而提高查詢效率。

三、增長只讀實例，也至關於數據庫橫向擴展，直接增長負載能力，同時增長數據冗餘，確保數據庫高可用。

DDM服務實現了自動讀寫分離，用戶購買了RDS只讀實例後，將只讀實例信息同步到DDM中便可，無需再作其餘配置。同時，DDM支持用戶在SQL中自定義讀寫分離策略，具體用法請參考如何實現讀寫分離。

讀寫分離示意圖

平滑擴容

隨着業務增加，邏輯庫存儲空間不足，併發壓力較大，此時可對DDM實例邏輯庫進行平滑擴容，經過增長RDS實例來提升數據存儲能力與併發支持能力。

平滑擴容是一種水平擴容方式，經過增長RDS實例的數量來提高整體數據存儲容量，把分庫平滑擴容到新增長的RDS實例上，保證全部的數據都是均衡分佈在每一個分庫上，降單個RDS實例的處理壓力。平滑擴容原理以下圖所示。

平滑擴容原理

以上就是對分佈式數據庫中間件DDM實現原理的淺析，目前華爲雲DDM推出了免費體驗活動，想要了解更多，歡迎前往分佈式數據庫中間件查看。