Zeppelin Meta Server 设计 - Qihoo360/zeppelin GitHub Wiki

背景介绍

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

概要设计

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

详细设计

1. 总体结构

Zeppelin Meta

  • 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中内容恢复存活检测记录
  • 其他节点发现主切换后，会将请求转发给新主