Zookeeper了解及使用

dataDir=../data
dataLogDir=../data/log

1. 一致性：client不论连接到哪个Server，展示给它都是同一个视图，这是ZooKeeper最重要的性能。
2. 可靠性：具有简单、健壮、良好的性能，如果消息m被到一台服务器接受，那么它将被所有的服务器接受。
3. 实时性：ZooKeeper保证客户端将在一个时间间隔范围内获得服务器的更新信息，或者服务器失效的信息。但由于网络延时等原因，ZooKeeper不能保证两个客户端能同时得到刚更新的数据，如果需要最新数据，应该在读数据之前调用sync()接口。
4. 等待无关（wait-free）：慢的或者失效的client不得干预快速的client的请求，使得每个client都能有效的等待。
5. 原子性：更新只能成功或者失败，没有中间状态。
6. 顺序性：包括全局有序和偏序两种：全局有序是指如果在一台服务器上消息a在消息b前发布，则在所有Server上消息a都将在消息b前被发布；偏序是指如果一个消息b在消息a后被同一个发送者发布，a必将排在b前面。

1、临时无序 断开连接则删除，其实是session断开或关闭
2、临时有序 同上，只不过节点由zookeeper进行顺序编号
3、持久无序 持久化的节点在连接断开后依然存在
4、持久有序 同上，只不过节点由zookeeper进行顺序编号
-注意：
临时节点不能有子节点
数据存在节点上，而数据都有版本号的
节点都可以被客户端监听，当出现节点上数据修改、子节点变化，都会进行通知

CREATE: 创建子节点的权限。（对子节点）
READ: 获取节点数据和子节点列表的权限。
WRITE：更新节点数据的权限。
DELETE: 删除子节点的权限。（对子节点）
ADMIN: 设置节点ACL的权限。

首先需要了解，zookeeper集群中会将各个机器分为三个角色：
1、Leader：系统故障时完成数据恢复；保证并维持多台机器的状态一致；发起投票与决策。
    维持服务器间的心跳连接，并接受处理其发送的请求，讲多请求的有序化，保证请求的有序与原子性。
2、Fllower：与Leader通信保存连接；Leader故障参与选举；与客户端通信与数据交互。
    向Leader发送命令（PING消息、REQUEST消息、ACK消息、REVALIDATE消息），处理Leader的命令。
    处理客户端请求，写则交由Leader完成。
3、Observer：类似Fllower，但不参与集群选举与投票。
    对集群的扩展
消息类型：
    PING消息： 心跳消息；
    PROPOSAL消息：Leader发起的提案，要求Follower投票；
    COMMIT消息：服务器端最新一次提案的信息；
    UPTODATE消息：表明同步完成；
    REVALIDATE消息：根据Leader的REVALIDATE结果，关闭待revalidate的session还是允许其接受消息；
    SYNC消息：返回SYNC结果到客户端，这个消息最初由客户端发起，用来强制得到最新的更新。
-

 1、zookeeper保证数据一致性的关键是ZAB协议，该协议主要完成两点功能，恢复、广播。当Leader出现故障导致崩溃时，出现新的选举，当选举完新的Leader后，会进行状态恢复；而广播模式让Leader与Learner保持状态一致。
2、为了保证事务的顺序一致性，zookeeper采用了递增的事务id号（zxid）来标识事务。所有的提议（proposal）都在被提出的时候加上了zxid。实现中zxid是一个64位的数字，它高32位是epoch用来标识leader关系是否改变，每次一个leader被选出来，它都会有一个新的epoch，标识当前属于那个leader的统治时期。低32位用于递增计数
3、每个Server在工作过程中有三种状态：
　　　　LOOKING：当前Server不知道leader是谁，正在搜寻
　　　　LEADING：当前Server即为选举出来的leader
　　　　FOLLOWING：leader已经选举出来，当前Server与之同步
--选举【参考】
  当系统启动或者leader崩溃后，就会开始leader的选举。
    1.状态变更。服务器启动的时候每个server的状态时Looking，如果是leader挂掉后进入选举，那么余下的非Observer的Server就会将自己的服务器状态变更为Looking，然后开始进入Leader的选举状态；
    2.发起投票。每个server会产生一个（sid，zxid）的投票，系统初始化的时候zxid都是0，如果是运行期间，每个server的zxid可能都不同，这取决于最后一次更新的数据。将投票发送给集群中的所有机器；
    3.接收并检查投票。server收到投票后，会先检查是否是本轮投票，是否来自looking状态的server；
    4.处理投票。对自己的投票和接收到的投票进行PK：
        先检查zxid，较大的优先为leader；
        如果zxid一样，sid较大的为leader；
        根据PK结果更新自己的投票，在次发送自己的投票；
    5.统计投票。每次投票后，服务器统计投票信息，如果有过半机器接收到相同的投票，那么leader产生，如果否，那么进行下一轮投票；
    6.改变server状态。一旦确定了Leader，server会更新自己的状态为Following或者是Leading。
    7.选举结束。
说明：
    在步骤2发送投票的时候，投票的信息除了sid和zxid，还有：
        electionEpoch：逻辑时钟，用来判断多个投票是否在同一轮选举周期中，该值在服务端是一个自增序列，每次进入新一轮的投票后，都会对该值进行加1操作。
        peerEpoch：被推举的Leader的epoch。
        state：当前服务器的状态。
    为了能够相互投票，每两台服务器之间都会建立网络连接，为避免重复建立TCP连接，zk的server只允许sid大于自己的服务器与自己建立连接，否则断开当前连接，并主动和对方建立连接。
--请求流程
    1.在Client向Follwer发出一个写的请求
    2.Follwer把请求发送给Leader
    3.Leader接收到以后开始发起投票并通知Follwer进行投票
    4.Follwer把投票结果发送给Leader
    5.Leader将结果汇总后如果需要写入，则开始写入同时把写入操作通知给Leader，然后commit;
    6.Follwer把请求结果返回给Client
--事务一致
    更新请求顺序进行，来自同一个client的更新请求按其发送顺序依次执行。
    数据更新原子性，一次数据更新要么成功，要么失败。
    全局唯一数据视图，client无论连接到哪个server，数据视图都是一致的。
    实时性，在一定事件范围内，client能读到最新数据。
--

1、命名服务
2、配置管理
3、集群管理
4、分布式锁
5、队列管理
6、发布订阅

conf 输出相关服务配置的详细信息。
cons 列出所有连接到服务器的客户端的完全的连接 / 会话的详细信息。包括“接受 / 发送”的包数量、会话 id 、操作延迟、最后的操作执行等等信息。
dump 列出未经处理的会话和临时节点。
envi 输出关于服务环境的详细信息（区别于 conf 命令）。
reqs 列出未经处理的请求
ruok 测试服务是否处于正确状态。如果确实如此，那么服务返回“imok ”，否则不做任何相应。
stat 输出关于性能和连接的客户端的列表。
wchs 列出服务器 watch 的详细信息。
wchc 通过 session 列出服务器 watch 的详细信息，它的输出是一个与watch 相关的会话的列表。
wchp 通过路径列出服务器 watch 的详细信息。它输出一个与 session相关的路径。