vlambda博客
学习文章列表

最近和朋友聊到分布式核心数据库的发展和应用情况以及人行发布的金融数据库规范标准，聊到早在2018年有一份《金融分布式事务数据库白皮书》，其中详细介绍了分布式数据库的发展趋势和必然性，本文就对这份白皮书做一次解读。

---

1、金融分布式事务数据库白皮书

1.1 分布式数据库概述

1.1.1 分布式转型的趋势

金融机构信息系统向分布式架构转型，有内在因素也有外在因素：

1. 互联网业务的爆发式增长导致当前的业务系统架构已经难以支撑海量数据实时服务和存储处理需求

2. 新兴互联网企业在集中式架构向分布式架构的探索中已经取得不错的进展，以X86服务器替换IBM等厂商小机以及EMC存储、以自研数据库替换Oracle等商用数据库，完成集中式向分布式架构的转型，并且可以支撑当前互联网企业的大规模、高并发和多模式的业务类型

3. 金融监管机构指明金融核心系统的分布式架构转型的方向，以信创和核心软件自主可控为目标，实现信息系统的架构转型

1.1.2 分布式数据库发展历程

来源：金融分布式事务数据库白皮书

分布式数据库发展主要经历4个技术阶段：

1. OLTP和OLAP分离阶段，联机事务型和分析计算型业务边界区分

2. 硬件提升带动数据库能力阶段，以大型机和小型机为代表的硬件处理能力的提升

3. 非关系型数据库发展阶段，以NoSQL为代表的非关系型数据库技术的发展

4. 分布式事务数据库发展阶段，利用已有非分布式计算和存储体系，横向突破单机的计算和存储容量限制

1.1.3 分布式事务数据库的核心属性和能力

分布式事务数据库具备3大核心属性和6大核心能力：

1. 3大核心属性：事务属性（ACID原子性、一致性、隔离性和持续性）、联机交易属性、分布式架构属性（计算和存储基于分布式架构分布于不同的节点上）

2. 6大核心能力：基于X86硬件标准实现、 满足事务ACID要求、支持高并发OLTP负载、原生的标准SQL支持、自动化故障自愈和高可用切换、跨中心站点级别的集群弹性扩展

1.1.4 分布式事务数据库的技术架构

分布式事务数据库有以下几种发展方向：

1） 基于单机事务关系数据库的业务分布式改造，即在应用业务层面建立数据分片和数据路由规则此类方式业务侵入方式较为严重

来源：金融分布式事务数据库白皮书

2） 基于单机事务关系数据库的分布式管理组件方案，也就是在计算层通过分布式中间件实现自动路由策略，并通过一致性方面的配套理论和算法，解决分布式事务一致性问题

来源：金融分布式事务数据库白皮书

3）分布式数据库理论和实现架构，由数据库驱动、计算节点集群、数据节点集群和全局管理节点组成

• 数据多副本存储在数据的多个节点上，数据节点之间不共享，由各副本之间通过一致性算法实现同步

• 计算节点负责分布式查询处理和全局事务控制，

• 全局管理节点维护分布式事务一致性以及维护各分区和组件之间的关系，管理元数据

来源：金融分布式事务数据库白皮书

1.1.5 集中式事务数据库与分布式事务数据库对比

集中式事务数据库与分布式事务数据库对比如下所示：

相较而言，分布式事务数据库在软硬件成本、扩展性和伸缩性上对比集中式事务数据库有很大优势；同时利用分布式架构的优势，在可用性和可靠性上也有足够的保障支撑，满足监管RTO和RPO要求。

1.2 金融行业事务数据库现状概述

1.2.1 金融行业业务需求分析

随着移动互联业务场景的发展及业务场景的丰富，金融行业在新形态下有新的业务需求：

1） 金融行业数据激增，对数据库存储和管理提出了更改要求

• 海量数据从TB级别增加到PB级别

2） 金融行业对业务连续性更加重视

• 灾备中心建设以及核心系统的双活建设

3） 面临高并发业务和高用户量带来的系统压力

• 互联网金融业务开展后高并发和高用户量带来的系统压力

4） 对移动应用响应速度要求更快

• 移动互联网业务需求下对移动互联应用响应到秒级

5） 技术层面的国产化需求

• 金融行业在技术上的国产化改造，对安全和稳定有更高要求

1.2.2 金融数据库系统现状及痛点分析

金融行业的数据库技术在几十年的发展过程中，形成了以集中式事务数据库为主的格局：

