wanglaye
作者wanglaye2022-01-18 16:59
信息技术经理, 某大型金融机构

某金融机构分布式数据库设计与实践

字数 7588阅读 4926评论 5赞 7

文章摘要:

在现今云计算、大数据等新型技术推动下,金融科技迎来了新一轮创新浪潮,业界主流的应用架构,正由松耦合、集中式的SOA架构向解耦合、分布式的微服务架构发展。传统数据库在应用方面,存在并发能力不强、弹性不足、系统资源利用不均衡、更新迭代发布周期长等问题,难以适应业务高并发、负载波动大、新功能上线频繁等需求。同时,随着数据库规模的增大,对于管理成本和人力成本提出了很大挑战,缺乏统一的数据库分析和辅助决策,出现问题时往往各自为政,存在数据孤岛,管理时效性难以保证。近年来,为满足业务发展需求,我司顺应技术发展潮流,开展了分布式数据库的探索和应用。

一、背景

在现今云计算 、大数据等新型技术推动下,金融科技迎来了新一轮创新浪潮, 业界主流的应用架构 ,正由松耦合、集中式的SOA架构向解耦合、分布式的微服务架构发展。在“去IOE”、“自主可控”的技术和政策双重背景下,传统金融行业的业务系统所采用的数据库,正在从老牌厂商的 DB2 、 Oracle等 逐渐过渡至开源数据库或国产新兴的 分布式数据库 。

我司各类业务系统,均是典型 SOA系统架构 ,其 数据库均为主备部署模式,在应用方面存在并发能力不强、弹性不足、系统资源利用不均衡、更新迭代发布周期长等问题,难以适应业务高并发、负载波动大、新功能上线频繁等需求。同时, 作为一家传统金融企业,各业务系统仍然是纵向隔离的状态,在烟囱式系统架构中,每个业务系统都有其独立的数据库,随着业务系统数量越来越多、数据规模越来越大、交易复杂度不断提升,数据库的数量也越来越多,对于管理成本和人力成本提出了很大挑战。并且,由于数据库各自独立,无法对全部数据库的运行状况形成全局视图,缺乏统一的“数据库管理大脑”,无法进行统一的数据库分析和辅助决策, 出现问题时往往各自为政 ,存在数据孤岛,管理时效性难以保证。

近年来 , 为满足业务发展需求 , 我司顺应技术发展潮流 ,以微服务的理念,进行线上交易系统的微服务化设计。但我司现有的数据库架构,尚不能以平台化形式提供分布式数据库服务,难以满足业务系统未来的发展需求。基于以上原因,我司开展了分布式数据库的探索和应用。

二、目标与需求

我们在进行分布式数据库设计时 ,主要考虑达成几个目标,一是提高系统扩展能力,应对高并发访问;二是提高资源利用率,降低运营成本;三是提高系统可靠性,降低运行风险。

结合分布式数据库设计目标,以及分布式数据库应用和运维场景,我们进一步梳理了分布式数据库的需求,主要包括以下方面:

(1)通用需求:如支持标准SQL语法,支持x 86 ,支持各种数据类型、数据库对象、约束、字符集等。

(2)分布式功能需求:如支持分布式事务、MVCC多版本控制,支持高并发情况下的完善锁机制,具备不同隔离级别,支持分表分区分片,支持读写分离,支持在线弹性伸缩与平滑扩容,支持SQL优化器等。

(3)性能需求:要求系统集群采用高可用架构,性能满足QPS支持10w+、TPS支持5w+,以及连接数和并发数要求,且具备良好的数据副本同步性能。

(4)高可用需求:要求集群架构无任何服务单点,服务稳定可靠,具备各种层级的高可用能力等。

(5)备份与恢复需求:如支持在线全量备份、增量备份、差量备份等功能,支持任意时间点的备份还原等。

(6)灾备需求:支持多数据中心多活容灾。

(7)安全需求:如支持加密存储,支持多租户资源隔离,支持权限管理,支持黑白名单,支持防注入攻击等。

(8)运管监控需求:如具备可视化运维管理工具,支持数据库实时监控和历史回溯,支持数据库审计、SQL执行计划及优化提醒,支持统计分析等。

