A. zookeeper集群为什么是3个以上节点
Apache Zookeeper是我最近遇到的最酷的技术，我是在研究Solr Cloud功能的时候发现的。Solr的分布式计算让我印象深刻。你只要开启一个新的实例就能自动在Solr Cloud中找到。它会将自己分派到某个分片中，并确定出自己是一个Leader（源）还是一个副本。不一会儿，你就可以在你的那些服务器上查询到了。即便某些服务器宕机了也可以继续工作。非常动态、聪明、酷。
将运行多个应用程序作为一个逻辑程序并不是什么新玩意。事实上，我在几年前就已写过类似的软件。这种架构比较让人迷惑，使用起来也费劲。为此Apache Zookeeper提供了一套工具用于管理这种软件。
为什么叫Zoo？“因为要协调的分布式系统是一个动物园”。
在本篇文章中，我将说明如何使用PHP安装和集成Apache ZooKeeper。我们将通过service来协调各个独立的PHP脚本，并让它们同意某个成为Leader（所以称作Leader选举）。当Leader退出（或崩溃）时，worker可检测到并再选出新的leader。
ZooKeeper是一个中性化的Service，用于管理配置信息、命名、提供分布式同步，还能组合Service。所有这些种类的Service都会在分布式应用程序中使用到。每次编写这些Service都会涉及大量的修bug和竞争情况。正因为这种编写这些Service有一定难度，所以通常都会忽视它们，这就使得在应用程序有变化时变得难以管理应用程序。即使处理得当，实现这些服务的不同方法也会使得部署应用程序变得难以管理。
虽然ZooKeeper是一个Java应用程序，但C也可以使用。这里就有个PHP的扩展，由Andrei Zmievski在2009创建并维护。你可以从PECL中下载，或从GitHub中直接获取PHP-ZooKeeper。
要使用该扩展你首先要安装ZooKeeper。可以从官方网站下载。
$ tar zxfv zookeeper-3.4.5.tar.gz
$ cd zookeeper-3.4.5/src/c
$ ./configure --prefix=/usr/
$ make
$ sudo make install
这样就会安装ZooKeeper的库和头文件。现在准备编译PHP扩展。
$ cd$ git clone https://github.com/andreiz/php-zookeeper.git
$ cd php-zookeeper
$ phpize
$ ./configure
$ make
$ sudo make install
将“zookeeper.so”添加到PHP配置中。
$ vim /etc/php5/cli/conf.d/20-zookeeper.ini
因为我不需要运行在web服务环境下，所以这里我只编辑了CLI的配置。将下面的行复制到ini文件中。
extension=zookeeper.so
使用如下命令来确定扩展是否已起作用。
$ php -m | grep zookeeper
zookeeper
现在是时候运行ZooKeeper了。目前唯一还没有做的是配置。创建一个用于存放所有service数据的目录。
$ mkdir /home/you-account/zoo
$ cd$ cd zookeeper-3.4.5/
$ cp conf/zoo_sample.cfg conf/zoo.cfg
$ vim conf/zoo.cfg
找到名为“dataDir”的属性，将其指向“/home/you-account/zoo”目录。
$ bin/zkServer.sh start
$ bin/zkCli.sh -server 127.0.0.1:2181[zk: 127.0.0.1:2181(CONNECTED) 14] create /test 1
Created /test[zk: 127.0.0.1:2181(CONNECTED) 19] ls /[test, zookeeper]
此时，你已成功连到了ZooKeeper，并创建了一个名为“/test”的znode（稍后我们会用到）。ZooKeeper以树形结构保存数据。这很类似于文件系统，但“文件夹”（译者注：这里指非最底层的节点）又和文件很像。znode是ZooKeeper保存的实体。Node（节点）的说法很容易被混淆，所以为了避免混淆这里使用了znode。
因为我们稍后还会使用，所以这里我们让客户端保持连接状态。开启一个新窗口，并创建一个zookeeperdemo1.php文件。
<?php
class ZookeeperDemo extends Zookeeper {
public function watcher( $i, $type, $key ) {
echo "Insider Watcher\n";
// Watcher gets consumed so we need to set a new one
$this->get( '/test', array($this, 'watcher' ) );
}
}
$zoo = new ZookeeperDemo('127.0.0.1:2181');$zoo->get( '/test', array($zoo, 'watcher' ) );
while( true ) {
echo '.';
sleep(2);}
现在运行该脚本。
$ php zookeeperdemo1.php
此处应该会每隔2秒产生一个点。现在切换到ZooKeeper客户端，并更新“/test”值。
[zk: 127.0.0.1:2181(CONNECTED) 20] set /test foo
这样就会静默触发PHP脚本中的“Insider Watcher”消息。怎么会这样的？
ZooKeeper提供了可以绑定在znode的监视器。如果监视器发现znode发生变化，该service会立即通知所有相关的客户端。这就是PHP脚本如何知道变化的。Zookeeper::get方法的第二个参数是回调函数。当触发事件时，监视器会被消费掉，所以我们需要在回调函数中再次设置监视器。
现在你可以准备创建分布式应用程序了。其中的挑战是让这些独立的程序决定哪个（是leader）协调它们的工作，以及哪些（是worker）需要执行。这个处理过程叫做leader选举，在ZooKeeper Recipes and Solutions你能看到相关的实现方法。
这里简单来说就是，每个处理（或服务器）紧盯着相邻的那个处理（或服务器）。如果一个已被监视的处理（也即Leader）退出或者崩溃了，监视程序就会查找其相邻（此时最老）的那个处理作为Leader。
在真实的应用程序中，leader会给worker分配任务、监控进程和保存结果。这里为了简化，我跳过了这些部分。
创建一个新的PHP文件，命名为worker.php。
<?php
class Worker extends Zookeeper {
const CONTAINER = '/cluster';
protected $acl = array(
array(
'perms' => Zookeeper::PERM_ALL,
'scheme' => 'world',
'id' => 'anyone' ) );
private $isLeader = false;
private $znode;
public function __construct( $host = '', $watcher_cb = null, $recv_timeout = 10000 ) {
parent::__construct( $host, $watcher_cb, $recv_timeout );
}
public function register() {
if( ! $this->exists( self::CONTAINER ) ) {
$this->create( self::CONTAINER, null, $this->acl );
}
$this->znode = $this->create( self::CONTAINER . '/w-',
null,
$this->acl,
Zookeeper::EPHEMERAL | Zookeeper::SEQUENCE );
$this->znode = str_replace( self::CONTAINER .'/', '', $this->znode );
printf( "I'm registred as: %s\n", $this->znode );
$watching = $this->watchPrevious();
if( $watching == $this->znode ) {
printf( "Nobody here, I'm the leader\n" );
$this->setLeader( true ); }
else {
printf( "I'm watching %s\n", $watching );
}
}
public function watchPrevious() {
$workers = $this->getChildren( self::CONTAINER );
sort( $workers );
$size = sizeof( $workers );
for( $i = 0 ; $i < $size ; $i++ ) {
if( $this->znode == $workers[ $i ] ) {
if( $i > 0 ) {
$this->get( self::CONTAINER . '/' . $workers[ $i - 1 ], array( $this, 'watchNode' ) );
return $workers[ $i - 1 ];
}
return $workers[ $i ];
}
}
throw new Exception( sprintf( "Something went very wrong! I can't find myself: %s/%s",
self::CONTAINER,
$this->znode ) );
}
public function watchNode( $i, $type, $name ) {
$watching = $this->watchPrevious();
if( $watching == $this->znode ) {
printf( "I'm the new leader!\n" );
$this->setLeader( true );
}
else {
printf( "Now I'm watching %s\n", $watching ); }
}
public function isLeader() {
return $this->isLeader;
}
public function setLeader($flag) {
$this->isLeader = $flag;
}
public function run() {
$this->register();
while( true ) {
if( $this->isLeader() ) {
$this->doLeaderJob();
}
else {
$this->doWorkerJob();
}
sleep( 2 );
}
}
public function doLeaderJob() {
echo "Leading\n";
}
public function doWorkerJob() {
echo "Working\n";
}
}
$worker = new Worker( '127.0.0.1:2181' );$worker->run();
打开至少3个终端，在每个终端中运行以下脚本：
# term1
$ php worker.php
I'm registred as: w-0000000001Nobody here, I'm the leader
Leading
# term2
$ php worker.php
I'm registred as: w-0000000002I'm watching w-0000000001
Working
# term3
$ php worker.php
I'm registred as: w-0000000003I'm watching w-0000000002
Working
现在模拟Leader崩溃的情形。使用Ctrl+c或其他方法退出第一个脚本。刚开始不会有任何变化，worker可以继续工作。后来，ZooKeeper会发现超时，并选举出新的leader。
虽然这些脚本很容易理解，但是还是有必要对已使用的Zookeeper标志作注释。
$this->znode = $this->create( self::CONTAINER . '/w-', null, $this->acl, Zookeeper::EPHEMERAL | Zookeeper::SEQUENCE );
每个znode都是EPHEMERAL和SEQUENCE的。
EPHEMRAL代表当客户端失去连接时移除该znode。这就是为何PHP脚本会知道超时。SEQUENCE代表在每个znode名称后添加顺序标识。我们通过这些唯一标识来标记worker。
在PHP部分还有些问题要注意。该扩展目前还是beta版，如果使用不当很容易发生segmentation fault。比如，不能传入普通函数作为回调函数，传入的必须为方法。我希望更多PHP社区的同仁可以看到Apache ZooKeeper的好，同时该扩展也会获得更多的支持。
ZooKeeper是一个强大的软件，拥有简洁和简单的API。由于文档和示例都做的很好，任何人都可以很容易的编写分布式软件。让我们开始吧，这会很有趣的。
B. Zookpeer是什么在系统中如何起作用
Zookeeper分布式服务框架是Apache Hadoop的一个子项目，它主要是用来解决分布式应用中经常遇到的一些数据管理问题。如：统一命名服务、状态同步服务、集群管理、分布式应用配置项的管理等。
我们先看看它都提供了哪些功能，然后再看看使用它的这些功能能做点什么。
简单的说，zookeeper=文件系统+通知机制。
Zookeeper维护一个类似文件系统的数据结构：
每个子目录项如 NameService 都被称作为 znode，和文件系统一样，我们能够自由的增加、删除znode，在一个znode下增加、删除子znode，唯一的不同在于znode是可以存储数据的。
客户端注册监听它关心的目录节点，当目录节点发生变化（数据改变、被删除、子目录节点增加删除）时，zookeeper会通知客户端。
这个似乎最简单，在zookeeper的文件系统里创建一个目录，即有唯一的path。在我们使用tborg无法确定上游程序的部署机器时即可与下游程序约定好path，通过path即能互相探索发现，不见不散了。
程序总是需要配置的，如果程序分散部署在多台机器上，要逐个改变配置就变得困难。
可以把这些配置全部放到zookeeper上去，保存在 Zookeeper 的某个目录节点中，然后所有相关应用程序对这个目录节点进行监听，一旦配置信息发生变化，每个应用程序就会收到 Zookeeper 的通知，然后从 Zookeeper 获取新的配置信息应用到系统中就好。
集群管理无在乎两点：是否有机器退出和加入、选举master。
对于第一点，所有机器约定在父目录GroupMembers下创建临时目录节点，然后监听父目录节点的子节点变化消息。一旦有机器挂掉，该机器与 zookeeper的连接断开，其所创建的临时目录节点被删除，所有其他机器都收到通知：某个兄弟目录被删除，于是，所有人都知道：它下船了。当然又会有新机器加入，也是类似：所有机器收到通知---新兄弟目录加入，highcount又有了，有人上船了。
对于第二点，我们假设机器创建临时顺序编号目录节点，每次选取编号最小的机器作为master就好。
有了zookeeper的一致性文件系统，锁的问题变得容易。锁服务可以分为两类，一个是保持独占，另一个是控制时序。
对于第一类，我们将zookeeper上的一个znode看作是一把锁，通过createznode的方式来实现。所有客户端都去创建 /distribute_lock 节点，最终成功创建的那个客户端也即拥有了这把锁。厕所有言：来也冲冲，去也冲冲，用完删除掉自己创建的distribute_lock 节点就释放出锁。
对于第二类， /distribute_lock 已经预先存在，所有客户端在它下面创建临时顺序编号目录节点，和选master一样，编号最小的获得锁，用完删除，依次方便。
两种类型的队列：
1、 同步队列，当一个队列的成员都聚齐时，这个队列才可用，否则一直等待所有成员到达。
2、队列按照 FIFO 方式进行入队和出队操作。
第一类，在约定目录下创建临时目录节点，监听节点数目是否是我们要求的数目。
第二类，和分布式锁服务中的控制时序场景基本原理一致，入列有编号，出列按编号。
Zookeeper中的角色主要有以下三类：
系统模型如图所示：
Zookeeper的核心是原子广播，这个机制保证了各个Server之间的同步。实现这个机制的协议叫做Zab协议。Zab协议有两种模式，它们分 别是恢复模式（选主）和广播模式（同步）。当服务启动或者在领导者崩溃后，Zab就进入了恢复模式，当领导者被选举出来，且大多数Server完成了和 leader的状态同步以后，恢复模式就结束了。状态同步保证了leader和Server具有相同的系统状态。
为了保证事务的顺序一致性，zookeeper采用了递增的事务id号（zxid）来标识事务。所有的提议（proposal）都在被提出的时候加上 了zxid。实现中zxid是一个64位的数字，它高32位是epoch用来标识leader关系是否改变，每次一个leader被选出来，它都会有一个 新的epoch，标识当前属于那个leader的统治时期。低32位用于递增计数。
每个Server在工作过程中有三种状态：
当leader崩溃或者leader失去大多数的follower，这时候zk进入恢复模式，恢复模式需要重新选举出一个新的leader，让所有的 Server都恢复到一个正确的状态。Zk的选举算法有两种：一种是基于basic paxos实现的，另外一种是基于fast paxos算法实现的。系统默认的选举算法为fast paxos。先介绍basic paxos流程：
通过流程分析我们可以得出：要使Leader获得多数Server的支持，则Server总数必须是奇数2n+1，且存活的Server的数目不得少于n+1.
选完leader以后，zk就进入状态同步过程。
Leader主要有三个功能：
PING消息是指Learner的心跳信息；REQUEST消息是Follower发送的提议信息，包括写请求及同步请求；ACK消息是 Follower的对提议的回复，超过半数的Follower通过，则commit该提议；REVALIDATE消息是用来延长SESSION有效时间。
Leader的工作流程简图如下所示，在实际实现中，流程要比下图复杂得多，启动了三个线程来实现功能。
Follower主要有四个功能：
Follower的消息循环处理如下几种来自Leader的消息：
Follower的工作流程简图如下所示，在实际实现中，Follower是通过5个线程来实现功能的。
https://blog.csdn.net/xinguan1267/article/details/38422149
https://blog.csdn.net/gs80140/article/details/51496925
https://www.2cto.com/kf/201708/668587.html
https://blog.csdn.net/milhua/article/details/78931672
P.S. 这篇文章是本人对网络上关于ZK的文章阅读之后整理所得，作为入门级的了解。个人觉得看了上面的内容就能基本了解Zookeeper的作用了，后面在结合实际项目使用加深自己的了解。
end
C. zkparking数据库配置程序
摘要 这边给您查询分析到每台机器的应用程序都需要连接数据库，而数据库的配置信息（连接信息），这时候放在机器本地的话不方面（机器多，需要一个个改配置信息），这就用到Zookeeper，把数据库的配置信息放到配置中心，利用Zookeeper节点可以存储数据的特性，然后各台机器可以使用JavaAPI去获取Zookeeper中数据库的配置信息。每一个应用都在Zookeeper节点注册监听器，一旦节点信息改变，各台机器就获取信息，使用最新的信息连接数据库，这样优点一是方便了管理（只放置一份数据在配置中心，没必要放到多个机器上去），二是一旦配置改了，就做一个发布的动作即可。
D. zk框架问题
java 代码
detail.addEventListener("fulfill", new EventListener(){
@Override
public void onEvent(Event arg0) throws Exception {
}
});
detail.addEventListener("onOpen", new EventListener(){
@Override
public void onEvent(Event arg0) throws Exception {
}
});
E. zk是什么意思
1、ZK是一套以AJAX/XUL/Java为基础的网页应用程序开发框架，用于丰富网页应用程序的使用界面。
2、ZK是科视界股份有限公司注册申请的品牌，品牌产品有光导电子液位仪。
3、zk电影网，主要为广大影视迷提供最新最好看的电视剧、电影、动画片及播放服务。网站内容绿色健康，页面简洁大方。无广告无弹窗，24小时安全监控，保证没病毒没不良内容。
ZK发展理念
zk电影网自2012年07月上线以来，经历了种种不同在困难，在风格设计与内容发布方面我投入了不少成本与精力之外，更是网站管理人员对网站的精心维护，然而，网站的日流量正在日益飙升，努力打造成为一个广大网民喜欢的无广告弹窗、绿色安全的电影体验网站。
ZK程序包含了一个以AJAX为基础、事件驱动（event-driven）、高互动性的引擎。
以上内容参考：网络-ZK （程序）、网络-ZK （商标）、网络-zk电影网
F. java程序员在面试中被问到如何配置多数据源以及如何配置多数据源下的分布式事务，该怎么回答看清再做答
你好，我来先回答你的第一个问题：
通常多数据源，在spring中配置如下，如果你想切换环境ENV 的值，在property中
<bean id="placeholderConfigurer" class="org.springframework.beans.factory.config.PropertyPlaceholderConfigurer">
<property name="ignoreResourceNotFound" value="true"></property>
<property name="" value="true"></property>
<property name="nullValue" value="NULL"></property>
<property name="locations">
<list>
<value>jdbc.properties</value>
</list>
</property>
</bean>
<bean id="dataSource" class="com.spring..JDBCConfig">
<property name="driverClassName" value="${${Env}.jdbc.driverClassName}"></property>
<property name="url" value="${${Env}.jdbc.url}"></property>
<property name="username" value="${${Env}.jdbc.username1}"></property>
<property name="password" value="${${Env}.jdbc.password}"></property>
</bean>
jdbc.properties
*****************************
Env=PROD
jdbc.driverClassName=${${Env}.jdbc.driverClassName}
jdbc.url=${${Env}.jdbc.url}
jdbc.username=${${Env}.jdbc.username}
jdbc.password=${${Env}.jdbc.password}
######### JDBC Configuration for DEV Environment ###############
DEV.jdbc.driverClassName=com.mysql.jdbc.Driver
DEV.jdbc.url=jdbc:mysql://localhost:3306/devportal
DEV.jdbc.username=DEVuser
DEV.jdbc.password=DEVpwd
######### JDBC Configuration for UAT Environment ############
UAT.jdbc.driverClassName=com.mysql.jdbc.Driver
UAT.jdbc.url=jdbc:mysql://localhost:3306/UATportal
UAT.jdbc.username=UATuser
UAT.jdbc.password=UATpwd
########## JDBC Configuration for PROD Environment ############
PROD.jdbc.driverClassName=com.mysql.jdbc.Driver
PROD.jdbc.url=jdbc:mysql://localhost:3306/portal
PROD.jdbc.username=root
PROD.jdbc.password=admin，
我这里有三套环境，分别是DEV，UAT和PROD，这种方式可以灵活切换的。
我再回答你的第二个问题：
还请你去http://docs.spring.io/spring-framework/docs/4.0.x/spring-framework-reference/html/transaction.html这里看下，很详细，不过是英文的哦
G. 易语言写多个配置项
.版本 2
.程序集 窗口程序集1
.程序集变量 按钮, 按钮, , "0"
.子程序 __启动窗口_创建完毕
' 原理上是这样的，但方法可以改变下~并不是说一定要写N条代码
' 如果按这种逻辑编程，我想很多程序的体积会比现在大上好几倍吧！
' 下面我以按钮为例写N个配置项，方法可根椐需求而改变，不要局限于某种方法！
按钮1.可视 ＝ 假 ' 用于复制按钮
按钮2.标题 ＝ “读配置”
按钮3.标题 ＝ “写配置”
.子程序 _按钮2_被单击, , , 读配置
读配置 ()
.子程序 _按钮3_被单击, , , 写配置
写配置 ()
.子程序 读配置
创建按钮 (12, 真) ' 注意使用此程序，不要重复创建了！
.子程序 销毁按钮
.局部变量 n, 整数型
.计次循环首 (取数组成员数 (按钮), n)
.如果真 (是否已创建 (按钮 [n]))
按钮 [n].销毁 ()
.如果真结束
.计次循环尾 ()
.子程序 创建按钮
.参数 数量
.参数 读, 逻辑型, 可空
.局部变量 n, 整数型
销毁按钮 () ' 最好在重新创建时 销毁 之前创建的按钮
按钮1.可视 ＝ 假
重定义数组 (按钮, 假, 数量)
.计次循环首 (数量, n)
复制窗口组件 (按钮1, 按钮 [n])
按钮 [n].左边 ＝ n × 80 － 70
.如果 (读)
按钮 [n].标题 ＝ 读配置项 (取运行目录 () ＋ “\配置.ini”, “按钮配置”, “按钮” ＋ 到文本 (n), “无”)
.否则
按钮 [n].标题 ＝ “按钮” ＋ 到文本 (取随机数 (1, 99))
.如果结束
按钮 [n].可视 ＝ 真
.计次循环尾 ()
.子程序 写配置
.局部变量 n, 整数型
创建按钮 (12) ' 注意使用此程序，不要重复创建了！
.计次循环首 (取数组成员数 (按钮), n)
写配置项 (取运行目录 () ＋ “\配置.ini”, “按钮配置”, “按钮” ＋ 到文本 (n), 按钮 [n].标题)
.计次循环尾 ()
H. zookeeper怎么实现分布式锁
1. 利用节点名称的唯一性来实现共享锁
ZooKeeper抽象出来的节点结构是一个和unix文件系统类似的小型的树状的目录结构。ZooKeeper机制规定：同一个目录下只能有一个唯一的文件名。例如：我们在Zookeeper目录/test目录下创建，两个客户端创建一个名为Lock节点，只有一个能够成功。
算法思路: 利用名称唯一性，加锁操作时，只需要所有客户端一起创建/test/Lock节点，只有一个创建成功，成功者获得锁。解锁时，只需删除/test/Lock节点，其余客户端再次进入竞争创建节点，直到所有客户端都获得锁。
基于以上机制，利用节点名称唯一性机制的共享锁算法流程如图所示：
该共享锁实现很符合我们通常多个线程去竞争锁的概念，利用节点名称唯一性的做法简明、可靠。
由上述算法容易看出，由于客户端会同时收到/test/Lock被删除的通知，重新进入竞争创建节点，故存在"惊群现象"。
使用该方法进行测试锁的性能列表如下：
总结 这种方案的正确性和可靠性是ZooKeeper机制保证的，实现简单。缺点是会产生“惊群”效应，假如许多客户端在等待一把锁，当锁释放时候所有客户端都被唤醒，仅仅有一个客户端得到锁。
2. 利用临时顺序节点实现共享锁的一般做法
首先介绍一下，Zookeeper中有一种节点叫做顺序节点，故名思议，假如我们在/lock/目录下创建节3个点，ZooKeeper集群会按照提起创建的顺序来创建节点，节点分别为/lock/0000000001、/lock/0000000002、/lock/0000000003。
ZooKeeper中还有一种名为临时节点的节点，临时节点由某个客户端创建，当客户端与ZooKeeper集群断开连接，则开节点自动被删除。
利用上面这两个特性，我们来看下获取实现分布式锁的基本逻辑：
客户端调用create()方法创建名为“locknode/guid-lock-”的节点，需要注意的是，这里节点的创建类型需要设置为EPHEMERAL_SEQUENTIAL。
客户端调用getChildren(“locknode”)方法来获取所有已经创建的子节点，同时在这个节点上注册上子节点变更通知的Watcher。
客户端获取到所有子节点path之后，如果发现自己在步骤1中创建的节点是所有节点中序号最小的，那么就认为这个客户端获得了锁。
如果在步骤3中发现自己并非是所有子节点中最小的，说明自己还没有获取到锁，就开始等待，直到下次子节点变更通知的时候，再进行子节点的获取，判断是否获取锁。
释放锁的过程相对比较简单，就是删除自己创建的那个子节点即可。
上面这个分布式锁的实现中，大体能够满足了一般的分布式集群竞争锁的需求。这里说的一般性场景是指集群规模不大，一般在10台机器以内。
不过，细想上面的实现逻辑，我们很容易会发现一个问题，步骤4，“即获取所有的子点，判断自己创建的节点是否已经是序号最小的节点”，这个过程，在整个分布式锁的竞争过程中，大量重复运行，并且绝大多数的运行结果都是判断出自己并非是序号最小的节点，从而继续等待下一次通知——这个显然看起来不怎么科学。客户端无端的接受到过多的和自己不相关的事件通知，这如果在集群规模大的时候，会对Server造成很大的性能影响，并且如果一旦同一时间有多个节点的客户端断开连接，这个时候，服务器就会像其余客户端发送大量的事件通知——这就是所谓的惊群效应。而这个问题的根源在于，没有找准客户端真正的关注点。
我们再来回顾一下上面的分布式锁竞争过程，它的核心逻辑在于：判断自己是否是所有节点中序号最小的。于是，很容易可以联想的到的是，每个节点的创建者只需要关注比自己序号小的那个节点。
3、利用临时顺序节点实现共享锁的改进实现
下面是改进后的分布式锁实现，和之前的实现方式唯一不同之处在于，这里设计成每个锁竞争者，只需要关注”locknode”节点下序号比自己小的那个节点是否存在即可。
算法思路：对于加锁操作，可以让所有客户端都去/lock目录下创建临时顺序节点，如果创建的客户端发现自身创建节点序列号是/lock/目录下最小的节点，则获得锁。否则，监视比自己创建节点的序列号小的节点（比自己创建的节点小的最大节点），进入等待。
对于解锁操作，只需要将自身创建的节点删除即可。
具体算法流程如下图所示:
使用上述算法进行测试的的结果如下表所示：
该算法只监控比自身创建节点序列号小(比自己小的最大的节点)的节点，在当前获得锁的节点释放锁的时候没有“惊群”。
总结 利用临时顺序节点来实现分布式锁机制其实就是一种按照创建顺序排队的实现。这种方案效率高，避免了“惊群”效应，多个客户端共同等待锁，当锁释放时只有一个客户端会被唤醒。
4、使用menagerie
其实就是对方案3的一个封装，不用自己写代码了。直接拿来用就可以了。
menagerie基于Zookeeper实现了java.util.concurrent包的一个分布式版本。这个封装是更大粒度上对各种分布式一致性使用场景的抽象。其中最基础和常用的是一个分布式锁的实现： org.menagerie.locks.ReentrantZkLock，通过ZooKeeper的全局有序的特性和EPHEMERAL_SEQUENTIAL类型znode的支持，实现了分布式锁。具体做法是：不同的client上每个试图获得锁的线程，都在相同的basepath下面创建一个EPHEMERAL_SEQUENTIAL的node。EPHEMERAL表示要创建的是临时znode，创建连接断开时会自动删除； SEQUENTIAL表示要自动在传入的path后面缀上一个自增的全局唯一后缀,作为最终的path。因此对不同的请求ZK会生成不同的后缀，并分别返回带了各自后缀的path给各个请求。因为ZK全局有序的特性，不管client请求怎样先后到达，在ZKServer端都会最终排好一个顺序，因此自增后缀最小的那个子节点，就对应第一个到达ZK的有效请求。然后client读取basepath下的所有子节点和ZK返回给自己的path进行比较，当发现自己创建的sequential node的后缀序号排在第一个时，就认为自己获得了锁；否则的话，就认为自己没有获得锁。这时肯定是有其他并发的并且是没有断开的client/线程先创建了node。
I. zk集群数据迁移和恢复
zk集群数据迁移和恢复
一、zk数据迁移，有如下两种方案：
1、利用zk集群超过半数仍然可用的特性，比如集群中有5个节点，可以将其中1~2个节点割裂出去，再添加1个新的节点，组成新的集群，以此实现数据迁移；
2、直接拷贝集群的元数据文件到新集群；
但第1种方案并不是最佳选择，例如zk集群连接数负载高，如果此时再减少节点数，则会导致集群负载变得更高，甚至集群崩溃。故采用第2种方案，通过拷贝元数据的方式来实现集群数据迁移和恢复。
二、zk数据迁移和恢复的实现思路
1、搭建好新的zk集群，并且启动集群（此时集群还没有数据）；
2、停止新集群所有节点的zk进程；
3、删除新集群所有节点数据目录下的文件，包括：事务日志、快照、epoch文件
4、将老集群leader节点的事务日志、快照、epoch文件拷贝到新集群所有节点对应的数据目录下；
5、重新启动新集群；
三、注意事项：
如果新集群的两个epoch文件不删掉的话，会造成新集群无法启动；原因是：如果只是拷贝了老集群的快照、事务日志到新集群，新集群的节点在启动时会识别epoch文件中记录的当前epoch值，然后将这个epoch值和从老集群拷贝过来的元数据中的事务ID（zxid）进行比较，发现并不匹配，就会造成新集群无法正常启动。故需要将新集群中各个节点的epoch文件删除，将老集群的epoch文件、快照文件、事务日志文件一并拷贝到新集群的各个节点。
四、zk数据迁移和恢复的具体操作步骤：
1、搭建新集群：
1）、rpm -ivh jdk-8u20-linux-x64.rpm
2）、cd /data/ && tar -zxvf zk_server.tgz ###解压到/data或者/data1
3）、cd /data/ && mv zk_server zk.1 ###myid为1的节点，家目录为/data/zk.1、myid为2的节点，家目录为/data/zk.2
4）、解压之后，可以看到3个目录：
cd /data/zk.1 && ls -l
zk_data ###保存zk快照数据的主目录
zk_log ###保存zk事务日志的主目录
zookeeper ###程序路径，包含配置文件
5）、cd /data/zk.1/zk_data && echo 1 > myid ###配置节点myid，myid为1的节点配置成1，myid为2的节点配置成2，myid为3的节点配置3
6）、cd /data/zk.1/zookeeper/conf && cp -ar zoo.cfg.template zoo.cfg
7）、vim zoo.cfg
tickTime=2000
initLimit=10
syncLimit=5
clientPort=2181
autopurge.snapRetainCount=500
autopurge.purgeInterval = 48
dataDir=/data/zk.1/zk_data ###myid为2则配置为/data/zk.2/zk_data
dataLogDir=/data/zk.1/zk_log ###myid为2则配置为/data/zk.2/zk_log
server.1=节点1的IP:8880:7770 #节点1的配置
server.2=节点2的IP:8880:7770 #节点2的配置
server.3=节点3的IP:8880:7770 #节点3的配置
8）、其余2个节点的安装部署方法也是一样
9）、依次启动3个节点，并检查状态
启动：
cd /data/zk.1/zookeeper/bin/ && nohup sh zkServer.sh start > zookeeper.out &
检查节点状态：
cd /data/zk.1/zookeeper/bin/ && ./zkServer.sh status
连接本地节点，查看数据：
cd /data/zk.1/zookeeper/bin/ && ./zkCli.sh -server 127.0.0.1:2181
2、停止新集群所有节点的zk进程：
cd /data/zk.1/zookeeper/bin/ && sh zkServer.sh stop
cd /data/zk.2/zookeeper/bin/ && sh zkServer.sh stop
cd /data/zk.3/zookeeper/bin/ && sh zkServer.sh stop
3、删除新集群所有节点数据目录下的文件，包括：事务日志、快照、epoch文件（以节点1为例）：
cd /data/zk.1/zk_data/version-2 && rm -f snapshot.* && rm -f acceptedEpoch && rm -f currentEpoch
cd /data/zk.1/zk_log/version-2 && rm -f log.*
4、将老集群leader节点的事务日志、快照、epoch文件拷贝到新集群所有节点对应的数据目录下（以leader节点的数据为准）：
1）、备份老集群leader节点的数据目录下的文件（拷贝到本地的新建的zk_meta_dir目录）
最新的log事务日志文件 ###不是所有的log文件，而是最新的log文件
最新的snapshot文件 ###不是所有的snapshot文件，而是最新的snapshot文件
acceptedEpoch文件
currentEpoch文件
2）、将leader节点zk_meta_dir目录的log文件、snapshot文件、Epoch文件分发到新集群每个节点对应的目录，例如节点1的/data/zk.1/zk_data/version-2、/data/zk.1/zk_log/version-2
5、重新启动新集群：
以节点1为例：
cd /data/zk.1/zookeeper/bin/ && nohup sh zkServer.sh start > zookeeper.out &