腾讯TDSQL分布式金融级数据库的全局读一致性技术
Tencent大数据技术架构
SetA
网关 主 MySQL + Agent 备1 MySQL + Agent
…
应用 MySQL API
备2n MySQL + Agent
网关
SetB
网关 主 MySQL + Agent 备1 MySQL + Agent
…
备2n MySQL + Agent
1、识别DDL类sql，并以任务形式保存至scheduler； 2、解析DML类sql，并转发至对应Set； 3、收集Set返回的结果，组合后返回请求端； 4、watch并获取表的访问路由； …
容量：自动分表
GW(逻辑表) Mysql(物理表) GW(逻辑表) Mysql(物理表)
T 0 T 1
T
T
当SET资源不够或表 记录超标时，触发 扩容，物理表分裂
T 2 T T 3
该过程自动完成
初始态：逻辑表=物理表
T n
扩容后：逻辑表=N个物理表
容量：自动伸缩
伸缩方式
整表迁移 子表分裂
T1 T2 T3
原则：避免表分裂，及时表合并 表分裂的问题
在一个集群中，每次表分裂，会导致集群 表数量的增加；集群中表的数量就是路由 的条数，表数量越多，路由的效率就会越 低
•
• •
采用hardlimit+softlimit结合的方式
Hardlimit保证安全，不超机器总容量 Softlimit保证充分利用整机资源
14
Gaia 技术特点
强扩展性：支持单cluster万台规模
（即将达到
8800节点，20w+核，1500个pool）
腾讯云-TDSQL分布式数据库服务概述
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架构原理概述TDSQL（TiDB Distributed SQL）是一个分布式数据库架构，它是由PingCAP公司开发的一款开源数据库。
TDSQL具有强一致性、高可用性和水平可扩展性的特点，适用于大规模、高并发的数据存储和处理需求。
TDSQL的架构原理主要包括三个方面：存储层、计算层和协调层。
存储层是TDSQL的核心组件，它负责数据的存储和管理。
存储层采用分布式存储的方式，将数据分成多个分片，并将每个分片复制到不同的节点上，以保证数据的冗余和可靠性。
存储层采用Raft协议保证数据的一致性，通过多副本和强一致性保证数据的可靠性和持久性。
此外，存储层还支持水平扩展，可以根据需求增加节点来扩展存储容量和处理能力。
计算层是TDSQL的查询和计算引擎，它负责接收用户的查询请求，并将请求转化为分布式查询任务。
计算层采用分布式查询的方式，将一个查询任务拆分成多个子任务，并将子任务分配给不同的节点进行并行处理。
计算层通过调度和协调各个节点上的计算任务，最终将结果返回给用户。
计算层采用分布式索引和分布式事务的方式，使得在大规模数据查询和处理中依然能够保持较高的性能和可用性。
协调层是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的核心架构是基于传统关系数据库的基础上扩展和优化而成的分布式关系数据库系统。
通过将数据切分和分片存储在多个节点上，以及采用分布式事务管理和查询优化的技术，实现了数据的高可用性和横向扩展能力。
tdsql和mysql语法
tdsql和mysql语法
TDSQL（Tencent Distributed Structured Query Language）
是腾讯公司开发的一种分布式数据库管理系统，而MySQL是一种流
行的开源关系型数据库管理系统。
它们都有自己独特的语法和特点。
首先，让我们来看一下TDSQL的语法特点。
TDSQL支持标准的SQL语法，包括SELECT、INSERT、UPDATE、DELETE等常见的SQL操作。
与传统的关系型数据库不同，TDSQL还支持分布式SQL查询和
分布式事务处理，可以处理大规模数据的存储和查询。
TDSQL还提
供了一些特有的语法和函数，用于处理分布式环境下的数据操作，
比如分区表的语法、分布式索引的语法等。
而MySQL的语法特点也非常明显。
MySQL同样支持标准的SQL
语法，但它也有一些自己独特的语法和特性。
比如MySQL支持存储
过程和触发器，可以在数据库中编写复杂的逻辑处理。
此外，MySQL
还有一些特有的数据类型和函数，比如JSON数据类型和相关的
JSON函数，以及空间数据类型和相关的空间函数。
在使用这两种数据库时，需要根据具体的需求和场景来选择合
适的语法和特性。
如果需要处理大规模的分布式数据，TDSQL可能
是更好的选择，因为它专为分布式环境设计。
而如果需要复杂的逻辑处理或者特定的数据类型支持，MySQL可能更适合。
当然，在实际应用中，也可以结合使用这两种数据库，根据具体的业务需求来选择合适的数据库和语法。
总之，了解并熟练掌握它们的语法特点对于合理选择和使用数据库是非常重要的。
TDSQL分布式金融级数据库架构
可见
TDSQL》
未来展望
腾讯TDSQL分布式金融级数据库架构
全局读一致性
面向金融类业务，十年积累，亿级账户验证
腾讯公司内与计费、充值、转账、财务等核心系统90%以上都使用TDSQL！
2002
2004
2008
2010
2012
2014
腾讯SP业务 原生MYSQL
增值业务 分库分表手工
伸缩
业务爆炸 一致性、 7X24可用性
腾讯计费 超高并发超短
低效
所有事件全序排序=>所有事务全 局排序，低效
数据是否可读，需要通过全局事 务提交状态验证，增加通讯次数
案例
Pg XC
某些系统 SS2PL+MVCC
Spanner SS2PL+MVCC
CockroachDB SSI+MVCC
5
2次读
增加了通讯轮数，且只能解决读 学术界的解决
《Scalable atomic visibility with
有异 常
有异 常
• 写-写
有异 常
• 写-读
并发操作可以被区分为四种：读-读、读-写、写-读、写-写
两个数据节点Na、Nb；两个数据项X、Y Na节点commit完成；Nb节点commit未完成 全局该事务处于committing状态
读半已提交数据异常
结果：账目不平
第1个分布式事务
第2个分布式事务
目录 CONTENTS
分布式事务处理模型与数据异常 业界主流数据库的解决方式
TDSQL全局读一致性的实现技术
解决方案
编号 1 2
3
4
各种方案 全局事务管理器 基于封锁的并发访问控制算法+全
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的容灾切换和故障恢复能力可以确保游戏的稳定运行。
GoldenDB分布式事务全局一致性
87业界观察Industry Observation2019 . 10 中国金融电脑GoldenDB 分布式事务全局一致性中兴通讯股份有限公司 李磊 陆天炜 付裕金融行业的数据库必须具备事务处理实时一致、数据复制安全可靠、性能容量线性扩展、运维操作简单易用等特点，其中事务的实时一致性尤为重要。
而分布式架构下的事务实时一致性是一个难点。
分布式事务一致性难点分布式数据库系统中事务的实时一致性的难点主要表现在三个方面：分布式环境中事务的原子性，分布式环境中事务的隔离性以及备份数据恢复后的事务一致性。
1. 原子性传统关系型单机数据库通过日志先落盘（WAL）、故障恢复（crash recovery）等机制保证事务的原子性。
在分布式数据库中，分布式事务必须分解成若干子事务下发到数据节点上去执行。
子事务的原子性是由各个数据节点进行保证的，无法保证分布式事务的原子性。
分布式事务一致性需要应用系统或者分布式数据库本身实现。
如果应用层实现事务一致性必须进行大量的事务处理改造。
大大增加了应用的处理逻辑，失去了在传统领域应用的价值。
2. 隔离性传统关系型单机数据库的隔离性，能够很好地解决并行事务间数据访问的冲突问题。
事务的隔离性也可以根据应用的需求进行不同级别的设置。
分布式数据库由于各个子事务分散在数据节点上进行，每个数据节点只能保证节点内部数据的隔离性。
并行的全局事务由于各子事务完成时间无法同步，其隔离性也就无法通过数据节点隔离性来保证。
当某个数据节点已经完成了子事务的提交之后，从单节点层面已经允许并行事务对涉及到的字段进行读写。
全局事务涉及到的其他数据节点并没有完成全局事务处理，容易引起脏读和丢失更新类的问题。
因此分布式事务的隔离性也是分布式数据库中设计的重点，特别是面向金融级要求强一致性读写的应用。
3. 备份恢复一致性传统关系型单机数据库对于事务操作的原子性能够保证数据在备份恢复的时候数据的一致性不受损。
分布式数据库系统在备份某一特定时刻的数据时，无法确保多个单一的数据节点上的备份操作，所备份的数据都是全局提交的数据。
分布式数据库TDSQL架构原理概述
腾讯分布式数据库TDSQL金融级能力的架构原理概述目录TDSQL是什么：腾讯如何打造一款金融级分布式数据库我们先初步了解TDSQL产品，以及它的适用场景。
第一章包括四个方面：使用场景、发展历程、核心特性，以及兼容性。
首先，TDSQL是腾讯推出的一款兼容MySQL的自主可控、高一致性分布式数据库产品。
这里我们强调一点，高度兼容MySQL——TDSQL完全兼容MySQL协议，并且做到完全自主可控、数据强一致性。
第二是TDSQL具备分布式的特性，具备一个弹性扩展、高可用的架构。
在互联网行业，海量的用户流量场景很常见，如果数据库不具备可伸缩性、可扩展性，是很难应对如：电商的大型促销，春节抢红包等突增流量的场景，这些其实都是对数据库应对海量用户流量的考验。
目前TDSQL已经服务超过500+的金融政企，行业覆盖银行、保险、证券、政务、互联网金融等各个领域。
我们再看一下TDSQL的前世今生。
TDSQL最早可以追溯到2002年，那个时候其实还不叫TDSQL，它是腾讯计费平台部的一个数据库服务，当时使用了开源的MySQL。
2002年-2007年随着公司业务的发展，腾讯所面临的用户量的压力也越来越大。
这个时候我们提出了7×24小时不宕机的高可用设计方案，来保证数据库能提供7×24小时不间断连续高可用服务。
那个时候，腾讯的增值业务日渐成规模，业务对数据也越来越敏感，对数据可用性的要求越来越高，甚至平时还要防备一些像运营商的光纤被挖断等各种各样的异常场景。
在2007年-2012年，这可能是互联网时代从互联网到移动互联网的发展的快速5年。
当然，公司的业务也是突飞猛进。
我们开始把这个高可用的数据库产品化。
到2012年，TDSQL的雏形就已经出来了，作为一款内部产品，开始在公司内部提供金融级的数据强一致性、可靠性服务。
从2012年起，TDSQL已经在腾讯内部做得已经比较成熟，已经是一个知名的产品了，但是它一直没有对外做商业化。
腾讯自研分布式数据库TDSQL简介-支持从oracle迁移(1)
TDSQL素材1产品简介TDSQL（Tencent Distributed SQL）是腾讯打造的一款MySQL兼容HTAP分布式数据库产品，具备强一致高可用、全球部署架构、分布式水平扩展、高性能、企业级安全等特性，同时提供智能DBA、自动化运营、监控告警等配套设施，为用户提供完整的分布式数据库解决方案。
目前TDSQL已经为超过500+的政企和金融机构提供数据库的公有云及私有云服务，客户覆盖银行、保险、证券、互联网金融、计费、第三方支付、物联网、互联网+、政务等领域。
TDSQL亦凭借其高质量的产品及服务，获得了多项国际和国家认证，得到了客户及行业的一致认可。
2九大特性2.1强同步复制多副本强一致性下的高可用方案，基于跨数据中心强同步复制，故障可自动切换，且数据零丢失。
2.2全球部署架构按需部署，轻松实现异地多活，两IDC对等架构、两地三中心架构、两地四中心架构、多地多中心。
2.3分布式水平扩展Auto Sharding机制，实现实时在线无缝扩容，确保集群性能、容量线性增长；提供健壮的分布式事务机制，全SQL兼容，单机数据库迁移TDSQL零门槛。
2.4内核深度优化内核深度定制优化，跨数据中心强同步性能相较于异步零损耗；OLTP TPS相较于原生MySQL提升85%。
2.5企业级安全增强通过透明加密、数据库防火墙、SSL接入、SQL审计等措施，实现事前、事中、事后的全生命周期安全防护。
2.6HTAP内嵌分布式查询引擎，OLTP与OLAP混合支持，同时支持Spark On TDSQL，对不同负载SQL进行智能调度。
2.7多引擎支持支持MySQL社区版、Percona、MariaDB三大分支；支持InnoDB、RocksDB等多种存储引擎。
2.8智能DBA基于海量运营经验加AI的DBA智能诊断系统，快速帮助业务预防、发现、定位并解决问题。
2.9自动化运营体系提供完善的运营配套体系，Binlog订阅、冷备、多源异构数据库同步等，无缝对接周边系统。
TDSQL金融级特性之：数据强一致性保障
作为金融场景下不可或缺的数据强一致性的保障。
们将从四个方面来聊一聊数据一致性的保障：1.主备数据复制2.数据复制比较：TDSQL主备数据复制方案 VS MySQL原生方案3.核心功能：容灾切换，数据强一致、0丢失0出错4.数据强一致性TDSQL主备数据复制：高性能强同步首先在讲数据一致性之前，们先了解一下MySQL原生的数据复制的。
首先种异步复制：主机在不等从机应答直接返回客户端成功。
这个在金融场景不能接受的，这样的话相当于数据没有多副本保障。
第二种半同步：主机在一定条件下等备机应答，如果等不到备机应答，它还会返回成功，也就说它最终还会退化成一个异步的，这同样也金融场景所不能接受的。
除此之外，原生半同步其实有一个性能方面的缺陷，即在跨IDC网络抖动的场景下，请求毛刺现象很严重。
所以原生的异步复制和半同步复制都存在一些问题，并不能完全适应金融场景。
TDSQL引入了基于raft协议的强同步复制，主机接收到请求后，等待其中一个备机应答成功后才返回客户端成功。
们一主两备下一条请求到达了主机之后必须等其中一个备机应答成功，才能返回客户端成功，否则这个请求不会应答的。
所以说，强同步TDSQL最基础的一个特性，TDSQL保证数据不会丢、不会错的关键。
讲到这里的话，可能有些同学会问，你们这个强同步其实也不复杂，不就在半同步的基础上把这个超时时间改成无限同时应答的备机设置为1。
并不这样的，TDSQL强同步这里的关键不在解决备机应答的问题，而要解决这种增加了等待备机的机制之后，如何能保证高性能、高可靠性。
换句话说，如果在原生半同步的基础上不改造性能，仅把超时时间改成无限的时候，其实跑出来的性能和异步比甚至连异步的一半都达不到。
这个在们看来也无法接受的。
相当于为了数据的一致性牺牲了很一部分性能。
TDSQL强同步复制的性能在原生半同步的基础上了量的优化和改进，使得性能基本接近于异步。
所以这里强同步强调的，实现强同步的同时还具备高性能特性，所以确切地说一个高性能的强同步。
腾讯TDSQL分布式事务处理技术概述
occur. Therefore, asynchronously replicated database t3
systems can allow stale reads without giving up its
serializability (or even one-copy serializability)
因果关系是隐式无法 知道的 因果关系是显式可知 道的
时钟漂移到未来，无 因果关系
＠分布式一致性的问题—挑战：问题复杂度增加
太多的一 致性，如 何与事务 一致性融
合？
＠分布式一致性+事务一致性的问题—业界观点
Making Consistency More Consistent: A Unified Model for Coherence, Consistency and Isolation
system is simply time travelling the read transaction
to a point in time in the equivalent serial order of
t0
transactions before the new writes to this data item t2
P1 W1-x-t1
P2
R2-x-t1 R3-x-t0 (时间关系不确定导致因果反转)
或：
P1 W1-x-t1
W1-y-t3
P2
R3-x-t0（读已提交导致因果反转）
P1 W1-x-t1 R1-x-t0 相同session之间存在显式的因果关系
P1
W1-x1-t1 C1
P2 R2-x1-t0 C2 （读后于自己在real-time上发生的数据，无因果关系）
腾讯云数据库TDSQL在金融核心的实践
◆ TDSQL
物理设备操作系统（加强定制版Linux）
调度系统
故障迁移 业务调配
当前金融行业技术现状
传统技术架构遇到瓶颈
目前国内大中型银行主要以国外厂商提供的大型主机和数 据库解决方案来进行系统构建。以国外大型主机和数据库 为核心的架构已无法满足大规模交易和数据处理的需求。
一方面：性能无法满足业务不断激增的处理需求，存在系 统过载风险； 另一方面：本身价格比较昂贵，维护成本居高不下。
总行机房
SQL Engine
同城
灾备机房
SQL Engine
异地
SQL Engine
Master
强同步
Slave
异步 Master
异步
强同步
Slave
Slave
Slave
#1 #2
#3 #4
#5
TDSQL最佳实践-完善的全白屏化运维方案
实时诊断优化 效果可预见
掌上运维 AI 助力
TDSQL最佳实践-软硬一体解决方案
“张家港农商银行采用基于腾讯TDSQL的分布式数据库架构建设， 硬件投入从千万级降低到百万级，硬件成本下降75%以上，性能并 可线性增长。”
—— 张家港农商行
◆比如高并发低延时的场景拆分后仍不满足的业务，可以引入缓 存进一步加速； ◆需要更强的查询分析能力的话可以引入等面向联机分析的产品。
核心系统改造：循序渐进，选择最合适的技术方案
第四步：单元化改造
◆ 无限可伸缩微服务架构 ◆ 异地多活部署 ◆ 异构机房上的弹性混合云架构
User=0 User=1 User=2
2019.7 生产机器性能论证
2019.8 项目投产
TDSQL最佳实践-产品定位
腾讯自研分布式数据库TDSQL简介-支持从oracle迁移（1）
腾讯自研分布式数据库TDSQL简介-支持从oracle迁移（1）TDSQL素材1产品简介TDSQL（Tencent Distributed SQL）是腾讯打造的一款MySQL 兼容HTAP分布式数据库产品，具备强一致高可用、全球部署架构、分布式水平扩展、高性能、企业级安全等特性，同时提供智能DBA、自动化运营、监控告警等配套设施，为用户提供完整的分布式数据库解决方案。
目前TDSQL已经为超过500+的政企和金融机构提供数据库的公有云及私有云服务，客户覆盖银行、保险、证券、互联网金融、计费、第三方支付、物联网、互联网+、政务等领域。
TDSQL亦凭借其高质量的产品及服务，获得了多项国际和国家认证，得到了客户及行业的一致认可。
2九大特性2.1强同步复制多副本强一致性下的高可用方案，基于跨数据中心强同步复制，故障可自动切换，且数据零丢失。
2.2全球部署架构按需部署，轻松实现异地多活，两IDC对等架构、两地三中心架构、两地四中心架构、多地多中心。
2.3分布式水平扩展Auto Sharding机制，实现实时在线无缝扩容，确保集群性能、容量线性增长；提供健壮的分布式事务机制，全SQL兼容，单机数据库迁移TDSQL零门槛。
2.4内核深度优化内核深度定制优化，跨数据中心强同步性能相较于异步零损耗；OLTP TPS相较于原生MySQL提升85%。
2.5企业级安全增强通过透明加密、数据库防火墙、SSL接入、SQL审计等措施，实现事前、事中、事后的全生命周期安全防护。
2.6HTAP内嵌分布式查询引擎，OLTP与OLAP混合支持，同时支持Spark On TDSQL，对不同负载SQL进行智能调度。
2.7多引擎支持支持MySQL社区版、Percona、MariaDB三大分支；支持InnoDB、RocksDB等多种存储引擎。
2.8智能DBA基于海量运营经验加AI的DBA智能诊断系统，快速帮助业务预防、发现、定位并解决问题。
2.9自动化运营体系提供完善的运营配套体系，Binlog订阅、冷备、多源异构数据库同步等，无缝对接周边系统。
金融云分布式数据库TDSQL技术架构
2002
2004
2008
业务爆炸 一致性、 7X24可用性
2010
腾讯计费 超高并发超短 时延
2012
米大师，腾讯 充值 更名TDSQL
2014
2015
腾讯SP业务 原生MYSQL
增值业务 分库分表手工 伸缩
WeBank 私有化部署
腾讯云 金融云
TDSQL 数据库的特点
基于MySQL生态
MySQL100%兼容
Agent Slave3 6
Agent Master Agent Slave2
SET
1、主DB降级为备机 2、参与选举的备机上报最新的binlog点 3、scheduler收到binlog点之后，选择出binlog最大的节点
4、重建主备关系 5、修改路由 6、请求发给新的主机
TDSQL强一致原理（恢复阶段不丢失数据）
增加节点 C(主) T1,T2,X3,X4 Xtrabackup自动快速 重做 D( 备 ) T1，T2,X3,X4
TDSQL高性能原理
半同步复制（同步 降级为 异步）
Binlog Dump
异步复制
TDSQL高性能原理
User Thread
Com mit(T1) O K( T1) Engine commit
HASH分区
两级分区
RANGE分区 全局唯一数字序列
group by, Order by Max,sum,min,ave等聚合函数 Distinct,count(1) 同一个group内的join 事务
只读帐号支持读写分离
热点更新
Data Buffer脏页刷出效率提升
TDSQL分布式方案（部署）
永不停机、高一致性
腾讯会议核心数据库TDSQL，如何做到快速无损在线扩容？
腾讯会议核⼼数据库TDSQL，如何做到快速⽆损在线扩容？引⾔⾃去年12⽉底发布后，腾讯会议40天更新14个版本，8天紧急扩容超过10万台云主机，投⼊的计算资源超100万核。
疫情复⼯期间，每周都有数万家企业和政府相关机构使⽤腾讯会议复⼯复产，通过腾讯会议开拓了云签约、云招标、云⾯试、云培训等云上协同场景。
腾讯会议这款云视频会议产品，⽇活跃账户数已超1000万，成为当前中国最多⼈使⽤的视频会议专⽤应⽤。
⽬前，腾讯会议国际版也已经在超过100个国家和地区上线，助⼒全球战疫。
作为腾讯会议核⼼数据库，近期腾讯分布式数据库 TDSQL 持续⽀撑腾讯会议应对快速增长的存储容量和性能需求，为⽤户提供⾼速流畅、稳定可靠的服务，在平稳应对流量突增，实现让⽤户⽆感知的情况下进⾏快速⽆损在线扩容的场景⽅⾯提供了最佳实践案例。
⼀、不停机⽆损线性⽔平扩容⾯对流量突增场景，保障系统⾼可⽤的第⼀要务是进⾏系统扩容，满⾜业务的性能和容量需求。
回顾腾讯会议数据库⾯对流量突增的过程，作为腾讯会议的重要系统基础⽀持，随着流量的持续暴涨，优化之后 TDSQL 进⾏了⼀轮快速的数据库机器⽔平扩容实践：通过 TDSQL 策略丰富的读写分离技术，数据库层⾯快速响应了持续增长的容量和性能需求。
为了尽可能的将读请求分离，进⼀步降低对主节点的影响，TDSQL通过读写账号分离、灾备只读实例等措施，将纯只读业务分离出来，进⼀步降低主节点的压⼒提⾼整体的吞吐量。
最终，25%的复杂查询根据读写分离策略发往只读实例，快速达到降低主节点的负载的效果。
健壮的分布事务能⼒⽀撑，持续不断地进⾏性能优化。
SQLEngine 作为协调节点，⽆状态，能满⾜业务层⼏乎⽆限制的⽔平扩容需求。
不停机⽆损线性⽔平扩容，保障系统⾼可⽤、⾼性能，数据库技术架构如何做到？中间有哪些看不见的坑，有没有经过了实际验证的最佳⽅案？数字化转型全局发展正在提速，流量洪峰渐成常态****，未来，我们需要怎样的分布式技术架构系统？以下我们⼀⼀拆解。
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、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
全局读一致性---腾讯TDSQL分布式金融级数据库
面向金融类业务，十年积累，亿级账户验证
腾讯公司内与计费、充值、转账、财务等核心系统90%以上都使用TDSQL！
2002
腾讯SP业务原生MYSQL
2004
增值业务
分库分表手工
伸缩
2008
业务爆炸
一致性、
7X24可用性
2010
腾讯计费
超高并发超短
时延
2012
米大师，腾讯
充值
更名TDSQL
2015
腾讯云
金融云
2014
WeBank
私有化部署
2017
分布式
事务
2018
全时态
数据库
向上攀登
永不止步2019
全局读
一致性
分布式事务处理模型与数据异常
目录CONTENTS 业界主流数据库的解决方式TDSQL 全局读一致性的实现技术
并发操作可以被区分为四种：读-读、读-写、写-读、写-写•写-读
•写-写•读-写•读-读
无异
常
有异常有异常有异
常
读半已提交数据异常●两个数据节点Na、Nb；两个数据项X、Y
结果：账目不平
●Na节点commit完成；Nb节点commit未完成
●全局该事务处于committing状态
第1个分布式事务第2个分布式事务
分布式事务处理模型与数据异常
目录CONTENTS 业界主流数据库的解决方式TDSQL 全局读一致性的实现技术
解决方案
编号各种方案缺点案例
1全局事务管理器非去中心化、低效Pg XC
2基于封锁的并发访问控制算法+全
局可串行化低效某些系统
SS2PL+MVCC
3全局可串行化+线性一致性所有事件全序排序=>所有事务全
局排序，低效
Spanner SS2PL+MVCC
4全局可串行化+混合逻辑时钟+全局
事务提交标志数据是否可读，需要通过全局事
务提交状态验证，增加通讯次数
CockroachDB
SSI+MVCC
52次读
《Scalable atomic visibility with
ramp transactions》增加了通讯轮数，且只能解决读
半已提交数据异常
学术界的解决
方式
更多的数据异常……分布式读半已提交异常Cross 异常
Carsten Binnig, Stefan Hildenbrand, Franz Färber, Donald Kossmann,
Juchang Lee, Norman May: Distributed snapshot isolation: global
transactions pay globally, local transactions pay locally. VLDB J. 23(6):
987-1011 (2014)。