从数据库巨人身上撕开一道口子

大咖介绍 苏强，腾讯云数据库资深产品经理，拥有多年ToB产品策划、产品运维经验。曾在多个知名企业任职产品经理，主导或参与多款业内知名的B端产品从0到1过程，部分主导产品已实现同类产品占有率第一。接手腾讯分布式数据库以来，主要负责腾讯云分布式数据库功能策划、市场能力建设、服务支撑能力建设和团队建设等。

你们好，我是来自腾讯云的苏强。从腾讯云分布式数据库商用那天起，我就在分布式数据库团队里，因此能够很自豪地说，我是最了解腾讯云分布式数据库的人之一。今天我将和你们分享近两年来分布式数据库在金融行业里真实应用的细节与核心。

1、金融行业现状

目前国内大中型银行主要以国外厂商提供的大型主机和数据库解决方案来进行系统构建。因为近年来金融业务量的不断增加，以及银行数字化转型成为必然趋势。目前以国外大型主机和数据库为核心的架构已没法知足大规模交易和数据处理的需求。

一方面：性能没法知足业务不断激增的处理需求，存在系统过载风险；另外一方面：自己价格比较昂贵，维护成本居高不下。

以手机银行、网上理财、互联网保险等为表明的金融业务创新快速发展，推进新技术正之前所未有的速度与力度发生深层次变革。

这些技术发展，对金融服务模式带来重大影响，使得金融行业向数字化、分布式转型成为必然趋势，金融业务创新与科技创新正在相互促进，重塑金融行业系统能力。

一、分布式数据库领域的百家争鸣

| 多种架构长期共存： 分布式数据库通过这么多年的发展，实际上并非一种新兴的技术了，从最先基于中间件的模型开始到如今基于分布式存储的架构，这些架构一直在并存着往前发展，谈不上哪一个更优秀，由于都各有各的应用场景。

| 多种技术栈卡位竞争： 分布式技术目前发展的方向是，技术栈有兼容MySQL的，也有兼容Oracle的，也有兼容PG的，各技术栈如今互相卡位，在国内的厂商之间，几乎每一个厂商都跟着一条线。

l 厂商互相PK： 目前投入的厂家，特别是在这两年国家对这块的支持力度和资本介入之下，作分布式数据库的厂家愈来愈多，造成了互相竞争的关系。

二、金融客户应该如何选择分布式数据库

抛开所谓的金融产品的可靠性、可用性等技术点之外，选择一个金融分布式数据库最核心的要点我认为是如下四方面：

l 质量可靠： 产品应该成熟可靠，通过大规模业务持续验证，拥有较多的客户案例和ISV集成经历。
l 团队建设： 创建能用、会用、用好国产数据库的人才队伍；造成一支具有高水平维护能力的队伍。
l 持续演进： 背靠优质平台或生态，产品能够持续演进发展；厂商拥有一流的研发团队和长期投入。
l 服务能力： 在国内主要地市创建健全分销体系、培训能力、服务团队。不只包括数据库，更能覆盖金融全技术栈的服务能力。

三、腾讯云分布式数据库解决方案

腾讯云分布式数据库最先源自于腾讯的增值业务，从充值Q币开始一直到财富通、微信支付、微众银行，腾讯的分布式数据库一直是基于开源的自主研发。最近几年咱们开始逐渐面向产研结合和产用结合，在产研结合方面咱们和国内顶级高校创建了联合实验室，也在国际上发表了多篇顶级论文；在产用结合方面咱们和不少银行创建了联合实验室，共同促进产品发展，目前主要应用的是咱们TDSQL和TBase两条产品线。

2、金融应用实践

接下来将分享一个关于某金融客户主机下移过程的真实案例，但愿能真正给到你们一些启发。

抛开细枝末节，只聚焦在数据库上，咱们怎么样把数据库的核心往下切？当时咱们总结出了如下七个问题：

如何选择分布式技术栈；

如何设计信息技术创新节奏；

如何使用分布式数据库；

新老系统的切换；

分布式的扩展容灾方案；

如何对国产数据库进行运维；

