下载文档原格式
腾讯会议核⼼数据库TDSQL，如何做到快速⽆损在线扩容？引⾔⾃去年12⽉底发布后，腾讯会议40天更新14个版本，8天紧急扩容超过10万台云主机，投⼊的计算资源超100万核。
疫情复⼯期间，每周都有数万家企业和政府相关机构使⽤腾讯会议复⼯复产，通过腾讯会议开拓了云签约、云招标、云⾯试、云培训等云上协同场景。
腾讯会议这款云视频会议产品，⽇活跃账户数已超1000万，成为当前中国最多⼈使⽤的视频会议专⽤应⽤。
⽬前，腾讯会议国际版也已经在超过100个国家和地区上线，助⼒全球战疫。
作为腾讯会议核⼼数据库，近期腾讯分布式数据库 TDSQL 持续⽀撑腾讯会议应对快速增长的存储容量和性能需求，为⽤户提供⾼速流畅、稳定可靠的服务，在平稳应对流量突增，实现让⽤户⽆感知的情况下进⾏快速⽆损在线扩容的场景⽅⾯提供了最佳实践案例。
⼀、不停机⽆损线性⽔平扩容⾯对流量突增场景，保障系统⾼可⽤的第⼀要务是进⾏系统扩容，满⾜业务的性能和容量需求。
回顾腾讯会议数据库⾯对流量突增的过程，作为腾讯会议的重要系统基础⽀持，随着流量的持续暴涨，优化之后 TDSQL 进⾏了⼀轮快速的数据库机器⽔平扩容实践：通过 TDSQL 策略丰富的读写分离技术，数据库层⾯快速响应了持续增长的容量和性能需求。
为了尽可能的将读请求分离，进⼀步降低对主节点的影响，TDSQL通过读写账号分离、灾备只读实例等措施，将纯只读业务分离出来，进⼀步降低主节点的压⼒提⾼整体的吞吐量。
最终，25%的复杂查询根据读写分离策略发往只读实例，快速达到降低主节点的负载的效果。
健壮的分布事务能⼒⽀撑，持续不断地进⾏性能优化。
SQLEngine 作为协调节点，⽆状态，能满⾜业务层⼏乎⽆限制的⽔平扩容需求。
不停机⽆损线性⽔平扩容，保障系统⾼可⽤、⾼性能，数据库技术架构如何做到？中间有哪些看不见的坑，有没有经过了实际验证的最佳⽅案？数字化转型全局发展正在提速，流量洪峰渐成常态****，未来，我们需要怎样的分布式技术架构系统？以下我们⼀⼀拆解。
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自动设置成只读。
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产品，以及它的适用场景。
第一章包括四个方面：使用场景、发展历程、核心特性，以及兼容性。
首先，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计算引擎研发工程师岗位面试题及答案1.介绍一下TDSQL计算引擎的基本工作原理。
回答：TDSQL是基于分布式计算框架的实时数据分析引擎，通过将SQL查询转化为分布式计算任务来实现快速数据分析。
在查询处理过程中，数据会被分片并在多个节点上并行处理，最终结果会被聚合返回。
2.请解释一下分布式计算中的数据分片和数据聚合。
回答：数据分片是将数据划分成小块，使得每个节点可以并行处理部分数据。
数据聚合是将多个节点处理的结果合并为最终的输出。
3.在TDSQL中，如何处理复杂的SQL查询，例如涉及多表连接和子查询的情况？回答：复杂的SQL查询需要经过优化器解析，优化和重写阶段。
TDSQL会根据数据分布情况决定是否将多表连接和子查询下推到各个节点进行处理，然后再将结果聚合。
4.请描述一下TDSQL的查询优化过程。
回答：查询优化过程包括查询解析、查询重写、查询优化以及物理计划生成等阶段。
解析器解析查询语句，重写器根据规则进行优化，优化器选择最优执行计划，执行引擎根据物理计划执行任务。
5.在TDSQL中，如何处理数据倾斜的情况？请举例说明。
回答：数据倾斜可能导致某些节点负载过重。
可以采用数据重分布、数据倾斜检测和动态负载均衡等方法来处理。
例如，可以将数据倾斜的表进行重新分片，或者在查询时通过动态调整任务分配来平衡负载。
6.请讨论一下TDSQL中的事务处理和并发控制。
回答：TDSQL支持分布式事务处理，通过协调者节点来保证事务的原子性、一致性、隔离性和持久性。
并发控制可以使用多版本并发控制（MVCC）来管理不同事务的访问。
7.如何确保TDSQL的查询结果的准确性和一致性？回答：TDSQL通过在分布式计算中引入数据同步和版本控制机制来确保查询结果的准确性和一致性。
每个节点在执行查询时，都会根据数据版本来保证结果的正确性。
8.请解释一下索引在TDSQL中的作用以及如何选择合适的索引。
回答：索引在TDSQL中用于加速查询，减少数据扫描的成本。
tdsql原理全文共四篇示例，供读者参考第一篇示例：TD-SQL全称为Time Division-SQL，是一种基于时间划分的SQL 语言，主要用于处理时序数据的查询与分析。
TD-SQL的引入，使得SQL语言在处理时间序列数据时更加高效和灵活。
TD-SQL的设计，融合了传统的SQL语法和时间序列数据库的特性，使得用户没有必要学习新的语法和接口，就可以轻松地处理时间序列数据。
TD-SQL的原理基于以下几个核心概念：时间窗口、时间序列数据、时间函数和时间索引。
时间窗口是TD-SQL中一个非常重要的概念，用于限定查询的时间范围。
时间序列数据是TD-SQL中的主要数据类型，用于描述随时间变化的数据。
时间函数是TD-SQL中特有的函数，用于处理时间序列数据，比如对时间序列数据进行统计、计算平均值等操作。
时间索引是TD-SQL中的一种索引方式，用于加速基于时间条件的查询操作。
在TD-SQL中，用户可以利用时间窗口对时间序列数据进行筛选和聚合操作，从而方便地进行时序数据分析。
用户可以使用时间窗口来查询某一天、某一周或某一个月的数据，还可以使用时间窗口来计算时间序列数据的移动平均值、方差等统计指标。
通过时间函数的使用，用户可以进一步对时间序列数据进行复杂的计算和分析，比如计算两个时间序列数据之间的相关性、预测未来时间序列数据的走势等。
TD-SQL的设计，旨在提高用户处理时序数据的效率和便利性。
它不仅支持传统的SQL查询方式，还集成了丰富的时间序列数据处理函数，方便用户对时间序列数据进行进一步的分析。
TD-SQL还支持时间索引的使用，提高了查询的速度和性能。
TD-SQL是一种高效、灵活的处理时序数据的SQL语言，为用户提供了更加便捷的时序数据分析工具。
通过掌握TD-SQL的原理和使用方法，用户可以更加轻松地处理各种时序数据，为业务决策提供有力支持。
TD-SQL的应用范围广泛，可用于金融、医疗、工业等领域的数据分析与挖掘工作。
分布式事务详解1. 什么是分布式事务1.1 事务严格意义上的事务实现应该是具备原⼦性、⼀致性、隔离性和持久性，简称 ACID。
通俗意义上来说，事务就是为了使得⼀些更新等操作要么都成功，要么都失败。
原⼦性（Atomicity）：可以理解为⼀个事务内的所有操作要么都执⾏，要么都不执⾏。
⼀致性（Consistency）：可以理解为数据是满⾜完整性约束的，也就是不会存在中间状态的数据，⽐如你账上有400，我账上有100，你给我打200块，此时你账上的钱应该是200，我账上的钱应该是300，不会存在我账上钱加了，你账上钱没扣的中间状态。
隔离性（Isolation）：指的是多个事务并发执⾏的时候不会互相⼲扰，即⼀个事务内部的数据对于其他事务来说是隔离的。
持久性（Durability）：指的是⼀个事务完成了之后数据就被永远保存下来，之后的其他操作或故障都不会对事务的结果产⽣影响。
其中，原⼦性和持久性就是靠undo和redo⽇志来实现的。
在Mysql中，有许多⽇志⽂件，这2个⽂件就是与事务有关的。
1.2 undo⽇志undo⽇志：⽤于保证事务的原⼦性。
原理：1. 在操作任何数据之前，先将数据备份到Undo Log。
2. 然后进⾏数据的修改。
3. 若出现了错误或⽤户执⾏了ROLLBACK语句，系统就可以利⽤Undo Log中的备份数据恢复到事务开始之前的状态。
流程举例：1. 事务开始2. 记录A=1到undo log3. 修改A=34. 记录B=2到undo log5. 修改B=46. 将undo log写到磁盘7. 将数据写到磁盘8. 事务提交1.3 redo⽇志redo⽇志：⽤于保证事务的持久性原理：1. redo log与undo log 相反，redo log记录的是新数据的备份，undo log记录的是旧数据的备份2. 在事务提交前只需要将redo log持久化即可。
流程举例：1. 事务开始2. 记录A=1到undo log3. 修改A=34. 记录A=3到redo log5. 记录B=2到undo log6. 修改B=47. 记录B=4到redo log8. 将undo log写到磁盘9. 将redo log写⼊磁盘10. 事务提交1.4 分布式事务分布式事务:顾名思义就是要在分布式系统中实现事务，它其实是由多个本地事务组合⽽成。
分布式事务 dts 原理分布式事务（Distributed Transaction）是指在分布式系统中，涉及多个独立的事务参与者的一系列操作，需要保证这些操作都要么全部成功，要么全部失败，以保持数据的一致性。
DTS（Distributed Transaction Service）是一种支持分布式事务的服务框架，它可以提供事务的协调和管理，并确保在分布式环境下的各个事务参与者之间的一致性。
DTS的原理主要包括以下几个方面：1. 事务协调器：DTS框架中的事务协调器负责协调各个事务参与者的操作，在事务的开始和结束阶段进行协调和管理。
事务协调器使用分布式锁机制来保证事务的一致性，确保所有的操作在事务的边界内执行。
2. 两阶段提交（2PC）：在DTS框架中，通常使用两阶段提交协议来保证分布式事务的一致性。
在第一阶段，事务协调器向所有的事务参与者发送预提交请求，要求其准备提交事务。
每个事务参与者在接收到预提交请求后，会执行本地事务，并将执行结果和状态返回给事务协调器。
在第二阶段，如果所有的事务参与者都返回了成功的状态，事务协调器向所有的参与者发送提交请求，要求其提交事务；如果任何一个参与者返回了失败的状态，事务协调器会向所有的参与者发送回滚请求，要求其回滚事务。
3. 分布式事务日志：为了保证分布式事务的可靠性，DTS框架通常使用分布式事务日志来记录事务的操作和状态信息。
当一个事务参与者执行完毕，会将其操作和状态信息写入到分布式事务日志中。
在进行故障恢复或者出现异常情况时，可以通过分布式事务日志来进行事务的恢复和回滚操作。
总的来说，DTS框架通过事务协调器、两阶段提交和分布式事务日志等机制来确保分布式系统中的事务一致性和可靠性。
通过对事务的协调和管理，可以有效地处理分布式环境下的并发和故障问题，保证数据的一致性。
