《大规模分布式存储系统》第9章分布式存储引擎【9.2】

javazx · 发表于 2017-3-6 14:37:42

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_[MAX_UPS_COUNT];
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漂移到自身，于是自动切换为主机提供服务。

		自动登录	找回密码
密码			立即注册

《大规模分布式存储系统》第9章分布式存储引擎【9.2】

相关帖子

宣传达人

突出贡献

优秀版主

荣誉管理

论坛元老

《大规模分布式存储系统》第9章 分布式存储引擎【9.2】

相关帖子

宣传达人

突出贡献

优秀版主

荣誉管理

论坛元老

《大规模分布式存储系统》第9章分布式存储引擎【9.2】