一、关于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跟传统数据库厂商有什么不同，传统数据库厂商研发数据库产品，卖给客户使用，而我们在卖给客户之前，首先在自己内部充分验证和适用，先拿自己的业务体验和采坑。
- 性能和成本双优化
刚刚介绍了那么多，最后我们分享一下以张家港行为例，银行传统核心完成分布式改造之后达到的效果，主要是成本和性能两方面。
先看性能，查询交易100毫秒之内，高频率交易300毫秒，贷款结息3分钟，日终跑批14分钟，这是银行披露的数据。目前这个性能已经完全满足张家港行未来十年的业务量。
![Uploading file...]()
再看成本，按照Oracle的架构，硬件方面需要采用大型机、小型机，张家港行采用腾讯云TDSQL分布式数据库架构后的硬件成本，只有传统架构成本的1/5甚至更低。此外，由于TDSQL是分布式的架构，支持水平扩展，通过不断增加硬件资源可继续提高吞吐量。
所以，当看到这样的成本性价比，相信任何一个有商业头脑的银行，当目前核心涉及到更新换代时，肯定不会再像以往那么坚定的选择国外厂商，而是更多考虑国内互联网公司的分布式数据库。