分布式数据库在金融核心场景的落地实践

金融行业作为国民经济的命脉和枢纽，对底层数据库的能力要求在不断提高。具有高性能、可扩展、高可用等特性的分布式数据库是金融行业数字化转型的重要支撑。作为金融企业或金融行业从业者，如何在不同的应用场景下，做好分布式数据库的选型和落地？本文从业务、技术、行业角度出发，从市场发展到落地实践，全方位全流程为您剖析分布式数据库在金融场景中的应用与实践。本文将会为您解答以下具体问题：

• 如何在品目繁多的市场中选择一款合适的数据库？

• 从哪些维度去考察数据库？

• 数据库迁移过程中需要注意哪些要点呢？

• 有无实际的案例可供参考呢？

《金融业数据库选型之路》

韩锋，中国计算机协会常务理事，前 Oracle ACE

数据库市场会如何发展，在金融领域首先要看政策与监管，《金融科技（FinTech）发展规划（2019-2021）》中明确指出要加强分布式数据库的研发应用。做好分布式数据库金融应用的长期规划，加大研发与应用投入力度。韩锋认为，当前分布式数据库研发应用的成效就是看金融企业内部是否能够平稳的推进分布式数据库的使用。

在我国，数据库市场起步较晚但发展势头强劲，基于国产数据库的金融科技转型已不再是难题。但是，品目繁多的数据库市场和复杂的数据库技术给金融企业带来了不小的困扰。如何选择一款合适的数据库？从哪些维度去考察数据库？有没有参考呢？

选型之前先要了解市场上有什么。基于多年深耕数据库市场的经验，韩锋为大家梳理了数据库行业及技术的背景，提炼出了目前行业和技术的三大特点，并指出了背后的三大痛点。

1. 碎片化严重

数字化浪潮下，企业的数据意识越来越强，数据在企业生产经营的应用广度和深度都在提升，由此也衍生出丰富的业务场景。

面对丰富的业务场景，市场上很难找到一款数据库去适配所有的场景。现在的普遍现象是企业在不同的场景下，需要对应不同的产品，来解决相应的问题。且不同的产品提供的技术路线又不尽相同，企业当然很迷茫。由此，在多场景、多形态、多技术栈、多元路线的影响下，整个数据库市场呈现出来的是一种碎片化状态。

痛点一：在数据库碎片化严重的背景下，企业如何在纷纭复杂的市场中，找到一款适合公司的数据库产品呢？

 2. 开源 or 商业

从近十年来的全球数据库流行趋势中我们不难发现，开源数据库的流行程度逐年上升，甚至在 2021 年已经超过了商业数据库。在国内，越来越多的国产数据库厂商纷纷走向开源。开源对国产数据库来说意义非凡，是实现弯道超车的最佳拐点。因为数据库作为基础软件，技术门槛相对较高，整体的架构设计也较为复杂。开源则能够大大降低数据库的使用门槛，使得越来越多的开发者能够参与到开源生态中去建设，无论是植根数据库内核技术上，还是打磨数据库应用场景方面，开源都能够加速国产数据库的普及与使用。

痛点二：对企业来说，开源和商业，到底怎么选？

从早期的架构选型，到中期的开发部署，再到后期的运营维护，开源数据库和商业数据库之间都有非常明显的差异，需要企业基于自身的业务特点、公司实力从各个维度去评估。

3. 厂商分化

据统计，数据库赛道上已有 200 多家厂商，并且还有越来越多的国内外厂商参与进行。国内的数据库市场中可以分成四大类数据库厂商，扎根数据库领域多年的传统厂商、深受资本关注的初创厂商、创新资源交付形态的云厂商、数据库上下游的跨界厂商。在国外，可以分为数据库老牌厂商以及活跃的开源厂商。

痛点三：在厂商分化，百花齐放的数据库市场中，企业该如何选择？

企业要对业务场景有明确的认识。数据库在金融行业的应用非常广泛，场景非常丰富，而分布式数据库往往需要有明确的适用场景。因此，选型的数据库产品是不是适用于这些场景呢？韩锋认为前提是企业要认识到自己的场景到底是什么。下图是金融业数据库使用场景的简单划分，主要包括业务、数据规模、一致性要求、负载特点、分析能力等方面。韩锋强调，客户在选型的时候，要明晰一款数据库是很难甚至是不可能适用于所有场景的。

更进一步地，韩锋提供了更多维度的考察点，如下图所示包括性能、扩展能力等多个具体的技术细节上。我们可以看到不同场景下的差异是非常明显的。韩锋以数据分片为例，从技术角度上为大家详细阐述了如何考察数据库的能力。

数据库是非常复杂的系统工程软件，在选型时要注意的细节其实还有很多。韩锋总结了几个观点，给企业的选型之旅提供方向。

