分布式數(shù)據(jù)庫 DCDB 的優(yōu)勢

1.性能/容量線性增長

DCDB?是天然的 MPP (Massively Parallel Processing，大規(guī)模并行處理系統(tǒng))架構(gòu)，這意味著隨著 DCDB 分片的增加，每個分片各自承擔(dān)一部分分布式任務(wù)，意味著并發(fā)性能、處理能力、存儲容量將線性增長。

并且?DCDB 默認采用線程池，且對調(diào)度算法進行了優(yōu)化，改進當(dāng)系統(tǒng)內(nèi)核處于重負載時，查詢和更新請求在線程組間分布不均衡等極端情況下性能，并且能夠更好地利用計算資源，減少無謂的線程切換，減少請求在隊列中的等待時間，及時處理請求。類似的內(nèi)核優(yōu)化還有很多，通過 sysbench 的壓力測試，DCDB 單個分片純寫入操作能超過 12 萬+TPS，純查詢操作能超過 48 萬 QPS，是 MySQL5.6 性能的 4 倍，MySQL5.7 的 2 倍以上，且騰訊云數(shù)據(jù)庫團體還在持續(xù)優(yōu)化。

2.高可用與強同步（MAR）

在生產(chǎn)系統(tǒng)中，通常都需要用高可用方案來保證系統(tǒng)不間斷運行；數(shù)據(jù)庫作為系統(tǒng)數(shù)據(jù)存儲和服務(wù)的核心能力，其可用要求高于計算服務(wù)資源。目前，數(shù)據(jù)庫的高可用方案通常是讓多個數(shù)據(jù)庫服務(wù)協(xié)同工作，當(dāng)一臺數(shù)據(jù)庫故障，余下的立即頂替上去工作，這樣就可以做到不中斷服務(wù)或只中斷很短時間；或者是讓多臺數(shù)據(jù)庫同時提供服務(wù)，用戶可以訪問任意一臺數(shù)據(jù)庫，當(dāng)其中一臺數(shù)據(jù)庫故障，立即更換訪問另外數(shù)據(jù)庫即可。

由于數(shù)據(jù)庫中記錄了數(shù)據(jù)，想要在多臺數(shù)據(jù)庫中切換，數(shù)據(jù)必須是同步的，所以數(shù)據(jù)同步技術(shù)是數(shù)據(jù)庫高可用方案的基礎(chǔ)；當(dāng)前，數(shù)據(jù)復(fù)制方式有以下三種方式：

• 異步復(fù)制：應(yīng)用發(fā)起更新（含增加、刪除、修改操作）請求，Master 完成相應(yīng)操作后立即響應(yīng)應(yīng)用，Master 向 Slave 異步復(fù)制數(shù)據(jù)。因此異步復(fù)制方式下， Slave 不可用不影響主庫上的操作，而 Master 不可用有概率會引起數(shù)據(jù)不一致。
• 強同步復(fù)制：應(yīng)用發(fā)起更新請求，Master 完成操作后向 Slave 復(fù)制數(shù)據(jù)，Slave 接收到數(shù)據(jù)后向 Master 返回成功信息，Master 接到 Slave 的反饋后再應(yīng)答給應(yīng)用。Master 向 Slave 復(fù)制數(shù)據(jù)是同步進行的，因此 Slave 不可用會影響 Master 上的操作，而 Master 不可用不會引起數(shù)據(jù)不一致。（使用“強同步”復(fù)制時，如果主庫與備庫自建網(wǎng)絡(luò)中斷或備庫出現(xiàn)問題，主庫也會被鎖住（hang）只讀，而此時如果只有一個主庫或一個備庫，那么是無法做高可用方案的。—— 因為單一服務(wù)器服務(wù)，如果股指則直接導(dǎo)致部分數(shù)據(jù)完全丟失，不符合強同步的設(shè)計初衷。）
• 半同步復(fù)制：半同步復(fù)制是 google 提出的一種同步方案，他的原理是正常情況下數(shù)據(jù)復(fù)制方式采用強同步復(fù)制方式，當(dāng) Master 向 Slave 復(fù)制數(shù)據(jù)出現(xiàn)異常的時候（Slave 不可用或者雙節(jié)點間的網(wǎng)絡(luò)異常）退化成異步復(fù)制。當(dāng)異常恢復(fù)后，異步復(fù)制會恢復(fù)成強同步復(fù)制。半同步復(fù)制意味著 Master 不可用有概率會較小概率引起數(shù)據(jù)不一致。

