Zeppelin Meta Server 设计

背景介绍

1. Zeppelin的第一期版本采用有中心的接口，由Meta Server负责元信息管理；
2. Client及Data Server均需要通过Meta Server获取元信息。

概要设计

1. Meta Server以集群的方式运行；
2. 利用下层Floyd提供一致性访问服务；
3. 尽量减少Meta Sever压力。

详细设计

1. 总体结构

• Meta集群将元数据信息记入Floyd;
• 非主节点将Ping，Join请求转给主处理;

2. 线程模型

• Dispatch线程接受来自Client及Data Server请求，并转发给Worker线程
• Worker线程处理请求，元信息改变时通知Update线程
• Update线程修改元信息并通知DataServer

3. 数据存储

Meta Server工作过程中需要处理的数据按更新频率由高到低包括:

• Data Server 心跳存活信息
• Data Server 主从信息
• 各个Table所包含的Parititon信息
• 各个Partition所负责的机器集合
• Data Server 地址端口信息

将更新更频繁的数据存储在Floyd中无疑会增加Meta Server压力，但同时降低程序的复杂度，充分利用Floyd提供的便利，目前权衡选择仅将后四种数据记入Floyd。因此Floyd中需要的内容包括：

• Nodes表：记录每个节点的地址端口及状态
• ReplicateSet表：每个Partition中包括的所有Node
• Table信息表：记录每个Table对应的Partition及Parition的主从信息

而剩余的心跳存活信息及为了方便查找而建立的从Node到Table的索引信息则维护在Meta Server的内存中，启动或者选主之后这些信息会根据Floyd里所存储的内容恢复出来。

4. 数据交互

• PING消息：探测Node存活，同时将当前的元信息epoch传递给Node
• PULL消息：DataServer或Client发送给Meta，回复信息包含Partition的Node及主从信息
• INIT消息：客户端的分片分表请求，执行Distribution过程

5. 工作过程

• PING：Worker线程收到Data Server的PING消息，如果第一次加入，则更新Nodes表，加入存活检测表。否则更新存活时间；
• 存活检测：Worker线程接受心跳，更新存活时间，过期时交给Update线程修改Nodes表状态，如果是主，则要在主从表中改变，并更新元信息Epoch；
• Distribution：接受用户命令INIT，建立Table，分配Partition机器，选主并更新ReplicateSet表及主从表，更新元信息Epoch

6. 故障恢复

• Meta主节点崩溃后，Floyd尝试选出新主
• 新主第一次提供服务前会通过Floyd中内容恢复存活检测记录
• 其他节点发现主切换后，会将请求转发给新主