【AICon】探索RAG 技术在实际应用中遇到的挑战及应对策略!AICon精华内容已上线73%>>> 了解详情
写点什么

探寻腾讯金融数据库 TDSQL 的十年之路

  • 2016-11-03
  • 本文字数:6300 字

    阅读完需:约 21 分钟

云数据库 TDSQL 是一种兼容 MySQL 的关系数据库,是腾讯云提供的金融数据库解决方案。在腾讯 TEG 计费平台技术总监潘安群看来,金融的数据库要满足一下要求:新环境下的金融数据库应满足以下要求:要保证数据安全性、高可靠性,对数据丢失零容忍;需要高可用的容灾架构,以解决分布式环境中各种异常灾难;完善的水平扩展能力,以适应当前互联网爆发式增长带来的业务请求量和数据量。那具体而言,TDSQL 为了实现其适用于金融行业目标都做了哪些技术功课?InfoQ 采访了腾讯云 TDSQL 的潘安群先生。

嘉宾简介

潘安群,腾讯 TEG 计费平台部技术总监,目前主要负责金融级分布式数据库 TDSQL 的研发工作。2007 年加入腾讯,一直专注于分布式存储系统研发,尤其是分布式 NoSQL 及 MySQL 体系在支付金融领域的研发与实践。

InfoQ:TDSQL 目前线上使用情况如何?有哪些想和大家分享的亮点?

潘安群: TDSQL 诞生于腾讯计费平台部,2014 年开始为微众银行提供核心交易层数据库解决方案,2015 年正式上云,作为腾讯云金融政企行业的数据库解决方案,为客户提供公有云及专有云数据库服务。目前 TDSQL 的客户已覆盖第三方支付、互联网金融、银行、保险、证券、互联网 + 等多个金融政企行业。

数据库技术圈子不大,大家技术交流很开放,开源社区也很活跃,彼此会互相借鉴,所以技术层面,最终可能会殊途同归,只不过是各自产品针对不同场景,做不同的取舍而已。我们认为 TDSQL 有两点比较能打动人的:

  • 良好的用户体验:无论是开发体验,还是运营体验。腾讯很重视用户体验,集团内部有场景并大量使用 TDSQL,腾讯产品上线都会要求腾讯自己首先是重度用户,而刚好我们计费平台部有这么一个场景,全公司所有计费系统全部承载在 TDSQL 上,包括近 100 亿的账户或订购数据,其中就有大家熟知的 Q 币,各类包月服务、游戏点券等等。数据分布在深圳、上海、香港、加拿大等多地。可以说我们积累了很多经验,支付体系对数据库层的要求是什么;也会从运营和开发两个层面去不断思考什么样的数据库才好用。
  • 细节的把控:腾讯 10 多年来在 MySQL/NoSQL 等方面趟过的坑可谓一部血泪史,这促使我们不断的优化细节。就以容灾切换为例,在各种异常、各种灾难下,系统是否表现如预期一样是需要一个长期积累的过程。从 08 年以来,我们几乎每个月都会挑选系统,进行容灾演练确保容灾机制符合预期。即便如此,我们系统在线上依然发现很多场景没有覆盖到,因为故障的表现总是五花八门。所以一个系统的细节完善程度,一定是通过趟坑,在实践中去逐渐完善的。

InfoQ:为什么基于 MySQL?为什么当时没有选用其他类型的开源关系型数据库?

潘安群: 为什么会选择 MySQL 作为 TDSQL 的底层存储引擎,核心还是下面几点:

  • 团队技术能力:从技术上来说对 MySQL 更有把握。从 03 年开始,我们的团队基本都是基于 MySQL 定制开发,积累了不少相关经验。
  • MySQL 的技术成熟:本身的成熟度。金融场景要求的是稳定可靠,这正是我们技术选型的一个重要考查点。
  • 广泛使用和传播:MySQL 使用广泛;我们看好其 MySQL 社区的发展。尤其是 MySQL 近些年的几个大版本表现都非常出色。

InfoQ:TDSQL 的技术研发积累已经十二年,可否分阶段介绍下技术的发展?

潘安群: TDSQL 作为腾讯计费平台数据存储层的第四代产品,虽从严格意义上来说,其研发始于 2012 年,但实际上是我们十二年数据存储层容灾、扩容等方面的经验沉淀:

