OceanBase 架构学习--OB上手视频学习总结第二章 （OBCA）
OceanBase 架构学习--OB上手视频学习总结第二章 （OBCA）
一直提到框架学习法，其中主体的思想就是如何快速的学习某项数据库产品的知识。其中框架学习法里面有一条系统学习，系统学习是在给学习的知识搭建“骨架”，所以从这期起，开始搭建OceanBase学习的骨架。今年要和“申公豹”一样修炼岂可怠慢。
修炼岂可怠慢
这里先解释一下什么是6大学习法，怎么将知识变成一种理念的过程，首先知识的学习是要以兴趣为动力的，没有兴趣去学习是无法提高学习的效率和成效的，在有了兴趣去学习后，那么上来就要上逻辑法，将学习的知识分成小块，也就是我们习以为常的总分总的分，在学习中不断的通过重复记忆，提炼的方法加深记忆，在理解了知识后， 使用庞统法，来将知识和周边的常识进行关联，最后通过费曼学习法将知识铁桶话，最后一步就是将学到的知识进行知行合一，这就是将知识转变为自己常识的知识学习6大法。学习OB的兴趣和动力我有了，下面首先就要上的是逻辑法，和重复记忆法。
此篇为OceanBase 视频学习总结的第二篇：这篇主要是围绕OBCA 4.0课程中的第二章中的三个小结进行学习
1 集群基本概念 2 路由与负载均衡 3 高可用部署架构
image
OceanBase 集群的基本概念、路由与负载均衡以及高可用部署架构总结如下： 集群基本概念
1整体架构
从业务流的视角来看，OceanBase 分布式数据库的访问可以分成四个层级：
1 应用层
2 负载均衡层
3 数据库代理层
4 后端的存储层
从 OceanBase 内部架构来看，它是一个多节点、多副本并且读写分离的架构。
从租户的角度，或者从多租户架构的角度来看：
一个数据库集群内可以划分多个业务租户，不同的租户之间资源与数据是隔离的。租户资源是以资源池的形式进行分配，对应用来说就相当于是一个个独立的数据库实例.
从用户的角度看： 系统分为系统组合和用户租户，系统租户在集群创建时默认创建，主要用来管理整个集群和所有租户。
用户租户由用户主动创建的业务租户，由用户负责租户内数据库对象的管理和访问，承载用户的业务数据。从 V4.0.0 版本开始，引入了 Meta 租户概念。
因此，当前版本对用户可见的租户有三种类型：系统租户、用户租户以及 Meta 租户。
从OB数据库的类型看，分为商业版本和开源版本，从数据库的兼容性看，分为 ORACLE 和 MySQL。
image
image
OceanBase 的基本概念： 基本概念关键词
1 多租户架构：OceanBase 采用多租户架构，允许在一个数据库集群内划分多个业务租户，以此实现资源和数据的隔离. 每个租户的资源以资源池的形式进行分配，对于应用程序来说，这就像是独立的数据库实例。
2 集群： 在物理层面上，OceanBase 集群分布在一个或多个数据中心的多台 observer 服务器上，这些服务器负责数据库的存储和计算服务。
3 可用区： 可用区是一个逻辑概念，每个可用区包含一份完整的数据副本. 例如，一个 OceanBase 数据库集群可能包含三个可用区，每个可用区由两台 observer 承载一份完整的数据副本。
4 Observer： Observer 是集群中承载数据、负责存储并提供计算服务的服务器. Observer 可以是物理服务器、ECS 或 Docker 容器。在 OceanBase 集群中，每个 observer 都可以同时提供存储和计算服务
5 数据副本：为了保证数据与服务的高可用性，OceanBase 数据库会将同一份数据拷贝到多个可用区，每一份拷贝被称为一个副本. 在多个副本中，只有一个可以执行写操作，这个副本被称为主副本（Leader），其余的则为从副本（Follower）. 从副本可以提供对数据一致性要求较低的读操作。
6 日志流： OceanBase 集群的多个副本之间通过同步事务日志来完成数据同步，这些在多个副本之间同步的事务日志被称为日志流。
7 paxos 协议： 多副本之间日志流的同步依赖 Paxos 分布式一致性协议. 在更新数据时，对应的事务日志需要在多数派的副本同步成功才算提交完成. 副本的 leader 选举也依赖 Paxos 协议。
8 Root Service： Root Service 是 OceanBase 的核心模块，提供资源管理、容灾、负载均衡和 DDL 管理等功能. RS 负责租户的资源分配与管理，集群与租户的扩缩容，以及将租户的资源单元和 leader 节点合理地分布在不同的 observer 节点上，以达到负载均衡的目的。
image
OceanBase集群涉及租户和集群的扩缩容，并通过修改租户的资源单元个数来改变可用区下服务于该租户的observer个数。
OceanBase通过Root Service(RS)实现自动负载均衡能力，从而在数据库水平扩缩容与创建分区等场景下，达到各个服务节点上分区数与存储容量的均衡以及不同中间分区数量的均衡。
以下是关于OceanBase集群扩缩容的一些关键点：
资源管理：Root Service（RS）负责租户的资源分配与管理，集群与租户的扩缩容等.
负载均衡：RS将租户的资源单元以及leader节点合理地分布在不同的observer节点上，以达到负载均衡的目的。
水平扩缩容：通过修改租户的资源单元个数来改变每一个可用区下服务于该租户的observer个数。
自动负载均衡：在数据库水平扩缩容与创建分区的场景下，可以达到各个服务节点上分区数与存储容量的均衡，以及不同中间分区数量的均衡。
仲裁服务：在3D5中心的部署架构里，可以使用仲裁服务来降低第三个城市的数据中心的建设成本， 仲裁服务是 OceanBase V4 版本引入的一种新的高可用机制. 仲裁服务作为中立的第三方，只参与副本 leader 选举相关的投票，不同步事务日志和数据。
·
数据副本与高可用 数据可以跨越多个数据中心，集群中的数据可以有多个副本。当集群有多个副本时，这是一个分布式集群，数据副本是一个完整的数据集合。OceanBase 通过日志流来实现多个副本的协同。当一个副本出现故障，其他副本可以继续提供数据的读写服务，以此实现数据库的高可用。
可用区和租户的知识详解：
定义：可用区（Zone）是一个逻辑概念，代表数据副本的集合. 每一个可用区都包含一份完整的数据副本。
多副本集群：在 OceanBase 数据库集群中，一个典型的配置是包含三个可用区，例如 Z1、Z2 和 Z3，这构成一个三副本集群。
Observer 节点：每个可用区下通常有多台 Observer 服务器，用于承载完整的数据副本. 例如，一个可用区下可能有两台 Observer 节点来承载数据副本。
Paxos 协议：OceanBase 分布式数据库使用 Paxos 多数派协议来保证多个副本之间数据的一致性. 这意味着数据的更新必须在多数派的副本中完成同步. 对于三副本集群，多数派副本数是2。
Primary Zone 设置：OceanBase 允许设置租户级别的 Primary Zone，将租户的 Leader 副本分配到指定的可用区内，从而影响业务流量的分布. 例如，将 Primary Zone 设置为 ZONE1，则该租户所有表或分区的 Leader 副本均在 ZONE1，数据访问均在 ZONE1 内完成.
优先级设置：Primary Zone 可以设置优先级，使用分号分隔表示不同的优先级，逗号分隔表示相同的优先级. 例如，"ZONE1; ZONE2; ZONE3" 表示 ZONE1 > ZONE2 > ZONE3 的优先级，而 "ZONE1, ZONE2; ZONE3" 表示 ZONE1 等于 ZONE2 且都高于 ZONE3 的优先级。
数据分布和流量控制：通过合理设置 Primary Zone，可以控制数据分布和业务流量，在多地多中心的部署场景中尤其有用。
从用途上，租户可以分为系统租户和用户租户：
系统租户：在集群创建时默认创建，主要用于管理整个集群和所有租户。系统租户的数据是集群私有的，不与其他租户共享数据，并且是MySQL模式的租户。Root Service (RS) 作为系统租户的内置服务运行在系统租户的leader节点上。
用户租户：由用户主动创建的业务租户，用户负责租户内数据库对象的管理和访问，承载用户的业务数据。
Meta租户：存储管理用户租户的Meta信息，例如租户的位置项、副本位置信息以及租户管理相关的信息等。Meta租户是用户租户的影子租户，OceanBase自动为每一个用户租户创建一个Meta租户，其生命周期和用户租户保持一致。（V4版本）
租户ID：系统租户的ID固定不变，用户租户的ID从1002开始分配，且为偶数，比用户租户ID小1的ID会分配给对应的Meta租户。
租户命名：系统租户名为SYS，不可修改；用户租户的名字可以修改；Meta租户的名称由系统指定，不可修改，规则为Meta加用户租户的ID。
数据属性：系统租户包含集群的私有数据，Meta租户包含租户的私有数据，用户租户保存用户的真实业务数据。
访问方式：系统租户、用户租户均可以连接访问Meta租户。 租户隔离： 租户隔离是多租户架构的关键，OceanBase通过以下方式实现租户隔离：
资源隔离：租户之间除了数据隔离外，CPU资源、内存资源以及I/O资源也是隔离的。
数据隔离：每个租户相当于一个独立的MySQL实例，租户之间的数据是隔离的。
权限管理和命名空间隔离：Database是数据库对象的集合，用于权限管理和命名空间隔离，是一个逻辑概念。
多租户的优势：多租户架构适用于微服务架构和云上的SaaS服务商，可以平衡隔离性和成本，并且大小租户可以独立进行扩缩容。
image
租户扩缩容与日志副本日志流部分详解
1 租户扩缩容要点
资源管理：Root Service（RS）负责租户的资源分配与管理，集群与租户的扩缩容等。
负载均衡：RS将租户的资源单元以及leader节点合理地分布在不同的observer节点上，以达到负载均衡的目的。
水平扩缩容：通过修改租户的资源单元个数来改变每一个可用区下服务于该租户的observer个数。
自动负载均衡：在数据库水平扩缩容与创建分区的场景下，可以达到各个服务节点上分区数与存储容量的均衡，以及不同中间分区数量的均衡。
副本--日志流---Paxos协议这三者的关系式
OceanBase通过多副本实现高可用性，日志流用于副本间的数据同步，而Paxos协议是保证数据一致性的基础
ceanBase通过多副本实现高可用性，日志流用于副本间的数据同步，而Paxos协议是保证数据一致性的基础. 以下是关于副本、日志流和Paxos协议的要点：
副本 (Replicas)
OceanBase数据库将同一份数据拷贝到多个可用区，每一份拷贝被称为副本。
多个副本中只有一个主副本（Leader），负责执行写操作，其他是从副本（Follower），可以提供对数据一致性要求较低的读操作。当主副本发生故障时，OceanBase会自动从从副本中选举新的主副本。副本的数量通常为奇数，如3副本或5副本，以满足Paxos协议的多数派要求。
日志流 (Log Stream)
OceanBase集群的多个副本之间通过同步事务日志来完成数据同步，这些同步的事务日志称为日志流。
在V4版本中，OceanBase像单机数据库一样处理事务日志，将一个租户在同一台observer下的所有leader分区作为一个整体来写事务日志，并作为一个日志流在多个副本之间进行同步，这被称为单机日志流。在单机日志流的架构下，事务的参与者从一个个分区变成了observer节点。扩缩容时，相应的日志流需要做拆分，并分布到更多的observer节点上去。
Paxos 协议
Paxos是OceanBase分布式架构的基础，多副本之间日志流的同步离不开Paxos分布式一致性协议。在对数据进行更新时，对应的事务日志需要在大多数副本同步成功才算提交完成。OceanBase通过Paxos协议实现分区级别的高可用性，可以简单理解为一个Paxos组包含一个分区的3个副本，包括一个主副本和2个从副本。Paxos协议可以确保事务的协调者和参与者都是多副本、高可用的，副本的leader选举也依赖Paxos协议。
OceanBase 数据库访问代理的概念和详解：
OceanBase数据库访问代理（ODP），也称为OBProxy，在OceanBase的分布式架构中扮演着关键角色，它为应用提供统一的数据访问入口，并负责实现自动的访问路由服务。 以下是关于OceanBase数据库访问代理 (ODP) 的一些关键要点：
统一访问入口：在没有ODP的情况下，应用服务器需要感知数据的分布位置，并直接连接到不同的Observer节点来实现业务访问，这显然是不现实的。ODP的出现，使得应用只需连接到ODP，即可访问整个分布式数据库集群，无需关心数据存储在哪个Observer节点上。
反向代理：ODP作为数据库服务的反向代理，能够感知数据库集群内表和分区的位置，并将不同的数据访问请求发送到对应的Observer节点上。
高可用性：为了避免ODP故障导致数据库访问的不可用，通常会部署多个ODP节点，实现ODP的高可用。
无状态服务：ODP是一个无状态的服务进程，不做数据保留，多个OBProxy之间也没有关联，互相不感知。
主要能力：
数据库服务反向代理：感知数据库集群内表和分区的位置，将数据访问请求发送到对应的Observer节点。
Observer状态感知：可以自动屏蔽问题节点，避免将SQL请求发送到故障节点上。
轻量级SQL解析：仅对SQL做轻量化的解析，不做数据的加工处理，从而提供非常高的性能。单个OBProxy进程每秒可提供百万次的SQL路由服务.
连接管理：将应用到数据库的连接分成两段，一段是应用到OBProxy的连接，一段是OBProxy到Observer的连接，从而提供连接管理能力.
负载均衡：当部署了多个OBProxy服务时，需要在应用与数据库代理之间部署负载均衡设备，为所有OBProxy节点提供统一的VIP或者域名，让应用统一连接这个VIP，从而将并发的应用请求按照设定的规则分散到不同的OBProxy节点上，实现负载均衡与高可用
Primary Zone 的作用和定义：
Primary Zone 是 OceanBase 中一个用于影响业务流量分布的重要配置。 通过设置租户的 Primary Zone，可以将租户的 leader 副本分配到指定的可用区内，从而控制业务流量的分布。 以下是关于 Primary Zone 的一些关键要点：
定义：Primary Zone 是一个可用区（Zone）的集合。
作用：通过设置 Primary Zone，可以将租户的 Leader 副本分配到指定的可用区内，从而影响业务流量的分布。
流量控制：
例如，将租户的 Primary Zone 设置为 ZONE1，则该租户所有表或分区的 Leader 副本均在 ZONE1，数据的访问均在 ZONE1 内完成，业务请求也只会路由到 ZONE1。
优先级设置：
Primary Zone 可以设置优先级，使用分号 ; 分隔表示不同的优先级，逗号, 分隔表示相同的优先级。
例如，ZONE1; ZONE2; ZONE3 表示 ZONE1 > ZONE2 > ZONE3 的优先级。
ZONE1, ZONE2; ZONE3 表示 ZONE1 等于 ZONE2 且都高于 ZONE3 的优先级。
流量均分：
如果要把业务流量均分到 ZONE1 和 ZONE2，而不分配到 ZONE3，那么需要设置 Primary Zone 为 ZONE1, ZONE2; ZONE3。
如果要把业务流量均分到所有 Zone，那么需要设置 Primary Zone 为 ZONE1, ZONE2, ZONE3。
多地多中心部署：Primary Zone 的设置在多地多中心的部署场景中尤其有用，可以基于性能的考虑，将特定的业务流量聚集到特定的数据中心或者可用区。
无法完全避免跨节点数据访问：当租户的 Zone 多于一个 Zone 时，或者租户的 Primary Zone 只有一个，但是一个 Zone 内有多个跨机房的节点，Primary Zone 的设置并不能完全避免跨节点数据访问的问题。
什么是表组，表组的定义属性等概念
表组（Table Group） 功能用于将业务相关的表或分区汇聚到相同的节点，以便更精细地控制数据分布和业务流量。
以下是关于如何使用表组（Table Group）将业务相关的表或分区汇聚到相同节点的一些关键点：
表组的定义：表组提供了一种能力，按照一定的规则将表组内的表或分区进行聚合。
表级属性：表组是表级别的属性，可以在创建表或者修改表时指定表所在的表组。
Sharding 模式：表组根据其定义的 Sharding 模式的不同，可以对表组内的表和分区进行不同程度的聚集。 OceanBase 表组提供三种 Sharding 模式：SHARDING=NONE、SHARDING=DUPLICATED和SHARDING=PARTITION.
SHARDING=NONE：最宽松的标准模式，不要求表组内表的分区方式相同，即可以包含分区表，也可以包含非分区表。
SHARDING=DUPLICATED：OceanBase 会将表组内的所有表和分区都聚集在相同的 Observer 上，它们的 leader 副本也聚集在同一台 Observer 上，对于应用来说，表组内的表提供了类似集中式数据库的访问性能。
SHARDING=PARTITION：对表组内的表的分区方式有要求，按照分区号对表组内的表进行相应的聚集。
聚集效果：对于SHARDING=DUPLICATED模式，OceanBase 会将表组内的所有表和分区都聚集在相同的 Observer 上，它们的 Leader 副本也聚集在同一台 Observer 上。对于应用来说，表组内的表提供了类似集中式数据库的访问性能。 因此，通过将 Sharding 模式设置为 SHARDING=DUPLICATED，可以将业务相关的表分区汇聚到相同的节点上，从而优化性能。
OceanBase的负载均衡具有以下特点：
Root Service (RS) 负载均衡：OceanBase集群依赖Root Service总控服务来实现分布式架构下的高可用能力. RS作为系统租户的内置服务，提供负载均衡的职能，将租户的资源单元以及leader节点合理地分布在不同的observer节点上，达到负载均衡的目的。
自动负载均衡能力：OceanBase通过RS服务实现了自动的负载均衡能力。在数据库水平扩缩容与创建分区的场景下，可以达到各个服务节点上分区数与存储容量的均衡，以及不同中间分区数量的均衡。
OBProxy 负载均衡：当部署了多个OBProxy服务时，需要在应用与数据库代理之间部署负载均衡设备，为所有的OBProxy节点处于统一的VIP或者域名，让应用统一连接这个VIP。这样可以将并发的应用请求按照设定的规则分散到不同的节点上，实现负载均衡与高可用。
单机分布式一体化架构下的负载均衡：OceanBase在分布式部署的时候，可以自动地进行负载均衡。
容灾能力和高可用方案比较：
无需停机扩展：
无论是单机转数据库，还是垂直扩展增加单机的规格，或是水平扩展增加 Zone 的节点数或增加 Zone 的数量，OceanBase 都不需要停机停服，对上层业务无感知。
自动故障恢复：
OceanBase 具有自动故障恢复能力，当包含 Leader 副本的 Observer 节点发生故障时，会自动进行选举操作，从 Follower 副本中选出新的 Leader 继续提供服务。
如果发生故障的 Observer 节点只包含 Follower 副本，只要剩余的副本数依然满足多数派的要求，节点故障对数据库集群和业务访问均没有影响。
OceanBase 提供自动补副本的能力，如果某个 Observer 节点出现故障，且故障时间达到一定的阈值，OceanBase 会将故障节点永久下线，并将故障节点上的副本剔除，然后在同一个可用区内的其他 Observer 节点上重建这些副本
多副本机制：
OceanBase 通过将同一份数据拷贝到多个可用区来实现数据库的高可用。
每个可用区包含一份完整的数据副本
多个副本中，只有一个是主副本（Leader），负责写操作，其他的为从副本（Follower），提供对数据一致性要求较低的读操作。
当主副本出现故障时，OceanBase 会自动从从副本中选举出新的主副本。
仲裁服务：
OceanBase V4 版本引入了仲裁服务，作为一种新的高可用机制。
仲裁服务代表中立的第三方，只参与副本 Leader 选举相关的投票，不同步事务日志和数据，资源要求非常低。仲裁服务还提供集群副本数自动升降级的能力。
OceanBase 中 RPO 和 RTO 指标的内容如下：
RTO（Recovery Time Objective，服务恢复时间目标）：指的是数据库在发生故障之后，需要经过多久时间才能恢复对外服务。RTO 的实际意义是当发生故障之后，数据库需要经过多久时间才能恢复对外服务。通常数据库故障恢复的 RTO 总是大于 0 的。
RPO（Recovery Point Objective，数据恢复目标）：指的是数据库的数据恢复目标，代表了服务的可用性。RPO 的实际意义是，当发生故障之后，数据库可能丢失的数据的时间范围是多少。RPO=0 时，表示没有数据的丢失。
OceanBase 的 RPO 和 RTO：
OceanBase 原生分布式架构可以满足金融行业的 6 级容灾标准，也是最高的容灾标准。
在 V4 版本，OceanBase 进一步提升了高可用能力，在数据零丢失及 RPO 等于零的基础上，将服务恢复时间缩短到了 8 秒以及 RTO<8 秒，树立了行业的新标准。
与传统集中式数据库相比，OceanBase 在高可用能力的优势最重要的一点是 RPO=0，数据零丢失。在多副本的架构下，发生少数派故障不会导致数据丢失。
OceanBase 有自动的容灾恢复和负载均衡机制，可以在少数派故障发生后，在 8 秒钟之内完成 leader 副本的切换和服务的恢复
OceanBase的自动补副本具备以下特点：
自动触发：如果某个Observer节点出现故障，并且故障时间超过设定的阈值，OceanBase会将该故障节点永久下线，并从集群中移除该节点上的副本。
副本重建：OceanBase会在同一个可用区内的其他Observer节点上重建这些副本。由于一个可用区内只能有一个副本，补副本操作只能在发生故障的可用区内进行。
资源依赖：副本是否能够成功重建，取决于可用区内正常运行的Observer节点上是否有足够的资源。
目的：在leader副本重新选举后，集群在缺失副本的情况下运行，为了避免再次发生宕机故障导致集群不可用，OceanBase提供自动补副本的能力。
OceanBase 的同城双中心主备、同城三中心仲裁和三地五中心仲裁的容灾部署方案具有以下特点：
同城双中心主备互备架构：
在机房 IDC E1 的 OceanBase 集群 1 中创建主租户 1，并在机房 IDC2 的 OceanBase 集群 2 中创建主租户 2。在两个集群中分别创建对方集群的备租户。既实现了传统主备库的高可用，又解决了传统备库无法提供业务服务的问题。
同城三中心仲裁高可用部署：
可以在每一个中心都部署全功能副本，构建一个三副本或五副本的集群。也可以在第三中心只部署仲裁服务，构建一个 2F1A 或 4F1A 的集群。使用仲裁服务可以大幅降低第三中心的建设成本，因为仲裁服务对资源和网络带宽的要求很低。
三地五中心仲裁架构：
最极致的容灾架构，可以应对城市级灾难。当一个数据中心甚至一个城市发生故障时，仍然有多数派的副本可用，保证集群的高可用。可以使用仲裁服务来降低第三个城市的数据中心的建设成本。如果出现中心级故障，比如 IDC1 发生断电，仍然有三个全功能副本可用，满足多数派要求，所以不会导致集群不可用。如果出现城市级故障，比如主城市 1 类的 IDC1 和 IDC2 同时不可用，主城市 2 里面的 IDC3 和 IDC4，加上仲裁服务，依然满足多数派的要求，不会导致集群不可用。仲裁服务检测到同一个城市的两个副本均出现故障后，会自动进行降副本的操作，将 4 个副本加仲裁降级为 2 个副本加仲裁。
本文分享自 AustinDatabases 微信公众号，前往查看
如有侵权，请联系 cloudcommunity@tencent.com 删除。
本文参与 腾讯云自媒体同步曝光计划 ，欢迎热爱写作的你一起参与！
腾讯云开发者
