作者hanfeng_twt·2021-12-27 18:15

数据库架构师·SphereEx

金融行业分布式数据库选型及实践经验

字数 16309阅读 10846评论 16赞 12

**文章摘要：**随着企业数字化转型深化，数据在企业中扮演着愈发重要的作用。数据无论从存储规模、还是计算要求都有着较之以往更高的需求。金融行业，作为数据应用的“高地”，这一点表现尤为突出。如何在新时期，满足对数据基础设施更高的要求，成为各金融机构首要面对的问题。分布式数据库，作为一种新的数据库架构，经过近十余年的高速发展，已逐步成熟，并开始在一些金融机构中投产使用。但这种新的架构，较之以往的传统架构有着诸多不同。本文尝试从建设背景、技术趋势、落地实践、典型产品等多角度，分析当前分布式数据库与金融行业背景想结合，如何实现更好的落地实践。

## 1. **金融业分布式数据库建设背景**

#### 1） **多元素驱动数据库架构升级**

-  数字化转型

随着全行业数字化转型深化，金融业作为数据应用“高地”，走在这一趋势的前沿。一方面，金融业企业的业绩水平与数字化能力是直接挂钩的，从今年数据来看，转型较快的金融机构业绩提速明显快于较慢的；另一方面，来自宏观经济发展压力，导致规模盈利减低，进而导致业务转型加速。在数字化转型加剧的大背景下，金融 企业对数据使用呈现多样化特点且针对特性能力提出更高要求。相应的也对数据底层基础设施之一的数据库提出要求。

-  金融业 业务驱动

如上面所谈，金融业在数字化转型中，面临业务转型问题。当前金融业整体处于信息化末期、移动化成熟期、开放化成长期、智能化探索期。其典型特点是，金融行业的数据急剧增长，对数据存储和管理提出了更高要求；在高并发业务和大用户量带来的系统压力的同时，也要求移动应用响应速度更快。

-  国家 政策指导

在政策层面，国家很早就将新型数据库作为重要基础设施来看待并给出指导性原则。在《金融科技（ FinTech）发展规划（2019-2021）》中明确指出：“加强分布式数据库的研发应用。做好分布式数据库金融应用的长期规划，加大研发与应用投入力度。有计划、分步骤稳妥推动分布式数据产品先行先试，形成可借鉴、能推广的典型案例和解决方案，为分布式数据库在金融领域的全面应用探明路径。建立健全产学结合、校企协同的人才培养机制，持续加强分布式数据库底层和前沿技术研究，制定分布式数据库金融应用标准规范，从技术架构、安全防护、灾难恢复等方面明确管理要求，确保分布式数据库在金融领域的稳妥应用。”

#### 2） **金融业对数据库转型诉求**

在上述大背景情况下，金融业对数据库支持能力呈现如下特点：

-  实时性

在数字化趋势下，数据会更多参与到企业决策、业务调整甚至驱动业务变化。数据的鲜活性，对企业价值意义完全不同。实时的交易处理、实时的反馈、实时的汇聚、实时的洞察成为全场景数字化的必备。例如在金融场景中，金融需求与生活场景相融合，实时风控的复杂度以及时效性要求随场景服务的发展不断增长，通常需要秒级完成业务流程。翻译成技术语言，即要求支持对数据高频实时多点写入、对多类信息实时汇聚分析处理。于是近些年来，在数据流式处理、 HTAP、高性能计算等领域的发展，正是为迎合这一诉求。

-  敏捷性

数字化转型下，各种业务形态不断涌现且单业务内变化也很大，这对底层基础设施提出了敏捷性要求。即具备快速响应能力，满足各类业务应用需求。作为传统的以静态、固定资源供给方式，过渡到以动态、可调节的资源供给方式。这其中以云、容器化、 Serverless、存算分离为代表的技术能力，正是为满足这类需求而诞生。即使是以较为传统架构的资源供给方式，也更为强调弹性、可定制能力，满足客户此方面需求。

-  安全性

数据安全，是近些年来的热门话题。从监管方的频频出台各项政策，可见一斑。作为承载数据的主体，数据库首当其冲需要将更为重视安全问题。从数据存储、数据访问、数据传输、数据应用等多角度解决数据安全问题。特别是过去一二十年开源数据库蓬勃发展，但开源数据库自身在安全方面是否能达到商用标准，值得关注。此外，考虑到复杂的国际产业环境，开源协议本身的合法合规性也值得关注。

- 可用性

可用性要求，一直是数据库提供的基本能力之一。随着数字化深入，越来越多的数据参与到企业经营管理之中，这些对于可用性要求提出了更高的要求。从数据库的角度来看，之前单机架构或集中式架构，一般是通过高可用硬件 +软件来解决；对于新兴的分布式架构来说，其组件更多也更为复杂，且对于硬件也无较多要求，这就要求软件本身提供更高要求。

- 经济性

