腾讯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自动设置成只读。
腾讯云-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技术架构

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
物理设备操作系统(加强定制版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架构原理概述

腾讯分布式数据库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计算引擎研发工程师岗位面试题及答案(经典版)

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原理

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、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。
无环
按事务+分布式一致性原理推理的执行逻辑: -T1 -> T3 按real-time排定逻辑关系 R1(control)[deposit_no=1] W1(receipt)[deposit_no=1] -> R3(receipt)
T1 -> T2 R1(control) -> R2(control) W2(control)
select * from receipt;
receipt_no | deposit_no | payee | amount
------------+------------+--------+---------
1|
1 | Crosby | $100.00
2|
1 | Stills | $200.00
commit;
ERROR: could not serialize access
due to read/write dependencies among transactions
DETAIL: Cancelled on identification as a pivot, during commit attempt. HINT: The transaction might succeed if retried.
T2->T3(session order) 应该判断
理论分析时的并发情况:
T1
T2
T3
R1-x0
W1-y1
R2-x0
W2-x1
C2
R3-y0
C1 ?
事实并发情况:
T1
T2 /T3
R1-x0
W1-y1
R2-x0
W2-x1
C2
R3-y0 C1 ?
@分布式一致性+事务一致性的问题— PostgreSQL 中一个神奇的例子
P1
T1
begin; -- T1 insert into receipt (deposit_no, payee, amount) values ( (select deposit_no from control), 'Young', '100' );
(3 rows)
https:///wiki/SSI#Deposit_Report
@分布式一致性+事务一致性的问题— PostgreSQL 中一个神奇的例子
可串行化:T3-T1-T2 依赖图:无环 SSI: 无环 Pg SSI:无环,但有“ R W T1 RW”
T2->T3(session order) 没有判断
T3 R W T1 R W T2
发生了Stale read,在事务型DB中,是否合理?
可串行化:T3-T1-T2 <------> 因果序:T2-T3 结论: 单机系统的事务排序,需要考虑因果序( 可串行化的缺陷) DTA:T3的lower >= 符合读已提交的数据的提交时间戳 多级一致性:T3-T1-T2-T3,故有环
腾讯TDSQL分布式事务处理 技术概述
多级一致性技术(强一致性)
“强一致”的 分布式事务型数据库
@分布式一致性+事务一致性的问题—挑战:缺少一致性带来的问题
无事务保障:脏写数据异常
分布式事务型数据库, 两种一致性缺一不可
无一致性 保障:违 反因果序
@分布式一致性+事务一致性的问题— PostgreSQL 中一个神奇的例子
按事务原理推理的执行逻辑: -T1 -> T3 按real-time排定逻辑关系 R1(control)[deposit_no=1] W1(receipt)[deposit_no=1] -> R3(receipt)
T1 -> T2 R1(control) -> R2(control) W2(control)
数据准备 create table control ( deposit_no int not null ); insert into control values (1);
create table receipt ( receipt_no serial primary key, deposit_no int not null, payee text not null, amount money not null ); insert into receipt (deposit_no, payee, amount) values ((select deposit_no from control), 'Crosby', '100’); insert into receipt (deposit_no, payee, amount) values ((select deposit_no from control), 'Stills', '200’); insert into receipt (deposit_no, payee, amount) values ((select deposit_no from control), 'Nash', '300’);
P2 T3
begin; -- T3
select * from receipt where deposit_no = 1;
receipt_no | deposit_no | payee | amount
+
+
+
1|
1 | Crosby | $100.00
2|
1 | Stills | $20.00
3|
1 | Nash | $300.00
4|
1 | Young | $100.00
(4 rows)
T2
begin; -- T2 select deposit_no from control; deposit_no ------------
1
update control set deposit_no = 2; commit;
Pg事实执行逻辑: -T3 -> T1 因为T1没有提交,T3根据MVCC读旧版本 R1(control)[deposit_no=1] R3(receipt) -> W1(receipt)[deposit_no=1]
T1 -> T2 R1(control) -> R2(control) W2(control)