腾讯云 TDSQL：真正面向金融行业的典型场景

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 优化做得效果不太明显，所以我们目前的建议是部署在物理机上。如果是一些测试环境或非核心环境也是可以部署在虚拟机上的。

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