关于java:不愧是清华大佬把Zookeeper讲的如此简单明了

本文章转自：优极限
文章次要解说：Zookeeper
获取更多Java材料请百度搜寻:优极限官网

数据存储历史背景

• 所有的的计算工作都由一台计算机实现，数据的存储也由一台计算机实现

• 单节点计算

  • 单点故障

  • 性能瓶颈

    • IO的瓶颈
    • 内存

磁盘阵列

Raid简介

• Redundant Arrays of Independent Disks
• 将数据寄存在多块磁盘必定能解决IO瓶颈的问题

• 磁盘阵列是由很多块独立的磁盘，组合成一个容量微小的磁盘组，利用个别磁盘提供数据所产生加成成果晋升整个磁盘零碎效力。利用这项技术，将数据切割成许多区段，别离寄存在各个硬盘上。 磁盘阵列还能利用同位查看（Parity Check）的观点，在数组中任意一个硬盘故障时，仍可读出数据，在数据重构时，将数据经计算后从新置入新硬盘中。

  条带化

• 问题

  • 大多数磁盘零碎都对拜访次数（每秒的 I/O 操作，IOPS）和数据传输率（每秒传输的数据量，TPS）有限度。
  • 当达到这些限度时，前面须要拜访磁盘的过程就须要期待，这时就是所谓的磁盘抵触。

• 解决方案

  • 条带化技术就是将一块间断的数据分成很多小局部并把他们别离存储到不同磁盘下来。
  • 这就能使多个过程同时拜访数据的多个不同局部而不会造成磁盘抵触
  • 在对这种数据进行程序拜访的时候能够取得最大水平上的 I/O 并行能力，从而取得十分好的性能。

• Raid0

• RAID0 具备低成本、高读写性能、 100% 的高存储空间利用率等长处，然而它不提供数据冗余爱护，一旦数据损坏，将无奈复原。
• RAID0 个别实用于对性能要求严格但对数据安全性和可靠性不高的利用，如视频、音频存储、长期数据缓存空间等。

• Raid1

• RAID1 称为镜像，它将数据完全一致地别离写到工作磁盘和镜像 磁盘，它的磁盘空间利用率为 50%
• RAID1 在数据写入时，响应工夫会有所影响，然而读数据的时候没有影响
• RAID1 提供了最佳的数据保护，一旦工作磁盘产生故障，零碎主动从镜像磁盘读取数据，不会影响用户工作

• Raid2

• RAID2 称为纠错海明码磁盘阵列，其设计思维是利用海明码实现数据校验冗余。
• 海明码是一种在原始数据中退出若干校验码来进行谬误检测和纠正的编码技术，其中第 2n 位（ 1, 2, 4, 8, … ）是校验码，其余地位是数据码

• 海明码宽度和校验码计算

  • 如果是 4 位数据宽度须要 4 块数据磁盘和 3 块校验磁盘
  • 如果是 64 位数据宽度须要 64 块 数据磁盘和 7 块校验磁盘。
• 海明码的数据冗余开销太大，而且 RAID2 的数据输入性能受阵列中最慢磁盘驱动器的限度。再者，海明码是按位运算， RAID2 数据重建十分耗时。

• Raid3

• RAID3 是应用专用校验盘的并行拜访阵列，它采纳一个专用的磁盘作为校验盘，其余磁盘作为数据盘，数据按位可字节的形式穿插存储到各个数据盘中
• RAID3 至多须要三块磁盘，不同磁盘上同一带区的数据作 XOR 校验，校验值写入校验盘中
• RAID3 完整时读性能与 RAID0 完全一致，并行从多个磁盘条带读取数据，性能十分高，同时还提供了数据容错能力。
• RAID3 写入数据时，必须计算与所有同条带的校验值，并将新校验值写入校验盘中。
• 一次写操作蕴含了写数据块、读取同条带的数据块、计算校验值、写入校验值等多个操作，零碎开销十分大，性能较低。
• 如果 RAID3 中某一磁盘呈现故障，不会影响数据读取，能够借助校验数据和其余完整数据来重建数据。

• Raid4

