「腾讯云数据库」火速拿下2000家金融客户，背后的技术方法论

近年来，金融行业数据泄漏事故频发，远高于其他行业。

通过永安在线数据资产泄露风险监测平台统计，金融行业是数据资产泄露的主要来源，占到了42%，而数据资产泄露高发的互联网行业也只排名第二，占27%。出现这种情况是因为金融行业涉及到的人群大多是高净值人群，数据转化率高，变现能力强。

腾讯云数据库TDSQL首席架构师张文认为：“虽然企业数据安全不只依靠数据库，但数据库一定要做这种最后一根救命稻草的保障。”

张文还介绍到，“数据的误删、误操作，对于一些银行客户而言，可能一年或者几个月都不会发生一次，但是，我们面对着云上的客户，每天都有客户误删、误操作，在这方面TDSQL积累、总结了大量的经验、教训。对此，我们也有很多的解决方案包括SQL防火墙、透明加密、自动备份等——如何更快速的帮助用户找回数据、恢复其可用性，经过这么多年的打磨，我认为我们是非常专业的。”

恰逢新年，雷锋网《AI金融评论》邀请到张文参加「银行业AI生态云峰会」，他分享了腾讯云是如何在「银行数据库」这一领域深耕发展；如何在国外商用数据库的“压力”下，突破求生，拿下多个银行核心系统大单。

目前「银行业AI生态云峰会」已成功举办4场，微众银行区块链安全科学家严强、达观数据联合创始人纪传俊、腾讯云数据库TDSQL首席架构师张文、阿里云金融科技AI产品负责人王巍给观众带来了十分精彩的演讲，后续还将有360数科首席科学家张家兴、融慧金科董事长兼CEO王劲、华为云FusionInsight首席架构师徐礼峰、摸象科技董事长高鹏等众多大咖前来分享最新、最有货的科技观点。

以下为张文的演讲内容，雷锋网AI金融评论作了不改变原意的编辑：

大家晚上好，很高兴能在雷锋网 (公众号：雷锋网) 这个平台带来关于分布式数据库的分享，今天主要的议题是《腾讯云分布式数据库在银行核心系统的改造实践》。

众所周知，2020年12月24日，腾讯云数据库官宣TDSQL品牌整合升级计划，集中发力数据库技术创新突破。腾讯云原有的TDSQL、TBase、CynosDB三大产品线统一升级为“腾讯云企业级分布式数据库TDSQL”。全新升级后的腾讯云TDSQL将 涵盖金融级分布式、分析型、云原生等多引擎融合的完整数据库产品体系。 本次分享将主要以金融级分布式版TDSQL的实践进行介绍，下述以“TDSQL”为简称。

基础技术创新背景与当前行业趋势分析

银行的“核心系统”，对于数据库厂商而言是一个比较大的挑战。

银行，我们都知道有核心系统和外围系统，核心系统是银行心脏中的心脏。

银行的核心系统改造，对于数据库厂商而言是一个很大的考验。数据库厂商需要面对包括数据的一致性、高可用，以及SQL的兼容性等等一系列复杂问题。

信息技术创新的大势所趋

过去我们的核心系统，包括银行核心，还有一些政务核心系统，对外国厂商的依赖度超过了90%，包括软、硬件，硬件主要是依赖于国外的大型机，小型机。

软件方面，像操作系统和数据库软件，整个一套技术架构都采用的是国外的产品。直到现在，在技术自主创新大趋势浪潮下，从硬件到软件，我们逐步在进行国产化的探索。

硬件上，我们开始尝试用基于X86或者是ARM的国产化硬件，以构成底层的硬件平台；软件上，从操作系统到数据库，包括一些中间件，在国产化方面近几年涌现出了很多基础类软件。

所以，现在整体的技术导向是：从软件到硬件整个基础平台开始向国产化的态势发展，而不仅仅局限于数据库。

金融级分布式数据库的挑战与难点

分布式数据库的挑战（技术层面）

对于分布式数据库而言，如何迎合这样的契机和挑战？

为什么早期国外的商用数据库和商用的基础软件，在国内的银行、政务系统占据了大量份额？大部分企业选择这些基础软件，主要诉求是其稳定性。以稳定性为口碑，经过多年打磨，因而国外厂商的这些软件占据了垄断性的地位。