1） 硬件方面

• 大型机和小型机占有较大的市场份额

2）软件方面

• 各类业务主要运行在Oracle和DB2为主的商用数据库上

• 开源MySQL、PostgreSQL也在广泛应用于互联网核心业务和金融领域的外围业务系统中

3）新时代金融业务发展需求

• 弹性管理，当业务数据量增加的时候需要进行弹性的扩容

• 提升处理性能，针对实时业务和高并发场景，需要高性能的读写以及实时业务访问

• 可靠性能力，除了数据高可用，还有容灾建设以及数据中心的双活需求

• 多类型业务数据处理需求，对多模数据进行统一管理，从结构化到非结构化，进行不同类型数据的统一整合

• 增强开发运维能力，包括数据库运维管理能力以及简化运维开发

• 支撑核心业务的自主可控产品，对产品核心代码的控制力，自主可控以提升稳定性和技术支持能力

1.2.3 分布式事务数据库转型必由之路

与集中式数据库相比，分布式数据库可以实现数据非分散存储，将数据库的压力分散在不同的服务器上，同时可以实现交易均衡负载，并采用高并发的架构提升交易的处理能力。分布式数据库的几大优势如下：

1. 高性能：面对海量数据和高并发场景，能够达到数千并发、数万连接和TPS以及数十万的QPS

2. 弹性扩容：实现在线的扩容缩容以及弹性扩缩容

3. 多中心：单机房内的数据同步并保证一致性以及跨机房和中心级别的容灾方案

4. 低成本：国产x86服务器以及SSD存储即可满足硬件资源需求

5. 无绑定：没有严重的服务厂商绑定现象，应用选择权扩大

1.3 金融关键业务对分布式事务数据库的要求

金融分布式事务数据库技术标准共有50项技术指标，分为6大类：基本功能18项、兼容能力6项、管理能力14项、高可用能力4项、扩展能力4项和安全能力4项。

1.4 分布式事务数据库对金融业务设计的改变

金融业务架构从集中式到分布式转变过程中，底层的数据存储也从单节点变成多节点的分布式存储。因此底层基础设施架构的改变，对业务系统的设计模式和操作方法也会带来变化：

1）业务系统组件化、服务化改造

• 业务系统分层解耦，确定应用层、服务层和数据层的边界

• 对承上启下的服务层进行服务化改造，提供“去中心化”的服务调用

2）数据库模式设计，满足扩展需求

• 扩展性需求：数据分区，满足负载均衡、调度和扩展性

• 性能需求

• 数据节点数增加，结合数据常用的访问模式，准确的路由，减少二次分发路由的开销

• 考虑不同表数据的亲和性，将常一起访问的表数据放在一个数据节点，减少分布式事务访问

• 维护全局索引会产生分布式事务，对性能有影响

• 全局一致性快照：一条语句访问不同节点数据时候，这些数据能够在同一个快照点

3）数据库SQL能力评估及业务开发注意事项

• Sequence支持：部分业务需要使用sequence来生成记录的唯一键

• 强一致性事务及事务隔离级别支持：金融核心业务必须有强一致性的事务支持，通常是Read Committed隔离级别

• 复杂查询支持：分布式数据库优化器面对表联接以及复杂查询语句，能否将关联和计算下沉到每个数据节点，减少节点间的数据传输

4）容量系统评估及弹性方案

• 系统容量评估，以确定数据库系统的硬件资源需求

• 除了TPS/QPS，还有热点账号等关键特征

• 秒杀和双十一等流量峰值的弹性规划

• 扩缩容可以在线完成，不影响正常的业务运行

5）高可用及容灾方案

• 通过数据库软件来实现高可用，主流方案是多副本强一致方案，副本之间通过日志回放实现数据同步

• 单机房多副本、同城三机房、两地三机房、三地三机房等

6）系统运维方案

• 运维复杂度更高，尽可能自动化和在线操作

• 系统升级和系统备份等需要在线实施，不影响业务正常运行

• 分布式系统的问题跟踪更加复杂，业务设计中可以根据交易号串联整个业务流程

1.5 金融分布式事务数据库迁移策略

1.5.1 指导原则

金融分布式事务数据库从集中式架构迁移改造过程中，要基于可持续发展、透明开放以及代价可控原则。

1）可持续发展：当前分布式事务数据库还处于起步阶段，迁移过程中充分考虑分布式事务数据库架构的可持续发展，以满足中长期的发展需求

