深度解析：腾讯云分布式数据库DCDB

这些问题，腾讯全部遇到过

我们知道，集中式（单机）数据库在存储容量、并发性能、快速扩容等都会因业务增长而达到瓶颈。而在业务发展初期，团队很难准确预测数据库增长的速度和规模，只有靠拍脑袋确定规模进行设备选型：

• 若达不到预期，会导致资源浪费；
• 若超过预期，则会出现扩展难题；
• 若成为行业领先，那么性能瓶颈又摆在了面前。
• 还有集中式数据库一系列容灾、恢复、管理等一系列问题，都让人糟心。
  

多数情况下，互联网业务往往都会超出预期，随之而来的问题就令人头疼了。为解决上述问题，腾讯数据库团队曾经选择多种方向，也考察过商业数据库基于共享存储的体系架构（RAC）。我们发现，RAC架构无法通过增加计算节点来“线性的”提升数据库集群性能，因为共享存储的体系架构中多个节点对同一个数据块有对等访问权限，这就意味着所有数据都是全局资源，任何节点在操作数据时必须加锁以防止其它节点的干扰，为了协调节点间的访问，就必须通过密集的消息通信来传递资源锁。在传统企业IT（内部ERP、OA）等系统上，这样的问题并不明显；然而当其面对的是互联网海量处理应用是，这种资源锁机制严重限制了RAC架构的扩展能力。其次，从运营成本角度上讲，商业数据库高昂的授权费用、昂贵的硬件成本，都制约了业务的快速发展。因此，腾讯最终选择了分布式数据库方案。

时至今日，放眼互联网行业，排名靠前企业的核心业务都在使用分布式数据库，我们不禁要问，这其中有什么秘密？

分布式数据库为什么能解决容量、并发、扩展等难题

了解分布式数据库，需要先了解垂直切分（分库）、水平切分（分表）两种方案：

• 垂直切分(通常也叫做“分库”)也就是按功能切分数据库，这种切分方法跟业务紧密相关，实施思路也比较直接，比如“京东JD”等电商平台，一个原有一个数据库实例，按功能切分为会员数据库、商品数据库、交易数据库、物流数据库等多个数据库实例，共同承担业务压力。有时候，垂直拆分并不能彻底解决压力问题，因为单台数据库服务器的负载和容量也是有限的，随着业务发展势必也会成为瓶颈，解决这些问题的常见方案就是水平切分了。
• 水平切分（又叫做“分表”）是按照某种规则，将一个表的数据分散到多个物理独立的数据库服务器中，这些“独立”的数据库“分片”；多个分片组成一个逻辑完整的数据库实例。一般来说，分表的前提是分库。
  
  

水平拆分的方案，实际上是分布式数据库的基础原理，他的每个节点都参与计算和数据存储，而且每个节点都仅计算和存储一部分数据。因此，无论业务的规模如何增长，我们仅需要在分布式集群中不断的添加设备，用新设备去应对增长的计算和存储需要就够了。

腾讯云分布式数据库DCDB

腾讯云分布式数据库（DCDB）是部署在腾讯云上的一种，面向OLTP业务支持自动水平拆分（分表）的share nothing架构的分布式数据库。DCDB也是随着腾讯业务规模不断扩大而发展起来的，从2004年开始，腾讯部分业务就已经开始遇到单机数据库架构已经无法支撑，进而开始研究分布式架构，业务发展最终推动了数据库架构技术的不断革新，面对日益复杂的需求。截止到2017年，包括微信支付，腾讯充值，阅文集团等腾讯公司交易、转账等核心系统90%以上都使用了腾讯分布式数据库（DCDB）。

DCDB的前身是腾讯自研TDSQL，我们的设计理念是淡化复杂的拆分、扩展等逻辑，让开发者使用DCDB就像使用集中式单机数据库一样顺利。

当前，DCDB已支持MySQL 5.7、5.6（基于Percona、MariaDB分支），未来计划进一步支持PostgreSQL引擎（基于腾讯自研PostgreSQL-XZ分布式引擎）等。

DCDB整个集群架构简图如下图，这种集群架构极大简化了各个节点之间的通信机制，也简化了对于硬件的需求，这就意味着即使是简单的x86服务器，也可以搭建出类似于小型机、共享存储等一样稳定可靠的数据库。

大多数情况下，可以用您熟悉的对象映射框架使用DCDB。对于分表，建议您尽量使用基础的SQL语句，因为这样能达到最佳性能，特别是几亿甚至几百亿条记录的情况下。这意味着，某些情况下，您可能需要一定的改造，才可以接入DCDB。

分布式数据库DCDB的分表方案

关系型数据库是一个二维模型，数据的切分通常就需要找到一个分表字段（shardkey）以确定拆分维度，再通过定义规则来实现数据库的拆分。业内的几种常见的分表规则如下：

• 基于日期顺序（Time），如按年拆分，2015年一个分表，2016年一个分表。
• 基于某字段划分范围（Range），如按用户ID划分，0~1000一个分表，1001~2000一个分表。
• 基于某字段求模（HASH），将求模后的值，再按Range方式分散到不同库中。
  