随着数据存储规模越来越大，对数据计算要求越来越高，整体数据存储和计算的成本也整体提高。如何提供更具经济性的方案，对客户能否大规模使用意义很大。这其中云数据库、存算分离、数据分层等技术，正是为了应对这一诉求。云作为一种新的资源供给方式，可以带来更为切合需求的资源消耗。存算分离，则提供一种按计算和存储独立扩展能力，避免冗余浪费。数据分层，则可根据数据热度等因素提供不同的能力，满足个性化需求。

- 智能化

由上述变化可见，对于数据库而言，无论从使用规模、复杂程度都会带来很大调整。针对这一问题，一方面可以通过工具化、平台化的方式来满足管理问题；而更为优雅的方式是在数据库端提供内置的智能管理能力，例如智能调优、索引推荐、自我诊断、故障自愈等，可协助 DBA降低运维难度，大幅提升管理效率。

- 海量并发

这是两个需求，一个是数据规模问题，提供海量数据支撑能力；一个是数据计算问题，提供高并发访问支持。这些都是数字化会带来业务变化的必然。对应于技术而言，分布式数据库无疑是一种很好的方式，也是其主要面对解决的场景之一。

- 统一管理

随着数字化深入，对数据库的种类与数量、企业的 IT体系等都发生了不少变化。这些变化冲击了传统的数据库生态，第一数据库选型自身呈现多元化趋势；第二随着分布式、存算分离等新兴架构，对管理也带来了管理难题；第三随着对安全性、可靠性等方面的更高要求，也带来了不少难点。面对上述问题，为数据库提供统一管理和运维的平台型工具也逐渐走向台前，变得越来越重要。

- 自主可控

对基础软件来说，自主可控非常关键。作为数字化的载体，数据库的自主可控能力尤为重要。近些年国产化诉求日益高涨，也有着这方面的考虑。这其中值得关注的一点是关于开源的使用。根据近期的调研，开源数据库份额已经超越商业数据库；但对于开源数据库的把控能力，却有着较大差异。特别是某些商业数据库，底层也是基于开源产品的，尤其值得关注。

- 开放生态

数字化深入，带来的更多的场景、更多的方案、更多的产品。如何能做到产品之间的很好的融合，发挥最大的作用，开放生态非常重要。对于数据库而言，过去数十年来以国外商用数据库产品为主，已经培育自己的生态圈；而对于国内产品而言，还需要走过这一过程。比较可喜的是，开源软件的使用可大大加速这一过程。以 MySQL、PG为代表的开源软件，具有较为完备的生态，国内产品可通过兼容开源产品，复用其生态，大大加速这一进程。

- 简化融合

如之前所说，数字化深化带来的技术需求的多元化，与之对应的产品方案也呈现同样的态势。虽然可以通过统一管理角度去简化管理，但对于用户而言仍然不得不去面对复杂的管理和使用问题。如果能通过单一平台提供所需能力，无疑对用户非常有吸引力。这就是简化融合的诉求的来源。近些年来，包括混合事务与分析处理（ HTAP）、湖仓一体、流批一体等，都是代表着用户追求 “简化、融合”技术栈的需求。此外，云也是一种简化融合的体现，通过一站式的产品+方案，解决用户复杂管理和使用问题。

- 消费创新

数据在未来扮演着愈发重要的角色，人们对数据的消费使用习惯也发生了很多变化。从使用角度来看，普惠性得以强调。数据的使用消费者，从传统的分析师、 BI工程师向普通的数据消费者转移。越来越多的用户能够触达数据，享受数据结果。当然，这也得对数据提供方式带来新的挑战，自助式、对话式、自动化甚至智能化的数据计算展现方式得到更多的使用，进一步减低人们使用数据的门槛。这对于底层数据库带来包括适配能力、实时计算、多模计算、智能分析等诸多要求。

#### 3） **分布式数据库在金融业使用痛点**

如之前所说，金融业一方面面临诸多转型压力，对底层数据库提出了更多要求；另一方面原有数据库技术已不适应当前业务特点，继续升级换代。面对底层基础设施的转型问题，分布式数据库作为解决上述方案的唯一选型。但在这一选择过程中，往往存在较多的痛点和难点。这主要是因为金融行业的特殊性所造成的。

- 基础功能待完善

对标传统集中式数据库，现有的分布式数据库在功能上仍然有待完善。这一方面是因为分布式架构所造成的功能 tradeoff，另一方面是在产品化能力完整性上的欠缺。前者是我们在使用分布式数据库产品时，需要在架构、设计层面需要在关注的，在项目初期都需要解决掉的。而后者厂商产品经过多年发展在内核能力上已趋于完善，但在周边配套的管理、设计、优化工具上，仍需进一步完善。毕竟最终为用户呈现的，是一套完整的数据库解决方案。

- 运行稳定待验证

对于金融行业而言，稳定性是第一位的。虽然分布式数据库在设计之初，就将稳定性设计放在优先位置，其天然的分布式架构也有利于提供更高的可用性保证。但一方面分布式架构天然由多组件组成，其复杂程度较集中式更高；另一方面其对底层基础环境的要求也更高。此外，产品的稳定性是要在长期实践中不断打磨、持续改进的。分布式数据库作为后来者，也需要经历这一过程。

- 迁移改造任务重

