對話DDM：分佈式數據庫中間件全解析

進入雲計算時代，傳統的數據庫在性能和容量等方面已沒法知足企業的要求，隨着數據量的不斷驟增，易於擴展、拆分的數據庫解決方案對於企業的雲化轉型更是顯得尤其重要。爲使企業應用上雲更簡單，分佈式數據庫中間件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充分利用雲化的優點，提供了對實例、邏輯庫、邏輯表、分片算法等的全面圖形化界面操做。同時能夠在線查看慢SQL等監控內容，方便對系統進行鍼對性的性能調優。

將來DDM會往什麼方向發展？

DDM將來方向對分佈式事務、分佈式查詢能力加強、性能的優化等，考慮到有些特性實現若是隻從中間件層面實現會限制比較多。DDM會經過與數據庫底層的修改進行配合，一塊兒提供更優秀的特性來知足用戶的業務需求。