1)2003-2008,MySQL 热备 + 分库分表 最原始的数据库容灾扩容方案,备份直接使用 MySQL Replication 机制,一主一备或一主两备;容量或性能问题,通过在应用层的分库分表来实现。

整体来说,这套机制是简单有效,但也存在明显的问题,就是在极端情况下,可能会丢数据:因当时 MySQL 只有异步复制模式,并没有现在的 Semisynchronous
Replication,在主机异常或网络异常情况下,应用层直接切换到备机,是有可能丢失数据的。

2)2008-2010,MySQL 7*24 容灾 针对在异常情况下,会丢失数据的问题,我们设计了一套名为“7*24”的容灾体系,其核心思路就是增加了一个一致性控制中心(CC)。CC 会不断的比对主备数据之间的数据同步情况,当故障发生时,CC 会知道所有未同步数据(黑名单),应用层在切换到备机之前,需要先到 CC 拉取这份黑名单,将这些数据置为不可用状态,而其他数据则可以直接访问备机。通过牺牲极少部分用户的可用性,换取了 DB 主备切换的一致,一致性问题得到了系统的解决。整个故障检测、切换、恢复过程均由系统自动完成,基本无需手工操作。

通过大量的容灾演练和实战积累,这个阶段有了相对完善的孤岛检测、黑名单、多级切换等机制。同时,故障检测、主备一致性保障、数据恢复等机制也被提炼出来。当然,这套机制也有着她自身的问题:与应用层是高度耦合的,这要求每个业务开发人员必须对整套容灾逻辑非常熟悉,开发难度和运营维护难度都很高,而且容易出错。

3)2010- 至今,HOLD,一套基于全内存的,高一致性的 KV 存储系统 为了解决应用层与数据层高度耦合的问题,我们又开发了第三代产品,但是她的底层存储不再基于 MySQL,而是自研的一个全内存 KV 存储引擎。

后来的 TDSQL 架构和其中重要技术,几乎都在这个项目里进行了系统性的验证,包括在数据底层实现跨 IDC 的强同步、跨城容灾、切换一致性保障、数据自动的 Sharding、集群管理等。目前 HOLD 存储系统在公司内还大量使用,尤其是一些超高并发的业务系统。而她的缺点也是 KV 系统固有的问题,仅仅支持简单的 Get/Set 等接口,开发不够灵活。

4)2012 年 - 至今,TDSQL 经过近 10 年在数据存储层的摸爬滚打,我们希望能更优雅地解决数据层的问题,于是 2012 年立项 TDSQL:把 HOLD 中验证过的集群架构直接移植过来,将金融场景下最关注的一致性保障和水平伸缩等关键特性,都直接被融入底层架构中,这次直接使用了 MySQL 作为数据存储引擎,以获得成熟的关系型数据存储和访问能力。当然这里也有软硬件行业发展的契机:

  • SSD 在公司内开始大规模使用,SSD 的 IOPS 相对于机械硬盘有质的变化,能满足大部分系统的性能需求。利用好 SSD 优势,能极大简化存储系统的架构体系。
  • 以 KV 为代表的 NoSQL 无法形成业界标准及规范,反观以 Oracle、MySQL 为代表的传统关系型数据库生态完善,使用范围也更广,更容易被开发人员接受。
  • MySQL 在 5.5 版本引入半同步复制,5.6 版本引入 GTID 等机制,而且经过 5.5,5.6,5.7 等几个版本,开源的 MySQL 在性能、数据强一致性方面有了质的提升。

InfoQ:可否给介绍下你们的分布式数据库架构和设计思路?

潘安群: 在架构上,TDSQL 的核心思想只有两个:数据的复制(replica)和分片(sharding),其他都是由此衍生出来的。其中:

  • replica 配合故障的检测和切换,解决可用性问题;
  • sharding 配合集群资源调度、访问路由管理等,解决容量伸缩问题。 对应地,replica 引入了数据多副本间的一致性问题和整体吞吐量下降的问题,而 sharding 的引入也会带来一定的功能约束。

在最终实现上,TDSQL 由 Scheduler、Proxy、Agent 三个核心组件加上 MySQL 组成,其中:

  • Scheduler 是管理调度器,内部又分为 zookeeper 和 scheduler server;
  • Proxy 为接入网关,多个网关组成一个接入层;
  • Agent 是执行代理,与 MySQL 实例一起,构成数据节点。多个数据节点构成服务单元 SET。

