随着软件的发展，应用的部署结构也从单机模式发展到了分布式模式， 当同一个应用部署到多个节点时， 通常会遇到很多问题， 比较典型的有：1、配置文件变更维护成本大如log4j配置、jdbc配置、甚至是业务配置，哪怕细微的配置变化都需要同步到若干节点，成本可想而知2、集群内设备扩容或宕机无法快速感知如原集群有5台设备，突然间加了一台或宕机一台设备，这种场景如果单纯的靠码代码是很难完美解决

zookeeper作为构建复杂系统的基础，本身要求具备高效、可靠。具备以下特性：1、高效适用于大型的分布式系统. 如果写多的话性能不高，因为它要做所有节点之间的数据同步。2、可靠支持集群，大部分可用即服务可用3、顺序事务性控制好。 多个客户端并发修改数据，会按顺序去写。在master上维护着一个写队列，控制并发操作。4、简洁对外提供的api非常实用、简洁。仅

先吐槽几句： 很多资料把paxos写得太过复杂，搞得人云里来雾里去的。 说实话特别反感一些人装逼，明明简单的问题说的长篇大论。接下来再来分享paxos是如何选举的。先来梳理一下zk的几个角色：server-leader：负责写、改、删server-follower：职责a：负责心跳探测leader状态将写请求转发leader职责b： 接收客户端请求，返回查询

如果leader挂了怎么办？ 当然是重新选举一个新的leader呀， 选举流程如下：1)、所有当前server向所有节点广播消息，去竟选leader2)、收到回执3)、向小于或等于当前节点编号的节点发送广播4)、比较投票数， 如果获得的票数>n/2+1，则推举为leader5)、被推举的节点状态由looking->leader举例：集群有5台机器

所有写请求都会被转发到leader节点，follower会通过单独的端向leader报告， 集群配置里面有专门指定，如下 zoo.cfg配置：clientPort=4180 #用来接受客户端读请求的监听端口#server.A=B：C：D：其 中A 是一个数字，表示这个是第几号服务器；　　　　　B 是这个服务器的 ip地址；　　　　　C 表示的是这个服务器与集群中的 Leader

存储结构采用树形目录结构，把它想象为windows 资源管理器就可以了。 每个节点上面有元信息，如创建时间、数据信息、数据长度、修改时间等。 和windows资源管理器一样，树上的节点可以是文件也可以目录。特点每个目录或文件节点上面都有ACL通过ACL可以设定权限访问对每个目录或文件节点的操作具有原子性每次对节点进行操作，节点中的版本号将增加

一、下载安装包https://mirrors.tuna.tsinghua.edu.cn/apache/zookeeper/zookeeper-3.4.9/zookeeper-3.4.9.tar.gz二、相关配置1、解压：tar -zxfzookeeper-3.4.9.tar.gz 2、进入conf，编辑zoo.cfg这个里面主要配

一、环境搭建1、分别创建三个server目录2、分别在3个目录中创建logs、data子目录，如下：3、分别在data目录下创建myid文件server1: myid， 内容为0server2:myid, 内容为1server3: myid,内容为 24、copy 一份单机版的zookeeper完整目录到server1、ser