騰訊自主研發(fā)了的基于 MySQL 協(xié)議的異步多線程強同步復(fù)制方案（Multi-thread Asynchronous Replication MAR），簡單來說，MAR 強同步方案強同步技術(shù)具有以下特點：

• 一致性的同步復(fù)制，保證節(jié)點間數(shù)據(jù)強一致性；
• 對業(yè)務(wù)層面完全透明，業(yè)務(wù)層面無需做讀寫分離或同步強化工作；
• 將串行同步線程異步化，引入線程池能力，大幅度提高性能
• 支持集群架構(gòu)；
• 支持自動成員控制，故障節(jié)點自動從集群中移除；
• 支持自動節(jié)點加入，無需人工干預(yù)；
• 每個節(jié)點都包含完整的數(shù)據(jù)副本，可以隨時切換；
• 無需共享存儲設(shè)備

騰訊 MAR 方案強同步技術(shù)原理是，只有當(dāng)備機數(shù)據(jù)同步（日志）后，才由主機向應(yīng)用返回事務(wù)應(yīng)答，示意圖如下：

從性能上優(yōu)于其他主流同步方案，通過在同樣的測試方案下，我們發(fā)現(xiàn)其 MAR 技術(shù)性能優(yōu)于 MySQL 5.6 半同步約 5 倍（此處測試使用 sysbench 標(biāo)準用例測試）。

同步方案（跨IDC測試） 最大QPS（100并發(fā)水平） 平均耗時（ms）

MAR強同步	485624	26
MySQL 5.7 半同步	386513	32
MySQL 5.6 半同步	107200	42
DCDB 異步同步	486004	13
MySQL 5.7 異步同步	418186	12

3.豐富的邏輯表

DCDB?對應(yīng)用來說，讀寫數(shù)據(jù)完全透明，對業(yè)務(wù)呈現(xiàn)的表實際上是邏輯表。邏輯表屏蔽了物理層實際存儲規(guī)則，業(yè)務(wù)無需關(guān)心數(shù)據(jù)層如何存儲，只需要基于業(yè)務(wù)表應(yīng)該如何設(shè)計。

DCDB?為用戶提供了三種類似的表分表，小表以及單表：

• 分表：是指那些原有的很大數(shù)據(jù)的表，需要切分到多個數(shù)據(jù)庫的表，這樣每個分片都有一部分數(shù)據(jù)，所有分片構(gòu)成了完整的數(shù)據(jù)。
• 廣播表：即又名小表廣播功能，設(shè)置為廣播表后，該表的所有操作都將廣播到所有物理分片（set）中，每個分片都有改表的全量數(shù)據(jù)。
• 單表：主要用于存儲一些無需分片的表：該表的數(shù)據(jù)全量存在第一個物理分片（set）中，所有該類型的表都放在第一個物理分片（set）中，語法和使用防范和mysql完全一樣，您可以把他理解為一個非分布式的表。

4.高性能分布式事務(wù)

計劃 2017 年 7 月支持

分布式事務(wù)，就是一個數(shù)據(jù)庫事務(wù)在多個數(shù)據(jù)庫實例上面執(zhí)行，并且多個實例（分布式數(shù)據(jù)庫上即多個分片）上面都執(zhí)行了寫入（insert/update/delete） 操作。實現(xiàn)分布式事務(wù)處理的最大難點，就是在這些多個數(shù)據(jù)庫實例上面實現(xiàn)統(tǒng)一的數(shù)據(jù)庫事務(wù)的ACID保障，而這里面最重要的算法就是兩階段提交算法。分布式事務(wù)能力理論雖然很早就被提出，而業(yè)內(nèi)實際工程化實現(xiàn)和大規(guī)模業(yè)務(wù)驗證的產(chǎn)品還較少。

