1、上传 解压2、配置环境变量exportZOOKEEPER_HOME=/root/Downloads/zookeeper-3.4.5exportPATH=$PATH:$ZOOKEEPER_HOME/bin:$ZOOKEEPER_HOME/sbin 3、在zk下创建data文件　　创建data文件---------在data下创建myid给各个机器编号　　mkdirdata----------touchmyid----------（从第一台开始） 4、创建logs文件　　mkdirlogs 5、在zookeeper路径下 修改conf配置文件 dataDir=/root/Downloads/zookeeper-3.4.5/datadataLogDir=/root/Downloads/zookeeper-3.4.5/logsserver.1=linux04:2888:3888server.2=linux05:2888:3888server.3=linux06:2888:3888...

项目描述：今天花了680元买了阿里云的一台内存1G,带宽1M的云主机.想以后方便测试用,而且想把自己的博客签到自己的主机上.所以自己就搭了一个测试的环境.可以用来进行基本的hbase入库,hadoop mrjob的运行.步骤：1.配置JDK我的安装路径如下:/usr/local/java/jdk1.7.0_79设置环境变量:JAVA_HOME=/usr/local/java/jdk1.7.0_79exportPATH=$JAVA_HOME/bin:$PATH刷新配置source/etc/profile2.安装zookeeper解压:在conf目录下创建一个配置文件zoo.cfg，并修改内容:tickTime=2000dataDir=/zzy/zookeeper-standlone/datadataLogDir=/zzy/zookeeper-standlone/datalogclientPort=2181启动:./zkServer.shstart 验证:jpsQuorumPeerMain3.安装hadoop（伪分布）解压：tar-zxvfhadoop.2.6.0.ta...

ZookeeperInvalidconfig,exitingabnormally  出现Invalidconfig,exitingabnormally的情况可能有3个：是否开启了日志输出路径dataLogDir，如果开启了检查是不是创建了所需的文件夹检查myid是不是在dataDir=/zzy/zookeeper-3.4.5/tmp（tmp需要自己建立）目录下。myid是不是有此文件，并且有值。...

关键节点的单点故障(SinglePointofFailure)在大型的架构中，往往是致命的。比如：SOA架构中，服务注册中心(ServerRegister)统一调度所有服务，如果这个节点挂了，基本上整个SOA架构也就崩溃了，另外hadoop1.x/2.x中的namenode节点，这是hdfs的核心节点，如果namenode宕掉，hdfs也就废了。ZooKeeper的出现，很好的解决了这一难题，其核心原理如下：1.关键节点的运行实例（或服务器），可以跑多个，这些实例中的数据完全是相同的（即：对等设计），每个实例启动后，向ZK注册一个临时顺序节点，比如/core-servers/server0000001,/core-servers/server0000002...，最后的顺序号是由ZK自动递增的2.其它应用需要访问1中的核心服务器里，可以事先约定好，从ZK的这些临时节点中，挑选一个序号最小的节点，做为主服务器（即master）3.当master宕掉时，超过一定的时间阈值，临时节点将由ZK自动删除，这样原来序列最小的节点也就没了，客户端应用按2中的约定找最小节点的服务器时，自动会找到原来次...

大型应用通常会按业务拆分成一个个业务子系统，这些大大小小的子应用，往往会使用一些公用的资源，比如：需要文件上传、下载时，各子应用都会访问公用的Ftp服务器。如果把FtpServer的连接IP、端口号、用户名、密码等信息，配置在各子应用中，然后这些子应用再部署到服务器集群中的N台Server上，突然有一天，Ftp服务器要换IP或端口号，那么问题来了？不要紧张，不是问挖掘机哪家强：），而是如何快速的把这一堆已经在线上运行的子应用，通通换掉相应的配置，而且还不能停机。要解决这个问题，首先要从思路上做些改变：1、公用配置不应该分散存放到各应用中，而是应该抽出来，统一存储到一个公用的位置（最容易想到的办法，放在db中，或统一的分布式cacheserver中，比如Redis，或其它类似的统一存储，比如ZooKeeper中）2、对这些公用配置的添加、修改，应该有一个统一的配置管理中心应用来处理（这个也好办，做一个web应用来对这些配置做增、删、改、查即可）3、当公用配置变化时，子应用不需要重新部署（或重新启动），就能使用新的配置参数（比较容易想到的办法有二个：一是发布/订阅模式，子应用主动订阅公用配...

