之前整理过一篇文章《》，本文介绍的 Zookeeper 是以 3.4.5 这个稳定版本为基础，最新的版本可以通过官网 来获取，Zookeeper 的安装非常简单，下面将从单机模式和集群模式两个方面介绍 Zookeeper 的Windows安装和配置.
首先需要安装JdK，从Oracle的Java网站下载，安装很简单，就不再详述。
单机安装非常简单，只要获取到 Zookeeper 的压缩包并解压到某个目录如：C:\zookeeper-3.4.5\下，Zookeeper 的启动脚本在 bin 目录下，Windows 下的启动脚本是 zkServer.cmd。
在你执行启动脚本之前，还有几个基本的配置项需要配置一下，Zookeeper 的配置文件在 conf 目录下，这个目录下有 zoo_sample.cfg 和 log4j.properties，你需要做的就是将 zoo_sample.cfg 改名为 zoo.cfg，因为 Zookeeper 在启动时会找这个文件作为默认配置文件。下面详细介绍一下，这个配置文件中各个配置项的意义。
# The number of milliseconds of each tick
tickTime=2000
# The number of ticks that the initial
# synchronization phase can take
initLimit=10
# The number of ticks that can pass between
# sending a request and getting an acknowledgement
syncLimit=5
# the directory where the snapshot is stored.
# do not use /tmp for storage, /tmp here is just
# example sakes.
dataDir=C:\\zookeeper-3.4.5\\data
dataLogDir=C:\\zookeeper-3.4.5\\log
# the port at which the clients will connect
clientPort=2181
# 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
tickTime：这个时间是作为 Zookeeper 服务器之间或客户端与服务器之间维持心跳的时间间隔，也就是每个 tickTime 时间就会发送一个心跳。
dataDir：顾名思义就是 Zookeeper 保存数据的目录，默认情况下，Zookeeper 将写数据的日志文件也保存在这个目录里。
dataLogDir：顾名思义就是 Zookeeper 保存日志文件的目录
clientPort：这个端口就是客户端连接 Zookeeper 服务器的端口，Zookeeper 会监听这个端口，接受客户端的访问请求。
当这些配置项配置好后，你现在就可以启动 Zookeeper 了，启动后要检查 Zookeeper 是否已经在服务，可以通过 netstat & ano 命令查看是否有你配置的 clientPort 端口号在监听服务。
Zookeeper 不仅可以单机提供服务，同时也支持多机组成集群来提供服务。实际上 Zookeeper 还支持另外一种伪集群的方式，也就是可以在一台物理机上运行多个 Zookeeper 实例，下面将介绍集群模式的安装和配置。
Zookeeper 的集群模式的安装和配置也不是很复杂，所要做的就是增加几个配置项。集群模式除了上面的三个配置项还要增加下面几个配置项：
initLimit=5&
syncLimit=2&
server.1=192.168.211.1:&
server.2=192.168.211.2:
initLimit：这个配置项是用来配置 Zookeeper 接受客户端（这里所说的客户端不是用户连接 Zookeeper 服务器的客户端，而是 Zookeeper 服务器集群中连接到 Leader 的 Follower 服务器）初始化连接时最长能忍受多少个心跳时间间隔数。当已经超过 10 个心跳的时间（也就是 tickTime）长度后 Zookeeper 服务器还没有收到客户端的返回信息，那么表明这个客户端连接失败。总的时间长度就是 5*2000=10 秒
syncLimit：这个配置项标识 Leader 与 Follower 之间发送消息，请求和应答时间长度，最长不能超过多少个 tickTime 的时间长度，总的时间长度就是 2*2000=4 秒
server.A=B：C：D：其中 A 是一个数字，表示这个是第几号服务器；B 是这个服务器的 ip 地址；C 表示的是这个服务器与集群中的 Leader 服务器交换信息的端口；D 表示的是万一集群中的 Leader 服务器挂了，需要一个端口来重新进行选举，选出一个新的 Leader，而这个端口就是用来执行选举时服务器相互通信的端口。如果是伪集群的配置方式，由于 B 都是一样，所以不同的 Zookeeper 实例通信端口号不能一样，所以要给它们分配不同的端口号。
除了修改 zoo.cfg 配置文件，集群模式下还要配置一个文件 myid，这个文件在 dataDir 目录下，这个文件里面就有一个数据就是 A 的值，Zookeeper 启动时会读取这个文件，拿到里面的数据与 zoo.cfg 里面的配置信息比较从而判断到底是那个 server。
Zookeeper 会维护一个具有层次关系的数据结构，它非常类似于一个标准的文件系统，如图 1 所示：
Zookeeper 这种数据结构有如下这些特点：
每个子目录项如 NameService 都被称作为 znode，这个 znode 是被它所在的路径唯一标识，如 Server1 这个 znode 的标识为 /NameService/Server1
znode 可以有子节点目录，并且每个 znode 可以存储数据，注意 EPHEMERAL 类型的目录节点不能有子节点目录
znode 是有版本的，每个 znode 中存储的数据可以有多个版本，也就是一个访问路径中可以存储多份数据
znode 可以是临时节点，一旦创建这个 znode 的客户端与服务器失去联系，这个 znode 也将自动删除，Zookeeper 的客户端和服务器通信采用长连接方式，每个客户端和服务器通过心跳来保持连接，这个连接状态称为 session，如果 znode 是临时节点，这个 session 失效，znode 也就删除了
znode 的目录名可以自动编号，如 App1 已经存在，再创建的话，将会自动命名为 App2
znode 可以被监控，包括这个目录节点中存储的数据的修改，子节点目录的变化等，一旦变化可以通知设置监控的客户端，这个是 Zookeeper 的核心特性，Zookeeper 的很多功能都是基于这个特性实现的，后面在典型的应用场景中会有实例介绍
Zookeeper 作为一个分布式的服务框架，主要用来解决分布式集群中应用系统的一致性问题，它能提供基于类似于文件系统的目录节点树方式的数据存储，但是 Zookeeper 并不是用来专门存储数据的，它的作用主要是用来维护和监控你存储的数据的状态变化。通过监控这些数据状态的变化，从而可以达到基于数据的集群管理.
通过C#代码使用zookeeper
Zookeeper的使用主要是通过创建其Nuget ZooKeeperNet包下的Zookeeper实例，并且调用其接口方法进行的，主要的操作就是对znode的增删改操作，监听znode的变化以及处理。
using System.Collections.G
using System.L
using System.T
using ZooKeeperN
namespace ZookeeperDemo
class Watcher : IWatcher
public void Process(WatchedEvent @event)
if (@event.Type == EventType.NodeDataChanged)
Console.WriteLine(@event.Path);
using System.Collections.G
using System.L
using System.T
using ZooKeeperN
namespace ZookeeperDemo
class Program
static void Main(string[] args)
//创建一个Zookeeper实例，第一个参数为目标服务器地址和端口，第二个参数为Session超时时间，第三个为节点变化时的回调方法
using (ZooKeeper zk = new ZooKeeper("127.0.0.1:2181", new TimeSpan(0, 0, 0, 50000), new Watcher()))
var stat = zk.Exists("/root",true);
////创建一个节点root，数据是mydata,不进行ACL权限控制，节点为永久性的(即客户端shutdown了也不会消失)
//zk.Create("/root", "mydata".GetBytes(), Ids.OPEN_ACL_UNSAFE, CreateMode.Persistent);
//在root下面创建一个childone znode,数据为childone,不进行ACL权限控制，节点为永久性的
zk.Create("/root/childone", "childone".GetBytes(), Ids.OPEN_ACL_UNSAFE, CreateMode.Persistent);
//取得/root节点下的子节点名称,返回List&String&
zk.GetChildren("/root", true);
//取得/root/childone节点下的数据,返回byte[]
zk.GetData("/root/childone", true, null);
//修改节点/root/childone下的数据，第三个参数为版本，如果是-1，那会无视被修改的数据版本，直接改掉
zk.SetData("/root/childone", "childonemodify".GetBytes(), -1);
//删除/root/childone这个节点，第二个参数为版本，－1的话直接删除，无视版本
zk.Delete("/root/childone", -1);
创建连接：
1.获取服务主机列表
2.设置超时时间
3.注册客户端事件
4.以线程安全的方式创建请求连接（启动客户端请求队列，循环队列基于socket通信、根据请求类型执行不同的请求动作）
请求流程：
构造请求头、构造request,reponse、构造响应头、构造Packet对象,packet对象准备好后，把整个对象放入一个outgoingQueue packet被放入outgoingQueue中，等待SendThread把packet对应的内容发送给server。server处理分3步在doio方法中ReadLength ReadConnectResult ReadResponse，直到ReadResponse方法中确定packet请求结束。
响应流程：
针对心跳的ping请求的resp，针对auth请求的resp，一般接口请求的resp，如果接口请求要求了watcher，当watcher关注的内容有变化时的notification
锁相关部分API方法：
创建节点：create
demo：zk.Create(Dir, severname.GetBytes(), Ids.OPEN_ACL_UNSAFE, CreateMode.Persistent);
其中CreateMode分为4类Persistent、PersistentSequential、Ephemeral、EphemeralSequential
PERSISTENT 创建持久化节点，对应机器关闭连接后节点/数据不会消失
PERSISTENT_SEQUENTIAL 如果PATH是以&/&结尾则以这个PATH作为父节点，创建一个子节点，其子节点名字是一个按先后顺序排列的数值；否则创建一个名字是&/&后面字符加上先后顺序排列的数值字符串的节点，同样创建持久节点
EPHEMERAL 创建瞬时节点，Zookeeper在感知连接机器宕机后会清除它创建的瞬时节点
EPHEMERAL_SEQUENTIAL 穿件瞬时顺序节点，和PERSISTENT_SEQUENTIAL一样，区别在于它是瞬时的
删除节点 delete
demo ：zk.Delete(Dir, -1);
前一个参数代表节点名称（一般用作路径），后一个是版本号 -1表示全匹配
查看节点 exists
demo ： zk.Exists(Dir, new MyWatch2());
获取数据 getData
demo ：zk.GetData(Dir, new MyWatch2(), stat);
获取一个节点的数据，可注入watcher&
设置数据 setData
demo ： zk.SetData(Dir, new byte[1], 1);
获取下级节点集合 GetChildren
demo ：zk.GetChildren(Dir, true);
znodes类似文件和目录。但它不是一个典型的文件系统，zookeeper数据保存在内存中，这意味着zookeeper可以实现高吞吐量和低延迟。
Zookeeper有两种watches，一种是data watches，另一种是child watches。其中，getData()和exists()以及create()等会添加data watches，getChildren()会添加child watches。而delete()涉及到删除数据和子节点，会同时触发data watches和child watches。
示例代码下载：
相关文章：
基于ZooKeeper构建大规模配置系统II
分布式服务框架 Zookeeper -- 管理分布式环境中的数据
基于ZooKeeper的分布式Session实现
ZooKeeper介绍、分析、理解&&
ZooKeeper实现分布式队列Queue &
李欣：ZooKeeper在携程的使用及前景
阅读(...) 评论()为什么不应该使用ZooKeeper做服务发现
-------------
新增文件夹...
新增文件夹
(多个标签用逗号分隔)
本文作者通过ZooKeeper与Eureka作为 （注：WebServices 体系中的UDDI就是个发现服务）的优劣对比，分享了Knewton在云计算平台部署服务的经验。本文虽然略显偏激，但是看得出Knewton在云平台方 面是非常有经验的，这篇文章从实践角度出发分别从云平台特点、CAP原理以及运维三个方面对比了ZooKeeper与Eureka两个系统作为发布服务的 优劣，并提出了在云平台构建发现服务的方法论。
很多公司选择使用 作为Service发现服务（Service Discovery），但是在构建 （Knewton 是一个提供个性化教育平台的公司、学校和出版商可以通过Knewton平台为学生提供自适应的学习材料）平台时，我们发现这是个根本性的错误。在这边文章 中，我们将用我们在实践中遇到的问题来说明，为什么使用ZooKeeper做Service发现服务是个错误。
请留意服务部署环境
让我们从头开始梳理。我们在部署服务的时候，应该首先考虑服务部署的平台（平台环境），然后才能考虑平台上跑的软件 系统或者如何在选定的平台上自己构建一套系统。例如，对于云部署平台来说，平台在硬件层面的伸缩（注：作者应该指的是系统的冗余性设计，即系统遇到单点失 效问题，能够快速切换到其他节点完成任务）与如何应对网络故障是首先要考虑的。当你的服务运行在大量服务器构建的集群之上时（注：原话为大量可替换设 备），则肯定会出现单点故障的问题。对于knewton来说，我们虽然是部署在AWS上的，但是在过往的运维中，我们也遇到过形形色色的故障；所以，你应 该把系统设计成“故障开放型”（expecting failure）的。其实有很多同样使用AWS的 跟我们遇到了（同时有很多 是介绍这方面的）相似的问题。你必须能够提前预料到平台可能会出现的问题如：意外故障（注：原文为box failure，只能意会到作者指的是意外弹出的错误提示框），高延迟与 （注：原文为network partitions。意思是当网络交换机出故障会导致不同子网间通讯中断）——同时我们要能构建足够弹性的系统来应对它们的发生。
永远不要期望你部署服务的平台跟其他人是一样的！当然，如果你在独自运维一个数据中心，你可能会花很多时间与钱来避免硬件故障与网络分割问题，这 是另一种情况了；但是在云计算平台中，如AWS，会产生不同的问题以及不同的解决方式。当你实际使用时你就会明白，但是，你最好提前应对它们（注：指的是 上一节说的意外故障、高延迟与网络分割问题）的发生。
ZooKeeper作为发现服务的问题
ZooKeeper（注：ZooKeeper是著名Hadoop的一个子项目，旨在解决大规模分 布式应用场景下，服务协调同步（Coordinate Service）的问题；它可以为同在一个分布式系统中的其他服务提供：统一命名服务、配置管理、分布式锁服务、集群管理等功能）是个伟大的开源项目，它 很成熟，有相当大的社区来支持它的发展，而且在生产环境得到了广泛的使用；但是用它来做Service发现服务解决方案则是个错误。
在分布式系统领域有个著名的 （C- 数据一致性；A-服务可用性；P-服务对网络分区故障的容错性，这三个特性在任何分布式系统中不能同时满足，最多同时满足两个）；ZooKeeper是个 CP的，即任何时刻对ZooKeeper的访问请求能得到一致的数据结果，同时系统对网络分割具备容错性；但是它不能保证每次服务请求的可用性（注：也就 是在极端环境下，ZooKeeper可能会丢弃一些请求，消费者程序需要重新请求才能获得结果）。但是别忘了，ZooKeeper是分布式协调服务，它的 职责是保证数据（注：配置数据，状态数据）在其管辖下的所有服务之间保持同步、一致；所以就不难理解为什么ZooKeeper被设计成CP而不是AP特性 的了，如果是AP的，那么将会带来恐怖的后果（注：ZooKeeper就像交叉路口的信号灯一样，你能想象在交通要道突然信号灯失灵的情况吗？）。而且， 作为ZooKeeper的核心实现算法 ，就是解决了分布式系统下数据如何在多个服务之间保持同步问题的。
作为一个分布式协同服务，ZooKeeper非常好，但是对于Service发现服务来说就不合适了；因为对于Service发现服务来说就算是 返回了包含不实的信息的结果也比什么都不返回要好；再者，对于Service发现服务而言，宁可返回某服务5分钟之前在哪几个服务器上可用的信息，也不能 因为暂时的网络故障而找不到可用的服务器，而不返回任何结果。所以说，用ZooKeeper来做Service发现服务是肯定错误的，如果你这么用就惨 了！
而且更何况，如果被用作Service发现服务，ZooKeeper本身并没有正确的处理网络分割的问题；而在云端，网络分割问题跟其他类型的故障一样的确会发生；所以最好提前对这个问题做好100%的准备。就像 在 ZooKeeper网站上发布的博客中所说：在ZooKeeper中，如果在同一个网络分区（partition）的节点数（nodes）数达不到 ZooKeeper选取Leader节点的“法定人数”时，它们就会从ZooKeeper中断开，当然同时也就不能提供Service发现服务了。
如果给ZooKeeper加上客户端缓存（注：给ZooKeeper节点配上本地缓存）或者其他类似技术的话可以缓解ZooKeeper因为网络故障造成节点同步信息错误的问题。 与 公 司就使用了这个方法来防止ZooKeeper故障发生。这种方式可以从表面上解决这个问题，具体地说，当部分或者所有节点跟ZooKeeper断开的情况 下，每个节点还可以从本地缓存中获取到数据；但是，即便如此，ZooKeeper下所有节点不可能保证任何时候都能缓存所有的服务注册信息。如果 ZooKeeper下所有节点都断开了，或者集群中出现了网络分割的故障（注：由于交换机故障导致交换机底下的子网间不能互访）；那么ZooKeeper 会将它们都从自己管理范围中剔除出去，外界就不能访问到这些节点了，即便这些节点本身是“健康”的，可以正常提供服务的；所以导致到达这些节点的服务请求 被丢失了。（注：这也是为什么ZooKeeper不满足CAP中A的原因）
更深层次的原因是，ZooKeeper是按照CP原则构建的，也就是说它能保证每个节点的数据保持一致，而为ZooKeeper加上缓存的做法的 目的是为了让ZooKeeper变得更加可靠（available）；但是，ZooKeeper设计的本意是保持节点的数据一致，也就是CP。所以，这样 一来，你可能既得不到一个数据一致的（CP）也得不到一个高可用的（AP）的Service发现服务了；因为，这相当于你在一个已有的CP系统上强制栓了 一个AP的系统，这在本质上就行不通的！一个Service发现服务应该从一开始就被设计成高可用的才行！
如果抛开CAP原理不管，正确的设置与维护ZooKeeper服务就非常的困难；错误会 ， 导致很多工程被建立只是为了减轻维护ZooKeeper的难度。这些错误不仅存在与客户端而且还存在于ZooKeeper服务器本身。Knewton平台 很多故障就是由于ZooKeeper使用不当而导致的。那些看似简单的操作，如：正确的重建观察者（reestablishing watcher）、客户端Session与异常的处理与在ZK窗口中管理内存都是非常容易导致ZooKeeper出错的。同时，我们确实也遇到过 ZooKeeper的一些经典bug：
与 ； 我们甚至在生产环境中遇到过ZooKeeper选举Leader节点失败的情况。这些问题之所以会出现，在于ZooKeeper需要管理与保障所管辖服务 群的Session与网络连接资源（注：这些资源的管理在分布式系统环境下是极其困难的）；但是它不负责管理服务的发现，所以使用ZooKeeper当 Service发现服务得不偿失。
做出正确的选择：Eureka的成功
我们把Service发现服务从ZooKeeper切换到了Eureka平台，它是一个开 源的服务发现解决方案，由Netflix公司开发。（注：Eureka由两个组件组成：Eureka服务器和Eureka客户端。Eureka服务器用作 服务注册服务器。Eureka客户端是一个java客户端，用来简化与服务器的交互、作为轮询负载均衡器，并提供服务的故障切换支持。）Eureka一开 始就被设计成高可用与可伸缩的Service发现服务，这两个特点也是Netflix公司开发所有平台的两个特色。（ ）。自从切换工作开始到现在，我们实现了在生产环境中所有依赖于Eureka的产品没有下线维护的记录。我们也被告知过，在云平台做服务迁移注定要遇到失败；但是我们从这个例子中得到的经验是，一个优秀的Service发现服务在其中发挥了至关重要的作用！
首先，在Eureka平台中，如果某台服务器宕机，Eureka不会有类似于ZooKeeper的选举leader的过程；客户端请求会自动切换 到新的Eureka节点；当宕机的服务器重新恢复后，Eureka会再次将其纳入到服务器集群管理之中；而对于它来说，所有要做的无非是同步一些新的服务 注册信息而已。所以，再也不用担心有“掉队”的服务器恢复以后，会从Eureka服务器集群中剔除出去的风险了。Eureka甚至被设计用来应付范围更广 的网络分割故障，并实现“0”宕机维护需求。当网络分割故障发生时，每个Eureka节点，会持续的对外提供服务（注：ZooKeeper不会）：接收新 的服务注册同时将它们提供给下游的服务发现请求。这样一来，就可以实现在同一个子网中（same side of partition），新发布的服务仍然可以被发现与访问。
但是，Eureka做到的不止这些。正常配置下，Eureka内置了心跳服务，用于淘汰一些“濒死”的服务器；如果在Eureka中注册的服务， 它的“心跳”变得迟缓时，Eureka会将其整个剔除出管理范围（这点有点像ZooKeeper的做法）。这是个很好的功能，但是当网络分割故障发生时， 这也是非常危险的；因为，那些因为网络问题（注：心跳慢被剔除了）而被剔除出去的服务器本身是很”健康“的，只是因为网络分割故障把Eureka集群分割 成了独立的子网而不能互访而已。
幸运的是，Netflix考虑到了这个缺陷。如果Eureka服务节点在短时间里丢失了大量的心跳连接（注：可能发生了网络故障），那么这个 Eureka节点会进入”自我保护模式“，同时保留那些“心跳死亡“的服务注册信息不过期。此时，这个Eureka节点对于新的服务还能提供注册服务，对 于”死亡“的仍然保留，以防还有客户端向其发起请求。当网络故障恢复后，这个Eureka节点会退出”自我保护模式“。所以Eureka的哲学是，同时保 留”好数据“与”坏数据“总比丢掉任何”好数据“要更好，所以这种模式在实践中非常有效。
最后，Eureka还有客户端缓存功能（注：Eureka分为客户端程序与服务器端程序两个部分，客户端程序负责向外提供注册与发现服务接口）。 所以即便Eureka集群中所有节点都失效，或者发生网络分割故障导致客户端不能访问任何一台Eureka服务器；Eureka服务的消费者仍然可以通过 Eureka客户端缓存来获取现有的服务注册信息。甚至最极端的环境下，所有正常的Eureka节点都不对请求产生相应，也没有更好的服务器解决方案来解 决这种问题时；得益于Eureka的客户端缓存技术，消费者服务仍然可以通过Eureka客户端查询与获取注册服务信息，这点很重要。
Eureka的构架保证了它能够成为Service发现服务。它相对与ZooKeeper来说剔除了Leader节点的选取或者事务日志机制，这 样做有利于减少使用者维护的难度也保证了Eureka的在运行时的健壮性。而且Eureka就是为发现服务所设计的，它有独立的客户端程序库，同时提供心 跳服务、服务健康监测、自动发布服务与自动刷新缓存的功能。但是，如果使用ZooKeeper你必须自己来实现这些功能。Eureka的所有库都是开源 的，所有人都能看到与使用这些源代码，这比那些只有一两个人能看或者维护的客户端库要好。
维护Eureka服务器也非常的简单，比如，切换一个节点只需要在现有EIP下移除一个现有的节点然后添加一个新的就行。Eureka提供了一个 web-based的图形化的运维界面，在这个界面中可以查看Eureka所管理的注册服务的运行状态信息：是否健康，运行日志等。Eureka甚至提供 了Restful-API接口，方便第三方程序集成Eureka的功能。
关于Service发现服务通过本文我们想说明两点：1、留意服务运行的硬件平台；2、时刻关注你要解决的问题，然后决定 使用什么平台。Knewton就是从这两个方面考虑使用Eureka替换ZooKeeper来作为service发现服务的。云部署平台是充满不可靠性 的，Eureka可以应对这些缺陷；同时Service发现服务必须同时具备高可靠性与高弹性，Eureke就是我们想要的！
原文链接：
相关资讯 　—　
相关文档 　—　
发布时间1： 10:12:04
同类热门经验
45767次浏览
46807次浏览
34291次浏览
57101次浏览
26769次浏览
34338次浏览
OPEN-OPEN, all rights reserved.zookeeper 单机运行配置 - 简书
下载简书移动应用
写了1349字，被0人关注，获得了0个喜欢
zookeeper 单机运行配置
zookeeper 是什么
zookeeper 是 hadoop 下的一个子项目，是一个针对大型分布式系统的可靠的协调系统 。zookeeper 提供了 配置维护、名字服务、分布式同步、组服务 等功能。
zookeeper 运作原理
zookeeper 通过 Zab（Zookeeper Atomic Broadcast） 协议保持集群间的数据一致性。Zab 协议包括两个阶段：Leader Election 和 Atomic Broadcast 。
Leader Election
此阶段集群内会选举出一个 leader，余下机器则会成为 follower。leader 会通过 broadcast 通知所有 follower ，当大部分机（& 1/2）器完成了与 leader 的状态同步后，Leader Election 阶段结束。
当 leader 失去大多数 follower 时，集群会再次进入 Leader Election 阶段并选举出新的 leader ，使集群回到正确的状态。
Atomic Broadcast
此阶段 leader 会通过 broadcast 与 follower 通讯，保证 leader 与 follower 具有相同的系统状态。
zookeeper 搭建
搭建java运行环境
可参考我的另一篇笔记
下载 zookeeper
下载地址 : 这是国内的镜像源 , 也可以到官网下载 , 此笔记编写时 , zookeeper 稳定版本为 3.4.6参考命令 :
wget http://mirror./apache/zookeeper/stable/zookeeper-3.4.6.tar.gz
解压 zookeeper：
参考命令：
tar -xf zookeeper-3.4.6.tar.gz
cp zookeeper-3.4.6 /usr/local/zookeeper
rm -f zookeeper-3.4.6.tar.gz
配置 zookeeper：
参考命令：
#创建相应目录，注意目录的权限
mkdir /tmp/zookeeper
mkdir /tmp/zookeeper/data
mkdir /tmp/zookeeper/log
cp /usr/local/zookeeper/conf/zoo_sample.cfg zoo.cfg
vim /usr/local/zookeeper/conf/zoo.cfg
参考配置：
tickTime=2000 #zookeeper 服务器心跳时间，单位为ms
initLimit=10
#投票选举新 leader 的初始化时间
syncLimit=5
#leader 与 follower 心跳检测最大容忍时间，响应超过 tickTime * syncLimit，认为 leader 丢失该 follower
clientPort=2181 #端口
dataDir=/tmp/zookeeper/data #数据目录
dataLogDir=/tmp/zookeeper/log #日志目录
配置zookeeper日志
参考命令：
vim /usr/local/zookeeper/bin/zkEnv.sh
参考配置：
if [ "x${ZOO_LOG_DIR}" = "x" ]
ZOO_LOG_DIR="/tmp/zookeeper/log"
if [ "x${ZOO_LOG4J_PROP}" = "x" ]
ZOO_LOG4J_PROP="INFO,ROLLINGFILE"
配置环境变量 :
参考命令：
vim /etc/profile
新增如下配置：
export ZOOKEEPER_INSTALL=/usr/local/zookeeper
export PATH=$PATH:$ZOOKEEPER_INSTALL/bin
运行zookeeper
至此，zookeeper搭建完毕，可以尝试运行zookeeper参考命令：
cd /usr/local/zookeeper
bin/zkServer.sh start conf/zoo.cfg #启动zookeeper服务，读取配置文件为conf/zoo.cfg
bin/zkServer.sh status conf/zoo.cfg #查看指定配置的zookeeper的运行状态
可以看到当前 zookeeper 运行状态为 Mode：standalone , 至此，zookeeper单机运行配置完成。
如果觉得我的文章对您有用，请随意打赏。您的支持将鼓励我继续创作！
打开微信“扫一扫”，打开网页后点击屏幕右上角分享按钮
如果觉得我的文章对您有用，请随意打赏。您的支持将鼓励我继续创作！
选择支付方式：}