（杨祥合 北京奥星贝斯金融行业解决方案架构师 & 北京金融科技产业联盟专家）

        近关于金融级数据库的话题，行业内讨论热烈。在这方面我想抛砖引玉，分享下自己的观点。

10多年来，我一直在分布式数据库领域探索实践，从DBA到架构师工作经历可以分为两大段。段作为数据库管理员，我参与了阿里 “从Oracle到去O”的工作，通过了Oracle 10G OCP和11G的Specilist的认证，在阿里参与Mysql去O、并与分布式数据库OceanBase结缘，是OceanBase批DBA，从OceanBase 0.3版本开始使用，从此迈入原生分布式数据库行业。第二段作为数据库及存储架构师，我从0到1建成了浙江网商银行的数据库存储架构，七年时间建成多地多活、单元化、云原生、国密密态的银行，其中多地多活的单元化方案获得2019人民银行金融科技发展奖二等奖。

多年来，基于技术和产业一线的工作经验，作为核心作者之一，我参与编写了架构畅销书《金融级IT架构-云原生数字银行解密》。恰逢金融行业数字化转型的浪潮，心中燃起服务金融行业的执念。2021年底来到奥星贝斯（OceanBase），聚焦服务金融行业客户。

1.多副本实时同步，不仅满足金融业务数据一致性的要求，而且带来更高的性能。

1.一致性协议是分布式数据库发展的必然

中国信通院《大数据白皮书2018》(第11页)指出“一致性协议的诞生为分布式数据库发展铺平了道路”，并明确列出事务型数据库架构演进图。

这份白皮书中明确了一致性协议对分布式数据库的重要意义，同时指明了原生分布式数据库是必然方向。换言之，真正的分布式数据库一致性协议是标配。

(1)传统的主备数据库，在PC服务器上面临数据丢失风险

• PC服务器稳定性比大机、小机低: 金融行业从手工记账走向金融电子化，30年来享受了大型主机、小机的稳定的硬件发展的红利，而今，PC服务器的宕机等故障概率高很多，个别从业者未充分意识到服务器稳定性变差带来的影响。
• 数据库主备模式，解决不了“脑裂”及RPO=0的问题

在数据库的主备架构下，在主备强同步(大保护)模式下，会出现故障数翻倍，因为主库或者备库故障都会导致主库停止服务；在大可用模式下，如果主备之间网络故障不是原子性中断的，而是先出现延迟，后彻底中断，此时大可用先降为大性能，然后主库不可用，此时数据丢失。而这种场景在故障中占多数，比如机房进水、起火、交换机光模块损坏等等，故障不会是原子性的。

换个角度看这个问题，如果主备模式能保证数据不丢，为什么一致性协议备受重视。Google Chubby的作者MikeBurrows说“这个世界上只有一种一致性算法，那就是Paxos，其它的算法都是残次品。”

• 磁盘固件门及各类静默错误的新挑战:

一些新问题的出现需要用技术去面对、去解决，用今天的眼光去看，传统数据库主备架构、Raid冗余机制对冷数据的磁盘静默错误。

• 2018年，一家企业“前沿数控”的数据在国内某云上全部丢失，将磁盘静默错误推到风口浪尖。
• 2021年，FaceBook的论文《Silent Data Corruptions at Scale》，CPU静默错误已成为行业公开的秘密。

(2) 金融级分布式数据库的坚守:

创始人阳振坤老师很早前曾说过“数据一致性是OceanBase的生命线，宁可少做几个功能，也要确保数据一致”。今天回头看，数据一致性的五道防线深入内核层，成为该领域新的制高点。只有地基打的牢，楼才能盖的高，正所谓“根深叶茂”。

五道防线:

1. 一致性协议Paxos：保证事务发生时数据一致性。
2. 链式交叉校验：宏块、分区等多重校验和构成校验链;全局索引和数据交叉校验;二进制和数据双重校验。
3. 集群内多副本之间一致性校验: 每日合并时自从触发校验
4. 主备集群之间的数据一致性: 用于同构容灾、异构芯片混合部署
5. 冷数据定时扫描: 发现数据中的错误，如: 磁盘的静默错误等

