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

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

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

一、金融行业现状

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

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

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

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

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

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

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

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

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

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

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

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

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

二、金融应用实践

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

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

如何选择分布式技术栈；

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

如何使用分布式数据库；

新老系统的切换；

分布式的扩展容灾方案；

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

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

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

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

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

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

所以说这两个技术栈方向都各有优势，腾讯云因为金融业务足够大所以覆盖了这两个方向的产品，都有自己的产品线，我们现在都把它叫做分布式数据库产品线，分别是 MySQL 技术栈的以及 Postgre 技术栈的产品。

2、技术创新节奏

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

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

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

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

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

技术复用：该技术应该是可以复用或容易建立的；

全量切换：应该是在完全磨合好以后，再全量切换。

并且分成四种节奏开展落地：

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

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

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

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

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

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

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

1）水平拆分 &垂直拆分

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

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

2）水平拆分的主要方案

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

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

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

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

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

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

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

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

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

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

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

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

7、典型场景

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

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

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

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

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

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

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

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

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

5）分布式弹性

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

三、总结

四、Q & A

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

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

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

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

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

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

苏强：因为数据库本身是一个软件，理论上来说是可以部署在物理机和虚拟机上的。但因为生产环境目前虚拟机对数据库所需要的高 IO，下面 IO 优化做得效果不太明显，所以我们目前的建议是部署在物理机上。如果是一些测试环境或非核心环境也是可以部署在虚拟机上的。

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