DCDB?支持分布事務(wù)，可以為銀行轉(zhuǎn)賬、電商交易等業(yè)務(wù)提供支持有效支持。當(dāng)然，分布式事務(wù)處理的開銷比會比單機架構(gòu)事務(wù)處理開銷要大一些，使用分布式事務(wù)會導(dǎo)致系統(tǒng) TPS 降低，事務(wù)提交延時增大(我們不建議您分表上在分布式數(shù)據(jù)庫上使用復(fù)雜的事務(wù))。而騰訊 DCDB 通過多種優(yōu)化，提供了高于開源 XA（分布式事務(wù)簡稱）的性能。

由于理論上，一個事務(wù)不會操作全部分片，僅操作1~2個分片（如轉(zhuǎn)賬業(yè)務(wù)），再加上?DCDB?的 MPP 架構(gòu)的原因；因此一個分布式實例多個分片的分布式事務(wù)性能可以理論疊加（某些事務(wù)可能操作所有分片，會導(dǎo)致分片越多，性能反而下降）。

所以是否使用分布式事務(wù)要根據(jù)實際應(yīng)用需求來定：數(shù)據(jù)量非常大或者數(shù)據(jù)訪問負載非常高時，分布式事務(wù)會大大降低應(yīng)用開發(fā)難度，DCDB 每個事務(wù)的查詢語句的寫法與使用單機架構(gòu)實例完全相同，且獲得事務(wù)的 ACID 保障。然而，業(yè)務(wù)中可能存在少量特別復(fù)雜的事務(wù)一次性操作所有分片，這勢必會造成分布式事務(wù)性能的下降（若需要操作如此多數(shù)據(jù)，即使是單機實例耗時也會很長）；遇到這種情況，我們建議業(yè)務(wù)謹慎平衡性能和開發(fā)難度的關(guān)系，或?qū)⑹聞?wù)拆解，巧妙設(shè)計；或引入一些等待機制，以優(yōu)化用戶體驗。

5. 靈活的讀寫分離

計劃 2017 年 7 月支持

DCDB?默認支持讀寫分離能力，架構(gòu)中的每個從機都能支持只讀能力，如果配置有多個從機，將由網(wǎng)關(guān)集群（TProxy）自動分配到低負載從機上，以支撐大型應(yīng)用程序的讀取流量；我們提供多種讀寫分離方案供您選擇，且您無需關(guān)注若干從機是否完全存活，因為系統(tǒng)將根據(jù)策略自動調(diào)度

• 只讀帳號：您僅需要在創(chuàng)建帳號時，標(biāo)記為只讀帳號，系統(tǒng)將根據(jù)策略向?qū)⒆x請求發(fā)往從機；
• /slave/注釋：您可以在編程過程中，通過注釋/slave/，系統(tǒng)將把該條語句發(fā)往從機，常用于編程階段將特殊的讀邏輯嵌入代碼。

通過多種只讀方案的組合，您可以配置出復(fù)雜的只讀方案，以滿足您各種業(yè)務(wù)需求和開發(fā)的靈活性。

6.可應(yīng)用于秒殺場景的熱點更新能力

計劃 2017 年 8 月支持

DCDB?提供熱點更新能力，可應(yīng)用于秒殺或某些瞬時超大并發(fā)數(shù)據(jù)修改的業(yè)務(wù)場景。傳統(tǒng)的方案是將商品庫的子庫前置在 cache 層或業(yè)務(wù)層，通過蛻化數(shù)據(jù)強一致（后通過第三方對賬確保庫存和搶購一致），而僅保證單個用戶看到的庫存減少規(guī)律一致（確保用戶不會一會兒看見商品還有 10 個，過一會兒發(fā)現(xiàn)商品還剩 12 個導(dǎo)致投訴）。稍稍研究下，我們就會發(fā)現(xiàn)，這種實現(xiàn)方案相當(dāng)復(fù)雜。而 DCDB 通過在數(shù)據(jù)庫層直接實現(xiàn)熱點更新能力來做到滿足業(yè)務(wù)秒殺的需求，不僅減少了出錯的概率，還提升了極大的開發(fā)效率。

7. 全局唯一數(shù)字序列