InfoQ:是怎么保证服务器的高可用的?

潘安群: 分布式系统中,完整的容灾体系一般都是基于这样一个理论而设计的:多个独立的小概率事件同时发生的几率极低。

举个例子:假如一台服务器在一年内会出现故障的可能性为 0.5%,且服务器之间都是独立的。那么,在某一天内,任意指定的两台服务器均出现故障的几率为:(0.5%
\* 1/365)^2=0.00000002%,也就是常说的 7 个 9 的可用性,远远高于金融要求的 5 个 9。注意,这里的时间跨度是“同一天”,如果缩小到“同时”,如小时甚至分钟级别(一般一个节点故障恢复所需时间是几秒至几小时),这个几率还要小很多。

在这个理论中,实际有四个变量:多个、独立的、小概率、同时。传统的 IOE 架构,专用的软硬件使得其在
“小概率”这个方向上优势明显。而在互联网分布式架构中,正是因其分布式,在“多个”和“同时”这两个方向天生就有优势,所以容灾设计的大部分精力都是投在“独立的”这个方向上。

TDSQL 中,直接在 SET 这个级别上针对上述四个方向进行了优化:

  • “多个”,实际就是冗余度,这里是数据副本的个数。理论上是越高越好,但是太多副本一方面资源投入太大,另一方面保持副本间的一致性成本也很高;所以,在 TDSQL 中,一般要求一个 SET 三个节点;
  • “小概率”,就是节点的故障率,具备一定冗余度的节点会有更低的故障率,比如双电源、双网卡、磁盘 RAID 等。TDSQL 中,通过采用更加可靠的物理服务器来降低单机故障概率;
  • “同时”,实际上可以认为就是单节点的故障恢复时长,如果在一个节点的故障恢复时间内,同一个 SET 的另外一个节点又发生故障,则这两个节点就是“同时”故障。这个时长越短越好。在 TDSQL 中,节点故障是优先本地恢复,若本地恢复不了,会在异地通过物理快照 + 增量 binlog 实现快速重建;
  • “独立的”,就是说一个 SET 内的节点间,越独立越好。但是,这个世界所有东西都是相关的,绝对的独立是没有的。以两台服务器为例,如果它们在同一个机架、或者接入同一个交换机、或者在同一个 IDC,当机架电源故障、或者接入交换机故障、或者 IDC 故障,则两台服务器对外将表现为同时故障。更不用说更大范围的故障了,比如一个城市故障,整个城市的服务器都将“同时故障”。更好理解的例子是:如果地球没了,整个人类世界都没了。所以,“独立”只能是某个级别上的独立。在传统金融方案中,两地三中心的容灾方案,就是城市级别的。在 TDSQL 中,采用的“同城三中心,异地三中心”的方案,相比具有更高的容灾级别。

在同城部署时,一个 SET 至少三个节点,且三个节点跨三个 IDC。当一个 SET 中主机故障时,系统自动切换至备机,对上层应用没有任何影响;由于节点间的数据副本是强同步的,数据也不会有任何的丢失或错乱。当出现 IDC 级别的故障(如整个 IDC 网络孤岛或掉电宕机)时,仍然能保障每个 SET 至少有两个节点,服务也不会受到影响。

在跨城(两城地理距离 >1000km)时,SET 内在异地增加 watcher 节点。Watcher 节点不参与主备切换选举,仅通过异步方式从 master 复制数据。当整个主城故障且无法短时间内恢复服务时,可以直接将服务切换到异地的 TDSQL 上。这时候可能会存在几秒的数据的丢失,但在城市级灾难情况下,这属于可容忍范围。
所以,TDSQL 是将容灾直接做到 SET 内部:每个 SET 可部署为跨机架、跨 IDC、跨城容灾。在不考虑双重灾难的前提下,一个 SET 就是一个永不停服、永不丢数据的服务单元。

InfoQ:什么情况下建议采用数据库的分库分表?什么情况下不建议?

潘安群: 目前 TDSQL 有两个分支版本,一个是 No-Sharding(NS)版本,一个是 Group-Sharding(GS)版本。NS 版本不支持自动扩容;GS 版本支持自动扩容,但是该版本对 SQL 有一些限制,例如只支持 Group 内的 Join,不支持跨 Sharding 的 Join 等。