其余典型场景分布式数据库如何适配。

一、分布式技术栈的选择：对主流方向都有布局和应用

对于分布式技术栈的选择，目前有两个主流方向，一个是兼容MySQL，一个是兼容Oracle。

兼容MySQL的优点是其分布式技术栈比较成熟，易于团队建设。基于MySQL的分布式协议最先来自于国外的一些互联网厂家，后逐渐引入到国内的互联网厂家，包括国内的微信支付、蚂蚁金服等几个巨头的支付厂家，其底座都是以兼容MySQL协议为主，再加上这么多年国内开发者对MySQL的研究，因此在此背景之下，金融机构的相关团队建设是比较容易成型的。

兼容Oracle的优点是对整个金融系统的改造、迁移、使用成本相对较低，有可复用的部分而且方案相对简单。

因此说这两个技术栈方向都各有优点，腾讯云由于金融业务足够大因此覆盖了这两个方向的产品，都有本身的产品线，咱们如今都把它叫作分布式数据库产品线，分别是MySQL技术栈的以及Postgre技术栈的产品。

二、技术创新节奏

1）某大型银行客户的主机下移“五年计划”

了解过技术栈的选择，接下来就是考虑自身团队适合哪款产品、选择这款产品后怎么设计核心系统等。如下是某大型银行真实计划的缩影，他们给整个过程设定了五年计划原则：

技术团队：创建一支熟悉分布式数据库技术栈的技术团队；

分批改造：根据业务重要性，分批分阶段改造业务系统；

业务磨合：技术方案应在不影响宏观稳定，确保业务与数据库磨合；

技术复用：该技术应该是能够复用或容易创建的；

全量切换：应该是在彻底磨合好之后，再全量切换。

而且分红四种节奏开展落地：

2018~2019年，团队招聘与培养：肯定基于Oracle+MySQL实现双技术栈团队建设，并选择互联网银行业务选择开源MySQL方案打磨团队；

2020年，（试点）核心系统改造：团队对MySQL熟悉后，实现核心业务系统基于腾讯云TDSQL上线并开始运营；

2021年，新老系统并行，剩余系统改造：老业务系统不下线，数据保证明施同步回老业务系统，若是新业务系统一旦故障确保老系统可用；

2022年，最终核心交易全量切换：在运行一段时间后，确保新系统彻底稳定后，再封存老系统。

2）某银行客户传统核心业务系统改造过程

以上是另外一个银行客户的案例，他们的客户规模相对于上面的银行小一些，因此进程较快。他们在2018年4月选择了某一个技术栈方向，而且开始POC测试，联合着XXX（英文）在2018年末到2019年初就在业务系统改造生产完成，而且在2019年上半年经过了相关专家机构的评审，正式上线。在2019年年中投产，逐步投产后运行很是稳定，并且性能较以前有较大的提高，因此2019年末整个核心系统所有下移投产。整个过程经历了差很少两年的时间，过程当中整个项目团队的工做是很是紧张的，并且也借助了大量的成熟经验和长亮科技能力。

三、数据层下移的拆分策略

1）水平拆分&垂直拆分

在执行了相应的规划之后，就要考虑数据库改造中数据层下移的拆分策略。说到水平拆分就不得不说起垂直拆分，垂直拆分通常是在SOA时代，基于业务垂直拆分。

分布式改造最主要的仍是对其中一些业务核心户进行水平拆分，使其可以适应新时代新的科技金融业务的发展。但也并非全部的系统都须要分布式改造，有些规模比较小的系统就不必。腾讯的产品是集中式和分布式组合在一块儿的，便于客户只买一个产品，能知足几乎全部数据库的需求。

2）水平拆分的主要方案

从实践来说，数据层下移的拆分方案主要分为三种：

第一种是按客户维度拆分：如上图所示，主要面向客户规模比较大、无明显分布性、交易金额小、笔数多等这种对私类业务，通常的拆分策略是一致性哈希。

