進入雲計算時代，傳統的資料庫在效能和容量等方面已無法滿足企業的要求，隨著資料量的不斷驟增，易於擴充套件、拆分的資料庫解決方案對於企業的雲化轉型更是顯得尤為重要。為使企業應用上雲更簡單，分布式資料庫中介軟體ddm（distributed database middleware）專注解決企業在上雲過程中面臨的的資料庫瓶頸難題，不但更能輕鬆滿足水平拆分、擴容、讀寫分離等業務需求，同時也比傳統方案更具價效比。接下來讓我們一起零距離解密ddm。
ddm是什麼？
ddm專注於解決資料庫分布式擴充套件問題，它突破了傳統資料庫的容量和效能瓶頸，實現海量資料高併發訪問。ddm提供了對應用透明的資料庫讀寫分離、自動的資料分片、靈活的彈性伸縮等分布式資料庫能力。
ddm如何定義讀寫分離？
從資料庫的角度來說，對於大多數應用來說，從集中到分布，最基本的乙個需求不是資料儲存的瓶頸，而是在於計算的瓶頸，即sql查詢的瓶頸，在沒有讀寫分離的系統上，很可能高峰時段的一些複雜sql查詢就導致資料庫系統陷入癱瘓，從保護資料庫的角度來說，我們應該盡量避免沒有主從複製機制的單節點資料庫。傳統讀寫分離解決方案耦合應用**，擴容讀節點或修改讀寫分離策略等需要修改應用**，公升級應用程式，非常複雜。ddm實現了透明讀寫分離，應用實現讀寫分離不需要修改**，為了保證讀一致性， 預設情況在事務中的讀全部分發到主節點。事務外的讀分發從節點。寫分發主節點。在應用程式需求複雜時，ddm提供了hint可由程式自主控制sql的讀寫分離邏輯。此外，後端db如果部分節點故障了，ddm會自動摘除故障節點，自動進行主從切換，對應用無感知。
( 附改造前後構架對比圖)
應用在微服務架構下，服務會拆分的比原來更多，與資料庫的連線數也會增加很多，這是否同樣是分布式資料庫中介軟體需要解決的乙個重要問題？
對的。舉個栗子，比如某應用的最大連線數是2000，未做服務化拆分前，應用程式獨享2000個資料連線，假設拆分成100個微服務，那麼為了保證總的連線數不超過mysql的最大連線數，那麼每個微服務能配置的最大連線數就是20.這對應用幾乎是不可接受。市面上很多分庫分表中介軟體如cobar、atlas等，對後端mysql的連線池管理是基於分片來實現的，而不具備整個mysql例項的共享互通，抗併發能力被嚴重削弱。而ddm是真正基於mysql例項模式實現的，乙個mysql例項下的所有資料庫共享乙個連線池。這個對於分片來講，能避免有些庫的連線很空閒，有些庫的連線不夠用的情況，最大限度提高並行性。其中涉及到session級別的屬性由ddm自動維護，應用程式無感知。
在這種共享模式下連線數有上限嗎？
ddm的前端連線與mysql連線對比起來相對輕量級，可以相對輕鬆支援上萬的連線。當然，為了防止單個使用者濫用資源，支援設定前端最大連線數限制。
( 附改造前後構架對比圖)
在應用場景上，是否一定要用ddm的方式去解決？這裡同樣也有硬體公升級、資料庫自身的分割槽方案，該如何選擇？
硬體方案由於成本高和擴充套件性差的問題在這裡就不談了，而資料庫自身的分割槽表方案，只能侷限在乙個庫內，資料無法跨庫跨例項，擴充套件方案有限，db故障和調整都需要應用同步調整，運維難度劇增，公升級維護工作量大，小型系統還好，對於大型系統不可接受，長期來看採用分布式資料庫中介軟體是解決之道。
ddm如何做分片設計？
對於分布式資料庫中介軟體，業內普遍有以下兩種做法，第一種，認為分片演算法的選擇對使用者來說是一種心智負擔，應該對使用者完全隱藏，另外一種觀點認為應該給使用者完全自由去選擇，比如一些開源軟體，提供了十幾種分片演算法。ddm認為如果完全隱藏分片欄位和分片演算法的選擇，可能會造成不必要的全表掃瞄，浪費資源，無法做到線性擴充套件。因為最了解業務的還是使用者自己。分片演算法過多的確會帶來選擇上的負擔，有些演算法存在主要是因為缺少平滑擴容存在的不得已而為之。ddm設計了三種標準分片演算法，hash、range、list，後續酌情開放自定義演算法。
能不能給大家詳細介紹下這三種演算法？
1. hash：hash演算法的特點的資料分布比較均勻，無熱點問題，缺點是如果有針對部分範圍的查詢，需要全分片掃瞄。hash類資料擴容需要遷移資料，ddm有平滑擴容功能，所以這塊不用擔心。
2. range：資料按數字範圍或者日期範圍進行分片，針對範圍的查詢可以並行，但是缺點範圍是單個範圍可能會有熱點問題，比如按日期最近乙個月的資料操作會比較多，按範圍就只其中一台或少量幾台機器可以負擔操作。範圍分片在擴容時不需要遷移資料，只需要將新範圍配置到新加的rds即可。
3. list：列舉分片可以看做range的乙個特例，在此不再贅述。
hash演算法的設計？
hash演算法的設計，主要考慮到與平滑擴容的配合，採用二級對映分片規則，主要為了方便控制slot到實際datanode的對映關係，而一致性雜湊這裡是演算法固定。
與傳統方案相比，ddm在擴容上有什麼獨特的優勢？
傳統做法dba手工遷移資料，要停機，影響業務，遷移過程可能會出錯。業內很多中介軟體的實現擴容方式一般是按照整庫遷移的方案，比如原先有8個分庫，遷移只是將部分庫整庫遷移到新的rds上，這樣的弊端是分片個數並沒有增加。ddm的做法是真正實現了資料重分布，按slot為單位遷移資料，遷移完成後保證資料的大致分布均勻。分片個數隨著新增rds而自動增加。ddm在操作上真正做到了自動化，實現了一鍵式遷移，遷移過程中切換路由、清理資料均是自動化完成，不需要使用者時刻盯著再去操作。即使遷移中出現異常，也會自動回滾，保證遷移資料的一致性。遷移過程中不阻塞業務，只在切換路由時短暫中斷寫入操作，讀操作正常，而且只影響到被遷移的那部分資料的寫入，對其他資料完全沒有影響。
( 附遷移流程圖)
在路由切換速度和內容準確性上ddm有哪些考慮？
關於切換路由速度，雖然業內很多號稱毫秒級，一般是省略了資料校驗，或者只校驗條數。號稱是演算法精巧已經測試比較充分了。ddm認為即使測試已經充分了也難以保證百分之一百保證不出問題。所以ddm通過設計了快速的校驗演算法，對資料的內容進行校驗，即使資料有一點點不一樣，演算法也能校驗出來，同時充分利用了rds的計算能力提高校驗的速度。
在一般的大型應用裡，有的表資料量很大，有的表資料量少且不怎麼更新，ddm是如何做到不同型別場景的支援？
針對業務會遇到的實際場景，ddm設計了三種表型別：分片表：針對那些資料量很大的表，需要切分到多個分片庫的表，這樣每個分片都有一部分資料，所有分片構成了完整的資料；單錶：針對資料量相對比較少，沒有和其他分片表join查詢的需求。單錶資料儲存在預設當乙個分片上，這種設計可以盡量相容單錶自身的複雜查詢；全域性表：針對資料量和更新都比較少，但是和其它分片表有join的需求。全域性表每個分片上儲存乙份完全一樣的資料，這樣可以解決與分片表的join直接下推到rds上執行。
在分布式條件下，原有資料庫中的主鍵約束將無法使用，是不是需要引入外部機制保證資料唯一性標識，那麼這種全域性唯一序列ddm是如何保證的呢？
ddm 全域性唯一序列，使用方法與 mysql的auto_increment 類似。目前 ddm 可以保證該欄位全域性唯一和有序遞增，但不保證連續性。目前ddm設計了2種型別的序列機制，db和time。db方式的序列是指通過db來實現，需要注意步長的設定，步長直接關係到序列的效能，步長的大小決定了一次批量取序列的大小。time序列使用了時間戳加機器編號的生成方式，好處是無需通訊即可保證唯一性。
ddm在運維監控方面的優勢？
未來ddm會往什麼方向發展？
ddm未來方向對分布式事務、分布式查詢能力增強、效能的優化等，考慮到有些特性實現如果只從中介軟體層面實現會限制比較多。ddm會通過與資料庫底層的修改進行配合，一起提供更優秀的特性來滿足使用者的業務需求。
對話DDM 分布式資料庫中介軟體全解析
進入雲計算時代，傳統的資料庫在效能和容量等方面已無法滿足企業的要求，隨著資料量的不斷驟增，易於擴充套件 拆分的資料庫解決方案對於企業的雲化轉型更是顯得尤為重要。為使企業應用上雲更簡單，分布式資料庫中介軟體ddm distributed database middleware 專注解決企業在上雲過程中...
分布式資料庫中介軟體DDM的實現原理
隨著資料量不斷增大，傳統的架構模式難以解決業務量不斷增長所帶來的問題，特別是在業務成線性 甚至指數級上公升的情況。此時我們不得不通過水平擴充套件，把資料庫放到不同伺服器上來解決問題，也就是我們說的資料庫中介軟體。作為資料庫中介軟體，分布式資料庫中介軟體ddm將底層資料庫儲存引擎以集群方式管理起來，使...
分布式資料庫中介軟體DDM如何配置讀寫分離詳細教程
ddm支援配置rds讀策略，您可以根據資料讀取壓力負載情況，登入ddm管理控制台 rds匯入管理 更多 設定rds讀策略 合理配置rds讀策略，提高查詢效能,更多詳情請到華為雲官網，目前有試用體驗活動哦。rds讀策略分為四種，詳情如下表所示。表1讀策略詳細資訊 rds讀策略 全讀主 均衡讀 唯讀例項...