网商银行数据库迭代记,OceanBase助力金融创新实践-阿里云开发者社区

开发者社区> OceanBase> 正文
登录阅读全文

网商银行数据库迭代记,OceanBase助力金融创新实践

简介: 2020年12月21日第十一届中国数据库技术大会(DTCC 2020)于北京如期举行,网商银行架构师,存储底盘负责人杨祥合先生,在 “OceanBase 企业级分布式数据库实践专场” 分享了《网商银行分布式数据库应用实践》的演讲,本文为演讲实录

2020年12月21日第十一届中国数据库技术大会(DTCC 2020)于北京如期举行,网商银行架构师,存储底盘负责人杨祥合先生,在 “OceanBase 企业级分布式数据库实践专场” 分享了《网商银行分布式数据库应用实践》的演讲,以下为演讲实录:

随着数据量爆发,业务日益复杂,现今 IT 环境中面对的场景复杂度和故障率也越来越高,甚至在国内出现了多起数据安全“黑天鹅”事件。以下分享将以网商银行的架构历史演进和对数据库的应用徐徐展开,以期给诸位带来启发。

网商银行架构史,斩获人行科技奖

网商银行是一家以普惠金融为使命的互联网银行,业务主要面向三农和小微企业。技术底盘架构在蚂蚁金融云和 OceanBase 上。作为 OceanBase 服务的第一家银行,网商银行对高并发、扩展性、数据一致性的需求一开始就存在。而在数据库选型的过程中,首先考虑的是高可用和高弹性,其次是低成本和自研。

我们先从存储架构和数据库版本两个方面来谈谈网商银行的发展史。

存储架构方面,从最初的两地三中心,到后来从 OceanBase 0.5版本升级到 OceanBase 1.0版本,实现了三地五中心的单元化。“三地五中心”,即在三座城市部署五个中心,一旦其中一到两个中心发生故障,甚至一个城市出现问题,业务都能够在 30 秒内自动恢复。

2019年,将 OceanBase 在高可用、扩展性用于混合云架构,在做多云架构时,面对不同业务目标的多朵云,可以一键将数据扩展到另一朵云上。2020年,开始落地云原生架构,配合全栈加密,从用户数据进入到服务的全过程,整个生命周期数据传输加密,落在磁盘上的数据都是密文。

在数据库方面,网商银行基于分库分表的数据库架构,从设计之初就设定单元化的目标。使用分库分表多集群,解决了库设计上的单点问题,数据库的升级、备份等在不同集群之间错峰进行,避免影响全局。

1.png

网商银行架构师,存储底盘负责人杨祥合

网商银行到底有怎样的技术实力?这在网商银行成立之初,就在行业中引起了热议。当时我们做了一个勇敢的决定,在生产系统中来一次断网演练。当完成了相关的报备后,我们就正式开始了这次断网演练,直接把生产系统中其中一个机房的流量全部断掉。让行业震惊的是,网商银行用了不到 1 分钟便实现了快速恢复,这背后其实充分体现的就是 OceanBase 的高可用、快速恢复的自治能力。

整个三地五中心异地多活的项目落地之后,我们把项目上报到人行,该项目最终获得了人行科技发展二等奖。实际的生产环境中,网商银行利用人行的窗口,定期做断网演练,这是发现自身问题的重要举措。

网商银行架构一览,从分库分表到批场景

OceanBase 不只是数据库,云原生架构之后,可实现链路加密,在 ServiceMesh 做加密,数据库做解密。目前,网商银行数据库集群规模 100 多套,数据量达到 PB 级。在线库和历史库架构中,历史库访问量较低。云原生微服务起来后,数据库、业务系统不断被拆分,需要下游的核心能力,包括建立一些基于 AI 能力的加持。

在分库分表方面,网商银行采用分区架构,在生产实践当中,有热点库、热点行、热点表等挑战,这些热点利用分区的能力,每一个分区独立到一台机器。

银行业务中的海量数据的处理方面,数据库设计是每批次并发处理 13~130 亿。具体逻辑为,每个批次查询 5000-100 万条,单表拆分片数 13 片到 2600 片,按照这个逻辑,网商银行使用了 999 分片,最大每批次可处理 130 亿账户。

