《大规模分布式存储系统》第9章 分布式存储引擎【9.2】
9.2 RootServer实现机制RootServer是OceanBase集群对外的窗口，客户端通过RootServer获取集群中其他
模块的信息。RootServer实现的功能包括：
●管理集群中的所有ChunkServer，处理ChunkServer上下线；
●管理集群中的UpdateServer，实现UpdateServer选主；
●管理集群中子表数据分布，发起子表复制、迁移以及合并等操作；
●与ChunkServer保持心跳，接受ChunkServer汇报，处理子表分裂；
●接受UpdateServer汇报的大版本冻结消息，通知ChunkServer执行定期合并；
●实现主备RootServer，数据强同步，支持主RootServer宕机自动切换。
9.2.1 数据结构
RootServer的中心数据结构为一张存储了子表数据分布的有序表格，称为
RootTable。每个子表存储的信息包括：子表主键范围、子表各个副本所在
ChunkServer的编号、子表各个副本的数据行数、占用的磁盘空间、CRC校验值以及
基线数据版本。
RootTable是一个读多写少的数据结构，除了ChunkServer汇报、RootServer发起子
表复制、迁移以及合并等操作需要修改RootTable外，其他操作都只需要从RootTable
中读取某个子表所在的ChunkServer。因此，OceanBase设计时考虑以写时复制的方式
实现该结构，另外，考虑到RootTable修改特别少，实现时没有采用支持写时复制的
B+树或者跳跃表（Skip List），而是采用相对更加简单的有序数组，以减少工作量。
往RootTable增加子表信息的操作步骤如下：
1）拷贝当前服务的RootTable为新的RootTable；
2）将子表信息追加到新的RootTable，并对新的RootTable重新排序；
3）原子地修改指针使得当前服务的RootTable指向新的RootTable。
ChunkServer一次汇报一批子表（默认一批包含1024个），如果每个子表修改都
需要拷贝整个RootTable并重新排序，性能上显然无法接受。RootServer实现时做了一
些优化：拷贝当前服务的RootTable为新的RootTable后，将ChunkServer汇报的一批子
表一次性追加到新的RootTable中并重新排序，最后再原子地切换当前服务的
RootTable为新的RootTable。采用批处理优化后，RootTable的性能基本满足需求，
OceanBase单个集群支持的子表个数最大达到几百万个。当然，这种实现方式并不优
雅，我们后续将改造RootTable的实现方式。
ChunkServer汇报的子表信息可能和RootTable中记录的不同，比如发生了子表分
裂。此时，RootServer需要根据汇报的tablet信息更新RootTable。
如图9-2所示，假设原来的RootTable包含四个子表：r1（min，10]、r2（10，
100]、r3（100，1000]、r4（1000，max]、ChunkServer汇报的子表列表为：t1（10，
50]、t2（50，100]、t3（100，1000]，表示r2发生了tablet分裂，那么，RootServer会
将RootTable修改为：r1（min，10]、r2（10，50]、r3（50，100]、r4（100，1000]、
r5（1000，max]。
图 9-2 RootTable修改
RootServer中还有一个管理所有ChunkServer信息的数组，称为ChunkServer-
Manager。数组中的每个元素代表一台ChunkServer，存储的信息包括：机器状态（已
下线、正在服务、正在汇报、汇报完成，等等）、启动后注册时间、上次心跳时
间、磁盘相关信息、负载均衡相关信息。OceanBase刚上线时依据每台ChunkServer磁
盘占用信息执行负载均衡，目的是为了尽可能确保每台ChunkServer占用差不多的磁
盘空间。上线运行一段时间后发现这种方式效果并不好，目前的方式为按照每个表
格的子表个数执行负载均衡，目的是尽可能保证对于每个表格、每台ChunkServer上
的子表个数大致相同。
9.2.2 子表复制与负载均衡
RootServer中有两种操作都可能触发子表迁移：子表复制（rereplication）以及负
载均衡（rebalance）。当某些ChunkServer下线超过一段时间后，为了防止数据丢
失，需要拷贝副本数小于阀值的子表，另外，系统也需要定期执行负载均衡，将子
表从负载较高的机器迁移到负载较低的机器。
每台ChunkServer记录了子表迁移相关信息，包括：ChunkServer上子表的个数以
及所有子表的大小总和，正在迁入的子表个数、正在迁出的子表个数以及子表迁移
任务列表。RootServer包含一个专门的线程定期执行子表复制与负载均衡任务，步骤
如下：
1）子表复制：扫描RootTable中的子表，如果某个子表的副本数小于阀值，选取
某台包含子表副本的ChunkServer为迁移源，另外一台符合要求的ChunkServer为迁移
目的地，生成子表迁移任务。迁移目的地需要符合一些条件，比如，不包含待迁移
子表，服务的子表个数小于平均个数减去可容忍个数（默认值为10），正在进行的
迁移任务不超过阀值等。
2）负载均衡：扫描RootTable中的子表，如果某台ChunkServer包含的某个表格的
子表个数超过平均个数以及可容忍个数（默认值为10）之和，以这台ChunkServer为
迁移源，并选择一台符合要求的ChunkServer，生成子表迁移任务。
子表复制以及负载均衡生成的子表迁移任务并不会立即执行，而是会加入到迁
移源的迁移任务列表中，RootServer还有一个后台线程会扫描所有的ChunkServer，接
着执行每台ChunkServer的迁移任务列表中保存的迁移任务。子表迁移时限制了每台
ChunkServer同时进行的最大迁入和迁出任务数，从而防止一台新的ChunkServer刚上
线时，迁入大量子表而负载过高。
例9-1 某OceanBase集群包含4台ChunkServer：ChunkServer1（包含子表A1、
A2、A3），ChunkServer2（包含子表A3、A4），ChunkServer3（包含子表A2），
ChunkServer4（包含子表A4）。
假设子表副本数配置为2，最多能够容忍的不均衡子表的个数为0。RootServer后
台线程首先执行子表复制，发现子表A1只有一个副本，于是，将ChunkServer1作为迁
移源，选择某台ChunkServer（假设为ChunkServer3）作为迁移目的，生成迁移任务＜
ChunkServer1，ChunkServer3，A1＞。接着，执行负载均衡，发现ChunkServer1包含3
个子表，超过平均值（平均值为2），而ChunkServer4包含的子表个数小于平均值，
于是，将ChunkServer1作为迁移源，ChunkServer4作为迁移目的，选择某个子表（假
设为A2），生成迁移任务＜ChunkServer1，ChunkServer4，A2＞。如果迁移成功，A2
将包含3个副本，可以通知ChunkServer1删除上面的A2副本。最后，tablet分布情况
为：ChunkServer1（包含tablet A1、A3），ChunkServer2（包含tablet A3、A4），
ChunkServer3（包含tablet A1、A2），ChunkServer4（包含tablet A2、A4），每个
tablet包含2个副本，且平均分布在4台ChunkServer上。
9.2.3 子表分裂与合并
子表分裂由ChunkServer在定期合并过程中执行，由于每个子表包含多个副本，
且分布在多台ChunkServer上，如何确保多个副本之间的分裂点保持一致成为问题的
关键。OceanBase采用了一种比较直接的做法：每台ChunkServer使用相同的分裂规
则。由于每个子表的不同副本之间的基线数据完全一致，且定期合并过程中冻结的
增量数据也完全相同，只要分裂规则一致，分裂后的子表主键范围也保证相同。
OceanBase曾经有一个线上版本的分裂规则如下：只要定期合并过程中产生的数
据量超过256MB，就生成一个新的子表。假设定期合并产生的数据量为257MB，那
么最后将分裂为两个子表，其中，前一个子表（记为r1）的数据量为256MB，后一
个子表（记为r2）的数据量为1MB。接着，r1接受新的修改，数据量很快又超过
256MB，于是，又分裂为两个子表。系统运行一段时间后，充斥着大量数据量很少
的子表。
为了解决分裂产生小子表的问题，需要确保分裂以后的每个子表数据量大致相
同。OceanBase对每个子表记录了两个元数据：数据行数row_count以及子表大小
（occupy_size）。根据这两个值，可以计算出每行数据的平均大小，即：
occupy_size/row_count。
根据数据行平均大小，可以计算出分裂后的子表行数，从而得到分裂点。
子表合并相对更加麻烦，步骤如下：
1）合并准备：RootServer选择若干个主键范围连续的小子表；
2）子表迁移：将待合并的若干个小子表迁移到相同的ChunkServer机器；
3）子表合并：往ChunkServer机器发送子表合并命令，生成合并后的子表范围。
例9-2 某OceanBase集群中有3台ChunkServer：ChunkServer1（包含子表A1、
A3），ChunkServer2（包含子表A2、A3），ChunkServer3（包含子表A1、A2），其
中，A1和A2分别为10MB,A3为256MB。RootServer扫描RootTable后发现A1和A2满足
子表合并条件，首先发起子表迁移，假设将A1迁移到ChunkServer2，使得A1和A2在
相同的ChunkServer上，接着分别向ChunkServer2和ChunkServer3发起子表合并命令。
子表合并完成以后，子表分布情况为：ChunkServer1（包含子表A3），
ChunkServer2（包含子表A4（A1，A2），A3），ChunkServer3（包含子表A4（A1，
A2）），其中，A4是子表A1和A2合并后的结果。
每个子表包含多个副本，只要某一个副本合并成功，OceanBase就认为子表合并
成功，其他合并失败的子表将通过垃圾回收机制删除掉。
9.2.4 UpdateServer选主
为了确保一致性，RootServer需要确保每个集群中只有一台UpdateServer提供写
服务，这个UpdateServer称为主UpdateServer。
RootServer通过租约（Lease）机制实现UpdateServer选主。主UpdateServer必须持
有RootServer的租约才能提供写服务，租约的有效期一般为3～5秒。正常情况下，
RootServer会定期给主UpdateServer发送命令，延长租约的有效期。如果主
UpdateServer出现异常，RootServer等待主UpdateServer的租约过期后才能选择其他的
UpdateServer为主UpdateServer继续提供写服务。
RootServer可能需要频繁升级，升级过程中UpdateServer的租约将很快过期，系
统也会因此停服务。为了解决这个问题，RootServer设计了优雅退出的机制，即
RootServer退出之前给UpdateServer发送一个有效期超长的租约（比如半小时），承
诺这段时间不进行主UpdateServer选举，用于RootServer升级。代码如下：
enum ObUpsStatus
{
UPS_STAT_OFFLINE=0，//UpdateServer已下线
UPS_STAT_NOTSYNC=1，//UpdateServer为备机且与主UpdateServer不同步
UPS_STAT_SYNC=2，//UpdateServer为备机且与主UpdateServer同步
UPS_STAT_MASTER=3，//UpdateServer为主机
};
//RootServer中记录UpdateServer信息的结构
class ObUps
{
ObServer addr_;//UpdateServer地址
int32_t inner_port_;//UpdateServer内部端口
int64_t log_seq_num_;//UpdateServer的日志号
int64_t lease_;//UpdateServer的租约
ObUpsStatus stat_;//UpdateServer状态
};
class ObUpsManager
{
public:
//UpdateServer向RootServer注册
int register_ups(const ObServer＆addr,int32_t inner_port,int64_t
log_seq_num,int64_t lease,const char*server_version);
//检查所有UpdateServer的租约，RootServer内部有专门的线程会定时调用该函数
int check_lease();
//RootServer给UpdateServer发送租约
int grant_lease();
//RootServer给UpdateServer发送超长租约
int grant_eternal_lease();
private:
ObUps ups_array_;
int32_t ups_master_idx_;
};
RootServer模块中有一个ObUpsManager类，它包含一个数组ups_array_，其中的
每个元素表示一个UpdateServer,ups_master_idx_表示主UpdateServer在数组里的下标。
ObUps结构记录了UpdateServer的信息，包括UpdateServer的地址（addr_）以及内部
端口（inner_port_），UpdateServer的状态（stat_，分为
UPS_STAT_OFFLINE/UPS_STAT_NOTSYNC/UPS_STAT_SYNC/UPS_STAT_MASTER
这四种），UpdateServer的日志号（log_seq_num_）以及租约（lease_）。
UpdateServer首先通过register_ups向RootServer注册，将它的信息告知
RootServer。一段时间之后，RootServer会从所有注册的UpdateServer中选取一台日志
号最大的作为主UpdateServer。ObUpsManager类中还有一个check_lease函数，由
RootServer内部线程定时调用，如果发现UpdateServer的租约快要过期，则会通过
grant_lease给UpdateServer延长租约。如果发现主UpdateServer的租约已经失效，则会
从所有Update-Server中选择一个日志号最大的UpdateServer作为新的主UpdateServer。
另外，Root-Server还可以通过grant_eternal_lease给UpdateServer发送超长租约。
9.2.5 RootServer主备
每个集群一般部署一主一备两台RootServer，主备之间数据强同步，即所有的操
作都需要首先同步到备机，接着修改主机，最后才能返回操作成功。
RootServer主备之间需要同步的数据包括：RootTable中记录的子表分布信息、
ChunkServerManager中记录的ChunkServer机器变化信息以及UpdateServer机器信息。
子表复制、负载均衡、合并、分裂以及ChunkServer/UpdateServer上下线等操作都会
引起RootServer内部数据变化，这些变化都将以操作日志的形式同步到备
RootServer。备RootServer实时回放这些操作日志，从而与主RootServer保持同步。
OceanBase中的其他模块，比如ChunkServer/UpdateServer，以及客户端通过
VIP（Virtual IP）访问RootServer，正常情况下，VIP总是指向主RootServer。当主
RootServer出现故障时，部署在主备RootServer上的Linux HA（heartbeat，心跳），软
件能够检测到，并将VIP漂移到备RootServer。Linux HA软件的核心包含两个部分：
心跳检测部分和资源接管部分，心跳检测部分通过网络链接或者串口线进行，主备
RootServer上的心跳软件相互发送报文来告诉对方自己当前的状态。如果在指定的时
间内未收到对方发送的报文，那么就认为对方失败，这时需启动资源接管模块来接
管运行在对方主机上的资源，这里的资源就是VIP。备RootServer后台线程能够检测
到VIP漂移到自身，于是自动切换为主机提供服务。
页:
[1]