这种垄断性地位在短时间内是不容易被打破的，因为它有个长时间的市场效应， 对于使用国外软件的这些厂商而言，一旦涉及到替换或者升级，就容易产生一些兼容性问题，还有一些迁移成本和改造难度等问题 。

对于国产的分布式数据库，如果想要切入政务及银行系统，首先需要打破长期被国外商用数据库建立起来的一系列壁垒，这些壁垒对于国产物数据库是一系列的挑战点。

强一致性高可用

作为金融级数据库，可用性和数据强一致性是至关重要的，因为在金融场景下，一条数据的价值是无法估量的，没法评估它到底是错了一分钱还是一个亿，或者更多，所以金融级高可用是国产分布式数据库首要面对的一个挑战。

性能成本

在国产化方面主要基于廉价存储，因为在分布式的架构下，可以实现线性水平扩展。但是数量对于分布式数据库而言，并不是一昧的堆机器、堆存储、堆计算，那样实际上是很浪费资源的。分布式数据库组成一个较大的集群，假如有上千台机器，那么如果在性能方面提高20%，就能节省上百台的机器，甚至能节省出来一个机房。

所以，性能成本也是分布数据库一直在探索的以较低的成本获取较高的性能，这也是我们追求的一个性价比。

水平伸缩

对于分布式数据库，水平伸缩能力是必须要具备的，因为分布式数据库在互联网场景算是需要比较常态化的水平伸缩。

例如应对如双11购物节、春晚红包的突增流量，需要有一个迅速的弹性扩展能力以承载这些流量。而业务有峰值就有谷值，活动结束后，需要再将这些资源进行回收。这种水平伸缩能力，是分布式数据库应当具备的基本点，任何分布式数据库都需要具备这种可伸缩、可拓展的能力。

产品化程度

产品化程度是用户能否快速上手的关键。

比如从一个传统的集中式数据库转换到分布式数据库，尤其是对于一些政企类、金融客户而言，他们能否从传统观念或者传统数据库的环境下，过渡到分布式数据库的环境和条件，这类客户其网络往往跟外网是隔离的，也就是在用户出了问题之后，我们没法第一时间登录他的环境，帮助其进行调试，就需要他自助的完成。

如果没有比较成熟且产品化的一套解决方案，用户出了问题只能7x24小时找到厂商解决，非常低效。所以，产品化程度也是至关重要的。

早期那些国外的商务数据库也是历经多年打磨，才慢慢的让这些传统厂商的数据库团队、科技团队接受的。

关键案例

前面几点做得再好、再花哨，如果是没有关键案例的验证，一切都是竹篮打水一场空，“实践是检验真理的唯一标准”，做得再好都需要有案例加以证明其可行性，对于分布式数据库的挑战，最重要的一点也是最为关键的一点，就是实实在在的案例。

如果没有人用，大家都处于观望状态。关键案例是分布式数据库面临的最大挑战，目前来看，国内的传统厂商、银行、政企，还是外企的份额居多，国内的分布式数据库也是在近几年才杀出一条血路。

所以，关键案例方面，除了需要TDSQL，也需要所有的友商共同探索，将关键案例不断的迭代、铺开，有了更多案例的证明，国产分布式数据库的影响力也好，口碑也罢，包括大家的接受程度，才能慢慢地得到提高。

分布式数据库的挑战（非技术层面）

这里的非技术层次的挑战更偏向于产品侧，主要分为以下4个挑战：

质量可靠

对于一款分布式数据库，需要经过大量业务的验证，产品在成熟或者说正式用于外部之前，一定需要经过内部的打磨和锤炼，像TDSQL数据库，我们往往都是在内部打磨得非常成熟后才将其推向外部。

因为我们的内部场景非常多，腾讯也有很多业务线，例如在类金融场景、社交场景、医疗健康、互动娱乐，以及各种各样的公有云的场景加以打磨。

我们秉承着对自己产品认真、负责的态度，先经过内部的打磨才推送到外部客户。因为将产品推送到外部客户时，实际上已经是一个黑盒的环境，要求我们一定要在内部尽可能的提前发现一些比较关键和显而易见的问题，比如用户的体验性和一些使用方面的问题。

