最近在看关于ZK的博客，有一些感觉很不错的内容。这篇博客是我认为比较重要的内容我把它们收集起来，便于以后看：

zookeeper的一些处理原则

1.可靠 delivery

	如果消息m被一台服务器delivered，它会被所有服务器delivered

2.完全有序

	如果消息a在一台服务器上先于消息b被delivered，在所有服务器上都保持这个顺序

3.因果顺序(causual order)

	消息的发送顺序决定了消息的顺序



-- zookeepker使用TCP，下列几个特性依赖TCP的特性

(与同类系统容忍丢包和乱序不同，zookeepker假定所有servers建立在 p2p的FIFO通道上)3


4.有序delivery(Ordered delivery)

5.FIFO channel一旦关闭，就不能发送任何信息

6.发送消息包括两个阶段

  * Leader activation ：本阶段会推选一个leader，并建立系统状态和次序，准备好发送proposal

  * Active messaging ：本阶段leader会接收message，并协调系统中message的传送

7.Leader activation

  包括Leader election，其有两个算法，LeaderElection和FastLeaderElection(AuthFastLeaderElection是其变种，是一种简单的授权以防止IP欺骗的election方式)	

  但ZooKeeper messaging不关注election算法，而

  * leader获取到所有followers中的最大zxid (必要条件)

  * 一定量的servers已经follow这个leader 

  在election过程中或完成后，有较多服务器断开，则会重新进行election

   所有follower会连接到leader

8.Active Messaging 

   * leader以FIFO方式给所有Followers发送message，Followers按顺序存储和执行

   * 当Followers收到message后，要返回一个ack给leader

   * 当leader收到quorum Followers的 ack后，会发送一个COMMIT


zxid      ZooKeeper Transaction id，所有proposal都有唯一标识其和其顺序的zxid

	  目前为64位表示一个zxid(epoch, count).，高32位为epoch，低32位为counter

	  epoch与一个leader关联，新leader有新epoch号

packet  由FIFO channel发送的字节数据

proposal   一种约定(在所有zookeepker服务器之间)，一般带有message(NEW_LEADER类型的不带message)
message   原子广播包，需放入 proposal或agreed才能发送

quorum   法定人数，zookeeper 中指有些操作必须有一定数量的followers，才能执行

我们说性能，可以从两个方面去考虑：写入的性能与读取的性能。

   由于ZooKeeper的写入首先需要通过Leader，然后这个写入的消息需要传播到半数
以上的Fellower通过才能完成整个写入。所以整个集群写入的性能无法通过增加
服务器的数量达到目的，相反，整个集群中Fellower数量越多，整个集群写入的
性能越差。

   ZooKeeper集群中的每一台服务器都可以提供数据的读取服务，所以整个集群中服
务器的数量越多，读取的性能就越好。但是Fellower增加又会降低整个集群的写
入性能。为了避免这个问题，可以将ZooKeeper集群中部分服务器指
定为Observer。

   详细一点的ZK的java的api说明实例：

// 创建一个Zookeeper实例，第一个参数为目标服务器地址和端口，第二个参数为Session超时时间，第三个为节点变化时的回调方法
ZooKeeper zk  =   new  ZooKeeper( " 127.0.0.1:2181 " ,  500000 , new  Watcher()  {
            //  监控所有被触发的事件
              public   void  process(WatchedEvent event)  {
            // dosomething
           }
      } );
// 创建一个节点root，数据是mydata,不进行ACL权限控制，节点为永久性的(即客户端shutdown了也不会消失)
zk.create( " /root " ,  " mydata " .getBytes(),Ids.OPEN_ACL_UNSAFE, CreateMode.PERSISTENT);

// 在root下面创建一个childone znode,数据为childone,不进行ACL权限控制，节点为永久性的
zk.create( " /root/childone " , " childone " .getBytes(), Ids.OPEN_ACL_UNSAFE,CreateMode.PERSISTENT);

// 取得/root节点下的子节点名称,返回List<String>
zk.getChildren( " /root " , true );

// 取得/root/childone节点下的数据,返回byte[]
zk.getData( " /root/childone " ,  true ,  null );

// 修改节点/root/childone下的数据，第三个参数为版本，如果是-1，那会无视被修改的数据版本，直接改掉
zk.setData( " /root/childone " , " childonemodify " .getBytes(),  - 1 );

// 删除/root/childone这个节点，第二个参数为版本，－1的话直接删除，无视版本
zk.delete( " /root/childone " ,  - 1 );
      
// 关闭session
zk.close();

***********************************************

