解密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只是开始，期待与您在金融云上碰撞出火花，一起为互联网金融添砖加瓦。