【摘要】本文汇总了多位金融行业同行针对分布式数据库应用难题的分享，包括工作中的实践及经验及思考洞察，同时对金融行业分布式数据应用的五大难点和应对进行了总结，可供更多同行参考借鉴。

【主笔作者】高工 某证券单位 数据库工程师

【参与分享同行】

杨光 某金融企业 数据库架构师

董生 某大型银行 数据库架构师

姚雅飞 某商业银行 资深工程师

施斌 某证券单位 数据库架构师

吉工 某证券单位 DBA

随着金融行业的快速发展，数据量急剧增加，业务复杂性不断提升，传统集中式数据库已难以完全满足金融行业对高性能、高可用性和可扩展性的需求。分布式数据库作为一种新兴技术，以其独特的架构和优势，逐渐成为金融行业解决大数据处理和高并发交易问题的一种优选方案。

然而，金融行业分布式数据库的应用并非一帆风顺。在迈向分布式数据库的道路上，金融行业面临着诸多挑战和难点。这些难点不仅涉及技术层面，还涉及到业务层面、管理层面以及人员转型等多个方面。

1.在技术层面，分布式数据库的功能完善性、稳定性与可靠性是金融行业最为关注的问题。由于分布式数据库的复杂性和多样性，其功能的完善程度直接影响到金融业务的正常运行和数据的安全性。同时，分布式数据库的稳定性和可靠性也是金融行业选择数据库产品的重要考量因素。任何故障或延迟都可能导致交易失败、资金损失甚至法律风险，因此金融行业对分布式数据库的稳定性和可靠性要求极高。

2.在业务层面，应用系统的迁移与改造是金融行业分布式数据库应用过程中的一大难点。金融行业的业务系统往往复杂且庞大，迁移和改造过程需要投入大量的人力、物力和财力。同时，迁移和改造过程中还可能带来不确定性风险，如性能下降、数据丢失等，这对金融行业的业务连续性和数据安全性构成了威胁。

3.在管理层面，技术与生态支持以及技术人员转型与培训也是金融行业分布式数据库应用的重要难点。分布式数据库作为一项新技术，其配套的技术支持和生态体系尚不完善，需要金融行业和数据库厂商共同努力来推动其发展。同时，金融行业的技术人员也需要进行转型和培训，以适应分布式数据库的应用和发展。

【问题1】对于核心系统的分布式信创改造，当前会存在若干个集中式和分布式数据库，如何进行管理？

从大的管理角度来说，大致可以分为两个方案：

1.使用数据库本身产品自带的运维管理工具进行深度运维；

2.结合企业本身开发的一些自动化运维工具（调用各自产品的API接口）或者外部购买的商业化管理软件，这些产品除了对Oracle、MySQL等传统数据库做了适配，还可以兼容当前的主流国产数据库。

其他方面，要做好相应的运维，还有其他几个方向：

1.制定运维管理指标和采集阈值和报警阈值

2.针对指标确认数据库是否提供相关监控查询方法

3.建设指标采集工具

4.建设一体化的监控报警平台，能够接收指标采集工具提供的数据，并进行有效的报警

5.制定数据库的各项配置的标准基线

6.建设自动化的数据库部署工具 ，能够按照各项配置的标准基线部署数据库。

7.主要用于SQL编写的客户端工具，一方面可以使用数据库产品自身提供的工具，也可以使用一些开源工具，加载jdbc驱动就可以使用，如果企业有信创化要求，也可以找一些国内厂商做的SQL开发平台，可以提供丰富的数据库支持，细粒度的权限管控，同时还是SQL审计和高危操作阻断能力。

【问题2】中小银行使用分布式数据库的时候，如何选择其运行业务及架构？比如账务交易业务等重要信息系统以分布式数据库的多租户模式放在同一个集群中运行？还是将多个非重要信息系统以多租户的形式放在同一个集群中运行？

笔者单位当前也在推行相关的部署模式，这种方式的一大优点，就是降本增效、我司对系统进行了相关分类、分级，同一级别的优先放到一起，不同级别的系统因为保障能力和投入不同，不建议共用资源。以下是其他同行分享的一些方案：

杨光 某金融企业 数据库架构师：