选择使用分布式数据库产品，对应用侧来说，需要有大量的应用迁移工作。一方面是由于分布式数据库较集中式数据库功能上有所削弱，另一方面更换数据库天然所需要的移植工作。虽然目前各分布式数据库也推出 兼容能力，但从实际效果来看仅能减少部分移植工作，整体迁移任务量仍然很高。且迁移采用所谓的兼容模式，也不利于后期平滑更换，这点后面会讲到。

- 风险巨大需并行

对底层数据库的更换，是存在较大技术风险的。一是由于新产品、新架构所带来的风险；二是应用迁移改造带来的不确定性；三是产品本身的稳定性的潜在风险。为应对这种情况，最为稳妥的方式是采取应用双发并行的方式解决。这种方式可在最大程度上减少可能初期的风险，可做到数据冗余、无缝切换、灵活可控等，但其花费的代价也是非常高的。需要从应用端做大量双发改造，如果更换系统很多，这方面代价是比较大的。

- 生态环境需培育

虽然发展多年，但国产分布式数据库在整体市场上仍然属于小众选择。之前国外厂商产品占据市场领导地位，经过多年发展已形成了较为完善的生态。随着近些年来， MySQL、PG开源数据库在互联网行业得到大量应用，积累大量用户，建立其不错的生态。很多国产分布式数据库采用迂回策略，通过兼容上述数据库标准，来享受开源生态红利。此外，近期国产数据库如TiDB、OceanBase、PorlaDB、openGuass等，也纷纷开源建设自有生态。

- 信创要求时间紧

作为国家安全的重要举措之一，安全可控成为基础要求，信创因而诞生。为保证上述政策执行到位，国家也设定实施计划。作为基础软件的数据库，也是信创工作的重点。如何在规定的时间内完成，也为各企业带来的很大压力。

- 场景多元难选择

与互联网企业不同，金融行业对数据的使用场景更加多元化，这也对数据库提出了较高的要求。仅选择单一数据库满足全场景需求，几乎是不可能的。在传统集中式数据库上，这一问题还不明显，因为这些数据库往往是多面手，各方面功能较为均衡；而分布式数据库则不然，其往往有明确的适用场景范围。而作为企业用户，是需要对自己场景有个清晰的认识，然后按图索骥找到适合自己的产品。

- 厂商绑定风险高

选择某厂商产品，也就意味着选择某一技术路线，如果深度依赖厂商产品的特有能力，无疑存在绑定风险问题。这点对于分布式数据库来说，表现尤甚。各厂商产品实现差异很大，没有通用的使用标准。如何规避这一风险，带来最大的自由度选择？后文会展开说明。

## 2. **分布式数据库技术发展趋势**

#### 1） **数据库技术发展整体趋势**

数据库技术 ，最早源自上世纪70年代，从IBM著名的论文开始，后面诞生了Oracle、DB2为代表的优秀商业产品以及PostgreSQL、MySQL为代表的开源产品。这些产品很好的满足了对数据存储和计算的需求。随着21世纪初期，互联网浪潮的来临，数据规模呈爆炸式增长，单机数据库越来越难以满足用户需求。这也催生了分布式数据库的到来。到了2006年之后，出现以HBase/Cassadra/MongoDB为代表的NoSQL类产品。这些产品实现了分布式架构，可以实现容量的水平扩展，但也牺牲了诸如事务、SQL访问接口等能力。存储模型的简化为存储系统的开发带来了便利，但是降低了对业务的支撑。在这一阶段，很多企业为了解决大规模数据存储与访问的问题，也研发了很多中间件产品。其原理是通过将数据分片存储到单机库，上层对SQL解析实现对语句的路由。这种方式有一定的难点，例如对分布式事务的处理及规模扩大下的管理问题。到了2012年，Google的论文为关系模型的分布式架构，提供了新型分布式数据库理论基础。在此之后，诞生了一系列新型分布式数据库产品。其原理是通过分布式一致性算法协议完成底层数据多副本存储，上层则实现了标准SQL支持能力。

数据库架构演进，从整体来看，走过了大致三个阶段。
![](/home/attachment/202112/27/1228765_164059986585148.png)
- 第一阶段，是以单节点为主要特征，通过单机能力来承载数据计算和存储的能力。这一架构的优势在于架构简单、维护成本低，随着单机能力的提升可满足大部分业务场景需求。缺点是数据库节点（包括内置存储）容易出现单点故障，且计算和存储能力受限于硬件性能，无法扩展。

- 第二阶段，是以共享存储为主要特征，通过多台主机来承载数据计算能力，数据存储则集中于集中式共享存储之中。这一架构的优势在于解决了前一阶段数据计算部分的单点故障，结构仍较简单，易于实现事务一致性等问题。缺点在于数据计算部分扩展能力有限，底层数据存储部分依赖于高端共享存储且扩展能力也有限。

- 第三阶段，是以分布式为主要特征，通过多台主机来承担数据计算与存储能力。这一架构优点在于良好地水平扩展能力，数据多副本存储，无需依赖共享存储。缺点在于，计算与存储能力需同步扩展，灵活度稍差，此外存在分布式查询、分布式事务的处理开销问题。

