1：從管理員視角看，他創建的數據庫集群有多個Zone，比如3個Zone，分别在杭州、上海和北京，每個Zone又包含了多個OceanBase服務器，一般情況下各個Zone内的機器配置和數量是一緻的。所有這些就構成了各個業務需要使用的資源池。管理員可以根據業務情況，劃分成不同大小的資源池授予租戶使用，高要求的業務授予大資源池，低要求的業務授予小資源池。zone理解為可用區AZ，可以是城市、機房、或機架。每個zone中包括observer服務器提供計算及存儲資源。

2：從應用開發者視角看，他可以基于自己的業務規劃，向管理員申請租戶資源池，當然這個資源池不是固定不變的，是可以根據業務發展平滑擴容的。拿到租戶後，開發者可以創建數據庫、表、分區等操作，滿足應用對數據庫的各類要求。

集群由多個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上，它們自己會自動協商調度，對業務是無感知的。

一個集群由3個Zone以上組成，包含若幹台服務器，如此龐大的系統需要一個“大腦”來統一管理，RootService總控服務就是這樣一個“大腦”，它負責資源分配與調度、全局DDL、集群數據合并等全局事宜，是OceanBase的核心模塊。

比如擴容場景，新增一台服務器進入集群，原有哪個服務器應該割接哪個業務出來給這台新服務器，這些都是由RootService總控服務确定的。

RootService無需額外的軟硬件部署，一般與Zone内的一個OB Server合設，共用一台服務器。為了消除單點故障的風險，各個Zone都建議部署一個RootService總控服務，但隻有一個Zone的總控服務是“主”，其他Zone内的總控服務為“備”，當“主”出現故障的時候，“備”可以自動的接管整個服務。部署方式為一主多備，每個zone中選擇一台OBserver啟動rootserver服務。

租戶概念：

•将數據庫集群按指定規格（CPU、内存、存儲、TPS、QPS）劃分成多個資源池，分配給不同的租戶；

•租戶資源隔離策略：内存物理隔離；CPU邏輯隔離，數據隔離；

•一般一個應用占用一個租戶。

租戶特點：

租戶類似傳統數據庫的實例，它由系統租戶根據需要（比如說為了某個業務的需要）創建出來。在創建租戶的時候，除了指定租戶名字以外，最重要的是指定它占用的資源情況。租戶具有如下特性：

1. 可以創建自己的用戶（不同的用戶名和密碼）
2. 可以創建數據庫（database）、表（table）等所有客體對象
3. 有自己獨立的information_schema等系統數據庫
4. 有自己獨立的系統變量

如何定義資源池：首先定義資源規格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集群。