关键字：资源池化 | 可管理性 | 降低成本

OceanBase 的原生多租户架构，支持一个集群中同时运行多个数据库租户，每个租户可以视为一个独立的数据库服务。租户间数据和资源互相隔离，并且在集群内统一调度。支持在创建租户时选择不同的兼容模式，每个租户可单独配置数据副本数量、副本类型、存储位置及计算资源等。

SaaS 资源整合场景

微服务架构

  随着企业内业务系统越来越复杂，原来的单体服务在工程和管理上变的越来越不堪重负。使用微服务架构，新增和调整功能只需要增加新的微服务节点。但是每个微服务需要使用不同的数据库，数据库的数量大大增加，可靠性和运维管理都带来了挑战。使用 OceanBase 多租户特性，管理员只需要运维少量集群，既能保证租户之间数据和资源互相隔离，又提升了数据库的稳定性。

多租户 SaaS 服务

  云上的 SaaS 服务商，往往提供的是多租户的服务。多个业务租户的数据库如果在一个单机数据库中做逻辑名字空间隔离，大小租户之间互相影响。如果每个业务租户使用一个独立的数据库，成本高，几十到上百套分散数据库环境，运维工作复杂，同时扩展性受限。使用 OceanBase数据库内原生多租户，能更好地平衡隔离性和成本，而且大小租户可以独立扩缩容。

行业现状与挑战

• 实例碎片化：企业内部多个不同业务应用，或SaaS 企业面向不同客户的资源隔离需求，会导致需要部署大量的数据库实例，造成严重的碎片化，在某个关键业务或关键客户需求激增时，难以灵活的弹性扩展，性能和可用性难以保证。
• 资源浪费：由于数据库资源的碎片化部署，单个实例为了保证一定的性能弹性空间，往往会多划出一部分容量作为短时间内请求增长的预备资源。这种资源预留在整体业务视角来看实际上造成了巨大的资源浪费，抬高了企业资源成本。
• 管理复杂：大量的数据库实例同时带来的还有管理效率的降低， 数据库相关团队难以对成百甚至上千的实例进行精细化管理， 出现故障、抖动等事件时恢复时效差，对整体资源水位的把控难以全局掌控，抬高了企业的人力管理成本。

解决方案

方案描述

  基于 OceanBase 的多租户架构，帮助企业将多个不同业务的数据库实例集中整合，提升资源利用率，同时基于 Paxos 的多副本机制可以保证每个资源单元的高可用能力。
  既适用于中大型企业内部大量不同业务链路的资源池化，也适用于各个行业 SaaS 服务商，为不同客户提供不同规格的实例，保证资源隔离性的同时降低成本。

方案优势

• 多租户池化： OceanBase 集群原生实现了多租户下的资源隔离和虚拟化，一个集群中可以部署上百个数据库实例，每个实例数据和资源隔离，计算资源原地升配秒级生效。
• 多维度弹性：基于 OceanBase 的多节点分布式架构，用户可以实现单机原地升配、多机弹性扩展，多机流量均衡多个维度的扩容操作，并且扩容对上层应用透明。对于涉及数据迁移的扩展无需人工值守，OceanBase 自动完成迁移以及多维度数据校验。
• 统一管理：将多个零散的实例统一部署在 OceanBase 后，运维管理的复杂度大大降低，DBA 从之前管理几百个分散实例，到目前管理几个 OceanBase 集群，负载、告警、调优全部统一至集群级别，常规故障能够自动恢复，大幅提升业务支撑效率和应急响应能力。
• 降本增效：不但通过多租户实现计算资源池化，提高总体利用率，OceanBase 的高级压缩能力使得存储成本仅为原来传统数据库的 1/3。经过大量的客户反馈和广泛案例实践统计，OceanBase 的资源整合方案能够帮助中型及以上企业降低 TCO 约 30%-50%。

OceanBase 多租户特性介绍

多租户概述

  租户是一个逻辑概念。在 OceanBase 数据库中，租户是资源分配的单位，是数据库对象管理和资源管理的基础，对于系统运维，尤其是对于云数据库的运维有着重要的影响。租户在一定程度上相当于传统数据库的"实例"概念。租户之间是完全隔离的。
  在数据安全方面，OceanBase 数据库不允许跨租户的数据访问，以确保用户的数据资产没有被其他租户窃取的风险。在资源使用方面，OceanBase 数据库表现为租户"独占"其资源配额。总体上来说，租户（tenant）既是各类数据库对象的容器，又是资源（CPU、Memory、IO 等）的容器。
  OceanBase 数据库通过租户实现资源隔离，让每个数据库服务的实例不感知其他实例的存在，并通过权限控制确保租户数据的安全性，配合 OceanBase 数据库强大的可扩展性，能够提供安全、灵活的 DBaaS 服务。
  OceanBase 数据库采用了单集群多租户设计，天然支持云数据库架构，支持公有云、私有云、混合云等多种部署形式。