#### 2） **主流的分布式数据库技术**
![](/home/attachment/202112/27/1228765_164059987712397.png)
-  分布式中间件

这种架构是从之前谈到的中间件路线演进而来 ，是一种典型的“ Share Nothing”架构。通过上层无状态的计算节点提供弹性可扩展的计算能力，下层通过增强单机数据库提供基础存储能力及本地算力。这一架构通过硬件堆叠，可近似线性地提供计算性能和存储容量，具有可支持超大规模集群的能力。这种架构在分布式事务、全局MVCC等方面，往往存在一定难点，各厂商也有各自解决之道。

这一架构产品优势在于功能丰富、可按业务做定制；稳定性较高，基于成熟稳定的单机引擎。在面对超大规模数据存储，通过灵活的分片配置策略，支持高灵活度数据打散技术，并可贴近场景需求定制分片。相对不足在于全局事务能力、全局 MVCC、副本控制、高可用等方面存在先天短板，需要有针对性增强。例如引入全局事务管理器组件，突破单机限制，实现分布式事务的实时一致性及全局MVCC能力，对应用透明的分布式事务处理，应用无需改造。通过一阶段提交+自动补偿机制，提升分布式事务处理性能。针对数据强一致性的要求，在单机库同步技术基础上，通过内核级的增强优化实现更高级别的复制保证数据不丢失。此外，由于需维护多节点一致性而带来的在跨分片DDL、分片节点扩容、跨节点复杂查询、全局一致的备份恢复等方面问题值得关注。

这种架构产品较为适用于数据规模巨大、对延迟要求很高的在线交易场景。在数据库设计时，需要特别注意分区键和分区策略的选择，合理布局数据，尽量避免跨节点的分布式事务处理，以提高数据库的效率。

- 分布式事务

这 种架构正是受到Google论文影响演进而来 ，采用“ Share Nothing”架构。其采用存储与计算分离架构，底层多采用自研或裸存储引擎，数据按规则打散并存储多个副本，通过paoxs/raft等分布式协议保证多个副本间数据一致。上层实现数据库基础的优化器、执行器等组件，对分布式事务、全局MVCC等支持更为彻底。此外，由于其底层的存储引擎不是依赖某一产品，可根据需要组织数据，因此在适配场景上 更有优势，例如在某些分析类场景可选择列存。

原生分布式实现，工程上不依赖其他产品，可控程度更高。面对很多新的需求，可从底层加以实现支持，不受限于第三方。在副本控制、数据一致性、容灾、弹性能力等方面更具有优势。此外，场景方面有更为灵活的选择及未来可扩展的空间。 但这一方式在产品成熟度，仍需较长时间沉淀。特别是使用在核心业务场景，仍然需要较长时间的锤炼。此外，其内置的分片规则，对于某些需贴合业务的架构设计不太友好。对于高并发、低延迟的极端场景仍然有一定局限。

- 分布式存储

在某种程度上讲，云原生数据库也是一种分布式，但与前两者区别是非 Share Nothing架构，而是Share Everything模式。其底层是与分布式云存储，本质上来说仍然是一种集中式架构。上层的计算部分，是无状态的一组结点组成。针对这种架构不足展开说明，原因是这种方式是需要对底座有比较重的依赖，无法在金融行业相对要求独立环境中部署，除非整个底层都更换。因此，使用选择上存在一定困难。

## 3. **分布式数据库金融业实践**

#### 1） **金融业数据库选型难点**

金融业在分布式数据库选型存在若干难点：

- 复杂业务逻辑问题，包括数据库技术基因匹配性（如：数据库本身锁机制、隔离级别问题），包括技术兼任性（如存储过程、视图兼容性）；

- 应用的适配度问题，银行应用大部分都是基于单机关系型数据库机制设计的，例如大部分场景都是串行机制，发挥不出来分布式数据库的强大并发处理技术，反而分布式数据库本身的二阶段提交机制，对简单事务的延时增加问题，造成串行事务执行性能低下；

- 人员能力的匹配性，需要根据人员技术能力进行选型考虑，例如基于 Spanner体系，基于Aurora体系，基于国内互联网公司自研的产品等，要考虑现有人员对数据库技术的了解程度，更要关注数据库技术本身的开放度和社区热度，让人员可以很快的学习和提升数据库技术能力；

-  数据库自身能力问题，包括在分布式事务、数据一致性、高可用容灾等，相较于传统集中式数据库还是存在一些不足；此外金融业在联机交易的低延迟要求、跑批类的高吞吐要求也对分布式数据库提出了很高的要求；

-  数据库运营维护问题，包括是否具备足够能力维护分布式数据库？是否能够接受数据库转型期间的业务中断时间？是否具备迁移（甚至在线）迁移能力？是否具有应用级双发能力，规避可能出现的风险等。

#### 2） **金融业数据库选型策略**