數(shù)據(jù)切分后，原有的關(guān)系數(shù)據(jù)庫中的主鍵約束在分布式條件下將無法使用，因此需要引入外部機制保證數(shù)據(jù)唯一性標(biāo)識，這種保證全局性的數(shù)據(jù)唯一標(biāo)識的機制就是全局唯一數(shù)字序列（sequence）。
DCDB?全局唯一數(shù)字序列（以下簡稱 sequence，使用的是 unsigned long 類型，8 個字節(jié)長），使用方法與 MySQL的AUTO_INCREMENT 類似。目前?DCDB?可以保證該字段全局唯一和有序遞增，但不保證連續(xù)性。

8. 基于多租戶閑時超用技術(shù)

公有云虛擬化讓多個租戶的業(yè)務(wù)共享物理設(shè)備性能，而傳統(tǒng)隔離方案嚴格限制了每個租戶實例的性能大小。這種限制方案很公平，但沒有考慮到業(yè)務(wù)特點：大多數(shù)業(yè)務(wù)僅在一天（一月）的少數(shù)時刻有較大的業(yè)務(wù)壓力（如下圖）： 該業(yè)務(wù)日 CPU 平均使用率僅 30%，而一天中僅存在 7 次業(yè)務(wù)壓力較大，CPU 使用率在 80%~100%。雖然云能夠基于彈性擴容，然而普通的彈性方案在這種突發(fā)性的壓力面前，仍然無能為力——可能當(dāng)您反應(yīng)過來，您的業(yè)務(wù)峰值已過；最終，您還得基于業(yè)務(wù)峰值配置實例。

閑時超用技術(shù)，即在絕對保證每個實例預(yù)分配性能下限的基礎(chǔ)上，允許實例使用超過預(yù)分配的性能。舉個例子：假定 A 實例承載上海股票交易所的業(yè)務(wù)，B 實例是承載納斯達克股票的業(yè)務(wù)，A、B 實例被分配到一臺物理設(shè)備中，A可以在B的空閑時間，搶占（有限的，并發(fā)全部）一部分空閑性能。當(dāng)然，A、B同時面對峰值時，我們確保 A 分配的 CPU 基本數(shù)量。相對于傳統(tǒng)的方案，閑時超用是一種更加靈活的性能隔離方案，讓您的業(yè)務(wù)在面對偶然性峰值時也能游刃有余。

當(dāng)然，如果您不想使用多租戶方案，而期望獨享整個物理集群，也歡迎您咨詢騰訊工作人員，了解獨享集群數(shù)據(jù)庫

9.彈性擴展——自動再均衡技術(shù)

DCDB?支持在線實時擴容，擴容方式分為新增分片和對現(xiàn)有分片擴容兩種方式；DCDB 在線擴容僅需管理員到騰訊云WEB控制臺點擊付費即可，擴容過程對業(yè)務(wù)完全透明，無需業(yè)務(wù)停機。擴容時僅部分分片存在秒級的只讀（或中斷），整個集群不會受影響。

DCDB?主要是采用自研的自動再均衡技術(shù)（rebalance）保證自動化的擴容和穩(wěn)定，以新增分片為例，擴容過程如下下圖：

若 A 節(jié)點（實際上可能有多個節(jié)點）存在性能和容量瓶頸，通過控制臺點擊新增分片

根據(jù)新加 G 節(jié)點配置，將 A 節(jié)點部分數(shù)據(jù)搬遷（從備機）到 G 節(jié)點。

數(shù)據(jù)完全同步后，AG 校驗數(shù)據(jù)庫，（存在1~幾十秒的只讀），但整個服務(wù)不會停止。

調(diào)度通知 proxy 切換路由。

為確保業(yè)務(wù)不停以及數(shù)據(jù)一致性，DCDB?的整個遷移過程采用移存量數(shù)據(jù)、遷移增量數(shù)據(jù)、數(shù)據(jù)檢驗、再追增量、切換路由、清理 六個步驟循環(huán)迭代進行。該能力經(jīng)過騰訊內(nèi)外海量業(yè)務(wù)遷移，至今未發(fā)生過一次數(shù)據(jù)異常錯誤或全集群停機。

應(yīng)用場景

• 實時高并發(fā)交易場景：解決金融、紅包、電商、O2O、零售等行業(yè)普遍存在用戶基數(shù)大、并發(fā)高訪問慢，制約業(yè)務(wù)發(fā)展的問題。