在选择租户与非租户形式的时候，我们主要考虑业务系统的级别。如果是核心交易系统，是不会做混合部署的。一方面是为了充分保障核心系统的性能，另外一方面是系统间解耦，方便容灾的配置和切换。如果是非核心得交易系统，出于资源充分利用的角度，会将多个非重要信息系统以多租户的形式放在同一个集群中运行。实际使用过程中，由于非核心系统资源消耗不大，运行比较稳定。但是这样配置的过程中，需要注意的是数据库级的全局参数需要各个业务系统全部兼容，例如sql_mode等

董生 某大型银行 数据库架构师：

每个系统使用单独的分布式数据库集群。可能这样的成本会比多租户高，但是带来的好处也很多。1.减少因为撞库造成的数据泄露风险。2.减少因为多个系统之间或者多个租户之间计算资源的竞争，导致相互影响。3.减少了数据恢复时候，对其他租户的数据使用影响。4.跨租户统计数据比较困难。

当然多租户也有很多优势：1.它减少硬件资源的使用，使资源利用率更高。2.简化数据库管理。减少了管理工作量，并提高了效率。3.可以更容易地扩展和调整系统以满足不同租户的需求。如果是真的要选择多租户，可能选择同一个数据库，不同的schema，每个租户分布在一个schema内，不同租户使用不同的schema。跨租户访问，通过数据API实现。

姚雅飞 某商业银行 资深工程师：

从提问的问题看，主要想解决数据库集中管理、集中服务的问题，而非应用对数据库高性能的需求。分布式数据库对中小型商业银行来说，管理难度大，技术复杂度高。因此在大规模应用以前，最好先做好技术储备，比如人员培训等。在引入后可以前期借助厂商的力量，指导部署使用，在承载的应用场景上建议先从非重要信息系统入手，积累运行经验。在用到重要信息系统上时，还要充分考虑分布式数据库产品的容灾能力，而且由于是集中部署涉及的重要信息系统太多，能否进行单个系统的容灾切换、容灾切换的灵活性也要充分考虑。

【问题3】在使用两地三中心的分布式数据库，某中心异常时，降副本操作是自动的吗？会否导致数据重分布及性能下降？

针对此难题，同行分享了一些经验：

董生 某大型银行 数据库架构师：

以OceanBase为例，在两地三中心架构中，当某中心异常时，降副本操作是自动进行的，并且会导致数据重分布。‌ 当主集群中的某个中心出现故障时，备集群会自动接管业务，确保服务的连续性。这个过程涉及到数据的重新分布，以确保数据的完整性和一致性‌。在两地三中心的部署架构中，主集群通常采用五副本部署，而备集群采用三副本部署。当主集群中的某个中心出现故障时，备集群会自动接管，确保业务连续性。此时，主集群的副本数会从五副本降级为三副本，这个过程是自动完成的。降级过程中，OceanBase会自动重新分配数据副本，确保剩余的副本仍然能够提供高可用性和数据一致性‌。具体来说，当主集群中的某个中心异常时，备集群会异步拉取主集群的物理日志，并进行日志压缩以节约异地带宽。这个过程确保了在故障发生时，业务可以迅速切换到备集群，保证RPO（恢复点目标）和RTO（恢复时间目标）达到可接受的水平。

施斌 某证券单位 数据库架构师：

分布式数据库两点三中心的架构，单个中心故障，一般都能做到自动接管，但是由于减少了副本，某些数据库要求副本多数派响应的，可能会对性能有影响，具体还是要结合数据库产品和高可用架构。两地三中心架构，一般每个中心都有完整的数据副本，单个中心故障不会引起数据重新分布，性能影响主要还是与数据库高可用设计架构有关，看你们到底是采用了集群间同步的模式，还是使用多副本模式，比如2-2-1的5副本架构。对于后者，例如同城中心异常，为满足副本多数派响应的要求，可能会要求网络距离更远的异地副本给出响应，性能会有降低。

杨光 某金融企业 数据库架构师：

以TiDB数据库为例，分为计算节点和存储节点。