通过数据库的技术标准化和轻量化工作，形成统一的数据库使用规范，解耦应用和底层数据库技术架构，在标准数据库协议及语义下，可以很轻松的更换数据库架构。通过构建异构间数据同步、流量接入控制（限流、灰度等）、全局数据服务（如事务、快照等），实现业务的无感切换和迁移回退，保证最大的灵活可控。

针对上述诸多难点、痛点，作为金融行业如何选择分布式数据库呢？可遵从以下几个方面：

- 尊重路线之争，无关技术领先

如前面所述，分布式数据库的发展有着不同的技术路线。曾有种观点认为，“分布式数据库的发展方向代表着未来，分布式中间件方向没有前途”。针对这一问题，我的观点是采用不同技术路线的产品有自己的适用场景，与技术领先性无关。某种技术通过提出理论、工程化实现、产品能力输出，可解决某方面需求、甚至带来巨大产品能力的提升；但希望以此通过大一统的产品解决所有问题是不现实的，未来仍然是多种技术路线并存的情况。

- 成熟度有待完善，但时不我待提前规划

分布式数据库作为一种新兴技术产品，其成熟度尚需锤炼，但不能基于此就选择观望态度。产品成熟的提高，一方面来自厂商对产品的不断迭代优化；另一方面也来自使用者的不断打磨。企业内对数据库的落地使用，也需要较为长期的过程。此外，外部驱动也对这一选择起到加速推动作用。作为企业来讲，根据自身情况可以选择不同策略（引领、跟随）；但无论那种都需要提前规划，有明确方向和实施路径。

- 国产数据库百花齐放，机会无限

近些年来，国产数据库发展迅猛，呈现百花齐放态势。针对这一现状，一方面要持续关注这些产品，给予这些产品充分施展机会；另一方面制定准入标准严格把关，让真正有实力的厂商能够进入，得到充分锻炼、打磨的机会。

- 慎重技术选型，不迷信宣传

技术选型是个很严谨的过程，需要慎重对待。有很多第三方的评测和厂商宣传结论，但这些只能做参考，决策层面的依据还是需依靠自己。一方面宣传内容一般都会所选择有利于自己，这会带来一定误导性；另一方面对同一概念的理解是有偏差的，很难仅仅通过一段文字描述就能完全说清楚。这些问题只有在真实环境，叠加上自身需求，测试出的结果才具说服力。

- 结合场景需求，没有最好只有最适合

业务场景千差万别，其对数据库能力要求和侧重点也有所不同。很难选择一款通用型产品满足全场景，那就需要根据实际情况做有针对性的选择。此外，不同产品各有强点和局限之处，选择最适合你的产品就好。例如上文谈到的分布式中间件产品，在超大规模、自定义分片、超高性能、业务控制等方面往往更有优势；而分布式数据库产品，则在分布式事务、数据强一致、混合负载等方面有所擅长。

- 不选产品选兼容性，保持最大自由度

当前分布式数据库，仍然处于快速发展期，很难确定未来的主流选择。为了规避路线选择、厂商绑定的风险，比较现实的方法是选择一款兼容通用性协议的产品，并且在使用中仅使用标准数据库的用法。举个例子，选择一款兼容 MySQL的产品并且安装标准MySQL的用法使用；当出现风险时完全可选择另外一款同样兼容MySQL的产品来替代。目前MySQL生态在国内最为成熟，很多厂商产品也选择了兼容它，因此选择兼容性产品在未来的自由度最大。

- 保持技术敏感度，紧跟时代发展步伐

面对技术发展多变、应用特点多变、外部需求紧迫的现状，时刻关注分布式数据库发展，保持足够的技术敏感度，紧跟技术发展趋势。采取架构前置、谨慎选型、局部试点、多线布局、掌握主动、自建增强等策略，保持主动。

#### 3） **金融业数据库场景梳理**

金融企业对数据库使用场景众多，而对应分布式数据库产品功能各异且特点鲜明。如何为不同场景选择最为适合的分布式数据库产品，成为分布式数据库落地前提。下表结合金融行业特点，抽象出若干数据应用场景，形成以事务类、分析类、混合类为代表的三大类五种典型场景。从适用场景、技术架构特征、关键指标、功能维度等多方面对场景进行梳理。一句话总结：“没有最好的产品，只有最合适的产品！”。
![](/home/attachment/202112/27/1228765_164059990571098.png)
![](/home/attachment/202112/27/1228765_164059991110925.png)

#### 4） **金融业分布式数据库选型技术要素**

技术为业务服务的，不能为了使用技术而使用，需要综合考虑成本和收益的平衡。分布式数据库使用场景，应当在数据大规模、高并发、高可用性等场景下有其特有优势。一般的业务场景如果能用单机数据库支撑的尽量用单机库。选择一款分布式数据库，会带来一系列的成本，如应用适配成本、运维成本、硬件成本，这方面后面会赘述。此外，在做上述判断时，还需考虑业务的发展，最好是能判断三年的数据量和交易量的增长变化。在进行分布式选型时，可重点考察下列几个方面：

- 分布式事务