• 数据模型和核心功能架构先进性的可持续

• 数据库的工程化实现及运行架构的可持续

• 分布式事务数据库的跨行业、跨区域开拓的可持续

• 分布式数据库的许可模式、推广模式的可持续

2）透明开放原则：以透明开放的原则进行各种任务的规划和要求，保证透明和开放度

• 核心存储计算架构透明开放度

• 应用接口和API规范的透明开放度

• 底层部署和运行架构的透明开放度

• 扩缩容及变更运维平台/工具透明开放度

• 测试工具和用例的透明开放度

• 工具测可定制接口的透明开放度

3）代介可控原则：在对业务和系统的架构调整优化中，选择总体迁移代价最优的路线

• 应用适配代价

• 接口适配代价

• 基础设施资源支撑代价

• 运维管理基础设施调整代价

• 日常运维管理代价

• 变更和应急代价

• 人员能力掌握和维持代价

1.5.2 实施策略

1）知识传递先行：在实施阶段，首先需要执行知识的传递和转移

• 核心架构原理

• 应用适配

• 业务验证框架

• 评价体系

• 资源供给规划

• 容量和性能管理

• 实施和运行管理

• 故障排查和应急

• 日常运维管理手段

2）测试评估价值体系的建立：在实施启动前，需建立有效的测试评估评价体系

• 产品生态评估

• 产品成熟度评估

• 产品关键功能和企业级特性评估

• 产品性能和可用性评估

• 产品服务与支持能力评估

3）上线方案和上线实施：按照业务重要性、业务安全性以及流量压力，对自有存量和增量业务进行分级分类，按照一定顺序逐步验证实施分布式事务数据库

• 先增量后存量：先行替换试验，当满足业务需求以及人员熟悉操作方法和模式后，逐步对存量的核心业务进行替换

• 按业务性能瓶颈顺序：根据业务性能按照优先级顺序，逐轮进行流量切割处理

• 按业务不同的技术实现类型规划：不同业务种类如大并发事务类、大规模数据并行处理类以及大规模数据分析类，逐步验证分布式事务数据库能力

4）实施的阶段性计划

• 知识传递->业务适配验证及对接->评估评价和应用验证->实施方案筹措->上线方案和上线实施->投产保障支持->生产演练支持->实施工作交付与验收

1.5.3 典型问题和误区

1）转型过程中的应用过度适配和改造

适配分布式事务数据库的技术特性，如分布式事务控制、分布式数据库表关联以及一致性控制等，对应用进行局部调整。但过度的应用侧改造调整，降低了灵活性，耦合度的增加对整体扩展能力以及运行维护成本控制都有负面影响

2）使用旧管理策略约束分布式事务数据库

以整个分布式事务数据库集群的可用性作为核心指标，对于单个节点的故障应采取更加符合分布式事务数据库机制的运维管理流程进行管理

3）不重视基础网络环境建设

分布式事务数据库本质上是分布式计算与存储系统，对网络吞吐和网络延迟有非常高的依赖性和要求。

1.6 结论与建议

金融行业分布式架构转型是必然趋势，而分布式事务数据库是分布式架构转型的难点，因此需要金融行业、技术提供商以及学术界和研究机构一起建立标准、开展试点测试验证，完善技术生态圈。

1）建立技术标准体系，以标准带动产业，实现业务共识

• 新型产品技术要求

• 原有体系迁移规范

• 运维服务保障准则

2）开展技术试验与测试

• 当前的TPC-C性能测试不符合金融特征且功能单一，需抽象金融业务特征，依托金融场景构造自动化测试工具及体系

• 在金融机构开展试点

• 以实际业务为背景，开展新型产品真是环境验证试点工作，并总结梳理相关经验、共享成功案例

3）完善支撑配套体系

• 建立应用与服务融合新生态，打造互通平台、提高服务效率，完善应用开发、安全保障、运维服务等金融数据库业务配套生态体系

2、国内主流金融行业分布式数据库架构

1）数据缓存节点和数据持久节点结合

来源：分布式数据库技术架构及分布式核心功能的解读解密

• 架构分为：应用层、数据库接入层、数据缓存层和数据持久层

• 数据库接入层：数据库中间件实现DDL/DML/DCL/DQL全部功能

• 数据缓存层：负责单个数据分片内、单机多个数据分片以及多机多个数据分片的数据操作和事务控制