• RAID4 与 RAID3 的原理大致相同，区别在于条带化的形式不同。
• RAID4 依照块的形式来组织数据，写操作只波及以后数据盘和校验盘两个盘，多个 I/O 申请能够同时失去解决，进步了零碎性能。
• RAID4 按块存储能够保障单块的完整性，能够防止受到其余磁盘上同条带产生的不利影响。
• RAID4 提供了十分好的读性能，但繁多的校验盘往往成为零碎性能的瓶颈。

• 数据块

  • 数据块也称为存储块，它蕴含为文件系统调配的其余空间。这些数据块的大小是在创立文件系统时确定的。
  • 缺省状况下，为数据块调配以下两种大小：8 KB 的逻辑块大小和 1 KB 的段大小 (fragment size)。

• Raid5

• RAID5 应该是目前最常见的 RAID 等级，它的校验数据分布在阵列中的所有磁盘上，而没有采纳专门的校验磁盘。
• 对于数据和校验数据，它们的写操作能够同时产生在齐全不同的磁盘上。
• RAID5 还具备很好的扩展性。当阵列磁盘 数量减少时，并行操作量的能力也随之增长
• RAID5 当一个数据盘损坏时，零碎能够依据同一条带的其余数据块和对应的校验数据来重建损坏的数据
• 重建数据时， RAID5 的性能会受到较大的影响。

• Raid6

• RAID6 引入双重校验的概念，它能够爱护阵列中同时呈现两个磁盘生效时，阵列仍可能持续工作，不会产生数据失落。
• RAID6 不仅要反对数据的复原，还要反对校验数据的复原，因而实现代价很高，控制器的设计也比其余等级更简单、更低廉。
• RAID6 思维最常见的实现形式是采纳两个独立的校验算法，假如称为 P 和 Q ，校验数据能够别离存储在两个不同的校验盘上，或者扩散存储在所有成员磁盘中。
• RAID6 具备疾速的读取性能、更高的容错能力。然而，它的老本要高于 RAID5 许多，写性能也较差，并有设计和施行非常复杂。
• <img src="https://i0.hdslb.com/bfs/album/088f2391f96a7ec92586eeb614fdb073f62206eb.png" alt="1603900520854" style="zoom:150%;" />

• CAP准则

  定义

• CAP定理是2000年，由 Eric Brewer 提出来的。Brewer认为在分布式的环境下设计和部署零碎时，有3个外围的需要，以一种非凡的关系存在。
• 这3个外围的需要是：Consistency，Availability和Partition Tolerance
• CAP定理认为：一个提供数据服务的存储系统无奈同时满足数据一致性、数据可用性、分区容忍性

• 概念

• Consistency：

  • 一致性，这个和数据库ACID的一致性相似，但这里关注的所有数据节点上的数据一致性和正确性，而数据库的ACID关注的是在在一个事务内，对数据的一些束缚。
  • 零碎在执行过某项操作后依然处于统一的状态。在分布式系统中，更新操作执行胜利后所有的用户都应该读取到最新值。

• Availability：

  • 可用性，每一个操作总是可能在肯定工夫内返回后果。须要留神“肯定工夫”和“返回后果”。
  • “肯定工夫”是指零碎后果必须在给定工夫内返回。
  • “返回后果”是指零碎返回操作胜利或失败的后果。

• Partition Tolerance：

  • 分区容忍性，是否能够对数据进行分区。这是思考到性能和可伸缩性。

  推导

• 如果要求对数据进行分区了，就阐明了必须节点之间必须进行通信，波及到通信，就无奈确保在无限的工夫内实现指定的工作
• 如果要求两个操作之间要残缺的进行，因为波及到通信，必定存在某一个时刻只实现一部分的业务操作，在通信实现的这一段时间内，数据就是不一致性的。

• 如果要求保障一致性，那么就必须在通信实现这一段时间内爱护数据，使得任何拜访这些数据的操作不可用。

  论断

• 在大型网站利用中，数据规模总是疾速扩张的，因而可伸缩性即分区容忍性必不可少，规模变大当前，机器数量也会变得宏大，这是网络和服务器故障会频繁呈现，要想保障利用可用，就必须保障分布式解决零碎的高可用性。

• 在大型网站中，通常会抉择强化分布式存储系统的可用性和伸缩性，在某种程度上放弃一致性

  数据的一致性

  定义

