進(jìn)入云計(jì)算時(shí)代增拥，傳統(tǒng)的數(shù)據(jù)庫(kù)在性能和容量等方面已無法滿足企業(yè)的要求犬钢，隨著數(shù)據(jù)量的不斷驟增，易于擴(kuò)展兄猩、拆分的數(shù)據(jù)庫(kù)解決方案對(duì)于企業(yè)的云化轉(zhuǎn)型更是顯得尤為重要。為使企業(yè)應(yīng)用上云更簡(jiǎn)單，分布式數(shù)據(jù)庫(kù)中間件DDM（Distributed Database Middleware）專注解決企業(yè)在上云過程中面臨的的數(shù)據(jù)庫(kù)瓶頸難題枢冤，不但更能輕松滿足水平拆分鸠姨、擴(kuò)容、讀寫分離等業(yè)務(wù)需求淹真，同時(shí)也比傳統(tǒng)方案更具性價(jià)比讶迁。接下來讓我們一起零距離解密DDM。
DDM是什么核蘸？
DDM專注于解決數(shù)據(jù)庫(kù)分布式擴(kuò)展問題巍糯，它突破了傳統(tǒng)數(shù)據(jù)庫(kù)的容量和性能瓶頸，實(shí)現(xiàn)海量數(shù)據(jù)高并發(fā)訪問客扎。DDM提供了對(duì)應(yīng)用透明的數(shù)據(jù)庫(kù)讀寫分離祟峦、自動(dòng)的數(shù)據(jù)分片、靈活的彈性伸縮等分布式數(shù)據(jù)庫(kù)能力徙鱼。
DDM如何定義讀寫分離宅楞？
從數(shù)據(jù)庫(kù)的角度來說，對(duì)于大多數(shù)應(yīng)用來說袱吆，從集中到分布厌衙，最基本的一個(gè)需求不是數(shù)據(jù)存儲(chǔ)的瓶頸，而是在于計(jì)算的瓶頸绞绒，即SQL查詢的瓶頸婶希，在沒有讀寫分離的系統(tǒng)上，很可能高峰時(shí)段的一些復(fù)雜SQL查詢就導(dǎo)致數(shù)據(jù)庫(kù)系統(tǒng)陷入癱瘓处铛，從保護(hù)數(shù)據(jù)庫(kù)的角度來說饲趋，我們應(yīng)該盡量避免沒有主從復(fù)制機(jī)制的單節(jié)點(diǎn)數(shù)據(jù)庫(kù)。傳統(tǒng)讀寫分離解決方案耦合應(yīng)用代碼撤蟆，擴(kuò)容讀節(jié)點(diǎn)或修改讀寫分離策略等需要修改應(yīng)用代碼奕塑，升級(jí)應(yīng)用程序，非常復(fù)雜家肯。DDM實(shí)現(xiàn)了透明讀寫分離龄砰，應(yīng)用實(shí)現(xiàn)讀寫分離不需要修改代碼，為了保證讀一致性讨衣， 默認(rèn)情況在事務(wù)中的讀全部分發(fā)到主節(jié)點(diǎn)换棚。事務(wù)外的讀分發(fā)從節(jié)點(diǎn)。寫分發(fā)主節(jié)點(diǎn)反镇。在應(yīng)用程序需求復(fù)雜時(shí)固蚤，DDM提供了hint可由程序自主控制sql的讀寫分離邏輯。此外歹茶，后端DB如果部分節(jié)點(diǎn)故障了夕玩，DDM會(huì)自動(dòng)摘除故障節(jié)點(diǎn)你弦，自動(dòng)進(jìn)行主從切換燎孟，對(duì)應(yīng)用無感知禽作。
應(yīng)用在微服務(wù)架構(gòu)下，服務(wù)會(huì)拆分的比原來更多揩页，與數(shù)據(jù)庫(kù)的連接數(shù)也會(huì)增加很多旷偿，這是否同樣是分布式數(shù)據(jù)庫(kù)中間件需要解決的一個(gè)重要問題？
對(duì)的爆侣。舉個(gè)栗子萍程，比如某應(yīng)用的最大連接數(shù)是2000，未做服務(wù)化拆分前累提，應(yīng)用程序獨(dú)享2000個(gè)數(shù)據(jù)連接尘喝，假設(shè)拆分成100個(gè)微服務(wù)，那么為了保證總的連接數(shù)不超過MySQL的最大連接數(shù)斋陪，那么每個(gè)微服務(wù)能配置的最大連接數(shù)就是20.這對(duì)應(yīng)用幾乎是不可接受。市面上很多分庫(kù)分表中間件如Cobar置吓、Atlas等无虚，對(duì)后端MySQL的連接池管理是基于分片來實(shí)現(xiàn)的，而不具備整個(gè)MySQL實(shí)例的共享互通衍锚，抗并發(fā)能力被嚴(yán)重削弱友题。而DDM是真正基于MySQL實(shí)例模式實(shí)現(xiàn)的，一個(gè)MySQL實(shí)例下的所有數(shù)據(jù)庫(kù)共享一個(gè)連接池戴质。這個(gè)對(duì)于分片來講度宦，能避免有些庫(kù)的連接很空閑，有些庫(kù)的連接不夠用的情況告匠，最大限度提高并行性戈抄。其中涉及到session級(jí)別的屬性由DDM自動(dòng)維護(hù)，應(yīng)用程序無感知后专。
在這種共享模式下連接數(shù)有上限嗎划鸽？
DDM的前端連接與MySQL連接對(duì)比起來相對(duì)輕量級(jí)，可以相對(duì)輕松支持上萬的連接戚哎。當(dāng)然裸诽，為了防止單個(gè)用戶濫用資源，支持設(shè)置前端最大連接數(shù)限制型凳。
在應(yīng)用場(chǎng)景上丈冬，是否一定要用DDM的方式去解決？這里同樣也有硬件升級(jí)甘畅、數(shù)據(jù)庫(kù)自身的分區(qū)方案埂蕊，該如何選擇实夹？
硬件方案由于成本高和擴(kuò)展性差的問題在這里就不談了，而數(shù)據(jù)庫(kù)自身的分區(qū)表方案粒梦，只能局限在一個(gè)庫(kù)內(nèi)亮航，數(shù)據(jù)無法跨庫(kù)跨實(shí)例，擴(kuò)展方案有限匀们，DB故障和調(diào)整都需要應(yīng)用同步調(diào)整缴淋，運(yùn)維難度劇增，升級(jí)維護(hù)工作量大泄朴，小型系統(tǒng)還好重抖，對(duì)于大型系統(tǒng)不可接受，長(zhǎng)期來看采用分布式數(shù)據(jù)庫(kù)中間件是解決之道祖灰。
DDM如何做分片設(shè)計(jì)钟沛？
對(duì)于分布式數(shù)據(jù)庫(kù)中間件，業(yè)內(nèi)普遍有以下兩種做法局扶，第一種恨统，認(rèn)為分片算法的選擇對(duì)用戶來說是一種心智負(fù)擔(dān)，應(yīng)該對(duì)用戶完全隱藏三妈，另外一種觀點(diǎn)認(rèn)為應(yīng)該給用戶完全自由去選擇畜埋，比如一些開源軟件，提供了十幾種分片算法畴蒲。DDM認(rèn)為如果完全隱藏分片字段和分片算法的選擇悠鞍，可能會(huì)造成不必要的全表掃描，浪費(fèi)資源模燥，無法做到線性擴(kuò)展咖祭。因?yàn)樽盍私鈽I(yè)務(wù)的還是用戶自己。分片算法過多的確會(huì)帶來選擇上的負(fù)擔(dān)蔫骂，有些算法存在主要是因?yàn)槿鄙倨交瑪U(kuò)容存在的不得已而為之么翰。DDM設(shè)計(jì)了三種標(biāo)準(zhǔn)分片算法，hash纠吴、range硬鞍、list，后續(xù)酌情開放自定義算法戴已。
能不能給大家詳細(xì)介紹下這三種算法固该？
1. hash：hash算法的特點(diǎn)的數(shù)據(jù)分布比較均勻，無熱點(diǎn)問題糖儡，缺點(diǎn)是如果有針對(duì)部分范圍的查詢伐坏，需要全分片掃描。hash類數(shù)據(jù)擴(kuò)容需要遷移數(shù)據(jù)握联，DDM有平滑擴(kuò)容功能桦沉，所以這塊不用擔(dān)心每瞒。
2. range：數(shù)據(jù)按數(shù)字范圍或者日期范圍進(jìn)行分片，針對(duì)范圍的查詢可以并行纯露，但是缺點(diǎn)范圍是單個(gè)范圍可能會(huì)有熱點(diǎn)問題剿骨，比如按日期最近一個(gè)月的數(shù)據(jù)操作會(huì)比較多，按范圍就只其中一臺(tái)或少量幾臺(tái)機(jī)器可以負(fù)擔(dān)操作埠褪。范圍分片在擴(kuò)容時(shí)不需要遷移數(shù)據(jù)浓利，只需要將新范圍配置到新加的RDS即可。
3. list：枚舉分片可以看做range的一個(gè)特例钞速，在此不再贅述贷掖。
hash算法的設(shè)計(jì)？
hash算法的設(shè)計(jì)渴语，主要考慮到與平滑擴(kuò)容的配合苹威，采用二級(jí)映射分片規(guī)則，主要為了方便控制slot到實(shí)際dataNode的映射關(guān)系驾凶，而一致性哈希這里是算法固定牙甫。
與傳統(tǒng)方案相比，DDM在擴(kuò)容上有什么獨(dú)特的優(yōu)勢(shì)狭郑？
傳統(tǒng)做法DBA手工遷移數(shù)據(jù)腹暖，要停機(jī)，影響業(yè)務(wù)翰萨，遷移過程可能會(huì)出錯(cuò)。業(yè)內(nèi)很多中間件的實(shí)現(xiàn)擴(kuò)容方式一般是按照整庫(kù)遷移的方案糕殉，比如原先有8個(gè)分庫(kù)亩鬼，遷移只是將部分庫(kù)整庫(kù)遷移到新的RDS上，這樣的弊端是分片個(gè)數(shù)并沒有增加阿蝶。DDM的做法是真正實(shí)現(xiàn)了數(shù)據(jù)重分布雳锋，按slot為單位遷移數(shù)據(jù)，遷移完成后保證數(shù)據(jù)的大致分布均勻羡洁。分片個(gè)數(shù)隨著新增RDS而自動(dòng)增加玷过。DDM在操作上真正做到了自動(dòng)化，實(shí)現(xiàn)了一鍵式遷移筑煮，遷移過程中切換路由辛蚊、清理數(shù)據(jù)均是自動(dòng)化完成，不需要用戶時(shí)刻盯著再去操作真仲。即使遷移中出現(xiàn)異常袋马，也會(huì)自動(dòng)回滾，保證遷移數(shù)據(jù)的一致性秸应。遷移過程中不阻塞業(yè)務(wù)虑凛，只在切換路由時(shí)短暫中斷寫入操作碑宴，讀操作正常，而且只影響到被遷移的那部分?jǐn)?shù)據(jù)的寫入桑谍，對(duì)其他數(shù)據(jù)完全沒有影響延柠。
?
在路由切換速度和內(nèi)容準(zhǔn)確性上DDM有哪些考慮？
關(guān)于切換路由速度锣披，雖然業(yè)內(nèi)很多號(hào)稱毫秒級(jí)贞间，一般是省略了數(shù)據(jù)校驗(yàn)，或者只校驗(yàn)條數(shù)盈罐。號(hào)稱是算法精巧已經(jīng)測(cè)試比較充分了榜跌。DDM認(rèn)為即使測(cè)試已經(jīng)充分了也難以保證百分之一百保證不出問題。所以DDM通過設(shè)計(jì)了快速的校驗(yàn)算法盅粪，對(duì)數(shù)據(jù)的內(nèi)容進(jìn)行校驗(yàn)钓葫，即使數(shù)據(jù)有一點(diǎn)點(diǎn)不一樣，算法也能校驗(yàn)出來票顾，同時(shí)充分利用了RDS的計(jì)算能力提高校驗(yàn)的速度础浮。
在一般的大型應(yīng)用里，有的表數(shù)據(jù)量很大奠骄，有的表數(shù)據(jù)量少且不怎么更新豆同，DDM是如何做到不同類型場(chǎng)景的支持？
針對(duì)業(yè)務(wù)會(huì)遇到的實(shí)際場(chǎng)景含鳞，DDM設(shè)計(jì)了三種表類型：分片表：針對(duì)那些數(shù)據(jù)量很大的表影锈，需要切分到多個(gè)分片庫(kù)的表，這樣每個(gè)分片都有一部分?jǐn)?shù)據(jù)蝉绷，所有分片構(gòu)成了完整的數(shù)據(jù)鸭廷；單表：針對(duì)數(shù)據(jù)量相對(duì)比較少，沒有和其他分片表join查詢的需求熔吗。單表數(shù)據(jù)保存在默認(rèn)當(dāng)一個(gè)分片上辆床，這種設(shè)計(jì)可以盡量兼容單表自身的復(fù)雜查詢；全局表：針對(duì)數(shù)據(jù)量和更新都比較少桅狠，但是和其它分片表有join的需求讼载。全局表每個(gè)分片上保存一份完全一樣的數(shù)據(jù)，這樣可以解決與分片表的join直接下推到RDS上執(zhí)行中跌。
?
在分布式條件下咨堤，原有數(shù)據(jù)庫(kù)中的主鍵約束將無法使用，是不是需要引入外部機(jī)制保證數(shù)據(jù)唯一性標(biāo)識(shí)晒他，那么這種全局唯一序列DDM是如何保證的呢吱型？
DDM 全局唯一序列，使用方法與 MySQL的AUTO_INCREMENT 類似陨仅。目前 DDM 可以保證該字段全局唯一和有序遞增津滞，但不保證連續(xù)性铝侵。目前DDM設(shè)計(jì)了2種類型的序列機(jī)制，DB和TIME触徐。DB方式的序列是指通過DB來實(shí)現(xiàn)咪鲜，需要注意步長(zhǎng)的設(shè)置，步長(zhǎng)直接關(guān)系到序列的性能撞鹉，步長(zhǎng)的大小決定了一次批量取序列的大小疟丙。TIME序列使用了時(shí)間戳加機(jī)器編號(hào)的生成方式，好處是無需通訊即可保證唯一性鸟雏。
DDM在運(yùn)維監(jiān)控方面的優(yōu)勢(shì)享郊？
DDM: 采用傳統(tǒng)中間件運(yùn)維完全需要自己運(yùn)維，一般中間件專注核心功能孝鹊，較少考慮運(yùn)維和圖形化界面的操作炊琉。DDM充分利用云化的優(yōu)勢(shì)，提供了對(duì)實(shí)例又活、邏輯庫(kù)苔咪、邏輯表、分片算法等的全面圖形化界面操作柳骄。同時(shí)可以在線查看慢SQL等監(jiān)控內(nèi)容团赏，方便對(duì)系統(tǒng)進(jìn)行針對(duì)性的性能調(diào)優(yōu)。
?
未來DDM會(huì)往什么方向發(fā)展耐薯？
DDM未來方向?qū)Ψ植际绞聞?wù)舔清、分布式查詢能力增強(qiáng)、性能的優(yōu)化等曲初，考慮到有些特性實(shí)現(xiàn)如果只從中間件層面實(shí)現(xiàn)會(huì)限制比較多鸠踪。DDM會(huì)通過與數(shù)據(jù)庫(kù)底層的修改進(jìn)行配合，一起提供更優(yōu)秀的特性來滿足用戶的業(yè)務(wù)需求复斥。