2.分布式数据库创容灾、性能的佳绩

(1)“三地五中心”的浙江网商银行2022年双11大促全链路联合压测中，性能的容量是国内多家使用大型主机的银行的性能之和。

在《金融级IT架构》一书中披露过，浙江网商银行是“三地五中心”的架构，具备全行业务多地多活的能力，即城市级故障30秒自动恢复、数据不丢。根据一致性协议(多数派协议)，5副本下至少要写成功3副本，即需保证每个事务跨城市写成功。相邻城市之间的距离200多公里，第3城市1000公里以上。每个事务增加6~8毫秒，即commit语句增加6~8毫秒，DML语句性能不变。

(2)2019年人民银行科技发展奖二等奖

网商银行以“三地五中心、多地多活的单元化架构”，获得了2019年人民银行科技发展奖二等奖，项目名称《网商银行持续演进的云单元技术架构体系》，核心特点是性能、容灾两个都要。分布式数据库OceanBase承载着全行的业务基石，而一致性协议是分布式数据库的基石。
从这几点来看，有人认为“OceanBase节点间实时同步，对任何同城超过50公里以上的机房间，基本也不适用”的逻辑，与包括浙江网商银行在内的众多OceanBase实践案例不符，与人民银行科技发展奖中的价值点-性能与容灾兼顾的逻辑不符。

3.数据库行业的国际权威测试

TPC-C交易型数据库的榜单上，OceanBase世界；如果有更好的实现方式取代一致性协议，那必然有另一款产品取代TPC-C世界的位置。

综上，一致性协议(多数派协议)是分布式数据库的根基，中国信通院的大数据白皮书、Google Chunby的作者都给予了肯定。从性能角度，浙江网商银行多地多活的高容灾&高性能兼具，数据库权威测试TPC-C中世界排名的成绩，给予了有力佐证。

2.分布式数据库，面向主流硬件设计、多样化的部署方式是行业的要求。

(1)主流通用PC服务器机型具性价比

从PC服务器的硬件发展来看，主流机型是性价比高的，因为其单位功率的电力可提供更高性能。例如，今天我们买电脑不会买赛扬1.0，而会选择I7、I5等这样的电脑。因为主流机型提供更高的性能。在同等算力下，大幅减少机房、机柜、网络等的占用。

如下是，常见主流机型，非小可用机型。

不仅支持主流机型，而且支持老旧机型与新机型的混合部署，充分考虑到新老服务器过保的情况。例如，浙江网商银行3年、4年前的机型可以与新机型一起在同一个OceanBase集群上提供服务。

(2)分布式数据库的硬件目标是充分发挥主流服务器硬件能力

OceanBase有效利用大内存是"浪费"内存吗？

要充分利用主流机型的能力，数据库内核就需驾驭超大内存管理能力，这恰恰是完全自研数据库的强项。Oracle在一台服务器上部署一个实例可以将资源大化利用，而Mysql在行业里很少有一台物理机只部署一个Mysql实例的情况。根因是Mysql多核能力以及大内存利用能力要弱一些。从行业部署现状来看，国内使用Mysql的方式，无论单独的使用，还是做成分库分表的体系化部署，都使用单机多实例的方式，一台物理机部署多个实例成为"常态"，重要的原因是CPU、内存利用率差；

新技术用内存换磁盘IO提升生产力。BloomFilter(布隆过滤器)用内存容量换取静态数据的磁盘访问，无论select、insert、update、delete语句都有一个"查询"的逻辑，查询下数据库中究竟有没有符合条件的记录，如果没有记录，就无需实际去执行磁盘扫描。这在传统数据库上是难以实现的，因为持续不断地将修改过的“脏”数据页刷新到磁盘上的逻辑，数据一直在变化。因此，需客观看待技术创新带来的价值，因循守旧、抱残守缺不会成为主流。

