Zeppelin 是奇虎 360 开源的一个高性能，高可用的分布式 Key-Value 存储平台，它以高性能、大集群为目标，并希望能在 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 的整个设计和实现都围绕这三个目标努力。这里将从 API、数据分布、元信息管理、一致性、副本策略、数据存储、故障检测几个方面来分别介绍其技术细节。 API 设计 为了让读者对 Zeppelin 有个整体印象，先介绍下其提供的接口：
数据分布 最为一个分布式存储，首要需要解决的就是数据分布的问题。另一篇博客浅谈分布式存储系统数据分布方法中介绍了可能的数据分布方案，Zeppelin 选择了比较灵活的分片的方式，如下图所示： 用逻辑概念 Table 区分业务，并将 Table 的整个 Key Space 划分为相同大小的分片（Partition），每个分片的多副本分别存储在不同的存储节点（Node Server）上，因而，每个 Node Server 都会承载多个 Partition 的不同副本。Partition 个数在 Table 创建时确定，更多的 Partition 数会带来更好的数据均衡效果，提供扩展到更大集群的可能，但也会带来元信息膨胀的压力。实现上，Partition 又是数据备份、数据迁移、数据同步的最小单位，因此更多的 Partition 可能带来更多的资源压力。Zeppelin 的设计实现上也会尽量降低这种影响。 可以看出，分片的方式将数据分布问题拆分为两层隐射：从 Key 到 Partition 的映射可以简单的用 Hash 实现。而 Partition 副本到存储节点的映射相对比较复杂，需要考虑稳定性、均衡性、节点异构及故障域隔离（更多讨论见浅谈分布式存储系统数据分布方法）。关于这一层映射，Zeppelin 的实现自己的分布算法 DPRD(Decentralized Placement of Replicated Data)，DPRD 参考了 CRUSH 对副本故障域的层级维护方式，但摈弃了 CRUSH 对降低元信息量稍显偏执的追求。 在进行创建 Table、扩容、缩容等集群变化的操作时，用户需要提供整个：
Zeppelin 根据这些信息及当前的数据分布直接计算出完整的目标数据分布，这个过程会尽量保证数据均衡及需要的副本故障域。下图举例展示了，副本在机架（cabinet）级别隔离的规则及分布方式。 元信息管理 上面确定了分片的数据分布方式，可以看出，包括各个分片副本的分布情况在内的元信息需要在整个集群间共享，并且在变化时及时扩散，这就涉及到了元信息管理的问题，通常有两种方式：
考虑到对大集群目标的需求，Zeppelin 采用了有中心节点的元信息管理方式。其整体结构如下图所示： 可以看出 Zeppelin 有三个主要的角色，元信息节点 Meta Server、存储节点 Node Server 及 Client。Meta 负责元信息的维护、Node 的存活检测及元信息分发；Node 负责实际的数据存储；Client 的首次访问需要先从 Meta 获得当前集群的完整数据分布信息，对每个用户请求计算正确的 Node 位置，并发起直接请求。 为了减轻上面提到的中心节点的单点问题。我们采取了如下策略：
通过上面几个方面的策略设计，尽量的降低对中心节点的依赖。即使 Meta 集群整个异常时，已有的客户端请求依然能正常进行。 一致性 上面已经提到，中心元信息 Meta 节点以集群的方式进行服务。这就需要一致性算法来保证：
Zeppelin 中采用了我们的一致性库 Floyd 来完成这一目标，Floyd 是 Raft 的 C++ 实现。更多内容可以参考：Raft 和它的三个子问题。 利用一致性协议，Meta 集群需要完成 Node 节点的存活检测、元信息更新及元信息扩散等任务。这里需要注意的是，由于一致性算法的性能相对较低，我们需要控制写入一致性库的数据，只写入重要、不易恢复且修改频度较低的数据。 副本策略 为了容错，通常采用数据三副本的方式，又由于对高性能的定位，我们选择了 Master，Slave 的副本策略。每个 Partition 包含至少三个副本，其中一个为 Master，其余为 Slave。所有的用户请求由 Master 副本负责，读写分离的场景允许 Slave 也提供读服务。Master 处理的写请求会在修改 DB 后写 Binlog，并异步的将 Binlog 同步给 Slave。 上图所示的是 Master，Slave 之间建立主从关系的过程，右边为 Slave。当元信息变化时，Node 从 Meta 拉取最新的元信息，发现自己是某个 Partition 新的 Slave 时，将 TrySync 任务通过 Buffer 交给 TrySync Moudle；TrySync Moudle 向 Master 的 Command Module 发起 Trysync；Master 生成 Binlog Send 任务到 Send Task Pool；Binlog Send Module 向 Slave 发送 Binlog，完成数据异步复制。更详细内容见：Zeppelin 不是飞艇之存储节点。未来也考虑支持 Quorum 及 EC 的副本方式来满足不同的使用场景。 数据存储 Node Server 最终需要完成数据的存储及查询等操作。Zeppelin 目前采用了 Rocksdb 作为存储引擎，每个 Partition 副本都会占有独立的 Rocksdb 实例。采用 LSM 方案也是为了对高性能的追求，相对于 B+Tree，LSM 通过将随机写转换为顺序写大幅提升了写性能，同时，通过内存缓存保证了相对不错的读性能。庖丁解 LevelDB 之概览中以 LevelDB 为例介绍了 LSM 的设计和实现。 然而，在数据 Value 较大的场景下，LSM 写放大问题严重。为了高性能，Zeppelin 大多采用 SSD 盘，SSD 的随机写和顺序写之间的差距并不像机械盘那么大，同时 SSD 又有擦除寿命的问题，因此 LSM 通过多次重复写换来的高性能优势不太划算。而 Zeppelin 需要对上层不同协议的支撑，又不可避免的会出现大 Value，LSM upon SSD 针对这方面做了更多的讨论，包括这种改进在内的其他针对不同场景的存储引擎及可插拔的设计也是 Zeppelin 未来的发展方向。 故障检测 一个好的故障检测的机制应该能做到如下几点：
Zeppelin 中的故障可能发生在元信息节点集群或存储节点集群，元信息节点集群的故障检测依赖下层的 Floyd 的 Raft 实现，并且在上层通过 Jeopardy 阶段来容忍抖动。更详细内容见：Zeppelin 不是飞艇之元信息节点。 而存储节点的故障检测由元信息节点负责， 感知到异常后，元信息节点集群修改元信息、更新元信息版本号，并通过心跳通知所有存储节点，存储节点发现元信息变化后，主动拉去最新元信息并作出相应改变。 最后，Zeppelin 还提供了丰富的运维、监控数据，以及相关工具。方便通过 Prometheus 等工具监控展示。 回顾及未来发展 通过本文对 Zeppelin 设计的介绍，可以看出 Zeppelin 并不是一个适用于任何场景的万能药，它一直围绕自己的高性能、易扩展、支持上层协议的目标，也就牺牲了对一致性的满足，因此 Zeppelin 并不适合对数据一致性要求高的需求场景，同时也不能支持像数据库、文件系统、块存储等对一致性要求很高的上层协议。 目前 Zeppelin 已经完成了包括扩容缩容，中心节点成员变化在内的大部分作为分布式存储的基本需求。下一步会依然围绕我们的设计初心，同时针对目前的一些问题进行进一步的迭代，包括：
|
|
|
