关于数据库:腾讯云分布式数据库TDSQL在银行传统核心系统中的应用实践

3次阅读

共计 4098 个字符，预计需要花费 11 分钟才能阅读完成。

本文是腾讯云 TDSQL 首席架构师张文在腾讯云 Techo 开发者大会现场的演讲实录，演讲主题是《TDSQL 在银行传统外围零碎中的利用实际》。

我是 TDSQL 架构师张文，同时也是 TDSQL 的开发人员之一。明天的分享内容次要蕴含四个局部，别离为银行行业现状介绍、外围零碎分布式革新、TDSQL 最佳实际和革新成果。

张文演讲现场

搜寻关注“腾讯云数据库”官网微信，回复“1106 张文”即可下载本视频演讲 PPT。

一、对于 TDSQL

银行数据库系统被外企垄断超过 99%。数据库的复杂程度比较操作系统，作为基础性软件数据库对成熟度有着极高的要求，这意味着须要较长的钻研周期和测试才能够进入市场，这也是为什么国内商用数据库畛域长期被国外企业所垄断。

外企数据库绝对免费比拟昂扬，对于腾讯这种大型互联网企业，比如说搞个游戏充值流动或者过年的微信红包，都会产生突增的负载和流量，依照负载来免费，老本将无法估量。所以，如果用传统的商用数据库，咱们赚的钱可能还不够买数据库服务付出的费用，这就倒逼大型互联网企业研发本人的数据库。

TDSQL 诞生于腾讯计费平台部，2002 年以前计费业务最早应用 MySQL 就能满足需要，然而随着公司规模的倒退，到 2007 年咱们对性能、可用性以及数据一致性要求越来越高，同时腾讯的增值业务、娱乐业务在一直增长，比方 Q 币，这时咱们开始研制服务于计费、定位于金融场景的分布式数据库——TDSQL。

2007-2014 年，TDSQL 在外部通过一直迭代、踩坑，逐渐打磨成了一款比拟成熟的数据库产品。2014 年 TDSQL 首次尝试对外输入，胜利利用于微众银行的外围零碎，开始商业化摸索。2019 年 TDSQL 胜利利用到张家港银行新外围零碎，成为国内第一家投产于银行传统外围零碎的分布式数据库，这是 TDSQL 又一个里程碑式的倒退。

二、TDSQL 在银行外围零碎的实际

方才提到银行的外围零碎，介绍一下什么叫银行的外围零碎。

银行的外围零碎为什么这么重要？银行的外围零碎相当于银行的心脏，大家晓得银行是要存钱、管钱的。银行零碎分两局部，一个是外围零碎，一个是外围零碎。外围零碎能够比作银行的大脑，所有和钱无关的交易都须要通过外围零碎，实现资金的清理核算。换句话说外围零碎须要和其余所有对于钱的零碎打交道，因此它的业务逻辑也最为简单、最为要害，它间接影响着银行外围资产相干的数据。如果外围零碎比作大脑的话，外围零碎更像是四肢躯干。所以，外围零碎个别都是泛指各类渠道类业务，比方：手机银行、贷款、柜面、ATM 等。而这些外围零碎一旦波及到金钱交易，必须通过外围零碎实现资金的清理结算。一个外围零碎个别都是一个繁多的业务场景，所以一个外围系统故障只影响以后业务，不会影响全局。

此外，银行对数据库的可用性要求极高，如果一家银行长时间不能对外提供服务的话，客户会对他在银行中存的钱担心，可能会感觉不平安，进而把钱取出来，如果大家都这么做，那么对于银行来说就是挤兑危机。

传统数据库架构的分布式革新

上面咱们来理解一下如何把银行的外围零碎数据库从集中式升级成分布式。

在切入正题之前，这里先讲一个小故事，在做分布式革新的时候，一开始大家很有信念感觉非常简单，间接套用即可，进而间接把集中式的零碎照搬到分布式，发现成果十分不现实次要体现在性能很差，甚至一些简单的 SQL 都跑不进去后果。尽管信念备受打击，但事件都要迈出第一步，如果什么事件都很容易的话，国内过后为何还迟迟没有银行分布式外围数据库的先例?

对于数据库从集中式迁徙到分布式遇到的问题，首先咱们通过对每一个库表进行剖析并从新设计其分片关键字，获取最佳的数据分布策略。从集中式迁徙到分布式，多少有一些数据库高级特效的耦合问题，比如说 TDSQL 不反对序列，而 Oracle 反对序列同时业务代码中用到了大量序列。须要指出的是，TDSQL 曾经是一款标准化的数据库产品，但同时 TDSQL 也十分珍惜在银行传统外围零碎的实际机会，因此对于一些行业内比拟好的个性倡议（比方序列），咱们会将其放入迭代个性中开发。

解决了这个语法差别之后，又发现一个问题，因为银行的外围零碎都是运行多年的老零碎，这些老零碎在晚期开发时为了让业务层更简略，将很多计算相干的操作也放在了数据库层，即用到了很多函数、存储过程、触发器。在咱们外部尽可能不应用这些个性，这些个性不适用于分布式场景下，同时一旦应用后，未来还会面临简单的迁徙工作。此外，数据库应该专一于数据存取，计算相干的简单逻辑放在业务层更符合规范，对这些问题经 TDSQL 团队与跟业务方一起沟通评估，将更适合放在应用层的局部逻辑上移，最终实现了更为彻底的分布式架构。

