腾讯分布式数据库DCCB

阅读量：2388 次

发布时间：2019-05-10

本文共 5611 字，大约阅读时间需要 18 分钟。

分布式数据库 DCDB 的优势

1.性能/容量线性增长

是天然的 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.丰富的逻辑表

对应用来说，读写数据完全透明，对业务呈现的表实际上是逻辑表。逻辑表屏蔽了物理层实际存储规则，业务无需关心数据层如何存储，只需要基于业务表应该如何设计。

为用户提供了三种类似的表分表，小表以及单表：

分表：是指那些原有的很大数据的表，需要切分到多个数据库的表，这样每个分片都有一部分数据，所有分片构成了完整的数据。

广播表：即又名小表广播功能，设置为广播表后，该表的所有操作都将广播到所有物理分片（set）中，每个分片都有改表的全量数据。

单表：主要用于存储一些无需分片的表：该表的数据全量存在第一个物理分片（set）中，所有该类型的表都放在第一个物理分片（set）中，语法和使用防范和mysql完全一样，您可以把他理解为一个非分布式的表。

4.高性能分布式事务

计划 2017 年 7 月支持

分布式事务，就是一个数据库事务在多个数据库实例上面执行，并且多个实例（分布式数据库上即多个分片）上面都执行了写入（insert/update/delete）操作。实现分布式事务处理的最大难点，就是在这些多个数据库实例上面实现统一的数据库事务的ACID保障，而这里面最重要的算法就是两阶段提交算法。分布式事务能力理论虽然很早就被提出，而业内实际工程化实现和大规模业务验证的产品还较少。

支持分布事务，可以为银行转账、电商交易等业务提供支持有效支持。当然，分布式事务处理的开销比会比单机架构事务处理开销要大一些，使用分布式事务会导致系统 TPS 降低，事务提交延时增大(我们不建议您分表上在分布式数据库上使用复杂的事务)。而腾讯 DCDB 通过多种优化，提供了高于开源 XA（分布式事务简称）的性能。

由于理论上，一个事务不会操作全部分片，仅操作1~2个分片（如转账业务），再加上的 MPP 架构的原因；因此一个分布式实例多个分片的分布式事务性能可以理论叠加（某些事务可能操作所有分片，会导致分片越多，性能反而下降）。

所以是否使用分布式事务要根据实际应用需求来定：数据量非常大或者数据访问负载非常高时，分布式事务会大大降低应用开发难度，DCDB 每个事务的查询语句的写法与使用单机架构实例完全相同，且获得事务的 ACID 保障。然而，业务中可能存在少量特别复杂的事务一次性操作所有分片，这势必会造成分布式事务性能的下降（若需要操作如此多数据，即使是单机实例耗时也会很长）；遇到这种情况，我们建议业务谨慎平衡性能和开发难度的关系，或将事务拆解，巧妙设计；或引入一些等待机制，以优化用户体验。

5. 灵活的读写分离

计划 2017 年 7 月支持

默认支持读写分离能力，架构中的每个从机都能支持只读能力，如果配置有多个从机，将由网关集群（TProxy）自动分配到低负载从机上，以支撑大型应用程序的读取流量；我们提供多种读写分离方案供您选择，且您无需关注若干从机是否完全存活，因为系统将根据策略自动调度

只读帐号：您仅需要在创建帐号时，标记为只读帐号，系统将根据策略向将读请求发往从机；

/slave/注释：您可以在编程过程中，通过注释/slave/，系统将把该条语句发往从机，常用于编程阶段将特殊的读逻辑嵌入代码。

通过多种只读方案的组合，您可以配置出复杂的只读方案，以满足您各种业务需求和开发的灵活性。

6.可应用于秒杀场景的热点更新能力

计划 2017 年 8 月支持

提供热点更新能力，可应用于秒杀或某些瞬时超大并发数据修改的业务场景。传统的方案是将商品库的子库前置在 cache 层或业务层，通过蜕化数据强一致（后通过第三方对账确保库存和抢购一致），而仅保证单个用户看到的库存减少规律一致（确保用户不会一会儿看见商品还有 10 个，过一会儿发现商品还剩 12 个导致投诉）。稍稍研究下，我们就会发现，这种实现方案相当复杂。而 DCDB 通过在数据库层直接实现热点更新能力来做到满足业务秒杀的需求，不仅减少了出错的概率，还提升了极大的开发效率。

7. 全局唯一数字序列

数据切分后，原有的关系数据库中的主键约束在分布式条件下将无法使用，因此需要引入外部机制保证数据唯一性标识，这种保证全局性的数据唯一标识的机制就是全局唯一数字序列（sequence）。
全局唯一数字序列（以下简称 sequence，使用的是 unsigned long 类型，8 个字节长），使用方法与 MySQL的AUTO_INCREMENT 类似。目前可以保证该字段全局唯一和有序递增，但不保证连续性。

