解密Midas、Webank、金融云背后的核心数据库TDSQL【海量服务之道2.0】

如果,你在寻找一款数据库,希望:

•在任何情况下,数据都不丢失或错乱;

•能7*24小时不间断的对外提供服务,即使故障也不会中断;

•能支撑业务量10倍以上的弹性伸缩,不用担心会被压垮;

•能快速响应请求,为用户提供最爽的体验;

•没学习门槛,能快速上手;

•便宜,少花点钱;

那么,TDSQL就是你的菜!

TDSQL(Tencent Distributed mySQL-腾讯分布式MySQL)是由腾讯技术工程事业群计费平台部针对金融联机交易场景开发的高一致性数据库集群产品。其底层基于MySQL,针对金融OLTP场景进行了如下增强:

•通过多副本冗余和故障自动切换机制,解决单点问题,确保在单机、单IDC、甚至单个城市灾难时,服务持续可用;

•对数据多个副本之间的一致性保障进行深度优化,实现数据访问、主备切换的一致性,确保在单机、单IDC故障时数据零丢失;

•引入集群机制,实现自动的容量伸缩,确保在业务飙升时,数据库服务能力自动适配业务增长,保持对外服务的持续可用。

TDSQL解决方案

背景

在金融场景下,数据的准确性是高于一切的。因为在金融数据库中

1.数据直接代表的是真金白银;

2.你不知道丢掉或者出错的那条记录,代表的是一分钱,还是10个亿。

每条记录都可能是10个亿!是不是想想都头皮发麻?

所以,金融级数据库在软件领域一向都是最有挑战的方向之一。其最低要求都是:

1. 数据读写必须一致;

2. 任何时候不能丢失数据、搞错数据。

然而,我们面对的环境却是

1.硬件:没有高端硬件,有的全部是普通PC服务器;所以,故障是正常的,没有故障才不正常;

2.软件:从OS到数据库,都是开源软件;一般开源软件只是一个基础框架,而且没有技术支持、没有服务承诺的,出了问题只能自己解决;

如何基于这样“不太靠谱”的软硬件环境,打造非常靠谱的金融数据库服务?这是TDSQL团队面临的最大挑战。

方案

在金融传统的IT领域,DB2、Oracle等是绝对主角。这些商业产品功能强大,OLTP、OLAP通吃,要什么功能基本都能提供。但是,这是有前提的:看看他们的软硬件环境,基本都必须是定制的高端产品。比如传统的IOE方案:小型机、商用数据库、高端存储,这个组合简直就是“强大、专用、贵”的代名词。

以我们的普通PC服务器和开源软件,去跟这些巨头拼通用性,显然是不自量力。所以,一开始我们就明确定位:做金融垂直行业的OLTP数据库解决方案。

目标一旦确定,边界也就清晰了。在MySQL之上,TDSQL要解决的核心问题是:

1.保障数据不丢不错;

2.保障服务不中断;

3.保障数据服务能按需伸缩;

架构

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

•replica配合故障的检测和切换,解决可用性问题;

•sharding配合集群资源调度、访问路由管理等,解决容量伸缩问题。

同时,因replica引入了数据多副本间的一致性问题和整体吞吐量下降的问题,而sharding的引入也会带来一定的功能约束。

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

•Scheduler是管理调度器,内部又分为zookeeper和scheduler server;

•Gateway为接入网关,多个网关组成一个接入层;

•Agent是执行代理,与MySQL实例一起,构成数据节点。多个数据节点构成服务单元SET。

具体架构如下图示:

具体实现请参考

TDSQL的优势

相比单机版的MySQL,TDSQL的优势主要体现在集群维度,包括容灾、高一致性、高弹性等。

注:✔ 支持,✘不支持, ○不适用

容灾

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

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

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

TDSQL中,是在SET这个级别上针对上述四个方向进行了深入的优化:

•“多个”,实际就是冗余度,这里是数据副本的个数。理论上是越高越好,但是太多副本一方面资源投入太大,另一方面保持副本间的一致性成本也很高;所以,在TDSQL中,一般要求一个SET三个节点;

•“小概率”,就是节点的故障率,具备一定冗余度的节点会有更低的故障率,比如双电源、双网卡、磁盘RAID等。TDSQL中,通过采用更加可靠的物理服务器来降低单机故障概率;

•“同时”,实际上可以认为就是单节点的故障恢复时长,如果在一个节点的故障恢复时间内,同一个SET的另外一个节点又发生故障,则这两个节点就是“同时”故障。这个时长越短越好。在TDSQL中,节点故障是优先本机恢复,若本机恢复不了,则会通过物理快照+增量binlog快速重建节点,补齐SET;