• 一些分布式系统通过复制数据来进步零碎的可靠性和容错性，并且将数据的不同的正本寄存在不同的机器

• 在数据有多分正本的状况下，如果网络、服务器或者软件呈现故障，会导致局部正本写入胜利，局部正本写入失败。这就造成各个正本之间的数据不统一，数据内容抵触。

  模型

• 强一致性

  • 要求无论更新操作切实哪一个正本执行，之后所有的读操作都要能取得最新的数据。

• 弱一致性

  • 用户读到某一操作对系统特定数据的更新须要一段时间，咱们称这段时间为“不一致性窗口”。

• 最终一致性

  • 是弱一致性的一种特例，保障用户最终可能读取到某操作对系统特定数据的更新。
  • 从客户端来看，有可能临时获取的不是最新的数据，然而最终还是能拜访到最新的
  • 从服务端来看，数据存储并复制到散布到整个零碎超过半数的节点，以保证数据最终统一。

  最终一致性

• 因果一致性（Casual Consistency）

  • 如果过程A告诉过程B它已更新了一个数据项，那么过程B的后续拜访将返回更新后的值，且一次写入将保障取代前一次写入。
  • 与过程A无因果关系的过程C的拜访，恪守个别的最终一致性规定。
  • 查问微博和评论

• 读己之所写一致性（read-your-writes）

  • 当过程A本人更新一个数据项之后，它总是拜访到更新过的值，绝不会看到旧值。这是因果一致性模型的一个特例。
  • 读本人的数据都从主服务器去读取，读其他人的数据再从从服务器去读取
  • 发表微博与批改微博

• 会话（Session）一致性

  • 这是上一个模型的实用版本，它把拜访存储系统的过程放到会话的上下文中。只有会话还存在，零碎就保障“读己之所写”一致性。如果因为某些失败情景令会话终止，就要建设新的会话，而且零碎的保障不会连续到新的会话。
  • 确保会话内拜访的都是最新的

• 枯燥（Monotonic）读一致性

  • 如果过程曾经看到过数据对象的某个最新值，那么任何后续拜访都不会返回在那个值之前的值。
  • 不会读取最旧的数据

• 枯燥写一致性

  • 零碎保障来自同一个过程的写操作程序执行。要是零碎不能保障这种水平的一致性，就十分难以编程了。
  • 依照程序实现数据的书写

  Paxos算法

  简介

• Paxos算法是Leslie Lamport宗师提出的一种基于消息传递的分布式一致性算法，使其取得2013年图灵奖。
• Paxos在1990年提出，被广泛应用于分布式计算中，Google的Chubby，Apache的Zookeeper都是基于它的实践来实现的
• Paxos算法解决的问题是分布式一致性问题，即一个分布式系统中的各个过程如何就某个值（决定）达成统一。

• 传统节点间通信存在着两种通信模型：共享内存（Shared memory）、消息传递（Messages passing），Paxos是一个基于消息传递的一致性算法。

  算法形容

• Paxos形容了这样一个场景，有一个叫做Paxos的小岛(Island)下面住了一批居民，岛下面所有的事件由一些非凡的人决定，他们叫做议员(Senator)。议员的总数(Senator Count)是确定的，不能更改。岛上每次环境事务的变更都须要通过一个提议(Proposal)，每个提议都有一个编号(PID)，这个编号是始终增长的，不能倒退。每个提议都须要超过半数((Senator Count)/2 +1)的议员批准能力失效。每个议员只会批准大于以后编号的提议，包含已失效的和未失效的。如果议员收到小于等于以后编号的提议，他会回绝，并告知对方：你的提议曾经有人提过了。这里的以后编号是每个议员在本人记事本下面记录的编号，他不断更新这个编号。整个议会不能保障所有议员记事本上的编号总是雷同的。当初议会有一个指标：保障所有的议员对于提议都能达成统一的认识。当初议会开始运作，所有议员一开始记事本下面记录的编号都是0。有一个议员发了一个提议：将电费设定为1元/度。他首先看了一下记事本，嗯，以后提议编号是0，那么我的这个提议的编号就是1，于是他给所有议员发消息：1号提议，设定电费1元/度。其余议员收到音讯当前查了一下记事本，哦，以后提议编号是0，这个提议可承受，于是他记录下这个提议并回复：我承受你的1号提议，同时他在记事本上记录：以后提议编号为1。发动提议的议员收到了超过半数的回复，立刻给所有人发告诉：1号提议失效！收到的议员会批改他的记事本，将1好提议由记录改成正式的法令，当有人问他电费为多少时，他会查看法令并通知对方：1元/度。当初看抵触的解决：假如总共有三个议员S1-S3，S1和S2同时发动了一个提议:1号提议，设定电费。S1想设为1元/度, S2想设为2元/度。后果S3先收到了S1的提议，于是他做了和后面同样的操作。紧接着他又收到了S2的提议，后果他一查记事本，咦，这个提议的编号小于等于我的以后编号1，于是他回绝了这个提议：对不起，这个提议先前提过了。于是S2的提议被回绝，S1正式公布了提议: 1号提议失效。S2向S1或者S3打听并更新了1号法令的内容，而后他能够抉择持续发动2号提议。