第一，尊重路线之争，无关乎技术领先性。最好的数据库产品是适合企业业务的，而不一定是技术最先进的。选型一定要结合业务，不要寄希望于大一统的方案。

第二，成熟度有待完善，但时不我待提前规划。分布式数据库确实是一种新兴技术，成熟度有待完善。但企业在这个过程中不能“等靠要”，还是得参与进去，不断打磨，才能越用越好。

第三，国产数据库百花齐放。这一现状倒逼企业需要具备清晰的考察标准，严格考察市场现有产品，才能最终筛选出真正有实力。

第四，谨慎技术选型，不迷信厂商宣传。真正选型过程离不开测试，要想对产品有非常全面且准确的了解，需要在企业自己的环境中测试，这样的结果才更具有说服力。

第五，选产品选的是标准。很多企业担心厂商绑定问题，韩锋认为这个问题有一部份是兼容性带来的。因此，在选择产品的同时，我们要关注标准，尽量兼用某个通用协议的产品，相对自由度较大，便于后续更换数据库。

最后，保留技术敏感度，紧跟时代步伐。数据库技术迭代很快，金融企业客户要时刻关注技术发展，基于自身的业务进行思考是否升级。在具体措施上，可以选择架构前置、谨慎选型，局部试点、多线布局、掌握主动、自建增强等策略。

2《金融级分布式数据库探索架构》

贾瓅园，腾讯云数据库行业架构专家

分布式数据库是基于业务与技术的需求和发展以及监管要求下，解决当下以及未来趋势发展等问题，更优更稳定地满足金融银行业发展的选择。短期看虽有不足，用长远和发展的眼光看，对支撑金融需求、满足监管要求、提升自主可控能力、有效降低风险、合理控制系统建设成本等诸多方面都有助力和支撑作用，是金融银行业基础设施、基础软件建设的重点之一。

近年来，银行业在内外部金融环境的快速变化中持续进行转型和发展，从零售转型到互金 / 直销以及多渠道丰富金融产品的兴起，从追求业务多元化到追求场景化创新，基于持续不断的技术发展、业务创新积累下，再到金融数字化转型深入推进，这些对金融系统的技术架构有了更为严格的标准和要求以及诉求。面对此背景和发展的时代，我们首先要满足高可用及双中心级以上容灾，这是银行或金融业对技术架构最基本的要求，在此基础之上要满足交易高频高效、低延迟的金融场景处理要求，再衍生到高吞吐能力。在适配和实践中，需要按照银行系统的分类进行，每类系统特点对数据库要求和特性也不一样。

金融业务系统数据库的场景维度可简单划分成为两类，第一类是日间交易场景，聚焦到银行核心就是客户信息查询、存贷款业务、支付账务业务、代缴费批量处理场景等。这类场景的特点就是要求时效性和强一致性，所以必须满足高并发、高性能。第二类是日终批处理场景，例如计提结息、总分核对、会计科目记账、借贷平衡检查这类时效性要求低一点的业务。在批量提交 SQL 时并发量大，单位时间对单表的读写量大。这种情况首先要做分布式处理，然后进行分布式聚合处理、查询，最后按系统测算量和现有数据量的大小分批提交事务。

基于多年的行业架构经验，贾瓅园从金融数据库实施角度出发，重点介绍了工作评估中的几个重要维度供参考。在实际应用过程中，应结合自身业务特点来评估维度的优先级。并且，一定要进行测试，以测试结果为准作为最终的评估依据。

1. 批量业务场景需求评估。这一点关乎金融数据库的安全性和数据强一致性，从客户端来看，直接影响到用户体验以及银行间的清算工作。因此，要重点评估大批量数据操作时，对数据库的吞吐影响情况。

2. 数据有效迁移需求评估。在投产过程中，迁移的时效性也直接影响到体验以及银行业行间清算、投产相关的安全平稳度。

3. 未来 5 年数据库容量评估。数据库建设往往是系统工程，涉及到业务系统的匹配、硬件的匹配、网络匹配，甚至是团队的技术知识匹配，其投入成本巨大，不可能仅使用一两年就更换。

4. 高峰值 TPS/QPS 需求评估。基于我国的人口红利，在应用场景中不乏有大量用户使用，而金融系统应用以稳定性为先，因此并发压力特点下对数据库性能的要求非常高。

5. 高可用、容灾需求评估。两地三中心，吞吐量要求、IO 要求等都是重点考量点，业务属性较强的系统，需要与数据库高可用架构和容灾设计相配合，在保障高吞吐量的前提下，同时保持故障切换的灵活性与时效性，对业务影响较低且满足监管要求。

6. 备份需求评估。因为云化将是未来分布式数据库的发展方向，所以面对传统的网络环境、流量限定等也会有一定的要求。存储方面也从原来的集中式存储，变为分布式存储，这些变化不仅仅是每个单项的技术发展，还可能是综合影响。