分布式架构，自然会带来分布式事务的问题。由于需要跨节点的网络交互，因此较单机事务会有很多损耗。随之带来的是事务处理时间较长、事务期间的锁持有时间也会增加，数据库的并发性和扩展性也会很差。针对单笔事务来说，分布式事务执行效率是肯定会有降低的，分布式带来的更多是整体处理能力的提升。但在设计之初，就应尽量做到业务单元化，将事务控制为本地事务，这可大大提升执行效率。

- 性能

由于二阶段提交和各节点之间的网络交互会有性能影响，分布式数据库优势不是单个简单 SQL的性能，但是大数据量的SQL查询，每个节点会将过滤之后的数据集进行反馈，会提升性能，并且分布式数据库的优势是并发，大量的SQL并发也会比单机数据库强大，应用需要做分布式架构的适配，将串行执行机制尽量都改造成并发处理。对于含有需要节点间数据流动的SQL语句的事务，OLTP类的分布式数据库处理效率一般较差，事务处理时间会较长，事务期间的锁持有时间也会增加，数据库的并发性和扩展性也会很差。建议尽量改造存在跨节点数据流动的SQL语句 （主要是多表关联）的事务。 分布式数据库性能是软硬整体架构的保障，不仅在软件、S QL 语句方面做优化，硬件方面也需要重视，包括处理器、内存、网络、磁盘等等，尤其在支撑交易类业务系统时重视对基础设施选型和优化。

- 数据备份

分布式数据库一致性保证通过内部时钟机制，所有节点都会遵循一致的时钟，所以备份恢复的增量也是基于时钟，相当于单机数据，但是分布式数据库的备份解决方案最重要标志是否支持物理级的备份，物理级的备份会比逻辑的备份性能吞吐会大很多，还有就是是否支持一些分布式备份方案，比如 S3协议接口，是否支持压缩等功能。分布式数据库基本都具备备份和恢复方案，通常从备节点进行连续备份（全量+日志），恢复的时候制定节点进行恢复到指定时间点，整个过程可配置自动任务自动执行。

- 高可用

分布式数据库大多都是基于多数派协议，同城双中心不适合多数派的要求，同城数据级多活建议采用三中心部署，如果同城主备可以采用集群级的异步复制。异地建议采用集群级的 binlog异步复制。建议实例的主备节点设置在同城两个双活数据中心，仲裁节点三机房部署；异地灾备单独启实例与本地实例进行数据库间同步，也可以将本地备份文件T+1恢复到异地灾备。

- 数据一致性

NewSQL分布式数据库基本都是通过获取全局时钟时间戳，采用二阶段提交实现一致性，可以实现一致性的保证，分库分表架构对于事务的一致性，需要应用层考虑，比如通过合理的分区键设计来规避。分布式数据库对于跨节点事务目前还是实现的最终一致，对于全局一致性读，一般通过引入类似全局时间戳的组件统一管理全局事务，在数据库选型时可以重点关注厂商对这一块的实现。如果目前暂时无法提供全局一致性读的分布式数据库，对于要依赖分布式事务“中间状态”的业务，优先进行业务改造进行规避，其次通过合理的数据分片设计让其在单节点内完成。

- 其他因素

金融行业在数据库选型中，除了需要考虑上述外，还有其他一些因素的考虑。如原有系统的承载能力、是否必须进行选择等。

#### 5） **金融业分布式数据库选型非技术要素**

金融业分布式数据库选型，除了上述技术要素外，还包含如下非技术要素，主要是在成本投入方面：

-  硬件成本

一般采用 x86服务器，存储多为本地存储，推荐使用SSD甚至是NVMe SSD，网络一般 采用 万兆网络。在这部分主要成本是取决于集群规模、数据量及数据库自身架构。此外，如果涉及到灾备方案，还需要考虑灾备环境的硬件投入及主备间的专线费用。 此外，考虑很多金融单位现在机房建设空间和能耗有限，可采用配置较高的硬件设备，如基于英特尔 ®至强® 金牌处理器内核的x 86 物理机、配置 英特尔®傲腾™固态盘 等，减少服务器数量、降低耗电量。

- 软件成本

主要来自分布式数据库本身的软件采购成本，成本取决于各厂商的内部商业策略。但这部分总体来讲，是较传统数据库产品还是有优势的。此外，这部分还涉及到维保费用，针对分布式数据库来说，相对较新，企业自有能力尚不具备，还是建议购买原厂服务或其他三方公司的服务，降低风险。

-  开发测试成本

这部分是指针对数据库更换后，应用需要需要完成的必要的开发测试成本。这部分成本差异很大，跟原有系统实现有较大关系。如果原有系统重度依赖数据库（大量功能是基于数据库自身功能实现的），那么存在的改造量较大。新型分布式数据库的功能，不能与传统数据库做一一对应，很多能力是需要在应用层重构完成。针对这种情况，是建议应用开发遵循数据库标准方式进行（如采用 MySQL作为标准）开发，这样如有改型也很简单。此外，还有一类隐形成本包含在这部分，如果业务比较重要，是需要考虑双发支持或灰度迁移的方式，这会带来一部分工作量。总体来说， 这部分成本是比较高的，可能占整体成本的大部分。

-  运营维护成本

