TDSQL分布式金融级数据库架构

TDSQL(Titan Distribute SQL) —一种分布式数据库之容灾篇一、传统的分库分表及由此引入的问题由于业务数据量巨大以至于无法单表存储，于是，我们习惯了分库分表的方式。

最常用的莫过于按照QQ号的后三位分1000表，除此之外，还有按照大区分表，按照时间分表，等等。

于是我们习惯了下面这样一种SVR与DB交互的架构结构。

图1—传统的分库分表存储这个我们习以为常的数据库存储结构，其实包含了一些问题，本篇将主要讨论主备一致性切换问题，并给出TDSQL主备切换的方式。

问题如下：1、主备的异步同步，在主机宕机的情况下，无法保证数据已经同步到了备机。

2、人工切换，则对DBA同学的实时处理提出非常高的要求。

3、自动切换，可能出现不同SVR对于主DB的健康状态判断不一致，造成不同SVR把数据写入到不同DB的情况即——脑裂。

4、即使通过仲裁节点来统一调度SVR连向主DB或者备DB，如果流程处理的不好，也可能因为SVR感知切换的时间差在短时间内造成脑裂。

如何解决上面的问题，业界给出了很多的方案，例如国外有Galera这种通过协议插件来实现一致性的方案（但这种方案在跨IDC时的性能非常差），国内也有阿里RDS，TDDL，360的atlas中间件，但上述的方案要么在主备切换的一致性，要么在主动切换，要么在性能上都会有或多或少的问题，因此我们在参考上述方案的基础上实现了今天要给大家介绍的方案Titan Distribute SQL —TDSQL。

二、TDSQL主备切换方案2.1 TDSQL容灾架构图二、TDSQL容灾架构图二是一个大家熟悉的具备调度能力的分布式集群，下面分别来介绍一个各个模块的作用及如何互动。

DB——图中的绿色部分，是集群的核心部分，也就是mysql节点。

为了实现主备的强一致性和较高的性能，这里必须使用我们在Mariadb 基础上进行二次开发的MySQL。

注意，只有主DB提供写服务，其它DB会被Agent自动设置成只读。

金融级分布式数据库架构设计目录1.行业背景 (3)2.数据库分布式改造的途径 (3)3.分布式数据库总体架构 (4)4.两阶段提交的问题 (5)5.CAP与BASE的抉择 (7)6.raft的优势 (8)6.1. Leader选举 (9)6.2. 日志复制 (10)6.3. 安全性 (11)7.分布式数据库如何实现PITR (16)1.行业背景银行业从最初的手工记账到会计电算化，到金融电子化，再到现在的金融科技，可以看到金融与科技的结合越来越紧密，人工智能、大数据、物联网、区块链等新兴技术改变了金融的交易方式，为金融行业的创新前行提供了源源不断的动力。

同时互联网金融的兴起是一把双刃剑，带来了机遇的同时也带来了挑战。

普惠金融使得金融的门槛降低，更多的普通大众参与到金融活动中，这让金融信息系统承受了越来越大的压力。

于是我们可以看到大型商业银行、保险公司、证券公司、交易所等核心交易系统都在纷纷进行分布式改造，其中数据库作为有状态的应用，成为了信息系统中唯一的单点，承担了所有来自上层应用的压力。

随着数据库瓶颈的凸显，进行分布式改造迫在眉睫。

2.数据库分布式改造的途径数据库进行分布式改造主要有三种途径：分布式访问客户端、分布式访问中间件、分布式数据库。

由于其分布式能力实现在不同的层次（应用层、中间层、数据库层），对应用程序有不同的侵入程度，其中分布式访问客户端对应用侵入性最大，改造难度最大，而分布式数据库方案对应用侵入性最小，但是架构设计及研发难度最大。

3.分布式数据库总体架构其实当前市面上的分布式数据库总体架构都是类似的，由必不可缺的三个组件组成：接入节点、数据节点、全局事务管理器。

总体架构如下，协调节点负责sql解析，生成分布式执行计划，sql转发，数据汇总等；数据节点负责数据存储与运算；全局事务管理器负责全局事务号的生成，保证事务的全局一致性。

这个架构或多或少都受到了google spanner F1论文的影响，这篇文章主要分析了这几个组件在实现上有什么难点，该如何进行架构设计。