租户和资源池

  租户是集群之上的递进概念，OceanBase 数据库采用了多租户架构。多租户架构适用于资源整合（Resource Consolidation）、SaaS 服务等场景，同时也降低了运维复杂度。
  集群偏向于部署层面的物理概念，是 Zone 和节点的集合，Zone 和节点具有部署地域（称为 Region）等属性；而租户则偏向于资源层面的逻辑概念，是在物理节点上划分的资源单元，可以指定其资源规格，包括 CPU、内存、日志盘空间、IOPS 等。
  租户类似于传统数据库的数据库实例，租户通过资源池与资源关联，从而独占一定的资源配额，可以动态调整资源配额。在租户下可以创建 Database、表、用户等数据库对象。
  要描述清楚租户的概念，首先需要描述清楚资源规格、资源单元（Unit）、资源池等前置概念。资源规格对应的视图是 DBA_OB_Unit_CONFIGS，资源池对应的视图是 DBA_OB_RESOURCE_POOLS，资源单元对应的视图是 DBA_OB_UnitS，租户对应的视图是 DBA_OB_TENANTS。
  资源规格资源规格定义了常见物理资源项的大小，包括 CPU、内存、磁盘空间、IOPS 等。创建资源池时指定其资源规格，从而根据定义创建资源单元。
  资源单元（Unit）Unit 是租户管理中非常重要的概念。OceanBase 按照 Unit 来管理物理资源，是 CPU、内存、存储空间、IOPS 等物理资源的集合。Unit 也是资源调度的基本单位，其具有节点、Zone、Region 等位置属性，节点是服务器的抽象，Zone 是机房的抽象，Region 是地域的抽象，通过调整 Unit 的位置属性从而调整租户的部署方式。
  资源池每个 Unit 都归属于一个资源池，每个资源池由若干个 Unit 组成，资源池是资源分配的基本单位，同一个资源池内的各个 Unit 具有相同的资源规格，即该资源池内 Unit 的物理资源大小都相同。
  如上图，展示了一个由 6 个 Unit 组成的资源池 a_pool，该资源池具有如下重要属性：

• ZONE_LIST：描述了该资源池中的 Unit 分布在哪些 Zone，本例为 ZONE_LIST='zone1,zone2,zone3'。
  
• UNIT_NUM：描述了 ZONE_LIST 中每个 Zone 中的 Unit 个数，本例为 UNIT_NUM=2。
  
• UNIT_CONFIG_ID：描述了该资源池关联的资源规格，从而决定该资源池中每个 Unit 的物理资源大小，包括 CPU、内存、日志盘空间、IOPS 等。
  

  通过 Unit 的概念，我们将 OceanBase 数据库的物理概念和逻辑概念进行了关联。每个租户有若干 Unit ，分布于若干 Zone 的若干节点上。而每个节点上分布有若干个 Unit ，这些 Unit 归属于不同租户。概括的讲：集群由节点组成，节点是 Unit 的容器。租户由 Unit 组成，Unit 是数据库对象的容器。
  创建租户时通过设置 RESOURCE_POOL_LIST，可以指定该租户关联到的资源池，从而该租户拥有指定资源池的 Unit。例如：设置租户 a 的 RESOURCE_POOL_LIST=('a_pool')，其部署图如下：

  该租户部署于 3 个 Zone，每个 Zone 有 2 个 Unit，可以通过调整 a_pool 的 UNIT_CONFIG_ID：描述了该资源池关联的资源规格，从而决定该资源池中每个 UNIT_CONFIG_ID 参数来动态调整租户的物理资源。
  还可以通过调整 Unit 在同一个 Zone 内不同节点的分布（称为 Unit 迁移），从而达到 Zone 内不同节点间的负载均衡。节点故障时通过将其上的 Unit 迁移到同 Zone 内其他节点上，从而达到自动容灾恢复的目的。通过调整 Unit 在不同 Zone 的分布（变更租户的 Locality 属性），从而调整租户的部署模式，例如 “同城三中心”、“两地三中心”、“三地五中心” 等，从而具备不同的容灾等级。

体验多租户特性

  详见 OceanBase 官网文档：https://www.oceanbase.com/docs/common-oceanbase-database-1000000000033292