(9)运维需求:如支持不停业务的版本升级,支持灰度发布、滚动升级等,支持在线配置,支持在线扩缩容等。

(10)可移植性需求:如支持基于原数据库 的开发内容,实现平滑过渡 , 降低移植改造成本。

通过需求分析与选型测试 , 我们最终选定OceanBase分布式数据库产品 。

三、整体架构设计

1. 分布式数据库产品概览

OceanBase已经发展多年,大家或许已经非常熟悉,OceanBase 整个产品的结构非常清晰,计算层跟数据存储层分离,这是现代大部分分布式数据库通常都会倾向和考虑采用的架构 。下面引用一张OceanBase官方架构图,做个简要介绍:

OceanBase 数据库采用Shared-Nothing 架构,各个节点之间完全对等 ,这些节点均可运行于标准服务器之上。OceanBase采用了 可用区 (Zone) 的概念,Zone是个逻辑概念 , 每个Zone 是一个机房内的 1台或多台 服务器, 即 数据库服务器(OBServer)。每台 OBServer 包含 SQL 引擎、事务引擎和存储引擎,用户的 SQL 查询 经过 SQL 引擎解析优化后转化为事务引擎和存储引擎的内部调用。SQL 引擎是整个数据库的数据计算中枢 ,分为解析器、优化器、执行器三部分;存储引擎负责数据的存取和管理,将数据分为基线数据和增量数据。对于跨服务器操作, OceanBase 数据库还会执行强一致的分布式事务 。 此外 , 还有一个承担集群大脑角色的集中调度器,叫做 “总控服务”(RootService),其中每个 Zone 上都会存在一个总控服务,运行在某一个 OBServer上,整个集群中只存在一个主总控服务,其他的总控服务作为主总控服务的备用服务运行,总控服务负责整个集群的资源调度、资源分配、数据分布信息管理以及 Schema 管理等功能。 同时 整体架构中还会融合一些管理 工具,包括 OCP、 ODC 、 OBProxy等 。

OceanBase可实现 在线水平伸缩 、 强一致性的分布式事务 、 基于Paxos协议和多副本 机制,并且也满足我司对于高可用、高性能、高可扩展性的要求。OceanBase 部署简单,在线弹性扩容不影响业务,异地多活及自动故障恢复保障数据安全,同时兼容MySQL 协议,使迁移使用成本降到极低 。这篇文章将详细介绍OceanBase在我司的设计与实践。

2. 逻辑架构设计


图 1:总体逻辑架构图

图 2:单中心逻辑架构图

我司的分布式数据库架构具备高可用、强一致、全对等、无共享等特点,说明:

(1)整个集群 采用主从结构, 每个 数据中心有一套主OBServer集群 , 作为本中心生产集群 , 同时在另一个数据中心有一套从集群 ,主从集群之间进行数据同步。

(2)两个数据中心共用一套OCP管理集群,部署于IDC 1 ,同时在IDC 2设置OCP从集群 , 主从集群之间进行数据同步 。

OCP(OceanBase Cloud Platform)管理集群,是一款以 OceanBase 为核心的企业级数据库管理平台。不仅提供对 OceanBase 集群和租户等组件的全生命周期管理服务,同时也对 OceanBase 相关的资源(主机、网络和软件包等)提供管理服务 。通过OceanBase云平台,可以一键安装、部署、升级OceanBase集群,监控集群的运行状态,创建和维护运维任务等。

(3)每个OBServer集群部署为三个Zone,采用2- 2 - 2架构 ,OCP集群采用1- 1 - 1架构 , 均为三副本。

(4)每台OBServer都是计算节点,每个节点有SQL引擎及存储引擎,各自管理不同的数据分区,完全对等。此外,每台OBServer上安装了OBProxy。

ObProxy是一款具备百万级处理能力的代理,可进行路由转发,也具备反向代理功能,是一款轻量级SQL Parser,本身无状态。 OBProxy会将应用的sql请求,转发到该条sql所涉及表的主副本所在的机器上 ,

(5)每个数据中心设置1台备份机。

3. 基础架构部署规划