Paxos推断

• 小岛(Island) 服务器集群
• 议员(Senator) 单台服务器
• 议员的总数(Senator Count)是确定的
• 提议(Proposal) 每一次对集群中的数据进行批改
• 每个提议都有一个编号(PID)，这个编号是始终增长的
• 每个提议都须要超过半数((Senator Count)/2 +1)的议员批准能力失效
• 每个议员只会批准大于以后编号的提议
• 每个议员在本人记事本下面记录的编号，他不断更新这个编号
• 整个议会不能保障所有议员记事本上的编号总是雷同的
• 议会有一个指标：保障所有的议员对于提议都能达成统一的认识。
• 后期投票(>1/2)，前期播送(all)

• Paxos算法

  • 数据的全量备份
  • 弱一致性 -——》最终一致性

算法模型延长

如果Paxos岛上的议员人人平等，在某种状况下会因为提议的抵触而产生一个“活锁”（所谓活锁我的了解是大家都没有死，都在动，然而始终解决不了抵触问题）。Paxos的作者在所有议员中设立一个总统，只有总统有权收回提议，如果议员有本人的提议，必须发给总统并由总统来提出。状况一：屁民甲(Client)到某个议员(ZK Server)那里询问(Get)某条法令的状况(ZNode的数据)，议员毫不犹豫的拿出他的记事本(local storage)，查阅法令并通知他后果，同时申明：我的数据不肯定是最新的。你想要最新的数据？没问题，等着，等我找总统Sync一下再通知你。状况二：屁民乙(Client)到某个议员(ZK Server)那里要求政府偿还欠他的一万元钱，议员让他在办公室等着，本人将问题反映给了总统，总统询问所有议员的意见，少数议员示意欠屁民的钱肯定要还，于是总统发表声明，从国库中拿出一万元还债，国库总资产由100万变成99万。屁民乙拿到钱回去了(Client函数返回)。状况三：总统忽然挂了，议员接踵而至的发现分割不上总统，于是各自发表声明，推选新的总统，总统大选期间政府开业，回绝屁民的申请。

• 无主集群模型

  • 人人都会发送指令,投票

    • 投票人数有可能导致分区(分不同营垒)，

      • 6个节点 33对抗
      • 相似于以前党争

    • 事务编号凌乱，每个节点都有可能有本人的提议

      • 提议的编号不能反复和小于

• 有主集群模型

  • 只能有一个主发送指令，发送提议

  • 单主会单点故障，必定有备用的计划

    • 从新选举
    • 切换到备用节点
  • 如果存在多个主就会脑裂

• 次要集群中节点数目高于1/2+1，集群就能够失常运行

Raft算法

简介

• Raft 实用于一个治理日志一致性的协定，相比于 Paxos 协定 Raft 更易于了解和去实现它。
• Raft 将一致性算法分为了几个局部，包含领导选取（leader selection）、日志复制（log replication）、平安（safety）
• http://thesecretlivesofdata.c...

问题

• 分布式存储系统通过保护多个副原本进步零碎的availability，难点在于分布式存储系统的外围问题：

  • 保护多个正本的一致性。

• Raft协定基于复制状态机（replicated state machine）

  • 一组server从雷同的初始状态起，按雷同的程序执行雷同的命令，最终会达到统一的状态
  • 一组server记录雷同的操作日志，并以雷同的程序利用到状态机。