7. 应用接入需求评估。什么系统可以直接适配？什么系统需要转化改造？这些需求评估在银行选型期间是考虑的重点。

此外，贾瓅园聚焦数据库语法维度，在六大使用场景中为开发者提供了适配优化方案。这六大使用场景包括了 SQL 语句、函数 / 关键词、设置 / 语法、索引、数据类型转换、分片 / 分区优化。

3《金融应用场景对分布式数据库的诉求》

孙亮，长亮科技高级技术总监，多年银行 IT 研发与实施经验

银行业是相对传统的金融行业，数字化转型过程中首先追求稳定，金融 IT 侧是趋于保守的。从银行业部署架构趋势来看，早期通常是将服务器集中部署在大型机上，为的就是稳定、高效、多并发。随着应用的发展，银行业的流行架构开始变成基于服务器来搭建不同的应用，Oracle 数据库开始席卷市场。后来，X86 服务器兴起引起应用架构开始发生变化，尽管这时候数据库市场还离不开 Oracle、DB2，但去 IOE 理念已经萌芽了。如今，在国产化浪潮下，自主可控的必然要求使得国产分布式数据库的流行。银行业需要将曾经部署在 Oracle、DB2 等数据库上的数据迁移至国产数据库上，这时候数据库迁移过程中的问题开始显现了。

基于公司多年的数据库迁移经验，孙亮以两个国产数据库对接案例为切入口向大家详细的阐述了迁移过程中的注意事项及优化项。总结来看，首先是分片键的配合，一定要带上 Shardkey。在数据量很大的情况下，能够保证精准分配；在报表规范、交易接口、数据传递过程中，要考虑到分片键如何向下传递。其次是 SQL 的优化特性，需要注意唯一性的要求。高唯一性的数据字段向前放，可以达到更好地索引命中的可能。接下来是数据库序列，每个数据库的序列都不相同，这导致在数据库迁移过程中需要重新对数据序列做分支方案，做归拢操作。现在的解决方案是先在技术平台上做独立的序列组件，通过序列组件去做整体的序列。最后，日终并发过程当中存在数据分布不均匀的情况，这也是对数据性能的影响，我们需要重点关注分片键是否设置得合理，是否可以达到数据平均化，或者把数据能够真正离散掉。

结合银行业的特点，孙亮为大家分享了几点在金融应用中常见诉求。金融行业的应用软件最高优先级关注点就是稳定性，孙亮认为很多不太优雅甚至是不太合理的基础转型，其实都是考虑到优先稳定性的要求。目前整个金融行业很关注的一点就是，迁移到国产数据库下，稳定性是如何保障的？同时容灾过程当中 RPO、RTO 真实的情况下能做到什么样的情况？包括同城、异地 RPO 也是重点关注的。虽然同城可以做到 RPO 为 0，但如果切到异地，RPO 不能为 0，容灾还是有一定的风险，金融行业是一定要考虑的。

在迁移过程中，我们关注迁移的难易程度，简单说就是 SQL 语法的兼容性。我们更期望于国产数据库这一侧，能够将这些语法尽量做到统一，减少上层大量的适配、改造。数据库的性能也是关注的重点，容量到底有多大？在金融行业或者在金融软件用户侧，我们认为数据库的容量其实更多指的是在指定表宽度下，单表最多能容纳多少条记录，才会产生性能拐点，这就是表容量。而不是一些国内外一些数据库宣传时提到的每个数据文件能够支撑多少 T 的数据。

另外以往缺陷率能否在现有版本当中进行修复也是需要重点关注的。如果大家都认为缺陷修复了，但由于分支的问题而被规避掉了，结果又被重新触发起来，这样得不偿失。因此这类问题需要国产数据库在内核构建中就得处理掉。

除此之外，基于公司的实施经验，孙亮还提出了在问题排查、运维部署以及术语对齐上的诉求。同时，对国产数据库提出了更高的要求，异地同步能否做到 RPO 为 0？多地多活是否可以在数据库层面实现？分布式事务是否能在数据库层面做到 XA 事务，让分布式事务变得和本地事物一样简单容易呢？

最后，孙亮基于行业经验及市场观察，对现有的三款分布式数据库类型进行了对比总结，其维度包括了一致性、性能（响应时间、并发能力、批量性能）、扩展性、生态、自主可控、高可用及部分形态（是否支持云原生部署等），可作为客户选型前的参考。

4《分布式数据库在金融场景下的实战》

作者｜王东，南云鹏

南云鹏，金谷农商银行运维科技部主任，拥有 15 年金融机构 IT 技术工作经历，主要擅长领域：系统运维、软件测试、配置管理、自动化发布、云计算等。