第二种是按分公司（法人）维度拆分：如上图所示，主要面向集团，其业务是基于分公司维度展开的，主要有几个特色——业务按分公司维度展开；交易/清算等以该维度展开；不一样分公司交易规模区分明显；总部搭建业务系统和数据收口；分公司总数少但交易数量多。因此腾讯提供了一种叫虚拟组的能力，能够在分公司分布的基础上再进行拆分，帮助用户去提高。好比一个发展比较快的东南亚分公司，可能原来只须要一个小的分片，两年后爆发式增加就能够基于这种架构进行快速无缝的扩展。

第三种是按时间维度拆分：如上图所示，一般是订单类的系统，并且按时间维度会涉及到大促时期呈峰值增加的问题。这种场景下，腾讯的产品能够提供一种二级分区的能力，能够按照时间分区，这就意味着不管归到历史库也好仍是这一时间阶段交易规模比较大也好，均可以均衡地负载性能。

四、新老系统的切换：DTS-DBBridge

接下来就会涉及到研发，一旦涉及到研发就要考虑整个业务系统迁移的流程。这个流程从最开始的业务沟通，腾讯就能够开始介入，腾讯的技术人员能够经过咱们成熟的迁移工具DBBridge输出对业务系统迁移的评估报告，同时配合开发人员进行业务系统改造、实施、新老系统的并行上线以及到最后的切换，整个服务体系均可以造成一个闭环。

五、国产数据库的运维：DBBrain&分布式数据库管理系统

迁移完成后就涉及到如何管理数据库，这里涉及到咱们另外一个方案DBBrain，它可以帮助用户从全局角度分析分布式数据库运行的状况，其中积累了腾讯海量的运维经验。

六、分布式多活多SET化扩展容灾方案

运维起来之后，随着运行一年到两年，某些核心就要开始考虑是否要符合监管的要求，是否要作两地三中心和容灾，甚至随着金融业务呈爆发式发展，原有的机房已经不能知足需求，须要换多机房方案。

传统的两地三中心容灾方案，从金融科技发展角度会呈现出一些小问题，好比容灾须要人工干预，当真的面临事故时，是否敢作切换的决策？实际上不少金融IT从业者都不敢打包票。另外就是备机房常态下无流量，利用率较低，因此如今发展出多活的容灾方案，简单来讲就是把业务系统经过一层网关进行一个按SET的划分，每个SET下面都对应一套数据库，这个数据库既能够是集中式也能够是分布式。腾讯里像微信支付，都是使用多SET的模型。

SET的主从之间是采用数据库的强同步，SET与SET之间同类业务采用数据同步模型，由于上层的SET作了业务拆分，因此两个SET组之间的数据是不冲突的，能够互相进行同步。这类架构目前也在国内的某头部保险公司，一样是腾讯云的客户，已经试验了两地四中心的架构，到目前为止已经稳定运行超过9个月，单个SET能承载的理论容量是10TB，理论TPS是5K以上，并且性能能够基于SET化的分布式扩展往上加，因此SET化能够扩展的能力是很强的。

七、典型场景

腾讯的产品还有哪些场景真正面向金融行业？下面给你们列举几个典型场景。

1）异常场景的恢复&全局一致性数据分析

第一种是异常场景的恢复和全局一致性数据分析，这个场景的功能和模型是差很少的，只是应用场景不同。举个简单的例子，到年终结算的时候我须要2020年凌晨零点整的整年所有数据的一致性快照，能够有两种方式，第一种是生成一个新的实例，第二种是生成一个新的快照。这里会存在一个问题，由于分布式状况下服务器的系统时钟不必定一致，因此如图中上者须要进行分布式的补查，下者须要一个GTS绝对时间戳来保证数据的准确。

2）分布式事务实时强一致

第二种是分布式事务实时强一致的能力，举个例子，假设我有五张银行卡，由于我要还房贷因此钱从这些卡之间转来转去。这时我媳妇正好在我转帐时来查帐，就会有两种结果：第一，我媳妇过十分钟后来查帐，她查询到的就是我转帐后的余额状况，这种叫最终一致性；第二，我媳妇在我转帐过程当中就来查帐，这时就叫实时一致性。实时一致性就是要保证在交易过程当中，即时随时查帐都能获得最准确的结果，这也是咱们数据库当前可以支持的一种能力。

