zookeeper理解
分布式协调服务-zookeeper
1，zookeeper能做什么
数据的发布/订阅（配置中心:disconf） 、 负载均衡（dubbo利用了zookeeper机制实现负载均衡） 、命名服务、
master选举(kafka、hadoop、hbase)、分布式队列、分布式锁
2，zookeeper的特性
顺序一致性： 从同一个客户端发起的事务请求，最终会严格按照顺序被应用到zookeeper中
原子性： 所有的事务请求的处理结果在整个集群中的所有机器上的应用情况是一致的，也就是说，要么整个集群中的所有机器都成功应用了某一事务、要么全都不应用
可靠性：一旦服务器成功应用了某一个事务数据，并且对客户端做了响应，那么这个数据在整个集群中一定是同步并且保留下来的
实时性：一旦一个事务被成功应用，客户端就能够立即从服务器端读取到事务变更后的最新数据状态；（zookeeper仅仅保证在一定时间内，近实时）
3，zookeeper安装
单机环境安装
1.下载zookeeper的安装包 : http://apache.fayea.com/zookeeper/stable/zookeeper-3.4.10.tar.gz
2.解压zookeeper : tar -zxvf zookeeper-3.4.10.tar.gz
3.cd 到 ZK_HOME/conf , copy一份zoo.cfg
cp zoo_sample.cfg zoo.cfg
4.启动zk服务：sh zkServer.sh
{start|start-foreground|stop|restart|status|upgrade|print-cmd}
5.sh zkCli.sh -server ip:port
集群环境 --zookeeper一般是由 2n+1台服务器组成
zookeeper集群, 包含三种角色: leader / follower /observer
leader
leader是zookeeper集群的核心。
- 事务请求的唯一调度者和处理者，保证集群事务处理的顺序性
- 集群内部各个服务器的调度者
- 处理客户端非事务请求，以及转发事务请求给leader服务器
- 参与事务请求提议（proposal）的投票（客户端的一个事务请求，需要半数服务器投票通过以后才能通知leader commit； leader会发起一个提案，要求follower投票）
- 参与leader选举的投票
follower
observer
观察zookeeper集群中最新状态的变化并将这些状态同步到observer服务器上
增加observer不影响集群中事务处理能力，同时还能提升集群的非事务处理能力
observer: observer 是一种特殊的zookeeper节点。可以帮助解决zookeeper的扩展性（如果大量客户端访问我们zookeeper集群，需要增加zookeeper集群机器数量。从而增加zookeeper集群的性能。 导致zookeeper写性能下降， zookeeper的数据变更需要半数以上服务器投票通过。造成网络消耗增加投票成本）
a).observer不参与投票。 只接收投票结果。
b).不属于zookeeper的关键部位。
zookeeper集群搭建：
1. 修改zoo.cfg
***.***.**.129/135/136
server.id=ip:port:port
server.1=192.168.11.129:2888:3181 2888表示follower节点与leader节点交换信息的端口号 3181 如果leader节点挂掉了, 需要一个端口来重新选举。
server.2=192.168.11.135:2888:3181
server.3=192.168.11.136:2888:3181
2. zoo.cfg中有一个dataDir = /tmp/zookeeper
$dataDir/myid 添加一个myid文件。
3. 启动服务
如果需要增加observer节点
zoo.cfg中 增加 ;peerType=observer
server.1=192.168.11.129:2888:3181
server.2=192.168.11.135:2888:3181
server.3=192.168.11.136:2888:3181:observer
zoo.cfg配置文件分析
tickTime=2000 zookeeper中最小的时间单位长度 （ms）
initLimit=10 follower节点启动后与leader节点完成数据同步的时间
syncLimit=5 leader节点和follower节点进行心跳检测的最大延时时间
dataDir=/tmp/zookeeper 表示zookeeper服务器存储快照文件的目录
dataLogDir 表示配置 zookeeper事务日志的存储路径，默认指定在dataDir目录下
clientPort 表示客户端和服务端建立连接的端口号： 2181
4.zookeeper的数据模型
zookeeper的数据模型和文件系统类似，每一个节点称为：znode. 是zookeeper中的最小数据单元。每一个znode上都可以
保存数据和挂载子节点。 从而构成一个层次化的属性结构
节点特性
持久化节点 ： 节点创建后会一直存在zookeeper服务器上，直到主动删除
持久化有序节点 ：每个节点都会为它的一级子节点维护一个顺序
临时节点 ： 临时节点的生命周期和客户端的会话保持一致。当客户端会话失效，该节点自动清理
临时有序节点 ： 在临时节点上多勒一个顺序性特性
会话
Watcher
zookeeper提供了分布式数据发布/订阅,zookeeper允许客户端向服务器注册一个watcher监听。当服务器端的节点触发指定事件的时候
会触发watcher。服务端会向客户端发送一个事件通知
watcher的通知是一次性，一旦触发一次通知后，该watcher就失效
ACL
zookeeper提供控制节点访问权限的功能，用于有效的保证zookeeper中数据的安全性。避免误操作而导致系统出现重大事故。
CREATE /READ/WRITE/DELETE/ADMIN
5.zookeeper的命令操作
1. create [-s] [-e] path data acl
-s 表示节点是否有序
-e 表示是否为临时节点
默认情况下，是持久化节点
2. get path [watch]
获得指定 path的信息
3.set path data [version]
修改节点 path对应的data
乐观锁的概念
数据库里面有一个 version 字段去控制数据行的版本号
4.delete path [version]
删除节点
5.stat信息
cversion = 0 子节点的版本号
aclVersion = 0 表示acl的版本号，修改节点权限
dataVersion = 1 表示的是当前节点数据的版本号
czxid 节点被创建时的事务ID
mzxid 节点最后一次被更新的事务ID
pzxid 当前节点下的子节点最后一次被修改时的事务ID
ctime = Sat Aug 05 20:48:26 CST 2017
mtime = Sat Aug 05 20:48:50 CST 2017
6.leader选举
leaderElection/AuthFastLeaderElection/FastLeaderElection（默认选举方式）
QuorumPeer startLeaderElection
源码地址：https://github.com/apache/zookeeper.git
需要的条件： jdk 1.7以上 、ant 、idea
FastLeaderElection（默认选举方式）
serverid : 在配置server集群的时候，给定服务器的标识id（myid）
zxid : 服务器在运行时产生的数据ID， zxid的值越大，表示数据越新
Epoch: 选举的轮数
server的状态：Looking、 Following、Observering、Leading
第一次初始化启动的时候： LOOKING
1.所有在集群中的server都会推荐自己为leader，然后把（myid、zxid、epoch）作为广播信息，广播给集群中的其他server, 然后等待其他服务器返回
2.每个服务器都会接收来自集群中的其他服务器的投票。集群中的每个服务器在接受到投票后，开始判断投票的有效性
a) 判断逻辑时钟(Epoch) ，如果Epoch大于自己当前的Epoch，说明自己保存的Epoch是过期。更新Epoch，同时clear其他服务器发送过来的选举数据。判断是否需要更新当前自己的选举情况
b) 如果Epoch小于目前的Epoch，说明对方的epoch过期了，也就意味着对方服务器的选举轮数是过期的。这个时候，只需要讲自己的信息发送给对方
3.
7. ZAB协议
拜占庭问题
paxos协议主要就是如何保证在分布式环网络环境下，各个服务器如何达成一致最终保证数据的一致性问题
ZAB协议，基于paxos协议的一个改进。
zab协议为分布式协调服务zookeeper专门设计的一种支持崩溃恢复的原子广播协议
zookeeper并没有完全采用paxos算法， 而是采用zab Zookeeper atomic broadcas
zab协议的原理
1.在zookeeper 的主备模式下，通过zab协议来保证集群中各个副本数据的一致性
2.zookeeper使用的是单一的主进程来接收并处理所有的事务请求，并采用zab协议，
把数据的状态变更以事务请求的形式广播到其他的节点
- zab协议在主备模型架构中，保证了同一时刻只能有一个主进程来广播服务器的状态变更
- 所有的事务请求必须由全局唯一的服务器来协调处理，这个的服务器叫leader，其他的叫follower
leader节点主要负责把客户端的事务请求转化成一个事务提议（proposal），并分发给集群中的所有follower节点
再等待所有follower节点的反馈。一旦超过半数服务器进行了正确的反馈，那么leader就会commit这条消息
zab协议的机制：崩溃恢复、原子广播
zab协议的工作原理
- 什么情况下zab协议会进入崩溃恢复模式
- 当服务器启动时
- 当leader服务器出现网络中断、崩溃或者重启的情况
- 集群中已经不存在过半的服务器与该leader保持正常通信
- zab协议进入崩溃恢复模式会做什么
- 当leader出现问题，zab协议进入崩溃恢复模式，并且选举出新的leader。当新的leader选举出来以后，如果集群中已经有过半机器完成了leader服务器的状态同（数据同步），退出崩溃恢复，进入消息广播模式
- 当新的机器加入到集群中的时候，如果已经存在leader服务器，那么新加入的服务器就会自觉进入数据恢复模式，找到leader进行数据同步
- 问题：
如果客户端发了一个事务请求给到leader， 而leader发送给各个follower以后，并且收到了ack，leader已经commit。 在准备ack给各个follower节点comit的时候，leader挂了，怎么处理的。
1.选举新的leader（zxid的最大值）
2.同步给其他的folower
8.数据存储
内存数据和磁盘数据
zookeeper会定时把数据存储在磁盘上。
DataDir = 存储的是数据的快照
快照： 存储某一个时刻全量的内存数据内容
DataLogDir 存储事务日志
查看事务日志的命令
java -cp :/**/**/**/zookeeper-3.4.10/lib/slf4j-api-1.6.1.jar:/**/**/**/zookeeper-3.4.10/zookeeper-3.4.10.jar org.apache.zookeeper.server.LogFormatter log.200000001
zookeeper 有三种日志
zookeeper.out //运行日志
快照 //存储某一时刻的全量数据
事务日志 //事务操作的日志记录
