数据库权限管理设计-数据权限如何设计

【摘要】在云计算、大数据等新技术的驱动下，金融科技迎来了新一轮的创新，业界主流应用架构正在从松散耦合、中心化的SOA架构向解耦、分布式的微服务架构发展。在应用方面，传统数据库存在并发性弱、弹性不足、系统资源利用率不均衡、更新迭代发布周期长等问题，难以满足业务并发高、负载波动大、新功能发布频繁等需求。同时，随着数据库规模的增加，对管理成本和人力成本提出了很大的挑战，缺乏统一的数据库分析和辅助决策。近年来，为适应业务发展的需要，我公司顺应技术发展趋势，开展了分布式数据库的探索和应用。

【作者】王莱业，某金融机构项目经理，拥有多年核心系统管理和分布式技术实践经验，长期致力于私有云、分布式数据库技术、智能运维等领域的研究与实践。

一、背景

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

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

近年来，为适应业务发展的需要，我公司顺应技术发展趋势，以微服务理念开展在线交易系统的微服务设计。但是，我们现有的数据库架构无法以平台的形式提供分布式数据库服务，难以满足业务系统未来的发展需求。基于以上原因，我公司开展了分布式数据库的探索和应用。

2. 目标和需求

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

结合分布式数据库的设计目标，以及分布式数据库

应用和运维场景，我们进一步梳理了分布式数据库的需求，主要包括以下几个方面：

（1）一般要求：如支持标准SQL语法，支持x86，支持各种数据类型、数据库对象、约束、字符集等。

（2）分布式功能需求：如支持分布式事务、MVCC多版本控制、高并发下完善的锁定机制、不同隔离级别，支持表分区分片，支持读写分离，支持在线弹性伸缩和平滑扩展，支持SQL优化器等。

（3）性能要求：要求系统集群采用高可用架构，性能满足QPS支持10w+、TPS支持5w+以及连接数和并发性的要求，具有良好的数据拷贝同步性能。

（4）高可用性要求：集群架构要求没有单一的服务点，稳定可靠的服务，以及各个级别的高可用性能力。

（5）备份和恢复需求：例如，支持在线全量备份、增量备份、差异备份等功能，支持任意时间点备份和恢复等。

（6）容灾需求：支持多数据中心多主动容灾。

（7）安全要求：如加密存储、多租户资源隔离、权限管理、黑白名单、反注入攻击等。

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

（9）运维需求：如支持不间断服务的版本升级，支持灰度发布、滚动升级等，支持在线配置，支持在线扩缩容等。

（10）可移植性要求：例如，支持基于原始数据库的开发内容，实现平滑过渡，降低移植和转化成本。

通过需求分析和选型测试，我们最终选择了OceanBase分布式数据库产品。

3. 整体架构设计 1.分布式数据库产品概述

OceanBase 已经开发多年了，大家可能已经非常熟悉了，OceanBase 整个产品的结构非常清晰，计算层与数据存储层分离，这是大多数现代分布式数据库通常倾向于采用和考虑的架构。下面引用官方的OceanBase架构图进行简要介绍：

OceanBase 数据库使用无共享架构，节点之间完全点对点，所有这些都可以在标准服务器上运行。OceanBase采用可用区（Zone）的概念，这是一个逻辑概念，每个可用区是机房中的一台或多台服务器，即数据库服务器（OBServer）。每个 OBServer 包含 SQL 引擎、事务引擎和存储引擎，用户的 SQL 查询经过 SQL 引擎解析优化后转换为事务引擎和存储引擎的内部调用。SQL引擎是整个数据库的数据计算枢纽，分为解析器、优化器和执行器三部分;存储引擎负责访问和管理数据数据库权限管理设计，将数据分为基线数据和增量数据。对于跨服务器操作，OceanBase 数据库还执行强一致性分布式事务。此外，还有一个集中式调度器，它承担集群大脑的角色，称为“根服务”，其中每个区域上都会有一个主控服务，运行在某个 OBServer 上，整个集群只有一个主控服务，其他主控服务作为主控服务的备份服务运行， 主控服务负责整个集群的资源调度、资源分配、数据分发信息管理和模式管理。同时，一些管理工具将被集成到整体架构中，包括OCP、ODC、OBProxy等。

OceanBase可以实现在线水平扩容、强一致性的分布式交易、Paxos协议和多副本机制，同时也满足我们对高可用性、高性能和高可扩展性的要求。OceanBase部署简单，在线弹性扩容不影响业务，异地多活自动故障恢复，保证数据安全，兼容MySQL协议，迁移成本极低。本文将详细介绍OceanBase在我们公司的设计和实践。

2. 逻辑架构设计

图

1：整体逻辑架构图

图

2：单中心逻辑架构图

我们的分布式数据库架构具有高可用、强一致性、完全点对点、无共享等特点，具体表现为：

（1）整个集群采用主从结构，每个数据中心都有一组主OBServer集群，作为中心的生产集群，同时在另一个数据中心有一组从集群，数据在主从集群之间同步。

（2）两个数据中心共享一组OCP管理集群，部署在IDC1中，OCP从集群设置在IDC2中，用于同步主从集群之间的数据。

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

