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）将会整体迁移
