Zookeeper应用——
SecureCRT应用
========
create /testnode test
==通过API写入内容：
get /testnode2/demo //查看写入文件内容
zkServer.sh start/stop zoo01.cfg // 启动、停止服务器zoo01
zkCli.sh -server 192.168.92.102:2181 //连接服务器 ——启动三个zookeeper节点
===========zk权限管理
[zk: 192.168.92.102:2183(CONNECTED) 24] getAcl /bigData
'world,'anyone
: cdrwa===新增权限
[zk: 192.168.92.102:2181(CONNECTED) 22] getAcl /aclTest
'digest,'macro1:ZFny+YH8T3K0CCIonclKCqtjRuE=
: rw
'digest,'macro2:tP7WsiSfaNqc9BFzeSaE9rJ2NhY=
: cdrwa====赋予对应节点的权限
[zk: 192.168.92.102:2181(CONNECTED) 23] addauth digest macro2:123456
[zk: 192.168.92.102:2181(CONNECTED) 24] ls /aclTest
[]======对应代码中：zooKeeper.addAuthInfo("digest", "macro2:123456".getBytes());
区别：ip方式创建：
[zk: 192.168.92.102:2181(CONNECTED) 9] getAcl /aclTest2
'ip,'192.168.92.102
: cdrwa
API调用模式
(1) 创建和zk的连接
(2) 创建节点
(3) 获取节点
① 获取节点的值
② 获取节点的状态
(4) 修改节点
(5) 删除节点
(6) 关闭连接
观察者模式
(1) keeperState：反应当前的节点状态，节点发生了什么样的变化
(2) eventType：反应当前的事件状态，对节点做了什么操作
可以监听的范围：
(1) 可以监听的范围：
① 创建连接的时候
② 子节点操作
③ 当前节点的数据操作
④ 监听指定节点的存在情况
(2) 监听器默认情况下，只能监听到一次；如果需要让他一直生效，需要循环监听
(3) 由于监听者是由一个守护线程来维持的，所以当用户线程结束后，守护线程自动结束；由代理来调用该process方法
zk权限管理
(1) 为什么要ACL权限管理：
(2) 权限分为2个部分：
① 以何种方式进行验证
② 当前权限可以对节点做什么
帕索斯算法
(1) 帕索斯算法的目标是为了保证数据一致性
(2) 帕索斯算法是一种思想
(3) 两个总要的组件：
① 提案发起人
② 提案批准人
(4) 两个原则：
① 产生结果的过程中一定不能错
② 只要产生结果后，所有节点一定要学习到
(5) 流程
① 要发起一个提案，每个提案会有一个编号
② 发起提案的人会向所有提案的审批人发送提案，并附带提案编号
③ 审批人在接收到提案之后，会用当前接受到新的提案编号和当前保存的提案编号进行比较，如果是新的编号大于当前保存的编号；
④ 审批人会先判断当前是否有结果，如果没有结果，则保留新提案提供的结果；如果有结果，则返回结果给提案发起人
⑤ 如果半数以上的提案被允许，那么该提案发起者将广播该提案
⑥ 接受到广播的会再次和当前自己保存的提案编号进行比较，如果发现小于当前自己保存的提案编号，则拒绝，从新发起新的一轮提案
(6) 帕索斯算法的目的：
① 正常情况下的数据一致性解决方案：
1) 没有数据备份，数据不安全。
2) 有数据备份，那么这个时候就要决定，以哪一个备份作为最终结果。
② 如果多个节点的数据不统一
1) 发起提案：
a. 提案ID：s % n = ir => s = m * n + ir
2) 审批提案：
③ 异常：
1) 活锁的问题
2) 节点异常的问题
2. Zookeeper选举和同步机制
(1) ZAB:Zookeeper真正采用的算法
(2) zookeeper选举
① 找到新的leader(myid:zxid)[标准：zxid最大，myid最小]
② 新的leader广播信息，告诉所有的follower我要进行数据同步
③ follower接受到信息准备好之后会告诉leader我准备好了
④ leader判断是否有半数以上follower准备好了
⑤ 如果超过半数则再次广播同意写入，follower接受到同意的信息后，完成写入工作
⑥ 如果有新节点加入或者有数据要写入，过程参照上面数据同步的流程（2-5）
3. Zookeeper的选举和同步机制相对hadoop来说比较粗暴
===
【1】崩溃恢复：参考上面的选举机制
【2】消息广播：zxid——全局唯一的自增id
【3】数据同步：quorum机制——准leader
WARO &&& Quorum机制
【1】write all read one
【2】假设有N个副本，更新操作wi 在W个副本中更新成功之后，才认为此次更新操作wi 成功。称成功提交的更新操作对应的数据为：“成功提交的数据”。对于读操作而言，至少需要读R个副本才能读到此次更新的数据。其中，W+R>N ，即W和R有重叠。一般，W+R=N+1.
====Qurom缺陷：
1）如何读取最新的数据？---在已经知道最近成功提交的数据版本号的前提下，最多读R个副本就可以读到最新的数据了。
2）如何确定 最高版本号 的数据是一个成功提交的数据？---继续读其他的副本，直到读到的 最高版本号副本 出现了W次。
补充：网络通讯
route print
tracert www.baidu.com
协议：一组由整个行业约定好的、共同遵守的一种通讯方式！
RPC:远程通信协议
