Zeppelin Data Server 设计
- Node Server负责Zeppelin真正的数据存储，可能有三到多个实例
- Node Server 从Meta Server获取整个集群的元信息
- Node Server启动时从配置中获得Meta Server位置
- Node Server建立与MetaServer的heartbeat链接，向Meta Server报告自己的存活，并发现Meta Server存活
- Node Server需要感知元信息的改变，并更新自己
- Node Server支持KV接口
Node：节点，一个单独的Node Server实例称为一个Node节点，通常用一块磁盘运行一个Node节点。
Partition：分片
- 将整个合法的Key空间进行分片，每个Partition负责一小段Key值的存储；
- 每个Partition拥有独立的Binlog和DB，是数据备份，数据迁移，数据同步的最小单位；
- 采用副本模式的Partition会存在多个副本，为了数据安全将相同Partition的不同副本存储在不同Node节点上；
- 相同Partition的不同副本见采用Master-Slave的方式进行异步复制；
Table：表，逻辑概念，用来区分和隔离不同的业务。Table中定义Partition的个数，副本方式，分片方式等。
可以看出，每个Table包含多个Partition，而每个Partition固定属于一个Table；每个Parition的多个副本存在于不同的Node上，而每个Node都会负责多个不同的Partition。
Zeppelin自上而下的层次如图所示。
- Network Proxy：负责网络的压包解包，采用Protobuf协议通Meta Server, Client, 及其他Node Server进行交互；
- Zeppelin Process：Zeppline主要逻辑处理层，包括分表分片，数据同步，命令处理等；
- Binlog：操作日志，同时是同步模块的数据来源；
- 存储层：采用Rocksdb进行数据存储。
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完成操作。
4，后台工作线程，包括BGSave and DBSync Thread，Binlog Purge Thread
- Binlog Purge Thread：为了减少对磁盘空间的占用，Binlog Purge Thread会定期删除过期的Binlog
- BGSave and DBSync Thread：建立主从关系时，如果主Partition发现同步点已经落后于当前保留的最早的binlog，则需要进行全量同步。该线程会首先将整个数据内容dump一份并发送给对应从Partition。全同步过程利用Rsync实现。
客户端需要访问针对某个业务Table进行操作时，会先向Meta Server请求改Table的元信息。之后每个访问请求，都会根据key计算出其所属于的Partition，通过元信息计算器Master所在的Node Server。直接请求改Node Server
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的主从角色，建立主从关系，提供服务。