OBCA 备考：第四章：OceanBase集群技术架构 --Paxos协议与负载均衡
最近公司组织参加obca和 obcp考试，现在整理分享一波OBCA的备考资料。
一、数据分区与分区备份
1.分区
Ø当一个表很大的时候，可以水平拆分为若干个分区，每个分区包含表的若干行记录。根据行数据到分区的映射关系不同，分为hash分区，List分区（按列表），range分区（按范围）等
Ø每一个分区，还可以用不同的维度再分为若干分区，叫做二级分区
Ø分区是OceanBase数据架构的基本单元，是传统数据库的分区表在分布式系统上的实现
2.备份
Ø为了数据安全和提供高可用的数据服务，每个分区的数据在物理上存储多份，每一份叫做分区的一个副本。
Ø副本根据负载和特定的策略，由系统自动调度分散在多个Server上。副本支持迁移、复制、增、删、类型转换等管理操作。
如下：交易记录表，按照用户ID分为3个hash分区（红、蓝、黄），每个一级hash分区再按照交易时间分为4个range分区。
3.支持三种副本，满足不同业务类型的需求
根据存储数据种类的不同，副本有几种不同的类型，以支持不同业务在在数据安全，性能伸缩性，可用性，成本等之间进行取舍折中
Ø全能型副本：也就是目前支持的普通副本，拥有事务日志，MemTable和SSTable等全部完整的数据和功能。它可以随时快速切换为leader对外提供服务
Ø日志型副本：只包含日志的副本，没有MemTable和SSTable。它参与日志投票并对外提供日志服务，可以参与其他副本的恢复，但自己不能变为主提供数据库服务。因为日志型副本所消耗的物理资源（CPU、内存、磁盘）更少，它可以有效降低最后一副本机器的成本，进而降低整个集群的总体成本
Ø只读型副本：包含完整的日志，MemTable和SSTable等，但是它的日志比较特殊。它不作为paxos成员参与日志的投票，而是作为一个观察者实时追赶paxos成员的日志，并在本地回放。这种副本可以在业务对读取数据的一致性要求不高的时候提供只读服务。因其不加入paxos成员组，又不会造成投票成员增加导致事务提交延时的增加
类型 |
LOG |
MemTable |
SSTable |
数据安全 |
全能型 |
有，参与投票 |
有 |
有 |
高 |
日志型 |
有，参与投票 |
无 |
无 |
低 |
只读型 |
有，但不属于paxos组，只是listener |
有 |
有 |
中 |
Ø一个分区在一个zone中最多有一个全功能或日志型副本
Ø只读型副本在同一个zone可以有多个
4.多副本一致性协议
Ø以分区为单位组建Paxos协议组：每个分区都有多份副本（Replica），自动建立Paxos组，在分区级用多副本保证数据可靠性和服务高可用，数据管理更加灵活方便
Ø自动选举主副本：OB自动生成多份副本，多副本自动选举主副本，主副本提供服务（如图黄色副本供应用访问，蓝色副本用于备份）
5.自动负载均衡与智能路由
Ø自动负载均衡：主副本均匀打散到各个服务器中，使得各个服务器都能承载业务流量。(如图应用1、2、3读请求分布路由到不同的OB Server）
Ø每台OB Server相互独立：每台OB Server均可以独立执行SQL，如果应用需要访问的数据在不同机器上，OB Server自动将请求路由至数据所在的机器，对业务完全透明（如应用2->P6->P7/P8)
6.通过多副本同步Redo Log确保数据持久化
ØPaxos组成员通过Redo-Log的多数派强同步，确保数据的持久化
ØLeader无需等待所有Follower的反馈，多数派完成同步即可向应用反馈成功
示例：
1. 应用写数据到P2分区。Zone2-OB Server1的P2为主副本（Leader），承接业务需求
2. 将Redo-Log同步请求发送到Zone1-OB Server1和Zone3-OB Server1中的P2从副本（Follower）
3. 任何一个Follower完成Redo-Log落盘并将响应返回给Leader后，Leader即认为Redo-Log完成强同步，无需再等待其它Follower的反馈
4. Leader反馈应用操作完成
7.查看表和分区的分布情况
7.1 查看表和分区的分布情况
表及分区的相关信息存储在这两个系统表中。
系统表：__all_virtual_meta_table, 关键信息
• tenant_id
• table_id
• partition_id
• svr_ip
• role：1 – leader, 2 - follower
系统表：__all_virtual_table, 关键信息
• table_id
• table_name
7.2 查看租户的分布情况
Ø该租户一共有21个分区（21个主副本，42个从副本），分布在Zone1/2/3的6台服务器内
Ø每个Zone都有7个主副本，实现了3个Zone的负载均衡
7.3 查看表的分区的分布情况
Ø该表格有3个分区，每个分区有3个副本，分布在3个zone内的一台OB Server
Ø每个Zone均有一个分区的主副本，实现负载均衡
8.OB Proxy为应用提供智能路由服务，应用透明访问
8.1高效路由转发
Ø对SQL做基本解析，确定对应Leader所在机器
Ø反向代理，将请求路由至对应Leader；Leader位置无法确定时随机选择OB Server
Ø轻量SQL解析 + 快速转发，保证高性能，单OB Proxy每秒转发百万次请求
8.2“非”计算节点，无状态
Ø每个OB Proxy是一个“无状态”的服务进程，不做数据持久化，对部署位置无要求
ØOB Proxy不参与数据库引擎的计算任务，不参与事务（单机 or 分布式） 处理
Ø多个OB Proxy之间无联系，可通过F5/SLB组成负载均衡集群
Ø不需要独立服务器，可以与OB Server共用一台服务器，如果应用对实时性要求高，也可以将OB Proxy部署到应用服务器中
9.Primary Zone
9.1通过设置Primary Zone，将业务汇聚到特定Zone
通过为不同的租户配置不同的Primary Zone，可以将业务流量集中到若干Zone中，减少跨Zone及跨服务器的操作。Zone List，逗号两侧优先级相同，分号左侧优先级高于右侧
9.2 Primary Zone有租户、数据库和表不同的级别
Ø如无特殊指定，自动继承上级对象的primary_zone：database继承租户的primary_zone设置，table继承database的primary_zone设置
Ødatabase和table可以指定各自的primary_zone，不必和上一级对象的设置保持一致；提供更加灵活的负载均衡策略
9.3 Primary Zone示例
10.Table Group
10.1 Table Group，将多个表的相同分区ID的主副本聚集在一个OB Server中，减少分布式事务引入的开销
Ø如果多个表的分区方式完全相同（分区类型、分区键个数、分区数量等），可以在逻辑上将这些表归属到同一个Table Group中，以影响动态负载均衡的策略
Ø同一个Table Group中的所有表，分区ID（partition_id）相同的所有分区，它们的leader在同一个observer上；在不影响全局负载均衡的前提下，可有效减少分布式事务引入的跨机访问开销
Ø如果负载均衡被打破（服务器故障后、扩容缩容等），Table Group中的所有表会作为一个整体来调整分区分布和leader分布
Ø动态创建和删除，并且对上层应用完全透明
Ø如果租户的unit_num=1且primary_zone只有一个zone，不需要tablegroup
10.2Table 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）将会整体迁移
create tablegroup emp_id_group partition by hash partitions 6;
create table employees (emp_id integer, emp_name varchar(64)) tablegroup = 'emp_id_group' partition by hash (emp_id) partitions 6;
create table salaries (emp_id integer, emp_salary number(10,2)) tablegroup = 'emp_id_group' partition by hash (emp_id) partitions 6;
参考资料：https://www.oceanbase.com/