<img src="https://i0.hdslb.com/bfs/album/a0a2cc24ba53a1bfc55aac059a815efb1e56b396.png" alt="image-20201030112725921" style="zoom: 80%;" />

• Raft有一个明确的场景，就是治理复制日志的一致性。

  • 每台机器保留一份日志，日志来自于客户端的申请，蕴含一系列的命令，状态机会按程序执行这些命令。
  • <img src="https://i0.hdslb.com/bfs/album/8c5c602ff02685f75f1aa295206cc63aa4b6a825.png" alt="image-20201030112837171" style="zoom:50%;" />

角色调配

• Raft算法将Server划分为3种状态，或者也能够称作角色：

  • Leader

    • 负责Client交互和log复制，同一时刻零碎中最多存在1个。

  • Follower

    • 被动响应申请RPC，从不被动发动申请RPC。

  • Candidate

    • 一种长期的角色，只存在于leader的选举阶段，某个节点想要变成leader，那么就发动投票申请，同时本人变成candidate

  <img src="https://i0.hdslb.com/bfs/album/ade1e61b67e4129743ae086634a9c5c5b646d2d1.png" alt="image-20201030113226989" style="zoom:50%;" />

算法流程

• Term

  • Term的概念类比中国历史上的朝代更替，Raft 算法将工夫划分成为任意不同长度的任期（term）。
  • 任期用间断的数字进行示意。每一个任期的开始都是一次选举（election），一个或多个候选人会试图成为领导人。如果一个候选人博得了选举，它就会在该任期的剩余时间负责领导人。在某些状况下，选票会被瓜分，有可能没有选出领导人，那么，将会开始另一个任期，并且立即开始下一次选举。Raft 算法保障在给定的一个任期最多只有一个领导人

• RPC

  • Raft 算法中服务器节点之间通信应用近程过程调用（RPCs）
  • 根本的一致性算法只须要两种类型的 RPCs，为了在服务器之间传输快照减少了第三种 RPC。
  • RequestVote RPC：候选人在选举期间发动
  • AppendEntries RPC：领导人发动的一种心跳机制，复制日志也在该命令中实现
  • InstallSnapshot RPC: 领导者应用该RPC来发送快照给太落后的追随者

• 日志复制（Log Replication）

  • 次要用于保障节点的一致性，这阶段所做的操作也是为了保障一致性与高可用性。
  • 当Leader选举进去后便开始负责客户端的申请，所有事务（更新操作）申请都必须先通过Leader解决
  • 日志复制（Log Replication）就是为了保障执行雷同的操作序列所做的工作。
  • 在Raft中当接管到客户端的日志（事务申请）后先把该日志追加到本地的Log中
  • 而后通过heartbeat把该Entry同步给其余Follower，Follower接管到日志后记录日志而后向Leader发送ACK
  • 当Leader收到大多数（n/2+1）Follower的ACK信息后将该日志设置为已提交并追加到本地磁盘中
  • 告诉客户端并在下个heartbeat中Leader将告诉所有的Follower将该日志存储在本人的本地磁盘中。

Zookeeper

角色调配

• 小岛——ZK Server Cluster

• 总统——ZK Server Leader

  • 集群中所有批改数据的指令必须由总统收回
  • 总统是由议员投票产生的（无主-->有主）

  • 选举条件

    • 首先依照事务zxid进行排序
    • 如果事务雷同依照myid排序

• 议员(Senator)——ZK Server Learner

  • 承受客户端申请

    • 查问间接返回后果（有可能数据不统一）

    • 写入数据，先将数据写入到以后server

      • 发送音讯给总统，总统将批改数据的命令发送给其余server
      • 其余server接受命令后开始批改数据，批改实现后给总统返回胜利的音讯
      • 当总统发现超过半数的人都批改胜利，就认为批改胜利了
      • 并将信息传递给承受申请的zkServer,zkServer将音讯返回给客户端，阐明数据更新实现

  • 分类Learner

    • Follower

      • 领有选举权
      • 领有投票权
      • 承受客户端的拜访

    • Observer

      • 只能够为客户端提供数据的查问和拜访
      • 如果客户端执行写申请，只是将申请转发给Leader