这部分成本，包括了为满足更换数据库所带来的数据迁移成本和上线后的日常维护成本。针对前者，可以在应用侧解决或者外采商业软件解决；后者更多是人员管理成本。针对这部分成本，是有个相对较长的投入，且整体成本不少。

#### 6） **金融业分布式数据库运维要点**

分布式数据库，作为较为新兴的基础架构产品，在运维层面有其独有特点。下面结合之前的实践，将运维要点整理如下：

- 软件规划和部署方案

分布式数据库组件众多，而且每个组件都有高可用备份，所以在有限数量的服务器下进行组件的分配要尽量考虑达到各个服务器负载的均衡， GTM作为分布式数据库的瓶颈尽量和他们组件分开部署。

- 监控方案

监控一般可以采用开源的 zabbix进行定制化开发，当然也可以基grafana+prometheus的方案做监控。但一般大中型金融企业都有一套自己的监控系统，这里需要有个对接适配的过程。此外，由于分布式的多组件特点，在监控指标数量及指标间关联上，与传统数据库差异巨大，是需要监控摸索过程。

- 语句调优

因为不同厂商研发的数据库 SQL优化器及执行计划都有所不同，所以要根据不同产品进行学习。天然由于分布式架构带来的复杂度，也会影响到语句的执行效率。比较常见的如数据库访问链路长所带来的的问题、数据分布不均带来的问题及分布式优化器的问题等。

- 备份方案

分布式数据库如何做到多节点全局一致性备份也是难点，要做到真正意义上的基于时点恢复，就需要做到分布式环境下每个全局事务的可追溯操作。

- 应急方案

因为分布式数据库还处于发展阶段，还不成熟，技术比较复杂，所以生产环境下要制定详细的应急方案，让不了解分布式数据库的同事也能够在出现问题时按照手册操作。

- DDL变更

在分布式架构下， DDL变更是个难点。如果做到全局一致，做到业务无感知，是核心点。不同厂商产品实现能力层次不齐，介于此安排在低峰期操作并做好必要的监控回退。

- 水平扩容

分布式架构下，都是支持水平扩容的。一般来说，非数据节点的扩容是相对容易的，对业务也是无感的，但涉及到数据节点的扩容，势必会遇到数据 reshard的问题。建议选择在低峰期，同时控制好扩容粒度。即便如此，仍然建议提前做好容量规划，避免扩容。

- 跨片计算

分布式架构下，数据是分布在多个节点中。如果数据计算是可以在本地计算完成，无疑是效率最高的，但完全避免跨片计算是不太现实的。如果发生跨片计算，则不可避免地对上层节点带来压力，要做好相应监控，并争取在根本上避免跨片类计算。

## 4. **分布式数据库典型产品分析**

下面以国内典型的分布式数据库产品—TiDB为例，阐述如何在金融业落地。

#### 1） **某典型产品技术特点**

针对金融业业务特点，结合T iDB 的自身能力。其产品可在一定场景下满足金融业对分布式数据库支持。其具备如下技术特点：

- 金融级高可用

数据采用多副本存储，数据副本通过Multi-Raft协议同步事务日志，多数派写入成功事务才能提交，确保数据强一致性切少数副本发生故障时不影响数据的可用性，可按需配置副本地理位置、副本数量等策略满足不同容灾级别的要求。

- 弹性扩缩容

得益于TiDB存储计算分离的架构设计，可按需对计算、存储分别进行在线扩容或者缩容，扩缩容过程中对应用运维人员透明。

- 实时HTAP

提供行存储引擎TiKV、列存储引擎TiFlash两款存储引擎，TiFlash通过Multi-Raft Learner协议实时从TiKV复制数据，确保行存储引擎TiKV和列存储引擎TiFlash之间的数据强一致，TiKV、TiFlash可按需部署在不同机器，解决资源隔离问题。

- 兼容MySQL5.7协议和MySQL生态

兼容MySQL5.7协议、MySQL常用的功能、MySQL生态，应用改造可参照MySQL体系，应用后续可便捷地在MySQL系数据库之间进行迁移。

#### 2） **某产品适用典型场景**

没有完美的产品，只有最适合的。T iDB 针对下面场景是比较适合的：

- 规模场景OLTP

1. TiDB水平弹性扩展、分布式数据库强一致性等特性适合批量计算场景
 2. 解决传统数据库并发低、分析能力差、无法线性扩展等痛点
 3. 结合应用系统的场景能力，打造整体分布式弹性扩缩容的业务架构

- 分布式批量处理
  1. 联机或批量应用实时或批量将各业务流水、账务明细、产品信息等海量数据写入TiDB数据库
  2. 分布式调度处理程序根据流水明细等静态数据进行批量处理，将任务切分给执行节点，结合TiDB分布式数据库特性，提供批量处理、高效写入、弹性计算等核心分布式批量数据处理能力

- 海量HTAP
  1. 使用TiFlash，构建列存副本，借助列存优势，实现海量数据快速访问
  2. 借助TiSpark，让 Spark SQL 直接运行在分布式存储引擎 TiKV 和TiFlash上
  3. 同时具备TP和AP的处理能力，且通过配置可实现资源隔离