Zookeeper 的主流应用场景实现思路（除去官方示例）

(1) 配置管理
集中式的配置管理在应用集群中是非常常见的，一般商业公司内部都会实现一套集中的配置管理中心，应对不同的应用集群对于共享各自配置的需求，并且在配置变更时能够通知到集群中的每一个机器。

Zookeeper 很容易实现这种集中式的配置管理，比如将 APP1 的所有配置配置到 /APP1 znode 下， APP1 所有机器一启动就对 /APP1 这个节点进行监控 (zk.exist( "/APP1" ,true)), 并且实现回调方法 Watcher ，那么在 zookeeper 上 /APP1 znode 节点下数据发生变化的时候，每个机器都会收到通知， Watcher 方法将会被执行，那么应用再取下数据即可 (zk.getData( "/APP1",false,null ));

以上这个例子只是简单的粗颗粒度配置监控，细颗粒度的数据可以进行分层级监控，这一切都是可以设计和控制的。     
(2) 集群管理
应用集群中，我们常常需要让每一个机器知道集群中（或依赖的其他某一个集群）哪些机器是活着的，并且在集群机器因为宕机，网络断链等原因能够不在人工介入的情况下迅速通知到每一个机器。

Zookeeper 同样很容易实现这个功能，比如我在 zookeeper 服务器端有一个 znode 叫 /APP1SERVERS, 那么集群中每一个机器启动的时候都去这个节点下创建一个 EPHEMERAL 类型的节点，比如 server1 创建 /APP1SERVERS/SERVER1( 可以使用 ip, 保证不重复 ) ， server2 创建 /APP1SERVERS/SERVER2 ，然后 SERVER1 和 SERVER2 都 watch /APP1SERVERS 这个父节点，那么也就是这个父节点下数据或者子节点变化都会通知对该节点进行 watch 的客户端。因为 EPHEMERAL 类型节点有一个很重要的特性，就是客户端和服务器端连接断掉或者 session 过期就会使节点消失，那么在某一个机器挂掉或者断链的时候，其对应的节点就会消失，然后集群中所有对 /APP1SERVERS 进行 watch 的客户端都会收到通知，然后取得最新列表即可。

另外有一个应用场景就是集群选 master, 一旦 master 挂掉能够马上能从 slave 中选出一个 master, 实现步骤和前者一样，只是机器在启动的时候在 APP1SERVERS 创建的节点类型变为 EPHEMERAL_SEQUENTIAL 类型，这样每个节点会自动被编号，例如           

zk.create( " /testRootPath/testChildPath1 " , " 1 " .getBytes(), Ids.OPEN_ACL_UNSAFE,CreateMode.EPHEMERAL_SEQUENTIAL);
        
zk.create( " /testRootPath/testChildPath2 " , " 2 " .getBytes(), Ids.OPEN_ACL_UNSAFE,CreateMode.EPHEMERAL_SEQUENTIAL);
        
zk.create( " /testRootPath/testChildPath3 " , " 3 " .getBytes(), Ids.OPEN_ACL_UNSAFE,CreateMode.EPHEMERAL_SEQUENTIAL);
        
//  创建一个子目录节点
zk.create( " /testRootPath/testChildPath4 " , " 4 " .getBytes(), Ids.OPEN_ACL_UNSAFE,CreateMode.EPHEMERAL_SEQUENTIAL);

System.out.println(zk.getChildren( " /testRootPath " ,  false ));

 打印结果： [testChildPath10000000000, testChildPath20000000001, testChildPath40000000003, testChildPath30000000002]

zk.create( " /testRootPath " ,  " testRootData " .getBytes(),Ids.OPEN_ACL_UNSAFE, CreateMode.PERSISTENT);

//  创建一个子目录节点
zk.create( " /testRootPath/testChildPath1 " , " 1 " .getBytes(), Ids.OPEN_ACL_UNSAFE,CreateMode.EPHEMERAL);
        
zk.create( " /testRootPath/testChildPath2 " , " 2 " .getBytes(), Ids.OPEN_ACL_UNSAFE,CreateMode.EPHEMERAL);
        
zk.create( " /testRootPath/testChildPath3 " , " 3 " .getBytes(), Ids.OPEN_ACL_UNSAFE,CreateMode.EPHEMERAL);
        
//  创建一个子目录节点
zk.create( " /testRootPath/testChildPath4 " , " 4 " .getBytes(), Ids.OPEN_ACL_UNSAFE,CreateMode.EPHEMERAL);

System.out.println(zk.getChildren( " /testRootPath " ,  false ));