zookeeper我已经设置分布式，为什么总显示是单机模式
将运行多个应用程序作为一个逻辑程序并不是什么新玩意。事实上，我在几年前就已写过类似的软件。这种架构比较让人迷惑，使用起来也费劲。为此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。由于文档和示例都做的很好，任何人都可以很容易的编写分布式软件。让我们开始吧，这会很有趣的。
利用节点名称的唯一性来实现共享锁
ZooKeeper抽象出来的节点结构是一个和unix文件系统类似的小型的树状的目录结构。ZooKeeper机制规定：同一个目录下只能有一个唯一的文件名。例如：我们在Zookeeper目录/test目录下创建，两个客户端创建一个名为Lock节点，只有一个能够成功。
算法思路: 利用名称唯一性，加锁操作时，只需要所有客户端一起创建/test/Lock节点，只有一个创建成功，成功者获得锁。解锁时，只需删除/test/Lock节点，其余客户端再次进入竞争创建节点，直到所有客户端都获得锁。
基于以上机制，利用节点名称唯一性机制的共享锁算法流程如图所示：
该共享锁实现很符合我们通常多个线程去竞争锁的概念，利用节点名称唯一性的做法简明、可靠。
由上述算法容易看出，由于客户端会同时收到/test/Lock被删除的通知，重新进入竞争创建节点，故存在"惊群现象"。
使用该方法进行测试锁的性能列表如下：
总结 这种方案的正确性和可靠性是ZooKeeper机制保证的，实现简单。缺点是会产生“惊群”效应，假如许多客户端在等待一把锁，当锁释放时候所有客户端都被唤醒，仅仅有一个客户端得到锁。
2. 利用临时顺序节点实现共享锁的一般做法
首先介绍一下，Zookeeper中有一种节点叫做顺序节点，故名思议，假如我们在/lock/目录下创建节3个点，ZooKeeper集群会按照提起创建的顺序来创建节点，节点分别为/lock/、/lock/、/lock/。
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。
