zookeeper相关要点

Zookeeper是一个分布式的协调服务框架。Zookeeper可以解决分布式环境中常见的问题。统一命名服务，信息配置管理，数据一致性，集群管理，分布式锁等等。

利用多台机器同时执行一个任务。分布式环境就是集群环境。
分布式环境下带来的难题：
1.容易出现死锁
2.容易出现活锁，处于活锁的线程都是非阻塞的。活锁是没有一个线程能抢占到资源，会造成cpu资源的浪费。想想避让的问题。线程在执行过程中产生了碰撞--再执行--再碰撞，如此循环往复，造成活锁。
Zookeeper框架是根据Google发表的论文的开源实现。
Zookeeper解决的问题：
集群的管理问题，比如宕机检测
集群文件的统一管理
集群状态更新的通知问题
管理集群的选举问题
分布式锁的实现
使用步骤：在conf下将zoo_sample.cfg修改为zoo.cfg
编辑：
dataDir
命令：
zookeeper服务端指令：
sh zkServer.sh start 
sh zkServer.sh stop
sh zkServer.sh restart
sh zkServer.sh status
sh zkCli.sh 进入zk客户端
zookeeper客户端命令：
查看根路径下的节点：ls /
ls /park01 查看park01下的节点
创建节点：create /park01 hello
create 路径 分配数据
获取节点信息：get /park01
ephemeralOwner：如果此节点不是临时节点，那么就是0
修改节点数据：set /park01 good
删除节点：delete /park01
递归删除节点：rmr /park01  针对该节点下还有其他节点的情况
退出客户端：quit
**创建一个临时节点：create -e /park02 nice  客户端下线临时节点就没有了 
机器注册在zookeeper上，通过临时节点就可以检测到是否还在
创建顺序节点：create -s /park01 "" 
创建临时的顺序节点：create -e -s /park04 66

临时节点在zk关掉以及注

Zookeeper知识点：
1.Zookeeper有一个根节点(/),所有节点的注册和操作基于根节点来实现
2.每一个节点都可以拥有自己的子节点
3.每一个节点都称之为znode节点
4.多个znode节点共同形成了一个znode树，这个znode树是维系在内存中，目的是供用户快速进行查询数据。
5.每个znode都可以存储数据
6.创建节点时，需要给此节点分配初始数据
7.znode节点分为4类，普通持久节点、普通临时节点、普通顺序持久节点、临时顺序节点
8.znode节点路径是唯一的
9.不要用zookeeper存储大量数据，从功能上来讲，zookeeper做的是集群的协调服务，所以存储的信息是很少量的。此外，znode树是维系在内存中的，如果海量内存的话，会占用大量的内存，可能会撑爆内存。所以不适合。