无论是Time、Range都有个主要缺点就是可能导致严重数据倾斜，即多个物理节点（又叫做分片）之间负载和数据容量严重不均衡。在大部分数据库系统中，数据都有明显的冷热特征——显然当前的订单被访问的概率比半年前的订单要高的多（更热）——而采用Time分表或range分表，就意味大部分热数据将会被路由在少数几个分表中，而存储冷数据的设备性能却被浪费掉了。

因此，DCDB通常采用某个字段求模（HASH）的方案进行分表，而计算HASH的某个字段就叫做shardkey。因为HASH算法本身就能够基本保证数据相对均匀的分散在不同的物理设备中（某些特殊情况下除外，我们将在后续章节进行介绍）。

HASH的过程大致就是，当某条记录(SQL)请求时被发起时，DCDB 会理解 SQL 语句的含义，然后按照拆分键的值和执行策略将 SQL 路由到对应分表进行执行，如下图所示，先通过hash算法计算，再路由到各个节点上。

而如果一个查询 SQL 语句的数据涉及到多个分表，此时SQL会被路由到多个分表执行，DCDB 会将各个分表返回的数据按照原始 SQL 语义进行合并，并将最终结果返回给用户。

读取数据时（如果有明确shardkey值）：

• 业务发送select请求中含有shardkey时，网关通过对shardkey进行hash
• 不同的hash值范围对应不同的分表
• 数据根据分表算法，将数据从对应的分表中取出
  

读取数据时（如果没有明确shardkey值）：

• 业务发送select请求没有shardkey时，将请求发往所有分表
• 各个分表查询自身内容，发回Proxy；
• Proxy根据SQL规则，对数据进行聚合，再答复给网关
  

从上述原理来看，查询SQL中含有shardkey值比不含shardkey值效率将会更高。

如何选择拆分键

拆分键是在水平拆分过程中用于生成拆分规则的数据表字段，必须在建表时就指定好。DCDB建议拆分键要尽可能找到数据表中的数据在业务逻辑上的主体，并确定大部分（或核心的）数据库操作都是围绕这个主体的数据进行，然后可使用该主体对应的字段作为拆分键进行分表，该分表方案通常叫做groupshard（按组分表），如下图：

Groupshard方案，可以确保不同分表的某些关联数据和复杂的业务逻辑运算，可以聚合到一个物理分片内，进而减轻分布式数据库本身一些使用缺陷。例如，某电商平台订单表和用户表都是基于用户维度（UserID）拆分，平台就可以很容易的通过联合查询（不会存在跨节点join，或分布式事务）快速计算某个用户近期产生了多少订单。
下面的一些典型选择拆分键的应用场景：

• 面向用户的互联网应用，都是围绕用户维度来做各种操作，那么业务逻辑主体就是用户，可使用用户对应的字段作为拆分键；
• 电商应用或O2O应用，都是围绕卖家/买家维度来进行各种操作，那么业务逻辑主体就是卖家/买家，可使用卖家/买家对应的字段作为拆分键；但请注意，某些情况下几个超大卖家占到绝大多数交易额，这种情况会导致某几个分片的负载和压力明显高于其他分片，我们会在后面章节予以说明。
• 游戏类的应用，是围绕玩家维度来做各种操作，那么业务逻辑主体就是玩家，可使用玩家对应的字段作为拆分键；
• 物联网方面的应用，则是基于物联信息进行操作，那么业务逻辑主体就是传感器/SIM卡，可使用传感器、独立设备、SIM卡的IMEI作为对应的字段作为拆分键；
• 税务/工商类/社保的应用，主要是基于纳税人/法人/居民的信息来开展前台业务，那么业务逻辑主体就是纳税人/法人，可使用纳税人/法人对应的字段作为拆分键。
• 以此类推，其它类型的应用场景，大多也能找到合适的业务逻辑主体作为拆分键的选择。
  

拆分键的限制

为了提高语法解析效率，避免因为shardkey设置导致路由错误，DCDB规定了拆分键设定的技术限制（请参考腾讯云官方文档）：

• 如存在主键或者唯一索引，则shardkey字段必须是主键以及所有唯一索引的一部分；
• shardkey字段的类型必须是int,bigint,smallint,char,varchar；
• shardkey字段的值尽量使用ascii码，网关不会转换字符集，所以不同字符集可能会路由到不同的分区（且尽量不要有中文）；
• 不能update shardkey字段的值，如必须则先delete，再insert；
• shardkey= 放在create语句的最后面，如下示例：mysql> create table test.right ( a int not null,b int not null, c char(20) not null,primary key(a,b) ,unique key(a,c)) shardkey=a;Query OK, 0 rows affected (0.12 sec)
• 访问数据尽量都能带上shardkey字段，可以极大的提升效率；
  

上一章节我们介绍了腾讯云分布式数据库的发展历史，基本原理和使用方法；本章节我们继续分析下分布式数据库 DCDB 的优势和应用场景。

分布式数据库 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 不可用或者双节点间的网络异常）退化成异步复制。当异常恢复后，异步复制会恢复成强同步复制。半同步复制意味着 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 场景，且可以覆盖多种数据类型；另一个，一个用来部署您的测试环境，用于新版本开发。

作者：腾讯云数据库团队  来自：腾讯云