关于zookeeper:zookeeper-概览与性能

4次阅读

共计 2969 个字符，预计需要花费 8 分钟才能阅读完成。

本文依据 zookeeper 概览进行整顿汇总, 大量退出了集体的了解, 不当之处欢送交换.

ZooKeeper 是一个针对分布式应用的分布式、开源的协调服务。它公开了一组简略的原语，分布式应用程序能够在这些原语的根底上构建，以实现更高级别的服务，用于同步、配置保护、分组和命名。它被设计成易于编程，并且应用了一种相似于文件系统目录树结构的数据模型。它在 Java 中运行，并且有针对 Java 和 C 的绑定。

协调服务是出了名的难搞。它们特地容易呈现竞争条件和死锁等谬误。ZooKeeper 背地的动机是为了加重分布式应用从头开始实现协调服务的责任。

ZooKeeper is simple.
- ZooKeeper 容许分布式过程 (集群中的各个服务节点) 通过共享的层次结构命名空间 (相似于规范文件系统) 进行协调. 命名空间由数据寄存器组成, 用 ZooKeeper 的说法就是 znode(它们相似于文件和目录). 与为存储而设计的典型文件系统不同,ZooKeeper 的数据保留在内存中, 这意味着 ZooKeeper 能够实现高吞吐量和低提早.
ZooKeeper is replicated
- zookeeper 是一个分布式的服务, 能够将很对的 zookeeper 分布式的部署在多个服务器上并组建成正本 (replica) 集群, 晋升服务的健壮性
ZooKeeper is ordered
- 对于 zookeeper 服务来讲, 数据操作是有序的(数据更改操作肯定从 leader 节点执行, 然而读取操作能够扩散到各个集群中的各个正本上), 每个操作都有一个成先后关怀的 zxid, 这些能够追踪读写操作的先后顺序
ZooKeeper is fast
- zookeeper 的非常适合读多写少的工作负载场景, 在 10:1 的读写比时它的性能最好. 同时 zookeeper 集群的读取压力能够扩散到集群中的各个节点上.zookeeper 的读性能其实很好的起因时数据是寄存在内存中的并在数据扭转时会有事务提交到磁盘上, 因为多节点间要做强一致性保障所以比个别的单机事务要花更多工夫, 数据的扭转只能从 leader 执行, 也制约了数据改变操作无奈做到负载平衡. 这是分布式事务一致性的自身限度不是 zookeeper 的技术起因

ZooKeeper 提供的命名空间相似于规范的文件系统. 名称是用斜杠 (/) 分隔的门路元素序列.ZooKeeper 命名空间中的每个节点都用门路标识.与规范的文件系统构造不一样的是 zookeeper 的门路全副是绝对路径齐全没有相对路径, 所以任何 node 的 path 都是 / 结尾的

上面是 node 的档次继承图

zookeeper 采纳高度相似文件系统的数据结构而不是从新设计一个专属的构造, 极大的简化的了 zookeeper 的学习难度, 非常容易上手.

zookeeper 确保上面的几个保障:

Sequential Consistency
Atomicity
Single System Image
Reliability
Timeliness

对于它们的具体解读请看: zookeeper 一致性保障

针对每一次客户端的事务操作,Zookeeper 都会将他们记录到事务日志中, 当然 Zookeeper 也
会将数据变更利用到内存数据库中 / 咱们能够在 zookeeper 的主配置文件 zoo.cfg 中配置数据长久化目录, 也就是事务日志的存储门路 dataLogDir. 如果没有配置dataLogDir(非必
填), 事务日志将存储到 dataDir(必填项)目录

Zookeeper 进行事务日志文件操作的时候会频繁进行磁盘 IO 操作, 事务日志的一直追加写操作会
触发底层磁盘 IO 为文件开拓新的磁盘块, 即磁盘 Seek. 因而 \ 为了晋升磁盘 IO 的效率，
Zookeeper 在创立事务日志文件的时候就进行文件空间的预调配, 即在创立文件的时候, 就向操
作零碎申请一块大一点的磁盘块. 这个预调配的磁盘大小能够通过零碎参数
zookeeper.preAllocSize 进行配置。

对于 zookeeper 的日志更多的信息请看:logging

数据快照用于记录 Zookeeper 服务器上某一时刻的全量数据, 并将其写入到指定的磁盘文件中.
能够通过配置 snapCount 配置每距离事务申请个数, 生成快照, 数据存储在 dataDir 指定的目录
中.

有了事务日志，为啥还要快照数据?
快照数据次要时为了疾速复原, 事务日志文件是每次事务申请都会进行追加的操作, 而快照是达
到某种设定条件下的内存全量数据. 所以通常快照数据是反馈过后内存数据的状态. 事务日志是
更全面的数据, 所以复原数据的时候, 能够先复原快照数据, 再通过增量复原事务日志中的数据
即可.

zookeeper 的长久化机制和 Redis 简直是齐全一样的. 同时有快照和操作日志.

实践上 zookeeper 的性能是很不错的, 官网给出的具体的阐明:Performance

zookeeper 集群中对于每个服务节点来讲其实有 2 份数据, 一份是缓存在内存中, 反馈了以后最新的数据, 例外一份就是长久化到磁盘上保证数据的可靠性. 对于读操作来讲毫无疑问的是读取内存中的数据, 因为 zookeeper 数据结构简略且数据的理论大小不大, 所以读性能是非常优良的, 并且能够扩散读申请的压力到多个节点, 在读多写少的场景下轻松的冲破上万的 QPS 齐全没有压力, 然而 zookeeper 的指标在于分布式一致性, 那么对于写操作来讲, 分布式一致性的协商和事务日志的长久化就要花一些工夫了, 对于写操作, 单节点而言数据被更新到内存中并长久化到磁盘上, 多节点间同时做了分布式一致性协商确认后能力返回给客户端最终的写操作胜利回执.

具体的性能相干的文档请看: Performance

所以我对 zookeeper 的性能制约因素总结如下:

分布式协商
- follow 数量: 对于一个 zookeeper 集群而言,leader 只会有一个然而 follow 有多个,follow 越多协商的老本越高, 所以在满足可靠性的前提下,follow 正当的数量有利于 zookeeper 的写性能并反馈到混合读写性能上, 读写比越高,follow 数量的影响越小, 然而 follow 的数量过少又会制约并发读取性能. 当初的典型的 zookeeper 最好采取 1 leader + 正当数量的 follow + 多个 obersver 的搭配. 多个 obersver 根本等同于 follow 然而不参加选举和一致性协商, 能够被认为是 leader 的同步镜像承当读操作的压力, 它能够无效补救 follow 数量多了会减少协商老本但数量不够又影响读操作性能的难堪.
长久化 IO 限度.zookeeper 是强一致性高牢靠设计, 那么对于每个写操作都会产生长久化操作, 这时传统的机械硬盘很容易因为 IO 性能不好而制约 zookeeper 的写性能
- 应用高 IOPS 的固态硬盘
- 拆散 zooker 的 dataDir 和dataLogDir, 数据快照和长久化操作不在一个磁盘上或者一个文件门路下, 拆散这它们的地位后可能升高单个磁盘的 IOPS 性能要求