•“独立的”,就是说一个SET内的节点间,越独立越好。但是,这个世界所有东西都是相关的,绝对的独立是没有的。所谓的独立,只是某一尺度内的独立。以两台服务器为例,如果它们在同一个机架、或者接入同一个交换机、或者在同一个IDC,当机架电源故障、或者接入交换机故障、或者IDC故障,则两台服务器对外将表现为同时故障。更不用说更大范围的故障了,比如一个城市级的灾难,整个城市的服务器都将表现为“同时故障”;更好理解的例子是:如果“光粒”击中地球,整个人类世界都没了,在星球这个尺度上,地球就是个单点。在传统金融方案中,两地三中心的容灾方案,就是城市尺度的。在TDSQL中,采用的“同城三中心,异地三中心”的方案,相比具有更高的容灾级别。

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

在跨城(两城地理距离>1000km)时,SET内在异地增加watcher节点。Watcher节点不参与主备切换选举,仅通过异步方式从master复制数据。当整个主城故障且无法短时间内恢复服务时,可以直接将服务切换到异地的TDSQL上。这时候可能会存在几秒的数据的丢失,但在城市级灾难情况下,这属于可容忍范围。

所以,TDSQL是将容灾直接做到SET内部:每个SET可部署为跨机架、跨IDC、跨城容灾。在不考虑双重灾难的前提下,一个SET就是一个永不停服、永不丢数据的服务单元。

高一致性保障

数据库系统中,一致性包括了时间和空间两个维度。即:

•读写一致性,或者说事务的一致性。这是从时间维度来观察的,表现为事务处理系统中ACID的C;

•主备一致性,或者说副本间的一致性。这是从空间维度来观察的,表现为分布式系统中CAP的C。

在一个SET中,由于网络、节点能力等原因,数据的多个副本在同一时刻可能会存在不一致的情况,这就是读写一致性问题。这个问题比较好解决,TDSQL要求一个SET在任意时刻只能有一个master节点,其他都为slave节点(或watcher),由master对外提供数据的读写服务,这样保障对外的读写是一致的。(注:更底层的读写一致性,如对同一个数据的并发访问,由MySQL数据引擎来解决,这里不深入讨论)

Master在负责向外提供读写的同时,也负责向slave/watcher复制数据。同样因为网络或节点自身的原因,数据复制会有延迟。如果在某个时刻,数据还没有复制到slave节点,master突然宕掉了,则在主备切换后,很可能会出现数据丢失,这就是主备切换的一致性问题。这个问题解决起来比较复杂,在考察了多种技术后,TDSQL最终通过修改MySQL内核代码,实现主备强同步来保障切换后的一致性。

在强同步模式下,TDSQL确保一个commit请求返回给APP之前,数据的变更在SET中至少有两个完整的、已落盘的副本。任意时候,如果主节点故障,只需要将请求路由切换到数据最新的备节点即可,对外服务不会中断,数据也不会丢失。

水平伸缩

TDSQL为金融场景提供两种伸缩模式:No_Sharding、Group_Sharding。其中

•No_Sharding针对规模较小的场景,不分库分表,只支持垂直伸缩,单SET最大容量为一台物理机的容量;

•Group_Sharding则针对规模较大的场景,自动按组分库分表,支持水平伸缩,如下图示:

一开始业务规模比较小,数据全部在一个物理节点上。随着业务规模的扩大,占用的磁盘空间、内存、CPU等越来越多,当耗用的资源持续超过物理节点的阀值时,说明一个物理节点已经无法支撑这样的业务规模了,系统就会触发扩容流程:将部分数据迁移到新的节点上,并在gateway上对应的调整路由规则。

整个的扩容的过程均由TDSQL自动完成,无需用户修改配置、搬迁数据,也不会中断服务。对前端应用来说,它看到的始终没变,都是网关上的逻辑库表,后端的物理库表迁移对它来说是完全透明的。

易用性

对于运维工作,TDSQL提供了web管理台,绝大部分的管理工作可以通过web图形界面完成。同时,也可以直接在命令行终端通过MySQL client登录TDSQL,因为看到的始终是网关上的逻辑库表,整个过程跟操作一个单机版的数据库一样。

对于开发工作,TDSQL提供统一的逻辑表界面。不管后端数据分布在多少个物理节点上,开发人员看到的都是一个大的逻辑库表,只需要针对这个逻辑的库表编程即可。大大简化了编程难度,把开发人员从复杂的分库分表逻辑中解脱出来,真正只需要关注业务逻辑。

性能

在同城跨三个IDC的部署结构下,MySQL异步模式TPS可高达20000。而一旦切换至同步模式(半同步模式在未掉落为异步模式前是同步的),受跨IDC网络延时增大的拖累,TPS急剧下降至2200左右。