1.对于计算节点的单机故障，一般来说对业务来说是无感的。应用一般是通过F5、HAproxy、TiProxy等负载均衡去连接数据库，单一计算节点故障，负载均衡可以自动完成剔除。对于存储节点的单机故障，创建集群的时候可以对存储实例打标签，具体级别为四级：可用区 (zone) -> 数据中心 (dc) -> 机架 (rack) -> 主机 (host)，副本调度时，会按照层级，保证同一份数据的不同副本尽可能分散。

2.对于存储单实例故障后，默认是30分钟（可调）后标记该实例上的副本不可用，随后进行自动在其他可用的服务器上进行补副本操作，这个过程中可以通过参数（store-limit）来设置region迁移的速度，使得在不影响性能的情况下完成补副本的。

对于3数据中心，1个数据中心故障时，需要看副本数量和隔离级别是如何设置的。

1.假设集群副本数设置为3，隔离级别是数据中心 (dc)，当任何一个数据中心发生故障时，集群依然是可用的，且不会自动补副本。

具体过程是：日常数据的3个副本会分别放置在dc1/dc2/dc3，若dc1整个可用区发生了停电事故并在一段时间后（默认为 30 分钟）仍然不能恢复，PD会认为 dc1上的 副本不再可用。但由于隔离级别设置为了dc，PD需要严格保证不同的 Region副本不会落到同一dc上。此时的dc2和dc3 均已存在副本，则PD在最小强制隔离级别限制下便不会进行任何调度。

2.假设集群副本数设置为3，隔离级别是机架 (rack)，当任何一个数据中心发生故障时，集群是会自动补副本的。

具体过程是：日常数据的3个副本依然会按照标签分别放置在dc1/dc2/dc3中，以实现数据中心级别的容灾，当整个数据中心故障后，PD会在存活的两个机房内自动不足3副本。

【问题4】中小型城商行在双活为主的架构下该如何选择国产化数据库？分布式数据库这一层是否有好的解决方案？

姚雅飞 某商业银行 资深工程师：

目前在数据库多中心多活上形式大于实质，更多的是打擦边球。对中小型城商行如果没有迫于宣传压力，更多的是从业务连续性和性能需求角度出发，选择合适的国产数据库。国产数据库在容灾等功能上解决方案和老外的DB2、Oracle等几乎没有太大差别，基本都支持而且比较稳定。在性能要求不高的情况下慎重选择分布式数据库，同时分布式数据库更多的解决的是性能问题，而不是容灾问题。对于分布式数据库是不适合跨数据中心进行部署的，厂商的设计也仅是满足单中心稳定运行的需要，基本没有考虑跨中心带来的网络延时、跨中心的节点数据访问、跨中心集群规模的控制、双中心独立操作带来的运行风险，对于分布式数据库跨中心的部署方案基本无法落地。

董生 某大型银行 数据库架构师：

如果你使用的是分布式数据库，且提供了多地多中心的数据同步功能，那么建议直接使用数据库提供的多活数据同步功能，不要使用自己进行应用设计。多活的架构下，最难的就是数据一致性的保障，分布式数据库一般采用Raft算法 实现了数据的一致，其中解决了诸如选举(Leader election)、日志复制(Log replication)、安全性(Safety)等问题。这些通过外挂的应用程序，不论如何补偿或者重试都不能完美的达到与之相同的效果，甚至相近的效果都很困难，特别是在进行灾备切换的时候。

吉工 某证券单位 DBA：

分布式数据库在使用上限制很多，很多自研或者采购的系统都比较难兼容，定制改造成本较大。如果要选择，需要谨慎。其他国产数据库，一般来说，功能上基本能替代传统的Oracle、MySQL、Db2等。但需要注意，一方面性能上有时会存在问题，特别是现在很多数据库也部署在云上，资源控制比较紧张。另外一方面，不时会有些bug。例如正在用的一款国产兼容MySQL的数据库，就好几次发现了厂商都没发现的bug，有些bug还是影响查询结果的，需要谨慎。

施斌 某证券单位 数据库架构师：

传统的数据库的双活架构，技术成熟度并不高，为实现数据的双向同步复杂度显著提升。分布式数据库，由于采用了多副本模式，天生支持不同数据分片读写和副本同步，使得数据库双写或者多写都可以实现。但关键是数据分片键的设计，如果能选择合适的数据分片键，确保数据的写操作访问的主分片（或者是leader分区）都在本地，性能上是可以保障的。但是这个对应用开发要求较高，要严格避免跨站点写操作，否则就容易出现写延时大问题，实际落地难度较大。另外，分布式数据库跨分片查询的性能显著降低，对于复杂查询往往是不可避免的，在实际应用过程中也是一个难点。