新型的Ocean Base 分布式数据库需要强有力的基础架构予以支撑,需要高可靠性、高性能和高容量保障。作为分布式系统, OceanB ase在多个服务器上复制数据,需要有高可靠的服务器作为保障。是否具有保性能的处理能力是衡量分布式数据库系统能力的重要指标。应对海量数据,分布式数据库对硬件平台的容量也有要求。以下是具体基础架构部署方案:

(1)IDC1、IDC2各 配置六个机柜 。

(2) 每个 I DC配置 两 台万兆交换机 (以主备模式部署) ,主集群 各台机器内部通信、 从集群 各台机器内部通信、 主从集群之间都 是使用 万兆网 络 。

(3)每个IDC配置负载均衡,各I DC 中负载均衡分别挂载各自中心内部的OBServer和OCP Server ,以千兆网环境对外提供服务。

(4)OBServer、OCP Server均使用基于第二代 英特尔®至强®可扩展处理器 内核的x 86物理机 , 其中OBServer采用不低于 64c、512G的配置,硬盘采用SSD和SAS盘结合的方式;OCP Server采用不低于 32c、384G的配置,硬盘采用SAS盘。

在性能方面,O ceanB ase承载交易类的业务系统,需要更快的数据一致性和更快的数据库系统,每一笔交易的成本需要尽可能地低。除了采用较高配置的处理器之外,配合如 英特尔®傲腾™固态盘 (其低延迟能力突出,适用于O LTP 类分布式数据库场景),查询性能和相应时间能够得到保障。

在高可用方面, 英特尔®傲腾™固态盘上也引入了企业级应用环境所必需的断电保护、内置冗余两项重要技术。断电保护技术可以帮助数据库系统在遇到电力意外中断时防止数据丢失。内置冗余技术是在规定的存储容量之上配备了冗余的 NAND 闪存阵列,在发生故障之时,可以自动重新配置故障 NAND 闪存阵列, 从而 降低数据丢失的可能性,进一步提升了数据库系统的可靠性。

在节能减排方面,企业的数据量快速增长,但电力和机房资源不可能同样持续高速增长,采用英 特尔®傲腾™固态盘 能在数据库系统提升性能时减少机器数量,单台服务器功耗也能降低。

(5)OceanBase分布式数据库集群 在一期计划承载少量 线上交易系统 , 我们根据业务的发展规模进行了合理估算,得出了预期日交易量、数据规模、数据增长率等信息。服务器设备需求 按照第一年 的 数据量和 日交易量 进行规划 ,并综合考虑了数据副本数和磁盘空间可用率,因此需要规划足够的冗余存储容量。

此外,OceanBase集群还需要OCP管理机对集群进行统一管理、需要服务器进行数据备份,因此,还要考虑这些进行服务器的规划。

服务器典型配置如下:

四、详细方案设计

1、高可用方案

高可用是我 司分布式 数据库 的 重要特性之一 , OBServer、 OCP Server都能容忍部分节点失效,不影响整个集群的可用性 。我司的OceanBase生产 集群 实现两地双活高可用部署方案 。 下面,我们将从不同的维度来分析集群的高可用性。

(1)从服务器角色的角度

为了数据安全和提供高可用的数据服务,OceanBase将数据进行分区,每个分区数据在物理上存储多份,每一份叫做分区的一个副本。 每个分区和它的副本构成一个独立的Paxos 复制组,其中一个分区为主分区(Leader),其它分区为备分区(Follower)。所有针对这个副本的写请求,都会自动路由到对应的主分区上进行。主分区可以分布在不同的 OBServer 上,这样对于不同副本的写操作也会分布到 不同的数据节点上,从而实现数据多点写入,提高系统性能。

OceanBase数据库基于多副本及 Paxos 分布式选举算法来实现系统的高可用 。集群中的服务器主要有两种角色:OBServer、 OCP Server ,我们从这两个角色来分析集群的高可用性。

OBServer以 集群 方式部署 ,采用 3个Zone、3副本方式。 集群中分区的副本会被保存到所有的Zone 上,每个Zone都有一份完整数据 , 整个系统中该分区的多个副本之间通过Paxos 协议进行日志同步 , 保持 多副本情况下的 数据一致性 ,保证数据写(持久化)到三个Zone中至少两个 。单个 OBServer节点 失效时,要根据这个节点上存储的所有 分区的角色来进行判断: 对于 分区 中的Leader 结点,Leader最后执行的少量事务可能没有同步到大多数副本,这些事务的状态不确定, 称为未决事务,需要等到某个 Follower 接替为新的Leader后才能最终确定 ,也就是说,leader 会中断服务,等待 其他OBServer上的分区 重新选举 Leader,待Leader选出了可继续对外提供服务 ;对于 分区 中的Follower节点,不会影响服务 。

