Zookeeper

前 言ZooKeeper是一个开源的、高可用的、分布式的协调服务，由Apache软件基金会保护。它旨在帮忙治理和协调分布式系统和应用程序，提供了一个牢靠的平台，用于解决分布式同步、配置管理和群组服务等工作。ZooKeeper广泛应用于构建分布式系统，它提供了一个稳固的根底来治理配置、协调节点、实现分布式锁、实现分布式队列等。通过ZooKeeper，开发人员能够轻松解决分布式系统中的同步和协调问题，使得分布式应用的开发更加简略和牢靠。 01 zookeeper的特点1-1 高可用性ZooKeeper的设计指标之一是高可用性。它通过复制数据到多个服务器，应用Quorum算法来确保数据的一致性。如果局部节点产生故障，依然可能提供可用的服务，放弃零碎的可用性。 1-2 一致性ZooKeeper提供强一致性保障。在ZooKeeper集群中，大多数节点（法定人数）必须就数据的状态达成一致意见。这样能够确保每个客户端对数据的读取都能取得雷同的最新数据。 1-3 简略数据模型ZooKeeper采纳相似文件系统的数据模型，应用树状构造来存储数据。每个节点（Znode）都有一个门路和一个数据负载。这种简略的数据模型使得ZooKeeper易于了解和应用。 1-4 事件告诉ZooKeeper反对Watch机制，客户端能够设置在Znode上的察看，以便在Znode产生更改时接管告诉。这样能够实现分布式的事件告诉和合作机制，反对事件驱动的利用程序设计。 1-5 程序节点 ZooKeeper反对程序节点的创立，即创立的节点会主动带有惟一递增的序列号。这个个性可用于实现分布式锁、分布式队列等常见的协调原语。 1-6 原子操作ZooKeeper提供原子操作，能够保障简单的多步骤操作在ZooKeeper上是原子的。这些原子操作为构建高级别的分布式协调原语提供了反对。 1-7 集群模式一致性。ZooKeeper集群中的节点能够动静地退出或来到，使得零碎更加灵便和可扩大。 1-8 长期节点ZooKeeper反对长期节点，这些节点的生命周期与客户端会话相关联。当客户端会话完结时，长期节点会被主动删除，这样能够实现临时性的数据和状态治理。 02  zookeeper架构下图为zookeeper架构的角色分布图： 2-1 Leader：集群中的一个服务器被选举为Leader。Leader负责解决客户端的写申请（例如创立、更新和删除Znodes）和协调分布式事务。Leader通过ZooKeeper协定来确保写操作在集群中的大多数节点上同步执行，以保持数据的一致性。如果Leader服务器产生故障或断开连接，集群会通过选举算法主动抉择新的Leader。 2-2 FollowerFollower是集群中的其余服务器，它们听从Leader的指令，复制Leader上的写操作，以保持数据一致性。Follower能够解决客户端的读申请，但不能解决写申请。Follower与Leader放弃心跳连贯，以便及时理解Leader的状态。观察者是一种非凡类型的ZooKeeper服务器，它不参加Leader选举，也不参加写操作的复制。 03  选举机制集群中在 Zookeeper运行期间 Leader 和 非 Leader 各司其职，当有非 Leader 服务器宕机或退出不会影响 Leader，然而一旦 Leader 服务器挂了，那么整个 Zookeeper 集群将暂停对外服务，会触发新一轮的选举。 第一次投票每台机器都会将票投给本人。接着每台机器都会将本人的投票发给其余机器，如果发现其余机器的zxid比本人大，那么就须要改投票从新投一次。比方server1 收到了三张票，发现server2的xzid为102，pk一下发现自己输了，前面果决改投票选server2为老大。 3-1 Server id(或sid)：服务器ID比方有三台服务器，编号别离是1,2,3。编号越大在抉择算法中的权重越大，比方初始化启动时就是依据服务器ID进行比拟。 3-2 Zxid：事务ID服务器中寄存的数据的事务ID，值越大阐明数据越新，在选举算法中数据越新权重越大。 3-3 Epoch：逻辑时钟也叫投票的次数，同一轮投票过程中的逻辑时钟值是雷同的，每投完一次票这个数据就会减少。 3-4 Server状态：选举状态LOOKING，竞选状态。FOLLOWING，随从状态，同步leader状态，参加投票。OBSERVING，察看状态,同步leader状态，不参加投票。LEADING，领导者状态。 04 ZAB协定ZAB（Zookeeper Atomic Broadcast）协定是Zookeeper外部用于实现分布式一致性的外围协定。它是一个基于原子播送的协定，用于保障Zookeeper集群中数据的一致性和可靠性。ZAB协定是Zookeeper的要害个性之一，确保在集群中的各个节点之间维持数据的一致性。ZAB协定的特点：原子播送：ZAB协定确保事务是原子性播送的，要么所有Follower节点都接管到该事务，要么都没有接管到。这样能够保证数据的一致性。解体复原：ZAB协定容许集群在局部节点宕机或解体后，从新选举新的Leader，从而放弃服务的可用性和容错性。程序性：ZAB协定保障所有节点依照雷同的程序处理事务，从而保持数据的一致性。轻量级：ZAB协定只须要在集群中的多数节点上进行播送和确认，因而具备较低的通信开销。穿插验证能够帮忙精确地预计模型的性能，从而反对更好的模型抉择和超参数调整，以取得更好的泛化性能。 05 CAP实践Zookeeper是一个分布式协调服务，它次要用于构建分布式系统中的协调和同步机制。而CAP实践则是分布式系统实践中的重要概念，它形容了在分布式系统中三个要害属性的衡量：一致性（Consistency）、可用性（Availability）和分区容忍性（Partition Tolerance）。CAP实践指出在分布式系统中，无奈同时满足这三个属性，只能抉择其中两个，因为其中任意两个属性之间是存在抵触的。具体来说，CAP实践的三个属性解释如下： 5-1 一致性（Consistency）在分布式系统中，一致性意味着所有节点在同一时刻看到的数据正本是雷同的。即便是在有多个正本的状况下，所有节点也可能看到雷同的数据。 5-2 可用性（Availability）可用性指的是零碎可能在无限工夫内对申请作出响应，并可能保障服务的可用性，即便在局部节点故障的状况下。 5-3 分区容忍性（Partition Tolerance）网络中断或节点之间无奈互相通信，零碎依然可能放弃可用性和一致性。在CAP实践中，在分布式系统中只能抉择其中两个属性，并且个别状况下抉择分区容忍性是必须的，因为网络分区是不可避免的，特地在大规模的分布式系统中。Zookeeper在设计时偏向于CP（一致性和分区容忍性）模型。它优先保证数据的一致性和分区容忍性，而可用性可能会在某些状况下受到影响。在Zookeeper中，当网络分区产生时，集群会尝试维持数据的一致性，但可能会导致一些节点在分区期间临时不可用。这是因为Zookeeper为了保持数据的一致性，须要在少数节点上进行写操作确认，如果无奈满足少数节点的写操作，写操作将被阻塞，从而影响可用性。 06 总结Zookeeper 作为 Hadoop 我的项目中的一个子项目，是 Hadoop 集群治理的一个必不可少的模块，它次要用 来管制集群中的数据，如它治理 Hadoop 集群中的 NameNode，还有 Hbase 中 Master Election、 Server 之间状态同步等。Zoopkeeper 提供了一套很好的分布式集群治理的机制，就是它这种基于档次型的目录树的数据结构，并对树中的节点进行无效治理，从而能够设计出多种多样的分布式的数据管理模型。

zookeeper原文https://www.baeldung.com/apache-curator 1. IntroductionApache Curator is a Java client for Apache Zookeeper, the popular coordination service for distributed applications. Apache Curator 是 Apache Zookeeper 的 Java 客户端，后者是分布式应用程序的风行协调服务。 In this tutorial, we'll introduce some of the most relevant features provided by Curator: Connection Management – managing connections and retry policiesAsync – enhancing existing client by adding async capabilities and the use of Java 8 lambdasConfiguration Management – having a centralized configuration for the systemStrongly-Typed Models – working with typed modelsRecipes – implementing leader election, distributed locks or counters在本文中，咱们讲介绍一些Curator提供的最实用的性能实现： ...

1 通过virtualbox配置3台主机ubuntu 22.041.1 网络配置为host-only & nat参考：https://segmentfault.com/a/1190000044119197 1.2 hostname别离设置为zk1, zk2, zk3hostname change command: hostnamectl hostname zk1 1.3 配置/etc/hosts 192.168.59.6 zk1192.168.49.3 zk2192.168.216.3 zk3ip address依据具体情况替换ip a command查问 2 install jdkjdk-8u144-linux-x64.tar.gz: https://www.oracle.com/java/technologies/javase/javase8-archi... 设置zookeeper工作目录，比方 /data/soft/new/将该目录user group设置以后用户可拜访, 假如以后用户为zk chown zk:zk -R /data/soft/new/ 解压： tar xvf jdk-8u144-linux-x64.tar.gz挪动： mv jdk-8u144-linux-x64 /data/soft/new/jdk配置jdk全局变量： # vim ~/.bashrcexport JAVA_HOME=/data/soft/new/jdkexport PATH=$PATH:$JAVA_HOME/bin使失效：source ~/.bashrc 3 install zookeeperzookeeper-3.4.6: https://archive.apache.org/dist/zookeeper/ tar xvf zookeeper-3.4.6.tar.gzmv zookeeper-3.4.6 /data/soft/new/zookeeper# 创立状态数据存储文件夹mkdir -p /data/soft/new/zkdata配置zoo.cfg 1 cd /data/soft/new/zookeeper/conf2 cp zoo_sample.cfg zoo.cfg3 vim zoo.cfg编辑zoo.cfg ...