Zookeeper集群搭建
//2888(原子端口)，3888(选举端口)
server.1=10.19.176.205:2888:3888
server.2=10.9.79.167:2888:3888
server.3=10.9.77.111:2888:3888
修改主机名：vim /etc/sysconfig/network 
hostname进行查看
zookeeper选举：
分两个阶段：
1.数据恢复阶段
每台zk服务在启动时，从本地目录找自己拥有的Zxid(最大事务id)，每有一次写操作，都是一个事务，每次事务id都会递增。事务id越大，则事务越新。
2.选举阶段
每台zk服务器都会提交一个选举协议。每次提交协议，协议中的内容：
1.自己的Zxid
2.选举id(myid里面的数字)
3.逻辑时钟值(每经过一次选举，就递增一次，用于记录选举的次数。作用是用于确保每台zk服务器处于同一轮选举中)
4.状态
1.Looking，选举状态
2.Leader
3.Follower
4.Observer
过程：首先启动一台zk1，准备选举，其他zk服务器没有启动，则进入looking状态，zk2启动，也要选举，然后zk1和zk2进行pk。根据pk原则，过半性原则导致选不出领导，都进入looking状态。zk03启动时就会选出leader。如果集群中再次加入zk服务，则默认是follower。
pK原则：
首先比较Zxid，谁大谁当领导。
如果比较不出来，就比较选举id，谁大，谁当领导
选举有个机制就是过半同意。
如果说follow都挂掉了，就不满足一个机制，过半存活，那么leader自动就挂掉。整个集群就宕掉。比如三台机器，至少要有两台机器存活。
zookeeper集群数量最好是奇数个，能更好的满足过半性。
bin下的zookeeper.out是zookeeper的错误日志文件
Leader选举之后：
首先做数据同步，目的是保证zk集群的数据一致性
确保当leader挂掉之后，其他follow可以顶替工作。
此外确保客户端从哪个zk服务器上获取数据都是一致
这种实现数据一致的过程称为原子广播！(Atomic Broadcast)
server1.ip:2888:3888
则这些zk服务器以2888通信
对于客户端的读请求，任何一台zk服务器都可以进行处理。但是写请求，会交给leader进行处理。leader会通过原子广播端口，将写请求的事务广播给其他节点，还会收集每台zk服务器的ack信息，然后统计是否满足过半性，如果满足，则表示事务提高成功。最后反馈给客户端。
leader接收到请求，会将请求发送到所有的follower，然后如果说某一个follower成功执行了某个请求，那么会commit一个，并向leader返回一个ack信号(反馈信息)，然后另外一台zk服务器也执行成功，commit了，并返回了一个ack信号，如果说当前有三台，有两台成功，则表示该请求执行成功。这里也有一个过半提高的概念。一旦有超多一半的zk服务器执行成功，那么就代表成功，并之后通过原子广播，通知给其他zk服务器说已经成功，不用再写，进行同步就可以了。
zk最重要的一个特点：
过半性(过半选举，过半事务提交，过半存活)!!!!!!
每次选举都会为当前的leader生成一个epoch id(这个id是递增的)，所以如果说老的leader活过来之后，进行原子广播，其他follower不会接收到老的leader的信息，而接受新的leader的


cZxid：创建的事务id，不能根据这个来判断最大事务id
mZxid：修改的事务id
事务id本质上是一个64位的二进制数，高32位是epoch id，低32位是最大事务id
tickTime:最小时间单位 默认2000毫秒
最大超时时间：20*ticktime
最小超时时间：2*ticktime
如果说你设置的超时时间，不在这个区间内，就用区间内的，如果在，就用你的
zookeeper默认的选举算法：fase paxos election3
zokeeper调优：
----------------------------
1.配置文件
配置leader不进行读写工作
2.观察者
观察者不影响zk集群的使用，可以随意挂掉，但是它还有一个功能就是支持读写。
zookeeper观察者：
1.选择一台作为观察者，并在其zoo.cfg中配置
任意一行添加： peerType=observer
在其端口ip修改：server.3=Cloud01:2888:3888:observer
2.然后修改其他两台的ip，配置第三台是观察者
然后在启动三台zk，查看第三台，发现其状态是observer

zookeeper特点总结：
数据一致性。严格按照其发起顺序执行。只能保证顺序一致性和最终一致性
原子性：要么都成功，要么都失败
可靠性：一旦成功，更改状态就会一直保存。
实时性：数据都放在内存中，所以返回结果很快。和网络状况有关系。最终一致性，顺序一致性。只能打到伪实时性，因为集群处理需要时间，并不是实时的
顺序性：如果a先发布，发出，则所有服务器上消息a都会在消息b之前发布。
每个客户端都有一个自己的版本号
每次发送的时候，都添加一个命令版本号，每添加一次，就递增一次。
过半性：过半同意
zookeeper的应用场景：
统一命名服务：通过znode实现，因为znode全局唯一，路径就是服务名。
集群管理：通过事件监听机制，让集群中每台机器都在zookeeper中注册一个临时节点。
数据订阅发布：通过事件监听机制，监听某一个发布方状态发生变化，如果发生变化，则其他监听的就自动订阅。
配置管理：也是通过监听机制来实现。
分布式同步协调通知：通过监听机制，查看修改的状态是否修改了多少次(成绩排名)。在zookeeper中叫屏障，类似队列中的栅栏。类似赛马的场景。
负载均衡：定期将自己的信息注册给zookeeper，比如cpu，带宽，磁盘使用率，然后zk根据这些信息做一个负载均衡的分配。
分布式锁：可以通过顺序节点来判断谁先抢占到资源。