持续投入

数据库的更新迭代非常快，从TB级PB级再到更高数量级的提升。

因为迭代更新比较快，所以要求厂商要有一个稳定的数据库团队持续地跟进演进。

对于TDSQL而言，作为腾讯内部唯一的自研数据库品牌，我们团队也要紧跟技术的演进和变化，除了服务外部客户还要服务内部，因为无论是内部还是外部都是我们的关键的客户，都是我们非常重视的使用场景。

像腾讯这种体量的互联网公司，需要一支比较稳定，并且可以不断紧跟着技术的演进和发展不断迭代的数据库团队。

团队建设

需要我们的数据库有自己的生态，包括用户从集中式转换到分布式的配套工具，周边文档资料，人员的招聘，还有一些过渡保障措施。

TDSQL是兼容MySQL、PostgreSQL生态的，而这些生态是一个非常庞大的数据库圈子，其文档和资料，以及全世界的活跃社区都给我们提供了很多的学习参考的途经，我们一些技术水平比较高的银行合作伙伴往往在出了问题之后，对于一些比较基本的问题，都是自己通过查阅相关资料加以解决。

对于我们的客户而言，选用了一款分布式数据库，它也要考虑自己团队对新型分布式数据库的维护能力。

服务能力

服务能力要求分布式数据库的具有完善的服务机制与生态体系。比如用户出了问题之后，能够第一时间真的需要到现场，能够第一时间去就近服务，包括一个完善的区域的合作伙伴的服务机制。

在服务能力方面，TDSQL也在全国培养了很多的技术支持团队帮助，引导客户解决问题。比如一些重大的节日保障，或者是涉及到一些重大变更，需要我们的合作伙伴立刻到达现场，做业务的割接、切换或者是大规模的灾备演练。比如对一个机房进行断电的容灾演练，我们也有专门的团队去支持，DBA团队也有服务合作伙伴，共同为客户保驾护航。

目前，我们在华东、华南、华北都有专门的服务团队。

作为一款成熟的分布式数据库产品，除了要在技术侧加以打磨，还需要有足够的案例输出，同时在服务体系、整合能力还有持续演进能力方面，都要有与之相匹配的能力。否则，它就没有办法成为一个成熟完善的商业化产品。

TDSQL的发展历程以及架构原理

腾讯的土壤

为什么在腾讯的土壤下能诞生出像TDSQL这样的数据库？

首先，腾讯是一个依托百亿级账户数量的互联网公司，其数据规模、场景相对而言比较有挑战性。

例如，几年前微信春节红包的峰值超过了每秒20万笔，对于任何数据库而言都是一个比较大的考验， 如果不按照分布式进行拆分，那么，没有任何一个大机或者小机能承载这样的业务压力。

众所周知，互联网业务营销活动比较多，在活动前、活动后，其请求还有峰值都是指数级的数量，对数据库的容量、伸缩能力是一个很大的考验。

TDSQL，依托腾讯云这个载体，服务于政务、金融、电商、社交，还有智慧城市等等各种场景的打磨。另外，TDSQL在公有云上服务于各行各业和各种场景的用户，这些都是对TDSQL各种场景的打磨。

最后就是持续的投入。

伴随着TDSQL迭代的这10年，腾讯加以持续的投入，不断的打磨产品。因为数据库对于这种体量的互联网公司而言至关重要。腾讯有着百亿的账户，丰富的内部产品线和业务线，任何一个这种互联网业务产品都会对数据库有着强依赖。在数据库方面，TDSQL不仅是作为外部的一个产品，在内部也是承担了一个比较重要的作用。

在这里，详细的介绍一下到底什么是TDSQL，其应对的主要场景有哪些？

按照官方最新解读，TDSQL是腾讯推出的一款多引擎融合分布式数据库品牌。

所以TDSQL覆盖三类数据库场景，分别是：分布式数据库，云原生数据库以及分析型数据库。所以，TDSQL分为三个产品序列，分别是金融级分布式TDSQL、云原生共享存储的TDSQL-C以及分析型数据库的 TDSQL-A。

