我们先从整体上看下 OceanBase 产品家族的几个主要产品：
首先，最核心的就是 OceanBase 数据库内核了，它通过 Paxos 协议保证了高可用性，它可以兼容 MySQL 和 Oracle，同时支持 HTAP，即它即可以用于 OLTP 业务，也可以用于 OLAP业务。物理上看，OceanBase 数据库运行在很多台服务器上，组成一个大的集群。(
注：OLTP是传统的关系型数据库的主要应用，主要是基本的、日常的事务处理，例如银行交易。
OLAP是数据仓库系统的主要应用，支持复杂的分析操作，侧重决策支持，并且提供直观易懂的查询结果。
总的来说，
OLTP就是面向我们的应用系统数据库的，OLAP是面向数据仓库的。)
OceanBase 给运维者提供 OCP 工具平台，图形化的界面，帮助管理员更好的完成日常的集群管理、租户管理、监控告警、性能诊断等任务。
OceanBase 给开发者提供 ODC 工具平台，图形化的界面，帮助开发者更好的完成数据库连接管理、数据库对象管理、存储过程开发调试、导入导出等任务。
为了方便快捷的进行数据迁移，OceanBase 还提供了 OMS 数据库迁移平台，既可以从数据仓库订阅数据，也可以从异构的数据库里（比如 DB2、Oracle、MySQL）进行数据迁移、回滚等。
OceanBase 支持多种部署方式。
OceanBase 已经部署到阿里云公有云上，而且是采用两地三中心的高可用形式部署的，用户可以直接在阿里云订购服务，即买即用。
OceanBase 已经包含在阿里云专有云 3.5 以上版本，如果企业使用了阿里云的专有云，可以选择启动 OceanBase。
如果企业已经建设了自己的基础设施，OceanBase 也可以独立部署。
为了达到更好的性能，建议 OceanBase 采用独立部署模式。OceanBase 服务器需要 3 台以上，最低的性能要求是 32C，128G，1.2TB 存储，当然为了达到更高的性能，建议配置为32C，256G，2TB 存储。实验环境可以不用这么高配置的机器，如果单机运行，可以使用 2C8G以上的服务器；如果集群部署，推荐使用 4C16G 以上服务器。
OCP 服务器是管理服务器，不需要那么多服务器，可以 1 台单机部署，为了追求更高的性能和可靠性，也可以 3 台部署 。
同时，为了更好的拥抱国产技术生态，OceanBase 积极适配国产化 CPU 及操作系统：
CPU 方面：除了支持 Intel X86 系列 CPU 外，支持如下国产 CPU（海光、海思、飞腾等）。
操作系统方面：除了支持 CentOS、Red Hat、SUSE、Debian/Ubuntu 等 Linux 操作系统外，还支持如下国产 Linux 操作系统，包括 AliOS、中标麒麟 NeoKylin、银河麒麟 Kylin 等。
OceanBase 一般的安装部署流程是：
第一步：首先需要对所有服务器和操作系统进行一系列的设置，使得服务器的环境适合部署 OceanBase；
第二步：部署 OCP，OCP 部署完成后可以使用图形化的界面完成后续安装部署；
第三步：通过 OCP 来部署 OceanBase 集群；
第四步：通过 OCP 来部署 OB Proxy；
第五步：创建租户，以及租户内的数据库、表等等；
最后，可以根据业务需要部署 OMS、ODC、备份恢复等其他组件。
OceanBase 部署完成并创建完租户后。OceanBase 支持 2 种客户端工具，用于连接数据库，对数据库进行日常的管理。一种是黑屏工具，包括 MySQL 客户端和 OceanBase 专有的客户端。OceanBase 专有的客户端工具可以同时访问 MySQL 租户和 Oracle 租户，是比较推荐的黑屏客户端工具。MySQL客户端只支持访问 MySQL 租户。第二种是白屏工具，包括 OceanBase 云平台 OCP，OceanBase 开发者中心 ODC，通过这些图形化的工具，DBA 和开发者可以更好的连接、使用 OceanBase 数据库。
上图是所有的基础概念以及这些概念之间的关系。更好的理解
OceanBase 的产品技术架构。
从管理员视角看，他创建的数据库集群有多个 Zone，比如 3 个 Zone，分别在杭州、上海和北京，每个 Zone 又包含了多个 OceanBase 服务器，一般情况下各个 Zone 内的机器配置和数量是一致的。所有这些就构成了各个业务需要使用的资源池。管理员可以根据业务情况，划分成不同大小的资源池授予租户使用，高性能要求的业务授予大资源池，低性能要求的业务授予小资源池。 从应用开发者视角看，他可以基于自己的业务规划，向管理员申请租户资源池，当然这个资源池不是固定不变的，是可以根据业务发展平滑扩容的。拿到租户后，开发者可以创建数据库、表、分区等操作，满足应用对数据库的各类要求。
首先是集群、Zone 和 OB Server 之间的关系。
一个集群由多个 Zone 组成，每一份数据在各个 Zone 上都有一份副本，而且只能有一份副本，这样一个 Zone 的故障不会影响业务正常运行和数据的完整性。物理上讲，不同的 Zone可以对应不同的城市，如杭州、上海和深圳；也可以对应一个城市的不同机房，如杭州石桥机房、滨江机房、西湖机房等。也可以对应一个机房的不同机架，从而实现不同级别的容灾。逻辑上讲，Zone 就是给集群内的一批机器打上同一个 tag，打了同样 tag 的服务器就归属于一个 Zone。Zone 的个数一般大于 3 台，因为 OceanBase 采用 Paxos 协议，多数派要达成一致。至少 3 个 Zone 的话，当一个 Zone 故障后，剩下 2 个 Zone 内的副本依然还可以构成多数派，不影响业务。当然，如果有足够的投资，5 个 Zone 会提供更高的可靠性，比如网商银行的三地五中心五副本的方案。OB Server 是相对独立的，有自己的计算引擎和存储引擎，也会有部分数据。对业务而言，每台 OB Server 均是一台传统的集中式数据库，业务访问到这台 OB Server 后，如果需要访问的数据在其它 OB Server 上，它们自己会自动协商调度，对业务是无感知的。
一个集群由 3 个 Zone 以上组成，包含若干台服务器，如此庞大的系统需要一个“大脑”来统一管理，RootService 总控服务就是这样一个“大脑”，它负责资源分配与调度、全局 DDL、集群数据合并等全局事宜，是 OceanBase 的核心模块。 比如扩容场景，新增一台服务器进入集群，原有哪个服务器应该释放哪个业务出来给这台新服务器，这些都是由 RootService 总控服务确定的。RootService 无需额外的软硬件部署，一般与 Zone 内的一个 OB Server ，共用一台服务器。为了消除单点故障的风险，各个 Zone 都建议部署一个 RootService 总控服务，但只有一个 Zone 的总控服务是“主”，其他 Zone 内的总控服务为“备”，当“主”出现故障的时候，“备”可以自动的接管整个服务。
接下来我们介绍下租户的概念，集群多个服务器组成了一个大的资源池，系统会根据各个租户的要求，创建与之对应的虚拟资源池给租户使用，资源池包括指定规格的 CPU、内存、存储、TPS、QPS 等。租户之间资源是相互隔离的，内存是物理隔离、CPU 是逻辑隔离，避免租户之间争抢资源。一般一个应用占用一个租户。这个概念跟虚拟机比较类似，将一个庞大的物理资源虚拟成多个逻辑资源，彼此互相隔离。每个租户跟传统数据库实例的概念比较类似，租户可以创建自己的用户、数据库、表等对象。有自己独立的系统变量。使得租户可以更好的满足业务个性化的需求。系统租户保存系统表，一般 ID 是 1000 以内。剩下是业务租户，创建租户时候必须指定是MySQL 模式还是 Oracle 模式。
那么租户的虚拟资源池是如何分布在各个 Zone 及 OB Server 内的呢？会不会集中到某个Zone 或者某个 OB Server 里面，当 Zone 故障或者这台服务器故障后，导致租户无法正常提供业务呢。这一页会做详细介绍。 首先，我们需要定义一个资源规格，比如资源规格 U1=2C8G。这只是定义了一个 2C8G 的资源规格，并没有真正创建资源池。 然后创建一个资源池并授予给租户 1，这个资源池的定义是：Unit=U1，Unit 数量=1。Unit=U1 这个比较好理解，就是该租户的每个资源模块的规格都是 2C8G。这个“Unit 数量”怎么理解呢？是指这个租户只有 1 个资源么？不是的，我们可以看这个图上，蓝色方块的数量是 3 个，说明租户 1 有 3 个资源，分布在 Zone1、Zone2 和 Zone3，每个 Zone 都有 1 个资源。所以这个“Unit 数量=N”的意思是各个 Zone 内分配 N 个资源，而不是一共分配 N 个资源，若 N=1，3 个 Zone 的话就是 3 个资源模块，5 个 Zone 的话就是 5 个资源模块，这样单个 Zone 的故障不影响租户承载的业务。同理可以看下黄色模块代表的租户 2 和绿色模块代表的租户 3，“Unit 数量”分别为 2 和 3，意味着每个 Zone 将为他们分配 2 个和 3 个服务器，在每个服务器上分配一个 2C8G 的资源模块给租户。 如果一个 Zone 内有很多服务器，租户的资源模块是分布在 Zone 内的各个 Server 中的，它的位置不是恒定不变的，会在 Zone 内各个 OB Server 中漂移（比如服务器故障或者有新扩容的服务器等）
当然，这个资源大小和数量也不是静态的，可以随着业务的发展调整 Unit 的规格，比如从2C8G 调整为 4C16G，如果你把这个租户看成传统数据库的话，就是纵向扩展，或者调整 Unit的数量，比如从 1 到 3，就是横向扩展了。当然横向扩展也是有上限的，上限就是每个 Zone内服务器数量的上限。
因此，管理员需要实时了解集群资源水位情况，比如剩余多少 CPU 资源、剩余多少内存资源。这样当有新的业务需要租户，或者租户需要扩容时，管理员可以给出合适的建议（是使用大的资源规格+少的资源数量，还是使用小的资源规格+多的资源数量）。如果系统找不到足够的资源，资源池创建的任务会失败，管理员需要扩展扩容集群规模。