针对强同步模式下的吞吐量下降问题,业界也有很多探索,比如网易的InnoSQL对半同步机制进行了优化,将吞吐量提升至4500;Percona和MariaDB集群中的Galera,采用虚拟同步机制在节点间进行数据复制,吞吐量能达到6000,但时延毛刺严重,在OLTP高压力场景下基本不可用。

TDSQL对此也做了大量的优化,优化后跨IDC强同步的TPS上升至9500左右,基本达到业界最高的水准。

注:此处为使用sysbench标准用例测试结果。

在实际应用中,以Midas为例,TDSQL承载的账户量超过100亿,每日请求超10亿,99.95%的请求在5ms以内响应。而且在如此海量数据规模、苛刻用户体验要求下,TDSQL在两年多的运营周期中仍然交出了零服务中断、零数据误差的答卷。

可以说,TDSQL在Midas上经受住了互联网海量数据规模、苛刻用户体验以及准金融级严苛数据保障的三重考验。

应用:互联网+金融

Midas苛刻的业务场景成就了TDSQL,一个金融级的联机交易数据库在实战中不断淬炼、茁壮成长。2014年,Webank的横空出世,给了TDSQL一个更大的舞台。

Webank

作为国内第一家纯互联网银行,Webank除了“刷脸支付”、“大数据信用”这种业务模式中时时流露出的互联网气质外,其背后的IT基础架构也抛弃了传统的IOE,完全采用了互联网分布式架构。TDSQL在Webank中取代Oracle作为交易核心DB,部署超过800个节点,承载全行所有OLTP业务。

在Webank项目的实施过程中,我们对TDSQL的性能是胸有成竹的。但是,由于之前银行的业务系统基本都是基于DB2或Oracle等商业数据库进行开发的,与TDSQL的差异还是比较大,对于将系统从原来的IOE架构迁移至TDSQL这种分布式架构,心里确实没有底。

在进行大规模系统移植之前,TDSQL和Webank应用系统团队一起做了大量的适配测试。比较幸运的是:

•Webank全套系统都是从零开始,不存在历史数据需要迁移,所以整个移植工作只需要进行系统功能适配就行了;

•很多银行应用软件提供商的系统为了适配不同的底层DB,在系统架构中设计有DB访问层,将业务逻辑和后端DB做了比较好的分离,所以适配工作对业务逻辑改动较小,调整集中在DB访问层;

•TDSQL本身跟MySQL高度兼容,应用系统的技术团队对MySQL都比较熟悉,团队技能在TDSQL上可以复用;

所以移植的难度并没有之前想象的大,工作主要集中在DB访问层的改造,以及功能和性能的验证测试。整个过程中,开始阶段问题比较多,后面就越走越顺利,仅用半年时间就完成了几大核心系统的移植工作。验证了从传统IOE架构迁移至TDSQL是完全可行的,迁移的成本也并没有想象中的高。

由于完全采用互联网架构,相比传统的IOE方案,webank在IT成本上大幅节约。同时,互联网架构的高伸缩性,使得Webank的服务能力具备很高的弹性,足以轻松应对普惠金融场景下的潮涌。

目前,webank各业务已陆续对外发布,运营良好。

金融云

在过去的几年内,互联网风暴席卷了所有传统产业,“互联网+”深入人心,深刻的影响着我们的衣食住行。

在这场互联网颠覆大潮中,金融行业也未能幸免,成了被颠覆的对象之一。各种互联网金融模式如雨后春笋般大量涌现,第三方支付、P2P网贷、大数据金融、众筹等等野蛮生长。在互联网技术的推动下,普惠金融正在从理念走向现实。

金融业务在转型,但是传统的金融IT基础架构却成为了掣肘:

•传统的金融IT架构是建立在封闭的商用设备和系统上的,购买费用和维护费用均居高不下;

•在普惠金融场景下,业务伸缩可能是10倍、甚至上100倍的。传统的集中式架构要达到这么高的弹性,投入将是天文数字,且不得不容忍大部分时间空转浪费;

•国家要求在金融行业更多使用自主可控的底层架构,以加强信息安全的可控性。而封闭的商用系统显然与此相抵触。

因此,金融IT基础架构“去IOE”势在必行。

Webank的成功上线,证明了TDSQL及互联网架构完全有能力支撑金融核心业务。而其低成本、高弹性以及开放的架构又恰好能弥补传统IOE架构的不足。

看起来,TDSQL就是去IOE的银弹。但是,事实真的如此吗?

大家都知道,互联网分布式架构的底层基础是开放的硬件和开源的软件,初始获取成本会比较低。但是,要用于生产的话,还需要进行大量的优化和改进,而且对运维团队的能力要求也比较高。如果企业想直接迁入分布式架构上,势必需要组建一个技术团队来搞定这些问题,这就相当于将原来IOE架构下投在软硬件上的成本转投到人力上。在IT系统规模较小时,完全没有优势,甚至是得不偿失的。这也是“去IOE”喊了这么久,实质性进展却比较小的一个原因。

