浙江网商银行股份有限公司技术专家杨祥合：网商银行分布式数据库应用实践

下午好，我叫杨祥合来自网商银行架构部，过去没有分布式数据库的时候，业界往往用类似MYSQL这样数据库做分库分表，把一个大库拆成很多小库。通过分库分表提升我们数据库的扩展能力。当拆完之后发现主库和备库之间搭建master-slave的架构，当主库出问题，如果备库拉起来就会丢失(部分主库)数据。如果备库不拉成主库，就会损失新的业务。这样就陷入难以决策的麻烦。随着分布式数据库的发展，给了我们解决这些问题的方式。

随着移动互联网、大数据、云计算以及新兴技术的蓬勃发展，诞生了互联网金融，传统银行在往互联网模式转型。

网商银行在移动互联网、大数据、云计算等新兴技术之上服务于小微企业、三农用户、大众消费者以及中小金融机构提供普惠金融服务，我们建行之初提出了低成本、高可用、高弹性的要求，银行作为强监管行业，银监会和人行在不同场合提出了自主可控的要求，在这种背景下，我们使用了自主研发的分布式数据库OceanBase来作为我们核心的数据库。

先看一下oceanBase的核心特性，每年双十一大促是全民的双十一也是OceanBase的双十一，OceanBase去年的数据每秒32.5万笔/秒，这是从性能方面说。从单表数据量来看，单表数据量已远超过3200亿，3200亿是两年前的数据。

可扩展性方面，单机群达到百台服务器以上。每年双十一有可能建设新的机房，利用 OceanBase本身的弹性能力，把一部分数据弹到新的机房去。

在高可用方面，oceanBase是用Paxos协议，提供多副本的协议，RTO=0，RTO<30秒。高可用方面，给大家的感知就是我们的系统到底怕不怕挖掘机的问题。

(据媒体报道)6月2日，AWS(中国)中断了十多个小时。(网商银行)我们希望为用户提供高可靠的服务，那需要付出一定的成本，这个后面去谈。

我们提供了多租户的能力，前面几位老师提过不同业务之间担心相互干扰，多租户提供了这样的隔离能力。

易用性方面兼容MYSQL和Oracle语法，可以让应用免修改代码直接使用。许多现有业务，可直接运行在oceanBase数据库上。

从架构方面来说，OceanBase集群是分布式的多副本架构，我们建议使用三个副本以上，每个副本分布在一个zone里面，每个zone分布在一个机房里。对于金融行业来说，我们是这么看分布式数据库的，我们说它拓展了单机数据库的容量，提供了机房级、地域级容灾及异地多活等能力。

回顾网商银行的架构发展史，创新能力一直是网商银行架构发展的一个驱动力。在网商银行整个4年的架构发展当中，我们经历了数据库的版本升级、拆库拆表、秒级弹性数据源建设。很多时候传统银行要向分布式数据库上转型可能会面临着把单机数据库通过拆库拆表拆成成多个，从而提高极端情况下的可用性。对比传统银行有ATM，有物理网点，现在因为大家都有了随身携带的手机，我们希望网商银行手机APP能够为大家随时随地的7×24小时的服务，为了这个(目标)我们不遗余力。

网商银行的架构发展从5库10表发展到百库百表并且建立秒级弹性数据源，下面一起看一下。先说数据库的迁移和拆分，这个可能是传统银行要上到分布式数据库需要经历的，我们通过如上图一种架构，在我们内部叫OMS的一站式数据迁移平台，它具备的能力是什么？

当我们有一个老的库比如OB0.5，从老的库OB0.5迁移到OB1.0，我们一定想使用生产数据做验证、生产的流量做验证，因为线下人力测试验证远远赶不上线上数据真实而且复杂。在这种情况下，我们通过分布式的数据访问组件或者数据流量录制能力把流量录制下来，把流量转发到双写测试库当中，双写测试库是一个1.0的库。通过这样的验证知道SQL性能是否OK和语法是不是兼容。

在迁移切换中有增量全量同步并且提供秒级数据校验，分钟级切换和回滚，整个过程一键完成，通过OMS平台构建了异构数据库之间进行互相迁移。

去年做的第二个创新点，上了秒级弹性数据源，当一套数据库集群不能满足我们要求的时候，我们想着加更多数据库集群上来，网商银行实现了在一个应用数据源上挂多个数据库集群。我们实现了最大一百个数据中心同时为提供服务，任何一个业务都可以跨100个数据中心，这就是我们架构创新带来的扩展能力。

通过这样一个能力，比如我们的生产库如果耗时达到一定的阈值，会自动切换到新的FO(故障切换)库，是实现了不同数据库集群自动化容灾。(尽管分布式数据库足够稳健)，这是在非常极端的情况下数据库出现问题会自动帮你完成切换。

前面谈了我们在分布式架构上的创新，不同的分布式数据源为用户提供了高可用的服务。现在谈谈三地五中心，我们三地五中心加分库分表分集群的架构设计目的不仅对抗挖掘机(挖断单机房网络)而且对抗城市级故障。一个城市出了故障之后我们不希望用户感知到，希望把它消化掉，所以我们在三个城市建立五个副本这样的能力。

接下来我们谈谈逻辑架构，我们的经验是分库分表分集群在分布式数据库时代依然是需要的。

分布式数据库集群也有很多内部事件、外部事件，内部事件，比如说数据库集群有可能存在累积性的问题，或者内部的定时任务，还有一些自动维护性的操作; 外部性事件比如集群要灰度、版本要升级、还有备份，每天跑的全量备份。另外三地五中心，分库分表分集群，对我们单元化构建异地多活的架构，也是非常重要的，因为异地多活之后，比如全国有10个机房，我们可能会在不同机房里边分配不同的集群，每个集群都是三地五副本的。

网商银行的架构发展从原来的两地三中心发展到现在的三地五中心，我们就是想解决城市级故障，大家都说城市级故障概率很低，我们不这么认为。我们觉得三地无副本的成本投入是对用户体验的极致追求，对银行信誉的极度珍视，这才是我们认为有价值的地方。

给大家看一下我们数据库redolog在异地多活是怎么跑的，我们看到003区主在IDC机房，这个主同步到IDC 2、3及其他的节点；看到31号分库的主在IDC 2; 99分库在IDC3机房，通过交叉部署提供机器资源利用率降低了成本。

一起看下逻辑架构的示例分布图，我们采用分库分表分集群，每个集群都可能会做灰度升级、变更。通过表级别看，红色是表的主节点；每个集群里边承担不同数量的表；多个集群共同支撑业务流量。

（编辑：厦门网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!