TDSQL分布式数据库服务产品概述目录产品简介产品概述 (4)简介 (4)解决问题 (4)单机数据库瓶颈 (4)应用层分片开发工作量大 (4)开源方案或 NoSQL 难题 (4)产品优势 (6)超高性能 (6)专业可靠 (6)简单易用 (6)应用场景 (7)大型应用（超高并发实时交易场景） (7)物联网数据（PB 级数据存储访问场景） (7)文件索引（万亿行数据毫秒级存取） (7)高性价比商业数据库解决方案 (7)基本原理水平分表 (9)概述 (9)水平切分 (9)写入数据（ SQL 语句含有 shardkey ） (11)数据聚合 (12)读取数据（有明确 shardkey 值） (12)读取数据（无明确 shardkey 值） (12)读写分离 (14)功能简介 (14)基本原理 (14)只读账号 (14)弹性拓展 (15)概述 (15)扩容过程 (15)新增分片扩容 (15)现有分片扩容 (15)强同步 (17)背景 (17)存在问题 (17)解决方案 (17)实例架构 (19)地域选择 (20)产品简介产品概述19-11-19 10:36:08简介分布式数据库 TDSQL（TencentDB for TDSQL，TDSQL）是部署在腾讯云上的一种支持自动水平拆分、Shared Nothing 架构的分布式数据库。

分布式数据库即业务获取的是完整的逻辑库表，而后端会将库表均匀的拆分到多个物理分片节点。

TDSQL 默认部署主备架构，提供容灾、备份、恢复、监控、迁移等全套解决方案，适用于 TB 或 PB 级的海量数据库场景。

解决问题单机数据库瓶颈面对互联网类业务百万级以上的用户量，单机数据库由于硬件和软件的限制，数据库在数据存储容量、访问容量、容灾等方面都会随着业务的增长而到达瓶颈。

TDSQL 目前单分片最大可支持6TB存储，如果性能或容量不足以支撑业务发展时，在控制台自动升级扩容。

升级过程中，您无需关心分布式系统内的数据迁移，均衡和路由切换。

分布式数据库TDSQL架构原理概述TDSQL（TiDB Distributed SQL）是一个分布式数据库架构，它是由PingCAP公司开发的一款开源数据库。

TDSQL具有强一致性、高可用性和水平可扩展性的特点，适用于大规模、高并发的数据存储和处理需求。

TDSQL的架构原理主要包括三个方面：存储层、计算层和协调层。

存储层是TDSQL的核心组件，它负责数据的存储和管理。

存储层采用分布式存储的方式，将数据分成多个分片，并将每个分片复制到不同的节点上，以保证数据的冗余和可靠性。

存储层采用Raft协议保证数据的一致性，通过多副本和强一致性保证数据的可靠性和持久性。

此外，存储层还支持水平扩展，可以根据需求增加节点来扩展存储容量和处理能力。

计算层是TDSQL的查询和计算引擎，它负责接收用户的查询请求，并将请求转化为分布式查询任务。

计算层采用分布式查询的方式，将一个查询任务拆分成多个子任务，并将子任务分配给不同的节点进行并行处理。

计算层通过调度和协调各个节点上的计算任务，最终将结果返回给用户。

计算层采用分布式索引和分布式事务的方式，使得在大规模数据查询和处理中依然能够保持较高的性能和可用性。

协调层是TDSQL的调度和管理中心，它负责监控和管理存储层和计算层的状态，并进行资源调度和任务分配。

协调层采用分布式锁和容错机制，确保系统的高可用性和故障容忍性。

协调层还支持动态负载均衡和自动故障转移，可以根据负载和节点状态动态管理和分配资源，提高系统的性能和可用性。

协调层也负责处理用户的请求和权限管理，对外提供统一的接口和服务。

总结起来，TDSQL的架构原理基于分布式存储、计算和协调的方式，实现了数据的分片和复制、任务的并行和调度、资源的管理和负载均衡，并通过分布式事务和索引保证了数据的一致性和性能。

通过这种设计，TDSQL能够满足大规模、高并发的数据存储和处理需求，提供高可靠性、高可用性和高扩展性的分布式数据库解决方案。