但是,云计算的出现改变了这一切。在云计算架构下,这些本来要招一帮牛人才能搞得定的事情,现在已经有一帮甚至更牛、更专业的人帮你搞定了。你要做的,只是“申请、使用”,就这么简单!

所以,TDSQL不是去IOE的良药,但TDSQL on Cloud才是。

2015年,TDSQL和腾讯云携手,启动“金融云”的建设工作。金融云的目的是:帮助金融企业快速搭建符合金融行业标准的IT系统,减少企业IT投入、降低研发运维复杂度、快速推出金融服务、促进金融创新。

腾讯金融云面向金融行业提供从IaaS、PaaS、直至SaaS的完整技术栈。

TDSQL在其中是作为PaaS层的数据库服务提供者。企业需要金融级的OLTP数据库服务时,无需经过自建机房、自购机器、自建团队等这个漫长的过程,直接在腾讯金融云即申请、即使用。

目前,招联金融的好期贷已经顺利的迁入金融云。这是TDSQL on Cloud作为“去IOE”替代方案的第一个完整case:迁移的内容不仅包括业务系统对接,也包括了历史数据的迁移。整个迁移过程非常平滑,仅用了不到一个月的时间。经过这个case,在之前Webank验证系统迁移可行性的基础上,进一步验证了数据迁移的可行性。

后续,包括招联金融在内,还有很多传统和新型金融企业在陆续接入中。随着相关政策的完善,云上金融的时代已经开启。

如果您有金融数据库的需求,请访问腾讯金融云 ,在这里您可以获得更详细的资料和直接试用。

结语

十年磨一剑!TDSQL团队始终不忘初心:打造好用的金融级数据库。midas、webank只是开始,期待与您在金融云上碰撞出火花,一起为互联网金融添砖加瓦。

原文发布于微信公众号 - 腾讯大讲堂(TX_DJT)

原文发表时间:2016-02-05

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏开源项目

GVP 特辑!7 款 JAVA 程序开发“大杀器” | 码云周刊第 39 期

码云 GVP 特辑 工欲善其事,必先利其器。对于 Java 程序员来说若想提高工作效率,那么以下这 7 款 Java 程序开发工具绝对是你不能错过的,不仅可...

3725
来自专栏域名资讯

2017上半年Radix注册局优质域名报告

注册者销售的优质域名已经涵盖优质域名续费成本。

1050
来自专栏程序员互动联盟

为什么国外的码农爱用苹果 Mac电脑?

Mac 在国外很受欢迎,尤其是在 设计/web开发/IT 人员圈子里。普通用户喜欢 Mac 可以理解,毕竟 Mac 设计美观,简单好用,没有病毒。那么为什么专业...

8019
来自专栏Guangdong Qi

iOS审核拒绝苹果官方原因详解

7892
来自专栏北京马哥教育

开源爱好者必看!开源许可证基础知识扫盲

作为一个开发者,如果你打算开源自己的代码,千万不要忘记,选择一种开源许可证(license)。 许多开发者对开源许可证了解很少,不清楚有哪些许可证,应该怎么选择...

4258
来自专栏SAP最佳业务实践

从SAP最佳业务实践看企业管理(121)-MM-130无QM采购

该采购流程使用报价请求,采购申请可以通过物料需求计划流程生成或由申请人手动生成。买方验证采购申请的准确性,然后将采购申请转换成采购订单。 同时也可以通过手动创建...

3475
来自专栏Titan框架

XML是历史前进中的怪胎

人的理性是有限的,甚至拙劣的,但理性中的人却很自负。互联网本身不是被理性事先设计出来的,但是我们总是想在互联网上再次理性设计,XML和区块链都是人类理性自负地结...

760
来自专栏FreeBuf

为什么说不要用VLAN、VPC解决东西向隔离问题

作为一个严谨的、有着职业操守的安全从业人员,首先我要摸着良心说:技术没有好坏,评价一个技术,我们主要看它能否在某些场景下很好的解决特定问题。而基于我们多年来的运...

1682
来自专栏北京马哥教育

2018 年 Linux 的 8个发展预测和学习建议

运维行业正在变革?推荐阅读:30万年薪Linux运维工程师成长魔法 转眼间,时间已进入 农历2018 年新年,2018 年又会有哪些新的趋势?OMGUbuntu...

4349
来自专栏安全领域

能够保护公司免受黑客攻击的最佳实践经验

原文地址:https://www.entrepreneur.com/article/237174

1032

扫码关注云+社区