背景

金融系统信创进入深水区，在国产数据库百花齐放的势头下，选择集中式，分布式已经成了关键性问题，无论选择哪种数据库，只有合适就是最好的，结合前期在金融业务信创数据库项目案例，聊一下金融核心系统分布式数据库实践，分布式数据库宣传中一定会强调的优点，例如性能优越，可横向扩展，高可用，金融核心业务目前主要是运行在集中式数据库，迁移到分布式架构下，需要应用厂商做好适配和优化，金融核心业务并发高，延迟要求低，传统柜台属于集中式架构，委托时延在毫秒级别，迁移到国产分布式数据库需要从数据库架构设计，调优及业务适配改造多方面关注。

技术

金融核心业务数据库改造到分布式架构，无论数据库处理性能，系统容量及安全要达到核心交易要求标准，力争各项表现优于集中式，所以涉及到硬件规划，数据库架构及结合业务进行数据库层的优化。

架构设计

数据库作为核心部位，架构设计要从安全和性能双重考虑，安全方面，以OceanBase分布式数据库为例，核心交易可以采用双中心主备集群架构，大中型券商主备硬件按1:1比例设计，小型券商备集群可以单点方式进行，主集群可以按3副本设计，更高级别的采用5副本，主集群单节点故障，OB3.X版本RTO<30秒，OB 4.X版本<8秒，RPO都为0秒。

硬件规划

目前核心交易数据库硬件以小型机或PC为主，迁移到国产服务器前，要做好国产服务器资源规划，前期对IOE环境下主机CPU，内存，TPS，存储容量做好调研，获取的数据对服务器资源规划，数据库租户资源划分都是重要参考依据，涉及到芯片类型选择上，在国内信创服务器领域，以海光为代表的X86架构和以鲲鹏为代表的ARM架构占据了绝对的份额，两者在指令集，功耗，性能存在差异，目前金融信创案例，也集中在两类CPU上进行选择。

数据库层优化

业务改造重点要考虑性能因素，核心交易对于时延要求非常高，分布式数据库不同体现在数据分布差异性上。集中式数据库也要关注数据的分布，数据库表的高水位，碎片等也是会引发某些业务性能问题的主要因素。因此集中式数据库中出现了shrink,move等功能，用于处理这些数据分布的问题。到了分布式数据库上，数据分布问题就更为复杂了。在使用分布式数据库的时候，表设计规划需要考虑分布式数据库特性。哪些表采用非分区表单副本leader存储，哪些采用分区表leader随机分布发挥分布式性能，哪些表是要采用复制存储的，都是在应用开发及改造阶段需要考虑的。

分布式存储往往都是业务的核心表，数据量大，读写频繁，可以通过某个键值把数据打散在分布式数据库的多个节点上，充分利用分布式可扩展能力不断扩展，例如按客户编号做hash分区，实现数据库层多分片负载，利用分布式特性提升交易性能，但是分区数量要结合cpu核数来规划，一般不超过租户CPU数量两倍为宜。

分布式数据库和oracle一样，都会害怕错误的执行计划，例如远程，分布式计划会对sql执行效率产生影响，以OB为例，我们通过表组，二次路由相关特性能够减少分布式带来的‘副作用’，对于业务逻辑大量需要多表关联的场景，读多写少的场景，可以创建成复制表，减少远程RPC，通过分布式数据库自有特性，来减少非必要的分布式执行计划。

总结

金融系统数据库采用分布式能够降低硬件成本，无需采购昂贵存储和小型机，并且能够获得弹性扩展能力，结合恒生UF30应用微服务架构，能够实时扩展交易容量，提升交易性能，分布式高可用能力为金融核心业务提供更好安全保护。