（3）每个OBServer集群部署为3个可用区，采用2-2-2架构，OCP集群采用1-1-1架构，均为3个副本。

（4）每个OBServer都是一个计算节点，每个节点都有一个SQL引擎和一个存储引擎，每个引擎管理不同的数据分区，完全是点对点的。此外，OBProxy 安装在每个 OBServer 上。

ObProxy 是具有数百万种处理能力的代理，可以路由转发，还具有反向代理的功能，是一种无状态的轻量级 SQL 解析器。OBProxy 将应用程序的 SQL 请求转发到 SQL 中涉及的表的主副本所在的计算机

（5） 在每个数据中心设置1台备份机。

3. 基础设施部署规划

新的OceanBase分布式数据库需要强大的基础设施来支持它，需要高可靠性，高性能和高容量。作为一个分布式系统，OceanBase在多台服务器上复制数据，需要有高度可靠的服务器作为保证。是否具有保证性能的处理能力是衡量分布式数据库系统能力的重要指标。为了应对海量数据，分布式数据库也需要硬件平台的容量。以下是特定的基础结构部署方案：

（1）IDC1和IDC2各配有六个机柜。（

2）每个IDC配置两台10千兆交换机（部署在主备模式下），10千兆网络用于主集群内每台机器的内部通信、从集群中每台机器之间的内部通信、主备集群之间的内部通信。

（3）每个IDC都配置了负载均衡，每个IDC中的负载均衡器挂载到各自中心的OBServer和OCP服务器上，在千兆网络环境下提供服务。

（4） 观察和

OCP服务器均采用基于第二代Intel ® Xeon ®可扩展处理器内核的x86物理机，其中OBServer采用不低于64c和512G的配置，硬盘采用SSD和SAS盘的组合;OCP服务器采用不低于32c和384G的配置，硬盘采用SAS盘。

在性能方面，OceanBase托管事务业务系统，需要更快的数据一致性和更快的数据库系统，并且每笔交易的成本需要尽可能低。除了处理器配置更高外，配合英特尔®傲腾™固态盘（其低时延能力出众，适用于OLTP分布式数据库场景），查询性能和相应的时间可以得到保证。

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

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

（5）OceanBase分布式数据库集群计划在一期托管少量在线交易系统，我们根据业务发展规模进行了合理估计，并获得了预计的日交易量、数据规模、数据增长率等信息。服务器设备需求是根据第一年的数据量和每日事务量来规划的，并考虑了数据副本的数量和磁盘空间的可用性，因此需要规划足够的冗余存储容量。

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

典型的服务器配置如下：

指标

技术参数要求

★ 服务器外观

机架式 2 路服务器

★中央处理器规格

[Intel_Xeon_Gold6240]*2

★CPU 内核数

[18]*2

★中央处理器架构

英特尔X86_64

★ 内存 （GB）。

16×32克

★ 内存规格

ECC DDR4 RDIMM 频率 ≥ 2666MHz

★ 内置硬盘

960G[960G_sata_ssd]*12 + 傲腾固态硬盘

★ 硬盘规格

SATA_SSD：市场主流品牌，企业级SATA固态硬盘，>=960G

（使用英特尔®傲腾™固态盘缓存热数据和重做日志）。

4. 详细方案设计

1. 高可用性解决方案

高可用性是我们分布式数据库的重要特性之一，OBServer和OCP服务器可以容忍某些节点的故障，而不会影响整个集群的可用性。我们的OceanBase生产集群在两个地方实现了双活高可用部署解决方案。下面，我们将从不同维度分析集群的高可用性。

（1）从服务器角色的角度看

为了保证数据安全，提供高可用的数据服务，OceanBase 对数据进行分区，每个分区数据物理上存储多个副本，每个副本称为分区的副本。每个分区及其副本形成一个单独的Paxos复制组，一个分区是主分区（Leader），另一个分区是辅助分区（Follower）。此副本的所有写入请求都会自动路由到相应的主分区。主分区可以分布在不同的OBServer上，这样不同副本的写入操作也会分布到不同的数据节点，从而实现多点数据写入，提高系统性能。

OceanBase数据库基于多副本和Paxos分布式选择算法，实现系统的高可用性。集群中的服务器主要有两个角色：OBServer 和 OCP 服务器，我们从这两个角色分析集群的高可用性。

OBServer部署在一个集群中，使用3个可用区和3个副本。集群中分区的副本保存到所有可用区，每个可用区都有数据的完整副本，通过Paxos协议在整个系统中分区的多个副本之间进行日志同步，以在多个副本的情况下保持数据一致性，并确保数据写入（持久化）到三个可用区中的至少两个。当单个 OBServer 节点发生故障时，应根据该节点上存储的所有分区的作用来判断：对于分区中的领导节点，主节点执行的少量事务可能无法同步到大多数副本，并且这些事务的状态不确定，称为挂起事务，需要等到跟随者接任新的领导者， 也就是说，领导者将中断服务。等待其他OBServer区重新选举领导人，领导人当选后，可以继续为公众提供服务;对于分区中的从属节点，服务不受影响。