LSM能够成为热门架构，其适应时代发展、解决了行业痛点。Google基于LSM架构做成了大名鼎鼎的分布式存储BigTable，OceanBase基于LSM架构做成了分布式数据库登顶TPC-C世界。这12年来，伴随CPU多核、固态SSD的盘的应用，其LSM架构将传统数据库的随机写变成了顺序写，解决了传统数据库在固态盘上的写放大问题。

• 因为LSM架构，随机写转顺序写，磁盘的寿命大幅延长，为客户节约大量磁盘固态成本。
• 因为LSM架构，分布式数据库的压缩比5:1 ~ 10:1之间，对业务性能几乎无影响，降本增效明显。

• 生产服务器的存储空间1台抵传统数据库的5台
• 大幅节约备份恢复的时间，备份时间是同等数据量的mysql、postgre等的1/5 ~ 1/10，提高了备份的恢复效率

从应用范围来看，LSM 被很多存储产品作为存储结构，比如 Apache HBase, Apache Cassandra, MongoDB 的 Wired Tiger 存储引擎, LevelDB 存储引擎, RocksDB 存储引擎等。

换个角度来看，如果LSM架构存在重大缺陷，你如何看待行业中LSM架构的产品百花齐放。Google的BigTable成为分布式存储领域的经典，OceanBase创造TPC-C的世界记录...

(3)OceanBase数据库支持多样化的部署方式

• 部署方式支持，物理机、裸金属服务器、国内和国外主流云厂商的云虚拟机或者容器化部署。
• OceanBase可支持国内外各种PC服务器，不存在指定的服务器的情况。因为金融行业客户有各种各样的场景 a.有传统的非云环境--基于物理机部署

b.有混合云部署--上云的过程中，会有云上和云下共存阶段、一个企业因业务用途不同而存在多云环境

(4)万兆带宽是目前行业的主流

1.从业务发展的角度，金融科技已步入4.0时代，也就是数字化时代，数字经济、数字金融、数字政务治理等成为热门，意在通过科技赋能提升经营质效。

2.从技术发展的角度，应用的分布式带来了云原生、微服务化，数据库的分布式带来原生分布式数据库。无论应用还是数据库的分布式客观上都会增加网络占用。那我们会不会因噎废食，从云原生、微服务的架构转回到大单体架构呢？显然是不会的。 因为技术的潮流奋勇向前、不可阻挡。

• 云原生、微服务增加了网络带宽、增加了链路耗时，但是带来业务的敏捷性。
• 分布式数据库带来了架构的无限扩展、超强的容灾能力，带来更好的业务连续性。

无线互联网都已经5G时代了，几年前，云厂商100G网络已经试点应用，如果还用100兆带宽，交换机坏了都没地方买；中国电信、中国移动等的千兆网络进家门，当家用网络已达千兆，金融行业万兆网络要求高吗？“东数西算”推动我国新型算力网络体系构建，打造高速智能网络是基础。2022年9月，打造高速智能网络，中国移动联合中兴通讯完成了全球400G QPSK准实时系统模拟现网真实参数传输验证; 5G技术的诞生和应用越来越热门。网络带宽越来越宽是必然趋势，作为IT系统底层的数据库，应该更好的更充分的利用高速网络、多核CPU、超大内存、固态硬盘等等先进的硬件，而不是相反。周小川先生讲“金融业是半个IT行业、数字金融是现代金融业发展的重要特征"，作为金融行业的从业者，应积极拥抱IT技术的发展，为行业创造更多价值。

(5)OceanBase使用的服务器多吗？

在某省的两个同等规模城商行，同一家核心系统开发商的V8版本，使用OceanBase的用了18台机器，使用某分库分表数据库的用了35台机器，经行里沟通压缩到30+的机器。

3.部署架构

支持一致性协议的数据库部署方式基本一致的。

3.1 双机房主备集群

