Zeppelin Data Server 设计 - Qihoo360/zeppelin GitHub Wiki

背景介绍

  1. Node Server负责Zeppelin真正的数据存储，可能有三到多个实例
  2. Node Server 从Meta Server获取整个集群的元信息

概要设计

  1. Node Server启动时从配置中获得Meta Server位置
  2. Node Server建立与MetaServer的heartbeat链接，向Meta Server报告自己的存活，并发现Meta Server存活
  3. Node Server需要感知元信息的改变，并更新自己
  4. Node Server支持KV接口

详细设计

1. 数据管理

Node：节点，一个单独的Node Server实例称为一个Node节点，通常用一块磁盘运行一个Node节点。

Partition：分片

  • 将整个合法的Key空间进行分片，每个Partition负责一小段Key值的存储；
  • 每个Partition拥有独立的Binlog和DB，是数据备份，数据迁移，数据同步的最小单位；
  • 采用副本模式的Partition会存在多个副本，为了数据安全将相同Partition的不同副本存储在不同Node节点上；
  • 相同Partition的不同副本见采用Master-Slave的方式进行异步复制；

Table：表，逻辑概念，用来区分和隔离不同的业务。Table中定义Partition的个数，副本方式，分片方式等。

Alt text

可以看出，每个Table包含多个Partition，而每个Partition固定属于一个Table；每个Parition的多个副本存在于不同的Node上，而每个Node都会负责多个不同的Partition。

2. 总体结构

Alt text

Zeppelin自上而下的层次如图所示。

  • Network Proxy：负责网络的压包解包，采用Protobuf协议通Meta Server, Client, 及其他Node Server进行交互；
  • Zeppelin Process：Zeppline主要逻辑处理层，包括分表分片，数据同步，命令处理等；
  • Binlog：操作日志，同时是同步模块的数据来源；
  • 存储层：采用Rocksdb进行数据存储。

3. 线程模型

Alt text

Zeppelin采用多线程的方式进行工作，Zeppline中的所有线程都是与Node绑定的，不会随着Table或Partiiton的个数增加而增加。根据不同线程的任务及交互对象将线程分为三大类：

1，元信息线程，包括Heartbeat Thread及MetaCmd Thread

  • Heartbeat Thread：负责与Meta Server保持的心跳连接，并通过PING信息感知Meta Server元信息的更新；
  • MetaCmd Thread：Heartbeat Thread感知到元信息的更新后由MetaCmd Thread从Meta Server获取最新的元信息。通过元信息中的副本信息，MetaCmd Thread会负责修改和维护改Node Server与其他Node Server的Peer关系；

2，用户命令线程，包括Dispatch Thread及Worker Thread

  • Dispatch Thread：接受用的链接请求并将客户端链接交个某个Worker Thread线程处理；
  • Worker Thread：处理用户请求，写命令会先写Binlog，之后访问DB完成用户命令的执行。

3， 同步线程，包括服务于副本间数据同步功能的多个线程

  • TrySync Thread: 负责发起主从同步请求。MetaCmd Thread修改副本状态后，TrySync Thread会一次对当前Node Server负责的所有需要建立主从关系的Partition的主Partition发送Sync命令，该Sync命令会首先获取本地的binlog位置作为当前主从同步的同步点；
  • Binlog Sender Thread：Partition的不同副本之间建立主从关系后会由Binlog Sender Thread读取并向从Parition的Binlog Receiver Thread 发送binlog项。这个过程通用户命令的执行异步进行，所以从的Partition可能会落后于主。同一个Sender会负责多个Partition；
  • Binlog Receiver Thread：接受Binlog Sender Thread发来的Binlog项，写Binlog并将写DB的操作分发给不同的Binlog BgWorker；
  • Binlog Receive BgWorker：接受Binlog Receiver Thread发来的请求，写DB完成操作。

Alt text

4，后台工作线程，包括BGSave and DBSync Thread，Binlog Purge Thread

  • Binlog Purge Thread：为了减少对磁盘空间的占用，Binlog Purge Thread会定期删除过期的Binlog
  • BGSave and DBSync Thread：建立主从关系时，如果主Partition发现同步点已经落后于当前保留的最早的binlog，则需要进行全量同步。该线程会首先将整个数据内容dump一份并发送给对应从Partition。全同步过程利用Rsync实现。

4. 客户端请求

客户端需要访问针对某个业务Table进行操作时，会先向Meta Server请求改Table的元信息。之后每个访问请求，都会根据key计算出其所属于的Partition，通过元信息计算器Master所在的Node Server。直接请求改Node Server

Alt text

5. 故障检测及处理

Node Server定期向Meta Server发送PING消息，当节点宕机或者网络中断发生时。Meta Server会感知并修改其维护的元信息，并将元信息Epoch加一。元信息修改后，其他Node Server会从PING消息的回复中获得新Epoch，由于与本地记录不同，Node Server会由MetaCmd Thread向Meta Server 发送PULL消息主动拉去最新元信息。 元信息中记录各个Table中每个Partition所负责的Master Node Server及两个Slave Node Server。Node Server获得最新的元信息，并根据该信息修改自己维护的Partitions的主从角色，建立主从关系，提供服务。