• 提议(Proposal)——ZNode Change

  • 客户端的提议会被封装成一个节点挂载到一个Zookeeper保护的目录树下面
  • 咱们能够对数据进行拜访（绝对路径）
  • 数据量不能超过1M

• 提议编号(PID)——Zxid

  • 会依照数字序列递增，不会缩小不会反复

• 正式法令——所有ZNode及其数据

  • 超过半数的服务器更新这个数据，就阐明数据曾经是正式的了

• 屁民--Client

  • 发送申请（查问申请，批改申请）

搭建Zookeeper

• 首先将三台虚拟机切换到互相免秘钥快照（keysfree）

• 上传Zookeeper,解压，拷贝

  • [root@node01 ~]# tar -zxvf zookeeper-3.4.5.tar.gz

• 批改配置文件

  • [root@node01 conf]# cd /opt/xxx/zookeeper-3.4.5/conf/[root@node01 conf]# cp zoo_sample.cfg zoo.cfg[root@node01 conf]# vim zoo.cfg

  • # the directory where the snapshot is stored.dataDir=/var/xxx/zookeeper# the port at which the clients will connectclientPort=2181# 设置服务器外部通信的地址和zk集群的节点server.1=node01:2888:3888server.2=node02:2888:3888server.3=node03:2888:3888

• 创立myid

  • [123]mkdir -p /var/xxx/zookeeper[123]touch /var/xxx/zookeeper/myid[1] echo 1 > /var/xxx/zookeeper/myid[2] echo 2 > /var/xxx/zookeeper/myid

• 拷贝Zookeeper

  • [root@node01 xxx]scp -r zookeeper-3.4.5 root@node02:/opt/xxx/

• 设置环境变量

  • vim /etc/profile

  • export ZOOKEEPER_HOME=/opt/xxx/zookeeper-3.4.5

  - [1]scp /etc/profile root@node02:/etc/profile- [1]scp /etc/profile root@node03:/etc/profile- [123] source /etc/profile

• 开启集群

  • [123] zkServer.sh start
  • [123] zkServer.sh status
  • [123] zkServer.sh stop

  • 关机拍摄快照

    • shutdown -h now

Zookeeper存储模型

存储构造

• zookeeper是一个树状构造，保护一个小型的数据节点znode
• 数据以keyvalue的形式存在，目录是数据的key
• 所有的数据拜访都必须以绝对路径的形式出现

• [zk: localhost:2181(CONNECTED) 10] get /xxx666 以后节点的值cZxid = 0xf00000013 创立这个节点的事务idctime = Mon Dec 09 17:33:06 CST 2019 创立工夫mZxid = 0xf00000013 最初一次批改节点数据的事务IDmtime = Mon Dec 09 17:33:06 CST 2019 批改工夫pZxid = 0xf00000014 子节点的最新事务IDcversion = 1 对此znode的子节点进行的更改次数dataVersion = 对此znode的数据所作的批改次数 aclVersion = 对此znode的acl更改次数ephemeralOwner = 0x0 （长久化节点）0x16ee9fc0feb0001（长期节点）dataLength = 3 数据的长度numChildren = 1 子节点的数目

  节点的分类

• 长久化节点（PERSISTENT）

  • 默认创立的就是长久化节点

• 长期节点（Ephemral）

  • 只在创立节点的会话无效时，创立节点会话生效之后就会生效
  • 能够被所有的客户端所查看
  • create -e

• 序列化节点（Sequential）

  • 在名字的前面增加一个序列号(有序)
  • create -s

  ZKServer的命令

• 启动ZK服务: bin/zkServer.sh start
• 查看ZK服务状态: bin/zkServer.sh status
• 进行ZK服务: bin/zkServer.sh stop
• 重启ZK服务: bin/zkServer.sh restart
• 连贯服务器: zkCli.sh -server 127.0.0.1:2181
  二、连贯zk
  Linux环境下：
  eg、zkCli.sh -server 127.0.0.1:2181
  三、zk客户端命令
  1.ls -- 查看某个目录蕴含的所有文件，例如：
  [zk: 127.0.0.1:2181(CONNECTED) 1] ls /
  ls /path

