金融云分布式数据库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架构原理概述
分布式数据库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技术架构
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分布式金融级数据库架构
全局读一致性
面向金融类业务，十年积累，亿级账户验证
腾讯公司内与计费、充值、转账、财务等核心系统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核心架构
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管理系统。
分布式数据库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订阅、冷备、多源异构数据库同步等，无缝对接周边系统。
SDCC2015-腾讯-潘安群-腾讯金融级数据库TDSQL分析
• 存储平台的易用性（TBOSS平台1.04.0）
• SSD的大规模使用
• SQL的通用性 VS NoSQL的特例化
• MySQL 5.5 5.6 5.7 的大幅提升
基于MySQL打造TDSQL的背景
• 继续通过MySQL API和SQL接口访问集群
• 节点异常自动切换，切换过程保证数据零丢失，
腾讯金融级数据库 TDSQL分析
关于本人
潘安群 腾讯 – TEG – 计费平台部 2007年加入腾讯， 10年以上的 Linux后台Server开发经验，目前主 要从事分布式Cache，实时大数据处 理引擎，分布式MySQL(TDSQL)设 计和开发工作
关于TDSQL
目录
1. 金融场景的数据库需求、背景及契机 2. 整体架构 3. 解决的几个重要问题
微信：pananq
冷备恢复中心
• 基于HDFS的冷备中心
– Binlog – 镜像
Proxy
用户请求
Proxy
用户请求
Agent
原实例
Agent 新实例
1、xtrabackup 2、binlog
• 支持恢复到任意时间点
– 取决于您购买的冷备服务
• 重建SET，并切换
冷备中心
多租户多实例管理
Server #1
Server #2
a. 容灾与一致性
b.
c.
如何扩容
配套设施
4. 目前的运营数据 5. 展望
金融场景的数据库需求
一分不差的银行级业务
—— 高一致性，零数据丢失
7 * 24 小时的不间断服务
—— 自动容灾，高可用
百亿级的账户，订单数据
百亿级的日交易流水
金融云简介演示
实现容器之间的网络通信，保证容 器应用的安全和稳定。
微服务架构
服务注册与发现
实现微服务之间的自动发现和注 册，提高系统的可靠性和可扩展
性。
负载均衡
实现微服务之间的负载均衡，提 高系统的性能和可用性。
服务间通信
实现微服务之间的通信和协作， 保证系统的稳定性和高效性。
03
金融云的应用场景
银行业务系统
客户服务系统
金融云可以提供客户服务系统，支持客户通过互联网或电话等方式进行咨询、投诉和建议等操作，提高 证券业务的客户满意度和服务质量。
企业财务系统
01
企业资源规划（ERP ）系统
金融云可以提供ERP系统，帮助企业 实现财务管理、供应链管理、人力资 源管理等业务的整合和优化，提高企 业管理的效率和决策水平。
金融云的发展历程
探索阶段
2000年代初期，一些大型金融机构开始探索金融云的应用，主要是通过与IT厂商合作， 搭建私有云平台来提供内部金融服务。
发展阶段
2000年代中期至末期，随着云计算技术的不断成熟和普及，越来越多的金融机构开始尝 试将业务系统迁移到公有云平台上，以降低IT成本和提高业务效率。
成熟阶段
金融云的高可用性和灵活性使得金融机构 能够更快地响应市场变化和客户需求，提 高业务效率。
加强安全
促进创新
金融云采用多重安全机制，能够加强金融 机构的数据安全和业务可靠性。
金融云为金融机构提供了更多的创新机会 ，使得金融机构能够更快地推出新的产品 和服务，满足客户需求。
02
金融云的核心技术
分布式技术
金融云简介演示
汇报人： 2023-11-19
• 金融云概述 • 金融云的核心技术 • 金融云的应用场景 • 金融云的安全管理 • 金融云的未来趋势 • 金融云案例分析
金融云应用解决方案
设备的兼容性与稳定性仍存在上升空间，生态圈也有待完善。
银行IT系统国产化诉求凸显
国产化需求与痛点矛盾图示
1 顶层理念缺失
国产化路途艰难
1 银行数据敏感，国产设备存储更安全
没有银行数据安全性靠国产化解决的意识
财务信息 交易信息
收入信息
2 IOE存在成本不可控隐患
未知国产化改造的路径、渠道，相关厂商，无从下手 2 生态系统未建立成，仍面临兼容性与稳定性挑战
4328
2020 2021e 2022e 2023e 2024e
银行业技术投入规模（亿元）
增速（%）
• 银行技术投入规模持续增大，依赖性增长，但传统IT系统存在的痛 点没有令银行得到对等的回报，出现了投入增加效率不涨的现象。
➢ 数据存储成本高：银行数据规模庞大，大量业务 相关数据需要存储，备份、归档，但是传统NAS 解决方案成本高昂，性能与扩展能力无法满足数 据规模增长的需求。
分布式云数据库替代Oracle数据库
✓ 优点一：分布式数据库可采用横向扩展方式，便捷进行容量扩展。云平 台的账户体系在多套之间同步数据。
✓ 优点二：支持同城双活异地备份。云平台的冗余设计可以免去人工灾备 切换。
网络管理与计算资源扩充可根据银行需求定义
✓ 优点：计算能力可根据需求调整虚拟机参数做到自由扩展扩充，可自定义增加网络、带宽等等。
➢ 网络攻击威胁高：银行信息敏感性高，开发人员 通常专注于实现应用功能，难免出现安全漏洞， 被进行网络攻击造成泄密。
2.安全维护
36
银行策略一：虚拟营业厅+数据中台
从获客、运转、资源利用、安全维护方面帮助银行开源节流
智能获客，数据分析等前端应用可以帮助银行精准获客，减少营销资源浪费，提高客户获取率。数据中台则可以打破数据 孤岛，做到各业务部门数据共享，便于业务协调运转，应对获取顾客，为银行“开源”。分布式数据库、云服务器等可以 弹性分配资源，按需索取，方便扩容，提高了资源利用率，降低升级成本。而平行容器、抗DDoS等服务可以增强IT系统 安全性，预防网络攻击带来信息泄露等问题，降低漏洞修复与弥补成本，为银行“节流”。
TDS平台架构介绍
TDS平台架构介绍（TDS 2.0）棠棣科技2012年11月文档信息及修订记录项目名称项目编号文档密级机密/秘密/内部/公开项目经理项目总监文档主送文档抄送修订人修订日期修订说明版本号李明2012-2-25 初稿填写说明：1、项目名称、项目编号、项目经理、项目总监按照本项目实际情况填写。
2、文档密级是该文档允许扩散的范围。
对于交通银行，机密文件必须由信息科技部经理室批准方可借阅；秘密文件必须由项目负责人批准方可借阅；内部文件经一般授权后可由在项目组内部传阅；公开文件不需经过授权，可自由进行阅读。
对于棠棣公司，机密文件、秘密文件必须由银行产品事业部经理室批准方可借阅；内部文件经一般授权后可由在公司内部和项目组内部传阅；公开文件不需经过授权，可自由进行阅读。
3、文档主送是指该文档应该主送的对象，双方项目总监、项目经理是该文档必须主送的对象之一。
4、文档抄送是指该文档应该抄送的对象，项目管理组是该文档应该抄送的对象之一。
5、版本号是指该文档的版本次序号，该文档首次发布时可确定为1.0，如果在上一版的基础上有细微的调整和修改，则可在小数点后次版本号加1；如果该文档内容总体上有重大变化或增加/删除了重要章节，则小数点主版本号加1。
目录1TDS平台简介 (3)1.1阅读约定 (3)1.2术语解释 (4)1.3平台概览 (4)2TDS Runtime总体架构 (5)2.1运行模式: 开发模式和生产模式 (6)2.2TDS平台的插件机制 (6)2.3内建服务 (6)2.3.1日志服务 (6)2.3.2数据库连接池服务 (6)2.4内建功能集 (7)2.4.1交易引擎功能集(CTL) (7)2.4.2报文引擎功能集(ITF) (7)2.4.3渠道引擎功能集(ATR) (7)2.4.4定时触发功能集(TIMER) (7)2.4.5冲正重发功能集 (8)2.4.6对账功能集 (8)2.4.7批量调度功能集 (8)2.4.8脚本引擎功能集 (8)2.4.9规则引擎功能集 (8)2.4.10监控引擎功能集 (8)3总结 (9)1TDS平台简介TDS平台是棠棣技术平台的简称。
TDSQL在银行的大规模实践
TDSQL在银行的大规模实践目录一、前言 (3)二、Why TDSQL？ (3)三、基于DCN 的分布式扩展架构 (8)四、银行IDC 架构 (9)五、基于TDSQL 的同城应用多活 (10)六、TDSQL 集群规模 (13)七、银行数据库现状及未来发展 (14)一、前言微众银行在2014 年成立之时，就非常有前瞻性的确立了微众银行的IT 基础架构的方向：摒弃传统的基于商业IT 产品的集中架构模式，走互联网模式的分布式架构。
众所周知，传统银行IT 架构体系非常依赖于传统的商业数据库，商业存储以及大中型服务器设备，每年也需要巨大的IT 费用去维护和升级，同时这种集中式的架构，也不便于进行高效的实现水平扩展。
从过往经验来看，当时除了oracle 等少数传统的商业数据库，能满足金融级银行场景的数据库产品并不多。
当时腾讯有一款金融级的分布式数据库产品TDSQL，主要承载腾讯内部的计费和支付业务，其业务场景和对数据库的可靠性要求，和银行场景非常类似，同时也经受了腾讯海量计费业务场景的验证。
微众银行基础架构团队，经过多轮的评估和测试，最终确定和腾讯TDSQL 团队合作，共同将TDSQL 打造为适合银行核心场景使用的金融级分布式数据库产品，并将TDSQL 用于微众银行的核心系统数据库。
二、Why TDSQL？为什么会选用TDSQL，作为微众银行的核心数据库呢？本章节将会详细介绍TDSQL 架构、以及TDSQL 的核心特性，看看TDSQL 是如何满足了金融级场景的数据库要求。
TDSQL 架构介绍TDSQL 是基于MySQL/Mariadb 社区版本打造的一款金融级分布式数据库集群方案。
在内核层面，TDSQL 针对MySQL 社区版本和Mariadb 社区版本的内核，在复制模块做了系统级优化，使得其具备主备副本数据强一致同步的特性，极大提升了数据安全性，同时相对原生的半同步复制机制，TDSQL 强一致复制的性能也有极大提升。
TDSQL全时态数据库系统-理念与愿景
TDSQL全时态数据库系统-理念与愿景本文大纲：•Abstract•Introductiono研究动机o TDSQL整体架构o TDSQL对时态数据库的需求o T-TDSQL核心技术与系统的价值o T-TDSQL解决了的问题•Acknowledgments•References1 AbstractTDSQL是腾讯公司研发的一款事务型分布式数据库。
T-TDSQL是基于TDSQL的一个分布式全时态数据库。
其特点是可扩展、多版本事务管理、分布式存储和计算、强数据一致性和强同步机制，且提供有效时间、事务时间双时态的全态数据存储、管理、计算。
这篇文章描述了T-TDSQL的架构、双时态特性集，以及全双时态设计思考点和决策的因素。
另外，基于MVCC技术描述了一种“全态数据可见性判断算法/历史态数据可见性判断算法”，这种算法能够读取到全态/历史态数据和其上发生的操作，这是T-TDSQL全时态数据库系统实现的关键算法。
另外，T-TDSQL支持多种强大的特性，诸如：无阻塞读历史态数据、无锁只读事务、增量抽取、增量计算、全时态一致性快照等。
全时态数据库T-TDSQL核心价值观是：历史数据富有价值。
全时态数据库T-TDSQL核心理念是：为数据赋能。
2 Introduction研究动机腾讯公司的计费业务系统，是世界上领先的金融云计费业务系统。
这个系统包括SAAS、PAAS、IAAS三个层面。
在SAAS层面，包括米大师、云商店、TDSQL等系统。
TDSQL托管账户近280亿，米大师依托TDSQL进行金融交易,腾讯充值及其相关合作伙伴的日流水量超过150亿条，每天处理的交易量超过100亿笔。
金融数据在TDSQL数据库中进行结算、对账、审计、风控数据分析、构建用户画像等业务。
如王者荣耀游戏点券的对账业务、用户账户消费充值变化审计与风控业务等。
要进行诸如对账、审计等业务，数据来源有两部分。
一部分数据来源是从不同系统（关系数据库或NoSQL系统）的日志数据中来，称为流水日志。
TDSQL分布式数据库核心架构解读
TDSQL分布式数据库核心架构解读海量计费场景验证TDSQL 的每个分片默认采用主从高可用架构，提供弹性扩展、备份、恢复、监控等全套解决方案，为您高效解决业务快速发展时面临的各种数据库需求和挑战。
TDSQL （T encent Distributed SQL ）是腾讯推出的一款兼容MySQL 的自主可控的、高一致性、分布式数据库产品。
目前已为超过500+金融政企提供数据库服务，行业覆盖银行、保险、证券信托、互联网金融、第三方支付、计费、智慧零售、物联网、政务、物联网等。
1.2发展历程数据库防火墙；透明加密；自动备份；快速恢复等减少用户误操作/黑客入侵带来的安全风险。
在线无缝扩容，高效透明的分布式事务。
2.1系统总览2.2核心架构2.3模块划分强同步：主机基于raft协议等待多数派备机应答成功后才返回客户端成功强同步机制：任何一笔应答前端成功的请求，除了在主机落盘成功外还会在多数派备机落盘成功强同步性能：在原生半同步复制的基础上做了大量异步化性能改良，使得性能基本与异步复制持平3.2数据复制比较3.3核心功能：容灾切换3.4数据强一致性4.1分表将数据打散的很自然的一个字段，如用户ID，微信ID等不同的SET负责不同范围的号段，SQL Engine 根据SQL 中的shardkey值hash计算后发往对应的SET按需可以对SET持续扩容创建表时需要指定路由字段shardkey业务SQL的增、删、改、查包含shardkey时，SQL Engine通过对shardkey 进行hash数据根据分片算法，将SQL发往对于的分片4.2水平拆分设计原则标准的两阶段提交协议实现4.3分布式事务基千两阶段提交在MySQL 原生X A 事务的基础上，做了大量的优化和Bug 修复，使其满足分布式事务的使用场景。
经测试，分布式事务与单节点非分布式事务相比，性能损耗仅为25%。
强劲的性能|业务透明分布式事务完全对业务透明，业务只需像常规事务那样使用即可。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
2002
2004
2008
业务爆炸 一致性、 7X24可用性
2010
腾讯计费 超高并发超短 时延
2012
米大师，腾讯 充值 更名TDS务 原生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
金融云分布式数据库TDSQL技术架构
技术创新 变革未来
TDSQL简介
目录
CONTENTS
TDSQL架构与分布式方案 TDSQL分布式事务处理 分布式事务处理技术
金融级云数据库解决方案（CDB for TDSQL）
腾讯公司内与计费、充值、转账、财务等核心系统90%以上都使用TDSQL！
面向金融类业务，十年积累，亿级账户验证
HASH分区
两级分区
RANGE分区 全局唯一数字序列
group by, Order by Max,sum,min,ave等聚合函数 Distinct,count(1) 同一个group内的join 事务
只读帐号支持读写分离
热点更新
Data Buffer脏页刷出效率提升
TDSQL分布式方案（部署）
A( 主 ) T1,T2,T3 A宕机， C选举成 新的主 机 C( 主 ) T1,T2,X3,X4
B(备) T1
C(备) T1,T2
B( 备 ) T1,T2,X3,X4
重新加入，可能需 要回退部分事务 C( 主 ) T1,T2,X3,X4 回退事务T3 B( 备 ) T1,T2,X3,X4 A( 备 ) T1,T2,T3,X3,X4 B( 备 ) T1，T2,X3,X4
Send T2 Inform(T1) 返回应答 ACK(T1)
master
主备复制方案（跨IDC） 异步 半同步 强同步 MariaDB Galera Cluster
slave
TPS 20,000 2,200 20000 6,000 时耗(ms) <10 4~600ms 18 <10 4~10000ms
高一致性
高可用性
安全可靠
弹性容量
性能卓越
7
TDSQL简介
目录
CONTENTS
TDSQL架构与分布式方案 TDSQL分布式事务处理 分布式事务处理技术
数据库部署架构
数据库节点组(SET)由MySQL数据 库、监控和信息采集模块组成一主 二从数据库节点。 调度集群作为集群的管理调度中心， 主要管理数据库节点组、接入网关 集群的正常运行 接入网关集群账号鉴权、管理连接、 SQL解析、分配路由
…
G255
实时在线自动扩容
DCDB的整个迁移过程采用： 移存量数据、迁移增量数据、数据检验、再追增量、切换路由、清理 六个步骤循环迭代进行。 该能力经过腾讯内部近千个业务验证，至今未发生过一次数据丢失或错误。
13
TDSQL强一致原理 SE T
主
4
IDC1
2
3 2
3
备
IDC2
备
IDC3
14
TDSQL强一致原理（确保没有脏数据）
分布式文件系统(HDFS)提供数据灾 备服务，提供至少3份备份
异地容灾数据库节点组部署在主节 点以外的异地机房。
9
数据库核心架构
10
数据分布
11
TDSQL分布式方案（自动扩容）
G0
Set 00 Set 01 Set … Set 255
网关
set 00
G 0 … G 1
G255
网关
G1
G
扩 容
G
永不停机、高一致性
基于OLTP场景
数据库集群
5
TDSQL 数据库的特点
跨机房部署
网络故障不影响业务
三重保障
集群内保障3套节点，单 点故障整体稳定
数据强同步
主备数据完全一致
金融级安全
支持物理专享，支持数 据库审计，支持加密等
可用性：99.999%
数据可靠性：99.99999%
6
TDSQL 数据库的特点
TDSQL高性能原理
更新索引 QPS：10万，99%的 <10ms 纯select QPS：50万，99%的 <5ms
主
备
备
环境：ts85机型(x86，24核(48超线程)，512G内存 ,6T SSD)
19
TDSQL分布式方案（可靠的备份系统）
数据备份
热备：实时同步，实时加载 冷备：快照 + binlog
保存 THD 回话
User ACK Thread
write
Binlog
Dump Thread
read
Dump ACK Thread
IO Thread
SQL Thread
Send Transaction(T1) with ACK request write
relaylog
read
Com m it(T2)
两地三中心
两地四中心 -–(自动化切换的强同步架构)
TDSQL简介
目录
CONTENTS
TDSQL架构与分布式方案 TDSQL分布式事务处理 分布式事务处理技术
数据恢复
就地恢复（闪回/补录） 新节点重建（冷备+binlog） 定点回退（冷备+binlog）
冷备中心 HDFS
全量冷备
实时热备 延迟加载
主
备0
…
备(n-1)
SE T
TDSQL分布式方案（特性）
所有的Set还是原来的NoShard实例 同一个用户的所有表在一起 小表可以广播到所有的Set 每个表都支持全局唯一序列号
1、主机可读可写，备机只读，备机可以开放给业务查询使用 2、任何时刻同一个SET不能有两个主机 3, 宁愿拒绝服务，不提供错误的服务，追求CAP中的C，必要的时候牺牲部分A
Scheduler Scheduler
Agent Proxy Master DB
Agent Slave 1 Proxy Agent Slave 2 SET