• 海量數(shù)據(jù)存儲訪問場景：面向物聯(lián)網(wǎng)，交易訂單等業(yè)務(wù)，業(yè)務(wù)數(shù)據(jù)增長迅猛，會產(chǎn)生超過單機數(shù)據(jù)庫存儲能力極限的數(shù)據(jù)，數(shù)據(jù)庫實例超過TB級別且持續(xù)快速增長，造成數(shù)據(jù)庫容量瓶頸，限制業(yè)務(wù)發(fā)展。

• 支持秒殺場景：支持電商、O2O 等存在的整點秒殺瞬時超高并發(fā)訪問，超大數(shù)據(jù)寫入，秒殺實時排隊等等場景。

• 支持游戲全區(qū)全服：支持 SNS 經(jīng)營養(yǎng)成類社交游戲；開房間類競技類游戲；卡牌對戰(zhàn)類游戲，等游戲全區(qū)全服，在線擴展，以及開房間等復(fù)雜玩法。

• 成為去O的中堅力量：企業(yè)的核心業(yè)務(wù)系統(tǒng)一般都是 OLTP 為主的應(yīng)用場景，在這個領(lǐng)域，Oracle 一直是市場的領(lǐng)導(dǎo)者，在互聯(lián)網(wǎng)領(lǐng)域，以 DCDB 為代表的分布式數(shù)據(jù)庫應(yīng)用非常廣泛，用普通 x86 服務(wù)器，輕松支撐起上億的用戶訪問，經(jīng)過驗證的好的分布式數(shù)據(jù)庫在性能和穩(wěn)定性上甚至高于用高端設(shè)備搭建的 Oracle RAC。當(dāng)然，對于企業(yè)而言，由于 Oracle 數(shù)據(jù)庫和上層應(yīng)用綁定比較緊密，通常會使用到 Oracle 的存儲過程、自定義函數(shù)、觸發(fā)器，這就需要涉及到應(yīng)用遷移，這個工作的工作量和時間周期通常較大，但綜合計算下來，即使加上軟件改造成本，采用 DCDB 的 TCO 仍然低于使用商業(yè)數(shù)據(jù)庫，當(dāng)前，不管是互聯(lián)網(wǎng)和傳統(tǒng)行業(yè)，去 O 的成功案例比比皆是。

• 分支業(yè)務(wù)聚合到總部：由于政務(wù)、銀行、大型國企的組織架構(gòu)通常采用總部-分部-分支的架構(gòu)；因為各種原因，其某些核心IT系統(tǒng)建設(shè)也采用總部-分部-分支模式。隨著業(yè)務(wù)互通，人員互通，信息互通等需求越來越強烈，業(yè)務(wù)逐漸向聚合。而業(yè)務(wù)聚合一個重要問題是數(shù)據(jù)庫性能和容量無法承載。以某部委為例，其省級業(yè)務(wù)系統(tǒng)數(shù)據(jù)規(guī)模和性能已經(jīng)在用最高端的商業(yè)數(shù)據(jù)庫硬件承載。如果聚合到總部，一是設(shè)備性能擴無可擴，二是軟件費用和硬件成本將會是天價。因此，到現(xiàn)在為止，不少業(yè)務(wù)也僅能做到數(shù)據(jù)匯總，而非業(yè)務(wù)聚合。DCDB 此類分布式數(shù)據(jù)庫在微信支付、京東等超大規(guī)模業(yè)務(wù)的應(yīng)用證明了，一個系統(tǒng)承載全國業(yè)務(wù)的可能性。

展望

分布式數(shù)據(jù)庫?DCDB?未來將支持更多優(yōu)秀特性以適應(yīng)不同的業(yè)務(wù)場景。我們的目標(biāo)是您的業(yè)務(wù)僅需要 2 個數(shù)據(jù)庫就夠了，一個用來部署正式業(yè)務(wù)，不增加存儲成本基礎(chǔ)上，能涵蓋 OLTP&OLAP 場景，且可以覆蓋多種數(shù)據(jù)類型；另一個，一個用來部署您的測試環(huán)境，用于新版本開發(fā)。

總結(jié)

以上是生活随笔為你收集整理的腾讯分布式数据库DCCB的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。