2.ls2 -- 查看某个目录蕴含的所有文件，与ls不同的是它查看到time、version等信息，例如：
[zk: 127.0.0.1:2181(CONNECTED) 1] ls2 /

3.create -- 创立znode，并设置初始内容，例如：
[zk: 127.0.0.1:2181(CONNECTED) 1] create /test "test"
Created /test
创立一个新的 znode节点“ test ”以及与它关联的字符串

create /path data    默认创立长久节点create -s /path data 创立程序节点create -e /path data 创立长期节点create /parent/sub/path /data

4.get -- 获取znode的数据，如下：
[zk: 127.0.0.1:2181(CONNECTED) 1] get /test

get /pathget /path0000000018 拜访程序节点必须输出残缺门路

5.set -- 批改znode内容，例如：
[zk: 127.0.0.1:2181(CONNECTED) 1] set /test "ricky"

set /path /data

6.delete -- 删除znode，例如：
[zk: 127.0.0.1:2181(CONNECTED) 1] delete /test

delete /path 删除没有子节点的节点rmr /path 移除节点并且递归移除所有子节点

7.quit -- 退出客户端

8.help -- 帮忙命令

## ZKServer的监听机制- 官网阐明  - 一个Watch事件是一个一次性的触发器，当被设置了Watch的数据产生了扭转的时候，则服务器将这个扭转发送给设置了Watch的客户端，以便告诉它们。- 机制特点  - 一次性触发 数据产生扭转时，一个watcher event会被发送到client，然而client只会收到一次这样的信息。  - watcher event异步发送- 数据监督    - Zookeeper有数据监督和子数据监督  getdata() and exists() 设置数据监督，getchildren()设置了子节点监督  - ```    //watch监听有不同的类型，有监听状态的stat ，内容的get，目录构造的ls。    get /path [watch]    NodeDataChanged    stat /path [watch]   NodeDeleted    ls /path [watch]     NodeChildrenChanged

• 父节点Watcher事件类型:

  • 创立父节点触发: NodeCreated
• 批改父节点数据触发: NodeDataChanged
• 删除父节点触发: NodeDeleted

• 子节点Watcher事件类型:

  • 应用ls命令为父节点设置watcher,子节点被创立时触发:NodeChildrenChanged

  • 应用ls命令为父节点设置watcher,子节点被删除时触发:NodeChildrenChanged

    • 应用ls命令为父节点设置watcher,子节点被批改时,不触发事件

ACL权限管制（理解）

ACL权限管制ZK的节点有5种操作权限：CREATE、READ、WRITE、DELETE、ADMIN 也就是 增、删、改、查、管理权限，这5种权限简写为crwda，这5种权限中，delete是指对子节点的删除权限，其它4种权限指对本身节点的操作权限身份的认证有4种形式：- world：默认形式，相当于全世界都能拜访- auth：代表曾经认证通过的用户(cli中能够通过addauth digest user:pwd 来增加以后上下文中的受权用户)- digest：即用户名:明码这种形式认证，这也是业务零碎中最罕用的- ip：应用Ip地址认证schema    world:只有一个用户anyone,代表所有人（默认）    ip：应用IP地址认证    auth：应用已增加认证的用户认证    digest：应用用户名：明码 形式认证id    world:只有一个id，anyone    ip：通常是一个ip地址或者地址段    auth:用户名    digest：自定义权限    create 简写为c,能够创立子节点    delete 简写为d 能够删除子节点    read 简写为r 能够读取节点数据及显示子节点列表    write 简写为w  能够设置节点数据    admin 简写为a 能够设置管理权限查看ACL    getAcl /parent设置ACL    setAcl /parent  world:anyone:wa增加用户    addauth digest zhangsan:123456设置权限    setAcl /parent auth:zhangsan:123456:rcwda

四字命令（理解）

装置nc

• yum install nc -y
• 如果呈现下图的谬误，请从新清空和重构cache

四字命令

ZooKeeper 反对某些特定的四字命令(The Four Letter Words)与其进行交互。

应用形式，在shell终端输出：echo 四字命令| nc node01 2181

Zookeeper环境搭建（理解）

• 基于Observer的环境搭建
• Zookeeper的热部署

感激大家的认同与反对，小编会继续转发《优极限》优质文章