1：从管理员视角看，他创建的数据库集群有多个Zone，比如3个Zone，分别在杭州、上海和北京，每个Zone又包含了多个OceanBase服务器，一般情况下各个Zone内的机器配置和数量是一致的。所有这些就构成了各个业务需要使用的资源池。管理员可以根据业务情况，划分成不同大小的资源池授予租户使用，高要求的业务授予大资源池，低要求的业务授予小资源池。zone理解为可用区AZ，可以是城市、机房、或机架。每个zone中包括observer服务器提供计算及存储资源。
2：从应用开发者视角看，他可以基于自己的业务规划，向管理员申请租户资源池，当然这个资源池不是固定不变的，是可以根据业务发展平滑扩容的。拿到租户后，开发者可以创建数据库、表、分区等操作，满足应用对数据库的各类要求。
集群、Zone和OB Server
集群由多个zone组成，每一份数据在各个zone上都有一份完整的副本，且只有一份副本。这样保证任意一个zone级别故障不会影响数据及集群的运行。物理上zone可以对应不同的城市、或一个城市里面不同的机房、或一个机房内不同的机架。逻辑上讲，Zone就是给集群内的一批机器打上同一个tag，打了同样tag的服务器就归属于一个Zone。
Zone的个数一般大于3台，因为OceanBase采用Paxos协议，多数派要达成一致。至少3个Zone的话，当一个Zone故障后，剩下2个Zone还可以构成多数派，不影响业务。
OB Server是相对独立的，有自己的计算引擎和存储引擎，也会有部分数据。对业务而言，每台OB Server均是一台传统的集中式数据库，业务访问到这台OB Server后，如果需要访问的数据在其它OB Server上，它们自己会自动协商调度，对业务是无感知的。
rootService总控服务（RS）
一个集群由3个Zone以上组成，包含若干台服务器，如此庞大的系统需要一个“大脑”来统一管理，RootService总控服务就是这样一个“大脑”，它负责资源分配与调度、全局DDL、集群数据合并等全局事宜，是OceanBase的核心模块。
比如扩容场景，新增一台服务器进入集群，原有哪个服务器应该割接哪个业务出来给这台新服务器，这些都是由RootService总控服务确定的。
RootService无需额外的软硬件部署，一般与Zone内的一个OB Server合设，共用一台服务器。为了消除单点故障的风险，各个Zone都建议部署一个RootService总控服务，但只有一个Zone的总控服务是“主”，其他Zone内的总控服务为“备”，当“主”出现故障的时候，“备”可以自动的接管整个服务。部署方式为一主多备，每个zone中选择一台OBserver启动rootserver服务。
多租户机制，资源隔离，数据隔离
租户概念：
•将数据库集群按指定规格（CPU、内存、存储、TPS、QPS）划分成多个资源池，分配给不同的租户；
•租户资源隔离策略：内存物理隔离；CPU逻辑隔离，数据隔离；
•一般一个应用占用一个租户。
租户特点：
租户类似传统数据库的实例，它由系统租户根据需要（比如说为了某个业务的需要）创建出来。在创建租户的时候，除了指定租户名字以外，最重要的是指定它占用的资源情况。租户具有如下特性：
- 可以创建自己的用户（不同的用户名和密码）
- 可以创建数据库（database）、表（table）等所有客体对象
- 有自己独立的information_schema等系统数据库
- 有自己独立的系统变量
如何定义资源池：首先定义资源规格unit_config,指定资源的大小如1C8G、2C16G等
资源池的计算能力=unit_config*unit_num 分配给租户的资源规格乘以规格数量得出。
同时unit的分布也是和zone及observer有关的。一个租户可以有多个资源池，但是一个租户的某一个资源池对应的unit在一台observer只能有一个。
例如租户1授予资源规格为U1（2C8G）数量为1，那么对于一个三个zone的集群每个zone中一台observer来说，ob会自动的在每个zone中observer划分一个unit。如果集群包括5个zone那么需要在5个zone中的observer划分一个unit。
例如租户2授予资源规格为U1（2C8G）数量为2，那么对于一个三个zone的集群每个zone中一台observer来说，创建会失败，因为ob不允许一台observer上面同一个资源池有两个unit同时存在。如果每个zone中有两台机器那么就满足创建条件，即选择每台observer上面创建一个unit（3个zone-每个zone-2台observer）
每个resource pool在每个OB Server上只能有一个resource unit；如果unit_num大于1，每个zone内都必须有和unit_num对应数目的机器。
所以这个“Unit数量=1”的意思是各个Zone内分配几个资源，而不是一共分配几个资源，3个Zone的话就是3个资源，5个Zone的话就是5个资源，这样单个Zone的故障是不影响租户承载的业务的。同理可以看下黄色模块代表的租户2和绿色模块代表的租户3，“Unit数量”分别为2和3。
资源分配也不是静态的，可以随着业务的发展调整Unit的规格，比如从2C8G调整为4C16G，如果你把这个租户看成传统数据库的话，就是纵向扩展，或者调整Unit的数量，比如从1到3，就是横向扩展了。当然横向扩展也是有上限的，上限就是每个Zone内服务器数量的上限。
后面分享一下如何部署ob集群。
,