什么情况下选择 NS 版本,什么情况下选择 GS 版本,对于客户来说主要基于业务的数据量与并发量。目前 NS 版本,在我们现有机型下,最大支持 6T 存储空间,12 万 QPS,如果业务的数据量和并发量小于这个值,推荐使用 NoSharding 版本,因为其 SQL 是 MySQL 全兼容的。如果超过这个值,或者未来增长会比较快,那么就必须选择 GS,虽然在 SQL 语法支持上达不到 NS 版本,但是胜在业务可以近乎无感知的平行扩容。目前我们 TDSQL 在腾讯云上最大的 GS 库表是汇通天下,目前服务器数 12 台(一主一备模式),数据量已达 20T,请求量峰值达到 180 万笔每分钟。

InfoQ:数据库进行分库分表之后怎样保证数据一致性?数据的备份和复制工作应该遵循怎样的基本原则?你们有哪些优化?

潘安群: 我们谈数据的一致性的时候,通常有两种:一种就是 CAP 理论里的一致性,重点描述的是一份数据多个副本的数据一致性;另外一种是 ACID 理论里的一致性,重点描述的是事务的一致性。

首先解决的是多副本的数据一致性,在实现时,主要依赖如下两个机制:

  • 强同步机制:基于 MySQL 半同步复制优化,对于进入集群的每笔更新操作,都将发到对应 Set(每一个 Set 包含 3 个 MySQL 实例:一主两备)的主机上,主机会将 binlog 发往两个备机,且收到其中任一一个备机应答后(仅仅是备机收到了 binlog 并刷盘,但可能还没有执行这个 binlog),然后才本地提交,并返回给客户端应答,这就能确保数据零丢失。此外,强同步机制势必会影响系统吞吐量,所以我们也引入线程池实现,并做了异步化,以提升并发性能。
  • Leader 选举:MySQL 节点本身无法直接参与选举,于是我们由 Scheduler 模块来负责这个事,如果主机发生故障,Scheduler 会从两个备机中,选择一个数据较新的备机(因为 MySQL
    binlog 是严格有序的,所以谁同步主机 binlog 的偏移量更大,谁的数据就更新。当然也可以基于 GTID 来判断)提升为主机。

其次是事务一致性问题:TDSQL 水平 Sharding 后,数据被分布在不同的物理节点,如果一个事务涉及到多个物理节点上的数据,那就存在事务的一致性问题。目前 TDSQL 提供 2PC 的分布式事务功能,当然这里会有性能损耗,业务开发需要做一个选择和平衡:是由数据库的分布式事务来保障数据强一致,还是在应用层来实现。在大并发量的场景下,把这个提前到应用层,并做一些取舍,成本会更好控制。

InfoQ:各个分片数据怎么保证高可靠?如果某个分片出现故障了,该分片数据会怎样,系统会有什么响应措施?

潘安群: 在 GS 版本中,一个 Group 包含多个 Set,每个 Set 负责一个或者几个分片的数据,前端 Proxy 根据路由信息分发 SQL 到对应的 Set。

在 Set 内部,一般使用一主两备的架构,同时主备间使用强同步。如果一个备机挂了,不影响业务;如果主机挂了,由于至少一个备机是和主机同步的,因此该备机升为主机,同时修改路由信息,使得 SQL 能够正确地分发到主机。如果之前的主机能够修复,降为备机加入 Set;否则新增备机加入 Set。整个过程都不需要人为参与,单点故障不影响业务,不丢数据。

InfoQ:在您看来,分布式数据库的运维难点和重点在哪里?

潘安群: 分布式数据库运维体系里面,我们认为最重要的两点就是:自动化和监控。

关于自动化,现在 TDSQL 几乎所有的运营操作,例如购买、扩容、切换、备份、定点恢复、升级等等,均可以通过 HTTP 接口来完成。

关于监控,其实这里挑战很大,误告和漏告对运维来说都是极不友好的事。目前 TDSQL 的做法,基本围绕两个基本原则:

  • 透明。这是最基础的,系统应充分的将自身内部状态呈现出来,并上报到监控系统,目前我们已经采集了 100+ 指标,包括 InnoDB 锁信息、MySQL 活跃线程数,请求时耗等。此外我们也对每一个操作的进度及结果都有严格的采集要求。
  • 告警分级。例如我们对于主备切换,这是非常高级别,需要 NOC 电话告警,而对于慢查询这类,跟业务相关性较强的告警,会配合 IO、CPU 等使用率做告警聚合, 减少告警量。