TDSQL核心架构TDSQL（Tencent Distributed SQL）是腾讯公司自主研发的一种分布式关系型数据库系统，其核心架构是基于传统关系数据库的基础上进行扩展和优化而成。

它采用分布式存储和计算的方式，通过将数据切分和分片存储在多个节点上，实现了数据的高可用性和横向扩展能力。

1. 存储引擎（Storage Engine）：存储引擎是TDSQL的核心组件，负责管理数据的存储和读写。

TDSQL采用了分布式存储的方式，将数据切分成多个片段，每个片段存储在不同的节点上。

存储引擎通过管理这些片段的分布和复制，实现了数据的高可用性和负载均衡。

2. 查询引擎（Query Engine）：查询引擎负责解析和执行用户的SQL查询请求。

它将查询分解成多个子查询，并将这些子查询发送到存储引擎上执行。

查询引擎还负责进行查询优化，通过选择最优的执行计划来提高查询的性能。

3. 分布式事务管理器（Distributed Transaction Manager）：分布式事务管理器负责管理分布式数据库系统中的事务。

它使用分布式事务协议来协调不同节点上的事务操作，并保证数据的一致性和隔离性。

分布式事务管理器还负责恢复和回滚失败的事务，并处理并发冲突。

4. 元数据管理器（Metadata Manager）：元数据管理器负责管理数据库的元数据。

它包括表、列、索引等数据库对象的定义和关联关系。

元数据管理器还负责数据的分布和复制策略的管理，以及数据对应关系的调整和优化。

5. 外部连接管理器（External Connection Manager）：外部连接管理器负责管理TDSQL与外部系统的连接。

它支持与其他数据库、消息队列等系统的数据交互，并提供数据同步和数据迁移的功能。

外部连接管理器还支持分布式事务和跨节点查询的功能。

总之，TDSQL的核心架构是基于传统关系数据库的基础上扩展和优化而成的分布式关系数据库系统。

通过将数据切分和分片存储在多个节点上，以及采用分布式事务管理和查询优化的技术，实现了数据的高可用性和横向扩展能力。

作为金融场景下不可或缺的数据强一致性的保障。

们将从四个方面来聊一聊数据一致性的保障：1.主备数据复制2.数据复制比较：TDSQL主备数据复制方案 VS MySQL原生方案3.核心功能：容灾切换，数据强一致、0丢失0出错4.数据强一致性TDSQL主备数据复制：高性能强同步首先在讲数据一致性之前，们先了解一下MySQL原生的数据复制的。

首先种异步复制：主机在不等从机应答直接返回客户端成功。

这个在金融场景不能接受的，这样的话相当于数据没有多副本保障。

第二种半同步：主机在一定条件下等备机应答，如果等不到备机应答，它还会返回成功，也就说它最终还会退化成一个异步的，这同样也金融场景所不能接受的。

除此之外，原生半同步其实有一个性能方面的缺陷，即在跨IDC网络抖动的场景下，请求毛刺现象很严重。

所以原生的异步复制和半同步复制都存在一些问题，并不能完全适应金融场景。

TDSQL引入了基于raft协议的强同步复制，主机接收到请求后，等待其中一个备机应答成功后才返回客户端成功。

们一主两备下一条请求到达了主机之后必须等其中一个备机应答成功，才能返回客户端成功，否则这个请求不会应答的。

所以说，强同步TDSQL最基础的一个特性，TDSQL保证数据不会丢、不会错的关键。

讲到这里的话，可能有些同学会问，你们这个强同步其实也不复杂，不就在半同步的基础上把这个超时时间改成无限同时应答的备机设置为1。

并不这样的，TDSQL强同步这里的关键不在解决备机应答的问题，而要解决这种增加了等待备机的机制之后，如何能保证高性能、高可靠性。

换句话说，如果在原生半同步的基础上不改造性能，仅把超时时间改成无限的时候，其实跑出来的性能和异步比甚至连异步的一半都达不到。

这个在们看来也无法接受的。

相当于为了数据的一致性牺牲了很一部分性能。

TDSQL强同步复制的性能在原生半同步的基础上了量的优化和改进，使得性能基本接近于异步。

所以这里强同步强调的，实现强同步的同时还具备高性能特性，所以确切地说一个高性能的强同步。