#### 3） **某产品技术架构特点**
![](/home/attachment/202112/27/1228765_164059993941810.png)
 TiDB主体包含三大组件，分别是TiDBServer、PD和TiKV，TiSpark和TiFlash为可选的大数据组件，实现大数据分析能力。针对不同组件的功能，下面简单描述如下：

- TiDB  Server

TiDB Server 提供无状态的分布式SQL 层，完成对SQL语句的语法解析、语义解析、协议解析。针对分布式特点，生成对应的分布式执行计划。对于能够下推的计算任务，将下推到下层节点TiKV来完成。

- TiKV

TiKV 是一个分布式且支持事务的 Key-Value 存储引擎，其底层存储在R ocksDB 中。通过优化的LSM-Tree结构，实现高速读写、批量写入、无锁快照读等。数据按分片规则，在多个数据节点存储，节点之间通过 Raft 协议 保持数据一致性。事务模型采用Google 的 Percolator 。

- PD（Placement Driver）

PD，主要存储系统级元数据，包括维护数据副本的规格，并提供全局唯一的 TSO 时间戳分发服务。根据集群的情况，下发调度任务进行集群维护工作。

#### 4） **某产品的高可用架构**

为保证分布式数据库的可用性， TiDB 在组件级、集群级提供了各种技术手段来保证整体可用性。

- 组件高可用

1.  P D 节点异常时， 自动将leader 迁移到其他节点 。如需要可 修复或者增加新的节点
  2. TiDB节点异常时，因为 TiDB 节点本身是无状态的，单台故障结合高可用机制，会自动隔离，不会影响系统的正常运行 。在 节点规划时会有一定的冗余，可以根据需要 增加。
  3. TiKV节点异常时， 会自动将异常节点中的leader迁移到其他节点，同时会在其他节点上自动补充副本数据 。在 规划时会有冗余，但由于是存储，建议修复或增加新节点

- 集群高可用
![](/home/attachment/202112/27/1228765_164060002495281.png)
 在集群级高可用中，同城集群部署方式与单地域两可用区部署方式一致，异地为一个3副本的灾备集群，生产集群与灾备集群间通过binlog或ticdc来进行数据同步。当发生机器级别故障，可参考组件高可用的方案。当发生可用区级别故障，如主中心发生故障，集群自动检测故障，并进行故障切换，启用副中心，保证R PO=0 ，R TO < 5 min。当发生地域级别故障，如主中心和副中心所在地域故障，可 通过脚本拉起灾备集群，应用系统连接到灾备集群 ，保证R PO<5 min，RTO<15 min。

#### 5） **对底层算力支持的增强**

移动互联网、物联网、人工智能等技术的快速发展推动了数据的爆发式增长，要求企业数据库必须能够应对海量数据和对瞬间的超大网络请求，迫使传统的IT架构必须提升其灵活性、可靠性、流动性和安全性。与传统数据相比，分布式数据库既支持分布式ACID事务，具备高并发、高可用、弹性伸缩特性，并同时处理交易类型业务和分析类型业务。这也对对包括处理器、内存、网络和磁盘等底层硬件提出了更高的要求。具体而言：

（1） 分布式数据库对算力，需要较高的内存频率、更多更大的内容存量，能够最大限度地满足分布式数据库的严苛要求，尤其在交易类场景，工作负载对性能有极为苛刻的要求，处理器的增强，能够显著加持提升分布式数据库软件层面的能力。

（2） 存储介质的数据吞吐能力和延时往往成为决定分布式数据库性能表现的关键因素。采用S SD ，结合固态盘，可以处理读取密集型工作负载，结合S SD ，为分布式数据库性能保障提供存储基础。

（3） 分布式数据库节点间的网络的带宽和延时往往也会极大的决定分布式数据库的性能和可靠性。高性能的网卡为分布式数据库奠定良好的网络性能和可靠性。

一般采用的硬件技术为英特尔 ®至强® 金牌处理器、英特尔 ®傲腾™ 固态盘和英特尔 ® 以太网网络适配器。典型配置如下：
![](/home/attachment/202112/27/1228765_164060004721588.png)

## 5. **总结**

分布式数据库 ，作为 一种新型数据库 产品架构，正处于蓬勃发展阶段。其 具备 的 数据分片管理、分布式事务、读写分离等关键分布式能力， 能够很好地满足企业在 高性能、大数据量 等多种 业务 场景 。近年来，各国产厂商都在积极推进分布式数据库产品的研发，技术已经逐步成熟 。金融行业，作为数字化转型的先导性行业，对数据基础设施有着更高的要求。分布式数据库的出现，恰好可以满足金融企业迫切需求。随着近些年来，分布式数据库的成熟，并在 金融行业已有成功案例投入生产系统使用。 相信，两者的结合，必定在未来能擦出更多火花，促进金融行业在新时代转型发展。

至强傲腾分布式数据库选型

著作权归作者所有

如果觉得我的文章对您有用，请点赞。您的支持将鼓励我继续创作！