8. 基于多租户闲时超用技术

公有云虚拟化让多个租户的业务共享物理设备性能，而传统隔离方案严格限制了每个租户实例的性能大小。这种限制方案很公平，但没有考虑到业务特点：大多数业务仅在一天（一月）的少数时刻有较大的业务压力（如下图）：该业务日 CPU 平均使用率仅 30%，而一天中仅存在 7 次业务压力较大，CPU 使用率在 80%~100%。虽然云能够基于弹性扩容，然而普通的弹性方案在这种突发性的压力面前，仍然无能为力——可能当您反应过来，您的业务峰值已过；最终，您还得基于业务峰值配置实例。

闲时超用技术，即在绝对保证每个实例预分配性能下限的基础上，允许实例使用超过预分配的性能。举个例子：假定 A 实例承载上海股票交易所的业务，B 实例是承载纳斯达克股票的业务，A、B 实例被分配到一台物理设备中，A可以在B的空闲时间，抢占（有限的，并发全部）一部分空闲性能。当然，A、B同时面对峰值时，我们确保 A 分配的 CPU 基本数量。相对于传统的方案，闲时超用是一种更加灵活的性能隔离方案，让您的业务在面对偶然性峰值时也能游刃有余。

当然，如果您不想使用多租户方案，而期望独享整个物理集群，也欢迎您咨询腾讯工作人员，了解

9.弹性扩展——自动再均衡技术

支持在线实时扩容，扩容方式分为新增分片和对现有分片扩容两种方式；DCDB 在线扩容仅需管理员到腾讯云WEB控制台点击付费即可，扩容过程对业务完全透明，无需业务停机。扩容时仅部分分片存在秒级的只读（或中断），整个集群不会受影响。

主要是采用自研的自动再均衡技术（rebalance）保证自动化的扩容和稳定，以新增分片为例，扩容过程如下下图：

若 A 节点（实际上可能有多个节点）存在性能和容量瓶颈，通过控制台点击新增分片

根据新加 G 节点配置，将 A 节点部分数据搬迁（从备机）到 G 节点。

数据完全同步后，AG 校验数据库，（存在1~几十秒的只读），但整个服务不会停止。

调度通知 proxy 切换路由。

为确保业务不停以及数据一致性，的整个迁移过程采用移存量数据、迁移增量数据、数据检验、再追增量、切换路由、清理六个步骤循环迭代进行。该能力经过腾讯内外海量业务迁移，至今未发生过一次数据异常错误或全集群停机。

应用场景

实时高并发交易场景：解决金融、红包、电商、O2O、零售等行业普遍存在用户基数大、并发高访问慢，制约业务发展的问题。

海量数据存储访问场景：面向物联网，交易订单等业务，业务数据增长迅猛，会产生超过单机数据库存储能力极限的数据，数据库实例超过TB级别且持续快速增长，造成数据库容量瓶颈，限制业务发展。

支持秒杀场景：支持电商、O2O 等存在的整点秒杀瞬时超高并发访问，超大数据写入，秒杀实时排队等等场景。

支持游戏全区全服：支持 SNS 经营养成类社交游戏；开房间类竞技类游戏；卡牌对战类游戏，等游戏全区全服，在线扩展，以及开房间等复杂玩法。

成为去O的中坚力量：企业的核心业务系统一般都是 OLTP 为主的应用场景，在这个领域，Oracle 一直是市场的领导者，在互联网领域，以 DCDB 为代表的分布式数据库应用非常广泛，用普通 x86 服务器，轻松支撑起上亿的用户访问，经过验证的好的分布式数据库在性能和稳定性上甚至高于用高端设备搭建的 Oracle RAC。当然，对于企业而言，由于 Oracle 数据库和上层应用绑定比较紧密，通常会使用到 Oracle 的存储过程、自定义函数、触发器，这就需要涉及到应用迁移，这个工作的工作量和时间周期通常较大，但综合计算下来，即使加上软件改造成本，采用 DCDB 的 TCO 仍然低于使用商业数据库，当前，不管是互联网和传统行业，去 O 的成功案例比比皆是。

分支业务聚合到总部：由于政务、银行、大型国企的组织架构通常采用总部-分部-分支的架构；因为各种原因，其某些核心IT系统建设也采用总部-分部-分支模式。随着业务互通，人员互通，信息互通等需求越来越强烈，业务逐渐向聚合。而业务聚合一个重要问题是数据库性能和容量无法承载。以某部委为例，其省级业务系统数据规模和性能已经在用最高端的商业数据库硬件承载。如果聚合到总部，一是设备性能扩无可扩，二是软件费用和硬件成本将会是天价。因此，到现在为止，不少业务也仅能做到数据汇总，而非业务聚合。DCDB 此类分布式数据库在微信支付、京东等超大规模业务的应用证明了，一个系统承载全国业务的可能性。