ZK中的每个节点都可以存储一些轻量级的数据，这些数据的变化会同步到集群中的其它机器。在应用中程序员可以添加watcher来监听这些数据的变化，watcher只会触发一次，所以触发过后想要继续监听，必须再手动设置监听，这比较麻烦，好在ZkClient已经做了一些增强，在watcher的基础上，封装了所谓的Listener，开发人员只需要订阅Listener即可。packageyjmyzz.test;importcom.cnblogs.yjmyzz.domain.BaseBean;importorg.I0Itec.zkclient.IZkDataListener;importorg.I0Itec.zkclient.ZkClient;importorg.junit.After;importorg.junit.Before;importorg.junit.Test;importjava.util.concurrent.TimeUnit;publicclassZKTestextendsBaseBean{privateZkClientzk;privateStringnodeName="/myApp...

先给一堆学习文档，方便以后查看官网文档地址大全：OverView(概述)http://zookeeper.apache.org/doc/r3.4.6/zookeeperOver.htmlGettingStarted(开始入门)http://zookeeper.apache.org/doc/r3.4.6/zookeeperStarted.htmlTutorial（教程）http://zookeeper.apache.org/doc/r3.4.6/zookeeperTutorial.htmlJavaExample(Java示例)http://zookeeper.apache.org/doc/r3.4.6/javaExample.htmlProgrammer'sGuide(开发人员指南)http://zookeeper.apache.org/doc/r3.4.6/zookeeperProgrammers.htmlRecipesandSolutions(技巧及解决方案)http://zookeeper.apache.org/doc/r3.4.6/recipes.html3.4.6APIonli...

本文的主题就是讲解Zookeeper通信模型，本节将通过一个概要图来说明Zookeeper的通信模型。  在Zookeeper整个系统中，有3中角色的服务，client、Follower、leader。其中client负责发起应用的请求，Follower接受client发起的请求，参与事务的确认过程，在leadercrash后的leader选择。而leader主要承担事务的协调，当然leader也可以承担接收客户请求的功能，为了方便描述，后面的描述都是client与Follower之间的通信，如果Zookeeper的配置支持leader接收client的请求，client与leader的通信跟client与Follower的通信模式完全一样。Follower与leader之间的角色可能在某一时刻进行转换。一个Follower在leadercrash掉以后可能被集群（Quorum）的Follower选举为leader。而一个leader在crash后，再次加入集群（Quorum）将作为Follower角色存在。在一个集群（Quorum）中,除了在选举leader的过程...

Zookeeper的Client直接与用户打交道，是我们使用Zookeeper的interface。了解ZKClient的结构和工作原理有利于我们合理的使用ZK，并能在使用中更早的发现问题。本文将在研究源码的技术上讲述ZKClient的工作原理及内部工作机制。在看完ZKClient的大致架构以后我希望能有一种简单的方式描述ZKClient的基本结构，想来想去我觉得还是图片比较能反映情况，于是我画了这张大致的结构图： 我想既然我画了这张图，就让我们从这张图开始讲起吧。 模块：我们可以认为ZK的Client由三个主要模块组成：Zookeeper,WatcherManager,ClientCnxnZookeeper是ZKClient端的真正接口，用户可以操作的最主要的类，当用户创建一个Zookeeper实例以后，几乎所有的操作都被这个实例包办了，用户不用关心怎么连接到Server，Watcher什么时候被触发等等令人伤神的问题。WatcherManager，顾名思义，它是用来管理Watcher的，Watcher是ZK的一大特色功能，允许多个Client对一个或多个ZNod...

原计划在介绍完ZKClient之后就着手ZKServer的介绍，但是发现ZKServer所包含的内容实在太多，并不是简简单单一篇Blog就能搞定的。于是决定从基础搞起比较好。那么ZKServer最基础的东西是什么呢？我想应该是Paxos了。所以本文会介绍Paxos以及它在ZKServer中对应的实现。先说Paxos，它是一个基于消息传递的一致性算法，LeslieLamport在1990年提出，近几年被广泛应用于分布式计算中，Google的Chubby，Apache的Zookeeper都是基于它的理论来实现的，Paxos还被认为是到目前为止唯一的分布式一致性算法，其它的算法都是Paxos的改进或简化。有个问题要提一下，Paxos有一个前提：没有拜占庭将军问题。就是说Paxos只有在一个可信的计算环境中才能成立，这个环境是不会被入侵所破坏的。关于Paxos的具体描述可以在Wiki中找到：http://zh.wikipedia.org/zh-cn/Paxos算法。网上关于Paxos分析的文章也很多。这里希望用最简单的方式加以描述并建立起Paxos和ZKServer的对应关系。Paxos描述了...

Zookeeper作为一个分布式的服务框架，主要用来解决分布式集群中应用系统的一致性问题，它能提供基于类似于文件系统的目录节点树方式的数据存储，但是Zookeeper并不是用来专门存储数据的，它的作用主要是用来维护和监控你存储的数据的状态变化。通过监控这些数据状态的变化，从而可以达到基于数据的集群管理，后面将会详细介绍Zookeeper能够解决的一些典型问题，这里先介绍一下，Zookeeper的操作接口和简单使用示例。 客户端要连接Zookeeper服务器可以通过创建org.apache.zookeeper.ZooKeeper的一个实例对象，然后调用这个类提供的接口来和服务器交互。前面说了ZooKeeper主要是用来维护和监控一个目录节点树中存储的数据的状态，所有我们能够操作ZooKeeper的也和操作目录节点树大体一样，如创建一个目录节点，给某个目录节点设置数据，获取某个目录节点的所有子目录节点，给某个目录节点设置权限和监控这个目录节点的状态变化。这些接口如下表所示：表1org.apache.zookeeper.ZooKeeper方法列表方法名方法功能描述String&nb...

译自http://zookeeper.apache.org/doc/trunk/zookeeperProgrammers.html本文是为想要创建使用ZooKeeper协调服务优势的分布式应用的开发者准备的。本文包含理论信息和实践信息。本指南的前四节对各种ZooKeeper概念进行较高层次的讨论。这些概念对于理解ZooKeeper是如何工作的，以及如何使用ZooKeeper来进行工作都是必要的。这几节没有代码，但却要求读者对分布式计算相关的问题较为熟悉。这四节是：l         ZooKeeper数据模型l         ZooKeeper会话l         ZooKeeper观察l         一致性保证接下来的四节...

译自http://zookeeper.apache.org/doc/trunk/zookeeperOver.htmlZooKeeper是一个用于分布式应用的开源分布式协调服务。它提供了简单的原语集合，分布式应用可在这些原语之上构建用于同步、配置维护、分组和命名的高层服务。ZooKeeper的设计使得编程容易，并且使用类似于广泛熟知的文件系统目录树结构的数据模型。它运行在Java环境中，但是有Java和C语言绑定。分布式协调服务是出了名的难得编写正确，很容易出现竞争条件和死锁之类的错误。ZooKeeper的动机是减轻为分布式应用开发协调服务的负担。ZooKeeper让分布式进程可通过共享的、与标准文件系统类似的分层名字空间相互协调。名字空间由数据寄存器（在ZooKeeper世界中称作znode）构成，这与文件和目录类似。与用于存储设备的典型文件系统不同的是，ZooKeeper在内存中保存数据，这让其可以达到高吞吐量和低延迟。ZooKeeper的实现很重视高性能、高可用性，以及严格的顺序访问。高性能意味着可将ZooKeeper用于大的分布式系统。可靠性使之可避免单点失败。严格的顺序访问使得...

ZooKeeper是一个高可用的分布式数据管理与系统协调框架。基于对Paxos算法的实现，使该框架保证了分布式环境中数据的强一致性，也正是基于这样的特性，使得ZooKeeper解决很多分布式问题。网上对ZK的应用场景也有不少介绍，本文将结合作者身边的项目例子，系统地对ZK的应用场景进行一个分门归类的介绍。值得注意的是，ZK并非天生就是为这些应用场景设计的，都是后来众多开发者根据其框架的特性，利用其提供的一系列API接口（或者称为原语集），摸索出来的典型使用方法。因此，也非常欢迎读者分享你在ZK使用上的奇技淫巧。 ZooKeeper典型应用场景一览数据发布与订阅（配置中心）发布与订阅模型，即所谓的配置中心，顾名思义就是发布者将数据发布到ZK节点上，供订阅者动态获取数据，实现配置信息的集中式管理和动态更新。例如全局的配置信息，服务式服务框架的服务地址列表等就非常适合使用。应用中用到的一些配置信息放到ZK上进行集中管理。这类场景通常是这样：应用在启动的时候会主动来获取一次配置，同时，在节点上注册一个Watcher，这样一来，以后每次配置有更新的时候，都会实时通知到订阅的客户端，从来...

　　目前分布式锁，比较成熟、主流的方案有基于redis及基于zookeeper的二种方案。　　大体来讲，基于redis的分布式锁核心指令为SETNX，即如果目标key存在，写入缓存失败返回0，反之如果目标key不存在，写入缓存成功返回1，通过区分这二个不同的返回值，可以认为SETNX成功即为获得了锁。　　redis分布式锁，看上去很简单，但其实要考虑周全，并不容易，网上有一篇文章讨论得很详细：http://blog.csdn.net/ugg/article/details/41894947/，有兴趣的可以阅读一下。　　其主要问题在于某些异常情况下，锁的释放会有问题，比如SETNX成功，应用获得锁，这时出于某种原因，比如网络中断，或程序出异常退出，会导致锁无法及时释放，只能依赖于缓存的过期时间，但是过期时间这个值设置多大，也是一个纠结的问题，设置小了，应用处理逻辑很复杂的话，可能会导致锁提前释放，如果设置大了，又会导致锁不能及时释放，所以那篇文章中针对这些细节讨论了很多。　　而基于zk的分布式锁，在锁的释放问题上处理起来要容易一些，其大体思路是利用zk的“临时顺序&rdquo...