开启掘金成长之旅！这是我参与「掘金日新计划 · 12 月更文挑战」的第9天，点击查看活动详情 @[toc]
第三章：OceanBase集群技术架构
1. Paxos协议与负载均衡
1.1 数据分区与分区副本
1.1.1 分区
• 当一个表很大的时候，可以水平拆分为若干个分区，每个分区包含表的若干行记录。根据行数据到分区的映射关系不同，分为hash分区，List分区（按列表），range分区（按范围）等 • 每一个分区，还可以用不同的维度再分为若干分区，叫做二级分区 • 分区是OceanBase数据架构的基本单元，是传统数据库的分区表在分布式系统上的实现
1.1.2 副本
• 为了数据安全和提供高可用的数据服务，每个分区的数据在物理上存储多份，每一份叫做分区的一个副本 • 副本根据负载和特定的策略，由系统自动调度分散在多个Server上。副本支持迁移、复制、增删、类型转换等管理操作
例如，交易记录表，按照用户ID分为3个hash分区（红、蓝、黄），每个一级hash分区再按照交易时间分为4个range分区。
1.2 支持三种副本，满足不同业务类型的需求
• 一个分区在一个zone中最多有一个全功能或日志型副本
• 只读型副本在同一个zone可以有多个
根据存储数据种类的不同，副本有几种不同的类型，以支持不同业务在在数据安全，性能伸缩性，可用性，成本等之间进行取舍折中 • 全能型副本：也就是目前支持的普通副本，拥有事务日志，MemTable和SSTable等全部完整的数据和功能。它可以随时快速切换为leader对外提供服务 • 日志型副本：只包含日志的副本，没有MemTable和SSTable。它参与日志投票并对外提供日志服务，可以参与其他副本的恢复，但自己不能变为主提供数据库服务。因为日志型副本所消耗的物理资源（CPU、内存、磁盘）更少，它可以有效降低最后一副本机器的成本，进而降低整个集群的总体成本 • 只读型副本：包含完整的日志，MemTable和SSTable等，但是它的日志比较特殊。它不作为paxos成员参与日志的投票，而是作为一个观察者实时追赶paxos成员的日志，并在本地回放。这种副本可以在业务对读取数据的一致性要求不高的时候提供只读服务。因其不加入paxos成员组，又不会造成投票成员增加导致事务提交延时的增加
| 类型 | Log | MemTable | SSTable | 数据安全 |
|---|---|---|---|---|
| 全能型 | 有，参与投票 | 有 | 有 | 高 |
| 日志型 | 有，参与投票 | 无 | 无 | 低 |
| 只读型 | 有，但不属于paxos组，只是listener | 有 | 有 | 中 |
1.3 多副本一致性协议
• 以分区为单位组建Paxos协议组：每个分区都有多份副本（Replica），自动建立Paxos组，在分区级用多副本保证数据可靠性和服务高可用，数据管理更加灵活方便
• 自动选举主副本：OB自动生成多份副本，多副本自动选举主副本，主副本提供服务（如图黄色副本供应用访问，蓝色副本用于备份）
1.4 自动负载均衡与智能路由
• 自动负载均衡：主副本均匀打散到各个服务器中，使得各个服务器都能承载业务流量。(如图应用1、2、3读请求分布路由到不同的OB Server）
• 每台OB Server相互独立：每台OB Server均可以独立执行SQL，如果应用需要访问的数据在不同机器上，OB Server自动将请求路由至数据所在的机器，对业务完全透明（如应用2->P6->P7/P8)
1.5 通过多副本同步Redo Log确保数据持久化
• Paxos组成员通过Redo-Log的多数派强同步，确保数据的持久化 • Leader无需等待所有Follower的反馈，多数派完成同步即可向应用反馈成功
- 应用写数据到P2分区。Zone2-OB Server1的P2为主副本（Leader），承接业务需求
- 将Redo-Log同步请求发送到Zone1-OB Server1和Zone3-OB Server1中的P2从副本（Follower）
- 任何一个Follower完成Redo-Log落盘并将响应返回给Leader后，Leader即认为Redo-Log完成强同步，无需再等待其它Follower的反馈
- Leader反馈应用操作完成