主备集群的部署方式，每个集群部署在一个机房里。

3.2 同城三机房

3.3两地三中心3副本

3.4两地三中心5副本

3.5三地五中心5副本

4.备份恢复

1.备份恢复的效能提升

• 目前OceanBase的生产版本是3.x，备份恢复的运行机制类似Oracle的RMAN，是物理备份；早在多年前的2.2.5版本开始采用物理备份，之前是静态数据逻辑备份+ 日志近备份运行机制。
• OceanBase的所有客户均开启了压缩比（一般在5:1~10:1之间），因为压缩对对性能几乎无损，相较传统数据库架构如mysql、postgreSQL，同等硬件下备份恢复时间是其他的1/5~1/10。
• 备份恢复没有任何第三方依赖组件，白屏化配置和管理。

2.恢复性测试白屏化

• 为了保障备份真实有效，恢复性测试成为必需品，白屏化的备份恢复性测试，让备份更加安全可信。

5.OCP管理平台

当一款产品从内部走向外部，简洁易用是基本原则，分布式数据库的复杂度比单机数据库或者基于分库分表的开源魔改库要复杂。此时，“将复杂留给自己，把简单易用留给客户”尤为重要。多年的内部实践经验，优选有效、常用的监控指标展现，这是产品易用性的体现。

OceanBase的CEO杨冰2021年说“过去一年OceanBase客户数实现翻倍，达400多家，客户数有目前Top 200的头部金融机构中有1/4都将OceanBase作为核心系统升级”。从金融到能源、电信，再到国计民生的各个通用领域，OCP管理平台始终守住OceanBase内核的状态，为客户提供集群管理、功能监控、告警等需求。在银行业，从国有大行到中小规模城商行、农商行等，满足通用需求。

从OCP发展的历史来看，从阿里到蚂蚁在内部打磨了10多年，从黑屏到白屏、从功能简陋到繁盛，再到简约的过程。商业化之后，倾听客户的声音，易用性、功能上持续加强。如果有个性化需求反馈，一定能够听的到的。如果是极为小众的个性化需求，大量内部表统计信息的收集，这是原生分布式数据库的巨大优势。作为分布式一体化的设计，大量的监控指标使用内存指针计算的方式(实现方式与Oracle的动态性能视图类似)。

1.监控层面

以客户为中心，通过分类分级，展现关键指标，隐藏次关键指标，选中即可展现。请注意【指标选择】

2.架构层面--融入全行一体化治理体系中

OCP是OceanBase管理平台的简称，作为全行一体化治理的一部分，因此API开放的较为全面。

https://www.oceanbase.com/docs/enterprise-oceanbase-ocp-cn-10000000000379276

6.每日合并

1.数据合并是数据持久化的需要

数据落盘是数据库中数据持久化的保障，其必然占用数据库资源，这个过程在LSM架构数据库是数据合并，在传统B+Tree数据库中是近实时的异步刷盘。LSM和Btree各有优势，其中LSM架构优化了写操作，对海量数据写入性能远高于Btree的写入。换言之，LSM架构将磁盘的大量小块随机写入转换为大块的顺序写，大幅提升了磁盘寿命。

2.数据合并对性能影响

以某商业银行的核心系统做性能测试，500并发情况下，做持续性压力测试，检测每日合并中业务影响情况。

• 集群架构: 主集群3-3-3，备集群:3-3-3，主备集群之间大保护模式
• 硬件配置: 主集群为 512GB内存 * 64核 * ARM架构，备集群内存小一点
• 每日合并配置: 合并线程数10，开启轮转合并

每日合并效果汇总:

这里对业务的正常运行是无损、无影响的。

每日合并影响大吗？

即如何理解，每日合并对业务的影响？有人认为，每日合并就不符合金融级交易数据库的标准吗？

当然不是。相较于主备模式的数据库，OceanBase的机器资源利用率是翻倍的，举个例子。

先假定没有资源瓶颈的情况下