此外 , 每台OBServer上都有相同的 OBP roxy,其本身是无状态的 , 一台宕掉不会影响业务分发, OBP roxy标准安装是有守护进程的 , 会自动拉起,并且OBServer前端还有负载均衡提供高可用能力。当单个 OBProxy 失效时, 仅仅 会影响 当前 实例上进行的 会话 , 应用服务 出现单次请求失败的情况, 应用被 重新分发 至其他OBProxy实例 后或等该OBProxy重新拉起后即可继续获得服务。

OCP Server 同样以 集群 方式部署 ,其本质也是一个OceanBase集群 , 通过 Paxos 协议保持数据的一致性 。 单个节点失效时,如果不是leader,那么服务完全不受影响;如果是leader, 那么集群 会重新选出新的leader,自动恢复服务。

(2)从宕机规模的角度

我司的分布式数据库集群可容忍单机级、单Zone级的故障,从而实现高可用。

单机服务器故障,分为OceanBase、 OCP两 个角色,参考上一小节的阐述。

我们将集群所有服务器分散放置在各个Zone里,每个Zone包含分区的一个副本,根据Paxos协议大多数原则,单个Zone出现故障,不会影响集群对外提供服务。我司的架构允许集群中单个Zone故障。

2、容量方案

数据 存储我们考虑了业务数据、数据库日志 及 运行状况 数据,综合考虑硬盘的容量、 I/O 读写速率等因素后,我们选用了SAS盘+SSD盘作为服务器硬盘存储。在规划硬盘存储容量时,我们考虑了数据多副本的特点,从而规划出足够的存储容量。在进行磁盘划分时,将数据盘和日志盘分别设置。

需要特别指出的是 , OceanBase 数据库的存储引擎 将 数据分为基线数据与增量数据,把基线数据和增量数据分别保存在硬盘和内存中,因而具备读写分离的特点 , 对数据的修改都是增量数据, 在 内存中进行 , 也因此具备了非常高的性能。 数据 读可能会在内存里有更新过的版本,在 硬盘 里有基线版本,需要把两个版本进行合并,获得一个最新版本 , 从而输出结果。因此 , 在规划数据库集群存储时 , 内存容量也非常重要 。

3、**多租户方案**

OceanBase支持多租户管理。租户是一个逻辑概念,可以理解为是 OceanBase资源分配的单位 。租户在一定程度上相当于传统数据库的“实例”概念,租户之间是完全隔离的。一个租户拥有若干个资源池,这些资源池的集合描述了这个租户所能使用的所有资源。一个资源池由具有相同资源规格(Unit Config)的若干个 UNIT(资源单元)组成。一个资源池只能属于一个租户。每个 UNIT 描述了位于一个 OBServer 上的一组计算和存储资源,包括若干 CPU 资源、内存资源、磁盘资源等。

我们为每个应用系统设置了 各自的租户。给租户分配资源时,原则上大业务可以使用分配资源多的租户 ,小业务可以使用分配资源少的租户 。租户对应的资源可以扩容,所以 也可以一开始先分配少量资源 , 在交易规模增大或遇到重要交易节点时进行扩容 。

4、备份与恢复方案

虽然OceanBase集群的多副本策略可以避免故障发生时数据的丢失,但我们仍然需要制定完善的数据备份与恢复策略,进一步加强数据安全性。

OceanBase提供全量备份、 增量备份 、 数据恢复功能。

我们设置了备份机 , 可以是物理机 , 也可以是虚拟机 , 用于网络共享存储 。OBServer挂载共享存储进行备份。全量备份定期进行,根据数据量、数据保存时间来决定备份周期,在非交易时间进行;增量数据备份实时进行。

数据 恢复需注意要恢复至新租户 。

5、日常运维方案