多租户间的隔离性

  很多同学好奇 Oceanbase 怎么实现多租户之间的隔离。其实租户就像一个容器，这套容器里包含了 table，database，user 等逻辑对象；也包含了分给这个租户的内存，cpu，磁盘空间等物理资源。

逻辑对象隔离

  不同租户的逻辑对象一定要处在不同的名字空间。逻辑对象实际是记录在内部表中的数据，为了保证名字空间独立，OceanBase 的每个租户都有自己一套完整的内部表，用于记录租户内逻辑对象的元数据信息，以此保证逻辑对象的隔离性。

物理资源隔离

  物理资源可以分为两类：一类是弹性资源，比如CPU，磁盘带宽等；另一类是刚性资源，比如内存，磁盘空间等。弹性资源是可以抢占的，刚性资源一旦被占用，除非占有者主动释放，否则是无法抢占的。
  从定义上来说，刚性资源无法超卖，必须要强隔离；弹性资源可以一定程度上超卖。无论是刚性资源还是弹性资源，在observer里都有租户级别的记账，通过视图可以方便地查看。

select * from DBA_OB_UNIT_CONFIGS;
+----------------+-----------------+---------+---------+-------------+---------------+----------+----------+-------------+
| unit_config_id | NAME            | MAX_CPU | MIN_CPU | MEMORY_SIZE | LOG_DISK_SIZE | MAX_IOPS | MIN_IOPS | IOPS_WEIGHT |
+----------------+-----------------+---------+---------+-------------+---------------+----------+----------+-------------+
|              1 | sys_unit_config |       1 |       1 |  1073741824 |    2684354560 |    10000 |    10000 |           1 |
|           1001 | 1c1g            |       1 |       1 |  1073741824 |    3221225472 |    10000 |    10000 |           1 |
|           1002 | 1c2g            |       1 |       1 |  2147483648 |    6442450944 |    10000 |    10000 |           1 |
|           1003 | 2c2g            |       2 |       2 |  2147483648 |    6442450944 |    20000 |    20000 |           2 |
|           1004 | 2c4g            |       2 |       2 |  4294967296 |   12884901888 |    20000 |    20000 |           2 |
+----------------+-----------------+---------+---------+-------------+---------------+----------+----------+-------------+

内存和磁盘空间隔离

  内存和磁盘空间的隔离机制比较简单，一旦超过配额，后续的资源申请就会失败。为了降低资源耗尽的情况，observer 内部会根据内存和磁盘空间的消耗情况控制写入的速度。

CPU 隔离

  observer 最基础的 CPU 隔离是通过用户态调度，控制活跃线程数来实现的。每个租户有独立的线程池，线程池的规格是由租户规格和一些配置参数来决定的。

  同时，observer 也支持配置 cgroup，来实现 CPU 的隔离优化。cgroup 能对线程的 CPU 使用率进行精准的限制，达到租户之间 CPU 强隔离的效果。

observer
  ├── tenant1
  │   └── tasks
  │         ├── thread1
  │         ├── thread2
  │         └── ...
  ├── tenant2
  │   └── tasks
  │         ├── thread1
  │         ├── thread2
  │         └── ...
  └── other

  CPU 隔离能力详见 OceanBase 社区里的这篇博客《为什么资源隔离对HTAP至关重要》中 “OceanBase 资源隔离的实现效果” 部分。

磁盘 I/O 资源隔离

  observer 内所有的 IO 都是异步 IO，并且是绕过 OS 的 direct IO，磁盘带宽的隔离是通过控制 observer 提交异步 IO 的时间间隔来实现的。具体的控制策略比较复杂，这里不作详述。
  磁盘 IO 隔离能力详见 OceanBase 社区里的这篇博客《OceanBase 4.1 解读：给用户足够灵活简单的IO隔离体验》。

用户案例

超大型金融机构某某人寿

业务挑战

• 快速增长的业务使得数据大规模增长，传统集中式数据库面对海量数据，难以维持性能；
• 保险业务的处理复杂，单一业务需多个系统完成，调用链比其他行业的业务更长、更复杂，确保复杂集合大交易量的稳定是保险业务数据库的挑战。
• 期望实现数据库技术可控，摆脱对外依赖。与此同时，期望升级后实现数据库使用成本、维护成本的双降低。

解决方案

• 语法全面兼容，功能完全覆盖原有功能点，提供迁移工具与解决方案，避免上千万行代码重写，实现应用真正平滑迁移，高效完成核心数据库替换；
• OceanBase 多租户能力，实现动态弹性调整租户计算资源，敏捷的应对业务负载要求的变化，顺利通过季度、年度开门红等业务冲刺高峰；
• OceanBase 大集群管理模式，整合竖井式应用，集中化管控，平台化管理，统一资源分配，避免集中式架构的资源浪费。集群通过 F5 提供应用访问，多个集群使用同一套 OCP 集群进行运维管控。

