zookeeper 简单总结（2）

节点类型：

1. 持久化节点                                                     #一旦创建，永久存在

2. 临时节点                                                         #节点断掉，主动清除，session超时，会被服务器删除
3. 持久化顺序节点                                              #持久化节点的基础上，自带顺序
4. 临时顺序节点                                                 #临时节点的基础上，自带顺序
5. 容器节点                                                        #当没有子节点时，父节点会被服务器删除
6. TTL节点                                                        #过了TTL指定的时间，会被服务器删除

创建节点命令：

# create /myznode                      //默认为持久化节点
# create -e /myznode                   //临时节点，不能有子节点
# create -s /myznode/xx-               //持久化顺序节点
# create -e -s /myznode/xx-            //临时顺序节点

事件监听机制：

# create /test   
# get -w /test    //对节点进行监听, 注册监听通知是一次性的
# create /test/sub  
# ls -w /test     //子节点改变，也会收到通知
   

zookeeper 分布式锁 curator：

如果使用普通的加锁，会出现羊群效应，导致很多个client都取监听争夺那把锁，每次只有一个client成功，是非公平锁，性能降低

找对应版本的curator Maven包

http://curator.apache.org/zk-compatibility-34.html

1. curator加锁的逻辑是，请求进来，直接在/lock节点下创建一个临时顺序节点

2. 判断自己是不是/lock节点下，最小的节点

      a. 是最小的，获得锁

      b. 不是。对前面的节点进行监听（watch）

3. 获得锁的请求，处理完释放锁，即delete节点，然后后继第一个节点收到通知，重复第二步判断

里面代码逻辑是使用了容器节点，当所有子节点都没有的时候，/lock会自动消失

4. curator 实现的公平锁

连接

public class CuratorCfg {
	@Bean(initMethod = "start")
	CuratorFramework curatorFramework(){
		RetryPolicy retryPolicy = new ExponentialBackoffRetry(1000, 3);
		CuratorFramework client = CuratorFrameworkFactory.newClient("192.168.0.106:2181", retryPolicy);
		return client;
	}
}

public class fbsDemo {
	@Autowired
	private CuratorFramework curatorFramework;

	public void test(){
		InterProcessMutex interProcessMutex = new InterProcessMutex(curatorFramework,"/product_"+1);

		try {
			/* 枷锁 */
			interProcessMutex.acquire();
		} catch (Exception e) {

			e.printStackTrace();
		}finally {
			/* 释放锁 */
			try {
				interProcessMutex.release();
			} catch (Exception e) {
				e.printStackTrace();
			}
		}
	}

}