批场景中,利用分库分表的基础上,使用表分区提高并发跑批能力。如银行工资代发、团体险等需使用表分区的能力,如企业人员导入,原本一个单表导入做成多个分区,把不同的数据打散不同的分区上提升性能。

业界有厂商宣称,库高可用是人为切主对业务无影响。我们认为应增加主库宕机 1 分钟内自动恢复,且数据保持一致的要求。网商银行数据库的标准是在此基础上,两个机房同时故障,也能够达到 RPO=0、RTO<1分钟。

金融业选型建议,从数据库到历史库

数据库选型,性能隐私双保险

一是主备模式不适合金融高并发场景。主库出问题需层层上报,强拉备库为主会丢数据。如果采用强同步模式,经测试性能会降 10 倍,这种性能下降是无法接受的。

据中国信通院发布云数据库标准选型建议,一致性协议应该成为金融数据库标配。高可用架构=快速恢复+最小影响面。快速恢复依赖一致性协议的加持。最小影响面分横纵两个纬度,横向拆分成多个集群、做分库分表和表内分片,纵向拆分成多个机房,让不同范围的用户编号进入到不同的机房,这样单机房/单个分库的故障影响面影响降到最小。

国家越来越重视用户隐私,用户安全的主题下,将全行数据加密提上日程。数据从金融网关进入网商那一刻起就变成密文,密文传输、密文存储;银行的备份和传统企业不一样,既要有同程备份又要有超远程的备份,中间有网络传输加密、透明加密,传输到超远程机房,再做一层存储透明加密。

历史库选型,让数据远离丢失风险

冷热分离为什么会带来数据丢失的风险?因为,在线数据库通过读取校验整个数据,CRC 验证 block 完整性,冷数据如果发生故障,没有读请求来验证数据块是否正常,从而难以发现坏块,极端情况甚至会导致多个副本永久丢失。

OceanBase 数据库有一个后台的进程,不间断扫描数据进行校验,以此发现问题,让数据库的备份真正的有效。如果几个月后才发现问题,为时晚矣,因为数据备份保存不了那么久。根据我们的历史库选型原则,一定要有后台校验,让数据远离丢失风险;此外,还要关注加密,保护用户隐私。

高性能探索实践,创新迭代扛大促

网商银行和 OceanBase 一路创新前行,不断探索向上。

线上性能摸底—链路压测

网商银行用的全链路压测方法进行容量摸底。通过压测代码上传到平台,将产出的流量打入金融网关,网关调用一层层业务服务。直接在生产系统进行压测,标通过标记区分是压测的业务,中间件把压测流量打到影子库中去;整体上,流量穿越所有的微服务链路,通过全链路压测进行容量摸底,确保链路上无单点流量瓶颈。

每年大促活动前,通过全链路压测进行容量摸底。

混合云弹性架构—大促弹出(20%)

假如网商银行一朵云上机器资源已用尽,能否并让流量跑到另一朵云上?通过混合云的弹性架构,数据库的一键扩展,应用上做单元化适配。今年大促最终弹出 20% 的流量到新云上,充分验证了 OceanBase 的快速的扩展能力。

OceanBase 致力于打造金融行业银行业的数据库,同时最令人骄傲的一点是 OceanBase 是中国人自己的数据库,希望行业同仁的交流能带来更多创新的尝试,带动国产数据库走向更广阔的发展。

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

分享:
OceanBase
使用钉钉扫一扫加入圈子
+ 订阅

OceanBase数据库由蚂蚁集团完全自主研发的企业级分布式关系数据库,始创于 2010 年。具有数据强一致、高可用、高性能、在线扩展、高度兼容 SQL 标准和主流关系数据库、低成本等特点。至今已成功应用于支付宝及阿里巴巴全部核心业务。并从 2017 年开始服务于广泛行业客户,包括南京银行、西安银行、天津银行、苏州银行、东莞银行、常熟农商行、广东农信、中国人保等近四十家银行、保险和证券机构,以及印度最大支付公司Paytm。

官方博客
官网链接