1.传统主备架构的数据库，因为备库所在机器资源闲置，资源利用率50%；分布式数据库资源利用率。

2.当每日合并发生时，分布式数据库从3个Zone提供服务变成2个Zone提供服务，利用率66.7%。

3.当OB4.x推出租户级的合并后，机器资源利用率接近，因为不同租户可以错开合并时间。

上述是极限值，实际客户现场要求的性能来看，15.7%的影响背后，其实是机器资源利用率的大提升。分布式充分利用多台机器的CPU和磁盘IO能力，并将单机的业务集中度降到低，即单机故障影响面降到低。

从上面表格中可以看出，”3分钟下跌"其实并非真正下跌，而是租户切主的过程，即回话从一台机器转移到另外机器需要的回话转移过程对新老回话做的阻塞动作。也正是这种处理让单位时间的处理能力有了凹槽，伴随后续版本迭代，对业务的影响将越来越小。

正如我们对单机故障的RTO时间一样，3.x以前是30秒恢复，4.X后，8秒恢复。

2.金融行业的业务都有业务低峰，银行、证劵、保险、基金、期货、信托等等皆是如此。

从业务实践中看，每日数据变化量在5%左右，在这样的情况下，数据库的每日合并甚至不需要配置轮转合并，即使高峰期合并业务TPS几乎无影响。在浙江网商银行的线上库，错峰合并和直接合并都存在的，将直接合并作为主要的合并方案。

3.会话迁移能力分布式数据库都需要

业务高峰期切主节点，就需要会话的迁移能力。从会话迁移的角度看，无论是Btree的数据还是LSM架构的数据库都是需要的，实现机制基本一致的。也就是说，只要是分布式数据库做会话迁移，都会存在处理能力下跌的情况。伴随技术发展和产品迭代，这种会话迁移的影响越来越小。

7.金融行业分布式数据库转型路径

从目前的数据库实践来看，这款原生分布式数据库在金融行业走出了四条快速转型的路径。

1.条路线，应用不动、Oracle平滑迁移

平滑迁移是更快的转型升级路线。某国内头部保险公司，创造了分布式数据库转型中“速度快、范围广”的转型案例。

关键特点:

• 从覆盖范围上看，数百套Oracle集群，近千个数据库，涵盖全部业务系统。分布式数据库转型一步到位，决策者有着敢为天下先的胆识，而对被选中的数据库厂商而言，是一种莫大的信任。
• 从转型速度上看，12个月内完成近千套数据库适配、迁移割接上线，需要厂商具备丰富的异构数据库升级经验。从这个角度，可以认为这个项目是多年去O、去M项目经验的积累成果的一次验证。
• 从转型的复杂度上看，500万行的存储过程、强依赖PROC*C和Tuxedo等条件下，在深度依赖这些Oracle特性下，业务代码零改动，对数据库兼容性要求是极高的。

价值:

1.从转型路线上看，依赖Oracle语法的头部金融机构通过国产原生数据库转型升级，牢牢掌控数据库下游升级的节奏，同时解决了芯片的选择问题，这对金融同业有较好的参考价值。

2.从数据库产品角度，Oracle语法的全面兼容、“一库多芯、数据自校验”的产品能力、历经几十万次验证的迁移、校验一体平台OMS等，对国产数据库行业的发展有借鉴意义。

2.第二条路线，小机DB2的应用迁移到Oracle模式，实现“单核异构、双逃生”

严谨的方案是更快的转型升级路线，在华中某城商行新一代核心系统2022年上半年在银行核心和村镇银行的多法人核心全面上线。

该行从2018年10月开始使用OceanBase，从客户、账户、权益、交易等业务中台开始使用，3年的持续稳定。2020年下半年开始启动新核心建设，该行有银行和村镇银行两套核心，涉及多法人主体。

特点:

总体来说，前瞻性、多重容灾、超强逃生的能力，实现了业界新高度。