InfoQ:TDSQL 适用什么样的场景,不适用什么样的场景,为什么?

潘安群: 当前 TDSQL 版本定位主要还是金融、政企的 OLTP 数据库场景,对于 OLAP 这类数据分析场景支持略显不足,对比 Oracle、PostgreSQL 系列产品,在统计函数和统计语法支持方面,例如分析函数等支持不够。此外我们的分布式版本,在分布式 JOIN 等,还有不少优化空间。所以我们并不推荐客户在 TDSQL 上做非常大量的数据分析工作。如果客户有大量的报表需求、关联查询,且数据量较大,我们的解决方案就是通过消息队列,将 TDSQL 数据实时同步到大数据平台(例如 Hadoop)进行计算。

2016-11-03 23:004734
用户头像

发布了 58 篇内容, 共 42.5 次阅读, 收获喜欢 35 次。

关注

评论

发布
暂无评论
发现更多内容

”微博评论“的高性能高可用计算架构

Sky

「架构实战营」

阿里开源的这个库,让 Excel 导出不再复杂(填充模板的使用指南)

看山

Java EasyExcel 10月月更

这几种Java异常处理方法,你会吗?

华为云开发者联盟

Java 数组 异常 程序

Apache APISIX 社区周报 | 2021 9.13-9.30

API7.ai 技术团队

开源社区 api 网关 社区周报 Apache APISIX

微博评论架构设计

Yina🌝很浪🌊

这篇 python 文章,是过去你错过的 python 细节知识点,滚雪球第4季第15篇

梦想橡皮擦

10月月更

架构实战训练营模块 5 作业

Sonichen

【LeetCode】外观数列Java题解

Albert

算法 LeetCode 10月月更

Vue进阶(幺叁捌):vue 路由传参的几种基本方式

No Silver Bullet

Vue 路由 10月月更

学习心得 - 架构训练营 - 第五课

Fm

架构:微内核架构(Microkernel Architecture)

程序员架构进阶

架构 微内核 插件化 10月月更

作业五:微博评论高性能高可用架构设计

紫云

架构实战营

架构设计系列五 如何设计业务高性能高可用计算架构

nydia

架构实战营模块五作业 - 设计微博系统中”微博评论“的高性能高可用计算架构

李焕之

为什么常用二倍图,流式布局中一倍图是否靠得住

你好bk

css3 大前端 html/css 页面布局

(model5)微博评论高性能高可用计算架构

消失的子弹

架构 微服务

微博系统中的微博评论架构分析

眼镜盒子

「架构实战营」

Apache APISIX 社区成员助力 openEuler 发布第一个社区创新版

API7.ai 技术团队

开源 openresty openEuler api 网关 Apache APISIX

微博评论背后的高性能高可用计算架构

Nico

架构训练营 模块五

Leach Sun

微博评论高性能高可用计算架构

毛先生

linux之grep使用技巧

入门小站

Linux

技术人在职场如何摆正心态

baiyutang

职场 10月月更

在线EXCEL文件数据转换解析工具

入门小站

工具

【Promise 源码学习】目录 - Promise 知识点梳理

Brave

源码 Promise 10月月更

【Flutter 专题】28 易忽略的【小而巧】的技术点汇总 (五)

阿策小和尚

Flutter 小菜 0 基础学习 Flutter Android 小菜鸟 10月月更

微博评论高性能高可用架构设计

Geek_db27b5

看动画学算法之:平衡二叉搜索树AVL Tree

程序那些事

数据结构 算法 二叉树 程序那些事

华为云企业级Redis:助力VMALL打造先进特征平台

华为云开发者联盟

华为云 云数据库 GaussDB(for Redis) 华为商城 VMALL

Apache APISIX 社区新里程碑——全球贡献者突破 300 位!

API7.ai 技术团队

开源社区 API网关 Apache APISIX

Prometheus 基础查询(三)范围向量和 PromQL 的缺陷

耳东@Erdong

Prometheus 10月月更

探寻腾讯金融数据库TDSQL的十年之路_数据库_木环_InfoQ精选文章