分布式服务协调 Zookeeper.docxVIP

分布式服务协调 Zookeeper 2021-08-30 Google的三篇论文影响了很多很多人，也影响了很多很多系统。这三篇论文一直是分布式领域传阅的经典。依据MapReduce，于是我们有了Hadoop；依据GFS，于是我们有了HDFS；依据BigTable，于是我们有了HBase。而在这三篇论文里都提及Google的一个Lock Service —— Chubby，哦，于是我们有了Zookeeper。 随着大数据的火热，Hxx们已经变得耳熟能详，现在作为一个开发人员假如都不晓得这几个名词出门都好像不好意思跟人打招呼。但实际上对我们这些非大数据开发人员而言，Zookeeper是比Hxx们可能接触到更多的一个基础服务。但是，无法的是它一直悄然的位于二线，从来没有Hxx们那么刺眼。那么到底什么是Zookeeper呢？Zookeeper可以用来干什么？我们将如何使用Zookeeper？Zookeeper又是怎样实现的？ 什么是Zookeeper 在Zookeeper的官网上有这么一句话：ZooKeeper is a centralized service for maintaining configuration information, naming, providing distributed synchronization, and providing group services。 这或许描述了Zookeeper次要是一个分布式服务协调框架，实现同步服务，配置维护和命名服务等分布式应用。是一个高功能的分布式数据全都性处理方案。 通俗地讲，ZooKeeper是动物园管理员，它是拿来管大象 Hadoop、鲸鱼 HBase、Kafka等的管理员。 Zookeeper和CAP的关系 作为一个分布式系统，分区容错性是一个必需要考虑的关键点。一个分布式系统一旦丢失了分区容错性，也就表示放弃了扩展性。由于在分布式系统中，网络毛病是经常消灭的，一旦消灭在这种问题就会导致整个系统不行用是确定不能容忍的。所以，大部分分布式系统都会在保证分区容错性的前提下在全都性和可用性之间做权衡。 ZooKeeper是个CP（全都性+分区容错性）的，即任何时辰对ZooKeeper的访问恳求能得到全都的数据结果，同时系统对网络分割具备容错性；但是它不能保证每次服务恳求的可用性。也就是在极端环境下，ZooKeeper可能会丢弃一些恳求，消费者程序需要重新恳求才能获得结果。 ZooKeeper是分布式协调服务，它的职责是保证数据在其管辖下的全部服务之间保持同步、全都；所以就不难理解为什么ZooKeeper被设计成CP而不是AP特性的了。而且， 作为ZooKeeper的核心实现算法Zab，就是处理了分布式系统下数据如何在多个服务之间保持同步问题的。 Zookeeper节点特性及节点属性分析 Zookeeper供应基于类似于文件系统的名目节点树方式的数据存储，但是Zookeeper并不是用来特地存储数据的，它的作用次要是用来维护和监控你存储的数据的形态变化。通过监控这些数据形态的变化，从而可以达到基于数据的集群管理。 数据模型 与Linux文件系统不同的是，Linux文件系统出名目和文件的区分，而Zookeeper的数据节点称为ZNode，ZNode是Zookeeper中数据的最小单元，每个ZNode都可以保存数据，同时还可以挂载子节点，因而构成了一个层次化的命名空间，称为树。 Zookeeper中ZNode的节点创建时候是可以指定类型的，次要有下面几品种型。 PERSISTENT：长久化ZNode节点，一旦创建这个ZNode点存储的数据不会自动消逝，除非是客户端自动的delete。 EPHEMERAL：临时ZNode节点，Client连接到Zookeeper Service的时候会建立一个Session，之后用这个Zookeeper连接实例创建该类型的znode，一旦Client关闭了Zookeeper的连接，服务器就会清除Session，然后这个Session建立的ZNode节点都会从命名空间消逝。总结就是，这个类型的znode的生命周期是和Client建立的连接一样的。 PERSISTENT_SEQUENTIAL：挨次自动编号的ZNode节点，这种znoe节点会依据当前已近存在的ZNode节点编号自动加 1，而且不会随Session断开而消逝。 EPEMERAL_SEQUENTIAL：临时自动编号节点，ZNode节点编号会自动添加，但是会随Session消逝而消逝 Watcher数据变更通知 Zookeeper使用Watcher机制实现分布式数据的发布/订阅功能。 Zookeeper的Watcher机制次要包括客户端线程、客户端WatcherMa