3）渠道类业务冷热数据不均

第三种是渠道类业务冷热数据不均，针对金融行业由于有大量的渠道业务，会出现严重的冷热不均衡。以微信支付为例，京东是咱们最大的渠道之一，它一家的体量顶得上街边小的收银渠道几千家的体量，这就会遇到一个问题，个人大商户和小商户怎么分布才能使得整个资源利用率是最佳的，因此咱们提出了冷热数据均衡的能力。我能够把一堆小商户放到专门小商户group里面，大商户放在大商户的group里面。

4）复杂SQL处理（跑批等）

第四种是复杂SQL处理（跑批等），在金融行业里有时使用开源的分布式数据库一遇到跑批就死掉，这是很正常的现象，由于数据量大了之后计算节点没法承载。因此咱们提出了基于CPU的策略优化方案，简单来讲相似于并行计算，把计算层的节点、计算层要作的事情往下推，推到数据层来作，本来须要在计算层几百个G的数据，下推后须要计算层处理的数据可能就只有几个G。由于经过计算层和计算层之间，数据能够作到打通和交流，这样就极大的提升了批处理的效率。

5）分布式弹性

第五种是分布式弹性，也是金融行业会遇到的比较典型的场景。上图是美国今年熔断，富途证券的峰值达到50亿次。因此分布式的扩展性能帮助咱们在面对这种比较极端的、没法预料的状况下，整套性能可以很快速的扩展到所须要的目标。

3、总结

4、Q & A

Q1：我了解如今国内作分布式改造无外乎是三种方式，一种是腾讯这种直接改造传统的结构化数据库，腾讯这两个产品都应该是这种模式吧？还有一种是增长一层分布式中间件，国内也有厂商作；第三种是基于谷歌Spanner论文作的产品。请问您怎么看这三种方案的优缺点？

苏强：您说的这种方式就是刚才我提到的如今多种业务架构并存，腾讯的方式准确来讲也不是基于中间件简单改的，它其实是把三种技术能力进行了融合。针对您所说的三种方式，如今确实各有优缺点。

首先基于谷歌Spanner的方式，它的优势是想象空间比较大，因此很容易实现行列混合存储能力。缺点是它的计算层层比较重，因此它的最大可扩展性和最大的理论性能是有限制的；另外由于该技术是新发展技术，因此大规模应用于称金融行业可能还须要一些时间。

而后基于中间件的方式，优势是性能特别好，缺点就是业务系统要配合，并且对于语法的兼容性相对来讲比较差，不太适合金融行业。

腾讯是属于偏二者中间模型，既吸取了NewSQL的能力，又支持像分布式中间件的可靠性能。它的特色是性能、语法兼容性相对来讲比较高、底层存储当前虽然是结构化存储，由于咱们把计算层往上提了，提了之后下面存储究竟是用MySQL、用PG，仍是用NewSQL的KV存储？对咱们来讲设计就比较灵活，因此咱们内部三种形态都有使用。目前由于是面向金融行业，主要仍是商用的最成熟，因此主要仍是推咱们本身最成熟的TDSQL和TBase那一套方案。将来咱们内部也有新的方案也在打磨，咱们也会发布新的产品能力出来。

Q2：企业里使用TDSQL的话，您是建议部署在物理机上仍是腾讯私有云平台上？

苏强：由于数据库自己是一个软件，理论上来讲是能够部署在物理机和虚拟机上的。但由于生产环境目前虚拟机对数据库所须要的高IO，下面IO优化作得效果不太明显，因此咱们目前的建议是部署在物理机上。若是是一些测试环境或非核心环境也是能够部署在虚拟机上的。

为了帮助你们部署在物理机上，方便管理以及进行资源的有效分配，咱们全部数据库部署在物理机上都会有一套本身的虚拟化模型，也就是说您能够在物理机上抽象出相似云的多租户的实例模型出来，能够给多个业务单位或者我的使用。

本文由博客一文多发平台 OpenWrite 发布！