第四章：OceanBase集群技术架构

1.Paxos协议与负载均衡

数据分区与分区副本

分区

1.当一个表很大的时候，可以水平拆分为若干个分区，每个分区包含表 的若干行记录。根据行数据到分区的映射关系不同，分为hash分区， List分区（按列表），range分区（按范围）等 2.每一个分区，还可以用不同的维度再分为若干分区，叫做二级分区 3.分区是OceanBase数据架构的基本单元，是传统数据库的分区表在分 布式系统上的实现

副本

1.为了数据安全和提供高可用的数据服务，每个分区的数 据在物理上存储多份，每一份叫做分区的一个副本 2.副本根据负载和特定的策略，由系统自动调度分散在多 个Server上。副本支持迁移、复制、增删、类型转换等 管理操作

支持三种副本，满足不同业务类型的需求

根据存储数据种类的不同，副本有几种不同的类型，以支持不同业务在在数据安全，性能伸缩性，可用性， 成本等之间进行取舍折中

全能型副本：也就是目前支持的普通副本，拥有事务日志，MemTable和SSTable等全部完整的数据和 功能。它可以随时快速切换为leader对外提供服务。

日志型副本：只包含日志的副本，没有MemTable和SSTable。它参与日志投票并对外提供日志服务， 可以参与其他副本的恢复，但自己不能变为主提供数据库服务。因为日志型副本所消耗的物理资源 （CPU、内存、磁盘）更少，它可以有效降低最后一副本机器的成本，进而降低整个集群的总体成本。

只读型副本：包含完整的日志，MemTable和SSTable等，但是它的日志比较特殊。它不作为paxos成 员参与日志的投票，而是作为一个观察者实时追赶paxos成员的日志，并在本地回放。这种副本可以在 业务对读取数据的一致性要求不高的时候提供只读服务。因其不加入paxos成员组，又不会造成投票成 员增加导致事务提交延时的增加。

类型	Log	MemTable	SSTable	数据安全
全能型	有，参与投票	有	有	高
日志型	有，参与投票	无	无	低
只读型	有，但不属于paxos组，只是listener	有	有	中

多副本一致性协议

• 以分区为单位组建Paxos协议组：每个分区都有多份副本（Replica），自动建立Paxos组，在分 区级用多副本保证数据可靠性和服务高可用，数据管理更加灵活方便。

• 自动选举主副本：OB自动生成多份副本，多副本自动选举主副本，主副本提供服务（如图黄色副 本供应用访问，蓝色副本用于备份）

                        

 自动负载均衡与智能路由

• 自动负载均衡：主副本均匀打散到各个服务器中，使 得各个服务器都能承载业务流量。(如图应用1、2、 3读请求分布路由到不同的OB Server）

• 每台OB Server相互独立：每台OB Server均可以独 立执行SQL，如果应用需要访问的数据在不同机器上， OB Server自动将请求路由至数据所在的机器，对业 务完全透明（如应用2->P6->P7/P8)

                          

 通过多副本同步Redo Log确保数据持久化

• Paxos组成员通过Redo-Log的多数派强同步， 确保数据的持久化

• Leader无需等待所有Follower的反馈，多数派 完成同步即可向应用反馈成功

查看表和分区的分布情况

表及分区的相关信息储存在这两个系统表中。

系统表：__all_virtual_meta_table，关键信息
• tenant_id
• table_id
• partition_id
• svr_ip
• role：1 – leader, 2 - follower

系统表：__all_virtual_table，关键信息
• table_id
• table_name

OB Proxy为应用提供智能路由服务，应用透明访问

高效路由器转发

对SQL做基本解析，确定对应Leader所在机器

反向代理，将请求路由至对应Leader；Leader位置无法确定时随机选择OB Server

轻量SQL解析+快速转发，保证高性能，单OB Proxy每秒转发百万次请求。

“非”计算节点，无状态

每个OB Proxy是一个“无状态”的服务进程，不做数据持久化，对部署位置无要求。

OB Proxy不参与数据库引擎的计算任务，不参与事务（单机or分布式）处理

多个OB Proxy之间无联系，可通过F5/SLB组成负载均衡集群

不需要独立服务器，可以与OB Server共用一台服务器，如果应用对实时性要求高，也可以将OB Proxy部署到应用服务器中。

                            

 

通过设置Primary Zone，将业务汇聚到特定Zone

                                        

配置：（z1,z2,z3)     意义：ZONE_1=ZONE_2=ZONE_3

主副本均匀分布到各机器

适合批处理场景，希望尽快跑完，不关注某一个sql的执行时间，期望让整体任务尽快完成。

                                        

 配置2：（z1;z2;z3)   意义：ZONE_1>ZONE_2>ZONE_3

主副本只在Zone1存在，Zone2和Zone3均是从副本

适合对时延敏感在线处理业务，业务量不大，不超过一台机器的处理能力，可以尽量避免跨服务器访问，从而降低时延。

                                        

配置3：（z1,z2,z3)   意义：（ZONE_1=ZONE_2)>ZONE_3

主副本均匀分布到Zone1和Zone2，Zone3均是从副本

适合三地五中心方案，将业务汇聚到距离较近的城市，距离较远的城市只承担从副本的角色。

通过为不同的租户配置不同的Primary Zone，可以将业务流量集中到若干Zone中，减少跨Zone及跨服务器 的操作。Zone List，逗号两侧优先级相同，分号左侧优先级高于右侧。

Primary Zone有租户、数据库和表不同的级别

如无特殊指定，自动继承上级对象的primary_zone：database继承租户的primary_zone设置， table继承database的primary_zone设置。

database和table可以指定各自的primary_zone，不必和上一级对象的设置保持一致；提供更加 灵活的负载均衡策略。

Table Group,将多个表的相同分区ID的主副本聚集在一个OB Server,减少分布式事务引入的开销

                                              

• 如果多个表的分区方式完全相同（分区类型、分区键个数、分区数量等） ，可以 在逻辑上将这些表归属到同一个Table Group中，以影响动态负载均衡的策略

• 同一个Table Group中的所有表，分区ID（partition_id）相同的所有分区，它们 的leader在同一个observer上；在不影响全局负载均衡的前提下，可有效减少分 布式事务引入的跨机访问开销

• 如果负载均衡被打破（服务器故障后、扩容缩容等），Table Group中的所有表会 作为一个整体来调整分区分布和leader分布

• 动态创建和删除，并且对上层应用完全透明

• 如果租户的unit_num=1且primary_zone只有一个zone，不需要tablegroup

Table Group举例

                        

• 假设一个集群有3个Zone，租户的Unit Num是2,表1和表2的Primary Zone是负载均衡的

• 对于某一个员工（emp_id）来说，他/她的员工信息数据和薪水数据，一 定在同一个observer上提供服务，比如employees(p1)和salaries(p1)

• employees表和salaries表组成一个Table Group

• Table Group中相同分区ID的主副本均在一台OB Server上

• 整体负载均衡没有被打破，每台OB Server均有主副本和从副本

• 如果Zone1-OB Server1故障，那么T1(P1）+T2(P1）将会整体迁移