介绍Curator是netflix公司开源的一套zookeeper客户端，目前是Apache的顶级我的项目。和ZK的原生客户端相比，Curator的抽象层次要更高，同时简化了ZK的罕用性能开发量，比方Curator自带连贯重试、重复注册Watcher、NodeExistsException 异样解决等等。 依据官网的介绍，咱们能够理解到它是一个用于分布式的Java客户端API工具。它基于high-level API，领有它能够更简略易懂的指挥vZookeeper实现分布式平安利用程序开发。 Curator由一系列的模块形成，对于个别开发者而言，罕用的是curator-framework和curator-recipes，上面对此顺次介绍。 Curator 当然也包含许多扩大，比方服务发现和Java 8异步DSL。 Apache Curator is a Java/JVM client library for [Apache ZooKeeper](https://zookeeper.apache.org/), a distributed coordination service.Apache Curator includes a high-level API framework and utilities to make using Apache ZooKeeper much easier and more reliable. It also includes recipes for common use cases and extensions such as service discovery and a Java 8 asynchronous DSL.用官网的介绍来说就是：guava之于java就像curator之于zookeeperZK 版本反对Curator 目前最新的版本为 5.X 的版本，曾经不反对 ZK 的 3.4.X 以及之前的版本，这里通过思考最终抉择了 ZK的 3.5.10 版本。 ...

引言本文将会介绍两种实现形式：增加服务办法和增加启动脚本办法，留神Zookeeper启动一个最小集群个别至多须要3台机器实现。 无关集体学习应用的ZK集群的部署过程能够参考：[[【Zookeeper】基于3台linux虚拟机搭建zookeeper集群]](https://segmentfault.com/a/1190000043925962)。 服务脚本和启动脚本备份集体筹备了两份脚本文件，须要的时候能够间接下载上传到服务器，略微批改配置之后，依照下文的步骤操作，即可疾速实现开机主动搭建集群。 链接：https://pan.baidu.com/s/1AZeQugRjHExsUhtQ93-Feg?pwd=3w2b提取码：3w2b 增加服务办法1、切换到/lib/systemd/system/目录，创立自启动文件切换到对应目录。 cd /lib/systemd/system/新建文件 zookeeper.service。 vim zookeeper.service外部增加如下内容： [Unit]Description=zookeeperserviceAfter=network.target[Service]#zookeeper门路WorkingDirectory=/opt/zookeeper/zk3.5.10/zk3510 ExecStart=/opt/zookeeper/zk3.5.10/zk3510/bin/zkServer.sh start User=rootGroup=rootRestart=alwaysRestartSec=10[Install]WantedBy=multi-user.target留神把 WorkingDirectory 和 ExecStart 替换为本人的门路。 2. 从新加载配置信息：systemctl daemon-reload3. 设置自启动systemctl enable zookeeper.service[root@zknode3 system]# systemctl daemon-reload[root@zknode3 system]# systemctl enable zookeeper.serviceCreated symlink from /etc/systemd/system/multi-user.target.wants/zookeeper.service to /usr/lib/systemd/system/zookeeper.service.4. 启动服务systemctl start zookeeper.service5.  查看启动状态systemctl status zookeeper.service因为集体应用了上面介绍的“启动脚本办法”进行自启动，所以这里报错了。 [root@zknode3 system]# systemctl status zookeeper.service● zookeeper.service - zookeeperservice Loaded: loaded (/usr/lib/systemd/system/zookeeper.service; enabled; vendor preset: disabled) Active: activating (auto-restart) (Result: exit-code) since Wed 2023-06-28 04:12:27 EDT; 95ms ago Process: 1583 ExecStart=/opt/zookeeper/zk3.5.10/zk3510/bin/zkServer.sh start (code=exited, status=1/FAILURE) Main PID: 1583 (code=exited, status=1/FAILURE)Jun 28 04:12:27 zknode3 systemd[1]: zookeeper.service: main process exited, code=exited, status=1/FAILUREJun 28 04:12:27 zknode3 systemd[1]: Unit zookeeper.service entered failed state.Jun 28 04:12:27 zknode3 systemd[1]: zookeeper.service failed.6. 自启动相干命令从新加载配置信息： ...

最近在读《数据密集型利用零碎设计》，其中谈到了zookeeper对容错共识算法的利用。这让我想到之前参考的zookeeper学习材料中，误将容错共识算法写成了2PC（两阶段提交协定），所以筹备以此文对共识算法和2PC做梳理和辨别，也心愿它能帮忙像我一样对这两者有误会的同学。 1. 2PC（两阶段提交协定）两阶段提交 (two-phase commit) 协定是一种用于实现 跨多个节点的原子事务（分布式事务）提交 的算法。它能确保所有节点提交或所有节点停止，并在某些数据库外部应用，也以 XA事务 的模式在分布式服务中应用。 在 Java EE 中，XA事务应用 JTA(Java Transaction API) 实现。2PC的实现2PC蕴含 筹备阶段 和 提交阶段 两个阶段，须要借助 协调者（事务管理器，如阿里巴巴的Seata）  来实现，参加分布式事务的数据库节点为 参与者。当分布式服务中的节点筹备提交时，协调者开始 筹备阶段：发送一个 筹备申请 到每个节点，询问它们是否可能提交，而后协调者会跟踪参与者的响应 如果所有参与者都答复"是"，示意它们曾经筹备好提交，那么协调者在 提交阶段 收回 提交申请，分布式事务提交如果任意一个参与者答复"否"，则协调者在 提交阶段 中向所有节点发送 停止申请，分布式事务回滚 上图是2PC提交胜利的状况，咱们来详述下过程： 当服务启动一个分布式事务时，它会向协调者申请一个事务ID，此事务ID是全局惟一的在每个参与者上启动单节点事务，每个单节点事务会持有这个全局事务 ID。所有的读写都是在这些单节点事务中各自实现的。如果在这个阶段呈现任何问题（节点解体或申请超时），则协调者或任何参与者都能够停止当利用筹备提交时，对应筹备阶段：协调者向所有参与者发送一个 筹备申请，同样也持有全局事务 ID 。如果任意一个申请失败或超时，则协调者向所有参与者发送针对该事务 ID 的 停止申请，即2PC提交停止的状况参与者收到 筹备申请 时，须要确保在任意状况下都能够提交事务。这包含将所有事务数据写入磁盘（呈现故障，电源故障，或硬盘空间有余都不能是稍后回绝提交的理由）以及查看是否存在任何抵触或违反束缚。通过向协调者答复 “是”，节点承诺这个事务肯定能够不出差错地提交。也就是说：参与者没有理论提交，同时放弃了停止事务的权力当协调者收到所有 筹备申请 的回答时，会就 提交或停止事务 作出明确的决定（只有在 所有参与者 投赞成票的状况下才会提交），这里对应提交阶段。协调者必须把这个提交或停止事务的决定 写到磁盘上的事务日志中，记录为 提交点（commit point） 。如果它随后解体，能通过提交点进行复原一旦协调者的决定曾经保留在事务日志中，提交或停止申请会发送给所有参与者。如果这个申请失败或超时，协调者 必须永远放弃重试，直到胜利为止，对于曾经做出的决定，协调者不论须要多少次重试它都必须被执行2PC协定中有两个要害的 不归路 须要留神： 一旦协调者做出决定，这一决定是不可撤销的参与者投票 “是” 时，它承诺它稍后必定可能提交（只管协调者可能依然抉择放弃），即便参与者在此期间解体，事务也须要在其复原后提交，而且因为参与者投了赞成，它不能在复原后回绝提交这些承诺保障了2PC的 原子性。 协调者生效的状况如果 协调者生效 并且所有参与者都收到了筹备申请并投了是，那么参与者什么都做不了只能期待，而且这种状况 解决方案 是期待协调者复原或数据库管理员染指操作来提交或回滚事务，当然如果在生产期间这须要承当运维压力。 所以，协调者在向参与者发送提交或停止申请 之前，将其提交或停止决定写入磁盘上的事务日志（提交点）。这样就能在协调者产生解体复原后，通过读取其事务日志来确定所有 存疑事务 的状态，任何在协调者事务日志中没有提交记录的事务都会被终止。因而两阶段提交在第二阶段（提交阶段）存在阻塞期待协调者复原的状况，所以两阶段提交又被称为 阻塞原子提交协定。 番外：3PC三阶段提交协定也是利用在分布式事务提交中的算法，它的提出是为了解决两阶段提交协定中存在的阻塞问题。它分为 CanCommit阶段、PreCommit阶段 和 DoCommit阶段，通过引入 参与者超时判断机制 来解决2PC中存在的参与者依赖协调者的提交申请而阻塞导致的资源占用等问题。 上图为在DoCommit阶段，参与者判断 DoCommit申请 超时状况的流程图，咱们详述下它的防止阻塞的流程 服务在每个参与者上启动单节点事务，当参与者筹备提交时，对应CanCommit阶段，协调者会向所有参与者发送 CanCommit申请，如果任意一个申请失败或超时，则协调者会向所有参与者发送针对该事务的 停止申请，执行事务回滚当协调者收到所有CanCommit申请的回答时，如果全是“是”那么则进入PreCommit阶段，否则发送停止申请，执行事务回滚进入PreCommit阶段后，协调者会向所有参与者发送 PreCommit申请，同样还是如果存在申请失败或超时，会发送停止申请执行事务回滚协调者收到所有PreCommit申请的回答时，如果全是“是”那么则进入DoCommit阶段，否则发送停止申请，执行事务回滚进入DoCommit阶段后，协调者会向所有参与者发送 DoCommit申请，留神这里，如果某个参与者没有收到该申请，它默认认为协调者会发送提交申请，那么便本地执行提交事务，从而防止阻塞3PC尽管解决了2PC中存在的阻塞问题，然而也引入了新的问题： 如果协调者在DoCommit阶段回复的是停止申请，那么超时节点自顾自地提交事务就会产生数据不统一的状况通信次数减少和实现绝对简单3PC使原子提交协定变成非阻塞的，然而3PC 假设网络提早和节点响应工夫无限，在大多数具备有限网络提早和过程暂停的理论零碎中，它 并不能保障原子性。非阻塞原子提交须要一个 完满的故障检测器 来以牢靠的机制判断一个节点是否曾经解体，而在有限提早的网络中，超时并不是一种牢靠的故障检测机制，因为即便节点没有解体也会因为网络提早而超时，出于这个起因，2PC依然被应用，只管存在协调者故障的问题。 2. 容错共识算法容错共识算法用于 节点间数据同步，保障各个正本间数据的一致性和集群的高可用。它的通常模式是一个或多个节点能够 提议（propose）  某些值，而共识算法 决定（decides）  采纳其中的某个值，并让这些节点就提议达成统一。共识算法必须具备如下性质： 一致同意：没有两个节点的决定不同完整性：没有节点决定两次有效性：如果节点决定了v值，那么v由该节点所提议终止性：由所有未解体的节点来最终决定值终止性本质上是说：容错共识算法不能简略地永远闲坐着期待，而是须要依据大多数节点来达成一项决定，因而终止属性也暗含着 不超过一半的节点解体或不可达 的信息。一致同意和完整性是共识的 核心思想，即所有节点决定了雷同的后果并且决定后不能扭转主见。 容错共识算法在节点集群外部都以某种模式应用一个领导者，并定义了一个 纪元编号（epoch number）  来确保在每个时代中，领导者都是惟一的。每当现任领导宕机时，节点间会开始一场投票，来选出一个新的领导，每次选举被赋予一个新的纪元编号（全序且枯燥递增），如果有两个不同时代的领导者之间呈现抵触（脑裂问题），那么带有更高纪元编号的领导者说了算。领导者每想要做出的每一个决定，都必须将提议值发送给其余节点，并期待 法定人数 的节点响应并赞成提案。法定人数通常（但不总是）由少数节点组成（个别为过半），只有在没有发现任何带有更高纪元编号的领导者的状况下，一个节点才会投票赞成提议。 容错共识算法的局限性节点在做出决定之前对提议进行投票的过程是一种同步复制共识零碎总是须要有 法定人数 的节点存活来保障运行大多数共识算法假设参加投票的节点是固定的汇合，这意味着你不能简略的在集群中增加或删除节点共识零碎通常依附 超时 来检测生效的节点，在网络提早高度变动的环境中，特地是在天文上分布的零碎，常常产生一个节点因为临时的网络问题，谬误地认为领导者曾经生效。尽管这种谬误不会侵害平安属性，但频繁的领导者选举会导致蹩脚的性能体现，所以共识算法对网络问题比拟敏感，而在面对不牢靠的网络相干的共识算法钻研仍在停顿中3. 2PC和容错共识算法的区别负责解决的问题不同：2PC解决的是分布式事务的一致性，各个节点存储的数据各有不同，指标侧重于保障事务的ACID；容错共识算法解决的是节点正本间数据的一致性和保障集群的高可用，节点间存储的数据完全一致，指标侧重于数据的复制和同步每个提议通过要求的参加节点数不同：2PC要求 所有的参与者表决胜利 才通过；容错共识算法只须要 遵循基于法定人数的表决 即可，这也是容错共识算法 终止属性（由所有未解体的节点来决定最终值）  的体现集群的高可用保障：2PC的协调者不是通过选举产生的，而是独自部署并人为指定的组件，所以它没有选主机制，不具备高可用性；利用容错共识算法的集群领导者是通过选举机制来指定的，并且在产生异常情况时（主节点宕机）可能选出新的领导者，并进入统一的状态，以此来保障集群的高可用4. zookeeper中的一次Create申请一些材料中会提到zookeeper在执行CRUD申请时，应用的是2PC，而 实际上它应用的是容错共识算法。咱们以Create申请的流程为例（如下图），来加深和记忆这一常识 客户端发 create 申请到 Leader，即便申请没落到 Leader 上，那么其余节点也会将写申请转发到 LeaderLeader 会先发一个 提议（proposal）申请给各个 Follower，且本人将数据写到本地文件Follower 集群收到 proposal 申请后会将数据写到本地文件，写胜利后返回给 Leader 一个 ack回复Leader 发现收到 ack 回复的数量为 法定人数（过半，蕴含以后 Leader 节点）时，则提交一个 commit 申请给各个 Follower 节点。发送 commit 申请就代表该数据在集群内同步状况没有问题，并且 能够对外提供拜访 了，此时Leader会把数据写到内存中Follower 收到 commit 申请后也会将数据写到各自节点的内存中，同时Leader会将数据发给 Observer集群，告诉 Observer集群 将数据写到内存伟人的肩膀《数据密集型利用零碎设计》第九章：分布式事务与共识百度百科：三阶段提交浅谈分布式一致性协定之3PC分布式事务(2PC) vs 共识协定(Paxos/raft)《深度分析zookeeper外围原理》原文收录：GitHub-Enthusiasm作者：京东物流 王奕龙 ...

环境和版本阐明环境阐明： 操作系统：Win11 2023 22H2CPU：13代 i6内存：64G虚拟机：VM Tool 17CenterOs版本：7.9镜像：CentOS-7-x86_64-Minimal-2009_2.isoZookeeper 版本：3.5.101. 进入官网下载CenterOs 7.9官网地址：https://www.centos.org/download/ 这里还是倡议有条件的用用魔法啥的。依据集体环境抉择 x86_64。 集体比拟举荐 163 和 阿里云的镜像： http://mirrors.aliyun.com/centos/7.9.2009/isos/x86_64/ http://mirrors.163.com/centos/7.9.2009/isos/x86_64/ 点击之后急躁期待下载即可。 2. 装置 Vmware 17嗯哼，集体用的是绿化版，怕作者网站被爆这里就不提供链接和操作阐明了。 3. 在Vmware 17上装置CenterOs 7.9集体倡议装置好一台之后，利用拷贝虚拟机的形式复制三份零碎，并且在文件治理中用目录辨别，不便换电脑或者迁徙的时候能够疾速复原应用。 比方上面集体的简略划分形式。 新建虚拟机 这里集体抉择“稍后装置操作系统”，也能够间接架在程序光盘映象文件。 集体笔记本电脑配置尚可，这里给了双核。 内存调配个1G即可，也能够酌情按需减少。 这里抉择NAT，如果不嫌IP变动麻烦，能够是用“桥接网络”。 前面始终下一步即可，直到呈现上面的画面。磁盘大小能够依照须要进行调配。 依照齐全自定义的形式装置，此时须要本人手动指定一下操作系统的镜像文件地位： 装置CenterOs 7.9启动虚拟机，看到如下界面之后抉择第一个。 急躁期待安装程序疏导。抉择语言，这里倡议抉择英文，顺带锤炼下英文程度： 进入下一步之后，通常须要确认一下操作系统装置到哪一块磁盘下面。 不相熟Linux的分区设置间接应用官网默认的配置即可（如果要手动设置分区能够抉择上面的“I will configure partitioning”）。 接着手动设置一下网卡，这里记得开启一下开关，否则装置之后无奈主动联网（须要手动调整一下网卡开关）。 CenterOs 零碎个别都是用于服务器应用，大多数状况下都是动态IP，所以默认是不开启网卡的。 因为是最小化装置，本人能够干的事件无限，这里咱们间接下一步即可。 之后是设置root明码和构建自定义用户，如果用户明码强度过低点击“Done”可能会没有任何反馈，然而能够通过两次点击“Done”给强制通过。 这里放一下集体的操作<s>root明码是经典的root</s>。 另外新建一个伪root用户，用于本人登陆操作（不倡议养成root登陆的习惯）。 ...

背景在 ZooKeeper 的日常应用过程中，一个令人头疼的问题就是节点的磁盘容量问题，如果因为过大的 TPS 或者不适当的清理策略会导致集群中数据文件，日志文件的沉积，最终导致磁盘爆满，Server 宕机。近期就在线上发现某用户的一个集群在一个时间段内的 TPS 暴增。导致磁盘中 snapshot 和 transaction log 文件十分多。 残缺内容请点击下方链接查看： https://developer.aliyun.com/article/1126879?utm_content=g_10... 版权申明：本文内容由阿里云实名注册用户自发奉献，版权归原作者所有，阿里云开发者社区不领有其著作权，亦不承当相应法律责任。具体规定请查看《阿里云开发者社区用户服务协定》和《阿里云开发者社区知识产权爱护指引》。如果您发现本社区中有涉嫌剽窃的内容，填写侵权投诉表单进行举报，一经查实，本社区将立即删除涉嫌侵权内容。

背景ZooKeeper 作为分布式系统的元数据中心，对外服务的数据一致性须要失去很好的保障，然而一些老版本的 ZooKeeper 在一些状况下可能无奈保证数据的一致性，导致依赖 ZooKeeper 的零碎出现异常。 某用户应用 3.4.6 版本 ZooKeeper 做任务调度，ZooKeeper 实例的 tps 和 qps 都比拟高，事务日志产生的速率很快，即便此用户配置了主动清理的参数，然而主动清理的最小距离还是赶不上数据产生的速度，导致磁盘爆满。 在此用户清理了旧日志之后，重启节点，局部业务机器就报出 NodeExist，NoNode 的异样，并且报错只集中在局部机器，此次异样导致用户任务调度零碎呈现工作反复调度以及工作失落问题，产生重大损失。 起因剖析仔细检查了这些客户端发现这些客户端都连贯在同一台 ZooKeeper 节点上，通过 zkCli 手动排查节点上的数据，比照其余未清理磁盘的 ZooKeeper 节点，清理了磁盘的 ZooKeeper 节点中的数据和其余节点具备差别，此时确定此节点因为一些起因呈现了数据不统一问题，导致连贯到此节点的客户端读到了脏数据。 然而排查日志，没有发现异常日志。因为此节点之前清理过日志，并且重启过，磁盘上的数据被从新加载过，因而狐疑是 ZooKeeper 在启动加载数据的过程中呈现了一些异常情况。通过剖析 ZooKeeper 启动中加载数据的代码，持续排查具体起因。 public long restore(DataTree dt, Map<Long, Integer> sessions, PlayBackListener listener) throws IOException { snapLog.deserialize(dt, sessions); FileTxnLog txnLog = new FileTxnLog(dataDir); TxnIterator itr = txnLog.read(dt.lastProcessedZxid+1); long highestZxid = dt.lastProcessedZxid; TxnHeader hdr; try { while (true) { ... try { processTransaction(hdr,dt,sessions, itr.getTxn()); } catch(KeeperException.NoNodeException e) { throw new IOException("Failed to process transaction type: " + hdr.getType() + " error: " + e.getMessage(), e); ... return highestZxid; }此处是 ZooKeeper 加载磁盘数据的代码，此办法的次要作用是，首先将磁盘中的 snapshot 文件加载进内存，初始化 ZooKeeper 内存中的数据结构，之后将加载事务日志利用日志中对数据的批改，最终还原磁盘中数据的状态。 ...

1、3.4.5 源码编译1、下载源码，执行以上批改首先 build.xml更改<property name="ivy.url" value="https://repo1.maven.org/maven2/org/apache/ivy/ivy" />ivysettings.xml更改<property name="repo.maven.org" value="https://repo1.maven.org/maven2/" override="false"/> <property name="repo.jboss.org" value="https://repository.jboss.org/nexus/content/groups/public-jboss/" override="false"/> <property name="repo.sun.org" value="https://download.java.net/maven/2/" override="false"/>其实都是把http改为https，否则这会无法访问，在2020年1月之后就不能够拜访了2、执行 ant eclipse3、import 指定 eclipse4、/Users/xxx/IdeaProjects/zookeeper 间接根目录下执行 ant即可 2、Zookeeper三种角色 & 节点类型Leader、Follower和Observer只有Leader能够写数据，其余节点只能同步数据，Follower参加选举Observer不参加选举所以只能一个leader进行写，单机写入最多每秒上万QPS，这是没法扩大的，所以zk适宜是写少读多的场景长久化节点、长期节点、程序节点(是和长久化节点和长期节点配合应用) 3、ZAB(Zookeeper Atomic Broadcast)ZAB = 2PC + 过半写磁盘日志， proposal(os cache) + 过半ack + commit(forceSync磁盘)内存数据结构 4、程序一致性程序一致性，其实是最终一致性。因为leader肯定会保障所有的proposal同步到follower上都是依照程序来走的，起码程序不会乱 5、Zookeeper集群部署 & 外围参数4核8G的机器，一般来说，每秒并发搞到1000是能够的8核16G的机器，每秒并发搞到几千是能够的16核32G的机器，每秒并发搞到上万或者是几万都是有可能的 tickTime : 默认2s，其余一些参数会以这个tickTime为基准来进行设置dataDir : 数据快照dataLogDir : 日志数据，proposal日志文件snapCount : 默认10万个事务，存储一次快照initLimit : 默认是10， 10 * tickTime，20s，启动结束之后，follower和leader之间的数据同步，如果超过这个工夫，leader间接对外提供服务了syncLimit : 默认值是5，5 * 2 = 10s，leader和follower之间会进行心跳，如果超过10s没有心跳，leader就把这个follower给踢出去了，认为他曾经死了maxClientCnxns : 每个客户端对zk的连贯最大是60个jute.maxbuffer : 一个znode最多能够存储1MB数据 server.x = zk01:2888:38883888 是用来leader选举的，2888是用来数据同步的 客户端反对非交互式./zkCli.sh -server localhost:2181 get /zookeeper2 6、读写锁[写锁，写锁，读锁，读锁，写锁，读锁，读锁，读锁]写锁只关怀后面一个节点，对后面的这个节点做监听，读锁，应该计算排在离本人最近的一把写锁所谓的羊群效应，就是不能我开释锁了，把所有不是监听我的锁都惊醒了，curator读锁应该是判断的离本人最后面的一个写锁 7、leader选举三台机器myid 1,2,3如果是空的集群，他们zxid都是0，如果是1,2,3顺次启动，则第二台机器入选为leader，当quorum=(3/2+1)=2，半数的机器的时候才会进行选举leader选举第一轮投票myid=0的机器，投票(0,0)，(myid,zxid)，播送给集群其余节点myid=1的机器，投票(1,0)，(myid,zxid)，播送给集群其余节点myid=0的机器，接管到(1,0)，和投出去(0,0)比照，因为不一样，须要从新调整抉择(1,0)myid=1的机器，接管到(0,0)，和投出去(1,0)比照，不须要从新调整持续(1,0) ...

背景线上 flink 用户应用 ZooKeeper 做元数据中心以及集群选主，一些版本的 flink 在 ZooKeeper 选主时，会重启 Job，导致一些非预期的业务损失。而 ZooKeeper 在 zxid溢出时，会被动触发一次选主，就会导致 flink Job 的非预期重启，造成业务损失。本篇从原理和最佳实际上剖析和解决因为 ZooKeeper zxid 溢出导致的集群选主问题。查看 ZooKeeper Server 日志呈现。 zxid lower 32 bits have rolled over, forcing re-election, and therefore new epoch start解决办法ZooKeeper 自身提供以后解决的最大的 Zxid，通过 stat 接口可查看到以后解决的最大的 zxid 的值，通过此值能够计算以后 zxid 间隔溢出值还有多少差距。MSE 提供风险管理以及集群选主相干告警，提前预防和及时感知选主危险，防止业务损失。 通过 MSE ZooKeeper 风险管理和集群选主工夫告警，预知危险。MSE ZooKeepr 提供风险管理的能力，风险管理会定期扫描集群危险，告诉用户，zxid 溢出就是集群的危险之一，当 zxid 靠近溢出值之前，通过风险管理对危险的扫描，就能够看到集群zxid溢出的危险，提前做好躲避。 风险管理会每天扫描集群的各项危险，也能够通过手动触发 一键健康检查进行集群危险诊断。 同时通过 MSE ZooKeeper 的集群选主工夫告警，能够检测集群的选主工夫，防止因为集群选主工夫过长导致业务损失。通过告警治理中创立 MSE 告警规定进行集群选主工夫的告警设置。 起因剖析什么是zxid，它是怎么产生的？首先咱们理解一下什么是 zxid，它是怎么产生的：zxid 是 ZooKeeper 中一个事务的全局惟一 id，通过 zxid 形容各个事务之间的全序关系。客户端对 ZooKeeper 外部数据的变更都是通过事务在 ZooKeeper 集群内的流传和解决实现的，因而 zxid 就是客户端对数据进行一次变更所产生的事务在全局事务中的一个惟一 id，这个 id 形容了本次变更的事务在全局事务中的地位，并且不会有两个不同的事务领有雷同的 zxid（全序关系）。 ...

ZooKeeper是一个分布式的，开放源码的分布式应用程序协调服务，是Google的Chubby一个开源的实现，是Hadoop和Hbase的重要组件。它是一个为分布式应用提供一致性服务的软件，提供的性能包含：配置保护、域名服务、分布式锁服务、集群治理、生成分布式惟一ID等。 Apache Dubbo 是一款高性能、轻量级的开源Java RPC框架，提供面向接口代理的高性能RPC调用、智能负载平衡、服务主动注册和发现、运行期流量调度、可视化服务治理和运维等性能。 作为架构师必须把握的分布式架构技术，你的小编（雷锋）在这个星期费神费劲给大家着重收集并整顿了这份对于ZooKeeper+Dubbo技术栈的源码+笔记+我的项目实战的材料。 第一阶段深刻Zookeeper原理和源码，剖析Zookeeper的外围实现，并通过多个利用场景阐明，体现出其重要性和宽泛的应用性。第二阶段深刻Dubbo RPC、SPI等外围性能点，列举多个示例加以利用阐明，冀望可能帮忙学者疾速晋升Dobbo和Zookeeper的技术能力。以上就是材料蕴含的内容，上面小编会展现目录和具体内容截图，有须要完整版源码+笔记的敌人，【间接点击此处】即可支付！！ 第一份笔记：Zookeeper+Dubbo技术栈笔记 一：Zookeeper篇 1.分布式概述 2.ZK概述 3.分布式CAP 4.一致性实现 5.ZK单机&集群搭建 6.ZK疾速入门 7.ZK源码解析 8.ZK利用场景 9.分布式锁和队列 二：Dubbo篇 1.RPC外围 2.手写RPC 3.Dubbo高可用 4.Dubbo IO模型 5.Dubbo 架构 6.源码解析 第二份：Nginx：模块开发与架构解析第一局部Nginx能帮咱们做什么 1，钻研Nginx前的筹备工作2，Nginx的配置 第二局部如何编写HTTP模块 3，开发-一个简略的HTTP模块4，配置、error日志和申请上下文5，拜访第三方服务6，开发-一个简略的HTTP过滤模块7，Nginx提供的高级数据结构 第三局部深刻Nginx 8， Nginx基础架构9，事件模块10，HTTP框架的初始化11，HTTP框架的执行流程12，upstream机制的设计与实现13，邮件代理模块14，过程间的通信机制15，变量16，slab共享内存

MacBook Linux装置zookeeperZooKeeper是一个分布式的，开放源码的分布式应用程序协调服务，是Google的Chubby一个开源的实现，是Hadoop和Hbase的重要组件。它是一个为分布式应用提供一致性服务的软件，提供的性能包含：配置保护、域名服务、分布式同步、组服务等。 官网下载地址: https://downloads.apache.org/... #官网下载 zookeeper-3.4.12.tar.gz#解压tar -zxvf zookeeper-3.4.12.tar.gz#进入目录cd zookeeper-3.4.12#复制配置文件cp conf/zoo_sample.cfg conf/zoo.cfg#创立日志目录mkdir logs#批改配置vim conf/zoo.cfg #指定日志目录dataDir=/Users/liang/software/zookeeper-3.4.12/logs#启动服务,默认是后盾启动./bin/zkServer.sh start#查看状态 ./bin/zkServer.sh status#回显如下:ZooKeeper JMX enabled by defaultUsing config: /Users/liang/software/zookeeper-3.4.12/bin/../conf/zoo.cfgMode: standalone#敞开服务./bin/zkServer.sh stop #后盾形式启动服务#./bin/zkServer.sh start &

服务注册核心，是一个给服务提供者注册服务、给服务消费者获取服务信息的中央，个别还提供服务列表查问、心跳检测等性能。注册核心为保障可用性个别集群部署。注册核心组件咱们可选的组件有Eureka、ZK、Nacos，而依据CAP定律，ZK反对CP，Eureka反对AP，Nacos可反对AP也可反对CP。上面别离论述下。 一、Eureka Eureka分服务端与客户端，服务端为注册核心，而客户端实现向服务端注册与服务发现。服务端的次要工作有： 提供服务注册。提供一个对立存储服务的中央，客户端（服务提供者）将服务注册后服务端提供治理提供注册表。为客户端（服务消费者）提供服务列表的查问，也就是服务发现性能。客户端获取服务列表后个别会在本地进行缓存，以缩小与注册核心交互服务剔除。如果客户端在肯定工夫内未上报心跳，服务端会剔除此服务实例自我爱护机制。一段时间内如果客户端可用率低于肯定比例则会进入自我爱护阶段，避免Eureka客户端自身是能够失常拜访的，然而因为网路通信故障等起因，造成Eureka服务端失去于客户端的连贯，从而造成的不可用客户端的性能这里只是简略列举一下：服务注册、主动刷新缓存获取最新服务列表、服务续约上报心跳、近程调用、服务下线。 注册与发现的工作流程： server启动后，client启动后将服务注册到serverclient默认每30s向server发动心跳server若 90s没收到client的心跳申请，则统计15分钟内是否有超过85%的比例，如果有进入自我爱护状态；如果没有则剔除该clientclient定时调用server接口获取服务列表更新本地缓存client近程调用时，先从本地缓存找，如果找到则间接发动调用，如果没有则先向server进行查问后再发动调用client敞开时会发http申请到server，server承受申请后将该实例剔除Eureka是CAP里的AP从CAP实践看，Eureka是一个AP零碎，其优先保障可用性(A)和分区容错性，不保障强一致性，但能做到最终一致性。 只有集群中任意一个实例不呈现问题，Eureka服务就是可用的；即Eureka Client 在向某个 Eureka Server 注册时，如果发现连贯失败，则会主动切换至其它节点；Eureka集群中没有主从的概念，各个节点都是平等的，节点间采纳Replicate异步的形式来同步数据；因为Eureka并不强调一致性而偏重可用性，在设计上为晋升性能采纳了多级缓存的计划。这种设计和mysql的读写拆散及JDK里的CopyOnWriteArrayList有点相似，目标是为了使操作不阻塞读操作。 Eureka数据存储机制 Eureka没有采纳数据库这类存储介质，它的数据层分数据存储层和缓存层。数据存储层记录注册到 Eureka Server 上的服务信息，缓存层是通过包装后的数据，能够间接在 Eureka Client 调用时返回。 存储层咱们先来看看数据存储层的数据结构，它底层是一个双层HashMap: private final ConcurrentHashMap<String, Map<String, Lease<InstanceInfo>>> registry= new ConcurrentHashMap<String, Map<String, Lease<InstanceInfo>>>();第一层的 ConcurrentHashMap 的 key=spring.application.name 也就是客户端实例注册的利用名；value 为嵌套的 ConcurrentHashMap。第二层嵌套的 ConcurrentHashMap 的 key=instanceId 也就是服务的惟一实例 ID，value 为 Lease 对象，Lease 对象存储着这个实例的所有注册信息，包含 ip 、端口、属性等。缓存层接下来咱们再来看看缓存层。 Eureka Server 为了提供响应效率，提供了两层的缓存构造，将 Eureka Client 所须要的注册信息，间接存储在缓存构造中。 第一层缓存：readOnlyCacheMap，实质上是 ConcurrentHashMap，依赖定时从 readWriteCacheMap 同步数据，默认工夫为 30 秒。readOnlyCacheMap ： 是一个 CurrentHashMap 只读缓存，这个次要是为了供客户端获取注册信息时应用，其缓存更新，依赖于定时器的更新，通过和 readWriteCacheMap 的值做比照，如果数据不统一，则以 readWriteCacheMap 的数据为准。 ...

架构 节点角色leader节点写和读。 从节点1.只读 2.选举leader 观察者节点1.只读 2.不选举leader 和从节点的区别？ 就是不参加选举leader。其余和从节点一样。 那有什么用呢？那为什么还要一个这种类型的节点呢？ 作用在于可读，可读的话，就能够替leader节点分担流量。就像从节点一样。 然而，比从节点的长处在于，不参加选举的话，性能就更快。比方，如果leader节点挂了，这个时候就要选举——问题就在这里，如果参加选举的节点数量过多，就会导致选举速度变慢。所以，观察者节点的作用，就是分担读的流量，然而不参加选举，从而进步选举leader的性能。 leader节点挂了如果leader节点挂了，会选举，过半节点抉择某个从节点，该从节点就晋升为leader节点。 选举期间，集群短暂不可写。 过半节点选举leader节点如果leader节点挂了，会选举，过半节点抉择某个从节点，该从节点就晋升为leader节点。 数据一致性每次写数据到leader节点的时候，都会复制数据到其余节点。 而且只有过半节点返回胜利，这次写数据才算胜利。也就是说，每次写数据，都要等过半节点确认胜利，能力返回给客户端。 上文有提到观察者节点的作用，分担读申请，然而不参加选举——这里的数据一致性过半节点确认，观察者节点也不参加，这样的话就缩小了参加确认节点的数量，从而进步写性能。 集群过半节点存活通信集群的每个节点之间，都会通信。 因为， 1.须要把leader节点的数据复制到从节点和观察者 从节点和观察者，也要提供读服务。 2.选举 选举的时候，须要投票。投票就要基于相互通信来实现。 转发写申请1.读申请 所有节点类型，都能够解决读数据。 2.写申请 1）leader节点 本人解决写数据。 2）非leader节点 转发给leader节点解决。

闲扯两句, 个别学习一门新技术我当初会间接看文档，文档上的一些外围观点放到文章中，起因在于我心愿记录我的思考过程，同时也是锤炼本人浏览英文文档的能力。概述首先咱们关上bing搜索引擎，搜寻Zookeeper，有同学可能会问，你为什么让关上bing搜素引擎，而不是百度呢。那是因为目前在百度搜寻Zookeeper，第一页没找到官网： 然而你关上bing搜寻Zookeeper: 个人感觉百度的搜寻品质有变差的迹象，所以我最近用bing比拟多。 ZooKeeper is a high-performance coordination service for distributed applications. It exposes common services - such as naming, configuration management, synchronization, and group services - in a simple interface so you don't have to write them from scratch. Zookeeper为分布式应用提供高性能协调服务，用简略的接口提供了许多服务，有域名服务、配置管理、分布式同步、组服务。 解读1: 域名服务、配置管理、分布式同步、组服务这四个似懂非懂. 解读2 为分布式应用提供了高性能的协调服务，高性能咱们是喜爱的，协调了啥？ 再聊聊分布式吧咱们再来聊聊服务端零碎架构的演进吧，最后的时候咱们的服务只在一台服务器上运行，缓缓的随着用户量的一直晋升，单机部署曾经无奈再满足访问量了。于是人们天然就想到了集群，即雷同的利用再部署一遍，由Nginx或其余中间件依据负载平衡算法将申请摊派到集群的机器上。然而为了谋求高牢靠，咱们不能将一个做单机集群，将利用在配置文件中改端口实现集群，然而这并不牢靠，如果这台计算机呈现了什么问题，整个服务都会变得不可用，为了不让鸡蛋放在一个篮子里，维持服务的高牢靠，咱们将服务在多台计算机上，这样就算一台计算机上的服务呈现了问题，服务还是可用的(当初咱们的服务还是一个单体利用)，这也就是分布式部署，所以分布式并不一定要和微服务挂钩。 然而这又引入了新的问题: 一个节点挂掉不能提供服务时如何被集群通晓并由其余节点接替工作例子: 当数据量与访问量一直回升，单机的MySQL无奈再撑持零碎的访问量，咱们开始搭建集群，晋升数据库的拜访能力，为了减少可靠性，咱们多机部署，甚至多地部署。 一般来说增删改耗费的性能远小于查问的性能，所以咱们选若干台数据库节点做写入，对于用户的新增数据申请，会摊派到写节点，写节点写入实现要将这个数据扩散到其余节点, 但这里有一个问题就是如果写节点挂掉呢，那一个自然而然的操作是从从库中再选一个读库回应申请，同时将挂掉的结点从集群中剔除. 在分布式的场景下如何保障工作只被执行一次。例子: 分布式下的定时工作，在计算机A和B上都部署了服务，如何保障定时工作只执行一次。这也就是Zookeeper的协调。 基本概念与设计指标在设计指标外面能看到外围概念。ZooKeeper is simple. (Zookeeper 是简略的)ZooKeeper allows distributed processes to coordinate with each other through a shared hierarchical namespace which is organized similarly to a standard file system. The namespace consists of data registers - called znodes, in ZooKeeper parlance - and these are similar to files and directories. Unlike a typical file system, which is designed for storage, ZooKeeper data is kept in-memory, which means ZooKeeper can achieve high throughput and low latency numbers. ...

1. 什么是 zookeeper ？zookeeper 是一个开源的分布式应用的协同服务 zookeeper 的设计指标是对简单易错的分布式应用的协同操作进行形象和封装： 简略的数据模型集群程序拜访高性能zookeeper 的个性： 程序一致性，zookeeper 的对于客户端的申请，严格依照发动程序进行解决原子性，事务性申请的原子性，要么全副失败，要么全副胜利可靠性，肯定事务申请胜利，集群所有节点对于该申请的后续响应都是一致性，除非有其余申请进行批改实时性，从 zookeeper 集群节点获取的数据都是最新的繁多视图，从 zookeeper 集群节点获取的数据始终是统一的2. zookeeper 提供哪些服务？应用程序要应用 zookeeper ，须要引入 对应的 zookeeper 客户端 zookeeper 典型的利用场景： 对立配置管理对立命名服务DNS 服务组成员治理（主从治理、负载平衡）分布式锁的实现zookeeper 更实用来存储一些要害数据，如配置文件、利用状态等，不适用于较大的数据量的存储理论示例： Hadoop：应用 zookeeper 做 Namenode 的高可用HBase：通过 zookeeper 保障集群中只有一个 master，保留集群中的 RegionServer 列表、保留 hbase:meta 表的地位Kafka：集群成员治理，controller 节点的选举3. zookeeper 的数据模型zookeeper 的数据模型是层次模型，相似于规范的文件系统 为什么应用层次模型而不是 K-V 模型： 层次模型的树形构造更容易表白数据之间的档次关系层次模型的树形构造便于为不同的利用调配独立的命名空间zookeeper 的层次模型的每个节点称为 znode，每个 znode 都能够保留数据（这是和文件系统的区别） 图示： zookeeper 对外提给了一个简化的类文件系统的 API 来拜访 znode： znode 以 UNIX 格调的门路进行命名，以 / 进行分隔znode 除了保留的数据，还以Key-Value 的模式保留了相干的版本信息等状态属性znode 的所有操作都是 wait-free，就是正执行的操作不影响其余 APIznode 最多存储 1 MB 的数据znode 的状态属性： ...

1. 什么是 Zookeeper？Zookeeper 是一个开源的高效牢靠的分布式协同服务 能够通过 Zookeeper 实现对立配置管理、对立命名服务、分布式锁、集群治理等 Zookeeper 更实用于存储和协同相干的要害数据，更实用于读多写少的利用场景 Zookeeper 有哪些个性（官网说是构建简单服务的保障）？ 程序一致性（事务申请都是有序执行的）原子性繁多视图（从集群任一节点获取的数据都是统一的）可靠性实时性2. Zookeeper 的数据模型Zookeeper 的数据模型是相似文件系统的层次模型 Zookeeper 的层次模型被称为 data-tree，date-tree 的每个节点叫做 znode： znode 是类 unix 格调的路径名来定位的，eg：/a/b，示意 znode节点 a 下的 子节点 bznode 的所有操作都是 wait-free 操作（一个操作是否执行完并不影响其余操作的执行）znode 分类： 持久性的 znode，创立之后始终保留，不会失落临时性的 znode，宕机或者超时就会失落长久程序性的 znode，具备程序性的持久性的 znode长期程序性的 znodeznode 的程序性直观的体现在 znode 命名上，每一个程序性的 znode 关联一个枯燥递增的整数，可能是后缀，也可能是命名znode 的基本操作： create：创立节点delete：删除节点setData：写入需保留的数据到节点内exists：判断节点是否存在getData：获取节点保留的数据getChildren：获取节点下所有子节点3. Zookeeper 集群角色Zookeeper 的集群角色有： Leader：负责解决所有事务申请（写操作），同时也能够解决读操作，协调集群外部服务Follower：只能解决非事务申请（读操作），Observer：只能解决读申请，转发写申请给 Leader 解决Zookeeper 是一主多从的架构，所以集群中只能有一个 Leader 从集群搭建的配置中看，咱们并没有指定集群的角色，因为 Zookeeper 集群的 Leader 是运行时动静选举进去的：一个节点获取超过半数节点的票数，就能够入选 Leader 如果 Leader 失联，则从 Follower 中从新选举，Observer 并不参加选举 Observer 负责察看 Zookeeper 集群的状态并进行同步，在不影响集群的状况下升高 Leader 的复杂程度 ...

本文应用「署名 4.0 国内 (CC BY 4.0)」许可协定，欢送转载、或从新批改应用，但须要注明起源。 署名 4.0 国内 (CC BY 4.0)本文作者: Nicksxs创立工夫: 2022-05-29本文链接: 记录下 zookeeper 集群迁徙和易错点 前阵子做了zk 的集群降级迁徙，大略状况是原来是一个三节点的 zk 集群（最小可用大略是 zk1 192.168.2.1zk2 192.168.2.2zk3 192.168.2.3在 zoo.cfg 中的配置就是如下 server.1=192.168.2.1:2888:3888server.2=192.168.2.2:2888:3888server.3=192.168.2.3:2888:3888加节点须要将集群迁徙到 192.168.2.4（简称 zk4），192.168.2.5（简称 zk5），192.168.2.6（简称 zk6） 这三台机器上，目前新的这三台机器上是没有 zk 部署的, 咱们想要的是数据不失落，那次要思考的就是滚动降级，这里我其实犯了几个谬误，也特地阐明下首先咱们想要新的三台机器加进去，所以我在zk4，zk5，zk6 的配置是这样 server.1=192.168.2.1:2888:3888server.2=192.168.2.2:2888:3888server.3=192.168.2.3:2888:3888server.4=192.168.2.4:2888:3888server.5=192.168.2.5:2888:3888server.6=192.168.2.6:2888:3888这样起来发现状态是该节点没起来，PS：查看以后节点状态能够通过 ./zkServer.sh status 来查看第一个问题是我须要一个myid文件，标识我是哪个节点，外面的内容就写 4或 5 或 6 这样就行了，并且这个文件的门路应该在配置文件中指定的dataDir=数据目录下第二个问题是困扰我比拟久的，我在按下面的配置启动节点后，发现这几个节点都是没起来的，并且有 FastLeaderElection@xxx - Notification time out: 60000 这个报错，一开始认为是网络不通，端口没开这些起因，查看了下都是通的，后果起因其实跟我之前的一个思考是相干的，当有六个节点的时候，实践上须要有半数以上的节点可用，集群才会是衰弱的，然而按我这个形式起来，其实我配置了六个节点，然而其中三个都是不可用的（包含本身节点），那么它天然是没方法失常工作，所以这里其实也须要滚动增加，相似于这样我的 zk4 的配置应该是这样 server.1=192.168.2.1:2888:3888server.2=192.168.2.2:2888:3888server.3=192.168.2.3:2888:3888server.4=192.168.2.4:2888:3888而后 zk5 的配置 server.1=192.168.2.1:2888:3888server.2=192.168.2.2:2888:3888server.3=192.168.2.3:2888:3888server.4=192.168.2.4:2888:3888server.5=192.168.2.5:2888:3888接着 zk6 的配置就能够是全副了 server.1=192.168.2.1:2888:3888server.2=192.168.2.2:2888:3888server.3=192.168.2.3:2888:3888server.4=192.168.2.4:2888:3888server.5=192.168.2.5:2888:3888server.6=192.168.2.6:2888:3888而后为了集群齐全更新，就持续在 zk4 和 zk5 加上其余节点，这样我的 6 节点集群就起来了 下节点这里我踩了另外一个坑，或者说没搞清楚两种形式的差异， ...

zookeeper-3.7.0 配置与部署官网文档 根底配置阐明Zookeeper 提供了一个简略的配置文件示例：zoo_simple.cfg # The number of milliseconds of each ticktickTime=2000# The number of ticks that the initial # synchronization phase can takeinitLimit=10# The number of ticks that can pass between # sending a request and getting an acknowledgementsyncLimit=5# the directory where the snapshot is stored.# do not use /tmp for storage, /tmp here is just # example sakes.dataDir=/tmp/zookeeper# the port at which the clients will connectclientPort=2181# the maximum number of client connections.# increase this if you need to handle more clients#maxClientCnxns=60## Be sure to read the maintenance section of the # administrator guide before turning on autopurge.## http://zookeeper.apache.org/doc/current/zookeeperAdmin.html#sc_maintenance## The number of snapshots to retain in dataDir#autopurge.snapRetainCount=3# Purge task interval in hours# Set to "0" to disable auto purge feature#autopurge.purgeInterval=1## Metrics Providers## https://prometheus.io Metrics Exporter#metricsProvider.className=org.apache.zookeeper.metrics.prometheus.PrometheusMetricsProvider#metricsProvider.httpPort=7000#metricsProvider.exportJvmInfo=truezookeeper 启动的时候默认会去加载 conf 目录下的 zoo.cfg 这个配置文件 ...

目前，国内泛滥的智能家居交互入口都将通过智能音箱，天猫精灵....来管制家电。极少有通过HomeKit来管制咱们灯、电视、摄像头等一系列家电产品。 本文将给大伙盘点那些通过第三方平台，来语音管制HomeKit设施，如华为智能音箱。仅用唤醒词“小艺小艺”唤醒华为智能音箱，这时能够听到音箱应答，而后再说“关上/敞开+设施名称”的语音指令即可；比方：“小艺小艺，关上客厅灯”。 1.在智汀家庭云APP内实现产品联网配置 依据APP内疏导实现设施联网配置，具体的教程解说参考：《如何用小度语音助手，去管制智汀家庭云里不同品牌设施？》 2.配置华为音箱 (如果你曾经配置好了华为智能音箱，你能够跳过这一步) ① 下载并装置华为智慧生存APP。 ② 注册或登录华为账号，并配对你的华为智能音箱。 3.绑定智汀账号 ① 点击智慧生存APP首页下方导航栏“我的”>> “连贯第三方平台” >> 找到“智汀” ② 点击绑定账号，批准对于智汀账号绑定的申明。 ③ 输出智汀账号、明码实现受权登录。 ④ 抉择须要绑定智慧生存的家庭，输出验证码实现绑定。 ⑤ 绑定胜利后智慧生存APP会主动同步您在智汀平台上的设施。 为确保语音管制失常应用，倡议输出一种语言文字。倡议设施命名例子：客厅灯，走廊插座、卧室开关...

public Vote lookForLeader() throws InterruptedException { try { self.jmxLeaderElectionBean = new LeaderElectionBean(); MBeanRegistry.getInstance().register( self.jmxLeaderElectionBean, self.jmxLocalPeerBean); } catch (Exception e) { LOG.warn("Failed to register with JMX", e); self.jmxLeaderElectionBean = null; } if (self.start_fle == 0) { self.start_fle = Time.currentElapsedTime(); } try { HashMap<Long, Vote> recvset = new HashMap<Long, Vote>(); HashMap<Long, Vote> outofelection = new HashMap<Long, Vote>(); int notTimeout = finalizeWait; synchronized(this){ logicalclock.incrementAndGet(); updateProposal(getInitId(), getInitLastLoggedZxid(), getPeerEpoch()); } LOG.info("New election. My id = " + self.getId() + ", proposed zxid=0x" + Long.toHexString(proposedZxid)); sendNotifications(); /* * Loop in which we exchange notifications until we find a leader */ while ((self.getPeerState() == ServerState.LOOKING) && (!stop)){ /* * Remove next notification from queue, times out after 2 times * the termination time */ Notification n = recvqueue.poll(notTimeout, TimeUnit.MILLISECONDS); /* * Sends more notifications if haven't received enough. * Otherwise processes new notification. */ if(n == null){ if(manager.haveDelivered()){ sendNotifications(); } else { manager.connectAll(); } /* * Exponential backoff */ int tmpTimeOut = notTimeout*2; notTimeout = (tmpTimeOut < maxNotificationInterval? tmpTimeOut : maxNotificationInterval); LOG.info("Notification time out: " + notTimeout); } else if(validVoter(n.sid) && validVoter(n.leader)) { /* * Only proceed if the vote comes from a replica in the * voting view for a replica in the voting view. */ switch (n.state) { case LOOKING: // If notification > current, replace and send messages out if (n.electionEpoch > logicalclock.get()) { logicalclock.set(n.electionEpoch); recvset.clear(); if(totalOrderPredicate(n.leader, n.zxid, n.peerEpoch, getInitId(), getInitLastLoggedZxid(), getPeerEpoch())) { updateProposal(n.leader, n.zxid, n.peerEpoch); } else { updateProposal(getInitId(), getInitLastLoggedZxid(), getPeerEpoch()); } sendNotifications(); } else if (n.electionEpoch < logicalclock.get()) { if(LOG.isDebugEnabled()){ LOG.debug("Notification election epoch is smaller than logicalclock. n.electionEpoch = 0x" + Long.toHexString(n.electionEpoch) + ", logicalclock=0x" + Long.toHexString(logicalclock.get())); } break; } else if (totalOrderPredicate(n.leader, n.zxid, n.peerEpoch, proposedLeader, proposedZxid, proposedEpoch)) { updateProposal(n.leader, n.zxid, n.peerEpoch); sendNotifications(); } if(LOG.isDebugEnabled()){ LOG.debug("Adding vote: from=" + n.sid + ", proposed leader=" + n.leader + ", proposed zxid=0x" + Long.toHexString(n.zxid) + ", proposed election epoch=0x" + Long.toHexString(n.electionEpoch)); } recvset.put(n.sid, new Vote(n.leader, n.zxid, n.electionEpoch, n.peerEpoch)); if (termPredicate(recvset, new Vote(proposedLeader, proposedZxid, logicalclock.get(), proposedEpoch))) { // Verify if there is any change in the proposed leader while((n = recvqueue.poll(finalizeWait, TimeUnit.MILLISECONDS)) != null){ if(totalOrderPredicate(n.leader, n.zxid, n.peerEpoch, proposedLeader, proposedZxid, proposedEpoch)){ recvqueue.put(n); break; } } /* * This predicate is true once we don't read any new * relevant message from the reception queue */ if (n == null) { self.setPeerState((proposedLeader == self.getId()) ? ServerState.LEADING: learningState()); Vote endVote = new Vote(proposedLeader, proposedZxid, logicalclock.get(), proposedEpoch); leaveInstance(endVote); return endVote; } } break; case OBSERVING: LOG.debug("Notification from observer: " + n.sid); break; case FOLLOWING: case LEADING: /* * Consider all notifications from the same epoch * together. */ if(n.electionEpoch == logicalclock.get()){ recvset.put(n.sid, new Vote(n.leader, n.zxid, n.electionEpoch, n.peerEpoch)); if(ooePredicate(recvset, outofelection, n)) { self.setPeerState((n.leader == self.getId()) ? ServerState.LEADING: learningState()); Vote endVote = new Vote(n.leader, n.zxid, n.electionEpoch, n.peerEpoch); leaveInstance(endVote); return endVote; } } /* * Before joining an established ensemble, verify * a majority is following the same leader. */ outofelection.put(n.sid, new Vote(n.version, n.leader, n.zxid, n.electionEpoch, n.peerEpoch, n.state)); if(ooePredicate(outofelection, outofelection, n)) { synchronized(this){ logicalclock.set(n.electionEpoch); self.setPeerState((n.leader == self.getId()) ? ServerState.LEADING: learningState()); } Vote endVote = new Vote(n.leader, n.zxid, n.electionEpoch, n.peerEpoch); leaveInstance(endVote); return endVote; } break; default: LOG.warn("Notification state unrecognized: {} (n.state), {} (n.sid)", n.state, n.sid); break; } } else { if (!validVoter(n.leader)) { LOG.warn("Ignoring notification for non-cluster member sid {} from sid {}", n.leader, n.sid); } if (!validVoter(n.sid)) { LOG.warn("Ignoring notification for sid {} from non-quorum member sid {}", n.leader, n.sid); } } } return null; } finally { try { if(self.jmxLeaderElectionBean != null){ MBeanRegistry.getInstance().unregister( self.jmxLeaderElectionBean); } } catch (Exception e) { LOG.warn("Failed to unregister with JMX", e); } self.jmxLeaderElectionBean = null; LOG.debug("Number of connection processing threads: {}", manager.getConnectionThreadCount()); } }选举过程: ...

伪分布式单机配置阐明： 服务器名称与地址：集群信息（服务器编号，服务器地址，LF 通信端口，选举端口） 这个配置项的书写格局比拟非凡，规定如下：server.N=YYY:A:B 其中， N 示意服务器编号， YYY 示意服务器的 IP 地址， A 为 LF 通信端口，示意该服务器与集群中的 leader 替换的信息的端口。 B 为选举端口，示意选举新 leader 时服务器间互相通信的端口（当 leader 挂掉时，其余服务器会互相通信，抉择出新的 leader） 一般来说，集群中每个服务器的 A 端口都是一样，每个服务器的 B 端口也是一样。 上面是一个集群的例子： server.0=233.34.9.144:2008:6008 server.1=233.34.9.145:2008:6008 server.2=233.34.9.146:2008:6008 server.3=233.34.9.147:2008:6008 然而当所采纳的为伪集群时，IP 地址都一样，只能是 A 端口和 B 端口不一样。 上面是一个伪集群的例子： server.0=127.0.0.1:2008:6008 server.1=127.0.0.1:2007:6007 server.2=127.0.0.1:2006:6006 server.3=127.0.0.1:2005:6005 initLimit 是 Zookeeper 用它来限定集群中的 Zookeeper 服务器连贯到 Leader 的时限。 syncLimit 限度了 follower 服务器与 leader 服务器之间申请和应答之间的时限。 配置步骤2.1 复制 3 个 ZooKeeper zookeeper-3.4.9.tar.gz 解压后拷贝到/myzookeeper 目录下并从新名为 zk01，再复制 zk01 造成 zk02、zk03，共计 3 份 ...

一.源码仓库:zookeeper基于分支3.4.14分支在windows系统启动流程进行剖析。 二.流程剖析:源码入口通过zkServer.cmd可执行文件内容能够看出zookeeper的服务端是通过org.apache.zookeeper.server.quorum.QuorumPeerMain这个类的main作为入口来启动服务端程序的.main办法传入的是咱们zoo.cfg文件的地址,而后通过解析zoo.cfg文件,将key,value的配置信息转换成QuorumPeerConfig的对象,转换细节能够看QuorumPeerConfig.parse办法,其中转换后的外围配置参数有:参数名参数形容dataLogDir事务日志存储门路dataDir快照存储门路electionType选举算法,目前只反对3-疾速选举算法myid以后服务idtickTime工夫单位initLimit syncLimit事务存储门路minSessionTimeout最小会话超时工夫maxSessionTimeout最大会话超时工夫peerType角色类型-OBSERVER,PARTICIPANTclientPort客户端连贯端口clientPortAddress客户端连贯HostsnapRetainCount快照保留个数,最小为3purgeInterval快照革除距离server.sidhostName:port(通信端口):electionPort(选举端口):peerTypemaxClientCnxns最大客户端连接数拿到解析后的参数后,能够通过是否配置了server.id参数来决定是否集群启动还是单机启动,单机启动运行通过ZooKeeperServerMain#main办法启动,集群启动则还是在QuorumPeerMain#runFromConfig办法进行解决的,这里咱们就间接解说集群模式,因为集群模式比单机模式多了集群间的通信相干的解决,如Leader选举,数据同步,申请转发等. public void runFromConfig(QuorumPeerConfig config) throws IOException { try { ManagedUtil.registerLog4jMBeans(); } catch (JMException e) { LOG.warn("Unable to register log4j JMX control", e); } LOG.info("Starting quorum peer"); try { ServerCnxnFactory cnxnFactory = ServerCnxnFactory.createFactory(); cnxnFactory.configure(config.getClientPortAddress(), config.getMaxClientCnxns()); quorumPeer = getQuorumPeer(); quorumPeer.setQuorumPeers(config.getServers()); quorumPeer.setTxnFactory(new FileTxnSnapLog( new File(config.getDataLogDir()), new File(config.getDataDir()))); quorumPeer.setElectionType(config.getElectionAlg()); quorumPeer.setMyid(config.getServerId()); quorumPeer.setTickTime(config.getTickTime()); quorumPeer.setInitLimit(config.getInitLimit()); quorumPeer.setSyncLimit(config.getSyncLimit()); quorumPeer.setQuorumListenOnAllIPs(config.getQuorumListenOnAllIPs()); quorumPeer.setCnxnFactory(cnxnFactory); quorumPeer.setQuorumVerifier(config.getQuorumVerifier()); quorumPeer.setClientPortAddress(config.getClientPortAddress()); quorumPeer.setMinSessionTimeout(config.getMinSessionTimeout()); quorumPeer.setMaxSessionTimeout(config.getMaxSessionTimeout()); quorumPeer.setZKDatabase(new ZKDatabase(quorumPeer.getTxnFactory())); quorumPeer.setLearnerType(config.getPeerType()); quorumPeer.setSyncEnabled(config.getSyncEnabled()); // sets quorum sasl authentication configurations quorumPeer.setQuorumSaslEnabled(config.quorumEnableSasl); if(quorumPeer.isQuorumSaslAuthEnabled()){ quorumPeer.setQuorumServerSaslRequired(config.quorumServerRequireSasl); quorumPeer.setQuorumLearnerSaslRequired(config.quorumLearnerRequireSasl); quorumPeer.setQuorumServicePrincipal(config.quorumServicePrincipal); quorumPeer.setQuorumServerLoginContext(config.quorumServerLoginContext); quorumPeer.setQuorumLearnerLoginContext(config.quorumLearnerLoginContext); } quorumPeer.setQuorumCnxnThreadsSize(config.quorumCnxnThreadsSize); quorumPeer.initialize(); quorumPeer.start(); quorumPeer.join(); } catch (InterruptedException e) { // warn, but generally this is ok LOG.warn("Quorum Peer interrupted", e); } }能够从代码片段中能够看出,新创建出了一个QuorumPeer对象,其实这就是OOP思维,以后实例代表着集群的一个节点,而后将QuorumPeerConfig从新设置给QuorumPeer对象,在这里呈现几个新的类： ...

本系列纲要大抵为: 1.服务端:选举过程（zab协定）发现阶段同步阶段播送阶段申请解决链路2.客户端:申请发送过程客户端监听机制

ZooKeeper可视化工具+状态实时监控下载地址：http://www.redisant.cn/za能够保留多个连贯，服务器信息在右侧疾速查看仪表盘性能，提供服务器实时状态数据对节点数据的增删改查，反对多种搜寻，正则、大小写、整词匹配反对多种数据格式，包含JSON，Message Pack、XML、HEX新建节点，能够设置ACL

大家好，我是冰河~~ 最近，有很多小伙伴让我更新一些Zookeeper的文章，正好也趁着清明假期把之前本人工作过程当中总结的Zookeeper知识点梳理了一番，打算写一个【精通Zookeeper系列】，心愿可能帮忙小伙伴们更好的了解和把握Zookeeper。 明天是【精通Zookeeper系列】的开篇，咱们先来简略的介绍下如何内容。 为何要学Zookeeper？好了，咱们直入主题吧，很多小伙伴可能都会问一个问题：为什么要学习Zookeeper呢？ Zookeeper是一个开源的分布式协同服务零碎，在业界的利用十分宽泛，尽管最近几年有Consul、etcd、Nacos等分布式协同零碎问世，然而Zookeeper仍然是最支流的分布式协同服务零碎。Zookeeper也是一个设计的十分胜利的软件系统，从Zookeeper最后依照料想的需要场景进行设计实现到当初，Zookeeper的对外API，在基本上没有扭转的前提下，在越来越宽泛的畛域失去利用，通过学习Zookeeper，小伙伴们能够相熟Zookeeper中胜利的设计和研发思路，晋升本人的零碎设计程度。另外，Zookeeper是应用Java语言开发的，通过学习Zookeeper，小伙伴们还能够积攒应用Java研发零碎级软件的实战经验。 另外，Zookeeper的利用场景非常广发，例如：大数据畛域中，Hadoop集群、Storm集群、Kafka集群、Spark集群、Flink集群、Flume集群等支流的大数据分析平台，在集群化的场景中，举荐应用Zookeeper作为集群环境中的分布式协同服务。在分布式和微服务畛域中，Dubbo、SpringCloud、分布式锁、分布式序列号服务、RPC服务等框架和技术，也可能通过Zookeeper进行实现。 很多大厂在面试过程中，也要求深刻把握Zookeeper技术，所以，学好Zookeeper还是很有必要的。 Zookeeper很难吗？说实话，大多数技术人员，都能够很快的上手Zookeeper，然而大部分都是局限于基于现有的Zookeeper协同服务示例做一些简略的批改和定制。如果要具备为本人的业务场景设计Zookeeper协同服务的能力，就须要深刻理解Zookeeper的外部工作原理，还要做大量的协同服务设计的积攒和总结。了解Zookeeper的外部工作原理，须要学习大量的计算机理论知识，这些理论知识包含：分布式系统、数据库系统和操作系统。找到和学习这些知识点，须要消耗大量的工夫。 在行将要连载的【精通Zookeeper系列】的文章中，会专门介绍学习Zookeeper须要学习的计算机理论知识，帮忙小伙伴们迅速建设起对Zookeeper外部原理和机制的了解。 学习Zookeeper播种大不大？在【精通Zookeeper系列】中，咱们首先介绍Zookeeper的基础知识，而后就是高阶的原理和源代码分析等内容。在介绍基础知识的时候，会联合代码多介绍些实战性的案例，也会介绍一些分布式系统的基本概念。高阶的内容次要介绍Zookeeper的外部原理和相干的源码实现。到时也会对Zookeeper和etcd进行简略的比照，以帮忙小伙伴们更好的了解和把握Zookeeper。 除了把握Zookeeper自身的技术之外，冰河也要让你学到以下常识： 如何设计一个本地数据节点分布式环境中节点之间如何通信如何从0到1设计一个RPC子系统如何应用数据一致性协定保证数据的高可用如何在数据一致性和零碎性能之间做取舍以上这些设计理念根本每个分布式系统都会波及到，把握这些分布式系统可能让你更好的了解分布式系统的架构设计，也能够将这些设计理念利用到本人设计和研发的零碎当中。 进大厂Zookeeper要学到什么水平？对于进大厂Zookeeper要学到什么水平？这个问题小伙伴们应该还是比较关心的，简略点说，进大厂，你只是会简略的应用Zookeeper还不行，你要了解Zookeeper的工作原理和底层源码机制。在之前的文章中，我就说过：大厂对于技术的要求高，不是他们成心刁难人。而是大厂的用户量级很大，业务体量很高，如果你不深刻理解原理和源码机制，一旦线上生产环境因为高并发、大流量等场景呈现一些偶尔的零碎问题，你可能就会半天定位不到问题，甚至会一脸懵逼的看着问题重复呈现。所以，要想进大厂，就要深刻理解Zookeeper的原理和源码机制。 精通Zookeeper系列更新哪些内容？说了这么多，那【精通Zookeeper系列】到底要更新哪些内容呢？ 总体上说，这个专题要更新六大部分的内容，如下所示。 在【精通Zookeeper系列】中，我次要依照图示的分类进行介绍，当然，每一部分都可能会写一到多篇文章。 好了，明天就到这儿吧，我是冰河，大家有啥问题能够在下方留言，一起交换技术，一起进阶，一起进大厂~~

参考文章 zkServer.sh start启动失常 zkServer.sh status启动异样 解决办法 呃...2181端口被占用还能启动胜利?【已解决】zookeeper显示Error contacting service. It is probably not running等问题 扯, server.X中的X能够是从0开始的(尽管如同网上所有文章都是从1开始, 连官网也是).人工智能 装置zookeeper时候，能够查看过程启动，然而状态显示报错 Error contacting service. It is probably not runningCentOS下ZooKeeper的装置教程（单机模式） 同参考文章2bin/zkServer.sh status fails when jmx_prometheus_javaagent added as agent #392zk: 3.4.9 (3节点) kubernetes: 1.17.2 容器镜像应用 CentOS7 + zk安装包自行封装. 问题形容zk的3个节点全副启动, 集群也建起来了, 失常对外提供服务. 然而执行zkServer.sh status查问节点状态异样, 如下 $ ./bin/zkServer.sh status ZooKeeper JMX enabled by default Using config: /usr/zookeeper-3.4.9/bin/../conf/zoo.cfg Error contacting service. It is probably not running应用jps能够看到zk过程 $ jps26 QuorumPeerMain120300 Jps排查过程依照参考文章1中所说, 批改bin/zkServer.sh, 查看status子命令的具体过程. ...

版本抉择CentOS7.6openjdk-11.0.2zookeeper-3.5.7 下载地址https://download.java.net/jav...https://archive.apache.org/di... 部署细节配置java环境变量：在/etc/profile.d/门路下新建my_env.sh文件 cd /etc/profile.d/vim my_env.sh#JAVA_HOMEexport JAVA_HOME=/opt/module/jdk1.8.0_221/export PATH=$PATH:$JAVA_HOME/binsource /etc/profile#验证环境javac解压、配置zookeeper：tar -zxvf apache-zookeeper-3.5.7-binconf目录下有个zoo_sample.cfg文件，就是配置文件。拷贝并批改为zoo.cfgcp zoo_sample.cfg zoo.cfg配置文件简析： #服务端和客户端的心跳超时工夫tickTime=2000#初始化的超时工夫initLimit=10#节点间的超时工夫syncLimit=5#这个目录须要扭转，不要将数据存在tmp下dataDir=/tmp/zookeeper#zookeeper的端口号clientPort=2181批改dataDir门路：/usr/local/apache-zookeeper-3.5.7-bin/conf/zkData并在zkData中创立myid文件，文件中输出一个数字。必须是集群中惟一。作为以后zookeeper的标识。 启动前查看防火墙状态：能够间接敞开，或者开启通信须要的端口号。systemctl status firewalld 启动后查看状态，发现有报错： [root@xaw4mwfdnnrs7sef-0815135 bin]# ./zkServer.sh startZooKeeper JMX enabled by defaultUsing config: /usr/local/apache-zookeeper-3.5.7-bin/bin/../conf/zoo.cfgStarting zookeeper ... STARTED[root@xaw4mwfdnnrs7sef-0815135 bin]# ./zkServer.sh statusZooKeeper JMX enabled by defaultUsing config: /usr/local/apache-zookeeper-3.5.7-bin/bin/../conf/zoo.cfgClient port found: 2181. Client address: localhost.Error contacting service. It is probably not running.这样报错无需惊恐。把所有节点的zookeeper都启动当前，再查看status。失常的话，应该有了：mode：leader/follower的显示。阐明集群启动失常。如果还是报错的话，能够到同级目录下logs文件夹下查看报错。 常用命令启动：bin/zkServer.sh start查看状态：bin/zkServer.sh status进行：bin/zkServer.sh stop

目前大多数我的项目都在往分布式上倒退，一旦零碎采纳分布式系统，便会引入更多简单场景和解决方案。比方，当你在零碎中应用了Elasticsearch、ZooKeeper集群时，你是否理解过集群的“脑裂”景象？又是否晓得它们是如何解决脑裂问题的？ 如果这些都还未理解，那么你对分布式的理解过于表象了，举荐你读一读这篇文章。 上面就以zookeeper为例，带大家理解一下分布式系统中的脑裂景象及如何解决。 什么是脑裂？在Elasticsearch、ZooKeeper这些集群环境中，有一个独特的特点，就是它们有一个“大脑”。比方，Elasticsearch集群中有Master节点，ZooKeeper集群中有Leader节点。 集群中的Master或Leader节点往往是通过选举产生的。在网络失常的状况下，能够顺利的选举出Leader（后续以Zookeeper命名为例）。但当两个机房之间的网络通信呈现故障时，选举机制就有可能在不同的网络分区中选出两个Leader。当网络复原时，这两个Leader该如何解决数据同步？又该听谁的？这也就呈现了“脑裂”景象。 艰深的讲，脑裂(split-brain)就是“大脑决裂”，原本一个“大脑”被拆分成两个或多个。试想，如果一个人有多个大脑，且互相独立，就会导致人体“载歌载舞”，“不听使唤”。 理解了脑裂的基本概念，上面就以zookeeper集群的场景为例，来剖析一下脑裂的产生。 zookeeper集群中的脑裂咱们在应用zookeeper时，很少遇到脑裂景象，是因为zookeeper曾经采取了相应的措施来缩小或防止脑裂的产生，这个前面会讲到Zookeeper的具体解决方案。当初呢，先假如zookeeper没有采取这些避免脑裂的措施。在这种状况下，看看脑裂问题是如何产生的。 现有6台zkServer服务组成了一个集群，部署在2个机房： 失常状况下，该集群只有会有个Leader，当Leader宕掉时，其余5个服务会从新选举出一个新的Leader。 如果机房1和机房2之间的网络呈现故障，临时不思考Zookeeper的过半机制，那么就会呈现下图的状况： 也就是说机房2的三台服务检测到没有Leader了，于是开始从新选举，选举出一个新Leader来。本来一个集群，被分成了两个集群，同时呈现了两个“大脑”，这就是所谓的“脑裂”景象。 因为本来的一个集群变成了两个，都对外提供服务。一段时间之后，两个集群之间的数据可能会变得不统一了。当网络复原时，就面临着谁当Leader，数据怎么合并，数据抵触怎么解决等问题。 当然，下面的过程只是咱们假如Zookeeper不做任何预防脑裂措施时会呈现的问题。那么，针对脑裂问题，Zookeeper是如何进行解决的呢？ Zookeeper的过半准则避免脑裂的措施有多种，Zookeeper默认采纳的是“过半准则”。所谓的过半准则就是：在Leader选举的过程中，如果某台zkServer取得了超过半数的选票，则此zkServer就能够成为Leader了。 底层源码实现如下： public class QuorumMaj implements QuorumVerifier { int half; // QuorumMaj构造方法。 // 其中，参数n示意集群中zkServer的个数，不包含观察者节点 public QuorumMaj(int n){ this.half = n/2; } // 验证是否合乎过半机制 public boolean containsQuorum(Set<Long> set){ // half是在构造方法里赋值的 // set.size()示意某台zkServer取得的票数 return (set.size() > half); }}上述代码在构建QuorumMaj对象时，传入了集群中无效节点的个数；containsQuorum办法提供了判断某台zkServer取得的票数是否超过半数，其中set.size示意某台zkServer取得的票数。 上述代码外围点两个：第一，如何计算半数；第二，投票属于半数的比拟。 以上图6台服务器为例来进行阐明：half = 6 / 2 = 3，也就是说选举的时候，要成为Leader至多要有4台机器投票才可能选举胜利。那么，针对下面2个机房断网的状况，因为机房1和机房2都只有3台服务器，根本无法选举出Leader。这种状况下整个集群将没有Leader。 在没有Leader的状况下，会导致Zookeeper无奈对外提供服务，所以在设计的时候，咱们在集群搭建的时候，要防止这种状况的呈现。 如果两个机房的部署申请部署3：3这种情况，而是3：2，也就是机房1中三台服务器，机房2中两台服务器： 在上述情况下，先计算half = 5 / 2 = 2，也就是须要大于2台机器能力选举出Leader。那么此时，对于机房1能够失常选举出Leader。对于机房2来说，因为只有2台服务器，则无奈选出Leader。此时整个集群只有一个Leader。 ...

前言个别工作中罕用的分布式锁，就是基于 Redis 和 ZooKeeper，后面曾经介绍完了 Redisson 锁相干的源码，上面一起看看基于 ZooKeeper 的锁。也就是 Curator 这个框架。 Curator 的锁也分为很多种，本文剖析共享可重入锁。 思考到如果文章篇幅较长，不太适宜浏览，所以对文章做了适当的拆分。环境配置 本机三个节点 版本：3.7.0零碎：macOS装置形式：brew install zookeeperCurator Maven 依赖版本：5.1.0 <dependency> <groupId>org.apache.curator</groupId> <artifactId>curator-recipes</artifactId> <version>5.1.0</version></dependency>加锁示例 详细信息可参考官网文档。 加锁前 在加锁之前，ZooKeeper 仅有一个节点 /zookeeper。 加锁中在 /locks/lock_01 门路上加锁。 加锁之后： 创立了一个 /locks/lock_01 的长久节点，节点下有一个子节点 _c_cc4fc045-5a1e-4378-b3c7-8a8d3fb9a37c-lock-0000000000节点 /locks/lock_01/_c_cc4fc045-5a1e-4378-b3c7-8a8d3fb9a37c-lock-0000000000 是长期节点节点 /locks/lock_01/_c_cc4fc045-5a1e-4378-b3c7-8a8d3fb9a37c-lock-0000000000 的数据是机器 IP 地址加锁源码PS：上面代码截图中的代码格调就是 Curator 源码的代码格调。入口InterProcessMutex#internalLock 开始先从 threadData 中获取以后线程，这里必定是没有的，所以进入 attemptLock 办法。 本办法中还蕴含了锁重入的逻辑，前面也会介绍。 加锁LockInternals#attemptLock 外围局部就是这两行： createsTheLock 创立长期程序节点internalLockLoop 判断是否创立胜利创立长期程序节点StandardLockInternalsDriver#createsTheLock 能够看出节点的 mode 是 CreateMode.EPHEMERAL_SEQUENTIAL，示意这是一个长期程序节点！ 进入 CreateBuilderImpl#forPath(java.lang.String, byte[]) client.getDefaultData() 就是本机 IP 地址。 ...

之前的文章Zookeeper根底原理&利用场景详解中将Zookeeper的基本原理及其利用场景做了一个具体的介绍，尽管介绍了其底层的存储原理、如何应用Zookeeper来实现分布式锁。然而我认为这样也仅仅只是理解了Zookeeper的一点皮毛而已。所以这篇文章就给大家具体聊聊Zookeeper的外围底层原理。不太熟悉Zookeeper的能够回过头去看看。 ZNode这个应该算是Zookeeper中的根底，数据存储的最小单元。在Zookeeper中，相似文件系统的存储构造，被Zookeeper形象成了树，树中的每一个节点（Node）被叫做ZNode。ZNode中保护了一个数据结构，用于记录ZNode中数据更改的版本号以及ACL（Access Control List）的变更。 有了这些数据的版本号以及其更新的Timestamp，Zookeeper就能够验证客户端申请的缓存是否非法，并协调更新。 而且，当Zookeeper的客户端执行更新或者删除操作时，都必须要带上要批改的对应数据的版本号。如果Zookeeper检测到对应的版本号不存在，则不会执行这次更新。如果非法，在ZNode中数据更新之后，其对应的版本号也会一起更新。 这套版本号的逻辑，其实很多框架都在用，例如RocketMQ中，Broker向NameServer注册的时候，也会带上这样一个版本号，叫DateVersion。接下来咱们来具体看一下这个保护版本号相干数据的数据结构，它叫Stat Structure，其字段有： 字段释义czxid创立该节点的zxidmzxid最初一次批改该节点的zxidpzxid最初一次批改该节点的子节点的zxidctime从以后epoch开始到该节点被创立，所距离的毫秒mtime从以后epoch开始到该节点最初一次被编辑，所距离的毫秒version以后节点的改变次数（也就是版本号）cversion以后节点的子节点的改变次数aversion以后节点的ACL改变次数ephemeralOwner以后长期节点owner的SessionID（如果不是长期节点则为空）dataLength以后节点的数据的长度numChildren以后节点的子节点数量举个例子，通过stat命令，咱们能够查看某个ZNode中Stat Structure具体的值。 对于这里的epoch、zxid是Zookeeper集群相干的货色，前面会具体的对其进行介绍。 ACLACL（Access Control List）用于管制ZNode的相干权限，其权限管制和Linux中的相似。Linux中权限品种分为了三种，别离是读、写、执行，别离对应的字母是r、w、x。其权限粒度也分为三种，别离是拥有者权限、群组权限、其余组权限，举个例子： drwxr-xr-x 3 USERNAME GROUP 1.0K 3 15 18:19 dir_name什么叫粒度？粒度是对权限所作用的对象的分类，把下面三种粒度换个说法形容就是对用户（Owner）、用户所属的组（Group)、其余组（Other）的权限划分，这应该算是一种权限管制的规范了，典型的三段式。 Zookeeper中尽管也是三段式，然而两者对粒度的划分存在区别。Zookeeper中的三段式为Scheme、ID、Permissions，含意别离为权限机制、容许拜访的用户和具体的权限。 Scheme代表了一种权限模式，有以下5种类型： world 在此中Scheme下，ID只能是anyone，代表所有人都能够拜访auth 代表曾经通过了认证的用户digest 应用用户名+明码来做校验。ip 只容许某些特定的IP拜访ZNodeX509 通过客户端的证书进行认证同时权限品种也有五种： CREATE 创立节点READ 获取节点或列出其子节点WRITE 能设置节点的数据DELETE 可能删除子节点ADMIN 可能设置权限同Linux中一样，这个权限也有缩写，举个例子： getAcl办法用户查看对应的ZNode的权限，如图，咱们能够输入的后果呈三段式。别离是： scheme 应用了worldid 值为anyone，代表所有用户都有权限permissions 其具体的权限为cdrwa，别离是CREATE、DELETE、READ、WRITE和ADMIN的缩写Session机制理解了Zookeeper的Version机制，咱们能够持续摸索Zookeeper的Session机制了。 咱们晓得，Zookeeper中有4种类型的节点，别离是长久节点、长久程序节点、长期节点和长期程序节点。 在之前的文章咱们聊到过，客户端如果创立了长期节点，并在之后断开了连贯，那么所有的长期节点就都会被删除。实际上断开连接的谈话不是很准确，应该是说客户端建设连贯时的Session过期之后，其创立的所有长期节点就会被全副删除。 那么Zookeeper是怎么晓得哪些长期节点是由以后客户端创立的呢？ 答案是Stat Structure中的ephemeralOwner（长期节点的Owner）字段下面说过，如果以后是长期程序节点，那么ephemeralOwner则存储了创立该节点的Owner的SessionID，有了SessionID，天然就能和对应的客户端匹配上，当Session生效之后，能力将该客户端创立的所有长期节点全副删除。 对应的服务在创立连贯的时候，必须要提供一个带有所有服务器、端口的字符串，单个之间逗号相隔，举个例子。 127.0.0.1:3000:2181,127.0.0.1:2888,127.0.0.1:3888Zookeeper的客户端收到这个字符串之后，会从中随机选一个服务、端口来建设连贯。如果连贯在之后断开，客户端会从字符串中抉择下一个服务器，持续尝试连贯，直到连贯胜利。 除了这种最根本的IP+端口，在Zookeeper的3.2.0之后的版本中还反对连贯串中带上门路，举个例子。 127.0.0.1:3000:2181,127.0.0.1:2888,127.0.0.1:3888/app/a这样一来，/app/a就会被当成以后服务的根目录，在其下创立的所有的节点路经都会带上前缀/app/a。举个例子，我创立了一个节点/node_name，那其残缺的门路就会为/app/a/node_name。这个个性特地实用于多租户的环境，对于每个租户来说，都认为本人是最顶层的根目录/。 当Zookeeper的客户端和服务器都建设了连贯之后，客户端会拿到一个64位的SessionID和明码。这个明码是干什么用的呢？咱们晓得Zookeeper能够部署多个实例，如果客户端断开了连贯又和另外的Zookeeper服务器建设了连贯，那么在建设连贯使就会带上这个明码。该明码是Zookeeper的一种安全措施，所有的Zookeeper节点都能够对其进行验证。这样一来，即便连贯到了其余Zookeeper节点，Session同样无效。 Session过期有两种状况，别离是： 过了指定的生效工夫指定工夫内客户端没有发送心跳对于第一种状况，过期工夫会在Zookeeper客户端建设连贯的时候传给服务器，这个过期工夫的范畴目前只能在2倍tickTime和20倍tickTime之间。 ticktime是Zookeeper服务器的配置项，用于指定客户端向服务器发送心跳的距离，其默认值为tickTime=2000，单位为毫秒而这套Session的过期逻辑由Zookeeper的服务器保护，一旦Session过期，服务器会立刻删除由Client创立的所有长期节点，而后告诉所有正在监听这些节点的客户端相干变更。 对于第二种状况，Zookeeper中的心跳是通过PING申请来实现的，每隔一段时间，客户端都会发送PING申请到服务器，这就是心跳的实质。心跳使服务器感知到客户端还活着，同样的让客户端也感知到和服务器的连贯依然是无效的，这个距离就是tickTime，默认为2秒。 Watch机制理解完ZNode和Session，咱们终于能够来持续下一个要害性能Watch了，在下面的内容中也不止一次的提到监听（Watch）这个词。首先用一句话来概括其作用 给某个节点注册监听器，该节点一旦产生变更（例如更新或者删除），监听者就会收到一个Watch Event和ZNode中有多种类型一样，Watch也有多种类型，别离是一次性Watch和永久性Watch。 一次性Watch 在被触发之后，该Watch就会移除永久性Watch 在被触发之后，依然保留，能够持续监听ZNode上的变更，是Zookeeper 3.6.0版本新增的性能一次性的Watch能够在调用getData()、getChildren()和exists()等办法时在参数中进行设置，永久性的Watch则须要调用addWatch()来实现。 并且一次性的Watch会存在问题，因为在Watch触发的事件达到客户端、再到客户端设立新的Watch，是有一个工夫距离的。而如果在这个工夫距离中产生的变更，客户端则无奈感知。 ...

本文章转自：乐字节 文章次要解说：ZooKeeper会话 获取ZooKeeper视频教程及源码文档能够关注公众号《乐字节》 发送：999 一、客户端会话的机密会话，即 session，这个词语或者说概念很多中央都有用到，在 ZK 中会话指的是两个不同的机器建设了网络连接后，就能够说他们之间创立了一个会话。ZK 的会话是有超时的概念的，当会话超时后，会由服务端被动敞开，当然客户端也能够被动申请服务端想要敞开会话。你可能会问，为什么要搞这个麻烦，间接两边连上始终用不就好了吗？有了会话这个概念就是为了避免，在建设连贯后，有些客户端不常应用，早点敞开连贯能够节俭资源。 1.1 鸡太美的一天我发现我良久没有 cue 鸡太美了，这次就让他再 C 位出道一次吧。 咱们的鸡太美每天起床后，日常发微博、直播、跳舞、打篮球，很多事务都须要去办事处办理。 所以第一件事件就是去办事处找马果果（当初就假如马果果一个办事处）申请应用办事处（建设连贯，创立会话） 而马果果会为鸡太美创立一个 ID，就是会话 ID，这个 ID （我这里假如是 19980802） 和鸡太美会进行绑定，而鸡太美在申请的同时还须要通知马果果本人最长的超时工夫是多久，我这里假如是 6000 毫秒。 而马果果这边会记录下来： 在马果果倒闭的时候本人自身也有一个会话的查看距离，就是配置在 zoo.cfg 中的 tickTime 选项，我这里假如是 3000 毫秒。马果果在倒闭的时候会计算出一个时间轴，这个时间轴的距离是固定的，并且不会扭转。 而后马果果会通过鸡太美的 6000 以及以后的工夫戳联合时间轴，计算出一个鸡太美会话超时工夫点 而后会记录下来： 记录完，就算鸡太美会话创立胜利了。 而马果果这边会遵循这个时间轴的节点定期对会话进行查看，假如当初的工夫进行到鸡太美的工夫点了 马果果会把在这个工夫点的会话全副取出（记得咱们下面说过，能够是多个吗？） 而后会依据 ID 信息找到对应的村民，一个个告诉他们会话敞开了。 你可能会问当初因为鸡太美超时工夫是 6000，而马果果超时查看是 3000，正好是整数倍，如果超时工夫不是整数倍呢？要不说咱们的马果果同志好学上进呢，他早就想到啦，所以设计了一个算法，无论村民的超时工夫是怎么样，都会向下取整找到马果果设置的检查点。 假如鸡太美的超工夫是 5900 再比方鸡太美的超时工夫是 6500 所以看到了吧，以马果果的 3000 为例，只有小于 3000 的都依照 0 来算，小于 6000 的依照 3000 来算，小于 9000 的依照 6000 来算，以此类推，所以只有马果果本人的查看工夫距离确定了之后，无论是哪个村民设置了什么样的超时工夫都能被向下取整至最近的对立检查点。这样马果果查看的时候就不会有太大的累赘，能够对立对村民的超时工夫进行查看。 ...

作者：雨中散步撒哈拉 起源：https://liudongdong.top 公众号：雨中散步撒哈拉 备注：欢送关注公众号，学习技术，一起成长！ 文末福利：上百本电子书，期待你的支付^v^ 环境阐明: 服务器为centos7集群zk为zookeeper-3.4.10.tar.gz版本jdk为1.8一、创立我的项目1. 增加依赖包，pom文件如下<dependencies><dependency>    <groupId>junit</groupId>    <artifactId>junit</artifactId>    <version>RELEASE</version></dependency><dependency>    <groupId>org.apache.logging.log4j</groupId>    <artifactId>log4j-core</artifactId>    <version>2.8.2</version></dependency><!--https://mvnrepository.com/artifact/org.apache.zookeeper/zookeeper --><dependency>    <groupId>org.apache.zookeeper</groupId>    <artifactId>zookeeper</artifactId>    <version>3.4.10</version></dependency></dependencies>2. 配置日志文件资源文件创建日志配置文件log4j.properties log4j.rootLogger=INFO, stdout log4j.appender.stdout=org.apache.log4j.ConsoleAppender log4j.appender.stdout.layout=org.apache.log4j.PatternLayout log4j.appender.stdout.layout.ConversionPattern=%d %p [%c] - %m%n log4j.appender.logfile=org.apache.log4j.FileAppender log4j.appender.logfile.File=target/spring.loglog4j.appender.logfile.layout=org.apache.log4j.PatternLayout log4j.appender.logfile.layout.ConversionPattern=%d %p [%c] - %m%n二、代码实现zk命令0. 创立连贯连贯集群ip和对外端口2181，集群映射，已在windows做了配置 hosts文件内容： 代码实现连贯: private static final String IPS = "master:2181,slave1:2181,slave2:2181";private static final int SESSIONTIMEOUT = 200;private ZooKeeper zkClient = null;@Testpublic void contectTest() throws Exception{    zkClient = new ZooKeeper(IPS, SESSIONTIMEOUT, new Watcher() {        @Override        public void process(WatchedEvent event) {        }    });    System.out.println("==================");    System.out.println(zkClient.getState());    System.out.println("==================");}运行打印后果 image.png 2. 创立节点创立/idea节点，类型为长期节点 private static final String IPS = "master:2181,slave1:2181,slave2:2181";private static final int SESSIONTIMEOUT = 200;private ZooKeeper zkClient = null;@Beforepublic void contectTest() throws Exception{    zkClient = new ZooKeeper(IPS, SESSIONTIMEOUT, new Watcher() {        @Override        public void process(WatchedEvent event) {        }    });    System.out.println("==================");    System.out.println(zkClient.getState());    System.out.println("==================");}@Testpublic void createTest() throws Exception{    String s = zkClient.create("/idea", "helloworld".getBytes(), ZooDefs.Ids.OPEN_ACL_UNSAFE, CreateMode.EPHEMERAL);    System.out.println(s);}打印后果 image.png 3. 监听节点变动监控根节点下的子节点变动 private static final String IPS = "master:2181,slave1:2181,slave2:2181";private static final int SESSIONTIMEOUT = 200;private ZooKeeper zkClient = null;@Beforepublic void contectTest() throws Exception{    zkClient = new ZooKeeper(IPS, SESSIONTIMEOUT, new Watcher() {        @Override        public void process(WatchedEvent event) {            System.out.println(event.getType() + "--" + event.getPath());            try {                zkClient.getChildren("/", true);            } catch (KeeperException e) {                e.printStackTrace();            } catch (InterruptedException e) {                e.printStackTrace();            }        }    });    System.out.println("==================");    System.out.println(zkClient.getState());    System.out.println("==================");}@Testpublic void childrenTest() throws Exception{    List<String> children = zkClient.getChildren("/", true);    for (String ch : children){        System.out.println(ch);    }    Thread.sleep(Long.MAX_VALUE);}在xshell典范增加节点，也能够在代码中模拟增加节点 [zk: localhost:2181(CONNECTED) 0] create -e /java "java"Created /java[zk: localhost:2181(CONNECTED) 1] create -e /python "java"Created /python打印后果 image.png 4. 判断节点是否存在private static final String IPS = "master:2181,slave1:2181,slave2:2181";private static final int SESSIONTIMEOUT = 200;private ZooKeeper zkClient = null;@Beforepublic void contectTest() throws Exception{    zkClient = new ZooKeeper(IPS, SESSIONTIMEOUT, new Watcher() {        @Override        public void process(WatchedEvent event) {        }    });    System.out.println("==================");    System.out.println(zkClient.getState());    System.out.println("==================");}@Testpublic void exTest() throws Exception{    Stat exists = zkClient.exists("/test", false);    System.out.println(exists == null ? "no" : "yes");}打印后果 image.png 5. 测试残缺代码package com.example.demo;import org.apache.zookeeper.*;import org.apache.zookeeper.data.Stat;import org.junit.Before;import org.junit.Test;import java.util.List;public class ZKDemo {    private static final String IPS = "master:2181,slave1:2181,slave2:2181";    private static final int SESSIONTIMEOUT = 200;    private ZooKeeper zkClient = null;    @Before    public void contectTest() throws Exception{        zkClient = new ZooKeeper(IPS, SESSIONTIMEOUT, new Watcher() {            @Override            public void process(WatchedEvent event) {                /*System.out.println(event.getType() + "--" + event.getPath());                try {                    zkClient.getChildren("/", true);                } catch (KeeperException e) {                    e.printStackTrace();                } catch (InterruptedException e) {                    e.printStackTrace();                }*/            }        });        System.out.println("==================");        System.out.println(zkClient.getState());        System.out.println("==================");    }    @Test    public void createTest() throws Exception{        String s = zkClient.create("/idea", "helloworld".getBytes(), ZooDefs.Ids.OPEN_ACL_UNSAFE, CreateMode.EPHEMERAL);        System.out.println(s);    }    @Test    public void childrenTest() throws Exception{        List<String> children = zkClient.getChildren("/", true);        for (String ch : children){            System.out.println(ch);        }        Thread.sleep(Long.MAX_VALUE);    }    @Test    public void exTest() throws Exception{        Stat exists = zkClient.exists("/test", false);        System.out.println(exists == null ? "no" : "yes");    }}文末福利蕴含c、c++、java、python、linux、html、php等上百本电子书！ 获取形式： 搜寻并关注公众号：雨中散步撒哈拉 回复关键词：001

一、参考elasticsearch 学习系列目录——更新ing ZooKeeper Getting Started Guide 二、装置运行2.1 下载解压tar包Apache ZooKeeper™ Releases /Users/yz/work/env/zktar -zvxf apache-zookeeper-3.7.0-bin.tar.gzcd apache-zookeeper-3.7.0-bin2.2 运行zkServer启动之前须要配置文件 zoo.cfg cd /Users/yz/work/env/zk/apache-zookeeper-3.7.0-bincp zoo_sample.cfg zoo.cfg./zkCli.sh start 2.3 运行zkCli

一、节点类型二、构造体三、监听器原理四、选举机制4.1 重要的参数。4.2 选举状态：4.3 服务器启动时的 leader 选举4.4 运行过程中的 leader 选举 作   者： 雨中散步撒哈拉 来   源：https://liudongdong.top 公众号：雨中散步撒哈拉 备   注： 欢送关注公众号，学习技术，一起成长！一、节点类型 image.png 长久（Persistent）：客户端和服务器端断开连接后， 创立的节点不删除 1.1. 长久化目录节点：客户端与Zookeeper断开连接后，该节点仍旧存在 1.2. 长久化程序编号目录节点：客户端与Zookeeper断开连接后， 该节点仍旧存在， 只是Zookeeper给该节点名称进行程序编号短暂（Ephemeral）：客户端和服务器端断开连接后， 创立的节点本人删除 2.1. 长期目录节点：客户端与Zookeeper断开连接后， 该节点被删除 2.2. 长期程序编号目录节点：客户端与Zookeeper断开连接后，该节点被删除，只是Zookeeper给该节点名称进行程序编号。阐明：创立znode时设置程序标识，znode名称后会附加一个值，顺序号是一个枯燥递增的计数器，由父节点保护留神：在分布式系统中，顺序号能够被用于为所有的事件进行全局排序， 这样客户端能够通过顺序号推断事件的程序 二、构造体应用stat命令，查看节点详细信息 image.png cZxid创立节点时的事务IDctime创立节点时的工夫mZxid最初批改节点时的事务IDmtime最初批改节点时的工夫pZxid示意该节点的子节点列表最初一次批改的事务ID，增加子节点或删除子节点就会影响子节点列表，然而批改子节点的数据内容则不影响该ID（留神，只有子节点列表变更了才会变更pzxid，子节点内容变更不会影响pzxid）cversion子节点版本号，子节点每次批改版本号加1dataversion数据版本号，数据每次批改该版本号加1aclversion权限版本号，权限每次批改该版本号加1ephemeralOwner创立该长期节点的会话的sessionID。（*_如果该节点是长久节点，那么这个属性值为0）_*dataLength该节点的数据长度numChildren该节点领有子节点的数量（只统计间接子节点的数量）三、监听器原理首先要有一个main()线程在main线程中创立Zookeeper客户端， 这时就会创立两个线程， 一个负责网络连接通信（ connet）， 一个负责监听（ listener ）。通过connect线程将注册的监听事件发送给Zookeeper。在Zookeeper的注册监听器列表中将注册的监听事件增加到列表中。Zookeeper监听到有数据或门路变动， 就会将这个音讯发送给listener线程。listener线程外部调用了process()办法。 image.png 常见的监听: 监听节点数据的变动 get path [watch]监听子节点增减的变动 ls path [watch]四、选举机制zookeeper 的 leader 选举存在两个阶段，一个是服务器启动时 leader 选举，另一个是运行过程中 leader 服务器宕机。 4.1 重要的参数。服务器 ID(myid)：编号越大在选举算法中权重越大事务 ID(zxid)：值越大阐明数据越新，权重越大逻辑时钟(epoch-logicalclock)：同一轮投票过程中的逻辑时钟值是雷同的，每投完一次值会减少4.2 选举状态：LOOKING: 竞选状态 FOLLOWING: 随从状态，同步 leader 状态，参加投票 OBSERVING: 察看状态，同步 leader 状态，不参加投票 LEADING: 领导者状态4.3 服务器启动时的 leader 选举每个节点启动的时候都 LOOKING 张望状态，接下来就开始进行选举主流程。这里选取三台机器组成的集群为例。第一台服务器 server1启动时，无奈进行 leader 选举，当第二台服务器 server2 启动时，两台机器能够互相通信，进入 leader 选举过程。 ...

    一、集群装置0、环境筹备1、下载好的zk进行解压2、创立数据和日志目录3、批改配置4、散发到集群节点5、别离增加id6、增加环境变量二、集群常用命令2.2.1 启动客户端2.2.2 退出客户端1、 启动zkserver服务2、查看zkServer状态3、进行zkserver2.1服务端server2.2三、配置解读3.1. tickTime=20003.2. initLimit=103.3. syncLimit=53.4. dataDir3.4. dataLogDir3.6. clientPort=21813.7.autopurge.purgeInterval3.8.autopurge.snapRetainCount    [toc] 一、集群装置0、环境筹备环境环境阐明备注server1192.168.158.128masterserver2192.168.158.129slave1server3192.168.158.130slave2jdkjdk1.8 zookeeperzookeeper-3.4.10.tar.gz 1、下载好的zk进行解压解压文件，进行寄存到指定目录！ tar -zxf zookeeper-3.4.10.tar.gz -C /root/programs/2、创立数据和日志目录数据目录和日志目录，创立的目标是zk运行过程中所产生的数据。 mkdir zkDatamkdir zkLog 3、批改配置进入zk下的conf配置文件目录 ]# cd conf/]# cp zoo_sample.cfg zoo.cfg]# vim zoo.cfg # The number of milliseconds of each ticktickTime=2000# The number of ticks that the initial # synchronization phase can takeinitLimit=10# The number of ticks that can pass between # sending a request and getting an acknowledgementsyncLimit=5# the directory where the snapshot is stored.# do not use /tmp for storage, /tmp here is just # example sakes.dataDir=/root/programs/zookeeper-3.4.10/zkDatadataLogDir=/root/programs/zookeeper-3.4.10/zkLog# the port at which the clients will connectclientPort=2181# the maximum number of client connections.# increase this if you need to handle more clients#maxClientCnxns=60## Be sure to read the maintenance section of the # administrator guide before turning on autopurge.## http://zookeeper.apache.org/doc/current/zookeeperAdmin.html#sc_maintenance## The number of snapshots to retain in dataDirautopurge.snapRetainCount=3# Purge task interval in hours# Set to "0" to disable auto purge featureautopurge.purgeInterval=1 server.1=master:2888:3888server.2=slave1:2888:3888server.3=slave2:2888:3888 ...

一、zookeeper概述 1.1 工作机制+1.2 特点1.3 数据结构1.4 利用场景 1.4.1 对立命名服务1.4.2 对立配置管理1.4.3 对立集群治理1.4.4 服务器动静高低线1.4.5 软负载平衡二、zookeeper下载 1、Linux下载2、官网下载[toc] zookeeper是 Apache 软件基金会的一个软件我的项目，它为大型分布式计算提供开源的分布式配置服务、同步服务和命名注册。 一个典型的分布式数据一致性的解决方案，分布式应用程序能够基于它实现诸如数据公布/订阅、负载平衡、命名服务、分布式协调/告诉、集群治理、Master 选举、分布式锁和分布式队列等性能。 1.1 工作机制+zookeeper从设计模式角度来了解：是一个基于观察者模式设计的分布式服务治理框架，它负责存储和治理大家都关怀的数据，而后承受观察者的注册，一旦这些数据的状态发生变化，zookeeper就将负责告诉曾经在zookeeper上注册的那些观察者做出相应的反馈。 1.2 特点 zookeeper：一个领导者（leader)，多个跟随者（follower），组成的集群。集群中只有有半以上节点存活，zookeeper集群就能失常服务。全局数据统一：每个server保留一份雷同的数据正本，client无论连贯到哪个server，数据都是统一的。更新申请程序进行，来自同一个client的更新申请按其发送程序顺次执行。数据更新原子性，一次数据更新要么胜利，要么失败。实时性，在肯定工夫范畴内，client能读到最新数据。1.3 数据结构zookeeper数据模型的构造与unix文件系统很相似，整体上能够看做一颗树，每个节点称作一个znode。每一个znode默认可能存储1MB的数据，每个znode都能够通过其门路惟一标识。 1.4 利用场景提供的服务包含：对立命名服务，对立配置管理，对立集群治理，服务器节点动静高低线，软负载平衡等。（三对立动为平衡） 1.4.1 对立命名服务在分布式环境下，常常须要对利用/服务进行对立命名，便于辨认。 例如：IP不容易记住，而域名容易记住。 1.4.2 对立配置管理1）在分布式环境下，配置文件同步十分常见。 个别要求一个集群中，所有节点的配置信息是统一的，比方kafka集群。对配置文件批改后，心愿可能疾速同步到各个节点上。2）配置管理可交由zookeeper实现。 可将配置信息写入zookeeper上的一个znode。各个客户端服务器监听这个znode。一旦znode中的数据被批改，zookeeper将告诉各个客户端服务器。 1.4.3 对立集群治理1） 分布式环境中，实时掌控没个节点的状态是必要的。 可依据节点实时状态做出一些调整。2） zookeeper能够实现实时监控节点状态变动 可将节点信息写入zookeeper上的一个znode。监听这个znode可获取他的实时状态变动。 1.4.4 服务器动静高低线客户端能实时洞察到服务器高低线的变动 1.4.5 软负载平衡在zookeeper中记录每台服务器的拜访数，让拜访数起码的服务器去解决最新的客户端申请。 二、zookeeper下载1、Linux下载# wget http://archive.apache.org/dist/zookeeper/zookeeper-3.4.10/zookeeper-3.4.10.tar.gz2、官网下载下载地址：https://zookeeper.apache.org/ 点击download跳转下载页面 抉择下载版本 公众号ID：雨中散步撒哈拉 集体网站： 名称：雨中散步撒哈拉 链接：https://liudongdong.top/ 形容：只有发明，才是真正的享受，只有拚搏，才是空虚的生存。 Q.E.D.

【中间件】Zookeeper从0到1实现一个分布式锁分布式锁，在理论的业务应用场景中算是比拟罕用的了，而分布式锁的实现，常见的除了redis之外，就是zk的实现了，后面一篇博文介绍了zk的基本概念与应用姿态，那么如果让咱们来记住zk的个性来设计一个分布式锁，能够怎么做呢? <!-- more --> I. 方案设计1. 创立节点形式实现zk有四种节点，一个最容易想到的策略就是创立节点，谁创立胜利了，就示意谁持有了这个锁 这个思路与redis的setnx有点类似，因为zk的节点创立，也只会有一个会话会创立胜利，其余的则会抛已存在的异样 借助长期节点，会话丢掉之后节点删除，这样能够防止持有锁的实例异样而没有被动开释导致所有实例都无奈持有锁的问题 如果采纳这种计划，如果我想实现阻塞获取锁的逻辑，那么其中一个计划就须要写一个while(true)来一直重试 while(true) { if (tryLock(xxx)) return true; else Thread.sleep(1000);}另外一个策略则是借助事件监听，当节点存在时，注册一个节点删除的触发器，这样就不须要我本人重试判断了；充沛借助zk的个性来实现异步回调 public void lock() { if (tryLock(path, new Watcher() { @Override public void process(WatchedEvent event) { synchronized (path){ path.notify(); } } })) { return true; } synchronized (path) { path.wait(); }}那么下面这个实现有什么问题呢？ 每次节点的变更，那么所有的都会监听到变动，益处是非偏心锁的反对；毛病就是剩下这些唤醒的实例中也只会有一个抢占到锁，无意义的唤醒节约性能 2. 长期程序节点形式接下来这种计划更加常见，早晨大部分的教程也是这种case，次要思路就是创立长期程序节点 只有序号最小的节点，才示意抢占锁胜利；如果不是最小的节点，那么就监听它后面一个节点的删除事件，后面节点删除了，一种可能是他放弃抢锁，一种是他开释本人持有的锁，不管哪种状况，对我而言，我都须要捞一下所有的节点，要么拿锁胜利；要么换一个前置节点 II.分布式锁实现接下来咱们来一步步看下，基于长期程序节点，能够怎么实现分布式锁 对于zk，咱们仍然采纳apache的提供的包 zookeeper来操作；后续提供Curator的分布式锁实例 1. 依赖外围依赖 <!-- https://mvnrepository.com/artifact/org.apache.zookeeper/zookeeper --><dependency> <groupId>org.apache.zookeeper</groupId> <artifactId>zookeeper</artifactId> <version>3.7.0</version> <exclusions> <exclusion> <groupId>org.slf4j</groupId> <artifactId>slf4j-log4j12</artifactId> </exclusion> </exclusions></dependency>版本阐明: ...

【中间件】Spring整合ZooKeeper根底应用介绍ZooKeeper是一个分布式的，开放源码的分布式应用程序协调服务，广泛应用于分布式系统中，比方有用它做配置核心，注册核心，也有应用它来实现分布式锁的，作为高并发技术栈中不可或缺的一个根底组件，接下来咱们将看一下，zk应该怎么玩，能够怎么玩 本文作为第一篇，将次要介绍基于zk-client的根本应用姿态，顺次来理解下zk的基本概念 <!-- more --> I. 筹备1. zk环境装置用于学习试点目标的体验zk性能，装置比较简单，能够参考博文: 210310-ZooKeeper装置及初体验 wget https://mirrors.bfsu.edu.cn/apache/zookeeper/zookeeper-3.6.2/apache-zookeeper-3.6.2-bin.tar.gztar -zxvf apache-zookeeper-3.6.2-bin.tar.gzcd apache-zookeeper-3.6.2-bin# 前台启动bin/zkServer.sh start-foreground2. 我的项目环境本文演示的是间接应用apache的zookeeper包来操作zk，与是否是SpringBoot环境无关 外围依赖 <!-- https://mvnrepository.com/artifact/org.apache.zookeeper/zookeeper --><dependency> <groupId>org.apache.zookeeper</groupId> <artifactId>zookeeper</artifactId> <version>3.7.0</version> <exclusions> <exclusion> <groupId>org.slf4j</groupId> <artifactId>slf4j-log4j12</artifactId> </exclusion> </exclusions></dependency>版本阐明: zk: 3.6.2SpringBoot: 2.2.1.RELEASEII. ZK应用姿态1. zk根本知识点首先介绍下zk的几个次要的知识点，如zk的数据模型，四种常说的节点 1.1 数据模型zk的数据模型和咱们常见的目录树很像，从/开始，每一个层级就是一个节点 每个节点，蕴含数据 + 子节点 留神：EPHEMERAL节点，不能有子节点（能够了解为这个目录下不能再挂目录） zk中常说的监听器，就是基于节点的，一般来讲监听节点的创立、删除、数据变更 1.2 节点长久节点 persistent node长久程序节点 persistent sequental长期节点 ephemeral node长期程序节点 ephemeral sequental留神： 节点类型一经指定，不容许批改长期节点，当会话完结，会主动删除，且不能有子节点2. 节点创立接下来咱们看一下zk的应用姿态，首先是创立节点，当然创立前提是得先拿到zkClient 初始化连贯 private ZooKeeper zooKeeper;@PostConstructpublic void initZk() throws IOException { // 500s 的会话超时工夫 zooKeeper = new ZooKeeper("127.0.0.1:2181", 500_000, this);}节点创立办法，上面别离给出两种不同的case ...

简略理解ZookeeperTips: 如果之前对Zookeeper不理解的话，这里大略留个印象就好了Zookeeper是一个分布式协调服务，能够用于元数据管理、分布式锁、分布式协调、公布订阅、服务命名等等。 例如，Kafka中就是用Zookeeper来保留其集群中的相干元数据，例如Broker、Topic以及Partition等等。同时，基于Zookeeper的Watch监听机制，还能够用其实现公布、订阅的性能。 在平时的惯例业务应用场景下，咱们简直只会应用到分布式锁这一个用处。 Zookeeper外部运行机制Zookeeper的底层存储原理，有点相似于Linux中的文件系统。Zookeeper中的文件系统中的每个文件都是节点（Znode）。依据文件之间的层级关系，Zookeeper外部就会造成这个这样一个文件树。 在Linux中，文件（节点）其实是分类型的，例如分为文件、目录。在Zookeeper中同理，Znode同样的有类型。在Zookeeper中，所有的节点类型如下： 长久节点（Persistent）长久程序节点（Persistent Sequential)长期节点（Ephemeral）长期程序节点（Ephemeral Sequential）所谓长久节点，就和咱们本人在电脑上新建一个文件一样，除非你被动删除，否则始终存在。 而长久程序节点除了继承了长久节点的个性之外，还会为其下创立的子节点保障其先后顺序，并且会主动地为节点加上10位自增序列号作为节点名，以此来保障节点名的唯一性。这一点上图中的subfiles曾经给出了示例。 而长期节点，其生命周期和client的连贯是否沉闷相干，如果client一旦断开连接，该节点（能够了解为文件）就都会被删除，并且长期节点无奈创立子节点； PS：这里的断开连接其实不是咱们直觉上了解的断开连接，Zookeeper有其Session机制，当某个client的Session过期之后，会将对应的client创立的节点全副删除Zookeeper的节点创立形式接下来咱们来别离看看几种节点的创立形式，给出几个简略的示例。 创立长久节点create /node_name SH的全栈笔记 这里须要留神的是，命令中所有的节点名称必须要以/结尾，否则会创立失败，因为在Zookeeper中是不能应用相对路径，必须要应用绝对路径。 创立长久程序节点create -s /node_name SH的全栈笔记 能够看到，Zookeeper为key主动的加上了10位的自增后缀。 创立长期节点create -e /test SH的全栈笔记 创立长期程序节点create -e -s /node_name SH的全栈笔记 Zookeeper的用处咱们通过一些具体的例子，来理解Zookeeper的具体用处，它不仅仅只是被当作分布式锁应用。 元数据管理咱们都晓得，Kafka在运行时会依赖一个Zookeeper的集群。Kafka通过Zookeeper来治理集群的相干元数据，并通过Zookeeper进行Leader选举。 Tips: 然而行将公布的Kafka 2.8版本中，Zookeeper曾经不是一个必须的组件了。这块我临时还没有工夫去细看，不过我预计可能会跟RocketMQ中解决的形式差不多，将其集群的元数据放到Kafka自身来解决。分布式锁基于Zookeeper的分布式锁其实流程很简略。首先咱们须要晓得加分布式锁的实质是什么？ 答案是创立长期程序节点当某个客户端加锁胜利之后，实际上则是胜利的在Zookeeper上创立了长期程序节点。咱们晓得，分布式锁可能使同一时间只能有一个可能拜访某种资源。那这就必然会波及到分布式锁的竞争，那问题来了，以后这个客户端是如何感知抢到了锁呢？ 其实在客户端侧会有肯定的逻辑，假如加锁的key为/locks/modify_users。 首先，客户端会发动加锁申请，而后会在Zookeeper上创立长久节点locks，而后会在该节点下创立长期程序节点。长期程序节点的创立示例，如下图所示。 当客户端胜利创立了节点之后，还会获取其同级的所有节点。也就是上图中的所有modify_users000000000x的节点。 此时客户端会依据10位的自增序号去判断，以后本人创立的节点是否是所有的节点中最小的那个，如果是最小的则本人获取到了分布式锁。 你可能会问，那如果我不是最小的怎么办呢？而且我的节点都曾经创立了。如果不是最小的，阐明以后客户端并没有抢到锁。依照咱们的认知，如果没有竞争到分布式锁，则会期待。期待的底层都做了什么？咱们用理论例子来捋一遍。 假如Zookeeper中曾经有了如下的节点。 例如以后客户端是B创立的节点是modify_users0000000002，那么很显著B没有抢到锁，因为曾经有比它还要小的由客户端A创立的节点modify_users0000000001。 此时客户端B会对节点modify_users0000000001注册一个监听器，对于该节点的任意更新都将触发对应的操作。 当其被删除之后，就会唤醒客户端B的线程，此时客户端B会再次进行判断本人是否是序号最小的一个节点，此时modify_users0000000002显著是最小的节点，故客户端B加锁胜利。 为了让你更加直观的理解这个过程，我把流程稀释成了上面这幅流程图。 分布式协调咱们都晓得，在很多场景下要保障一致性都会采纳经典的2PC（两阶段提交），例如MySQL中Redo Log和Binlog提交的数据一致性保障就是采纳的2PC，详情能够看基于Redo Log和Undo Log的MySQL解体复原流程。 在2PC中存在两种角色，别离是参与者（Participant）和协调者（Coordinator），协调者负责对立的调度所有分布式节点的执行逻辑。具体协调啥呢？举个例子。 例如在2PC的Commit阶段，两个参与者A、B，A的commit操作胜利了，但可怜的是B失败了。此时协调者就须要向A发送Rollback操作。Zookeeper大略就是这样一个角色。 公布订阅因为Zookeeper自带了监听器（Watch）的性能，所以公布订阅也牵强附会的成为了Zookeeper的利用之一。例如在某个配置节点上注册了监听器，那么该配置一旦公布变更，对应的服务就能实时的感知到配置更改，从而达到配置的动静更新的目标。 给个简略的Watch应用示例。 命名服务用大白话来说，命名服务次要有两种。 单纯的利用Zookeeper的文件系统个性，存储结构化的文件利用文件个性和程序节点的个性，来生成全局的惟一标识前者能够用于在零碎之间共享某种业务上的特定资源，后者则能够用于实现分布式锁。 欢送微信搜寻关注【SH的全栈笔记】，回复【队列】获取MQ学习材料，蕴含根底概念解析和RocketMQ具体的源码解析，继续更新中。 好了以上就是本篇博客的全部内容了，如果你感觉这篇文章对你有帮忙，还麻烦点个赞，关个注，分个享，留个言。

1 装置zookeeper_exporter监控目前promethus中没有开发有现成的zookeeper插件，所以抉择github中验证的zookeeper插件 l exporter下载地址：https://github.com/carlpett/zookeeper_exporter/releases/download/v1.0.2/zookeeper_exporter 下载后上传至/usr/local/prometheus目录下，没有能够本人建任意目录（留神上面配置到该目录即可）赋予执行权限chmod 755 zookeeper_exporter 查看帮忙：./zookeeper_exporter -h 2 启动zookeeper_exporter监控配置：vim /lib/systemd/system/prometheus-zookeeper.service[Unit]Description= prometheus-zookeeperAfter=network.target[Service]Type=simpleExecStart= /usr/local/prometheus/zookeeper_exporter/zookeeper_exporter -zookeeper yourIP:2181 -bind-addr :9143Restart=on-failure[Install]WantedBy=multi-user.target将 zookeeper_exporter 服务设为开机自启并启动systemctl daemon-reload systemctl enable prometheus-zookeeper.service systemctl start prometheus-zookeeper.service 3 配置zookeeper_exporter· 装置好zookeeper _exporter 后，咱们须要在 Prometheus 中对其进行集成· 批改 Prometheus 的配置文件 (prometheus.yml)，增加 redis 服务 (在 scrape_configs 属性下增加)cd /usr/local/prometheus/prometheus-2.15.2.linux-amd64vim prometheus.yml scrape_configs: # The job name is added as a label `job=<job_name>` to any timeseries scraped from this config. - job_name: 'prometheus' # metrics_path defaults to '/metrics' # scheme defaults to 'http'. static_configs: - targets: ['localhost:9090'] - job_name: 'zookeeper' static_configs: - targets: ['YourIP:9143'] labels: instance: zookeeper:wq ...

Zookeeper 是一个分布式服务框架，次要是用来解决分布式应用中遇到的一些数据管理问题如：对立命名服务、状态同步服务、集群治理、分布式应用配置项的治理等。 咱们能够简略把 Zookeeper 了解为分布式家庭的大管家，那么管家团队是如何选出Leader的呢？好奇吗，接下来率领大家一探到底。 人类选举的基本原理解说 Zookeeper 选举过程前先来介绍一下人类的选举。咱们每个人或多或少都经验过几次选举，在投票的过程中可能会遇到这样几种状况： 状况1：本人和候选人熟，将票投给你认为能力强的那个人； 状况2：本人也是候选人，会想着拉票，然而发现他人能力比你强，就将本人的票投给别的候选人。 所有人投票完后，统计投票箱中票数最多的候选人，入选领导。 在整个投票过程中咱们能够提炼出四个最外围的概念： 候选人能力: 投票的根本准则是选最强的人。 遇强改投: 如果前面发现更强的人能够改投票。 投票箱: 所有人的票都会放在投票箱。 领导者: 得票最多的人即为领导者。 从人类选举的原理咱们来简略推导一下Zookeeper的选举原理。 Zookeeper选举的基本原理如果zookeeper是单机部署，不是集群模式，那么不存在选举的问题。zookeeper 的选举和人类选举根本一样，借用下面说的4个外围概念，来说说选举的基本原理。 候选人能力zookeeper 通过 sid 和zxid (事物ID) 来证实本人的能力强弱。 zxid 的全称是 ZooKeeper Transaction Id，即 Zookeeper 事务id。 数据的最新版本号 ， 数据越大阐明能力越强。sid , 咱们自定义的服务器编号ID，值越大证实能力越大。 遇强改投在选举的时候，每台zookeeper 节点都会认为本人是最强的，会先投票给本人（选票上蕴含sid、zxid）。 而后将选票传递给集群中的每个节点，同时本人也会接管其余节点发过的选票。节点接管到选票后，会判断选票上节点的能力强弱，如果发现比本人强，那么就进行改票，把本人的选票投给能力强的。而后在传递给集群中的每个节点。 投票箱与人类选举不同，zookeeper 集群中，每个节点都会保护一份投票箱。 因为每个节点的选票都会同步给每个集群中的节点，所以投票箱的后果都是统一的。 领导者投票的过程中，只有发现票数有超过一半的节点，领导就抉择胜利，投票也就宣告完结。 什么场景下 Zookeeper 须要选举？当zookeeper 集群中有一台机器产生以下场景，就会进行选举。 机器启动机器运行期间leader宕机机器启动选举假如5台zookeeper顺次启动，sid的编号顺次为1-5。 服务器1先投本人1票，投票箱票数不过半，选举无奈实现。此时服务器-1的状态为looking 服务器2先投本人1票，将本人的选票后果同步给服务器1。 服务器1 发现服务器2的sid编号比本人大，于是进行改票，把本人的选票投给了服务器2，并同步给服务器2。 此时单方的投票箱后果为： 服务器1，获0票；服务器2，获2票；并没有超过票数过半的机器。选举仍然无奈实现，此时服务器2的状态仍为looking 服务器3先投本人1票，将本人的选票后果同步给服务器1、服务器2。 服务器1和服务器2 ，发现服务器3的sid编号比本人还大，所以连忙进行改票，都投给了服务器3。 此时投票箱的后果为： 服务器1，获0票；服务器2，获2票；服务器3，获3票；发现有票数过半的机器，于是服务器3，当仁不让成了leader。此时更改服务器1、2的状态为 following，服务器3为leading 服务器4先投本人1票，同步本人选票时，发现服务器1、2、3 曾经不是looking状态了，于是获得投票箱后果，将本人的选票改投给服务器3，本人的状态更改为following 服务5同服务器4 统一。 ...

大抵来说，zookeeper 的罕用的应用场景如下： 分布式协调分布式锁元数据/配置信息管理HA 高可用性分布式协调这个其实是 zookeeper 很经典的一个用法，简略来说，就好比，你 A 零碎发送个申请到 mq，而后 B 零碎音讯生产之后解决了。那 A 零碎如何晓得 B 零碎的处理结果？用 zookeeper 就能够实现分布式系统之间的协调工作。A 零碎发送申请之后能够在 zookeeper 上对某个节点的值注册个监听器，一旦 B 零碎解决完了就批改 zookeeper 那个节点的值，A 零碎立马就能够收到告诉，完满解决。 分布式锁举个栗子。对某一个数据间断收回两个批改操作，两台机器同时收到了申请，然而只能一台机器先执行完另外一个机器再执行。那么此时就能够应用 zookeeper 分布式锁，一个机器接管到了申请之后先获取 zookeeper 上的一把分布式锁，就是能够去创立一个 znode，接着执行操作；而后另外一个机器也尝试去创立那个 znode，后果发现自己创立不了，因为被他人创立了，那只能等着，等第一个机器执行完了本人再执行。 元数据/配置信息管理zookeeper 能够用作很多零碎的配置信息的治理，比方 kafka、storm 等等很多分布式系统都会选用 zookeeper 来做一些元数据、配置信息的治理，包含 dubbo 注册核心不也反对 zookeeper 么？ HA 高可用性这个应该是很常见的，比方 hadoop、hdfs、yarn 等很多大数据系统，都抉择基于 zookeeper 来开发 HA 高可用机制，就是一个重要过程个别会做主备两个，主过程挂了立马通过 zookeeper 感知到切换到备用过程。

摘要咱们理解了zk原理后，接下来就是部署zk、进行zk的运维。在部署zk的时候:zk个别作为基础架构类别的零碎，也能够作为数据中间件零碎，如果在公司的部署机器比拟少，尽管部署的机器少，然而你别用太普通的配置。 思维导图 内容1、单机模式如何启动zk？个别比方zk，kafka，hbase，hdfs这种零碎个别要求机器性能是比拟高的。应用虚拟机的话，比方zk部署3台机器，最好用8核16g，16核32g，最好用ssd固态硬盘。 zk依照集群化3，5单节点部署，部署结束之后，会进行恢复模式进行过半算法选举一个leader进去，只有leader能够读写，follower只能读，客户端跟leader/follower通过tcp长连贯进行连贯，两头靠心跳会保护一个session。往follower去写的话，其实会转发给leader，往集群外面写数据的时候，会采取一个2pc+过半写机制 数据写采纳:日志文件写磁盘+znode内存数据结构 保障的是程序一致性（不能说是强一致性或者最终一致性）。如果肯定须要减少集群的QPS，咱们能够往集群外面增加observer类型的节点进去就能够了，不采取过半写跟leader选举，只是同步数据，客户端查问。Mode:standalone 三台机器的小集群抗每秒十几万的并发是没有问题的，zk集群，基本上公司都够用了。参考：https://segmentfault.com/a/11... 2、zk集群部署zk集群部署操作参考:https://segmentfault.com/a/11... 2.1 集群部署须要多少台机器？为什么？zk如果你用4核8G的虚拟机其实是不太靠谱的。针对于zk的话:最起码也得是：8核16G，如果有16核32G这种高配置虚拟机最好了，而且最好是SSD固态硬盘。因为3种不同配置机器因为zk的并发限度了。 `4核8G的机器:一般来说，每秒并发搞到1000是能够的。8核16G的机器:每秒并发搞到几千是能够的。16核32G的机器:每秒并发搞到上万或者是几万都是有可能的。` 如果你用高配置的机器(16核32G内存的机器)，比方搞了3台机器，1个leader，2个follower，leader次要是写，每秒抗几万并发写入是能够的；leader+follower，读，每秒抗个5万~10万的读是没有问题的，综合能够每秒十多万的QPS都能够抗住了。 2.2 zk的读能力如何扩大；zk的写能力如何扩大？如果用高配置的机器，zk的读并发是比拟高的，只不过写QPS无奈线性的扩大。减少读QPS还能够，咱们只须要强制增加Observer角色节点，不能是leader或者follower(因为Observer不参加过半写机制跟过半选举leader) 因为zk在启动进入恢复模式或者宕机从新进入恢复模式的时候，zk是采纳过半选举机制；如果有过半的机器批准某一个节点为leader节点，那么此节点就是leader节点。比方6台机器，过半就是3台，只有宕机不超过（6-3）台机器，就能够再次选举出leader，提供服务；如果是5台机器，过半是3台，只有宕机机器不超过2台，也能够选举提供服务，过半3跟过半大于2.5的时候，都是3台。 3、正当设置ZooKeeper的JVM参数？1、zk能间接启动吗？比方你当初手头搞好了几台机器，并且是那种大内存的机器，并且zk的配置都配置好了，当初筹备启动了，那么zk能间接启动吗？ 不能，生产环境下，是有一些非凡的货色要改一改的。比方最最起码的一点：zk自身是用java写的，是基于JVM虚拟机来运行的，启动的是一个JVM过程，JVM过程外面会执行zk的全副代码。 2、设置JVM参数： 必须得正当的设置一些JVM的参数。次要有三大块货色，必须要正当的调优和设置的。 1、内存设置：你首先，设置调配你的各块内存区域的大小：堆内存，栈内存，Metaspace区域的内存；依据你机器上内存的状况去设置。 举例：比方你的机器如果有16G的内存，堆内存能够调配个10G，栈内存能够调配每个线程的栈是1MB，Metaspace区域能够调配个512MB都能够。 2、垃圾回收器设置：小内存(32G以下)：咱们设置垃圾回收器，回收新生代+老年代，咱们能够应用ParNew+CMS垃圾回收器进行垃圾回收。 如果是大内存机器，不倡议这个组合了，能够思考应用G1回收所有的垃圾对象，还得设置一些G1的参数，比方：region的大小，最要害的是预期的每次GC的进展工夫是多少毫秒，比方设置为100ms；而后决定G1每隔多长时间进行垃圾回收。 3、gc日志记录设置：线上JVM运行的时候，频繁gc问题，oom问题，退出一些参数，gc日志要写入哪个目录中，如果产生oom的话，此时要主动dump内存快照进去放哪个目录去。 3、怎么简略监控？ 当你的zk启动之后，在你的公司开始应用他了，在各种状况下，比方一些运行高峰期，你应该应用jstat察看一下他的状况，去整个察看下jvm运行的状况，包含他的新生代的对象增长速率，young gc的频率，老年代增长速率，full gc的频率。如果gc有问题，须要得进行gc调优，正当优化jvm参数。另外，如果有监控零碎，须要对zk运行时的jvm的状况进行监控，比如说gc频繁，内存使用率。 4、zk的JVM参数设置在哪里设置？zk的启动参数设置是在：zkServer.sh 的start模块去设置。 4、zk外围参数阐明后面曾经做了zk机器的配置，以及zk在机器上如何部署和配置，还有zk的jvm参数如何配置，如何给zk调配他须要的内存资源、垃圾回收器、gc日志参数。而后解说完了下面的其实还不够，还须要在正式的启动zk之前，还须要理解下其余的一些货色；就是对zk的一些参数进行配置。zk有很多参数，所以咱们须要思考下zk的个别参数如何配置。 tickTime:zk里的最小工夫单位,是zk的根本工夫单元。默认是2000毫秒，也就是2s，zk其余的一些参数就会以这个tickTime为基准来进行设置，比方有的参数就是tickTime * 2。dataDir:次要是放zk里的内存数据快照，因为zk里会存储很多的数据，然而这些数据在内存里有一份快照，而后在磁盘里其实也会有一份数据的快照，这样的话，比方：zk停机了，而后zk重启能力复原之前的数据。所以dataDir次要是寄存zk外面的数据快照的。dataLogDir: 在zk原理时候，咱们解说了zk的写数据操作，它是基于2PC机制，第一个阶段：将申请包装成写proposal，这个时候每台机器都会写入一个本地磁盘的事务日志，次要是放一些日志数据。 一般来说倡议dataDir跟dataLogDir挂载到不同的磁盘，并且最好挂载SSD固态硬盘；因为这样的话，能够保障读写速度十分快，因为dataLogDir这种事务日志磁盘写，是对zk的写性能和写并发的影响是很大的。 5、影响Leader与Follower组成集群运行的两个外围参数这外面给大家解说下两个比拟外围的参数：initLimit跟syncLimit。 initLimit（初始化同步容许超时工夫）：zk集群启动的时候，默认值10就是：10 * tickTime=20s，leader在启动之后会期待follower跟本人建设连贯以及同步数据，最长等待时间是20s，在20s内，follower个别必须要跟leader建设连贯。过了这个工夫之后，leader就不等follower，间接进入音讯播送模式，对外提供服务了。 个别下面默认的参数是不必动的，然而如果：你的zk里存储的数据量比拟大了，导致follower同步数据须要的工夫比拟长，此时能够调大这个参数。 syncLimit（心跳超时距离）：默认值5，也就是5 * tickTime，10s，这个就是指代：leader跟follower之间会进行心跳，如果超过10s没有心跳，leader就把这个follower给踢出去了，认为他曾经死掉了。 6、ZK数据快照zk里的数据分成两份：一份是在磁盘上的事务日志，一份是在内存里的数据结构，实践上两份数据是统一的，即便是有follower宕机，也是内存里的数据失落了，然而磁盘上的事务日志都是存在的。即便有的follower没收到事务日志就宕机了，也能够在启动之后找leader去同步数据 1、什么是数据快照 数据快照是某一时刻全量内存数据的镜像，存储在磁盘文件。2、为什么引入数据快照？ zk宕机时候,重建内存数据:比方zk宕机了，此时zk比如说在磁盘里有一份事务日志了，此时他启动之后要重建内存里的数据，如何重建呢？难道说把事务日志进行回放？一条一条从新执行每条事务日志到内存里去吗？这样必定是不靠谱的，而是会导致zk启动很慢的。所以zk是有一个数据快照的机制。3、zk是什么时候进行数据快照的？ 事务日志的次数超过设定值后，会触发ZK dump全量内存数据到磁盘文件，生成数据快照，如下图所示.4、数据快照创立流程以及相干的参数是什么？ 数据快照创立流程流程： 1. 首先，查看事务日志数量是否达到设定次数；2. 其次，如果超过指定次数，则切换事务日志文件（为了和数据快照放弃同步）；3. 其次创立异步线程，专门用于dump内存数据到磁盘文件；4. 用ZXID作为文件名，而后将会话信息和DatatTree分贝序列化写入文件；快照创立参数： 每次执行肯定的事务之后，就会把内存里的数据快照存储到dataDir这个目录中去，作为zk以后的一个数据快照。当初在磁盘事务日志里有1000个事务，而后把1000个事务对应的内存数据写入到dataDir里作为一个数据快照，接下来持续写事务日志，比方此时事务日志里有1032个事务，此时zk重启，他能够间接把蕴含1000个事务的快照间接加载到内存里来。而后1000之后的32个事务，1001~1032的事务，在内存里回放一遍，就能够在内存里复原进去重启之前的数据了。到底是写多少个事务日志存储一个快照呢？实际上它有一个参数叫做snapCount；snapCount：100000，默认是10万个事务存储一次快照。即便没到10万事务，就重启了，此时是没有快照文件的，然而此时是没有关系的，他认为10万个事务以内，不须要快照，因为10万个事务日志以内，能够间接读取事务日志，回放到内存就重建内存数据了。7、一台机器上最多能启动多少个ZooKeeper客户端？连接数： 在zk客户端上可能会运行一个Java开发的零碎去应用zk，比如说Kafka（尽管是Scala写的，也是JVM类的语言），HBase，Canal，HDFS，比如说Canal比方部署在一台机器上，此时他会去应用zk，他就是一个zk的客户端。当他们应用zk的Java API，去建设一个zk客户端，zk客户端负责跟zk servers进行连贯和通信。 然而一台机器上，咱们能够创立多少个zk客户端？也就是说能够跟zk servers建设多少个连贯呢？ 这个是有限度的，默认来说60；3.4.0以前是10个 1、参数：maxClientCnxns 咱们通过参数：maxClientCnxns能够设置某一个客户端机器最大连贯zk server的连贯个数。 所以如果咱们本人开发一个零碎去应用zk的话，一台机器上，你个别是就用一个zk客户端去跟zk servers进行交互就能够了，不要无限度的搞很多的zk客户端，会连贯不下来的，他zk servers最多只能容许你的一台机器跟他建设60个连贯。 ...

watch是什么watch是zookeeper的外围性能,client能够监控zookeeper中node的状态变动以及node子节点的状态变动,一旦这些状态状态产生了扭转,zookeeper就会告诉这个node上的client,这样client就能做相应的业务逻辑了. 根据ZooKeeper Watches.咱们能够晓得zooKeeper中的所有读操作,也就是getData()、getChildren()和exists()都能够设置一个watch,以下是zooKeeper对watch的定义:watch事件是一次性触发器,当监控的node数据发生变化时产生,事件发送给设置watch的客户端. watch的三个要点在这个watch的定义中有三个要点须要思考: 一次性: 当node的数据发生变化时,就是产生了一个事件,watch是一次性的,在被事件触发后这个watch就会生效.例如，如果client执行getData("/znode1"，true)，而后/znode1的数据被更改或删除，client将取得/znode1的watch事件。如果/znode1再次更改，则不会发送任何watch事件，除非客户端再次读取并设置了一个新的watch 这是一个很重要的知识点,就是一个watch会被重复的一类事件重复的触发么? 答案是不能,触发一次后watch就生效了,你须要再次设置watch来从新监听事件有序性: 产生到client的watch事件和更新node数据的操作是有先后顺序的,也就是先进行了node数据更新,node数据更新胜利后才会产生watch事件.client能力接到告诉.可能有人认为zookeeper只有接到node数据更新操作就会产生watch事件,这个假如是错的,zookeeper做到分布式一致性其实是有严格的有序性的.watch事件是被异步发送到client的,同时对于同一个watch事件如果有多个client监听的话,因为网络提早这些client可能会在事件的承受工夫上有轻微的偏差,不同客户端看到的所有操作仍然有统一的程序watch事件是有类型的: node数据的扭转能够分为2个了类型,一个是node的数据被扭转,例外一个是node的子节点被扭转. zookeeper因而保护了2种watch事件列表:getData()和exists()能够设置数据扭转相干的watch,getChildren()能够设置node子节点相干的watch.咱们在设置watch的时候须要依照下面的类型进行抉择.zookeeper对watch的保障zookeeper保护了如下的保障 有序性: watch是依据其余事件、其余watch和异步响应来排序的。ZooKeeper客户端库确保所有的事件都被有序地调度。事件产生在事件发送前: 一个事件必须在数据操作胜利后产生,而后才会发给watch. 事件的产生和事件的发送不是并行的,必须是先后关系事件的有序性: zookeeper会有多个watch,这些watch事件的产生的程序是和数据操作的程序统一的应用watch要留神如下的问题应用watch要留神上面几点: watch是一次性的,当watch被触发而后发送给client后,前面同类的事件是不会再次发送到client了,你要继续的监听只能从新增加watch因为规范的手表是一次性触发器，并且在获取事件和发送一个新的申请来获取手表之间有提早，你不能牢靠地看到产生在ZooKeeper节点上的每一个变动。筹备好解决znode在获取事件和再次设置手表之间屡次更改的状况。(你可能并不在乎，但至多意识到这种状况可能会产生。)A watch object, or function/context pair, will only be triggered once for a given notification. For example, if the same watch object is registered for an exists and a getData call for the same file and that file is then deleted, the watch object would only be invoked once with the deletion notification for the file.When you disconnect from a server (for example, when the server fails), you will not get any watches until the connection is reestablished. For this reason session events are sent to all outstanding watch handlers. Use session events to go into a safe mode: you will not be receiving events while disconnected, so your process should act conservatively in that mode.watch注册与处触发如图下图所示： ...

zookeeper提供简略的ACL性能,用于对某个具体的node做根本的访问控制.比方限度某个用户对/a这个节点只有只读权限.zookeeper的ACL的粒度严格限度在node级别而且对父节点的ACL设置不会被子节点继承,比方设置某用户u1对节点/a有只读权限后并不意味着用户u1对/a/sub_a的节点也是只读. Note also that an ACL pertains only to a specific znode. In particular it does not apply to children. For example, if /app is only readable by ip:172.16.16.1 and /app/status is world readable, anyone will be able to read /app/status; ACLs are not recursive.zookeeper的ACL权限管制,能够管制节点的读写操作,保证数据的安全性,Zookeeper ACL权限设置分为3局部组成,别离是:权限模式(Scheme)、受权对象(ID)、权限信息(Permission).最终组成一条例如scheme:id:permission格局的ACL申请信息。 上面咱们具体看一下这 3 局部代表什么意思: Scheme(权限模式): zookeeper提供上面5种权限模式 world: 默认,任何人都有权限auth: 代表曾经认证通过的用户(cli中能够通过addauth digest user:pwd 来增加以后上下文中的受权用户)digest: 应用username:password字符串生成MD5哈希，并将其用作ACL ID标识。身份验证是通过明文发送用户名:明码来实现的。当在ACL中应用时，表达式将是用户名:base64编码的SHA1明码摘要。ip: 应用客户端主机IP作为ACL ID标识。ACL表达式的模式是addr/bits，其中addr的最无效位与客户端主机IP的最无效位相匹配x509受权对象(ID): 受权对象就是说咱们要把权限赋予谁,不同的Scheme有绝对应的ID类型,对应于 5种不同的权限模式来说,如果咱们抉择采纳IP形式,应用的受权对象能够是一个IP地址或IP地址段;而如果应用Digest,则对应于一个用户名。如果是World模式，是受权零碎中所有的用户权限信息(Permission):权限就是指咱们能够在数据节点上执行的操作品种,在 ZooKeeper 中曾经定义好的权限有5种: 数据节点（c: create）创立权限，授予权限的对象能够在数据节点下创立子节点；数据节点（w: wirte）更新权限，授予权限的对象能够更新该数据节点；数据节点（r: read）读取权限，授予权限的对象能够读取该节点的内容以及子节点的列表信息；数据节点（d: delete）删除权限，授予权限的对象能够删除该数据节点的子节点；数据节点（a: admin）管理者权限，授予权限的对象能够对该数据节点体进行 ACL 权限设置。代码验证咱们能够应用setAcl设置ACL也能够应用getAcl获取ACL信息 ...

本文依据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 namespaceZooKeeper提供的命名空间相似于规范的文件系统.名称是用斜杠(/)分隔的门路元素序列.ZooKeeper命名空间中的每个节点都用门路标识.与规范的文件系统构造不一样的是zookeeper的门路全副是绝对路径齐全没有相对路径,所以任何node的path都是/结尾的 上面是node的档次继承图 zookeeper采纳高度相似文件系统的数据结构而不是从新设计一个专属的构造,极大的简化的了zookeeper的学习难度,非常容易上手. 一致性保障zookeeper确保上面的几个保障: Sequential ConsistencyAtomicitySingle System ImageReliabilityTimeliness对于它们的具体解读请看: 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 概览与性能

zookeeper是一个高性能,可扩大的服务.zookeeper的读操作和写操作的设计指标就是速度快,不过zookeeper的读比写快,在读的场景下,zookeeper能够将读的压力扩散到不同的follow服务节点上,而且须要读取的数据大部分是曾经被更新好了的'旧'的数据,而写操作须要在各个节点间保障一致性同步.保证数据的一致性同步是zookeeper的外围性能,他提供如下保障: 程序一致性: 从客户端发送过去的命令是依照工夫先后顺序有序执行的(注:更新操作是leader节点执行的,读取申请leader/follow都能够执行)原子性: 更新操作的后果要么胜利要么失败,没有局部胜利或者局部失败的状况,不会产生局部后果繁多的统一零碎映像:客户端读取到数据都是统一的,也就是讲对于一个zookeeper集群来讲,同一时间节点上客户端在任何一个节点读取的数据都是统一的,即便有些非凡状况下zookeeper产生了故障转移,客户端也不会读取到脏的数据可靠性: 一旦更新被利用了,那么数据就会被长久化了不会被失落或者篡改除非客户端前面被动的批改这个值,这个保障有2个推论: 如果客户端失去了一个操作的success code,那么这个更新操作就被利用了.一个服务端谬误产生了()那么客户端是不晓得的操作是胜利还是失败了,咱们采取的步骤是尽量减少失败,但只有返回胜利代码的操作才有保障(这在Paxos中称为枯燥条件)任何被客户端看到的数据,也就是以后看到的最新的数据或者被胜利更新后的最新的数据,即便服务器因为故障而从新复原后也不会被回滚为旧或者脏数据(失落,篡改,脏数据,旧数据)及时性:保证系统的客户端视图在肯定的工夫范畴内(以数十秒为数量级)是最新的.在此范畴内,客户机要么看到零碎更改要么检测到服务中断应用这些一致性保障很容易在ZooKeeper客户端上建设更高级别的性能,比方leader选举、阻碍、队列和读/写可撤销锁(不须要增加ZooKeeper),更多状况请看:Recipes and Solutions 留神 一些开发者会谬误的认为除了下面讲到的一致性保障外,还有例外的一种保障zookeeper不能反对,这保障就是工夫上齐全同时的一致性跨客户端视图:zookeeper无奈确保集群中的任意一个节点都会齐全同时的执行一个同一个操作,因为网络通信是有提早的,一个客户端更新操作是在例外一个客户端接到数据更新告诉的后面产生的,思考上面的场景,有A,B共2个客户端,如果A更新了/a节点的数据由0到1,而后通知B客户端去读取/a,客户端B可能会读到/a的旧数据,取决于B是从那个节点读取/a(读取leader是最新的,然而读取follow可能是旧的).如果客户端A和客户端B读取雷同的值很重要,客户端B应该在执行读取操作之前调用zookeeper API办法中的sync()办法.所以，zookeeper自身并不能保障在所有服务器上同步发生变化，然而zookeeper原语能够用来构建更高级别的函数，提供有用的客户端同步. 参考: Consistency Guarantees《ZooKeeper官网指南》一致性保障本文原创链接: zookeeper 一致性保障

咱们在架设好zookeeper服务后,个别会应用监控零碎来对zookeeper的服务状态进行监控,比方grafana,Prometheus等,在这个场景下简略疾速的获取服务状态是很有必要的,所以zookeeper为咱们提供了一些这方面的命令工具,官网文档为:ZooKeeper Commands: The Four Letter Words 监控相干的材料以前我也有写,请看: 察看零碎解决了什么它又须要什么 zookeeper提供的一系列四字(The Four Letter Words)命令,不便咱们跟服务器进行各种交互,来确认服务器以后的工作状况(这也是服务器监控告警的根底),咱们传递四个字母的字符串给zookeeper,zookeeper会返回一些有用的信息. zookeeper四字命令功能表命令性能conf输入相干服务配置的详细信息。cons列出所有连贯到服务器的客户端的齐全的连贯 /会话的详细信息。包含“承受 / 发送”的包数量、会话 id 、操作提早、最初的操作执行等等信息.dump列出未经解决的会话和长期节点.envi输入对于服务环境的详细信息（区别于 conf命令）.reqs列出未经解决的申请ruok测试服务是否处于正确状态。如果的确如此，那么服务返回“imok ”，否则不做任何相应.stat输入对于性能和连贯的客户端的列表.wchs列出服务器 watch的详细信息.wchc通过 session列出服务器 watch的详细信息，它的输入是一个与watch相干的会话的列表.wchp通过门路列出服务器 watch的详细信息。它输入一个与 session相干的门路.代码演示上面咱们对zookeeper的The Four Letter Words做一些简略的演示 查看服务状态 [thinktik@ThinkOnline bin]$ echo stat|nc 127.0.0.1 2181stat is not executed because it is not in the whitelist.默认状况下The Four Letter Words是没有退出白名单的,这意味着你须要将他们退出白名单后能力争取的执行,否则会报错xxx is not executed because it is not in the whitelist. 解决方案很简略,退出这些命令到白名单即可,咱们能够批改zoo.cfg而后重启zookeeper即可更多的细节这篇文章也不错:https://blog.csdn.net/Ellen5203/article/details/105706773 批改胜利后咱们就能够失常应用了,上面是一些演示 [thinktik@ThinkOnline bin]$ echo stat|nc 127.0.0.1 2181Zookeeper version: 3.6.2--803c7f1a12f85978cb049af5e4ef23bd8b688715, built on 09/04/2020 12:44 GMTClients: /127.0.0.1:41556[0](queued=0,recved=1,sent=0)Latency min/avg/max: 0/0.0/0Received: 1Sent: 0Connections: 1Outstanding: 0Zxid: 0x5eMode: standaloneNode count: 8测试是否启动了该Server，若回复imok示意曾经启动 ...

本文次要记录一个zookeeper node详细信息的各项参数的含意 官网文档: ZooKeeper Stat Structure 参数解释中文解读czxidThe zxid of the change that caused this znode to be created.批改这个节点时的zxid号mzxidThe zxid of the change that last modified this znode.批改这个节点时的zxid号pzxidThe zxid of the change that last modified children of this znode.批改这个节点给它增加子节点时的zxid号ctimeThe time in milliseconds from epoch when this znode was created.节点的创立工夫mtimeThe time in milliseconds from epoch when this znode was last modified.节点的批改工夫versionThe number of changes to the data of this znode.节点变更的版本号cversionThe number of changes to the children of this znode.该节点的子节点的更新次数aversionThe number of changes to the ACL of this znode.这个节点的ACL的变更次数ephemeralOwnerThe session id of the owner of this znode if the znode is an ephemeral node. If it is not an ephemeral node, it will be zero.如果是长期节点，那么创立这个节点的session id号dataLengthThe length of the data field of this znode.这个节点的数据的长度numChildrenThe number of children of this znode.这个节点的子节点数量代码演示[zk: localhost:2181(CONNECTED) 3] create /p1 thinktikCreated /p1[zk: localhost:2181(CONNECTED) 4] stat /p1cZxid = 0x58ctime = Mon Feb 15 23:42:57 CST 2021mZxid = 0x58mtime = Mon Feb 15 23:42:57 CST 2021pZxid = 0x58cversion = 0dataVersion = 0aclVersion = 0ephemeralOwner = 0x0 # 非长期节点的值固定为0x0，长期节点会有seesion iddataLength = 8 # 该节点的长度为为8，也是就thinktik的长度numChildren = 0 # 子节点个数为0[zk: localhost:2181(CONNECTED) 5] create /p1/s1 thinkCreated /p1/s1[zk: localhost:2181(CONNECTED) 6] stat /p1cZxid = 0x58ctime = Mon Feb 15 23:42:57 CST 2021mZxid = 0x58mtime = Mon Feb 15 23:42:57 CST 2021pZxid = 0x59 # 子节点被创立时的zxidcversion = 1 # 子节点批改了1次dataVersion = 0aclVersion = 0ephemeralOwner = 0x0dataLength = 8numChildren = 1 # 子节点个数为1[zk: localhost:2181(CONNECTED) 11] create /p1/s2 think2Created /p1/s2[zk: localhost:2181(CONNECTED) 12] stat /p1cZxid = 0x58ctime = Mon Feb 15 23:42:57 CST 2021mZxid = 0x58mtime = Mon Feb 15 23:42:57 CST 2021pZxid = 0x5ccversion = 2 # 子节点批改了2次dataVersion = 0aclVersion = 0ephemeralOwner = 0x0dataLength = 8numChildren = 2 # 子节点个数为2实际上的官网文档和代码演示有轻微的区别，然而区别不大 ...

长期节点多久会被删除zookeeper的长期节点顾名思义是长期的,也就是说在一个连贯session有效期内长期节点是沉闷的,当连贯断开后,session会天然的过期，session中过期了那么长期节点就会被删除 ZooKeeper also has the notion of ephemeral nodes. These znodes exists as long as the session that created the znode is active. When the session ends the znode is deleted.那么session的工夫默认是多少呢，答案是2xtickTime到20xtickTime之间 Ticks When using multi-server ZooKeeper, servers use ticks to define timing of events such as status uploads, session timeouts, connection timeouts between peers, etc. The tick time is only indirectly exposed through the minimum session timeout (2 times the tick time); if a client requests a session timeout less than the minimum session timeout, the server will tell the client that the session timeout is actually the minimum session timeout.the basic time unit in milliseconds used by ZooKeeper. It is used to do heartbeats and the minimum session timeout will be twice the tickTime. ...

本文依据ZooKeeper-cli: the ZooKeeper command line interface对一些常见的zookeeper cli命令做一些笔记. 登录咱们能够应用zkCli命令来登录上zookeeper. # 本地登录,默认为localhost:2181[thinktik@ThinkOnline bin]$ ./zkCli.sh# 指定host和port,咱们能够应用这个命令加上-server参数来进行近程登录[thinktik@ThinkOnline bin]$ ./zkCli.sh -server localhost:2181查看文档咱们能够应用zookeeper时通过help来查看文档 [zk: localhost:2181(CONNECTED) 0] helpZooKeeper -server host:port -client-configuration properties-file cmd args addWatch [-m mode] path # optional mode is one of [PERSISTENT, PERSISTENT_RECURSIVE] - default is PERSISTENT_RECURSIVE addauth scheme auth close config [-c] [-w] [-s] connect host:port create [-s] [-e] [-c] [-t ttl] path [data] [acl] delete [-v version] path deleteall path [-b batch size] delquota [-n|-b] path get [-s] [-w] path getAcl [-s] path getAllChildrenNumber path getEphemerals path history listquota path ls [-s] [-w] [-R] path printwatches on|off quit reconfig [-s] [-v version] [[-file path] | [-members serverID=host:port1:port2;port3[,...]*]] | [-add serverId=host:port1:port2;port3[,...]]* [-remove serverId[,...]*] redo cmdno removewatches path [-c|-d|-a] [-l] set [-s] [-v version] path data setAcl [-s] [-v version] [-R] path acl setquota -n|-b val path stat [-w] path sync path version Command not found: Command not found help创立节点咱们能够应用create [-s] [-e] [-c] [-t ttl] path [data] [acl]来创立节点，默认节点类型为persistent节点 ...

zookeeper简介ZooKeeper是一个分布式的，开放源码的分布式应用程序协调服务，是Google的Chubby一个开源的实现，是Hadoop和Hbase的重要组件。它是一个为分布式应用提供一致性服务的软件，提供的性能包含：配置保护、名字服务、分布式同步、组服务等。ZooKeeper的指标就是封装好简单易出错的要害服务，将简略易用的接口和性能高效、性能稳固的零碎提供给用户。ZooKeeper蕴含一个简略的原语集，提供Java和C的接口。ZooKeeper源代码中，提供了分布式独享锁、选举、队列的接口，代码在zookeeper-x.x.x\src\recipes。其中散布锁和队列有Java和C两个版本，选举只有Java版本。 zookeeper的原理ZooKeeper是以Fast Paxos算法为根底的，paxos算法存在活锁的问题，即当有多个proposer交织提交时，有可能相互排挤导致没有一个proposer能提交胜利，而Fast Paxos作了一些优化，通过选举产生一个leader，只有leader能力提交propose。=。因而要想弄懂ZooKeeper首先得对Fast Paxos有所理解。 ZooKeeper的根本运行流程： 选举Leader。同步数据。选举Leader过程中算法有很多，但要达到的选举规范是统一的。Leader要具备最高的zxid。集群中大多数的机器失去响应并follow选出的Leaderzookeeper的特点在Zookeeper中，znode是一个跟Unix文件系统门路类似的节点，能够往这个节点存储或获取数据。如果在创立znode时Flag设置为EPHEMERAL，那么当创立这个znode的节点和Zookeeper失去连贯后，这个znode将不再存在在Zookeeper里，Zookeeper应用Watcher觉察事件信息。当客户端接管到事件信息，比方连贯超时、节点数据扭转、子节点扭转，能够调用相应的行为来解决数据。Zookeeper的Wiki页面展现了如何应用Zookeeper来处理事件告诉，队列，优先队列，锁，共享锁，可撤销的共享锁，两阶段提交。那么Zookeeper能作什么事件呢，简略的例子：假如咱们有20个搜索引擎的服务器(每个负责总索引中的一部分的搜寻工作)和一个总服务器(负责向这20个搜索引擎的服务器收回搜寻申请并合并后果集)，一个备用的总服务器(负责当总服务器宕机时替换总服务器)，一个web的cgi(向总服务器收回搜寻申请)。搜索引擎的服务器中的15个服务器提供搜寻服务，5个服务器正在生成索引。这20个搜索引擎的服务器常常要让正在提供搜寻服务的服务器进行提供服务开始生成索引，或生成索引的服务器曾经把索引生成实现能够搜寻提供服务了。应用Zookeeper能够保障总服务器主动感知有多少提供搜索引擎的服务器并向这些服务器收回搜寻申请，当总服务器宕机时主动启用备用的总服务器。 装置筹备工作在装置zookeeper之前咱们要确保本人主机上曾经有了Java环境，倡议装置Oracle JDK8.x 环境版本RHEL/CentOS7.xJava8.xZookeeper3.4.x# 查看java环境[thinktik@localhost ~]$ java -versionjava version "1.8.0_191"Java(TM) SE Runtime Environment (build 1.8.0_191-b12)Java HotSpot(TM) 64-Bit Server VM (build 25.191-b12, mixed mode)[thinktik@localhost ~]$ lsapache-maven-3.6.0-bin.tar.gz httpd-2.4.37.tar.gz jenkins.war sonarqube-6.7.5.tarhttpd java8 maven zookeeper-3.4.13.tar.gzhttpd-2.4.37 jdk-8u191-linux-x64.tar.gz sonarqube-6.7.5# 解压[thinktik@localhost ~]$ tar -zxvf zookeeper-3.4.13.tar.gz [thinktik@localhost ~]$ lsapache-maven-3.6.0-bin.tar.gz httpd-2.4.37.tar.gz jenkins.war sonarqube-6.7.5.tarhttpd java8 maven zookeeper-3.4.13httpd-2.4.37 jdk-8u191-linux-x64.tar.gz sonarqube-6.7.5 zookeeper-3.4.13.tar.gz[thinktik@localhost ~]$ cd zookeeper-3.4.13[thinktik@localhost zookeeper-3.4.13]$ lsbin dist-maven lib README_packaging.txt zookeeper-3.4.13.jar.ascbuild.xml docs LICENSE.txt recipes zookeeper-3.4.13.jar.md5conf ivysettings.xml NOTICE.txt src zookeeper-3.4.13.jar.sha1contrib ivy.xml README.md zookeeper-3.4.13.jar# 创立data文件夹保持数据[thinktik@localhost zookeeper-3.4.13]$ mkdir data# 创立logs文件夹保留日志[thinktik@localhost zookeeper-3.4.13]$ mkdir logs[thinktik@localhost zookeeper-3.4.13]$ pwd/home/thinktik/zookeeper-3.4.13[thinktik@localhost zookeeper-3.4.13]$ cd conf/[thinktik@localhost conf]$ lsconfiguration.xsl log4j.properties zoo_sample.cfg# 将样例配置文件复制一份为zoo.cfg[thinktik@localhost conf]$ cp zoo_sample.cfg zoo.cfg # 批改配置文件[thinktik@localhost conf]$ vim zoo.cfg配置文件参考（这里我将dataDir和dataLogDir门路改为了我方才创立文件夹） ...

Zookeeper通过ZAB保障分布式事务的最终一致性。 ZAB全称Zookeeper Atomic Broadcast（ZAB，Zookeeper原子音讯播送协定） 1.ZAB是一种专门为Zookeeper设计的一种反对 解体复原 的 原子播送协定 ，是Zookeeper保证数据一致性的外围算法。ZAB借鉴了Paxos算法，但它不是通用的一致性算法，是特地为Zookeeper设计的。 2.基于ZAB协定，Zookeeper实现了⼀种主备模式的零碎架构来放弃集群中各正本之间的数据的⼀致性，表现形式就是使⽤⼀个单⼀的主过程（Leader服务器）来接管并解决客户端的所有事务申请（写申请），并采⽤ZAB的原⼦⼴播协定，将服务器数据的状态变更为事务 Proposal的模式⼴播到所有的Follower过程中。 问题提出 主从架构下，leader 解体，数据一致性怎么保障？选举 leader 的时候，整个集群无奈解决写申请的，如何疾速进行 leader 选举？ZAB过程 ZAB协定的核⼼是 定义了对于那些会扭转Zookeeper服务器数据状态的事务申请的解决⽅式所有事务必须由一个 全局惟一的服务器来协调解决 ，这样的服务器被称为Leader服务器，余下的服务器则称为Follower服务器 1.Leader服务器负责将一个客户端事务申请转化为一个事务Proposal（提案），并将该Proposal分发给集群中所有的Follower服务器 2.Leader服务器期待所有Follower服务器的反馈，一旦超过半数的Follower服务器进行了正确的反馈后，Leader就会向所有的Follower服务器发送Commit音讯，要求将前一个Proposal进行提交。 ZAB协定内容简介 ZAB协定包含两种根本的模式： 解体复原 和 音讯播送 音讯播送 当集群中有过半的Follower服务器实现了和Leader服务器的状态同步，那么整个服务框架就能够进入 音讯播送模式 。 当一台恪守ZAB协定的服务器启动后退出到集群中，如果此时集群中曾经存在一个Leader服务器在负责进行音讯播送，那么退出的服务器会盲目的进入 数据恢复模式：找到Leader 所在的服务器，并与其进⾏数据同步，数据同步实现后参加到音讯⼴播流程中。 ZAB协定的音讯播送应用原子播送协定， 相似一个二阶段提交的过程 ，但又有所不同。 1.二阶段提交中，须要所有参与者反馈ACK后再发送Commit申请。要求所有参与者要么胜利，要么失败。这样会产生重大的阻塞问题; 2.ZAB协定中，Leader期待半数以上的Follower胜利反馈ACK即可，不须要收到全副的Follower反馈ACK。 音讯播送过程： 1.客户端发动写申请 2.Leader将客户端申请信息转化为事务Proposal，同时为每个Proposal调配一个事务ID（Zxid） 3.Leader为每个Follower独自调配一个FIFO的队列，将须要播送的Proposal顺次放入到队列中 4.Follower接管到Proposal后，首先将其以事务日志的形式写入到本地磁盘中，写入胜利后给Leader反馈一个ACK响应 5.Leader接管到半数以上Follower的ACK响应后，即认为音讯发送胜利，能够发送Commit音讯 6.Leader向所有Follower播送Commit音讯，同时本身也会实现事务提交。Follower接管到Commit音讯后也会实现事务的提交解体复原 在整个服务框架启动过程中，如果Leader服务器呈现网络中断、解体退出或重启等异常情况，ZAB协定就会进入解体恢复模式。同时选举出新的Leader服务器。 当选举产生了新的Leader服务器，同时集群中曾经有过半的机器与该Leader服务器实现了状态同步（数据同步）之后，ZAB协定会退出恢复模式。 1.在ZAB协定中，为了保障程序的正确运⾏，整个复原过程完结后须要选举出⼀个新的Leader 服务器。 2.Leader选举算法不仅仅须要让Leader⾃身晓得曾经被选举为Leader，同时还须要让集群中的所有其余机器也可能疾速地感知到选举产⽣进去的新Leader服务器。 ZAB保证数据一致性 ZAB协定规定了 如果⼀个事务Proposal在⼀台机器上被解决胜利，那么应该在所有的机器上都被解决胜利，哪怕机器呈现故障解体。 针对这些状况ZAB协定须要保障以下条件： 曾经在Leader服务器上提交的事务最终被所有服务器都提交。假如⼀个事务在 Leader 服务器上被提交了，并且曾经失去过半 Folower 服务器的Ack反馈，然而在它 将Commit音讯发送给所有Follower机器之前，Leader服务器挂了抛弃只在Leader服务器上被提出（未提交）的事务。假如初始的 Leader 服务器 Server1 在提出了⼀个事务Proposal3 之后就解体退出 了，从⽽导致集群中的其余服务器都没有收到这个事务Proposal3。于是，当 Server1 恢复过来再次加 ⼊到集群中的时候，ZAB 协定须要确保抛弃Proposal3这个事务。综上所述，ZAB的选举进去的Leader必须满足以下条件： ...

1.什么是HA？所谓HA，也就是高可用，放在理论经营中，那就是7*24小时不间断服务。那么实现HA，最要害的中央的就是打消单点故障，那什么是单点故障，就没有可代替的节点，一旦这个节点挂了，那整个服务也跟着瘫痪，直到该节点复原。 2.Hadoop HAHadoop为什么须要HA呢？因为存在单点故障，HDFS上的NameNode，这就是一个单点故障，它只存在一个，如果NameNode挂了，或者咱们须要对这个节点降级更新，那么会导致集群不可用，2.0版本之后，还有Yarn也是，ResourceManager也只有一个，也是单点故障。 所以Hadoop须要HA，而且咱们要实现两个中央的HA，HDFS的HA和Yarn的HA。 3.利用Zookeeper的实现Hadoop的HA3.1 搭建hadoop参考文档hadoop部署 3.2 搭建Zookeeper集群参考文档zookeeper部署 3.3 HDFS HA我这有三个节点，hadoop14、hadoop15、hadoop16节点信息如下： ==============hadoop14 jps================6096 JobHistoryServer6436 Jps5751 DataNode5929 SecondaryNameNode6205 NodeManager5599 NameNode==============hadoop15 jps================3616 ResourceManager3746 NodeManager4163 Jps3454 DataNode==============hadoop16 jps================3089 Jps2796 DataNode2894 NodeManager咱们当初实现的是多个namenode和ResourceManager，打算如下： server_namehadoop14hadoop15hadoop16namenodeYYYResourceManager YYnamenode咱们弄三个，ResourceManager咱们来两个。 3.2.1 HDFS HA多个NameNode中，只有一个处于Active提供服务，其余的处于Standby状态，作为备用。如果Active的NameNode故障或者该节点须要保护，则切换到Standby节点上提供服务即可，这时提供服务的Standby的节点变为Active。那么如何做到实时同步节点Active和Standby的元数据信息呢？那就须要一个共享存储系统，咱们这里应用Zookeeper。Active负责向共享存储系统写入元数据，而处于Standby的的节点负责监听，当发现有新数据写入时，则读取这些数据，将其加载到内存中，保障本人内存状态与ActiveNameNode统一。 那么开始配置HDFS HA。1）core-site.html <!-- 把多个NameNode的地址组装成一个集群mycluster --> <property> <name>fs.defaultFS</name> <value>hdfs://mycluster</value> </property> <!-- 指定hadoop运行时产生文件的存储目录 --> <property> <name>hadoop.tmp.dir</name> <value>/opt/module/ha/data/tmp</value> </property> <!-- 申明journalnode服务器存储目录--> <property> <name>dfs.journalnode.edits.dir</name> <value>file://${hadoop.tmp.dir}/jn</value> </property>2)hdfs-site.html <!-- 齐全分布式集群名称 --> <property> <name>dfs.nameservices</name> <value>mycluster</value> </property> <!-- NameNode数据存储目录 --> <property> <name>dfs.namenode.name.dir</name> <value>file://${hadoop.tmp.dir}/name</value> </property> <!-- DataNode数据存储目录 --> <property> <name>dfs.datanode.data.dir</name> <value>file://${hadoop.tmp.dir}/data</value> </property> <!-- 集群中NameNode节点都有哪些 --> <property> <name>dfs.ha.namenodes.mycluster</name> <value>nn1,nn2,nn3</value> </property> <!-- nn1的RPC通信地址 --> <property> <name>dfs.namenode.rpc-address.mycluster.nn1</name> <value>hadoop14:9000</value> </property> <!-- nn2的RPC通信地址 --> <property> <name>dfs.namenode.rpc-address.mycluster.nn2</name> <value>hadoop15:9000</value> </property> <!-- nn3的RPC通信地址 --> <property> <name>dfs.namenode.rpc-address.mycluster.nn3/name> <value>hadoop16:9000</value> </property> <!-- nn1的http通信地址 --> <property> <name>dfs.namenode.http-address.mycluster.nn1</name> <value>hadoop14:9870</value> </property> <!-- nn2的http通信地址 --> <property> <name>dfs.namenode.http-address.mycluster.nn2</name> <value>hadoop15:9870</value> </property> <!-- nn3的http通信地址 --> <property> <name>dfs.namenode.http-address.mycluster.nn3/name> <value>hadoop16:9870</value> </property> <!-- 指定NameNode元数据在JournalNode上的寄存地位 --> <property> <name>dfs.namenode.shared.edits.dir</name> <value>qjournal://hadoop14:8485;hadoop15:8485;hadoop16:8485/mycluster</value> </property> <!-- 配置隔离机制，即同一时刻只能有一台服务器对外响应 --> <property> <name>dfs.ha.fencing.methods</name> <value>sshfence</value> </property> <!-- 应用隔离机制时须要ssh无秘钥登录--> <property> <name>dfs.ha.fencing.ssh.private-key-files</name> <value>/home/v2admin/.ssh/id_rsa</value> </property> <!-- 拜访代理类：client用于确定哪个NameNode为Active --> <property> <name>dfs.client.failover.proxy.provider.mycluster</name> <value>org.apache.hadoop.hdfs.server.namenode.ha.ConfiguredFailoverProxyProvider</value> </property>3)别离在三个节点启动journalnode服务 ...

1.监听机制1.1 触发器watch什么是触发器watch？watch事件是一次性的触发器。Zookeeper可能在所有的读操作上设置触发器watch，当watch的对象状态发生变化，就会触发此对象上触发器对应的事件。watch事件传递到客户端，这个过程是异步执行的。 watch类型Zookeeper中触发器的watch有两类，data watch和child watch。1）data watch：getData和exists负责设置datawatch。2）child watch：getChildren负责设置child watch watch注册和触发详解 通过操作getData、exists和getChildren的返回值来设置不同的watch。getData和exists返回节点的数据信息，getChildren返回子节点列表 1）在exists上watch，被监督的Znode创立、删除、数据更新会触发2）getData上的watch，被监督的Znode删除或数据更新时会触发。留神被创立时不会触发，而创立时，Znode还不存在，Znode只有存在，getData的操作才会胜利，也能力触发watch。3）getChildren上的watch，被监督的Znode创立或者删除它的子节点child，或者Znode被删除时会触发。具体是触发的watch是什么类型的事件，能够对应上表。 1.2监听原理整个监听机制的运行脱离不了三个角色，Client、Client WatcherManage、Zookeeper Server。1）Client在向服务器Zookeeper Server注册时，WatcherManager会存储Wather对象。2）当Zookeeper Server触发Watcher事件后，向Client发送告诉。3）Client从WatcherManager取出对应的Watcher对象来执行回调。 2.半数机制Zookeeper集群中只有半数以上机器存活，集群就能失常运行，所以部署时，咱们个别装置奇数个节点,5\7\9\11等。 3.选举机制首先明确一点，Zookeeper集群没有master和slave的概念，但有leader和follower节点之分。leader节点只有一个。以五个节点的示例阐明(这个示例记得是从一个博客看来的，具体是哪个忘了，过后只保留这个内容) 假如有五台服务器组成的 zookeeper 集群，它们 的 serverid 从 1-5，同时它们都是最新启动的，也就是没有历史数据，在存放数据量这一点 上，都是一样的。假如这些服务器依序启动，来看看会产生什么1、服务器 1 启动，此时只有它一台服务器启动了，它收回去的报没有任何响应，所以它的 选举状态始终是 LOOKING 状态2、服务器 2 启动，它与最开始启动的服务器 1 进行通信，互相交换本人的选举后果，因为 两者都没有历史数据，所以 id 值较大的服务器 2 胜出，然而因为没有达到超过半数以上的服务器都批准选举它(这个例子中的半数以上是 3)，所以服务器 1、2 还是持续放弃 LOOKING 状态3、服务器 3 启动，依据后面的实践剖析，服务器 3 成为服务器 1,2,3 中的老大，而与下面不 同的是，此时有三台服务器(超过半数)选举了它，所以它成为了这次选举的 leader4、服务器 4 启动，依据后面的剖析，实践上服务器 4 应该是服务器 1,2,3,4 中最大的，然而 因为后面曾经有半数以上的服务器选举了服务器 3，所以它只能接管当小弟的命了5、服务器 5 启动，同 4 一样，当小弟

1.Zookeeper概述与部署更新中

一.Zookeepr概述1.1 Zookeeper介绍介绍Zookeeper之前，先说这样一个场景。假设有三台服务器A、B、C组成的分布式系统，在A机器上有一个资源RS，A、B、C三个服务器上的过程都要竞争这个资源，而因为业务须要，同一个时刻，只能有一个过程拜访该资源，那么如何去做？那就加锁lock，当A的过程拜访到RS资源时，加上一把锁lock，使得其余过程不能再拜访该资源，而A用完RS资源，开释掉这把锁lock，其余过程又能拜访资源RS，但只有拜访到，就同样加锁，用完开释锁。在这个分布式系统中的锁，称之为分布式锁，也是分布式协调服务的外围。 Zookeeper就是一个分布式，开源的为分布式提供协调服务的一个Apache的我的项目。它是基于观察者设计模式的分布式服务治理框架，它负责存储管理相干数据，承受观察者的注册，当这些数据状态产生扭转，Zookeeper就负责告诉注册过的观察者做出反馈。 Zookeeper提供这些服务次要通过其文件系统和监听机制。 1.2 Zookeeper利用场景对立集群治理、配置管理、队列治理、分布式服务的同步、负载平衡等等。 二.Zookeeper 数据结构Zookeeper的数据结构和Unix的文件系统很类似，如下图 整体能够看成一个树，树中每一个节点都是叫做Znode。 3.1 Znode类型长久节点：客户端和服务器断开连接后，创立的节点不会删除，仍然存在长期节点：顾名思义，长期节点在客户端与服务器端会话断开后，节点就会删除创立znode时设置程序标识，znode名称后会附加一个值，顺序号是一个枯燥递增的计数器，由父节点保护 2.1 Znode组成Znode蕴含三局部内容： 1.stat：状态信息, 形容该Znode的版本, 权限等，具体如下表属性形容czxid创立节点的事务zxid，每次批改ZooKeeper状态都会收到一个zxid模式的工夫戳，也就是ZooKeeper事务ID。事务ID是ZooKeeper中所有批改总的秩序。每个批改都有惟一的zxid，如果zxid1小于zxid2，那么zxid1在zxid2之前产生。ctimeznode被创立的毫秒数(从1970年开始)mzxidznode最初更新的事务zxidmtimeznode最初批改的毫秒数(从1970年开始)pZxidznode最初更新的子节点zxidcversionznode子节点变动号，znode子节点批改次数dataversionznode数据变动号aclVersionznode访问控制列表的变动号ephemeralOwner如果是长期节点，这个是znode拥有者的session id。如果不是长期节点则是0。dataLengthznode的数据长度numChildrenznode子节点数量2.data：与该Znode关联的数据，但最多为1M，通常应用远远小于这个值。且数据操作为原子性，一次数据操作要么胜利，要么失败。3.children：子节点三.Zookeeper 装置部署3.1.分布式装置1）后期布局我这里有三台hadoop集群 主机名IP 地址hadoop10192.168.122.10hadoop11192.168.122.11hadoop12192.168.122.12在hadoop10、hadoop11、hadoop12上部署Zookeeper上传压缩包zookeeper-3.5.7.tar.gz至三个节点下 2）解压文件sudo tar -zxvf zookeeper-3.5.7.tar.gz -C /opt/// 因为我所有操作都是用v2admin去做，所以改下所属用户和组sudo chown v2admin:v2admin -R /opt/zookeeper-3.5.73)创立服务器编号文件并配置服务器编号cd /opt/zookeeper-3.5.7mkdir zkIdcd zkIdecho 10 > server_id// 另外两节点设置为 11 124)配置zoo.cfgcd /opt/zookeeper-3.5.7/confcp zoo_sample.cfg zoo.cfgvim zoo.cfg===============# 批改数据存储门路，就是服务器编号的门路dataDir=/opt/zookeeper.3.5.7/zkId# 减少如下内容server.10=hadoop10:2888:3888server.11=hadoop11:2888:3888server.12=hadoop12:2888:3888============-5)启动脚本当然能够挨个启动服务bin/zKserver.sh start，但要是更多的服务器，那就太麻烦了。vim zk_server.sh #!/bin/bashif [ $# -lt 1 ]then echo Not enough Argsfifor i in hadoop10 hadoop11 hadoop12docase $1 in"start") echo "====================start $i zookeeper============" ssh v2admin@$i /opt/module/zookeepr-3.5.7/bin/zkServer.sh start;;"status") echo "====================status $i ==================" ssh v2admin@$i /opt/module/zookeepr-3.5.7/bin/zkServer.sh status;;"stop") echo "=================stop $i ==================" ssh v2admin@$i /opt/module/zookeepr-3.5.7/bin/zkServer.sh stop;;*) echo "Args Error"esacdone赋予脚本执行权限 ...

什么是 ZooKeeperZooKeeper 是 Apache 的一个顶级我的项目，为分布式应用提供高效、高可用的分布式协调服务，提供了诸如数据公布/订阅、负载平衡、命名服务、分布式协调/告诉和分布式锁等分布式根底服务。因为 ZooKeeper 便捷的应用形式、卓越的性能和良好的稳定性，被宽泛地利用于诸如 Hadoop、HBase、Kafka 和 Dubbo 等大型分布式系统中。 Zookeeper有三种运行模式：单机模式、伪集群模式和集群模式。 单机模式：这种模式个别实用于开发测试环境，一方面咱们没有那么多机器资源，另外就是平时的开发调试并不需要极好的稳定性。集群模式：一个 ZooKeeper 集群通常由一组机器组成，个别 3 台以上就能够组成一个可用的 ZooKeeper 集群了。组成 ZooKeeper 集群的每台机器都会在内存中保护以后的服务器状态，并且每台机器之间都会相互放弃通信。伪集群模式：这是一种非凡的集群模式，即集群的所有服务器都部署在一台机器上。当你手头上有一台比拟好的机器，如果作为单机模式进行部署，就会浪费资源，这种状况下，ZooKeeper 容许你在一台机器上通过启动不同的端口来启动多个 ZooKeeper 服务实例，以此来以集群的个性来对外服务。ZooKeeper 的相干常识Zookeeper中的角色： 领导者（leader）：负责进行投票的发动和决定，更新零碎状态。跟随者（follower）：用于接管客户端申请并给客户端返回后果，在选主过程中进行投票。观察者（observer）：能够承受客户端连贯，将写申请转发给 leader，然而observer 不加入投票的过程，只是为了扩大零碎，进步读取的速度。Zookeeper 的数据模型层次化的目录构造，命名合乎惯例文件系统标准，相似于 Linux。每个节点在 Zookeeper 中叫做 Znode，并且其有一个惟一的门路标识。节点 Znode 能够蕴含数据和子节点，然而 EPHEMERAL 类型的节点不能有子节点。Znode 中的数据能够有多个版本，比方某一个门路下存有多个数据版本，那么查问这个门路下的数据就须要带上版本。客户端利用能够在节点上设置监视器。节点不反对局部读写，而是一次性残缺读写。ZooKeeper 的节点个性ZooKeeper节点是生命周期的，这取决于节点的类型。在 ZooKeeper 中，节点依据持续时间能够分为长久节点（PERSISTENT）、长期节点（EPHEMERAL），依据是否有序能够分为程序节点（SEQUENTIAL）、和无序节点（默认是无序的）。 长久节点一旦被创立，除非被动移除，不然始终会保留在 Zookeeper 中（不会因为创立该节点的客户端的会话生效而隐没）。 Zookeeper 的利用场景ZooKeeper 是一个高可用的分布式数据管理与零碎协调框架。基于对 Paxos 算法的实现，使该框架保障了分布式环境中数据的强一致性，也正是基于这样的个性，使得 ZooKeeper 解决很多分布式问题。 值得注意的是，ZooKeeper 并非天生就是为这些利用场景设计的，都是起初泛滥开发者依据其框架的个性，利用其提供的一系列 API 接口（或者称为原语集），摸索进去的典型应用办法。 数据公布与订阅（配置核心）公布与订阅模型，即所谓的配置核心，顾名思义就是发布者将数据公布到 ZooKeeper 节点上，供订阅者动静获取数据，实现配置信息的集中式治理和动静更新。例如全局的配置信息，服务式服务框架的服务地址列表等就非常适合应用。 利用中用到的一些配置信息放到 ZooKeeper 上进行集中管理。这类场景通常是这样：利用在启动的时候会被动来获取一次配置，同时在节点上注册一个 Watcher。这样一来，当前每次配置有更新的时候，都会实时告诉到订阅的客户端，素来达到获取最新配置信息的目标。 分布式搜寻服务中，索引的元信息和服务器集群机器的节点状态寄存在 ZooKeeper 的一些指定节点，供各个客户端订阅应用。 ...

概述这篇blog次要探讨常见的分布式一致性算法： paxoszab (zookeeper atomic broadcast)raftgossip重点在于比照这些算法的相同点和差别。思考算法的设计和取舍. paxospaxos是最早提出的分布式一致性算法.见http://lamport.azurewebsites.... 重要概念Roles实际中, 节点往往同时承载proposer/acceptors/learner的性能. proposer提案人，A proposer sends a proposed value to a set of acceptors. 能够了解为能够执行写入的master节点。留神paxos协定并没有限度Proposer的数量. 在实践中为了防止核心节点生成全序proposal number的单点故障, 应用了选主协定. 参考上面的leader. leader见论文的第三节：Implementing a State Machine必须有一个核心节点生成全序的 proposal number. 被选为主节点的proposer才可发动proposal.In normal operation, a single server is elected to be the leader, which acts as the distinguished proposer (the only one that tries to issue proposals) in all instances of the consensus algorithm. acceptors投票人，An acceptor may accept the proposed value. 即形成majority或quorum的节点。 ...

Zookeeper 是一个分布式服务框架，次要是用来解决分布式应用中遇到的一些数据管理问题如：对立命名服务、状态同步服务、集群治理、分布式应用配置项的治理等。 咱们能够简略把 Zookeeper 了解为分布式家庭的大管家，那么管家团队是如何选出Leader的呢？好奇吗，接下来率领大家一探到底。 人类选举的基本原理解说 Zookeeper 选举过程前先来介绍一下人类的选举。 咱们每个人或多或少都经验过几次选举，在投票的过程中可能会遇到这样几种状况： 状况1：本人与几个候选人都比拟熟，你会将票投给你认为能力比拟强的人； 图片 状况2：本人也是候选人，并且与其余几个候选人都不熟，这个时候你必定想着要去拉票，因为感觉本人才是最厉害的人呀，所有人都应该把票投给我。然而遗憾的是在拉票的过程中，你发现他人比你强，你开始自大了，最终还是把票投给了本人认为最强的人。 图片 所有人都投完票之后，最初从投票箱中进行统计，取得票数最多的人入选。 图片 在整个投票过程中咱们能够提炼出四个最外围的概念： 候选人能力：投票的根本准则是选最强的人。遇强改投：如果前面发现更强的人能够改投票。投票箱：所有人的票都会放在投票箱。领导者：得票最多的人即为领导者。从人类选举的原理咱们来简略推导一下Zookeeper的选举原理。 Zookeeper选举的基本原理留神如果 Zookeeper 是单机部署是不须要选举的，集群模式下才须要选举。Zookeeper 的选举原理和人类选举的逻辑相似，套用一下人类选举的四个基本概念具体解释一下Zookeeper。 集体能力如何掂量 Zookeeper 节点集体能力？答案是靠数据是否够新，如果节点的数据越新就代表这个节点的集体能力越强，是不是感觉很奇怪，就是这么定的！ 在 Zookeeper 中通常是以事务id（前面简称zxid）来标识数据的新旧水平（版本），节点最新的zxid越大代表这个节点的数据越新，也就代表这个节点能力越强。 zxid 的全称是 ZooKeeper Transaction Id，即 Zookeeper 事务id。遇强改投在集群选举开始时，节点首先认为本人时最强的（即数据是最新的），而后在选票上写上本人的名字（包含zxid和sid），zxid 是事务id，sid 惟一标识本人。 紧接着会将选票传递给其余节点，同时本人也会接管其余节点传过来的选票。每个节点接管到选票后会做比拟，这个人是不是比我强（zxid比我大），如果比拟强，那我就须要改票，明明他人比我强，我也不能厚着脸皮对吧。 投票箱与人类选举投票箱略微有点不一样，Zookeeper 集群会在每个节点的内存中保护一个投票箱。节点会将本人的选票以及其余节点的选票都放在这个投票箱中。因为选票时相互传阅的，所以最终每个节点投票箱中的选票会是一样的。 领导者在投票的过程中会去统计是否有超过一半的选票和本人抉择的是同一个节点，即都认为某个节点是最强的。一旦集群中有超过半数的节点都认为某个节点最强，那该节点就是领导者了，投票也宣告完结。 什么场景下 Zookeeper 须要选举？当 Zookeeper 集群中的一台服务器呈现以下两种状况之一时，须要进入 Leader 选举。 （1）服务器初始化启动。 （2）服务器运行期间 Leader 故障。 启动期间的 Leader 选举假如一个 Zookeeper 集群中有5台服务器，id从1到5编号，并且它们都是最新启动的，没有历史数据。 图片 假如服务器顺次启动，咱们来剖析一下选举过程： （1）服务器1启动 发动一次选举，服务器1投本人一票，此时服务器1票数一票，不够半数以上（3票），选举无奈实现。 投票后果：服务器1为1票。 服务器1状态放弃为LOOKING。 ...

关注“Java后端技术全栈” 回复“面试”获取全套面试材料 分布式系统和利用，不仅能提供更强的计算能力，还能为咱们提供更好的容灾性和扩展性。 而ZooKeeper以Fast Paxos算法为根底，同时为了解决活锁问题，对Fast Paxos算法进行了优化，因而能够宽泛用于大数据之外的其余分布式系统，为大型分布式系统提供牢靠的合作解决性能。 ZooKeeper相干简介： ZooKeeper是Google的Chubby我的项目的开源实现，它已经作为Hadoop的子项目，在大数据畛域失去广泛应用。 ZooKeeper基于分布式计算的外围概念而设计，次要目标是给开发人员提供一套容易了解和开发的接口，从而简化分布式系统构建的工作。 ZooKeeper的设计保障了其健壮性，这就使得利用开发人员能够更多关注利用自身的逻辑，而不是协同工作上。 ZooKeeper从文件系统API失去启发，提供一组简略的API，使得开发人员能够实现通用的合作工作，包含选举主节点、治理组内成员关系、治理元数据等。 ZooKeeper包含一个利用开发库（次要提供Java和C两种语言的API）和一个用Java实现的服务组件。ZooKeeper的服务组件运行在一组专用服务器之上，实现的服务组件。 最近很多小伙伴问我要一些 ZooKeeper相干的材料，于是我翻箱倒柜，找到了这本十分经典的电子书——《ZooKeeper分布式过程协同技术详解》。 材料介绍 《ZooKeeper分布式过程协同技术详解》从论述ApacheZooKeeper这类零碎的设计目标和动机开始，介绍基本概念和根本组成模块，继而论述开发人员所须要把握的ZooKeeper库调用办法和编程技巧，此外，还介绍了ZooKeeper外部原理及如何运行ZooKeeper。适宜所有对ZooKeeper感兴趣的读者浏览。 如何获取？ 辨认二维码并关注公众号「Java后端技术全栈」；在公众号后盾回复关键字「859」

日期作者版本备注2020-06-12丁斌v1.0 Zookeeper，简称zk, 作为解决分布式一致性问题的成熟开源技术栈曾经被宽泛应用。本文用简短精炼的篇幅迅速阐述一下zookeeper集群的装置部署和应用办法。 留神： 装置zookeeper之前须要在每台机器上装置好jdk，倡议装置至多jdk1.8及以上版本。本文装置的是jdk1.8。本文应用的zookeeper版本是以后最新的zookeeper 3.6.1版本。相干程序安装包和开源java工程源代码链接是：zookeeper3.6.1package.rar 提取码: fmw2其中zookeeper JAVA API用法demo源码在esproj.zip文件中java工程的zk目录下。如下2图所示：1. Zookeeper技术简介ZooKeeper是一个分布式的，开放源码的分布式应用程序协调服务，是Google的Chubby一个开源的实现，是Hadoop和Hbase的重要组件。它是一个为分布式应用提供一致性服务的软件，提供的性能包含：配置保护、域名服务、分布式同步、组服务等。 ZooKeeper的指标就是封装好简单易出错的要害服务，将简略易用的接口和性能高效、性能稳固的零碎提供给用户。 ZooKeeper蕴含一个简略的原语集，提供Java和C的接口。 ZooKeeper代码版本中，提供了分布式独享锁、选举、队列的接口，其中散布锁和队列有Java和C两个版本，选举只有Java版本。 原理ZooKeeper是以Fast Paxos算法为根底的，Paxos 算法存在活锁的问题，即当有多个proposer交织提交时，有可能相互排挤导致没有一个proposer能提交胜利，而Fast Paxos作了一些优化，通过选举产生一个leader (领导者)，只有leader能力提交proposer，具体算法可见Fast Paxos。因而，要想弄懂ZooKeeper首先得对Fast Paxos有所理解。 ZooKeeper的根本运行流程： 1、选举Leader。2、同步数据。3、选举Leader过程中算法有很多，但要达到的选举规范是统一的。4、Leader要具备最高的执行ID，相似root权限。5、集群中大多数的机器失去响应并follow选出的Leader。特点在Zookeeper中，znode是一个跟Unix文件系统门路类似的节点，能够往这个节点存储或获取数据。如果在创立znode时Flag设置为EPHEMERAL，那么当创立这个znode的节点和Zookeeper失去连贯后，这个znode将不再存在在Zookeeper里，Zookeeper应用Watcher觉察事件信息。当客户端接管到事件信息，比方连贯超时、节点数据扭转、子节点扭转，能够调用相应的行为来解决数据。Zookeeper的Wiki页面展现了如何应用Zookeeper来处理事件告诉，队列，优先队列，锁，共享锁，可撤销的共享锁，两阶段提交。 那么Zookeeper能做什么事件呢，简略的例子：假如咱们有20个搜索引擎的服务器(每个负责总索引中的一部分的搜寻工作)和一个总服务器(负责向这20个搜索引擎的服务器收回搜寻申请并合并后果集)，一个备用的总服务器(负责当总服务器宕机时替换总服务器)，一个web的cgi(向总服务器收回搜寻申请)。搜索引擎的服务器中的15个服务器提供搜寻服务，5个服务器正在生成索引。这20个搜索引擎的服务器常常要让正在提供搜寻服务的服务器进行提供服务开始生成索引，或生成索引的服务器曾经把索引生成实现能够提供搜寻服务了。应用Zookeeper能够保障总服务器主动感知有多少提供搜索引擎的服务器并向这些服务器收回搜寻申请，当总服务器宕机时主动启用备用的总服务器。 2. Zookeeper集群疾速搭建从zookeeper官网https://zookeeper.apache.org/releases.html 下载以后最新版本的zookeeper3.6.1。 分布式zookeeper(简称zk)集群至多要求运行在3台或以上服务器上。本文讲述是基于装置在3台vmware虚拟机上，各虚拟机机器结点如下表：本节应用的所有vmware虚拟机配置均为CPU：8核，内存6G，硬盘足够。 依据咱们一贯部署分布式服务的做法：1） 先创立zk用户和zk组； groupadd zkvim /etc/group 会发现最初一行有zk用户组adduser -g zk zk创立zk用户，同时退出zk用户组，主动创立zk的homedir为/home/zkvim /etc/passwd 能够看到最初一行是zk用户。passwd zk为zk用户新设立明码将zk用户退出sudo权限留神：本步骤非必须，可选。chmod +w /etc/sudoersvim /etc/sudoers增加如下行： 而后再chmod -w /etc/sudoers2） 创立zk服务的basedir：/opt/zk chown -R zk:zk /opt/zk3） 在/opt/zk下别离创立app data logs temp别离作为zk的app/data/logs/temp 目录。 4） 配置zk 解压zk压缩包文件：apache-zookeeper-3.6.1-bin.tar.gz 到/opt/zk/app目录下：在cent7a机器上执行： cd /opt/zk/app/apache-zookeeper-3.6.1-bin/confmv zoo_sample.cfg zoo.cfgvim zoo.cfg 批改如下：其中clientPort 2181是客户端连贯zk集群的端口，dataDir和dataLogDir别离是数据目录和日志目录。文件最初的3行是用于zk集群互联。 ...

zookeeper官网文档摘抄 1. ZooKeeper Watches->ZooKeeper中的所有读取操作:(All of the read operations in ZooKeeper): getData(), getChildren(), and exists() - have the option of setting a watch as a side effect. getData(), getChildren(), and exists() - 能够有抉择的设置一个watch作为一个副作用Here is ZooKeeper's definition of a watch: a watch event is one-time trigger, sent to the client that set the watch, which occurs when the data for which the watch was set changes. 以下是ZooKeeper对 watch 的定义:watch事件是一次性触发的，发送给设置watch的客户端，当watch所设置的数据发生变化时，就会产生watch事件。1.2 在这个watch的定义中，有三个关键点须要思考：There are three key points to consider in this definition of a watch: ...

1.zookeper包上传文件上传：上传： scp localpath username@ip:remotepath文件下载：scp -r remote_username@remote_ip:remote_folder local_folder scp /Users/xiexinming/software/package/zookeeper-3.4.9.tar.gz root@10.1.200.244:/usr/local/2.zookeper解压批改名称1、解压 tar -zxvf zookeeper-3.4.9.tar.gz 2、删除jar包，而后重命名 3.配置环境变量vi ~/.bashrc export ZOOKEEPER_HOME=/usr/local/zookeeper export PATH=$PATH:$ZOOKEEPER_HOME/bin source ~/.bashrc 4.批改配置文件拷贝一份曾经存在的样本文件，而后进行编辑 进入zookeeper的配置文件中: cd ./zookeeper/conf 咱们在/opt下新建目录：zookeeper 而后咱们批改zookeeper的配置文件。 mkdir /opt/zookeeper/datamkdir /opt/zookeeper/log批改外面的根本配置文件: dataDir=/opt/zookeeper/datadataLogDir=/opt/zookeeper/logserver.1=centos01:2888:3888server.2=centos02:2888:3888 设置zookeeper的id 进入zookeeper的data目录中去，设置他的id cd /opt/zookeeper/data echo 1 > myid下面myid外面内容为1，代表的是以后zookeeper机器编号。 5.其余机器zookeeper配置scp -r /usr/local/zookeeper centos02:/usr/local ，批改环境变量，在centos02将myid的内容改为2 （echo 2 > myid）scp -r /usr/local/zookeeper centos03:/usr/local，批改环境变量，在centos03将myid的内容改为3 （echo 3 > myid）在另一台机器查看: 批改环境变量： vi ~/.bashrc export ZOOKEEPER_HOME=/usr/local/zookeeper export PATH=$PATH:$ZOOKEEPER_HOME/bin source ~/.bashrc设置zookeeper的id 进入zookeeper的data目录中去，设置他的id ...

1. zookeeper1.1. 根底ZooKeeper是一个分布式的，开放源码的分布式应用程序协调服务，它蕴含一个简略的原语集，分布式应用程序能够基于它实现同步服务，配置保护和命名服务等。很多中间件，比方kafka、hadoop、hbase，都用到了 Zookeeper来构建集群。Zookeeper是hadoop的一个子项目，其倒退历程无需赘述。在分布式应用中，因为工程师不能很好地应用锁机制，以及基于音讯的协调机制不适宜在某些利用中应用，因而须要有一种牢靠的、可扩大的、分布式的、可配置的协调机制来对立零碎的状态。Zookeeper的目标就在于此。 数据结构了解ZooKeeper的一种办法是将其看做一个具备高可用性的文件系统。但这个文件系统中没有文件和目录，而是对立应用节点（node）的概念，称为znode。znode既能够保留数据（如同文件），也能够保留其余znode（如同目录）。所有的znode形成一个层次化的数据结构，。 Persistent Nodes: 永恒无效地节点,除非client显式的删除,否则始终存在Ephemeral Nodes: 长期节点,仅在创立该节点client放弃连贯期间无效,一旦连贯失落,zookeeper会主动删除该节点Sequence Nodes: 程序节点,client申请创立该节点时,zk会主动在节点门路开端增加递增序号,这种类型是实现分布式锁,分布式queue等非凡性能的要害集群生产环境的zookeeper服务，个别都是以集群的形式搭建环境。在zookeeper集群中，不同节点个别有上面几种角色： Leader：事务申请的惟一调度者和解决者。保障集群事务处理的程序性。集群外部各服务器的调度者。Follower：解决客户端非事务申请，转发事务申请给Leader。参加事务申请Proposal的投票。参加Leader选举投票。Observer：解决非事务申请，将事务申请交给Leader解决。可见在zookeeper集群中，真正决策的只有一个Leader节点，所有的事务申请达到其余节点后，都还是会被转发到Leader节点来解决。这种模式，保障了zookeeper在命令决策端的原子性。 Leader选举算法采纳了Paxos协定，当少数Server写胜利，则工作数据写胜利如果有3个Server，则两个写胜利即可；如果有4或5个Server，则三个写胜利即可。Server数目个别为奇数（3、5、7）如果有3个Server，则最多容许1个Server挂掉；如果有4个Server，则同样最多容许1个Server挂掉由此，咱们看出3台服务器和4台服务器的的容灾能力是一样的，所以为了节俭服务器资源，个别咱们采纳奇数个数，作为服务器部署个数。 原子播送zookeeper的外围是原子播送，这个机制保障了各个server之间的同步。实现这个机制的协定叫做Zab协定。Zab协定有两种模式，它们别离是恢复模式和播送模式。 当服务启动或者在领导者解体后，Zab就进入了恢复模式，当领导者被选举进去，且大多数server的实现了和leader的状态同步当前，恢复模式就完结了。状态同步保障了leader和server具备雷同的零碎状态。一旦leader曾经和少数的follower进行了状态同步后，他就能够开始播送音讯了，即进入播送状态。 数据一致性与paxos算法在一个分布式数据库系统中，如果各节点的初始状态统一，每个节点都执行雷同的操作序列，那么他们最初能失去一个统一的状态。 Paxos算法通过投票来对写操作进行全局编号，同一时刻，只有一个写操作被批准，同时并发的写操作要去争取选票，只有取得过半数选票的写操作才会被批准（所以永远只会有一个写操作失去批准），其余的写操作竞争失败只好再发动一轮投票，就这样，在日复一日年复一年的投票中，所有写操作都被严格编号排序。 编号严格递增，当一个节点承受了一个编号为100的写操作，之后又承受到编号为99的写操作（因为网络提早等很多不可预感起因），它马上能意识到本人数据不统一了，主动进行对外服务并重启同步过程。任何一个节点挂掉都不会影响整个集群的数据一致性（总2n+1台，除非挂掉大于n台）。 老手不要混同，在这里的投票选举是针对多个客户端有并发写操作时，抢夺该惟一写操作权的选举。和后面说的zookeeper集群中，投票选举master是不同的概念。尽管它们的选举协定，都是遵循paxos算法。 1.2. 装置应用docker 装置这里间接应用zookeeper官网镜像来装置。 docker run -d \ --name zookeeper \ --restart=on-failure:3 \ -p 2181:2181 \ -v /Volumes/zookeeper/data/:/data/ \ zookeeper启动执行 docker exec -it 编号 /bin/bash ，进入容器外部。 而后在 /bin 目录，执行 ./zkCli.sh ，运行启动脚本。 zooInspector客户端zooInspector是zookeeper图形化的客户端工具，可用来查看外部数据状况。 可下载 ZooInspector.zip，解压后在build目录下获取 zookeeper-dev-ZooInspector.jar。通过 java -jar zookeeper-dev-ZooInspector.jar，即可启动 ZooInspector 图形化客户端。 2. CAP比照2.1. CAP实践CAP实践通知咱们，一个分布式系统不可能同时满足以下三种： 一致性（C:Consistency）可用性（A:Available）分区容错性（P:Partition Tolerance）这三个根本需要，最多只能同时满足其中的两项，因为P是必须的,因而往往抉择就在CP或者AP中。 一致性（C:Consistency）在分布式环境中，一致性是指数据在多个正本之间是否可能保持数据统一的个性。在一致性的需要下，当一个零碎在数据统一的状态下执行更新操作后，应该保证系统的数据依然处于统一的状态。例如一个将数据正本散布在不同分布式节点上的零碎来说，如果对第一个节点的数据进行了更新操作并且更新胜利后，其余节点上的数据也应该失去更新，并且所有用户都能够读取到其最新的值，那么这样的零碎就被认为具备强一致性（或严格的一致性，最终一致性）。 可用性（A:Available）可用性是指零碎提供的服务必须始终处于可用的状态，对于用户的每一个操作申请总是可能在无限的工夫内返回后果。“无效的工夫内”是指，对于用户的一个操作申请，零碎必须可能在指定的工夫（即响应工夫）内返回对应的处理结果，如果超过了这个工夫范畴，那么零碎就被认为是不可用的。 ...

前言这里是zookeeper响应式编程的第二篇——自定义分布式锁，第一篇zookeeper分布式注册配置核心见如下链接：https://segmentfault.com/a/11...分布式锁因为在分布式系统中，任意2个节点的线程须要获取同一个资源的时候就须要锁来维持程序的正确运行，然而呢，如果应用JVM提供的锁只能锁住本人，因为这是2台主机，这就引入了分布式锁的概念。也即是说须要一把锁在主机的里面，而很多框架都能够实现分布式锁，比方redis,mysql和zookeeper,目前最为不便的是应用zookeeper，因为就其高可用性和对立视图而言就比其余的技术不便很多。 对于zookeeper做分布式锁的剖析过程如下：首先对于2台主机抢占同一把锁的时候，只能有一台主机胜利抢占，那么有可能呈现取得锁的主机“挂了”，那么咱们能够应用长期节点解决该问题，那么在一个主机胜利抢占该锁之后，如果它开释了锁，其余主机是如何晓得它曾经胜利开释了呢？第一种形式就是能够采纳被动轮询的形式一直检测该锁是否曾经被开释，然而这种形式有提早，并且在主机特地多的时候多台主机轮询一把锁会造成zookeeper很大的压力。第二种形式就是应用watch机制，这种形式能够解决提早的问题，然而在取得锁的主机开释锁的时候，zookeeper会回调哪些所有没有抢到锁的线程，而后那些主机又会发动强锁的操作，会造成较大的通信压力。第三种形式就能够应用watche机制+序列节点，而后让每一个长期序列节点都watch前一个节点，这样只有一个编号最小的能力取得锁，并且在开释锁后会只告诉前面的一个主机。 代码实现首选咱们须要在编写配置核心的Utils工具类，并且创立TestLock类实现分布式锁。而后咱们开拓10个线程模仿多台主机抢占锁的过程，根本流程就是抢占锁，而后执行业务代码(这里应用睡眠来代替)，最初再开释锁。 Utils代码如下：package org.qzx.config;import org.apache.zookeeper.ZooKeeper;import java.util.concurrent.CountDownLatch;/** * @Auther: qzx * @Date: 2020/10/29 - 10 - 29 - 1:02 下午 * @Description: org.qzx.config * @version: 1.0 */public class Utils { // zookeeper对象 private static ZooKeeper zooKeeper; // 连贯地址 private static String address = "10.211.55.5:2181,10.211.55.8:2181,10.211.55.9:2181,10.211.55.10:2181/test"; private static DefaultWatcher defaultWatcher = new DefaultWatcher(); // 锁 private static CountDownLatch latch = new CountDownLatch(1); public static ZooKeeper getZooKeeper() throws Exception{ zooKeeper = new ZooKeeper(address,3000,defaultWatcher); defaultWatcher.setLatch(latch); latch.await(); return zooKeeper; }}TestLock大体框架如下：package org.qzx.lock;import org.apache.zookeeper.ZooKeeper;import org.junit.After;import org.junit.Before;import org.junit.Test;import java.util.concurrent.TimeUnit;/** * @Auther: qzx * @Date: 2020/10/29 - 10 - 29 - 3:54 下午 * @Description: org.qzx.lock * @version: 1.0 */public class TestLock { private ZooKeeper zooKeeper; @Before public void conn() throws Exception { zooKeeper = Utils.getZooKeeper(); } @After public void close() throws InterruptedException { zooKeeper.close(); } @Test public void TestLock(){ for (int i = 0; i < 10; i++) { new Thread(()->{ try { // 抢占锁 // 业务代码 TimeUnit.SECONDS.sleep(1); System.out.println(Thread.currentThread().getName()+"is woorking!!!"); // 开释锁 } catch (InterruptedException e) { e.printStackTrace(); } }).start(); } }}咱们在这里提供另外一个工具类能够为每一个线程实现抢锁和开释锁的过程，同时因为抢占的锁实际上是zookeeper的长期序列节点，所以必定会应用wather和回调机制，这里就把这个工具类叫做MyWatcherAndCallBack,该类提供抢占锁、开释锁，节点变动回调办法。其大体框架如下： ...

前言因为本人最近在学习zookeeper分布式相干的常识，发现在其代码实现上存在较多难以想分明的点，尤其是响应式编程的操作，为此在这里记录残缺的代码书写流程(每一步的思维)，这里是第一篇zookeeper分布式注册配置核心的实现代码过程，前面还会有第二篇对于zookeeper分布式锁的简略实现过程。分布式注册配置核心zookeeper因为领有watcher机制，使得其领有公布订阅的性能，而公布与订阅模型，即所谓的配置核心，顾名思义就是发布者将数据公布到 ZK节点上，供订阅者动静获取数据，实现配置信息的集中式治理和动静更新。 利用在启动的时候会被动来获取一次配置，同时，在节点上注册一个 Watcher，这样一来，当前每次配置有更新的时候，都会实时告诉到订阅的客户端，素来达到获取最新配置信息的目标。 代码实现流程首选交代试验环境，本人的zookeeper的版本是3.5.8的版本，代码工具为IDEA，创立了一个MAVEN我的项目，仅仅增加了如下依赖。 <dependency> <groupId>org.apache.zookeeper</groupId> <artifactId>zookeeper</artifactId> <version>3.5.8</version></dependency>因为客户端须要与zookeeper建设连贯，获取数据，增加监控等等一系列的事件，所以这里封装一个Utils工具类供咱们应用。 而后对于zookeeper连贯客户端的地址的前面能够紧跟一个path，作为在根目录下的工作目录。该目录就是作为所有操作的根目录，这里应用/test、 同时因为zookeeper基于watch机制实现公布订阅，咱们所有的watcher都采纳自定义的形式实现，首先是对连贯胜利的时候的DefaultWatcher。 DefaultWatcher代码如下：package org.qzx.config;import org.apache.zookeeper.WatchedEvent;import org.apache.zookeeper.Watcher;/** * @Auther: qzx * @Date: 2020/10/29 - 10 - 29 - 1:05 下午 * @Description: org.qzx.config * @version: 1.0 */public class DefaultWatcher implements Watcher { @Override public void process(WatchedEvent event) { System.out.println(event.toString()); }}Utils工具类：package org.qzx.config;import org.apache.zookeeper.ZooKeeper;/** * @Auther: qzx * @Date: 2020/10/29 - 10 - 29 - 1:02 下午 * @Description: org.qzx.config * @version: 1.0 */public class Utils { // zookeeper对象 private static ZooKeeper zooKeeper; // 连贯地址 private static String address = "10.211.55.5:2181,10.211.55.8:2181,10.211.55.9:2181,10.211.55.10:2181/test"; private static DefaultWatcher defaultWatcher = new DefaultWatcher(); public static ZooKeeper getZooKeeper() throws Exception{ zooKeeper = new ZooKeeper(address,3000,defaultWatcher); return zooKeeper; }}因为zookeeper采纳的是异步调用，所以这里须要应用一把锁锁住主线程，在连贯胜利后主动解锁，主线程再往下进行。这里应用CountDownLatch实现锁，在主线程创立，传递到DafaultWatcher的回掉函数中。 ...

https://www.cnblogs.com/LOVE0612/p/9579751.htmldelete是删除子结点的权限

canal利用zookeeper进行服务协调，选举主节点，实现零碎的高可用，这里深刻理解zk，包含个性，实用场景和原理。 概述Zookeeper是一个分布式的协调服务。本质是提供了一个相似与linux的树形文件系统，客户端可增加子节点，对其赋值，监听节点变动。通过这些操作可实现不同的性能，包含服务发现，选主节点，分布式锁，命名服务等。 概念节点类型zk是一个树形构造，节点具备不同的个性，包含： 长期：与客户端会话生命周期雷同，如果客户端断开连接，长期节点被删除。长期节点不可设置子节点永恒：须要手动删除有序：按客户端拜访程序被zk调配有序的节点名称。可用于偏心锁的实现。无序订阅与告诉客户端可订阅节点，如果该节点被批改，删除或子节点变动，zk会告诉客户端相应变动。一旦变更被告诉，须要从新设置watch。利用watch机制可进行主节点选举。多个客户端竞争建设/leader长期节点，如果建设失败，订阅leader节点。如果主节点挂掉，会话隐没，leader节点被删除，此时订阅该leader的从节点竞争建设/leader长期节点，建设胜利的降职为主节点对外提供服务。失败的节点仍监听leader节点，负责从节点。利用节点的有序性可实现主节点的偏心选举或偏心锁。 会话会话即客户端维持与zk的一个长连贯。会话期间服务端向客户端收回心跳以表明客户端还存活。如果超时工夫内未检测到心跳，则开释会话，删除客户端建设的长期节点。如果客户端连贯的zk节点挂掉，会话会平移到失常提供服务的节点，客户端不会有感知。 事务zk会保障客户端的更新要么都胜利，要么都失败 ACLzk的权限管制 个性最终一致性：客户端不论连贯哪个server，最终会失去同样的视图。即集群内各个节点的状态最终是统一的。因为数据批改时，leader失去半数以上follower的ack即commit，因而有的节点数据更新会滞后，但最终会保持一致。可靠性：如果音讯被一台机器commit，最终会被所有机器commit。如果音讯在一台机器commit后，leader挂掉需从新选举leader。新leader规定是zxid最大，即领有最新commit数据的节点。原子性：更新只能胜利或失败，没有中间状态程序性：一台服务器上音讯a在音讯b前公布，则在所有Server上音讯a都将在音讯b前被公布；如果音讯a在音讯b前被同一个发送者公布，则a必将排在b后面。由zxid和队列保障。这些个性次要有zab协定保障。 场景：集群治理，主节点选举分布式锁服务发现配置核心分布式队列已应用的组件：Hadoop，hbase，dubbo，kafka，canal ZAB协定zab协定是zookeeper原子播送协定，规定了zk集群事务申请的解决形式以及如何保证数据一致性。应用Leader来接管并解决客户端的更新申请，通过二阶段提交的形式播送至所有的Follower。当leader解体时，由恢复模式不会影响曾经commit的数据。任意节点均可解决读申请。zab协定次要蕴含两种模式：恢复模式（选主+数据恢复）和播送模式（数据同步）。当服务初始化或者leader解体后，zookeeper会进入恢复模式选举leader，leader被选举进去后，将本身最新的数据同步至follower，恢复模式就完结了。播送模式应用2pc模式，保障leader和Server具备雷同的零碎状态。 Zk具备以下三种角色： Leader：一个集群中只有一个leader，维持和follower，observer的心跳，实现写读操作，写完后播送到其余节点Follower：实现读申请，将写申请转到leader，当一段时间接管不到心跳时进入选主状态Observer：和follower性能类似，但不能选主zk解决写申请zk解决读申请 原子播送模式：客户端申请zk服务，如果zk解决节点不是leader，则转发到leader进行写操作leader将事务申请转为proposal并为其调配全局惟一枯燥递增zxidleader为每个follower调配独自的队列，将proposal放入队列中，按FIFO准则异步发送至followfollower收到prososal后写入本地日志文件，写入胜利后响应ack给leader当leader收到半数folloer响应的ack后，会认为发送胜利，向follower发送commit音讯。同时响应给客户端后果follower收到commit后，会提交本地事务，数据更新胜利。留神： 原子播送模式规定zk如何解决数据更新事务。相似二阶段事务提交，但不同的是当超过半数follower ack后，leader即认为数据写入胜利并commit。可进步事务处理的性能。Leader 服务器与每一个 Follower 服务器之间都保护了一个独自的 FIFO 音讯队列进行收发音讯，做到异步解耦。如果应用同步的形式会引起阻塞，性能要降落很多。Zxid：zk对客户端的写申请转为proposal进行播送，leader为每次proposal调配全局惟一枯燥递增的事务ID，即zxid。Zxid是一个64为数字，低32位为枯燥递增的计数器，每次事务申请会自增1。高32位为epoch，代表leader周期，每新选举一次leader，epoch自增1表明进入新的leader周期，并将低32位清零。follower只会服从最高epoch的leader。zxid和FIFO队列保障事务的有序性。恢复模式会触发恢复模式的场景： Leader宕机集群初始化被分区的两个集群从新合并集群中不存在超过半数的服务器与Leader保留失常通信解体复原流程是主节点选举，数据恢复。新的主节点要求： 须要保障新的主节点的数据是最新的，即含有最大的 zxid，不能蕴含未提交的Proposal。之后将数据同步到其余节点，即数据恢复，以确保被一个节点commit的数据会被所有节点承受新选举进去的 Leader 不能蕴含未提交的 ProposalLeader 选举算法不仅仅须要让 Leader 本人晓得本人曾经被选举为 Leader ，同时还须要让集群中的所有其余机器也可能疾速感知到选举产生的新 Leader 服务器。步骤： 选举：Fast Leader Election（疾速选举）。选举领有最新Proposal history （lastZxid最大）的节点作为 Leader，成为 Leader 的条件： 选 epoch 最大的若 epoch 相等，选 zxid 最大的若 epoch 和 zxid 相等，抉择 server_id 最大的（zoo.cfg中的myid）复原：利用 Leader最新的Proposal历史，同步集群中所有的正本播送：到了这个阶段，Zookeeper 集群能力正式对外提供事务服务，并且 Leader 能够进行音讯播送。java客户端举荐应用curator 参考：zookeeper：https://www.jianshu.com/p/2bceacd60b8ahttps://dbaplus.cn/news-141-1875-1.htmlhttps://draveness.me/zookeeper-chubby/curator：https://www.jianshu.com/p/ae0c1fbbff3c

Zookeeper是Apache开源的一个分布式框架，它次要为分布式应用提供协调服务。 Zookeeper次要负责存储和治理大家都关怀的数据，一旦这些数据的状态发生变化，Zookeeper就会告诉那些注册在Zookeeper上的服务。简略来讲就是zookeeper=文件系统+告诉机制。 一 Zookeeper的数据结构Zookeeper的数据结构与Unix文件系统很相似，整体上能够看作是一棵树，与Unix文件系统不同的是Zookeeper的每个节点都能够存放数据，每个节点称作一个ZNode，默认存储1MB的数据，每个ZNode都能够通过其门路惟一标识。 1.1 四种类型的ZNode长久化目录节点：客户端与Zookeeper断开连接后，该节点仍旧存在。长久化程序编号目录节点：客户端与Zookeeper断开连接后，该节点仍旧存在，只是Zookeeper给该节点名称就行程序编号。长期目录节点：客户端与Zookeeper断开连接后，该节点被删除。长期程序编号目录节点：客户端与Zookeeper断开连接后，该节点被删除，只是Zookeeper给该节点名称就行程序编号。阐明：创立ZNode时设置程序标识，ZNode名称后会附加一个值，顺序号是一个枯燥递增的计数器，由父节点保护。 1.2 stat构造体ZNode次要蕴含以下信息： czxid-创立节点的事务 zxid：每次批改 ZooKeeper 状态都会收到一个 zxid 模式的工夫戳，也就是 ZooKeeper 事务 ID。 事务 ID 是 ZooKeeper 中所有批改总的秩序。每个批改都有惟一的 zxid，如果 zxid1 小于 zxid2，那么 zxid1 在 zxid2 之前产生。 ctime ：znode 被创立的毫秒数(从 1970 年开始)mzxid：znode 最初更新的事务 zxidmtime：znode 最初批改的毫秒数(从 1970 年开始)pZxid：znode 最初更新的子节点 zxidcversion：znode 子节点变动号，znode 子节点批改次数dataversion：znode 数据变动号aclVersion：znode 访问控制列表的变动号ephemeralOwner：如果是长期节点，这个是 znode 拥有者的 session id。如果不是长期节点则是 0 dataLength：znode 的数据长度numChildren：znode 子节点数量二 Zookeeper的利用场景Zookeeper的次要利用场景有对立命名服务，对立配置管理，对立集群治理，服务器节点动静高低线等。 2.1 对立命名服务在分布式环境中，常常须要对服务进行对立命名，如果有一个服务部署了2两个正本，间接调用具体的服务必定有些不适合，因为咱们并不分明哪个服务能够更快的解决咱们的申请，这时候咱们能够将这三个服务进行对立命名，而后其外部再去负载。这样就能够调用最优的那个服务了。 2.2 对立配置管理分布式环境下，配置文件的同步能够由Zookeeper来实现。 将配置文件写入Zookeeper的一个ZNode各个客户端服务监听这个ZNode一旦ZNode产生扭转，Zookeeper将告诉各个客户端服务 2.3 对立集群治理Zookeeper能够实现实时监控节点状态变动，当有一个三个节点的服务，如果其余一个宕机了，其余两个节点可立刻收到音讯，实现实时监控。将这三个节点写入Zookeeper的一个ZNode，每个节点都去监听这个ZNode，当ZNode发生变化时，这些节点可实时收到变动状态。 监听器的原理 创立一个Main()线程在Main()线程中创立两个线程，一个负责网络连接通信（connect），一个负责监听（listener）通过connect线程将注册的监听事件发送给Zookeeper将注册的监听事件增加到Zookeeper的注册监听器列表中Zookeeper监听到有数据或门路发生变化时，把这条音讯发送给Listener线程Listener线程外部调用process()办法三 Zookeeper集群Zookeeper集群尽管没有指定Master和Slave。然而，在Zookeeper工作时，会通过外部选举机制产生一个Leader节点，其余节点为Follower或者是Observer。 ...

简述在分布式环境下，为了保障在同一时刻只能有一个客户端对指定的数据进行拜访，须要应用分布式锁技术。分布式锁实现次要以Zookeeper、Redis、MySQL这三种。 分布式锁的特点互斥性：分布式锁须要保障在不同节点的不同线程的互斥。可重入性：同一个节点上的同一个线程如果获取了锁之后那么也能够再次获取这个锁。锁超时：和本地锁一样反对锁超时，避免死锁。高效：高可用:加锁和解锁须要高效，同时也须要保障高可用避免分布式锁生效，能够减少降级。反对阻塞和非阻塞：和ReentrantLock一样反对lock和trylock以及tryLock(long timeOut)。反对偏心锁和非偏心锁(可选)：偏心锁的意思是依照申请加锁的程序取得锁，非偏心锁就相同是无序的。这个一般来说实现的比拟少。ZooKeeper分布式锁 利用ZooKeeper实现分布式锁，罕用的实现办法是，所有心愿取得锁的客户端都须要执行以下操作： 客户端连贯ZooKeeper，调用create()办法在指定的锁节点（如/lock）下创立一个长期程序节点。 例如节点名为"zk"，则第一个客户端创立的节点为“/lock/zk00000000”，第二个客户端创立的节点为"/lock/zk00000001"客户端调用getChildren()办法查问锁节点/lock下的所有子节点列表，判断子节点列表中序号最小的子节点是否是本人创立的。如果是，则客户端取得锁，否则监听排在本人前一位的子节点的删除事件，若监听的子节点被删除，则反复执行此步骤，直至取得锁。客户端执行业务代码。客户端业务实现后，删除在ZooKeeper中对应的子节点以开释锁。问题 一、上述第一步为什么要创立长期节点？ 如果客户端A取得锁之后，客户端A所在的计算机宕机了，此时客户端A没有来得及被动删除子节点。如果创立的是永恒节点，锁将永远不会被开释，其余过程拿不到该资源。长期节点的益处：只管客户端宕机了，然而ZooKeeper在肯定工夫内没有收到客户端的心跳则会认为回话生效，而后长期节点删除以开释锁。二、未获取锁的客户端为什么要监听排在本人前一位的子节点的删除事件？ 依照抢夺锁的规定，每一轮锁的抢夺取的都是序号最小的节点，当序号最小的节点删除后，失常状况排在最小节点后一位的节点将取得锁。所以，客户端只须要监听本人前一位的节点即可，这样每当锁开释时，ZooKeeper只须要告诉一个客户端，从而节俭了网络带宽。若将监听事件设置在父节点/lock上，那么每次锁的开释将告诉所有客户端。如果客户端数量宏大，会导致ZooKeeper服务器必须解决的操作数量激增，减少了ZooKeeper服务器的压力，同时很容易产生网络阻塞。 以上内容整顿自《Hadoop大数据技术开发实战》

ZooKeeper中数据平时都在内存中通过一个叫ZkDataBase的类来治理保护的，同时ZooKeeper提供了Snapshot（快照）的形式能够将ZkDataBase长久化到磁盘，避免数据失落。 ZkDataBase通过DataTree保留整个树形数据结构。一个DataTree的每个节点是DataNode来示意。 以上就是ZooKeeper中的znode的数据结构了。 ZkDataBase读数据和写数据的实现逻辑都是通过DataTree实现的，次要包含getNode、getData、getACL、getChildren等操作接口。 构造示意： 图片转自：分布式服务框架 Zookeeper 治理分布式环境中的数据

引言行内在构建微服务平台时，选用了 Zookeeper 作为服务注册核心。 就分布式 CAP 定理而言，Zookeeper 做 CP，Eureka 做 AP，但其实是 AP 场景更适宜服务注册核心的高可用，可用性要比一致性更重要。 目前国内的 Zookeeper 遍及受影响于 Dubbo 的开源，阿里巴巴有一套本人的服务注册核心配合 Dubbo，但该服务注册核心却并未随 Dubbo 一起开源，主观环境限度下，Dubbo 官网举荐应用 Zookeeper 作为服务注册核心，这影响了一大批企业，尽管在起初阿里巴巴官网相干团队曾经公布文章不举荐应用 Zookeeper，但这就像流言和造谣一样，流言流传的范畴远远高于造谣信息的流传范畴。 阿里巴巴为什么不必 ZooKeeper 做服务发现？ - 阿里中间件团队博客 所以，如果不是非要用 Zookeeper 搭建服务注册核心的话，本文请选择性观看，就当做是一个对 Zookeeper 的理解学习就好。Zookeeper 依然是一款平凡的框架，当之无愧的分布式顶级我的项目，在数据一致性方面无可匹敌。 再次关上 Spring 官网，不由得感叹开源社区的平凡，在去年学习微服务时，仅有 Eureka、Zuul、Feign、Ribbon、Hystrix 等几个组件，现在曾经倒退至 30 多个开源组件；现在的 Spring Cloud，曾经反对 Zookeeper，成为业界最风行的微服务解决方案。 Zookeeper官网定义： ZooKeeper: A Distributed Coordination Service for Distributed Applications. Zookeeper：面向分布式应用的分布式协调服务。 装置Zookeeper下载地址：Releases - Apache Zookeeper 抉择一个稳固的 Release 版本下载： Zookeeper 采纳 Java 编写，运行 Zookeeper 之前须要配置 Java 环境。 ...

引言行内在构建微服务平台时，选用了 Zookeeper 作为服务注册核心。 就分布式 CAP 定理而言，Zookeeper 做 CP，Eureka 做 AP，但其实是 AP 场景更适宜服务注册核心的高可用，可用性要比一致性更重要。 目前国内的 Zookeeper 遍及受影响于 Dubbo 的开源，阿里巴巴有一套本人的服务注册核心配合 Dubbo，但该服务注册核心却并未随 Dubbo 一起开源，主观环境限度下，Dubbo 官网举荐应用 Zookeeper 作为服务注册核心，这影响了一大批企业，尽管在起初阿里巴巴官网相干团队曾经公布文章不举荐应用 Zookeeper，但这就像流言和造谣一样，流言流传的范畴远远高于造谣信息的流传范畴。 阿里巴巴为什么不必 ZooKeeper 做服务发现？ - 阿里中间件团队博客 所以，如果不是非要用 Zookeeper 搭建服务注册核心的话，本文请选择性观看，就当做是一个对 Zookeeper 的理解学习就好。Zookeeper 依然是一款平凡的框架，当之无愧的分布式顶级我的项目，在数据一致性方面无可匹敌。 再次关上 Spring 官网，不由得感叹开源社区的平凡，在去年学习微服务时，仅有 Eureka、Zuul、Feign、Ribbon、Hystrix 等几个组件，现在曾经倒退至 30 多个开源组件；现在的 Spring Cloud，曾经反对 Zookeeper，成为业界最风行的微服务解决方案。 Zookeeper官网定义： ZooKeeper: A Distributed Coordination Service for Distributed Applications. Zookeeper：面向分布式应用的分布式协调服务。 装置Zookeeper下载地址：Releases - Apache Zookeeper 抉择一个稳固的 Release 版本下载： Zookeeper 采纳 Java 编写，运行 Zookeeper 之前须要配置 Java 环境。 ...

从Paxos到Zookeeper 分布式一致性原理与实际 下载地址： https://pan.baidu.com/s/1Rq7FHUr-NooJ_CSXwG5E4g 扫码上面二维码关注公众号回复100015 获取分享码 本书目录构造如下: 一、概念 · 二、一致性协调 · 2.1 2PC (Two-Phase Commit) · 前提 · 根本算法 · 算法示意 · 毛病 · 2.2 3PC (Three-Phase Commit) · 根本算法 · 1.CanCommit阶段 · 2.PreCommit阶段 · 3.DoCommit阶段 · 算法示意 · 2PC和3PC区别 · 优缺点 · 2.3 Paxos（解决单点问题） · Paxos算法原理 · Paxos算法过程 · 三、Zookeeper · 3.1、初识Zookeeper · 3.1.1 zookeeper能够保障如下分布式一致性个性 · 3.1.2 zookeeper的四个设计指标 · 3.1.3 zookeeper的基本概念 · 1、集群角色 · 2、会话 ...

客户端抉择zookeeper的Java客户端次要有zkclient和Curator，此篇文章介绍Curator，就冲他官网的简介，zookeeper书的作者Patrick Hunt给了这么高的评估：Guava is to Java what Curator is to Zookeeper。 实际操作下来，Curator的确比zkclient更全面，代码编写也更加优雅。 引入jar包Curator次要提供了三个包 curator-framework：对zookeeper操作的封装curator-client：提供了一些客户端的操作curator-recipes：封装了一些高级个性咱们能够间接援用curator-recipes，它外面蕴含了其余两个jar包，然而要留神zookeeper的版本，官网中给出了上面提醒： 基本操作客户端实例的创立第一种 ExponentialBackoffRetry retry = new ExponentialBackoffRetry(1000, 3);CuratorFramework client = CuratorFrameworkFactory.newClient("127.0.0.1:2181", retry);retry是重试策略，间隔时间是2的指数增长，比方第一次期待1s，第二次2s，第三次4s。。。 第一个参数是距离根底单位，原始是毫秒；第二个参数是重试次数。 CuratorFrameworkFactory.newClient创立客户端，传入zookeeper的连贯地址和重试策略。 第二种 ExponentialBackoffRetry retry = new ExponentialBackoffRetry(1000, 3);CuratorFramework client = CuratorFrameworkFactory.builder() .connectString("123.206.212.170:2181") .connectionTimeoutMs(10000) .sessionTimeoutMs(10000) .retryPolicy(retry).build();重试策略和下面一样，客户端通过CuratorFrameworkFactory.builder()创立，connectionTimeoutMs示意连贯超时工夫，sessionTimeoutMs示意会话超时工夫。 创立节点CuratorFramework client = client();client.start();String path = "/demo/curd/node-2";client.create() .creatingParentsIfNeeded() .withMode(CreateMode.PERSISTENT) .forPath(path, "world".getBytes("utf-8"));client.close();curator的操作方法，根本都是链式调用，比起zkclient要优雅很多； creatingParentsIfNeeded()示意如果父节点没有，就一起创立； withMode(CreateMode.PERSISTENT)是创立的节点类型，zookeeper的节点有四种类型： PERSISTENT：长久化节点PERSISTENT_SEQUENTIAL：长久化程序节点EPHEMERAL：长期节点EPHEMERAL_SEQUENTIAL：长期程序节点最初.forPath设置创立的节点门路和节点携带的内容。创立后果能够通过IDEA的zookeeper插件可视化查看，插件装置办法自行百度。 删除节点CuratorFramework client = client();client.start();String path = "/demo/curd/node-2";client.delete().forPath(path);client.close();删除节点调用delete办法即可。 批改节点CuratorFramework client = client();client.start();String path = "/demo/curd/node-1";client.setData().forPath(path, "hello world".getBytes("utf-8"));client.close();批改节点调用setData()办法，前面forPath办法传入批改后的内容。 ...

客户端抉择zookeeper的Java客户端次要有zkclient和Curator，此篇文章介绍Curator，就冲他官网的简介，zookeeper书的作者Patrick Hunt给了这么高的评估：Guava is to Java what Curator is to Zookeeper。 实际操作下来，Curator的确比zkclient更全面，代码编写也更加优雅。 引入jar包Curator次要提供了三个包 curator-framework：对zookeeper操作的封装curator-client：提供了一些客户端的操作curator-recipes：封装了一些高级个性咱们能够间接援用curator-recipes，它外面蕴含了其余两个jar包，然而要留神zookeeper的版本，官网中给出了上面提醒： 基本操作客户端实例的创立第一种 ExponentialBackoffRetry retry = new ExponentialBackoffRetry(1000, 3);CuratorFramework client = CuratorFrameworkFactory.newClient("127.0.0.1:2181", retry);retry是重试策略，间隔时间是2的指数增长，比方第一次期待1s，第二次2s，第三次4s。。。 第一个参数是距离根底单位，原始是毫秒；第二个参数是重试次数。 CuratorFrameworkFactory.newClient创立客户端，传入zookeeper的连贯地址和重试策略。 第二种 ExponentialBackoffRetry retry = new ExponentialBackoffRetry(1000, 3);CuratorFramework client = CuratorFrameworkFactory.builder() .connectString("123.206.212.170:2181") .connectionTimeoutMs(10000) .sessionTimeoutMs(10000) .retryPolicy(retry).build();重试策略和下面一样，客户端通过CuratorFrameworkFactory.builder()创立，connectionTimeoutMs示意连贯超时工夫，sessionTimeoutMs示意会话超时工夫。 创立节点CuratorFramework client = client();client.start();String path = "/demo/curd/node-2";client.create() .creatingParentsIfNeeded() .withMode(CreateMode.PERSISTENT) .forPath(path, "world".getBytes("utf-8"));client.close();curator的操作方法，根本都是链式调用，比起zkclient要优雅很多； creatingParentsIfNeeded()示意如果父节点没有，就一起创立； withMode(CreateMode.PERSISTENT)是创立的节点类型，zookeeper的节点有四种类型： PERSISTENT：长久化节点PERSISTENT_SEQUENTIAL：长久化程序节点EPHEMERAL：长期节点EPHEMERAL_SEQUENTIAL：长期程序节点最初.forPath设置创立的节点门路和节点携带的内容。创立后果能够通过IDEA的zookeeper插件可视化查看，插件装置办法自行百度。 删除节点CuratorFramework client = client();client.start();String path = "/demo/curd/node-2";client.delete().forPath(path);client.close();删除节点调用delete办法即可。 批改节点CuratorFramework client = client();client.start();String path = "/demo/curd/node-1";client.setData().forPath(path, "hello world".getBytes("utf-8"));client.close();批改节点调用setData()办法，前面forPath办法传入批改后的内容。 ...

伪集群伪集群就是在一台机器上启动多个雷同利用，模仿实在集群环境。zookeeper的伪集群步骤和实在集群根本一样，只是配置的IP端口有点区别。 为什么须要集群？ 在生产环境中，不论什么单体利用都不能保障始终可用，比方服务宕机，云厂商呈现的bug或者物理机器遇到的天下大乱这些，尽管概率小，然而也不能完全避免。为了实现高可用，就须要集群，同一利用多地部署，就算其中一个挂了，其余的也能持续提供服务。 zookeeper对集群的要求 zookeeper集群节点数必须是奇数，因为在zookeeper集群中，须要一个leader节点，此节点是通过选举机制产生的，这个选举机制须要满足：可用节点数>总节点数/2，也就是存活的节点数必须超过总节点数的一半，如果总节点是3个，那能够容忍挂一个，如果总节点是4个，同样只能容忍挂一个，3个和4个都只能容忍挂一个，那为啥要部署4个呢？ 因自己资金无限，只有一台Linux服务器，所以采纳伪集群形式搭建zookeeper服务。上面咱们在一台机器上部署3个zookeeper节点，实现集群成果。 装置从官网下载zookeeper并上传到服务器，我这里下载的是3.4.14版本 解压：tar -zxvf zookeeper-3.4.14.tar.gz 因为须要部署三个zookeeper，咱们拷贝三分zookeeper cp -R zookeeper-3.4.14 zookeeper_01 cp -R zookeeper-3.4.14 zookeeper_02 cp -R zookeeper-3.4.14 zookeeper_03 配置创立日志目录和数据目录 进入zookeeper_01，创立data和logs目录 mkdir data mkdir logs 在data目录下，创立myid文件，此文件记录节点id，每个zookeeper节点都须要一个myid文件来记录节点在集群中的id，此文件中只能有一个数字，默认放在数据目录上面。myid中数字只能在1~255之间，也就是说zookeeper集群最多有255个节点。 配置zoo.cfg 进入conf目录，复制zoo_sample.cfg文件并重命名为zoo.cfg cp zoo_sample.cfg zoo.cfg 批改zoo.cfg # 单位工夫，其余工夫都是以这个倍数来示意tickTime=2000# 节点初始化工夫，10倍单位工夫initLimit=10# 心跳最大提早周期syncLimit=5# 数据目录dataDir=/root/zookeeper/zookeeper_01/data# 日志目录dataLogDir=/root/zookeeper/zookeeper_01/logs# 端口clientPort=2181#集群配置server.1=127.0.0.1:2888:3888server.2=127.0.0.1:2889:3889server.3=127.0.0.1:2890:3890每个节点都须要配置集群中所有节点信息，应用server.id=ip:port:port配置 其中id，是下面myid文件中配置的id；ip是节点的ip，第一个port是节点之间通信的端口，第二个port用于选举leader节点。 如果是实在集群环境，下面两个端口，每个节点都能够配置成2888和3888。因为我这里在同一台机器上，端口不能抵触，只能应用不同的。 另外两个节点也同样操作，创立data目录和logs目录、创立myid文件，外面配置节点id、批改zoo.cfg。 这里贴一下我三个节点的配置 /root/zookeeper/zookeeper_01/conf/zoo.cfg tickTime=2000initLimit=10syncLimit=5dataDir=/root/zookeeper/zookeeper_01/datadataLogDir=/root/zookeeper/zookeeper_01/logsclientPort=2181server.1=127.0.0.1:2888:3888server.2=127.0.0.1:2889:3889server.3=127.0.0.1:2890:3890/root/zookeeper/zookeeper_02/conf/zoo.cfg tickTime=2000initLimit=10syncLimit=5dataDir=/root/zookeeper/zookeeper_02/datadataLogDir=/root/zookeeper/zookeeper_02/logsclientPort=2182server.1=127.0.0.1:2888:3888server.2=127.0.0.1:2889:3889server.3=127.0.0.1:2890:3890/root/zookeeper/zookeeper_03/conf/zoo.cfg tickTime=2000initLimit=10syncLimit=5dataDir=/root/zookeeper/zookeeper_03/datadataLogDir=/root/zookeeper/zookeeper_03/logsclientPort=2183server.1=127.0.0.1:2888:3888server.2=127.0.0.1:2889:3889server.3=127.0.0.1:2890:3890启动进入zookeeper的bin目录，启动 ./zkServer.sh start 三个节点顺次启动。 能够通过./zkServer.sh status查看节点启动状态，是leader还是follower。 <center>扫一扫，关注我</center>

 起源：https://www.cnblogs.com/jieqi... 作者：jieqing刚开始看到Eureka这个单词的时候真心不会念，查了后发现他有一个好听的名字，来，大家一起念 [ j'rik ]   简介Eureka自身是Netflix开源的一款提供服务注册和发现的产品，并且提供了相应的Java封装。在它的实现中，节点之间互相平等，局部注册核心的节点挂掉也不会对集群造成影响，即便集群只剩一个节点存活，也能够失常提供发现服务。哪怕是所有的服务注册节点都挂了，EurekaClients（客户端）上也会缓存服务调用的信息。这就保障了咱们微服务之间的相互调用足够强壮。Zookeeper次要为大型分布式计算提供开源的分布式配置服务、同步服务和命名注册。已经是Hadoop我的项目中的一个子项目，用来管制集群中的数据，目前已降级为独立的顶级我的项目。很多场景下也用它作为Service发现服务解决方案。 比照在分布式系统中有个驰名的CAP定理（C-数据一致性；A-服务可用性；P-服务对网络分区故障的容错性，这三个个性在任何分布式系统中不能同时满足，最多同时满足两个）； ZookeeperZookeeper是基于CP来设计的，即任何时刻对Zookeeper的拜访申请能失去统一的数据后果，同时系统对网络宰割具备容错性，然而它不能保障每次服务申请的可用性。从理论状况来剖析，在应用Zookeeper获取服务列表时，如果zookeeper正在选主，或者Zookeeper集群中半数以上机器不可用，那么将无奈取得数据。所以说，Zookeeper不能保障服务可用性。诚然，在大多数分布式环境中，尤其是波及到数据存储的场景，数据一致性应该是首先被保障的，这也是zookeeper设计成CP的起因。然而对于服务发现场景来说，状况就不太一样了：针对同一个服务，即便注册核心的不同节点保留的服务提供者信息不尽相同，也并不会造成灾难性的结果。 因为对于服务消费者来说，能生产才是最重要的——拿到可能不正确的服务实例信息后尝试生产一下，也好过因为无奈获取实例信息而不去生产。 （尝试一下能够疾速失败，之后能够更新配置并重试）所以，对于服务发现而言，可用性比数据一致性更加重要——AP胜过CP。 Eureka而Spring Cloud Netflix在设计Eureka时恪守的就是AP准则。EurekaServer也能够运行多个实例来构建集群，解决单点问题，但不同于ZooKeeper的选举leader的过程，Eureka Server采纳的是Peer to Peer对等通信。这是一种去中心化的架构，无master/slave辨别，每一个Peer都是对等的。在这种架构中，节点通过彼此相互注册来进步可用性，每个节点须要增加一个或多个无效的serviceUrl指向其余节点。每个节点都可被视为其余节点的正本。 如果某台Eureka Server宕机，Eureka Client的申请会主动切换到新的EurekaServer节点，当宕机的服务器从新复原后，Eureka会再次将其纳入到服务器集群治理之中。当节点开始承受客户端申请时，所有的操作都会进行replicateToPeer（节点间复制）操作，将申请复制到其余EurekaServer以后所知的所有节点中。 一个新的Eureka Server节点启动后，会首先尝试从邻近节点获取所有实例注册表信息，实现初始化。EurekaServer通过getEurekaServiceUrls()办法获取所有的节点，并且会通过心跳续约的形式定期更新。默认配置下，如果EurekaServer在肯定工夫内没有接管到某个服务实例的心跳，EurekaServer将会登记该实例（默认为90秒，通过eureka.instance.lease-expiration-duration-in-seconds配置）。当Eureka Server节点在短时间内失落过多的心跳时（比方产生了网络分区故障），那么这个节点就会进入自我保护模式。  什么是自我保护模式？默认配置下，如果Eureka Server每分钟收到心跳续约的数量低于一个阈值（instance的数量 _(60/每个instance的心跳距离秒数)_ 自我爱护系数），并且继续15分钟，就会触发自我爱护。在自我保护模式中，EurekaServer会爱护服务注册表中的信息，不再登记任何服务实例。当它收到的心跳数从新复原到阈值以上时，该EurekaServer节点就会主动退出自我保护模式。它的设计哲学后面提到过，那就是宁肯保留谬误的服务注册信息，也不自觉登记任何可能衰弱的服务实例。该模式能够通过eureka.server.enable-self-preservation = false来禁用，同时eureka.instance.lease-renewal-interval-in-seconds能够用来更改心跳距离，eureka.server.renewal-percent-threshold能够用来批改自我爱护系数（默认0.85）。  总结ZooKeeper基于CP，不保障高可用，如果zookeeper正在选主，或者Zookeeper集群中半数以上机器不可用，那么将无奈取得数据。Eureka基于AP，能保障高可用，即便所有机器都挂了，也能拿到本地缓存的数据。作为注册核心，其实配置是不常常变动的，只有发版和机器出故障时会变。对于不常常变动的配置来说，CP是不适合的，而AP在遇到问题时能够用就义一致性来保障可用性，既返回旧数据，缓存数据。 所以实践上Eureka是更适宜作注册核心。而事实环境中大部分我的项目可能会应用ZooKeeper，那是因为集群不够大，并且根本不会遇到用做注册核心的机器一半以上都挂了的状况。所以实际上也没什么大问题。 举荐Netflix 微服务架构设计解析为什么阿里规定须要在事务注解@Transactional中指定rollbackFor？下一代构建工具 Gradle ，比 Maven 强在哪里！如何让你的Nginx 晋升10倍性能？面试必须要明确的 Redis 分布式锁实现原理！学习材料分享12 套 微服务、Spring Boot、Spring Cloud 核心技术材料，这是局部材料目录： Spring Security 认证与受权Spring Boot 我的项目实战（中小型互联网公司后盾服务架构与运维架构）Spring Boot 我的项目实战（企业权限治理我的项目））Spring Cloud 微服务架构我的项目实战（分布式事务解决方案）...公众号后盾回复arch028获取材料：：

单机启动下载https://zookeeper.apache.org/... 解压下载下来的压缩包tar -zxvf apache-zookeeper-3.6.1-bin.tar.gz批改配置文件cd conf/mv zoo_sample.cfg zoo.cfg这里单机启动咱们就应用默认的配置文件，改个名即可 配置中的 dataDir 和 clientPort 能够依据本人的需要改，dataDir 默认是在 /tmp 门路下的，个别是要批改的，这里演示就不做批改了 ，clentPort 能够依据本人的须要批改，默认是 2181端口启动zk ./bin/zkServer.sh start测试客户端连贯zk./bin/zkCli.sh -server 127.0.0.1:2181输出 help 能够查看zkCli的命令，这里应用几条命令测试一下 [zk: 127.0.0.1:2181(CONNECTED) 2] ls /[zookeeper][zk: 127.0.0.1:2181(CONNECTED) 15] create /test sampleCreated /test[zk: 127.0.0.1:2181(CONNECTED) 16] get /testsample[zk: 127.0.0.1:2181(CONNECTED) 17] set /test bar[zk: 127.0.0.1:2181(CONNECTED) 20] get /testbar[zk: 127.0.0.1:2181(CONNECTED) 21] delete /test[zk: 127.0.0.1:2181(CONNECTED) 23] ls /[zookeeper]集群搭建筹备工作3个节点 ，这里应用了3个虚拟机节点 ，我这里别离筹备了 192.168.199.238 192.168.199.239 192.168.199.240 3个节点将zk传到每个节点上凋谢服务器的 2888 3888 端口解压压缩包tar -zxvf apache-zookeeper-3.6.1-bin.tar.gz3个节点都执行一遍 ...

配置项含义说明tickTime=200心跳时间维持心跳的时间间隔，单位是毫秒在zookeeper所有的时间都是以这个时间为基础单元，进行整数倍配置 initLimit=10初始通信时限用于zookeeper集群，此时有多台zookeeper服务器，其中一个为leader,其他都为FollownersyncLimit=5同步通信时限在运行时Leader通过心跳检测与Follower进行通信，如果超过syncLimit*tickTime还未收到响应，则认为该Follower已经宕机dataDir=./data存储数据的目录数据文件也成为snapshotclientPort2181端口号默认2181maxClientCnxns=60单个客户端的最大连接数限制默认60，可以设置为0，表示没有限制autopurge.snapRetainCount=3保留文件的数量默认3个autopurge.purgeInterval=1自动清理快找文件和事务日志的频率默认为0，表示不开启自动清理，单位是小时dataLogDir=日志存放路径未指定时日志文件也存在dataDir,为了性能最大化，一般建议把dataDir和dataLogDir放到不同磁盘上创建命令：

一、zookeeper是什么Apache Zookeeper是一个开源的分布式服务框架，为分布式应用提供协调服务，用来解决分布式应用中的数据管理问题，如配置管理、域名服务、分布式同步、集群管理相关概念：分布式：将一个大型应用的不同业务部署在不同的服务器上，解决高并发的问题。集群：将同一个业务部署在多台服务器上，提高系统的高可用性。 二、Zookeeper组成主要包含两部分： 文件系统、通知机制 2.1文件系统ZooKeeper维护一个类似Linux文件系统的数据结构，用于存储数据 数据模型结构是一种树形结构，由许多节点组成每个节点叫做ZNode(Zookeeper Node)每个节点对应一个唯一路径，通过该路径来标识节点，如果/app1/p2每个节点只能存储大约1M的数据节点类型由四种： 持久化目录节点persistent 客户端与服务器断开连接，该节点仍然存在持久化顺序编号目录节点 persistent_sequential 客户端与服务器断开连接，该节点仍然存在，此时节点会被顺序编号，如：0000001，0000002临时目录节点 ephermeral 客户端与服务器断开连接，该节点会被删除临时顺序编号目录节点 ephermeral_sequential 客户端与服务器断开连接，该节点会被删除，此时节点会被顺序编号，如0000001，0000022.2通知机制ZooKeeper是一个基于观察者模式设计的分布式服务管理框架 ZooKeeper负责管理和维护项目的公共数据，并接受观察者的注册(订阅)一旦这些数据发生变化，ZooKeeper就会通知已注册的观察者此时观察者就可以做出相应的反应简单来说，客户端注册监听它关心的目录节点，当目录节点发生变化时，ZooKeeper会通知客户端 Zookeeper是一个订阅中心(注册中心) 三、应用场景3.1 配置管理场景：集群环境、服务器的许多配置都是相同的，如数据库连接信息、当需要修改这些配置时必须同时修改每台服务器，很麻烦 解决：把这些配置全部放到ZooKeeper上，保存在ZooKeeper的某个目录节点中，然后所有的应用程序(客户端)对这个目录节点进行监视Watch,一旦配置信息发生变化，Zookeeper会通知每个客户端，然后从ZooKeeper获取新的配置信息，并应用到系统中 3.2 集群管理场景：集群环境下，如何知道有多少台机器在工作？是否有机器退出或加入？需要选举一个总管master,让总管来管理集群。解决：在父目录GroupMembers下所有机器创建临时目录节点，然后监听父目录节点的子节点变化，一旦有机器挂掉，该机器与ZooKeeper的连接断开，其所创建的临时目录被删除，其他所创建的临时目录节点被删除，所有其他机器都会收到通知。当新机器加入时，会创建新的节点，同理。选举master: 为所有机器创建临时顺序编号目录节点，给每台机器编号，然后每次选取编号最小的机器作为master. 3.3 负载均衡ZooKeeper本身是不提供负载均衡策略，准确的说，是在负载均衡中使用ZooKeeper来做集群的协调(也称为软负载均衡)实现思路： 将ZooKeeper作为服务的注册中心，所有服务器在启动时向注册中心登录自己能够提供的服务服务的调用者到注册中心获取能够提供的所需要服务的服务器列表，然后自己根据负载均衡算法，从中选取一台服务器进行连接当服务器列表发生变化时，如：某台服务器宕机下线，或新机器加入，Zookeeper会自动通知调用者重新获取服务。实际上利用了ZooKeeper的特性，将ZooKeeper作为服务的注册和变更通知中心。

概述Z K作为一个分布式协调框架、内部存储着一些分布式系统运行时状态的元数据。如何有效的保护这些数据的安全、如何做一个比较好的权限控制显得非常的重要。 ZK 为我们提供一套完善的 ACL(access control list,访问控制列表) 权限控制机制来保障数据的安全。 ACL 介绍我们可以从三个方面来理解 ACL 机制 Scheme 权限模式Id 授权对象Permission 权限通常使用 scheme:id:permission 来标志一个有效的 ACL 信息、我们先来看看我们默认的数据节点里面的 ACL 数据 getACl / 我们也可以看到他也是分为三部分的 world 对应的就是 schemeanyone 对应的就是 idcdrwa 对应的就是 permission下面我们就分别介绍它们 权限create:c 数据节点的创建权限、允许授权对象在该数据节点下创建子节点。delete:d 子节点的删除权限、允许授权对象删除该数据节点的子节点read:r 数据节点的读取权限、允许授权对象对该数据节点读取数据内容和获取子节点列表信息write:w 数据节点的更新权限、允许授权对象对数据节点的数据内容进行更新admin:a 数据节点的管理权限、允许授权对象对该数据节点进行 ACL 相关的设置操作权限模式如果按分类来说、ZK 中其实只有两种权限模式，一种是基于IP/IP段的，一种是基于账号密码的。 但是可以细分为以下四种 IPdigestworldsuperIPIP 模式可以针对数据节点设置 IP 地址或设置 IP 网段的方式进行配置。 [zk: localhost:2181(CONNECTED) 44] create /acl_ip data ip:127.0.0.1:cdrwaCreated /acl_ip我们创建了数据节点 acl_ip 并且为这个节点设置了 ACL ,使用的是 IP 这种模式、授权对象就是 127.0.0.1 这个 ip，而权限则是五种权限全部都赋予了。我们在另外本机电脑的另一个 zkClient 中访问该数据节点 ...

GitHub地址: https://github.com/apache/zookeeper最新版本的 zookeeper 已经使用了 maven 进行管理了、不再需要安装 Ant 下载完成之后、使用 Idea 作为一个 maven 项目打开 拷贝配置文件拷贝zoo_sample.cfg文件至相同文件夹下，名为：zoo.cfg，配置全部使用默认；创建 /tmp/zookeeper 目录、用于存放 zk 数据.拷贝log4j.properties文件至：zookeeper-server/src/main/resources，文件名还是log4j.properties不变.将 resource 标记为 Resources Root增加启动项找到类 org.apache.zookeeper.server.quorum.QuorumPeerMain 在参数中加上 conf/zoo.cfg 修改pom文件中scope将 scope 注释掉 <dependency> <groupId>io.dropwizard.metrics</groupId> <artifactId>metrics-core</artifactId> <version>3.1.0</version></dependency><dependency> <groupId>org.xerial.snappy</groupId> <artifactId>snappy-java</artifactId> <version>1.1.7.3</version></dependency><dependency> <groupId>org.eclipse.jetty</groupId> <artifactId>jetty-server</artifactId></dependency><dependency> <groupId>org.eclipse.jetty</groupId> <artifactId>jetty-servlet</artifactId></dependency>执行server执行 main 方法前建议执行命令 mvn clean install -DskipTests 2020-05-11 23:51:27,731 [myid:] - INFO [main:NIOServerCnxnFactory@664] - binding to port 0.0.0.0/0.0.0.0:21812020-05-11 23:51:27,751 [myid:] - INFO [main:WatchManagerFactory@42] - Using org.apache.zookeeper.server.watch.WatchManager as watchmanager2020-05-11 23:51:27,751 [myid:] - INFO [main:WatchManagerFactory@42] - Using org.apache.zookeeper.server.watch.WatchManager as watchmanager2020-05-11 23:51:27,751 [myid:] - INFO [main:ZKDatabase@132] - zookeeper.snapshotSizeFactor = 0.332020-05-11 23:51:27,751 [myid:] - INFO [main:ZKDatabase@152] - zookeeper.commitLogCount=5002020-05-11 23:51:27,757 [myid:] - INFO [main:SnapStream@61] - zookeeper.snapshot.compression.method = CHECKED2020-05-11 23:51:27,759 [myid:] - INFO [main:FileSnap@85] - Reading snapshot /tmp/zookeeper/version-2/snapshot.32020-05-11 23:51:27,763 [myid:] - INFO [main:DataTree@1730] - The digest in the snapshot has digest version of 2, , with zxid as 0x3, and digest value as 13719855042020-05-11 23:51:27,774 [myid:] - INFO [main:FileTxnSnapLog@363] - 1 txns loaded in 5 ms2020-05-11 23:51:27,774 [myid:] - INFO [main:ZKDatabase@289] - Snapshot loaded in 23 ms, highest zxid is 0x4, digest is 13719855042020-05-11 23:51:27,774 [myid:] - INFO [main:FileTxnSnapLog@470] - Snapshotting: 0x4 to /tmp/zookeeper/version-2/snapshot.42020-05-11 23:51:27,775 [myid:] - INFO [main:ZooKeeperServer@522] - Snapshot taken in 1 ms2020-05-11 23:51:27,788 [myid:] - INFO [main:RequestThrottler@75] - zookeeper.request_throttler.shutdownTimeout = 100002020-05-11 23:51:27,802 [myid:] - INFO [main:ContainerManager@83] - Using checkIntervalMs=60000 maxPerMinute=10000 maxNeverUsedIntervalMs=02020-05-11 23:51:27,803 [myid:] - INFO [main:ZKAuditProvider@42] - ZooKeeper audit is disabled.2020-05-11 23:51:58,403 [myid:] - INFO [SessionTracker:ZooKeeperServer@603] - Expiring session 0x100016819530000, timeout of 30000ms exceeded2020-05-11 23:51:58,404 [myid:] - INFO [SessionTracker:ZooKeeperServer@603] - Expiring session 0x10001651fa70000, timeout of 30000ms exceeded2020-05-11 23:51:58,407 [myid:] - INFO [SyncThread:0:FileTxnLog@284] - Creating new log file: log.5启动成功 ...

读完这篇文章你将会收获到 在 Zookeeper 源码项目中新建模块，使用 Jute 进行序列化和反序列化修改 Jute 中的 buffer size 来序列化/反序列化大对象序言从 前面的文章 我们得知、ZK 的客户端和服务端会通过网络进行一系列的数据交互(节点中的数据内容、ACL 信息)，而我们知道从一个内存对象到网络传输，那么就会涉及到序列化和反序列化操作。ZK 使用到是一个叫 Jute 的序列化组件(对不起，我真的没听过，尴尬了) Jute 介绍Jute 是 ZK 中序列化的组件，前身是 Hadoop Record IO 中的序列化组件。 ZK 从第一个正式对外的版本开始，就一直使用 Jute 组件来进行网络数据传输和本地磁盘数据存储的序列化和反序列化工作。并不是 Jute 优秀到不被其他序列化框架所超越、而是替换这种基层组件、老版本的兼容性问题很难处理，并且 Jute 的序列化能力并不是 ZK 性能上的瓶颈，so 现在还是这个序列化组件。 Jute 使用Talk is cheap. Show me the code 在 zk 源代码中新建一个模块 加入依赖 dependencies> <dependency> <groupId>org.projectlombok</groupId> <artifactId>lombok</artifactId> <version>1.18.12</version> </dependency> <dependency> <groupId>junit</groupId> <artifactId>junit</artifactId> <scope>test</scope> </dependency> <dependency> <groupId>org.apache.zookeeper</groupId> <artifactId>zookeeper-jute</artifactId> <version>3.7.0-SNAPSHOT</version> </dependency> <dependency> <groupId>org.apache.zookeeper</groupId> <artifactId>zookeeper</artifactId> <version>3.7.0-SNAPSHOT</version> </dependency> </dependencies>创建 POJO , 并实现 Record 接口 ...

1.注册中心的作用利用注册中心，服务提供者可以动态添加删除服务，服务消费者在收到更新通知后，可以拉取最新的服务从而实现同步。可以在注册中心实现统一配置，参数的动态调整可以自动通知到所有服务节点。 2.Dubbo四种注册中心实现Dubbo注册中心的实现在dubbo-registry模块。 2.1 ZooKeeper基于Zookeeper。ZooKeeper学习 2.1.1 Zookeeper注册中心数据结构 2.1.2 Zookeeper注册中心实现原理Zookeeper注册中心采用"事件通知" + “客户端拉取”的实现方式： 客户端在第一次连接注册中心的时候，会获取对应目录下的全量数据。客户端会在订阅的节点上注册一个watch,客户端与注册中心之间保持TCP长连接。当节点发生事务操作，节点的版本号发生改变，就会触发watch事件，推送数据给订阅方，订阅方收到通知之后，就会拉取对应目录下的数据。服务治理中心会订阅所有service层的数据，service被设置成"*"，表示订阅全部。2.1.3 Zookeeper注册和取消注册//注册protected void doRegister(URL url) { try { //创建目录 zkClient.create(toUrlPath(url), url.getParameter(Constants.DYNAMIC_KEY, true)); } catch (Throwable e) { throw new RpcException("Failed to register " + url + " to zookeeper " + getUrl() + ", cause: " + e.getMessage(), e); }}//取消注册protected void doUnregister(URL url) { try { //删除目录 zkClient.delete(toUrlPath(url)); } catch (Throwable e) { throw new RpcException("Failed to unregister " + url + " to zookeeper " + getUrl() + ", cause: " + e.getMessage(), e); }}private String toUrlPath(URL url) { return toCategoryPath(url) + Constants.PATH_SEPARATOR + URL.encode(url.toFullString());}//返回"/dubbo/接口名称/providers"private String toCategoryPath(URL url) { return toServicePath(url) + Constants.PATH_SEPARATOR + url.getParameter(Constants.CATEGORY_KEY, Constants.DEFAULT_CATEGORY);}//返回"/dubbo/接口名称"private String toServicePath(URL url) { String name = url.getServiceInterface(); if (Constants.ANY_VALUE.equals(name)) { return toRootPath(); } return toRootDir() + URL.encode(name);}//返回"/"或者"/dubbo/"private String toRootDir() { if (root.equals(Constants.PATH_SEPARATOR)) { return root; } return root + Constants.PATH_SEPARATOR;}private String toRootPath() { return root;}private final static String DEFAULT_ROOT = "dubbo";private final ZookeeperClient zkClient;public ZookeeperRegistry(URL url, ZookeeperTransporter zookeeperTransporter) { //省略n行代码 String group = url.getParameter(Constants.GROUP_KEY, DEFAULT_ROOT); //添加前缀"/" if (!group.startsWith(Constants.PATH_SEPARATOR)) { group = Constants.PATH_SEPARATOR + group; } this.root = group; zkClient = zookeeperTransporter.connect(url); //省略n行代码}ZookeeperClient和ZookeeperTransporter都是接口，在Dubbo中有两种实现，一种是基于curator客户端的CuratorZookeeperClient和CuratorZookeeperTransporter；另一种是基于zkclient客户端的ZkclientZookeeperClient和ZkclientZookeeperTransporter。默认实现是curator。 ...

1 准备工作1、准备服务器，本次安装采用 centos7系统、内存2G、存储60G的虚拟机服务器一台；2、服务器安装java环境： 参考文章《centos7上安装jdk8》博文；3、准备zookeeper安装包， 本次采用 zookeeper-3.4.11.tar.gz 版本的包 2 安装zookeeper2.1、 解压zookeeper安装包，使用tar命令：tar -zxvf zookeeper-3.4.11.tar.gz 我们看下解压完成后，zookeeper文件夹的内容： 2.2、 修改配置文件：1、我们进入 conf 文件夹下，可以看到该文件夹的内容如下： 2、这里，我们将 zoo_sample.cfg 复制一份并命名为 zoo.cfgcp zoo_sample.cfg zoo.cfg 3、使用vi 命令打开zoo.cfg 并修改配置： 这里，我们需要注意上图标白的dataDir位置对应的目录，如果对应的目录不存在，我们需要修改该路径，我们先在zookeeper的解压路径下创建一个新的文件夹 data。 然后，我们将刚刚创建的文件夹路径设置到 dataDir 下： 其中，可以通过修改clientPort后面的值，修改zookeeper启动端口，默认为2181.4、启动zookeeper在zookeeper目录下的bin文件夹中，使用以下命令启动zookeeper:./zkServer.sh start -5 检查zookeeper启动情况我们可以使用以下命令查看zookeeper的启动状态：./zkServer.sh status 除此之外，我们也可以通过查看zookeeper的进程来判断其是否启动成功！ps -ef | grep zookeeper 3 设置zookeeper开机自启动我们可以将zookeeper作为一个服务，设置其开机自启，这样每次我们打开虚拟机就可以开启zookeeper，彻底解放双手！设置zookeeper开机自启需要以下几个步骤：1、进入 /etc/init.d 目录： 2、创建文件zookeeper，并添加脚本：vi zookeeper脚本内容为： !/bin/bash#chkconfig:2345 20 90#description:zookeeper#processname:zookeeperZK_PATH=/opt/soft/zookeeper-3.4.11export JAVA_HOME=/opt/soft/jdk1.8.0_152case $1 in start) sh $ZK_PATH/bin/zkServer.sh start;; stop) sh $ZK_PATH/bin/zkServer.sh stop;; status) sh $ZK_PATH/bin/zkServer.sh status;; restart) sh $ZK_PATH/bin/zkServer.sh restart;; *) echo "require start|stop|status|restart" ;;esac注意：上图的脚本中需要修改正确的zk和jdk安装路径！3、保存脚本之后，执行以下指令将其注册为服务：chkconfig --add zookeeper4、测试其是否生效，这里采用先停服务，再使用命令启动，注意需要修改创建的zookeeper服务权限：[root@zhiyou init.d]# service zookeeper startenv: /etc/init.d/zookeeper: 权限不够[root@zhiyou init.d]# [root@zhiyou init.d]# chmod +x zookeeper [root@zhiyou init.d]# [root@zhiyou init.d]# service zookeeper startZooKeeper JMX enabled by defaultUsing config: /opt/soft/zookeeper-3.4.11/bin/../conf/zoo.cfgStarting zookeeper ... STARTED[root@zhiyou init.d]# [root@zhiyou init.d]# service zookeeper statusZooKeeper JMX enabled by defaultUsing config: /opt/soft/zookeeper-3.4.11/bin/../conf/zoo.cfgMode: standalone[root@zhiyou init.d]# [root@zhiyou init.d]# ps -ef|grep zookeeper ...

前言ZooKeeper是一个分布式服务协调框架，可以用来维护分布式配置信息、服务注册中心、实现分布式锁等。在Hbase、Hadoop、kafka等项目中都有广泛的应用。随着分布式、微服务的普及，ZooKeeper已经成为我们日常开发工作中无法绕过的一环，本文将从安装配置到最基础的使用入手，对其进行介绍。 安装部署下载在 http://mirror.bit.edu.cn/apache/zookeeper/stable/ 下载推荐的stable版本。可以直接下载编译好的bin文件。目前最新的stable版本是3.5.5 解压将下载的文件解压至工作目录，我的工作目录是/var/workspace/zookeeper tar -xzvf apache-zookeeper-3.5.5-bin.tar.gz -C /var/workspace/zookeeper配置 此时如果直接启动zookeeper是会失败的，提示找不到zoo.cfg文件。需要我们把conf目录中提供的zoo_sample.cfg示例配置文件，复制为一份zoo.cfg，zoo.cfg是默认的启动配置文件 cp ../conf/zoo_sample.cfg ../conf/zoo.cfg启动 默认启动，使用config/zoo.cfg配置文件在后台启动 前台启动，会将启动日志打印在终端。终端关闭后服务也关闭。 访问 使用zcCli.sh -server host:port 访问ZooKeeper服务器。不加-server参数时，默认使用127.0.0.1:2181 使用ZooKeeper使用类似资源文件目录的方式来管理节点，每个节点可以存储数据。ZooKeeper有四种不同类型的节点： PERSISTENT：持久化节点，除非手动删除，否则会永久保存PERSISTENT_SEQUENTIAL：持久化顺序节点，除非手动删除，否则会永久保存。默认会在用户设置的节点名称后，顺序的增加十位的数字字符串。如 test_0000000001EPHEMERAL：临时节点，在session结束后，临时节点会被自动删除。EPHEMERAL_SEQUENTIAL：临时顺序节点，在session结束后，临时节点会被自动删除。默认会在用户设置的节点名称后，顺序的增加十位的数字字符串。如 test_0000000001help使用zkCli.sh连接到服务端后，可以使用help展示常见命令的使用方式。 ls 列出某个路径下的节点 create 可以使用create {path} 创建节点。使用 create -s {path} 可以创建有序节点，后面添加十位递增的数字后缀。 使用 create -e 创建临时节点，当断开连接后，临时节点会被删除。 set/get ZooKeeper的节点可以存储数据，使用set 方法将数据存在节点中。使用get 方法，从节点中获取数据。 set -v {currentVersion} {path} {data} 节点的数据每次更新时，都会递增，如果要更新节点，请使用上面的命令修改，如果currentVersion不是最新版本时，则更新失败，类似乐观锁CAS。 delete 可以通过delete删除节点。 总结通过上面的学习，我们已经学会了ZooKeeper最基本的安装部署及使用方式。需要牢记： ZooKeeper的节点是类似文件系统的管理方式Zookeeper有四种节点类型，临时节点会在会话断开后自动删除，顺序节点后缀序号会自动递增set数据时，可以指定版本号，版本号与当前版本一致时才更新。这种乐观锁的更新方式，可以避免并发时数据被覆盖 本文作者：aloof_阅读原文 本文为云栖社区原创内容，未经允许不得转载。

有课学是课返现平台，支持极客时间、知识星球、小专栏...等平台，希望每个人都能【学好课，有所获】关注有课学公众号，回复 zoo 获取极客时间专栏《ZooKeeper 实战与源码剖析》购买链接，提交购买截图即可获取返现。 ZooKeeper 是一个设计非常优雅和成功的软件系统。它的设计者们似乎从十多年前就想清楚了所有的需求场景，以至于这么多年过去了，ZooKeeper 的对外 API 基本上没有太多改变，而ZooKeeper 的应用范围却变得越来越广泛。 这得益于 ZooKeeper 独特的软件设计和功能特性： 安装配置简单，运维人员可以很快上手；核心API非常简单，只要使用其中6个方法就可以实现大部分协同服务的研发；ZooKeeper有丰富的生态圈，网上有很多的ZooKeeper第三方工具和相关资料；支持线性扩展，系统扩容就是简单的添加节点，而且可以在不中断服务的前提下进行。虽然大多数技术人都可以很快上手 ZooKeeper，但大都局限于基于现有的 ZooKeeper 协同服务示例做一些简单的定制。如果想要具备为自己的业务场景设计 ZooKeeper 协同服务应用的能力，就需要深刻理解 ZooKeeper 的内部工作原理，还要做大量的协同服务设计练习。 理解 ZooKeeper 的内部工作原理，需要学习大量的计算机理论知识。这些理论知识涉及分布式系统、数据库系统和操作系统，而找到并学习这些知识点需要耗费很多时间。 说到这里，要给你推荐极客时间新上的视频课《ZooKeeper 实战与源码剖析》，这门课程最大的亮点，是会深入核心代码，深度剖析 ZooKeeper 的内部原理。除此之外，还会带你进行大量的实战演练，比如与 Kafka 结合进行相应的开发实战。另外，也会带你上手 etcd。 更详细课程目录传送门: https://time.geekbang.org/cou...

zookeeper应用场景回顾下zk应用场景： 数据发布与订阅服务注册与发现分布式锁分布式队列master选举配置中心命名服务负载均衡zookeeper实现服务注册与发现服务注册与发现 再来看看zk在服务注册与发现中的应用： 代码实现逻辑： 服务注册： public class ServiceRegister { private static final String BASE_SERVICES = "/services"; private static final String SERVICE_NAME="/products"; public static void register(String address,int port) { try { ZooKeeper zooKeeper = new ZooKeeper("localhost:2181",5000,(watchedEvent)->{}); Stat exists = zooKeeper.exists(BASE_SERVICES + SERVICE_NAME, false); if(exists==null) { zooKeeper.create(BASE_SERVICES + SERVICE_NAME,"".getBytes(), ZooDefs.Ids.OPEN_ACL_UNSAFE, CreateMode.PERSISTENT); } String server_path = address+":"+port; //创建的临时的有序节点 //临时的话断开连接了可以监听到,有序节点创建代表每一个节点否则相同节点名称无法创建 zooKeeper.create(BASE_SERVICES + SERVICE_NAME+"/child",server_path.getBytes(), ZooDefs.Ids.OPEN_ACL_UNSAFE,CreateMode.EPHEMERAL_SEQUENTIAL); System.out.println("产品服务注册成功"); } catch (Exception e) { e.printStackTrace(); } }}发现服务： ...

一、大数据处理流程上图是一个简化的大数据处理流程图，大数据处理的主要流程包括数据收集、数据存储、数据处理、数据应用等主要环节。下面我们逐一对各个环节所需要的技术栈进行讲解： 1.1 数据收集大数据处理的第一步是数据的收集。现在的中大型项目通常采用微服务架构进行分布式部署，所以数据的采集需要在多台服务器上进行，且采集过程不能影响正常业务的开展。基于这种需求，就衍生了多种日志收集工具，如 Flume 、Logstash、Kibana 等，它们都能通过简单的配置完成复杂的数据收集和数据聚合。 1.2 数据存储收集到数据后，下一个问题就是：数据该如何进行存储？通常大家最为熟知是 MySQL、Oracle 等传统的关系型数据库，它们的优点是能够快速存储结构化的数据，并支持随机访问。但大数据的数据结构通常是半结构化（如日志数据）、甚至是非结构化的（如视频、音频数据），为了解决海量半结构化和非结构化数据的存储，衍生了 Hadoop HDFS 、KFS、GFS 等分布式文件系统，它们都能够支持结构化、半结构和非结构化数据的存储，并可以通过增加机器进行横向扩展。 分布式文件系统完美地解决了海量数据存储的问题，但是一个优秀的数据存储系统需要同时考虑数据存储和访问两方面的问题，比如你希望能够对数据进行随机访问，这是传统的关系型数据库所擅长的，但却不是分布式文件系统所擅长的，那么有没有一种存储方案能够同时兼具分布式文件系统和关系型数据库的优点，基于这种需求，就产生了 HBase、MongoDB。 1.3 数据分析大数据处理最重要的环节就是数据分析，数据分析通常分为两种：批处理和流处理。 批处理：对一段时间内海量的离线数据进行统一的处理，对应的处理框架有 Hadoop MapReduce、Spark、Flink 等；流处理：对运动中的数据进行处理，即在接收数据的同时就对其进行处理，对应的处理框架有 Storm、Spark Streaming、Flink Streaming等。批处理和流处理各有其适用的场景，时间不敏感或者硬件资源有限，可以采用批处理；时间敏感和及时性要求高就可以采用流处理。随着服务器硬件的价格越来越低和大家对及时性的要求越来越高，流处理越来越普遍，如股票价格预测和电商运营数据分析等。 上面的框架都是需要通过编程来进行数据分析，那么如果你不是一个后台工程师，是不是就不能进行数据的分析了？当然不是，大数据是一个非常完善的生态圈，有需求就有解决方案。为了能够让熟悉 SQL 的人员也能够进行数据的分析，查询分析框架应运而生，常用的有 Hive 、Spark SQL 、Flink SQL、 Pig、Phoenix 等。这些框架都能够使用标准的 SQL 或者 类SQL 语法灵活地进行数据的查询分析。这些 SQL 经过解析优化后转换为对应的作业程序来运行，如 Hive 本质上就是将 SQL 转换为 MapReduce 作业，Spark SQL 将 SQL 转换为一系列的 RDDs 和转换关系（transformations），Phoenix 将 SQL 查询转换为一个或多个HBase Scan。 1.4 数据应用数据分析完成后，接下来就是数据应用的范畴，这取决于你实际的业务需求。比如你可以将数据进行可视化展现，或者将数据用于优化你的推荐算法，这种运用现在很普遍，比如短视频个性化推荐、电商商品推荐、头条新闻推荐等。当然你也可以将数据用于训练你的机器学习模型，这些都属于其他领域的范畴，都有着对应的框架和技术栈进行处理，这里就不一一赘述。 1.5 其他框架上面是一个标准的大数据处理流程所用到的技术框架。但是实际的大数据处理流程比上面复杂很多，针对大数据处理中的各种复杂问题分别衍生了各类框架： 单机的处理能力都是存在瓶颈的，所以大数据框架都是采用集群模式进行部署，为了更方便的进行集群的部署、监控和管理，衍生了 Ambari、Cloudera Manager 等集群管理工具；想要保证集群高可用，需要用到 ZooKeeper ，ZooKeeper 是最常用的分布式协调服务，它能够解决大多数集群问题，包括首领选举、失败恢复、元数据存储及其一致性保证。同时针对集群资源管理的需求，又衍生了 Hadoop YARN ;复杂大数据处理的另外一个显著的问题是，如何调度多个复杂的并且彼此之间存在依赖关系的作业？基于这种需求，产生了 Azkaban 和 Oozie 等工作流调度框架；大数据流处理中使用的比较多的另外一个框架是 Kafka，它可以用于消峰，避免在秒杀等场景下并发数据对流处理程序造成冲击；另一个常用的框架是 Sqoop ，主要是解决了数据迁移的问题，它能够通过简单的命令将关系型数据库中的数据导入到 HDFS 、Hive 或 HBase 中，或者从 HDFS 、Hive 导出到关系型数据库上。二、学习路线介绍完大数据框架，接着就可以介绍其对应的学习路线了，主要分为以下几个方面： ...

https://github.com/Nirvana010...

1.一致性协议1.1两阶段提交2PC：本身是一致强一致性算法，所以很适合用作数据库的分布式事务。其实数据库的经常用到的TCC本身就是一种2PC。 数据库事务：回顾下数据库的事务，对一条数据的修改操作首先写undo日志，记录的数据原来的样子，接下来执行事务修改操作，把数据写到redo日志里面，万一捅娄子，事务失败了，可从undo里面回复数据。 数据库通过undo与redo能保证数据的强一致性，要解决分布式事务的前提就是当个节点是支持事务的。在这个前提下,2PC将整个分布式事务分两节点： 1.第一阶段：为准备节点，事务的请求都发送给一个个资源，资源可以是数据库，也可以是其他支持事务的框架(比如zookeeper)，他们会分别执行自己的事务，写日志到undo与redo，但不提交事务。2.第二阶段：当事务管理器收到了所以资源的反馈，事务都执行没报错后，事务管理器再发送commit指令让资源把事务提交，一旦发现任何一个资源在准备阶段没有执行成功，事务管理器会发送rollback，让所有的资源都回滚。强一致性是指：保证每个资源都成功,整个分布式事务才成功. 缺点： 1.同步阻塞.----------所有的节点都在等待其他节点的响应，无法进行其他操作。这种同步阻塞极大的限制了分布式系统的性能。2.单点问题.----------如果协调者在提交(commit)阶段出现问题，那么整个流程将无法运转。更重要的是，其他参与者将会处于一直锁定事务资源的状态中，而无法继续完成事务操作.3.数据不一致.-------若协调者即事务管理器未发送完所有commit请求自身崩溃，则导致一部分参与者未收到commit请求，导致数据不一致.4.容错性不好.----任何一个节点失败都会导致整个事务失败.1.2.三阶段提交 three-phase commit (3PC) 第一阶段：协调者向参与者发送commit请求，参与者如果可以提交就返回Yes响应，否则返回No响应。第二阶段：如果所有服务都ok，可以接收事务请求，这一阶段就可以执行事务了，这时候也是每个资源都回写redo与undo日志，事务执行成功，返回ack（yes）,否则返回no第三阶段：这阶段和前面说的2阶段提交大同小异，这个时候协调者发现所有提交者事务提交者事务都正常执行后，给所有资源发送commit指令。与2PC区别：第二阶段才写undo和redo事务日志第三阶段协调者出现异常或网络超时参与者也会commit 三阶段3PC优点：相对于2PC，3PC主要解决的单点故障问题，并减少阻塞，因为一旦参与者无法及时收到来自协调者的信息之后，会默认执行commit。而不会一直持有事务资源并处于阻塞状态。但是这种机制也会导致数据一致性问题，比如由于网络原因，协调者发送的abort响应没有及时被参与者接收到，那么参与者在等待超时之后执行了commit操作。这样就和其他接到abort命令并执行回滚的参与者之间存在数据不一致的情况。 但回顾整个过程，不管是2pc,还是3pc，同步阻塞，单点故障，容错机制不完善这些问题都没本质上得到解决，尤其是前面说得数据一致性问题，反而更糟糕了。 所有数据库的分布式事务一般都是二阶段提交，而者三阶段的思想更多的被借鉴扩散成其他的算法 1.3.Paxos算法 paxos算法分为两个阶段，有2个角色，提议者和接受者。 关键是：1.少数服从多数2.角色轮换避免单点故障具体流程也没搞清楚~~先知道核心思想即可 2 zookeeper集群2.1 zookeeper集群特点 顺序一致性 ：客户端的更新顺序与它们被发送的顺序相一致。原子性： 更新操作要么成功要么失败，没有第三种结果。单一视图： 无论客户端连接到哪一个服务器，客户端将看到相同的 ZooKeeper 视图。可靠性： 一旦一个更新操作被应用，那么在客户端再次更新它之前，它的值将不会改变。实时性： 连接上一个服务端数据修改，所以其他的服务端都会实时的跟新，不算完全的实时，有一点延时的角色轮换避免单点故障： 当leader出现问题的时候，会选举从follower中选举一个新的leader集群中的角色 Leader： 集群工作机制中的核心 事务请求的唯一调度和处理者，保证集群事务处理的顺序性， 集群内部个服务器的调度者(管理follower,数据同步)Follower： 集群工作机制中的跟随者处理非事务请求，转发事务请求给Leader, 参与事务请求proposal投票， 参与leader选举投票Observer： 观察者 3.30以上版本提供，和follower功能相同，但不参与任何形式投票 处理非事务请求，转发事务请求给Leader 提高集群非事务处理能力2.1 zookeeper集群搭建1.安装JDK，zookeeper。 2.配置环境变量vi /etc/profile export JAVA_HOME=/usr/local/jdk1.8.0_211export ZOOKEEPER_HOME=/usr/local/zookeeperexport CLASSPATH=.:$JAVA_HOME/lib/dt.jar:$JAVA_HOME/lib/tools.jarexport PATH=$JAVA_HOME/bin:$ZOOKEEPER_HOME/bin:$PATH 刷新profile文件source /etc/profile 关闭防火墙(命令视不同系统情况而定) 3.修改zk配置文件 mv zoo_sample.cfg zoo.cfg 修改conf: vi zoo.cfg 修改两处（1） dataDir=/usr/local/zookeeper/data（注意同时在zookeeper创建data目录） dataDirLog=/usr/local/zookeeper/log 日志目录，并创建目录（2）最后面添加server.0=192.168.64.128:2888:3888(2888是集群内机器通讯端口,3888是选举leader使用)server.1=192.168.64.129:2888:3888server.2=192.168.64.130:2888:3888 注意：server.0,server.1中，0和1就是服务器标识4.创建服务器标识 在dataDir路径下data目录下创建myid文件，内容即为0/1/2，即上述配置的。 5.复制 /usr/local/zookeeper下所有文件到另外2个服务器上面，只修改myid的服务器标识即可。 ...

1.zookeeper简介ZooKeeper致力于提供一个高性能、高可用，且具备严格的顺序访问控制能力的分布式协调服务，是雅虎公司创建，是Google的Chubby一个开源的实现，也是Hadoop和Hbase的重要组件。 2.设计目标简单的数据结构：共享的树形结构，类似文件系统，存储于内存；可以构建集群：避免单点故障，3-5台机器就可以组成集群，超过半数正常工作就能对外提供服务；顺序访问：对于每个读请求，zk会分配一个全局唯一的递增编号，利用这个特性可以实现高级协调服务；高性能：基于内存操作，服务于非事务请求，适用于读操作为主的业务场景。3台zk集群能达到13w QPS；3.应用场景数据发布订阅 (以下都是基于数据发布订阅)负载均衡命名服务Master选举集群管理配置管理分布式队列分布式锁4.zookeeper基础linux下安装zookeeper： 目录结构：bin →存放系统脚本conf → 存放配置文件contrib → zk附加功能支持dist-maven → maven仓库文件docs → zk文档lib → 依赖的第三方库recipes → 经典场景样例代码src → zk源码 其中bin和conf是非常重要的两个目录，也是经常用的。 bin目录：其中zkServer为服务器，启动后默认端口为2181zkCli为命令行客户端 conf目录：这里就不一一列举了，具体查阅资料 5.ZK的特性Zk的特性会从会话、数据节点，版本，Watcher，ACL权限控制，集群角色这些部分来了解，其中重点需要掌握的数据节点与Watcher。 5.1 会话客户端与服务端的一次会话连接，本质是TCP长连接，通过会话可以进行心跳检测和数据传输；会话（session）是zookepper非常重要的概念，客户端和服务端之间的任何交互操作都与会话有关。 会话状态图： Zk客户端和服务端成功连接后，就创建了一次会话，ZK会话在整个运行期间的生命周期中，会在不同的会话状态之间切换，这些状态包括：CONNECTING、CONNECTED、RECONNECTING、RECONNECTED、CLOSE 一旦客户端开始创建Zookeeper对象，客户端状态就会变成CONNECTING状态。同时客户端开始尝试连接服务端，连接成功后，客户端状态变为CONNECTED.通常情况下，由于断网或其他原因，客户端与服务端出现断开情况，Zookeeper客户端会自动进行重连服务，同时客户端状态再次变成CONNCTING，直到重连上后，状态又变为CONNECTED，一般客户端的状态总是介于CONNECTING和CONNECTED之间。 但是，如果出现诸如会话超时、权限检查或是客户端主动退出程序等情况，客户端的状态就会直接变更为CLOSE状态 5.2 ZK数据模型ZooKeeper的视图结构和标准的Unix文件系统类似，其中每个节点称为“数据节点”或ZNode,每个znode可以存储数据，还可以挂载子节点，因此可以称之为“树”. 注意：创建节点的时候必须设置值，不然节点是创建不成功的。 在Zookeeper中，znode是一个跟Unix文件系统路径相似的节点，可以往这个节点存储或获取数据通过客户端可对znode进行增删改查的操作，还可以注册watcher监控znode的变化。5.3 ZK节点类型 节点类型是非常重要的,是项目实战的基础。 a、Znode有两种类型：短暂（ephemeral）（create -e /testlinshi/linshi test1 客户端断开连接zk删除ephemeral类型节点,即linshi节点） 持久（persistent） （create -p /testlinshi/linshi test2 客户端断开连接zk不删除persistent类型节点） b、Znode有四种形式的目录节点（默认是persistent,持久）PERSISTENT PERSISTENT_SEQUENTIAL（持久序列/test0000000019 ） EPHEMERAL EPHEMERAL_SEQUENTIAL 创建znode时带-s参数即是顺序节点,znode名称后会附加一个值，顺序号是一个单调递增的计数器，由父节点维护 c、在分布式系统中，顺序号可以被用于为所有的事件进行全局排序，这样客户端可以通过顺序号推断事件的顺序. 5.4 zookeeper节点状态属性 如图 5.5 ACL保障数据的安全 举个例子查看znode的ACL信息 ...

一、高可用简介Hadoop 高可用 (High Availability) 分为 HDFS 高可用和 YARN 高可用，两者的实现基本类似，但 HDFS NameNode 对数据存储及其一致性的要求比 YARN ResourceManger 高得多，所以它的实现也更加复杂，故下面先进行讲解： 1.1 高可用整体架构HDFS 高可用架构如下： 图片引用自：https://www.edureka.co/blog/h...HDFS 高可用架构主要由以下组件所构成： Active NameNode 和 Standby NameNode：两台 NameNode 形成互备，一台处于 Active 状态，为主 NameNode，另外一台处于 Standby 状态，为备 NameNode，只有主 NameNode 才能对外提供读写服务。主备切换控制器 ZKFailoverController：ZKFailoverController 作为独立的进程运行，对 NameNode 的主备切换进行总体控制。ZKFailoverController 能及时检测到 NameNode 的健康状况，在主 NameNode 故障时借助 Zookeeper 实现自动的主备选举和切换，当然 NameNode 目前也支持不依赖于 Zookeeper 的手动主备切换。Zookeeper 集群：为主备切换控制器提供主备选举支持。共享存储系统：共享存储系统是实现 NameNode 的高可用最为关键的部分，共享存储系统保存了 NameNode 在运行过程中所产生的 HDFS 的元数据。主 NameNode 和 NameNode 通过共享存储系统实现元数据同步。在进行主备切换的时候，新的主 NameNode 在确认元数据完全同步之后才能继续对外提供服务。DataNode 节点：除了通过共享存储系统共享 HDFS 的元数据信息之外，主 NameNode 和备 NameNode 还需要共享 HDFS 的数据块和 DataNode 之间的映射关系。DataNode 会同时向主 NameNode 和备 NameNode 上报数据块的位置信息。1.2 基于 QJM 的共享存储系统的数据同步机制分析目前 Hadoop 支持使用 Quorum Journal Manager (QJM) 或 Network File System (NFS) 作为共享的存储系统，这里以 QJM 集群为例进行说明：Active NameNode 首先把 EditLog 提交到 JournalNode 集群，然后 Standby NameNode 再从 JournalNode 集群定时同步 EditLog，当 Active NameNode 宕机后， Standby NameNode 在确认元数据完全同步之后就可以对外提供服务。 ...

分布式系统A distributed system is de ned as a software system that is composed of independent computing entities linked together by a computer network whose components communicate and coordinate with each other to achieve a common goal.分布式系统是由独立的计算机通过网络连接在一起，并且通过一些组件来相互交流和协作来完成一个共同的目标。分布式系统特性资源共享，例如存储空间，计算能力，数据，和服务等等扩展性，从软件和硬件上增加系统的规模并发性，多个用户同时访问性能，确保当负载增加的时候，系统想要时间不会有影响容错性，尽管一些组件暂时不可用了，整个系统仍然是可用的API抽象，系统的独立组件对用户隐藏，仅仅暴露服务ZooKeeperZookeeper是一个分布式开源框架，提供了协调分布式应用的基本服务，它向外部应用暴露一组通用服务——分布式同步（Distributed Synchronization）、命名服务（Naming Service）、集群维护（Group Maintenance）等，简化分布式应用协调及其管理的难度，提供高性能的分布式服务。ZooKeeper本身可以以单机模式安装运行，不过它的长处在于通过分布式ZooKeeper集群（一个Leader，多个Follower），基于一定的策略来保证ZooKeeper集群的稳定性和可用性，从而实现分布式应用的可靠性。1、Zookeeper是为别的分布式程序服务的2、Zookeeper本身就是一个分布式程序（只要有半数以上节点存活，zk就能正常服务）3、Zookeeper所提供的服务涵盖：主从协调、服务器节点动态上下线、统一配置管理、分布式共享锁、统一名称服务等4、虽然说可以提供各种服务，但是zookeeper在底层其实只提供了两个功能： 管理(存储，读取)用户程序提交的数据（类似namenode中存放的metadata）并为用户程序提供数据节点监听服务；Zookeeper特性Zookeeper：一个leader，多个follower组成的集群全局数据一致：每个server保存一份相同的数据副本，client无论连接到哪个server，数据都是一致的分布式读写，更新请求转发，由leader实施更新请求顺序进行，来自同一个client的更新请求按其发送顺序依次执行数据更新原子性，一次数据更新要么成功，要么失败实时性，在一定时间范围内，client能读到最新数据Zookeeper数据结构层次化的目录结构，命名符合常规文件系统规范(类似文件系统） 每个节点在zookeeper中叫做znode,并且其有一个唯一的路径标识节点Znode可以包含数据和子节点（但是EPHEMERAL类型的节点不能有子节点）Zookeeper节点类型短暂（ephemeral）（create -e /app1/test1 “test1” 客户端断开连接zk删除ephemeral类型节点）持久（persistent） （create -s /app1/test2 “test2” 客户端断开连接zk不删除persistent类型节点）Znode目录节点PERSISTENTPERSISTENT_SEQUENTIAL（持久序列/test0000000019 ）EPHEMERALEPHEMERAL_SEQUENTIAL（默认是persistent ）创建znode时设置顺序标识，znode名称后会附加一个值，顺序号是一个单调递增的计数器，由父节点维护；在分布式系统中，顺序号可以被用于为所有的事件进行全局排序，这样客户端可以通过顺序号推断事件的顺序 Zookeeper应用场景数据发布与订阅（配置中心）发布与订阅模型，即所谓的配置中心，顾名思义就是发布者将数据发布到ZK节点上，供订阅者动态获取数据，实现配置信息的集中式管理和动态更新。例如全局的配置信息，服务式服务框架的服务地址列表等就非常适合使用。 负载均衡这里说的负载均衡是指软负载均衡。在分布式环境中，为了保证高可用性，通常同一个应用或同一个服务的提供方都会部署多份，达到对等服务。而消费者就须要在这些对等的服务器中选择一个来执行相关的业务逻辑，其中比较典型的是消息中间件中的生产者，消费者负载均衡。消息中间件中发布者和订阅者的负载均衡，linkedin开源的KafkaMQ和阿里开源的 metaq都是通过zookeeper来做到生产者、消费者的负载均衡。这里以metaq为例如讲下：生产者负载均衡：metaq发送消息的时候，生产者在发送消息的时候必须选择一台broker上的一个分区来发送消息，因此metaq在运行过程中，会把所有broker和对应的分区信息全部注册到ZK指定节点上，默认的策略是一个依次轮询的过程，生产者在通过ZK获取分区列表之后，会按照brokerId和partition的顺序排列组织成一个有序的分区列表，发送的时候按照从头到尾循环往复的方式选择一个分区来发送消息。 消费负载均衡： 在消费过程中，一个消费者会消费一个或多个分区中的消息，但是一个分区只会由一个消费者来消费。MetaQ的消费策略是： 每个分区针对同一个group只挂载一个消费者。如果同一个group的消费者数目大于分区数目，则多出来的消费者将不参与消费。如果同一个group的消费者数目小于分区数目，则有部分消费者需要额外承担消费任务。在某个消费者故障或者重启等情况下，其他消费者会感知到这一变化（通过 zookeeper watch消费者列表），然后重新进行负载均衡，保证所有的分区都有消费者进行消费。 命名服务(Naming Service)命名服务也是分布式系统中比较常见的一类场景。在分布式系统中，通过使用命名服务，客户端应用能够根据指定名字来获取资源或服务的地址，提供者等信息。被命名的实体通常可以是集群中的机器，提供的服务地址，远程对象等等——这些我们都可以统称他们为名字（Name）。其中较为常见的就是一些分布式服务框架中的服务地址列表。通过调用ZK提供的创建节点的API，能够很容易创建一个全局唯一的path，这个path就可以作为一个名称。阿里巴巴集团开源的分布式服务框架Dubbo中使用ZooKeeper来作为其命名服务，维护全局的服务地址列表， 点击这里查看Dubbo开源项目。在Dubbo实现中：服务提供者在启动的时候，向ZK上的指定节点/dubbo/${serviceName}/providers目录下写入自己的URL地址，这个操作就完成了服务的发布。服务消费者启动的时候，订阅/dubbo/${serviceName}/providers目录下的提供者URL地址， 并向/dubbo/${serviceName} /consumers目录下写入自己的URL地址。注意，所有向ZK上注册的地址都是临时节点，这样就能够保证服务提供者和消费者能够自动感应资源的变化。 另外，Dubbo还有针对服务粒度的监控，方法是订阅/dubbo/${serviceName}目录下所有提供者和消费者的信息。 ...

下载下载地址：https://archive.apache.org/dist/zookeeper/解压tar -xvf apache-zookeeper-3.5.5.tar.gz删除安装包rm -rf apache-zookeeper-3.5.5.tar.gz重命名mv apache-zookeeper-3.5.5 zookeeper配置环境变量export ZOOKEEPER_HOME=/usr/local/zookeeperexport PATH=$JAVA_HOME/bin:$ZOOKEEPER_HOME/bin:$PATHsource /etc/profile配置ZooKeepercd /usr/local/zookeeper/confmv zoo_sample.cfg zoo.cfg mkdir /usr/local/zookeeper/data vi zoo.cfgzoo.cfg文件中内容如下tickTime=2000dataDir=/usr/local/zookeeper/dataclientPort=2181tickTime：心跳时间，为了确保连接存在的，以毫秒为单位，最小超时时间为两个心跳时间initLimit：多少个心跳时间内，允许其他server连接并初始化数据，如果ZooKeeper管理的数据较大，则应相应增大这个值clientPort：服务的监听端口dataDir：用于存放内存数据库快照的文件夹，同时用于集群的myid文件也存在这个文件夹里（注意：一个配置文件只能包含一个dataDir字样，即使它被注释掉了。）dataLogDir：用于单独设置transaction log的目录，transaction log分离可以避免和普通log还有快照的竞争syncLimit：多少个tickTime内，允许follower同步，如果follower落后太多，则会被丢弃。 server.A=B：C：D：A是一个数字,表示这个是第几号服务器,B是这个服务器的ip地址C第一个端口用来集群成员的信息交换,表示的是这个服务器与集群中的Leader服务器交换信息的端口D是在leader挂掉时专门用来进行选举leader所用 启动Zookeeper/usr/local/zookeeper/bin/zkServer.sh start /usr/local/zookeeper/conf/zoo.cfg 查看ZooKeeper的状态zkServer.sh status

ZooKeeper 介绍ZooKeeper（wiki，home，github） 是用于分布式应用的开源的分布式协调服务。通过暴露简单的原语，分布式应用能在之上构建更高层的服务，如同步、配置管理和组成员管理等。在设计上易于编程开发，并且数据模型使用了熟知的文件系统目录树结构 [doc ]。 共识与 Paxos在介绍 ZooKeeper 之前，有必要了解下 Paxos 和 Chubby。2006 年 Google 在 OSDI 发表关于 Bigtable 和 Chubby 的两篇会议论文，之后再在 2007 年 PODC 会议上发表了论文“Paxos Made Live”，介绍 Chubby 底层实现的共识（consensus）协议 Multi-Paxos，该协议对 Lamport 的原始 Paxos 算法做了改进，提高了运行效率 [ref ]。Chubby 作为锁服务被 Google 应用在 GFS 和 Bigtable 中。受 Chubby 的影响，来自 Yahoo 研究院的 Benjamin Reed 和 Flavio Junqueira 等人开发了被业界称为开源版的 Chubby 的 ZooKeeper（内部实现事实上稍有不同 [ref ]），底层的共识协议为 ZAB。Lamport 的 Paxos 算法出了名的难懂，如何让算法更加可理解（understandable），便成了 Stanford 博士生 Diego Ongaro 的研究课题。Diego Ongaro 在 2014 年发表了介绍 Raft 算法的论文，“In search of an understandable consensus algorithm”。Raft 是可理解版的 Paxos，很快就成为解决共识问题的流行协议之一。这些类 Paxos 协议和 Paxos 系统之间的关系，如下 [Ailijiang2016 ]： ...