这样的多引擎超融合体系针对数据库场景的几个关键领域，都提供了特定场景的解决方案，比如云原生数据库，在存储层基于共享存储做分布式的就是TDSQL-C。

在面对金融场景或者政务系统的联机交易和离线跑批场景，分别是分布式TDSQL和分析型TDSQL-A的两个产品。实际上，TDSQL是腾讯整个一套分布式数据库的解决方案，无论是在线联机型的，还是离线分析型的，或者是基于共享存储的分布式型场景，它都可以轻松应对。

核心特性

金融级分布式版TDSQL的核心特性包括以下几点：

首先，数据强一致，因为在金融场景下，数据不丢不错是至关重要的。

第二，金融级高可用，在金融场景至少要保证99.999%的可用性，因为金融除了其本身的行业因素外，更重要的是它还受到监管的约束。 无论是对内还是对外服务，TDSQL是按照99.9999%的可用性要求的。 高性能低成本，作为分布式数据库，尽可能要让所有的X86、ARM的廉价存储方式榨干机器的资源，带给整个分布式数据库高吞吐量的增益效果。

再者，企业级安全，虽然需要实现企业级安全的不只是数据库，但数据库一定要做这种最后一根救命稻草的保障。比如数据的误删、误操作，对于一些银行客户而言，可能一年或者几个月都不会发生一次，但是，我们面对着云上的客户，每天都有客户误删、误操作，在这方面TDSQL积累、总结了大量的经验、教训。对此，我们也有很多的解决方案包括SQL防火墙、透明加密、自动备份等——如何更快速的帮助用户找回数据、恢复其可用性，经过这么多年的打磨，我认为我们是非常专业的。

线性水平扩展能力：分布式数据库一定要具备伸缩、可扩展能力。

最后，便捷的运维——这套分布式数据库交付到客户手里，用户要能够自行掌控、操作。而不是出了问题后，只能7×24小时的给厂商打电话，这也不是我们的初衷和诉求。

产品体系

最底层的是资源池。

TDSQL既可以基于物理机部署，也可以基于虚拟机，我们可以将这个资源池简单理解成一个iaas 服务层的概念，在资源池上方提供了两种形态的存储节点，一种是Noshard数据库，另外一种是分布式数据库，分别代表了单机版和分布式两种形态。

作为分布式TDSQL，为什么还要有一种形态是单机版的？

对于一个厂商、一个银行或者一个金融客户而言，并非所有业务都会用到分布式数据库，或者不一定所有的都是业务大表，它可能是多个业务之间有交叉，真正涉及到分布式的可能是一部分表，还有一部分可能是非分布式的。

在这种产品形态下，同时兼容分布式和非分布式，因为分布式下有一些使用限制，比如语法的限制、分布式事务的性能损耗，以及跨数据节点的join.

在分布式下，因为两个数据节点是一定分布在两个不同的物理节点上的，如果在这两个物理节点之间的数据做join，很容易造成拉表，相当于是把两个物理节点上的数据要统一汇总到一个节点上进行join，这样的效率不是很高。

而单机版的则没有这个问题，因为数据的拖拽都是在单台物理节点的内存中，所以，Noshard的形态可以自由做表与表之间的join，但是在分布式上会有性能方面的消耗，这也说明了分布式和非分布式两者各有优缺点。

所以，我们在存储节点保留了两种形态，用户可以根据需要自行选择，比如业务实例要求必须得做到分布式，需要将数据分散，包括将来考虑到业务的拆分，我们就要用分布式的；如果没有强烈的诉求，我们提供单机版的就能满足需求。此外，从单机模式转换成分布式模式，TDSQL自带的同步迁移工具也是支持的。

再往上是计算节点。

首先，OLTP型引擎主要包括了读写分离、SQL改写、分布式事务以及关联查询。

除此之外，对于计算节点，需要处理一些比较复杂的SQL，需要对其进行拆分，包括将执行计划下推等等，就属于OLAP型的计算逻辑。