最初是性能问题解决，对于银行这类金融企业常常会有一些跑批类业务，这类业务的特点是大多都是较为简单的 AP 型的 SQL，这类 SQL 对于 OLTP 型分布式数据库来说是一个比拟大的挑战。次要体现在数据的存储形式上，简单的 SQL 个别波及多个表之间的数据，对于集中式所有数据存储在一个节点上，不存在跨节点取数据，而分布式架构下，数据扩散在不同物理节点，一旦波及多个节点的关联查问，会导致性能急剧下降。针对银行业务的这种 AP 型场景，TDSQL 在简单 SQL 解决方面做了一系列优化，如：子查问上体、左连贯打消，丰盛下推策略等，尽可能进步解决简单 sql 的性能。最初当前述工作做完之后，其实咱们曾经达到交付规范，对于张家港行来说曾经够用了。然而，毕竟是作为全国第一家投产于传统外围零碎的分布式数据库，作为第一家就应该有一个第一家的样子，所以步骤 5 是一个继续优化的过程，利用 TDSQL 一系列性能优化、诊断工具，对每一条可优化 sql 进行优化，最终把性能晋升到极致。步骤 5 完结后，张家港行新外围零碎从刚开始的不可用，到起初体现优异，宛如从一架马车进化成了一艘火箭。

刚刚探讨了革新过程，咱们看到其实这个革新过程说简略也不简略，说难其实也没有太简单，总体思路是一个先跑通再优化，从简略到简单的过程。因为在银行业务里，大部分都是一些绝对不算是特地简单的 SQL，特地简单的 SQL 往往都是跑批类的，而银行大部分业务都是高频交易，所以，解决了高频交易，代表解决了问题的百分之九十的问题，剩下只是花多少工夫的问题。总结成一句话就是：“先解决高频率，再解决跑批类”。

分布式事务

作为分布式数据库，尤其是银行场景的分布式数据库，最关怀的就是分布式事务。

比方银行里 A、B 两人须要转帐，用户 A 的账户是在第一个物理结点，用户 B 的账户是在第二个物理结点。对于转账这个场景，也就是对 A、B 账户的余额的操作，要么全副胜利，要么全副失败，不能给 A 扣了款 B 没有加款，或者 B 加了款 A 没有扣款，这就是 TDSQL 分布式事务的保障。所以说，如果分布式数据库不反对强壮的分布式事务，那么它很难适应银行类金融场景。当然，分布式事务因为波及到多个数据节点，同时须要额定做很多的校验和通信，因此肯定会有性能损耗，TDSQL 这里通过大量优化仅损耗 25%。TDSQL 的分布式事务基于 MySQL 经典的两阶段提交，在 MySQL 的 XA 事务上二次开发，修复了大量官网 BUG 保障分布式事务的健壮性。

高可用部署架构

说完了分布式事务，再来聊聊银行的高可用部署架构。这是一个规范的两地三核心架构。同城部署，总行机房和灾备机房两个机房之间的数据同步基于 TDSQL 的强同步复制，保障在主机房写胜利的同时，至多在备机房的一个节点上落盘胜利。异地机房，次要用来做异地的灾备实例。

数据同步

上面咱们再来聊聊数据同步，对银行来说，尤其是第一家外围零碎采分布式数据库的银行，无论上线前你讲得再好，演练得再好，或者说测试得再好，也还是有肯定的不确定因素。这就引出了个 Oracle 灾备的计划，将 Oracle 作为备胎和 TDSQL 放弃实时同步关系，在极其状况下容许从 TDSQL 切换到 Oracle。兴许这个计划永远都不会用，然而正因为有了这个兜底计划，对银行来说用分布式数据库才更有信念。

数据同步计划这里另一个设计是多源同步解决方案——TDSQL 到其余异构数据库的导入导出。TDSQL 抱着一个凋谢的态度让用户抉择接入，并不绑架用户，如果哪一天银行客户用了 TDSQL，感觉用得不好，或者感觉 TDSQL 不满足他的需要或有比它更好的，通过数据同步计划能够轻松将数据迁出，TDSQL 反对业内规范格局的数据订阅，不便数据的导入导出。

自动化数据库经营治理
上面咱们持续再往下看到的是 TDSQL 自动化经营治理平台。作为银行科技部门的运维，心愿尽可能疾速上手，缩小人员培训老本，运维零碎尽可能自动化高，集成化高。

赤兔监控就是一个数据库的监控指标，提供上百项的数据库监控，数据库各项衰弱状态、性能参数高深莫测；监控通过联合智能告警，及时捕捉数据库异样状态，告诉 DBA 相干责任人解决。扁鹊零碎，是一套弱小的智能 DBA 诊断系统，基于腾讯海量运维教训，联合弱小的语法、规定库，对数据库进行一键诊断、迅速定位性能问题。一键运维，顾名思义所有运维操作集成到页面上，升高运维人员误操作的概率。须要强调的是，咱们 TDSQL 跟传统数据库厂商有什么不同，传统数据库厂商研发数据库产品，卖给客户应用，而咱们在卖给客户之前，首先在本人外部充沛验证和实用，先拿本人的业务体验和采坑。