在互联网金融的大背景下，农商银行面临着多重挑战。具体表现在第三方金融、大型金融机构大幅占据市场；客户在服务体验上的要求不断提升；年轻客源流失严重；存款理财等负债资金成本越来越高；线下渠道使用率大幅降低等。

农商银行这类金融机构普遍承担着发展落实乡村振兴战略，推动普惠金融的落地重任，又是支持县域经济发展与服务三农的金融主力军。要想做好普惠金融的工作，金谷银行亟需借助金融科技力量来解决上述的难题，经过充分调研，立刻启动互联网金融平台的建设工作。

金谷银行表示当时的预期就是搭建一套需 IT 人员配置少、技术力量要求不高，稳定的、管理简单、高可用、高并发且易于扩展的基础架构。选型期间重点考虑四个方面：首先是大并发与高可用，在面向互联网的业务在技术架构上，一定要考虑 7*24 小时不间断业务与交易峰值的场景；其次是易于维护与管理，这与农商银行自身的特点高度相关。农商银行普遍存在 IT 基础薄弱，人力资源有限的问题，因此操作简单，学习成本比较低的平台更适合。第三，采用分布式存储。这是因为集中式存储成本高、管理难度大、技术要求也比较高。最后是技术选型的前瞻性和架构设计的合理性。

南云鹏自毕业后就一直在金融机构从事 IT 技术相关的工作，基于 15 年的工作经验，他整理分享了在传统数据库运维管理中存在的一些难题。

1. 传统架构下数据库版本和种类较多，人员学习成本高，掌握知识泛而不精。因为没有统一平台，甲方只能跟着乙方走，乙方提供什么甲方就被动地接受什么。

2. 烟囱式数据库，运维自动化程度较低，导致工作及时性差，维护成本高。运维人员在维护数据库的同时，还要维护操作系统，还要兼顾硬件环境等。

3. 日常运维的工作比较繁琐，所有的操作基本都是人工完成，包括用户、表空间等等。这些人工操作，存在很大的风险，因为出错率比较高，难以形成统一的标准。

4. 集中式的架构横向扩展能力较差，面对性能不足、容量不足、空间不足等场景，用户能做的只有增加 CPU、增加内存、增加存储或者换机器的方式。但这些解决方案都无法保证业务的连续性。

5. 集中架构下高可用性也难以保障，业务服务能力完全依赖于高性能的主机，一旦主机出现问题，解决方案将十分复杂，对开发人员的要求也比较高。

此外，在数据备份恢复归档管理、统一监控管理和运维标准上都存在着困难。这就导致运维工作杂乱、繁琐，基本上遇到一个事情是一套方法，或者一套临时性的方案应对。

在运维架构设计的过程中，金谷银行结合实际的业务需求制定了一套合理合适的运维架构，帮助规范日常工作，同时满足监管要求。

运维整体架构分成基础环境层、规范制度层、业务层、工具平台以及监控层。最底层的工作包括业务如何落地、运维架构如何搭建、如何开展相应的运维工作、如何减少系统的异常场景以及如何保证业务系统的连续性等。基础环境依托在腾讯云平台上，在这个基础上金谷银行制定了自己的规范与制度。

在规范制度层，金谷银行针对操作系统中间件、网络配置、数据库等日常基础的标准环境，制定了相应的机械性与规范性的文件。这样能够保证所有的业务系统，尽可能地在一个安全、规范的环境下开展运维的工作，也减少运维人员日常的管理难度。在容量管理、问题管理、应急管理等领域，金谷银行也制定了相应的制度。这些制度一方面保证了资源的合理利用，另一方面也帮助银行内部进行知识沉淀。

在业务层主要是做一些部署和集成的工作。在此基础上，金谷银行构建了工具平台，包括堡垒机、运维管理平台以及自动化发布工具。堡垒机是日常运维操作的一个入口，所有对后端业务系统的操作都是通过堡垒机进行的；运维管理平台是对资源进行管理，比如资源的增加或减少以及对物理主机的管理等；Jenkins 是自动化开源发布工具，负责日常系统的变更、生产版本的发布以及发布完的结果反馈。

运维监控平台的构建纳管了所有业务的监控，主要建设了系统监控平台、业务监控平台以及行为监控平台。其中，系统监控平台监控着物理主机 CPU、内存等物理信息、基础信息等，同时监控了一些业务系统的服务端口，比如说开启 7001、8003 等，保证业务是健康存活的状态。如果业务端口宕掉了，也会有及时的短信告知等；业务监控平台是偏向于交易类型，比如说热点事件、大量的访问行为或攻击行为等，确保系统不被羊毛党、黑灰产恶意攻击；行为监控指的是内部操作行为的监控，以便追溯风险源。

最后，南云鹏基于日常工作中的实际操作经验，详细阐述了数据备份恢复、切换演练、容量管理和巡检工作中的操作流程、注意事项及优化方案。