**状态感知、配置管理、主从选举
**zookeeper 是一个分布式协调服务，就是为用户的分布式应用程序提供协调服务；
1.为别的分布式程序服务的
2.zookeeper本身就是一个分布式程序（只要半数以上的节点存活，zk就能正常服务）
3.zookeeper所提供的服务涵盖：主从协调，服务器节点动态上下线、统一配置管理、分布式共享锁，同意名称服务
4.虽然说可以提供各种服务，但是zookeeper在底层其实只提供了两个功能：
管理（存储，读取）用户程序提交的数据（配置管理）
并为数据提供监听服务
**应用场景：1、服务端采集客户端程序的数据进行分析，四台客户端对四台服务端，实时流式，使用ftp传送给服务端，
假如其中一台服务器宕机了，假设成功重启，但是还要下载重启之前的未接收的数据，负载比较大，跟不上实时的数据传输
解决方案：服务器在zk上面注册（/server/server01 /server/server02）,zk将服务器的状态数据或者用户程序的数据保存下来，并对注册的服务器进行监听；（数据保管）
工作流程：因为所有机器都有一个父节点server,zk在server上进行监听，假设其中有一台服务器宕机，zk监听到，其他服务器读一下server下的子节点，就知道哪个服务器宕机，选举一个空闲服务器接管这个宕机服务器的工作（节点监听）
2、为了服务高可用，同种服务有多台服务器，选哪个作为master(主从选举)
解决方案：在zk上注册服务器/server/server01 state ip /server/server02 state ip并进行监听！！
根据zk的选举算法，master,就选举出来了。
客户端在访问服务器之前先访问server父节点，看看子节点谁是master，然后进行访问，假设master宕机了,其他服务器都收到zk的监听消息，就继续选举新的master,客户端再去zk的server看看谁是新的master,再进行访问
3、solrcloud
solr是服务器版搜索引擎单机版，在多台机器上存储同一个索引库，进行切片多台机器存储（机器1 分片1 机器2 分片2），每个机器都有一个solr服务进程
几台机器的索引库的配置信息要一致（使用过程中配置信息可能动态改变，包括分词器的选择，增加索引字段等等），每台服务器的配置信息要一致，如何保证服务器的配置信息更新一起成功
解决方案：将配置信息放在zk服务器上面，zk对数据进行监听，一改变就通知服务器群读取新的配置，服务器群一起去zk上面读取信息（保管数据，提供监听，配置管理）
**广播协议
**主从选举使用PAXOS选举算法的简化–>Zab
**选举算法（假设配置文件中注册了三台）：
1.第一台myid=1启动，投自己, 1票，只有一票，等其他机器启动
2.第二天myid=2启动，发现没有master,进行投票，1和2进行投票，1投给自己和2，2投自己和1，都是2票，一看没有选出来，根据里面算法规则，投myid大的，1投给2,2投给2 （1:2票，2:4票）leader为2，1为follower
3.第三台启动，发现有leader 结束
**数据更新 假设访问到follwer ,数据会传送到leader,leader通知各个follower更新数据（假设机器集群太大，一个leader要让所有机器信息都更新会有延迟，所以不适合对时间一致要求很高的系统）
**配置：
1、conf/zoo.cfg
tickTime 心跳周期（默认2000ms）
initLimit 初始化阶段心跳时间个数（默认10个）
syncLimit 发送一个请求到获得响应之间最大的时差（5个心跳），超过5个心跳就认为请求得不到响应
dataDir 数据目录，zk集群数据的存放目录
clientPort 客户端访问的端口(默认2181)
用户补上
server.1 = zk1:2888:3888 (2888是leader和follower通信端口，3888是投票通信端口)
server.2 = zk2:2888:3888 ….
2、在dataDir里面配置myid文件，里面存放该机器的myid数值
配置完毕
**启动指令： zkCli.sh(或zkServer.sh) start
查看状态 zkServer.sh status
**客户端命令：
ls /
create (-e)(短暂，不写默认持久) (-s)（带序号的节点，节点后面生成一个序号，可以防止命名重复） /app1 “数据”
get /app1 可以查看—>节点数据
get /app1 watch(监听节点数据，只能监听一次本身节点的数据状态，监听不了其他子节点)
ls /app1 watch (监听子节点变化)
set /app1 “修改数据”
rmr /app1 递归删除节点
delete /app1 非递归删除
quit
get /app1 可以查看—>
“数据”
Stat{
cZxid 事务控制的编号
ctime 创建时间
mZxid 事务控制的编号（每次修改，都会递增，而且是全局递增）
mtime
pZxid 事务控制的编号
cversion 创建版本号
dataVersion
ephemeralOwner
dataLength
numChildren 子节点数
}
**zk数据结构Znode(短暂（断开连接自己删除）和持久（断开连接自己不删除）)
树状结构
0 (/)根节点
(/app1)0 0 (/app2)
0 0 0 0 0 0
javaapi
create(节点，数据，权限，节点类型)
获取子节点getChildren(节点,boolean watch)
getData获取znode数据
setData
exists(path,watch)
delete(节点，-1) -1表示删除所有版本的znode
监听机制：
客户端在使用zk时候，会启动两个线程，一个监听线程一个连接线程，连接线程将客户端的端口等数据发送给zk集群，一旦zk节点发生变化，就将监听事件发送给客户端监听线程的port,实现监听
服务器动态上下线：关键，注册临时-序列化节点，服务器下线就自动删除这个临时节点，服务器可以用setdata在节点上编辑自己被连接的次数，实现负载均衡
客户端先访问zk,查看注册列表，并对列表进行监听，可以感知服务器下线 ，假如下线了，客户端的watcher中的process方法中重新获取服务器列表，并再次注册监听