用户收益

• 速度：金融行业数据库升级整合范围最大、速度最快的大型金融机构，升级整合超 300 套原数据库，覆盖全部业务系统，迁移数据量达数百 TB，数据库装机量超过 2 万服务器核数；
• 成本：平台化管理能力提升，整合竖井式应用，集中化管控，统一资源分配和运维，业务数据库容量瘦身 78%，具有相同业务承载能力的 OceanBase 数据库软硬件成本缩减 75%；
• 效率：分析型大数据加工处理能力提升 300%，实现一份数据既做交易又做分析，不仅提高业务决策效率，整体资源利用效率和处理能力大幅提升；
• 安全：实现 RPO=0 的高级别跨城市容灾能力，满足金融行业分布式技术架构转型要求，全链路透明加密，提高数据全链路防泄漏能力；
• 绿色：数据库服务器及存储机柜数量利用率提高 300%，设备功率下降至原有 1/3。经测算，全年可节约电力约近千万度，有力践行国家双碳战略。

多点 DMALL

业务挑战

  多点 DMALL 服务对象横跨国内、海外等众多零售商，在国内有物美、中百等大型商超，覆盖麦德龙、Seven Eleven 711 便利店等跨国零售商。同时，还为众多海内外品牌商提供服务，让品牌商、供应商、零售商能够链接起来，让数据和信息更好地流动，让服务对象能够更好地支撑服务 C 端用户。从生产商、品牌商、供应商，再到各个商场门店的零售商，最后到消费者，不难想象，超长的服务链路会产生超级庞大的数据量，系统的复杂度也将随着数据量呈指数级增长。在此背景下，多点零售 SaaS 系统数据库面临三大难题：

• 运维复杂度高：多点 DMALL 使用微服务架构，全流程业务环节多，系统应用规模大，对应数据库的数量超过了 500 个。且随着系统不断迭代，数据的规模还在持续增加，运维管理难度越来越大。
• 业务增长快，水平扩展需求增多：随着业务增的长，多点制定了出海战略，需要在海外展开业务，基于地区数据安全法的要求，需要独立部署一整套全新的系统去承接海外业务流量。在初始的部署阶段，对后期业务规模及数据增长速度是难以准确预估的。因此，数据库资源在初始阶段的分配就变得十分困难。为了节约成本，常见的做法是给到较少的部署资源。但很快多点发现，业务的快速增长，数据的增长特别迅猛，带给多点的是如何快速扩容这一难题。
• 需要在同一个集群中服务大量商家：便利店/连锁商超的 SKU（最小存货单位）规模，从几千到几万，多点很难做到给每个商家独立部署一套系统。因此，多点 SaaS 系统支持上百个中小商家客户，所有商家产生的数据，在底层共享数据库资源。还有一个显著特点，在多点系统中存在非常大的单个租户，比如大型连锁商超，多点希望能让大型连锁商超所在的租户与其他租户有一定的资源隔离。

解决方案

• OceanBase 的大集群模式，将多个单实例整合到 OceanBase 集群中，进行统一管理，灵活调度，有效提高资源利用率。
• 使用租户进行资源隔离，多个业务模块之间数据独立，按需透明升降配。
• 通过 OceanBase 集群强大丰富的 Leader 分布和读写路由策略，将蚂蚁集团多年沉淀的高并发最佳实践输出给用户。
• 借助 OMS ，在不停机的情况下全站业务向 OceanBase 实现高效快捷的迁移，业务仅需极少改造甚至零改造。
• 通过 OceanBase 强大的智能管控平台，典型问题自动分析和感知，运维效率大幅提升。

用户收益

• 基于大集群多租户，实现秒级的数据库实例资源扩缩容，在整体集群资源使用不变的前提下，稳定承载大量业务的高峰压力。
• 在解决了业务扩展性难题的同时，也大大降低了 DBA 的运维成本以及出错概率。在机房级容灾方面，实现 RPO = 0，RTO < 8s，稳定支撑多点上亿级的用户量。
• 基于 OceanBase 的高级压缩技术，在保证性能的同时，多点的数据存储空间相比原先节约了近 75%。同等硬件投入的前提下，多点可存储更多数据。
• OceanBase 高度兼容 MySQL 的 SQL、存储过程及触发器等高级特性，对传统数据库具备高兼容能力，让多点可以平稳、平滑迁移过往数据，保证在过渡时期的大量业务不受影响。