OceanBase提供了图形化的数据库管理平台 —— OCP ,具备 集群管理 、 租户管理 、 监控告警 、 备份恢复等功能 , 涵盖运维管理的各个方面 。对于 运维人员来说,大大简化了在使用OceanBase过程中的运维复杂度。我们在实际工作中 , 会采用OCP与命令行结合的方式进行数据库的管理 。利用这两种方式,我们制定了监控方案(如集群状态、资源监测等)、巡检方案、故障处置方案(如资源负载、数据分布、容量控制、故障启停等)、应急方案、集群操作方案(如扩缩容、升级等)等。 ****

6、灾备方案

除了OceanBase生产主集群,我们还增加了从集群的设计,目的是为了实现异地灾备。 OceanBase 备库,将主集群的数据复制到从集群,主从集群完全独立,避免主集群异常时故障传导到从集群,具备更好的容灾隔离性 。

7、应用规范与迁移

OceanBase 与mysql在SQL 、 语法和数据类型等方面,有非常大的兼容性,改造成本较低, 基于 MySQL开发的应用系统可以平滑迁移 , 但在迁移时需要根据OceanBase开发规范进行必要的改造适配 。我们主要从以下几个方面来考虑按照规范进行改造:

(1) 检查和优化库/表/索引等内部对象 。

(2)检查和优化SQL语句,进行改造。

(2) 性能检查和判断 。 应用 连接数据库后,需要着重检查几个指标:QPS、TPS、响应时间、业务库大小、业务表增长率、数据库连接会话数、热点盘等。

五、结语

本文简单介绍了我司分布式数据库 的 方案设计与具体实践,并且涵盖了日常 运维管理 的各个方面 ,包括高可用 、 监控告警、集群调优、备份恢复、灾备、扩容缩容 等。健壮的分布式数据库架构需要软件、硬件、运维管理等多方位协同配合。今后我们会尝试将更多的业务场景迁移到分布式数据库上,以探索更多的实践领域、更好支持业务发展与创新。

作者系某金融机构项目经理,具备多年银行核心系统管理经验和分布式技术实践经验,长期致力于私有云、分布式数据库技术、智能运维领域的研究和实践。

如果觉得我的文章对您有用,请点赞。您的支持将鼓励我继续创作!

7

添加新评论5 条评论

sky199sky199软件开发工程师, 软通动力
2022-02-23 22:36
看完很有帮助
sky199sky199软件开发工程师, 软通动力
2022-02-23 22:36
看完很有帮助
匿名用户
2022-02-10 21:17
本文作者详细介绍“去IOE”中“O”架构方案,并采用业界主流的应用架构,使用OBDB分布式数据库 。使用场景应该是同城双活数据中心,“O”通过一套OCP进行管理集群维护,每个数据中心都有OBServer主、从集群互为主从,每个OBServer集群部署为三个Zone(3副本),每个数据中心设置1台备份机。两中心之间的内部通信配置了万兆交换机,对外提供服务使用千兆交换机。在详细方案设计中,从高可用、容量、多住户、备份与恢复、运维、灾备、应用规范与迁移几个方面做了阐述。在去“IOE”中,不断踊跃出很多国产数据库厂商,数据库的分类也越来越细。
saltypsaltyp系统架构师, 某银行
2022-02-09 15:34
分享的不错,希望可以看到更多金融同行可以分享自己的实践经验和遇到的坑。
a5060963a5060963运维工程师, 民营500强企业
2022-02-09 15:12
该文章看完后又刷新对数据库的了解,本文引用的Ocean Base,蚂蚁公司开发的分布式数据库。 1、该文章中表述层次鲜明,说明常规数据库的使用瓶颈,请求量也一一列出,最后再进行架构讲解,运维方案、灾备方案等 2、特别适合用于金融企业的高请求量,高并发。而且在灾备中相对于传统数据库的冗余解决方案更优 3、希望以后也可以接触到此方案的结构,学习强大的数据库解决方案
Ctrl+Enter 发表

本文隶属于专栏

最佳实践
不同的领域,都有先行者,实践者,用他们的最佳实践来加速更多企业的建设项目落地。

分布式关系型数据库选型优先顺序调查

发表您的选型观点,参与即得50金币。