tdsqlTDSQL简介及其应用领域一、TDSQL概述TDSQL（Tencent Database SQL）是腾讯云推出的一种基于MySQL协议进行扩展的分布式关系型数据库引擎。

TDSQL的设计目标是提供高性能、高可用性和可伸缩性，同时保持与MySQL的兼容性，使得迁移现有MySQL应用程序到TDSQL变得简单。

二、TDSQL的特点1. 高性能：TDSQL通过多节点、多副本及基于站库模式的读写分离架构，可以提供高吞吐量和低延迟的数据库性能。

2. 高可用性：TDSQL的数据存储采用分布式存储架构，具备自动数据备份、容灾切换和故障恢复等功能，以保证用户业务的持续运行。

3. 数据安全性：TDSQL支持数据的安全备份和恢复，并提供多层次的权限管理和访问控制，以保护用户数据的安全。

4. 兼容性：TDSQL完全兼容MySQL协议和SQL语法，可以直接支持现有的MySQL应用程序的迁移。

5. 可扩展性：TDSQL提供了水平扩展的能力，可以根据业务需求灵活地增加或减少节点的数量，以满足不同规模的应用需求。

三、TDSQL的应用领域由于TDSQL具备高性能、高可用性和可扩展性的特点，它在很多应用场景中都有广泛的应用。

1. 互联网行业：在互联网行业中，对数据库的性能和可扩展性要求较高。

TDSQL作为一种高性能的分布式数据库，能够满足互联网应用的高并发读写需求，并可以根据业务需求进行弹性扩容，以适应不断增长的数据量和用户访问量。

2. 电子商务：电子商务平台通常需要处理大量的交易数据，并保证数据的安全和一致性。

TDSQL提供了高可用性的数据存储和备份机制，可以确保交易数据的可靠性，并通过水平扩展的方式满足大规模交易的需求。

3. 游戏行业：游戏行业对数据库的性能和可扩展性要求较高。

TDSQL作为一种高性能的分布式数据库，可以满足复杂的游戏数据操作需求，如玩家数据存储、排行榜和战斗数据等。

同时，TDSQL的容灾切换和故障恢复能力可以确保游戏的稳定运行。

TDSQL的架构以及模块划分。

通过这一章节的了解，们更能切入TDSQL的技术细节，它为什么要这样设计，这样设计有什么好处，如何通过这样的架构和设计实现高可用、线性扩展等能力。

TDSQL系统总览1.1 资源池这张图从下往上看，首先层资源池，属于IaaS层，可以物理机，也可以虚拟机，只要给TDSQL机器就好，TDSQL在一个机器的资源池上实现了数据库实例的管理。

当然，这里推荐的还物理机，如果增加一层虚拟机，无疑在稳定性和性能方面都会引入一些隐患。

1.2 存储节从资源池再往上存储节。

存储节要强调的TDSQL的两种存储形态，一种Noshard 数据库，一种分布式数据库（也叫Shard版TDSQL）。

简单来说，Noshard就一个单机版的TDSQL，在MySQL的基础上了一系列的改造和改良，让它支持TDSQL 的一系列特性，包括高可用，数据强一致、7×24小时自动故障切换等。

第二种分布式数据库，具备水平伸缩能力。

所以TDSQL对外其实呈现了两种形态，呈现一种非分布式形态，一种分布式的形态。

至于这两种形态的区别，或者说什么场景更适合于哪种数据库，后面们有专门的章节去分析。

1.3 计算节再看计算节。

计算节就TDSQL的计算引擎，到了计算层和存储层相分离。

计算层主要一些SQL方面的处理，比如词法解、语法解析、SQL改写等。

如果分布式数据库形态，还要分布式事务相关的协调，所以们看到计算层不存储数据，只运行SQL方面的实时计算，所以它更偏CPU密集型。

此外，TDSQL计算节还具备OLAP的能力，对一些复杂的计算可以进行算法上的优化——什么时候该下推到存储引擎层，什么时候需要在计算层汇总等，这计算节需要的事情。

1.4 赤兔运营管理再往上，赤兔运营管理，如果说把这一套东西比作一个黑盒，们希望有一个用户界面操纵这个黑盒，这个界面就赤兔运营管理。

通过这个，DBA可以操纵TDSQL后台黑盒，所以相当于一套WEB管理系统。