本文依据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的技术起因

Data model and the hierarchical namespace

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性能要求

此外一个无奈回避的然而影响zookeeper性能的因素是zookeeper的故障复原会导致从新选举的过程中会有短暂的性能降落,然而工夫个别是几秒以内,文档请看: Reliability

本文原创链接:zookeeper 概览与性能