所以，计算节点在分布式下的工作相对还是比较复杂的，在内部，计算节点又被称为SQL引擎，作为所有SQL的入口，它会对SQL进行分发，对一些复杂SQL拆解成对应的SQL，再发到对应的存储节点，当存储节点取完数据之后再回吐到计算节点，计算节点对其进行分类汇总，最后回吐到客户端。

如果把计算节点、存储节点、资源池比作一个黑盒，那么赤兔运营管理平台就是一个用户接口，所有的DBA操作都是通过赤兔管理平台来操纵存储节点、计算节点、资源池。

以往，DBA要做数据库的变更，比如主备切换或者重启，需要登录到后台，比如计算节点，存储节点执行SQL命令，现在只要通过赤兔管理平台页面按钮可以完成90%以上的操作，极大地减少了DBA的误操作风险。

虽然有用户界面，但是如果DBA确实是要登录到后台了解更详细的信息也没有问题，一样允许登录到对应节点的后台进行查看。

赤兔运营管理平台主要是为DBA提供用户接口，它还对计算节点、存储节点，包括机器IO、CPU网络等各种信息的上百项指标进行统计汇总，并且当监控告警系统的指标出现异常时，可以在第一时间发出告警。

那么，“扁鹊”智能DBA平台有什么作用？

打个比方，某天晚上发生了机房断电，数据库也发生了切换，第二天早上DBA收到一个告警，线上前一天晚上发生了切换（当然这个业务是正常切换过来了，然后对业务的影响也是可控的），DBA需要知道为什么会发生切换，只需要在智能DBA平台上点一下“故障分析”，智能DBA自动到机器上分析操作系统和数据库日志，原来是操作系统发生了重启，这样 DBA就不需要再手动登录到机器上查看信息。

再比如上线了一个新业务，上线了新业务之后瞬间卡死不可用。这时就找到DBA投诉，“之前数据库用得好好的，怎么一上新业务就不行了？”

实际上，可能是新上线的业务产生了一条慢SQL，慢SQL并发量又比较大，然后把数据库连接耗尽。按照传统的做法，这时DBA也是先分析日志，找到这条慢SQL，然后再一点点的进行分析。

而通过智能DBA平台，可以进行一键诊断，智能DBA平台可自动筛选出那条慢SQL，并且告诉DBA需要对这条慢SQL如何进行优化。

有了智能DBA平台，就可以将我们从一些日常的、重复性的繁杂工作中解放出来，这套平台也是我们对外口碑最好的一套平台，尤其对于传统客户而言是非常受用的，能极大地提高DBA的工作效率，同时降低处理问题时在时间上的损失。

调度系统，负责整个集群的资源调度和管理，包括计算节点 ，如何组成一套数据库实例，跟下方资源池里的资源如何进行重组、搭配，都是调度系统需要做的事情。

备份系统，没有备份的数据库属于一个裸奔状态，在这方面，TDSQL提供了丰富的备份策略，如全量的、增量的、物理的、逻辑的、日志的等各种各样的策略。可以完成定点恢复、库表结构恢复、指定表的恢复等等。

服务模块，服务模块属于比较高级功能，主要应对一些特殊性场景，如：审计、数据订阅、数据治理，以及SQL防火墙，数据迁移等等。

比如用户需要从原生的MySQL迁移到TDSQL，或者从其它异构数据库把TDSQL迁移到其中，都涉及到数据迁移，我们有专门的数据迁移模块，包括TDSQL的两种形态之间，包括从分布式到单机版，从单机版到分布式，都依赖于这样的数据迁移。

数据迁移也彰显了TDSQL不绑架用户的一个初衷，这也是TDSQL开放生态的一个特点，基于MySQL生态的数据库在迁移过来之后一定不用担心将你绑架——也就是它不让你迁出去，因为日志、数据结构都是开源的，有很多种工具提供了在线、离线的迁移方式。

如果用户觉得TDSQL不好用，可以通过我们的迁移工具再将数据迁走，数据进出自由，并非绑死在TDSQL。

运营管理

• 赤兔监控：这里罗列的几项指标，是SQL引擎请求量的对比，包括与前一日的对比曲线。

• 智能告警：如果报警标红就会闪烁，如果只有监控而没有告警，其实是起不到任何作用的，一定要将监控与告警关联，才能起到预警作用。