• 数据持久层：从数据缓存层将数据持久化到硬盘

2）计算节点和存储节点组合

来源：分布式数据库技术架构及分布式核心功能的解读解密

• 架构分成：应用层、计算节点和存储节点

• 计算节点：实现数据库服务端的全部DDL功能，还需要实现连接池、高可用、事务和死锁等功能

• 存储节点层：负责单个数据分片内的数据操作和事务控制

3）应用层和路由层耦合

来源：分布式数据库技术架构及分布式核心功能的解读解密

• 应用程序层借助驱动程序嵌入数据路由信息，实现简单的数据结果集合并

• 数据存储层的数据分片由应用程序控制，同业务逻辑耦合

• 数据存储层的高可用借助第三方组件实现

4）三种技术架构优劣总结

来源：分布式数据库技术架构及分布式核心功能的解读解密

像主流厂商GoldenDB和TDSQL等基于第二种技术方案实现的。

3、金融分布式事务数据库建设思考

1）金融分布式数据库生态的选择

来源：分布式数据库技术架构及分布式核心功能的解读解密

基于以上评分标准主流的厂商基于MySQL基础上进行自研和优化改造，比如TDSQL、GoldenDB、OceanBase等

2） 分布式事务数据库的扩缩容能力 在北京金融科技产业联盟编制的《分布式数据库金融应用评价模型》中，节点的扩缩容能力占比权重为50%，说明在分布式数据库功能中，扩缩容能力是一项很重要的考量指标，也是分布式数据库相较于传统集中式数据库的一大优势。

3） 分布式数据库集群处理能力 集中式数据库单集群可以存储几十T甚至上百T的数据量，在分布式数据库X86部署架构中以单节点500G存储为例，20T的集中式架构需要40台数据节点服务器，加上计算节点和管理节点，分布式架构单副本至少需要60台服务器。

4） 高可用架构对比

• 传统的集群式架构基于存储复制确保数据一致性，并且通过RAC架构和HA保证高可用

来源：光大银行分布式数据库的架构转型实战

• 分布式数据库高可用架构是基于多副本实现的，核心业务系统会建立3中心5副本

来源：中兴通讯GoldenDB在金融核心业务的应用与实践

从单副本的集群数量可以知道，5副本的集群需要的服务器将会是数量级的增加，随之带来的是集群服务器数量的庞大以及运维压力的增大。从各厂商在同业的建设情况，这些只读副本似乎也只是用作高可用的可靠性，并没有进一步用途比如读写分离以减少主副本的流量压力。而以计算节点+存储节点结合的架构，最后的读写压力都会加载到主库上。至于分布式数据库的同城双活也没有成熟的方案可以参考。

5） 分布式事务数据库运维

• 分布式数据库集群对机房、服务器、网络等硬件资源的依赖，增加了硬件成本

• 同一集群环境下几百上千台服务器实现端到端全链路的监控，不利于故障的定位和排查

• 缺少成熟的DBPAAS分布式运维管理平台产品，大部分不满足人行关于分布式数据库技术金融应用规范标准的要求，需要基于标准进行大量的开发和定制工作

• 开源MySQL和X86平台自身的缺陷，缺少更深层次的故障数据采集和分析数据的收集，不利于深层次的根因排查

• 运维自动化平台在核心应用投产时就位，否则会增加运维成本和压力

• 业务的流控和限流只能基于网关去做，分布式数据库或中间件本身并不具备该功能

其它有关分布式核心数据库运维的问题和困难不一一赘述了。

4、写在最后

从2018年4月《金融分布式事务数据库白皮书》到2020年11月26日人行的《分布式数据库技术金融应用规范》系列标准发布，国内的分布式核心数据库发展的是如火如荼，以中信和平安银行为代表的商业银行的核心业务系统也分别进行了分布式架构改造并成功投产。集中式数据库架构到分布式核心数据库架构的演进是势在必行，也是大势所趋。

下面是人行《分布式数据库技术金融应用规范》的链接，感兴趣的可以看看。https://www.cfstc.org/bzgk/gk/view/bzxq.jsp?i_id=1893

---

参考资料

1. 《金融分布式事务数据库白皮书》，中国信通院

2. 《分布式数据库技术金融应用规范》的技术架构及分布式核心功能的解读解密，HotDB数据库

3. 中兴通讯GoldenDB在金融核心业务的应用与实践，DCTT2020

4. 光大银行分布式数据库的架构转型实战，deeplus社区231期