此外，每个 OBServer 都有

同一个 OBProxy，本身是无状态的，一次停机不会影响业务分发，OBProxy 标准安装有守护进程，会自动拉动，OBServer 前端也有负载均衡，提供高可用能力。当单个 OBProxy 失败时，只有当前实例上的会话会受到影响，如果应用程序服务中的单个请求失败，应用程序可以重新分发到其他 OBProxy 实例，也可以在 OBProxy 重新启动后继续接收服务。

OCP Server 也部署在一个集群中，该集群本质上是一个 OceanBase 集群，通过 Paxos 协议保持数据一致性。当单个节点发生故障时，如果不是领导者，则服务完全不受影响;如果是领导者，集群将选举新的领导者并自动恢复服务。

（2）从停机时间规模来看

我们的分布式数据库集群可以容忍单机和单可用区故障，从而实现高可用性。

独立服务器故障（分为 OceanBase 和 OCP 角色）请参阅上一节。

我们将集群的所有服务器分散在每个区域中，每个区域都包含分区的副本，根据

Paxos协议的多数原则是，单区失效，不会影响集群向外界提供服务。我们的架构允许集群中的单个区域发生故障。

2. 容量方案数据存储我们考虑了业务数据、

数据库日志和健康数据，综合考虑了硬盘的容量、I/O读写速率等因素，我们选择了SAS盘+SSD盘作为服务器硬盘存储。在规划硬盘的存储容量时，我们会考虑多个数据副本的特征，以规划足够的存储容量。划分磁盘时，请分别设置数据盘和日志盘。

需要指出的是，OceanBase数据库的存储引擎将数据分为基线数据和增量数据，并将基线数据和增量数据分别保存在硬盘和内存中，因此具有读写分离的特点，数据的修改是增量数据，是在内存中进行的， 所以它具有非常高的性能。数据读取可能在内存中有一个更新版本，在硬盘中有一个基线版本，并且需要合并两个版本才能获得新版本来输出结果。因此，在规划数据库集群存储时，内存容量也很重要。

3. 多租户方案

OceanBase支持多租户管理。租户是一个逻辑概念，可以理解为OceanBase资源分配的单位。租户在某种程度上等同于传统数据库的“实例”概念，租户彼此完全隔离。一个租户有多个资源池，这些资源池的集合描述了该租户可用的所有资源。资源池由具有相同单元配置的多个单元组成。一个资源池只能属于一个租户。每个单元描述一个 OBServer 上的一组计算和存储资源，包括多个 CPU 资源、内存资源、磁盘资源等。

我们为每个应用程序设置了一个单独的租户。在将资源分配给租户时，原则上，大型企业可以使用分配资源较多的租户，小型企业可以使用分配资源较少的租户。租户对应的资源可以扩容，所以一开始可以分配少量资源，在事务规模增加或者遇到重要事务节点时扩容。

4. 备份和恢复解决方案

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

海洋基地提供全量备份、增量备份和数据恢复功能。

我们为网络共享存储设置了一台备份机，可以是物理机或虚拟机。OBServer 挂载共享存储以进行备份。定时进行全量备份，根据数据量和数据保留时间确定备份周期，在非事务时间内进行;增量数据备份是实时进行的。

数据恢复需要仔细恢复到新租户。

5、日常运维计划

OceanBase提供图形化数据库管理平台OCP，具有集群管理、租户管理、监控告警、备份恢复功能，涵盖运维管理的各个环节。对于运维人员来说，使用OceanBase过程中的运维复杂度大大简化。在实践中，我们将使用 OCP 和命令行来管理数据库。利用这两种方法，我们制定了监控方案（如集群状态、资源监控等）、巡检计划、故障处理方案（如资源负载、数据分配、容量控制、故障启停等）、应急预案、集群运行方案（如扩缩容、升级等）。

6. 灾难恢复计划

除了OceanBase生产主集群外，我们还增加了从集群设计，以实现远程灾难恢复。OceanBase备份数据库将主集群的数据复制到从集群，主从集群完全独立，避免了主集群异常时故障传输到从集群，具有更好的容灾隔离。

7. 应用规范和迁移

OceanBase 和 MySQL

在SQL、语法和数据类型上兼容性强，转换成本低，基于MySQL开发的应用系统可以顺利迁移，但在迁移过程中需要按照OceanBase开发规范进行必要的转换和适配。我们主要从以下几个方面考虑根据规范进行改造：

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

（2）检查并优化SQL语句并进行转换。

（2）绩效检查和判断。应用接入数据库后，需要检查几个指标：QPS、TPS、响应时间、服务数据库大小、服务表增长率、数据库连接会话数、热点盘等。

五、结语

本文简要介绍了我们分布式数据库的解决方案设计和具体实践，涵盖了日常运维管理的方方面面，包括高可用、监控告警、集群调优、备份恢复、容灾、扩容缩容等。一个健壮的分布式数据库架构需要软件、硬件、运维等方面的协调。未来，我们将尝试将更多的业务场景迁移到分布式数据库数据库权限管理设计，以探索更多的实践领域，更好地支持业务发展和创新。