• 扁鹊系统：其内部逻辑非常复杂，主要是基于腾讯多年来海量运维的经验，形成的策略库、语法库。通过在这方面经验的积累，对一些常见的故障进行分析和识别并处理。

• 一键运维：TDSQL赤兔管理台的首页，它包含的功能在我们看来如果DBA数据库管理员有这套东西，基本上是可以做到只在页面上完成所有的操作，不需要登录到后台进行变更、维护。

系统数据库向国产分布式数据库迁移与转型实践

第一个案例：微众银行

微众银行是在2014年开始筹建，最终采用了TDSQL，并搭建分布式架构核心系统。微众银行对于机房的部署是，在同城有5个机房异地有2个机房，按照传统意义上的理解，这同城的5个机房如果做成1主4备，其余4个机房都有可能会浪费。因为只有1个机房没有读写请求。

微众银行对上述机房的部署肯定没法充分利用机房的资源。对此，又是怎么解决的呢？

首先，将数据库规划成一个个的 DCN，一个DCN模型就是一个小的微众银行的分行、网络分行，一个分行只固定500万的账户数，这500万的客户数也是经过了一系列的压测验证，至少这500万放在这个单机版的TDSQL上是安全的，不会有性能的瓶颈。

如果超过500万，比如客户数到了600万，就再加一个DCN，实际数据库的实例层是由多个DCN组成了一套集群，而多个DCN之间相互没有联系，因为用的都是单机版的TDSQL。

那么，微众银行是如何利用这种单机版的Noshard模式实现整体的分布式呢？

微众银行还引入了一个组件GNS， GNS被称作全局路由，业务访问数据库一定要经过GNS，之后，GNS告诉他所需要的数据在DCN的具体位置，业务再把对应的SQL发到对应的DCN。

所以，GNS解决了路由的问题。

在这种情况下，如果要做分布式事务该怎么办？传统的分布式数据库，对于用户侧而言就是一个begin，然后增删、改查、commit。

如果增删、改、查里涉及到的多个DCN对业务是透明的，但是在这种情况下，实际上没法做到完全的透明。

对此，微众银行又引入了一个组件RMB——可靠的消息队列，是处理分布式事务的，也就是在一笔分布式事务到达后，首先要在RMB这里注册一个分布式事务的总事务，之后再由RMB完成子事务的分发，最后它会确保所有的分布式事务所涉及到的 DCN在处理完成后，返回给业务端。

微众的数据库是怎么部署的呢？利用多个IDC交叉部署，第一个DCN的主放在IDC1，第二个DCN的主放在IDC2，以此类推，其所有DCN的主是交叉部署在这5个机房的。

如果最后是500个DCN，有5个机房，每个机房就放100个DCN，这样的好处在于每个机房的读写流量是均匀的，并不会造成像原来所有的读写都压在1个机房，其余4个机房都是stand by的角色。

所以，微众银行这套架构从整体上看，实现了5个机房资源的充分利用。

任何一个机房的故障都只会影响1/5的流量，不会造成系统性的宕机。

像以前这种1主4备的模式，如果主节点坏掉，整个全行所有的服务都会瘫痪，虽然最后也会切换，但是其过程对全行的业务是有影响的。

如果按照分散的方式，就会产生另外一个问题，一个节点坏掉之后，使得1/5的业务受到影响，而原来的1主4备的模式，如果坏掉的是一个备机，那正常业务就不会受到影响。所以，这其中存在着可用性和成本之间的博弈。

第二个案例：张家港银行

张家港银行是我们对传统银行核心系统进行的一次彻头彻尾地改造。

首先，它是一家传统银行，并非新成立。其次，它的核心系统是针对传统银行打造的。从微众银行到张家港银行已经过去大概5年的时间，整个TDSQL在产品迭代方面已经有了很大的变化。

对于张家港银行而言，首要考虑的问题是性能，其早期的数据库是Sybase数据库，大概是10年前的一个架构。在张家港银行在业务高峰期经常有卡顿、超时的问题，所以其诉求就是要升级成一个能满足行里现在业务场景的数据库。

第二，张家港银行的量级相对较小，其诉求就是成本。

