zookeeper原理

原理 进程需要访问共享数据时, 就在"/locks"节点下创建一个sequence类型的子节点, 称为thisPath. 当thisPath在所有子节点中最小时, 说明该进程获得了锁. 进程获得锁之后, 就可以访问共享资源了. 访问完成后, 需要将thisPath删除. 锁由新的最小的子节点获得. 进程如何知道thisPath是所有子节点中最小的呢? 可以在创建的时候, 通过getChildren方法获取子节点列表, 然后在列表中找到排名比thisPath前1位的节点, 称为waitPath, 然后在waitPath上注册监听, 当waitPath被删除后, 进程获得通知, 此时说明该进程获得了锁. lock操作过程： 1、创建一个永久性节点，作锁的根目录 2、当要获取一个锁时，在锁目录下创建一个临时有序列的节点 3、检查锁目录的子节点是否有序列比它小，若有则监听比它小的上一个节点，当前锁处于等待状态 4、当等待时间超过Zookeeper session的连接时间（sessionTimeout）时，当前session过期，Zookeeper自动删除此session创建的临时节点，等待状态结束，获取锁失败 5、当监听器触发时，等待状态结束，获得锁 unlock操作过程： 将自己id对应的节点删除即可，对应的下一个排队的节点就可以收到Watcher事件，从而被唤醒得到锁后退出； 来源：

一、高可用简介 Hadoop 高可用 (High Availability) 分为 HDFS 高可用和 YARN 高可用，两者的实现基本类似，但 HDFS NameNode 对数据存储及其一致性的要求比 YARN ResourceManger 高得多，所以它的实现也更加复杂，故下面先进行讲解： 1.1 高可用整体架构 HDFS 高可用架构如下： 图片引用自：https://www.edureka.co/blog/how-to-set-up-hadoop-cluster-with-hdfs-high-availability/ HDFS 高可用架构主要由以下组件所构成： Active NameNode 和 Standby NameNode ：两台 NameNode 形成互备，一台处于 Active 状态，为主 NameNode，另外一台处于 Standby 状态，为备 NameNode，只有主 NameNode 才能对外提供读写服务。 主备切换控制器 ZKFailoverController ：ZKFailoverController 作为独立的进程运行，对 NameNode 的主备切换进行总体控制。ZKFailoverController 能及时检测到 NameNode 的健康状况，在主 NameNode 故障时借助 Zookeeper 实现自动的主备选举和切换，当然

【ZOOKEEPER系列】Paxos、Raft、ZAB 2018-07-11 12:09:49 wangzy-nice 阅读数 2428 更多 分类专栏： zookeeper 版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。 本文链接： https://blog.csdn.net/qq_34370153/article/details/80998622 ZOOKEEPER系列 Paxos、Raft、ZAB Paxos算法 莱斯利·兰伯特（Leslie Lamport）这位大牛在1990年提出的一种基于消息传递且具有高度容错特性的一致性算法。如果你不知道这个人，那么如果你发表过Paper，就一定用过Latex,也是这位大牛的创作， 具体背景直接维基百科就可以，不深入讲解，直接讲Paxos算法。 分布式系统对fault tolorence 的一般解决方案是state machine replication。准确的描述Paxos应该是state machine replication的共识（consensus）算法。 Leslie Lamport写过一篇Paxos made simple的paper，没有一个公式，没有一个证明，这篇文章显然要比Leslie Lamport之前的关于Paxos的论文更加容易理解，但是

=====================================斩秋| http://blog.csdn.net/quhongwei_zhanqiu ======================================= Zookeeper集群启动的入口类是QuorumPeerMain来加载配置启动QuorumPeer线程。首先我们来看下QuorumPeer， 谷歌翻译quorum是法定人数，定额的意思， peer是对等的意思，那么QuorumPeer中quorum代表的意思就是每个zookeeper集群启动的时候集群中zookeeper服务数量就已经确定了，在每个zookeeper的配置文件中配置集群中的所有机器 server.1=127.0.0.1:2886:3886 server.2=127.0.0.1:2887:3887 server.3=127.0.0.1:2888:3888 事实上着也确定zookeeper在运行中是不能动态扩容的，必须停下服务修改配置才可以；QuorumPeer中peer代表就是集中每个zookeeper角色是对等的没有主从之分，每个zookeeper服务都可以成为leader， follower，observer。 1. QuorumPeerMain加载 1） QuorumPeerConfig读取配置文件，如下面的zoo.cfg文件

前言 关于kafka的工作机制，已经在上篇博文： Kafka原理及单机部署 中详细写出来，这里只是将kafka的一个群集部署写了出来。 博文大纲： 一、环境准备 二、部署zookeeper服务 三、部署kafka集群 一、环境准备 部署kafka群集所需的安装包，可以从我的网盘链接中 下载 。 二、部署zookeeper服务 1、主机kafka01配置如下 #部署zookeeper [root@kafka01 src]# tar zxf zookeeper-3.4.9.tar.gz [root@kafka01 src]# mv zookeeper-3.4.9 /usr/local/zookeeper #修改配置文件 [root@kafka01 src]# cd /usr/local/zookeeper/conf/ [root@kafka01 conf]# cp -p zoo_sample.cfg zoo.cfg [root@kafka01 conf]# sed -i 's/dataDir=\/tmp\/zookeeper/dataDir=\/usr\/local\/zookeeper\/data/g' zoo.cfg #直接群集节点信息，2888和3888端口用于群集内部通信 [root@kafka01 conf]# echo "server.1 192.168.20.2:2888

原文链接 NameNode 高可用整体架构概述 在 Hadoop 1.0 时代，Hadoop 的两大核心组件 HDFS NameNode 和 JobTracker 都存在着单点问题，这其中以 NameNode 的单点问题尤为严重。因为 NameNode 保存了整个 HDFS 的元数据信息，一旦 NameNode 挂掉，整个 HDFS 就无法访问，同时 Hadoop 生态系统中依赖于 HDFS 的各个组件，包括 MapReduce、Hive、Pig 以及 HBase 等也都无法正常工作，并且重新启动 NameNode 和进行数据恢复的过程也会比较耗时。这些问题在给 Hadoop 的使用者带来困扰的同时，也极大地限制了 Hadoop 的使用场景，使得 Hadoop 在很长的时间内仅能用作离线存储和离线计算，无法应用到对可用性和数据一致性要求很高的在线应用场景中。 所幸的是，在 Hadoop2.0 中，HDFS NameNode 和 YARN ResourceManger(JobTracker 在 2.0 中已经被整合到 YARN ResourceManger 之中) 的单点问题都得到了解决，经过多个版本的迭代和发展，目前已经能用于生产环境。HDFS NameNode 和 YARN ResourceManger 的高可用 (High Availability，HA) 方案基本类似