1.单核异构实现双逃生: 一套核心系统应用同时跑在DB2和国产数据库OceanBase上，因为这两个数据库都有Oracle兼容模式。背后的意义是，实现了国产、国外数据库的双逃生。

2.异构芯片混合部署: 一主拖两备集，一套备集群作为超远程热备集群，一套是国产 ARM 芯片、操作系统混合部署。利用数据库主备数据校验机制，验证数据一致性。为二阶段实现集群内异构芯片的混合部署，做好准备。

3.透明加密试点。异地机房开启了透明加密的加密区，实现了加密区和非加密区的混合部署，为后续全集群开启透明加密做了准备。

4.同城双活5副本: 不仅可容忍任意机房级别的故障 或者任意的两个Zone同时故障，如果机房3的距离较远，在机房1故障后，可以选择性的从5副本降为3副本，此时，只要实现机房2的2个副本写成功就可以提交。有效降低己方故障时的耗时，提升业务的性能。

3.第三条路线，大型主机DB2一步到位迁移到分布式数据库+单元化方案

一步到位下大型主机就是更快方案。在某国有大行贷记卡核心从大型主机DB2上，一步到位下移到分布式数据库上。

贷记卡核心一步到位迁移到分布式数据库上来，其重要意义如下:

1.对客户和ISV

• 信心提升：证明了贷记卡主机下移是可行的，OB+云能够承载大行核心系统，未来可期
• 认知提升：从“国外集中式架构佳实践”到“云+原生分布式库”的转变，并在容量、容灾、成本及弹性伸缩方面有非常大的优势
• 技术提升：从单元化多活到数据库，IAAS，PAAS中间件等有深入了解，并组建了上云团队

2.对生态ISV

• 产品力提升:单元化多活成为ISV的产品竞争力，如*阳、*亮科技形成“业务能力+单元化”双强
• 协作信心: 与OceanBase及云生态的“深度融合，非强绑定”，形成合力

3.对内

• 打磨产品：SOFA注册中心、Café、RMS、odp、ob，诺曼底、ACK、ECS，能用上的都被打磨了
• 新的篇章：云+OB全家桶国有大行核心大机下移的案例，具有标杆意义和示范效应
• 部分金融行业客户已经使用Mysql的情况下，转型到分布式数据库，可以选择OceanBase的Mysql模式，像使用单机数据库一样享受分布式数据库的扩展性、容灾、以及安全性等。

4.第四条路线Mysql平滑迁移

部分金融行业客户已经使用Mysql的情况下，转型到分布式数据库，可以选择OceanBase的Mysql模式，像使用单机数据库一样享受分布式数据库的扩展性、容灾、以及安全性等。

8.数据库的金融要求

金融行业数据库的需求层次

上面一行，从全行架构角度，

1.业务连续性是根本要求，数据库/应用的双活/多活应该是标配

• 浙江网商银行三地五中心、多地多活的案例，目前是国内全行业务多地多活案例。
• 从国有大行的单元化、到多家城商行双活的银行核心系统案例，已经上线。

注意:这里多活是指互相之间数据不丢，数据库、应用服务可接管，不是把数据简单拆分。

2.业务的敏捷性、安全性是业务发展的要求，微服务、云原生(双Mesh)带来业务的敏捷性，透明存储加密、透明传输加密带来数据的安全性。

具体下来，分布式数据库应有能力TOP 10:

洞察分布式数据库的行业，后以三个观点结束本文:

1. 纵观数据库发展的历史，终会剩余3~5家数据库，所谓“剩者为王”。
2. 技术创新是数据库厂商的核心竞争力，开源拼凑可以带来利润，长期很难走远。
3. 金融数据库的性能高低看两个点，一看核心系统的客户的性能，同等规模银行的核心系统性能如何。二看，数据库行业的权威测试排名。前者是已知业务场景，后者为银行后续新业务系统做参考，尤其在银行业4.0阶段，业务的范围和种类不断拓展，如全场景金融、全供应链金融等是这两类。