另外，改造的难度，在业务方面，微众银行在数据库方面做了很多的自身的改造。

比如引入了GNS、RMB，这些都是微众自己进行维护的。并且从一开始，微众银行基于自身的定位，更多地还是想参与金融创新，定位自身为一家金融科技公司。而张家港银行更希望能快速地解决自身的问题并且把东西用起来。

所以，张家港银行的架构图就非常清晰和简单，就是一个标准的分布式两地三中心的架构，同城总行机房部署一组主节点和一组备机节点，同城的灾备机房部署一组备节点，整个分布式实例采用一主三备四分片的架构。

此外，在异地还有一组异步节点。从整体看，没有任何的复杂组件，张家港银行采用的这种形态与微众银行的截然不同。

TDSQL有两种形态——Noshard和shard，张家港银行完全采用了后者的形态，这样，张家港银行就不需要引入诸如GNS、RMB等组件,因为我们的SQL引擎会助其自动做路由，以及分布式事务管理。

所以，张家港银行直接使用分布式shard版的TDSQL，对于业务而言，只需进行细微的调整和改动，例如重新设计库表。按照这种分片关键字，一些大表需要选择其分片关键字。

再者，就是将之前用到的存储过程、触发器的一些计算逻辑，尽可能地上提到业务代码中。因为在分布式数据库下，数据库尽可能的只做数据的存取，否则很容易产生性能问题。

按照这种策略和思路，对张家港银行的改造大概历时半年完成，改造完之后，整个性能提升非常明显，查询交易在100毫秒以内完成，高频交易在300毫秒内完成，像贷款结息这种跑批业务与原来相比得到成倍的提升，体现出分布式的一个优势。

性能方面，原来在硬件成本方面需要4~5000万，现在不足1000万。同样的成本，在oracle下是8000的TPS而在TDSQL下是6200的TPS。

在整体性能差异不大的情况下，成本已下降到了不足原来的1/5。同时TDSQL可以通过继续加机器来提高集群的吞吐能力，所以性能还可以不断地提升，具备横向扩展的能力。

第三个案例：平安银行

平安银行更具代表性。平安银行的体量与张家港银行相比又上升了一个数量级，同时其应用改造的难度相对而言也是一个比较有挑战性的工作。今年，我们完成了支持平安银行信用卡核心从传统集中式架构的大型机下移至分布式平台。

平安银行采用了TDSQL Noshard和Groupshard两种架构。为了配合此次改造，应用引入了微服务架构对应用进行了拆分和解耦。对账号的分布进行了单元化划分，以DSU为一个逻辑单元，单个DSU包含200万个客户信息，单个DSU同时处理联机和账务两种业务。这样做的好处：一方面避免跑批时段消耗资源过多对联机交易的，另外一方面避免由于基础架构的故障导致全局不可用。。

平安银行也有统计分析类型的业务，如果按照Noshard架构，对应用开发要求比较高，需要将统计类的SQL拆分成多个子SQL分发给多个noshard实例。

groupshard架构更适合， 从逻辑上来看，Groupshard架构对于应用而言就是多个独立的逻辑表，应用不需要关心数据是如何组织分布的。由于要对数据进行统计分析，数据访问量较大。所以，这种场景下，在访问需要的数据时，应用只需把SQL发给SQL引擎，SQL引擎会对SQL进行拆分、并行下推,再进行结果集的聚合。

同时，TDSQL Noshard和Groupshard两套集群之间通过TDSQL自带的同步组件完成实时数据同步。

政务系统

第七次全国人口普查的数据采集处理工作，对于我们的TDSQL而言也是具有重要意义的。

首先，其数据量的规模是10亿级别的，峰值QPS是百万级。

这种情况，无论在我们内部业务还是外部业务都是非常罕见的，对于TDSQL性能的要求，包括跨节点之间的通信、分布式事务的处理都是比较大的挑战。

因为人口普查涉及到国家政务的敏感信息，我们不便将其详细的架构图画出来。

但可以肯定的是，基于TDSQL多引擎融合技术，第七次全国人口普查稳健完成了数据采集处理工作。

欲了解更多活动详情，可联系负责人周舟（微信：18811172358）。

。