【问题5】分布式数据库与信创操作系统适配时磁盘IO资源无法充分使用影响整体性能的问题如何有效规避或者优化？

董生 某大型银行 数据库架构师：

首先第一步是排查操作系统的参数设置，看看是否存在优化的空间，如果检查后发现有优化空间，可以将参数进行适当的优化。如果从操作系统上确认已经没有优化的空间，就建议与相关厂家的技术支持团队进行沟通。最后，要是技术支持仍然无法解决，那么只能从应用上解决了，例如：

1.多一些实例，以数量的增加代替性能的不足；

2.可以考虑在应用的开发中引入预加工技术，或者使用缓存做二级检索，利用缓存机制来加快数据的检索速度。

杨光 某金融企业 数据库架构师：

1.首先是操作系统层，在信创改造过程可以进行多轮验证，不同的品牌、同一品牌的不同版本，磁盘io性能这块确实是有差异的。虽然最终通过操作系统厂商也能定位导致io差异的具体参数，但是对于dba来说，直接测试不同的操作系统然后直接选择更为快捷。

2.硬件层保障性能不做raid配置，鉴于现在还没找到基于信创技术能支持nvme的raid卡，我们是直接放弃了raid。通过数据库层的主备、多副本，来保证可靠性。

3.创建多个实例充分释放io，对于分布式数据库我们是每块nvme对应的去创建一个tikv存储实例。

姚雅飞 某商业银行 资深工程师：

本次探讨了金融行业分布式数据库应用过程中面临的五大问题，每个问题都直接关系到数据库的性能、稳定性、管理难度以及业务连续性。

1.核心系统分布式信创改造的管理问题：主要聚焦于磁盘IO资源无法充分使用，影响整体性能。解决策略包括优化操作系统参数、与厂家技术支持沟通，以及从应用层面进行调整，如增加实例数量、引入预加工技术等。

2.中小银行分布式数据库业务及架构选择问题：提出了制定运维管理指标、建设监控报警平台、自动化部署工具等解决方案，以确保数据库的稳定运行和高效管理。

3.两地三中心分布式数据库的容灾与性能问题：建议根据业务系统级别选择是否采用多租户模式，以保障核心系统的性能和安全性，同时提高资源利用率。

4.中小型城商行双活架构下国产化数据库的选择问题：分析了主集群故障时备集群的自动接管和数据重分布过程，以及这对性能的可能影响，强调了数据库高可用设计架构的重要性。

5.分布式数据库与信创操作系统适配问题：指出在双活架构下，应谨慎选择分布式数据库，充分考虑其性能、容灾能力以及与信创操作系统的适配性，确保业务连续性和数据安全性。

分布式数据库虽然已经发展了多年，但是真正进入大众的视野确没有太久， 随着国产信创大势的推进和各类业务的发展，分布式数据库逐步走进“寻常百姓家”，开始承担起重要业务系统的日常运转。相比于传统集中式数据库，分布式数据库在容量、性能扩展有着明显的优势，部分分布式数据库通过采用多副本的方式也增加了数据安全，但是分布式数据库的缺点也不容忽视，比如：

1.在数据一致性方面， 由于数据分布在多个节点上，可能存在数据复制和同步的问题，在成本上，分布式数据库通常是3节点起步，由此带来的软硬件费用急剧上升；

2.运维复杂度方面，故障时，多节点带来的排障耗时可能会影响业务的恢复时间等。

另外，随着硬件性能的提升，传统集中式数据库的性能瓶颈也在不断打破。对于用户来说，在进行数据库选型时，还是要充分评估业务需求和自身人力资源情况，不要因为分布式数据库的概念火热而加入进来，还是要对分布式数据库有一个充分的测试和学习之后再做决定，对于是否一定要使用分布式数据库，或许提升硬件或者改造应用也不失为一个好的办法。

欢迎点击文末阅读原文到社区阅读和讨论交流

觉得本文有用，请转发或点击在看，让更多同行看到