分布式數據庫 DCDB 的優勢

1.性能/容量線性增長

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

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

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

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

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

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

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

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

騰訊 MAR 方案強同步技術原理是，只有當備機數據同步（日志）后，才由主機向應用返回事務應答，示意圖如下：

從性能上優于其他主流同步方案，通過在同樣的測試方案下，我們發現其 MAR 技術性能優于 MySQL 5.6 半同步約 5 倍（此處測試使用 sysbench 標準用例測試）。

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

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

3.豐富的邏輯表

DCDB?對應用來說，讀寫數據完全透明，對業務呈現的表實際上是邏輯表。邏輯表屏蔽了物理層實際存儲規則，業務無需關心數據層如何存儲，只需要基于業務表應該如何設計。

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

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

4.高性能分布式事務

計劃 2017 年 7 月支持

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

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

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

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

5. 靈活的讀寫分離

計劃 2017 年 7 月支持

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

• 只讀帳號：您僅需要在創建帳號時，標記為只讀帳號，系統將根據策略向將讀請求發往從機；
• /slave/注釋：您可以在編程過程中，通過注釋/slave/，系統將把該條語句發往從機，常用于編程階段將特殊的讀邏輯嵌入代碼。

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

6.可應用于秒殺場景的熱點更新能力

計劃 2017 年 8 月支持

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

7. 全局唯一數字序列

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

8. 基于多租戶閑時超用技術

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

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

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

9.彈性擴展——自動再均衡技術

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

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

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

根據新加 G 節點配置，將 A 節點部分數據搬遷（從備機）到 G 節點。

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

調度通知 proxy 切換路由。

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

應用場景

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

• 海量數據存儲訪問場景：面向物聯網，交易訂單等業務，業務數據增長迅猛，會產生超過單機數據庫存儲能力極限的數據，數據庫實例超過TB級別且持續快速增長，造成數據庫容量瓶頸，限制業務發展。

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

• 支持游戲全區全服：支持 SNS 經營養成類社交游戲；開房間類競技類游戲；卡牌對戰類游戲，等游戲全區全服，在線擴展，以及開房間等復雜玩法。

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

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

展望

分布式數據庫?DCDB?未來將支持更多優秀特性以適應不同的業務場景。我們的目標是您的業務僅需要 2 個數據庫就夠了，一個用來部署正式業務，不增加存儲成本基礎上，能涵蓋 OLTP&OLAP 場景，且可以覆蓋多種數據類型；另一個，一個用來部署您的測試環境，用于新版本開發。

總結

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

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。