上一章節我們介紹了騰訊雲分布式資料庫的發展曆史，基本原理和使用方法；本章節我們繼續分析下分布式資料庫 DCDB 的優勢和應用場景。
DCDB 是天然的 MPP (Massively Parallel Processing，大規模并行處理系統)架構，這意味着随着 DCDB 分片的增加，每個分片各自承擔一部分分布式任務，意味着并發性能、處理能力、存儲容量将線性增長。
并且 DCDB 預設采用線程池，且對排程算法進行了優化，改進當系統核心處于重負載時，查詢和更新請求線上程組間分布不均衡等極端情況下性能，并且能夠更好地利用計算資源，減少無謂的線程切換，減少請求在隊列中的等待時間，及時處理請求。類似的核心優化還有很多，通過 sysbench 的壓力測試，DCDB 單個分片純寫入操作能超過 12 萬+TPS，純查詢操作能超過 48 萬 QPS，是 MySQL5.6 性能的 4 倍，MySQL5.7 的 2 倍以上，且騰訊雲資料庫團體還在持續優化。
在生産系統中，通常都需要用高可用方案來保證系統不間斷運作；資料庫作為系統資料存儲和服務的核心能力，其可用要求高于計算服務資源。目前，資料庫的高可用方案通常是讓多個資料庫服務協同工作，當一台資料庫故障，餘下的立即頂替上去工作，這樣就可以做到不中斷服務或隻中斷很短時間；或者是讓多台資料庫同時提供服務，使用者可以通路任意一台資料庫，當其中一台資料庫故障，立即更換通路另外資料庫即可。
由于資料庫中記錄了資料，想要在多台資料庫中切換，資料必須是同步的，是以資料同步技術是資料庫高可用方案的基礎；目前，資料複制方式有以下三種方式：
異步複制：應用發起更新（含增加、删除、修改操作）請求，Master 完成相應操作後立即響應應用，Master 向 Slave 異步複制資料。是以異步複制方式下， Slave 不可用不影響主庫上的操作，而 Master 不可用有機率會引起資料不一緻。
強同步複制：應用發起更新請求，Master 完成操作後向 Slave 複制資料，Slave 接收到資料後向 Master 傳回成功資訊，Master 接到 Slave 的回報後再應答給應用。Master 向 Slave 複制資料是同步進行的，是以 Slave 不可用會影響 Master 上的操作，而 Master 不可用不會引起資料不一緻。（使用“強同步”複制時，如果主庫與備庫自建網絡中斷或備庫出現問題，主庫也會被鎖住（hang）隻讀，而此時如果隻有一個主庫或一個備庫，那麼是無法做高可用方案的。—— 因為單一伺服器服務，如果股指則直接導緻部分資料完全丢失，不符合強同步的設計初衷。）
半同步複制：半同步複制是 google 提出的一種同步方案，他的原理是正常情況下資料複制方式采用強同步複制方式，當 Master 向 Slave 複制資料出現異常的時候（Slave 不可用或者雙節點間的網絡異常）退化成異步複制。當異常恢複後，異步複制會恢複成強同步複制。半同步複制意味着 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
DCDB 對應用來說，讀寫資料完全透明，對業務呈現的表實際上是邏輯表。邏輯表屏蔽了實體層實際存儲規則，業務無需關心資料層如何存儲，隻需要基于業務表應該如何設計。
DCDB 為使用者提供了三種類似的表分表，小表以及單表：
分表：是指那些原有的很大資料的表，需要切分到多個資料庫的表，這樣每個分片都有一部分資料，所有分片構成了完整的資料。
廣播表：即又名小表廣播功能，設定為廣播表後，該表的所有操作都将廣播到所有實體分片（set）中，每個分片都有改表的全量資料。
單表：主要用于存儲一些無需分片的表：該表的資料全量存在第一個實體分片（set）中，所有該類型的表都放在第一個實體分片（set）中，文法和使用防範和mysql完全一樣，您可以把他了解為一個非分布式的表。
計劃 2017 年 7 月支援
分布式事務，就是一個資料庫事務在多個資料庫執行個體上面執行，并且多個執行個體（分布式資料庫上即多個分片）上面都執行了寫入（insert/update/delete） 操作。實作分布式事務處理的最大難點，就是在這些多個資料庫執行個體上面實作統一的資料庫事務的ACID保障，而這裡面最重要的算法就是兩階段送出算法。分布式事務能力理論雖然很早就被提出，而業内實際工程化實作和大規模業務驗證的産品還較少。
DCDB 支援分布事務，可以為銀行轉賬、電商交易等業務提供支援有效支援。當然，分布式事務處理的開銷比會比單機架構事務處理開銷要大一些，使用分布式事務會導緻系統 TPS 降低，事務送出延時增大(我們不建議您分表上在分布式資料庫上使用複雜的事務)。而騰訊 DCDB 通過多種優化，提供了高于開源 XA（分布式事務簡稱）的性能。
由于理論上，一個事務不會操作全部分片，僅操作1~2個分片（如轉賬業務），再加上 DCDB 的 MPP 架構的原因；是以一個分布式執行個體多個分片的分布式事務性能可以理論疊加（某些事務可能操作所有分片，會導緻分片越多，性能反而下降）。
是以是否使用分布式事務要根據實際應用需求來定：資料量非常大或者資料通路負載非常高時，分布式事務會大大降低應用開發難度，DCDB 每個事務的查詢語句的寫法與使用單機架構執行個體完全相同，且獲得事務的 ACID 保障。然而，業務中可能存在少量特别複雜的事務一次性操作所有分片，這勢必會造成分布式事務性能的下降（若需要操作如此多資料，即使是單機執行個體耗時也會很長）；遇到這種情況，我們建議業務謹慎平衡性能和開發難度的關系，或将事務拆解，巧妙設計；或引入一些等待機制，以優化使用者體驗。
DCDB 預設支援讀寫分離能力，架構中的每個從機都能支援隻讀能力，如果配置有多個從機，将由網關叢集（TProxy）自動配置設定到低負載從機上，以支撐大型應用程式的讀取流量；我們提供多種讀寫分離方案供您選擇，且您無需關注若幹從機是否完全存活，因為系統将根據政策自動排程
隻讀帳号：您僅需要在建立帳号時，标記為隻讀帳号，系統将根據政策向将讀請求發往從機；
/slave/注釋：您可以在程式設計過程中，通過注釋/slave/，系統将把該條語句發往從機，常用于程式設計階段将特殊的讀邏輯嵌入代碼。
通過多種隻讀方案的組合，您可以配置出複雜的隻讀方案，以滿足您各種業務需求和開發的靈活性。
計劃 2017 年 8 月支援
DCDB 提供熱點更新能力，可應用于秒殺或某些瞬時超大并發資料修改的業務場景。傳統的方案是将商品庫的子庫前置在 cache 層或業務層，通過蛻化資料強一緻（後通過第三方對賬確定庫存和搶購一緻），而僅保證單個使用者看到的庫存減少規律一緻（確定使用者不會一會兒看見商品還有 10 個，過一會兒發現商品還剩 12 個導緻投訴）。稍稍研究下，我們就會發現，這種實作方案相當複雜。而 DCDB 通過在資料庫層直接實作熱點更新能力來做到滿足業務秒殺的需求，不僅減少了出錯的機率，還提升了極大的開發效率。
資料切分後，原有的關系資料庫中的主鍵限制在分布式條件下将無法使用，是以需要引入外部機制保證資料唯一性辨別，這種保證全局性的資料唯一辨別的機制就是全局唯一數字序列（sequence）。
DCDB 全局唯一數字序列（以下簡稱 sequence，使用的是 unsigned long 類型，8 個位元組長），使用方法與 MySQL的AUTO_INCREMENT 類似。目前 DCDB 可以保證該字段全局唯一和有序遞增，但不保證連續性。
公有雲虛拟化讓多個租戶的業務共享實體裝置性能，而傳統隔離方案嚴格限制了每個租戶執行個體的性能大小。這種限制方案很公平，但沒有考慮到業務特點：大多數業務僅在一天（一月）的少數時刻有較大的業務壓力（如下圖）： 該業務日 CPU 平均使用率僅 30%，而一天中僅存在 7 次業務壓力較大，CPU 使用率在 80%~100%。雖然雲能夠基于彈性擴容，然而普通的彈性方案在這種突發性的壓力面前，仍然無能為力——可能當您反應過來，您的業務峰值已過；最終，您還得基于業務峰值配置執行個體。
閑時超用技術，即在絕對保證每個執行個體預配置設定性能下限的基礎上，允許執行個體使用超過預配置設定的性能。舉個例子：假定 A 執行個體承載上海股票交易所的業務，B 執行個體是承載納斯達克股票的業務，A、B 執行個體被配置設定到一台實體裝置中，A可以在B的空閑時間，搶占（有限的，并發全部）一部分空閑性能。當然，A、B同時面對峰值時，我們確定 A 配置設定的 CPU 基本數量。相對于傳統的方案，閑時超用是一種更加靈活的性能隔離方案，讓您的業務在面對偶然性峰值時也能遊刃有餘。
當然，如果您不想使用多租戶方案，而期望獨享整個實體叢集，也歡迎您咨詢騰訊從業人員，了解獨享叢集資料庫
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 場景，且可以覆寫多種資料類型；另一個，一個用來部署您的測試環境，用于新版本開發。