专注java分布式架构之Zeppelin不是飞艇

过去的一年多的时间中，大部分的工作都围绕着Zeppelin这个项目展开，经历了Zeppelin的从无到有，再到逐步完善稳定。见证了Zeppelin的成长的同时，Zeppelin也见证了我的积累进步。对我而言，Zeppelin就像是孩提时代一同长大的朋友，在无数次的游戏和谈话中，交换对未知世界的感知，碰撞对未来的憧憬，然后刻画出更好的彼此。这篇博客中就向大家介绍下我的这位老朋友。Zeppelin是一个高性能，高可用的分布式Key-Value存储平台，以高性能、大集群为目标，说平台是因为Zeppelin不是终点而是起点，在Zeppelin的基础上，不仅能够提供KV的访问，还可以通过简单的一层转换满足更复杂的协议需求。本文就将从背景，技术细节，回顾和未来计划几个方面来进行介绍。

背景

Zeppelin的故事首先从我们之前的一个项目Pika说起，Pika是一个完全兼容Redis协议的单机存储，用多线程及LSM的方式，在降低Redis内存成本的同时基本保持了其高性能的特点。 正是由于Pika项目在公司内外的普及，让我们认识到有大量需要高性能的存储需求，同时随着Pika项目的推进，以及业务的发展，这种曾经被我们定义为缓存的需求正向着更大容量和更高性能发展，因此一个大容量高性能的分布式Pika势在必行。

同时，维护Ceph的经验给我们强化了一个认识，那就是从一个原子的用户接口出发可以很方便的构建出各种复杂的上层需求和用户接口，正如Ceph从一个高一致的对象存储平台Rados出发构建了对象存储、块存储和文件存储。Zeppelin作为一个高性能的KV存储平台，可以向上构建高性能S3，Table Store，Redis协议等，可以看出并没有一个合适的开源实现能够同时满足我们的需求。

最后，之前的项目Pika、QConf、Bada等给我们积累了不少的经验和丰富稳定的基础库，包括网络库Pink，辅助库Slash，引擎库Nemo，一致性库Floyd，再加上我们对Rocksdb的积累。这时我们离需要的高性能KV存储平台其实已经并不遥远。再加上陈宗志同学的蜜汁不屑，Zeppelin就开始了自己的征程。从2016年7月正式立项，到半年后2017年3月0.3.1版本开始接入业务，再到现在1.2.3版本，Zeppelin已经逐步完善稳定，并接入包括搜索，代码发布，信息流，静床在内的众多业务的近二十个集群。

通过上面的背景介绍，可以看出在设计之初，我们就对Zeppelin有如下几个主要期许：

• 高性能：Zeppelin和Pika的立命之本，因此无论语言选择，副本方式，引擎选择还是其他结构设计都不能以牺牲性能作为代价。

• 大集群：因此需要有更好的可扩展性和必要的业务隔离及配额；
• 作为支撑平台，向上支撑更丰富的协议；

Zeppelin的整个设计和实现都围绕这三个目标努力。这里将从API、数据分布、元信息管理、一致性、副本策略、数据存储、故障检测几个方面来分别介绍其技术细节。

API