dubbo注册zk后是内网地址问题

1、查看当前hostname

hostname

2、修改/etc/hosts文件

vim /etc/hosts

将hostname对应的ip地址改为外网地址

3、重启jar包即可

注修改/etc/hosts文件 记得将localhost新增为127001  本地ip地址，防止tomcat启动不起来（orgapachecatalinacoreStandardServerawait 无法在地址[localhost]和端口[8005]上创建服务器关闭套接字（基本端口[8005]和偏移量[0]）javanetBindException: 无法指定被请求的地址 (Bind failed)）

　　ZooKeeper作为发现服务的问题

　　ZooKeeper(注：ZooKeeper是著名Hadoop的一个子项目，旨在解决大规模分

布式应用场景下，服务协调同步(Coordinate

Service)的问题;它可以为同在一个分布式系统中的其他服务提供：统一命名服务、配置管理、分布式锁服务、集群管理等功能)是个伟大的开源项目，它

很成熟，有相当大的社区来支持它的发展，而且在生产环境得到了广泛的使用;但是用它来做Service发现服务解决方案则是个错误。

　　在分布式系统领域有个著名的 CAP定理(C-

数据一致性;A-服务可用性;P-服务对网络分区故障的容错性，这三个特性在任何分布式系统中不能同时满足，最多同时满足两个);ZooKeeper是个

CP的，即任何时刻对ZooKeeper的访问请求能得到一致的数据结果，同时系统对网络分割具备容错性;但是它不能保证每次服务请求的可用性(注：也就

是在极端环境下，ZooKeeper可能会丢弃一些请求，消费者程序需要重新请求才能获得结果)。但是别忘了，ZooKeeper是分布式协调服务，它的

职责是保证数据(注：配置数据，状态数据)在其管辖下的所有服务之间保持同步、一致;所以就不难理解为什么ZooKeeper被设计成CP而不是AP特性

的了，如果是AP的，那么将会带来恐怖的后果(注：ZooKeeper就像交叉路口的信号灯一样，你能想象在交通要道突然信号灯失灵的情况吗)。而且，

作为ZooKeeper的核心实现算法 Zab，就是解决了分布式系统下数据如何在多个服务之间保持同步问题的。

　　作为一个分布式协同服务，ZooKeeper非常好，但是对于Service发现服务来说就不合适了;因为对于Service发现服务来说就算

是

返回了包含不实的信息的结果也比什么都不返回要好;再者，对于Service发现服务而言，宁可返回某服务5分钟之前在哪几个服务器上可用的信息，也不能

因为暂时的网络故障而找不到可用的服务器，而不返回任何结果。所以说，用ZooKeeper来做Service发现服务是肯定错误的，如果你这么用就惨

了!

　　而且更何况，如果被用作Service发现服务，ZooKeeper本身并没有正确的处理网络分割的问题;而在云端，网络分割问题跟其他类型的

故障一样的确会发生;所以最好提前对这个问题做好100%的准备。就像 Jepsen在

ZooKeeper网站上发布的博客中所说：在ZooKeeper中，如果在同一个网络分区(partition)的节点数(nodes)数达不到

ZooKeeper选取Leader节点的逗法定人数地时，它们就会从ZooKeeper中断开，当然同时也就不能提供Service发现服务了。

　　如果给ZooKeeper加上客户端缓存(注：给ZooKeeper节点配上本地缓存)或者其他类似技术的话可以缓解ZooKeeper因为网

络故障造成节点同步信息错误的问题。 Pinterest与 Airbnb公

司就使用了这个方法来防止ZooKeeper故障发生。这种方式可以从表面上解决这个问题，具体地说，当部分或者所有节点跟ZooKeeper断开的情况

下，每个节点还可以从本地缓存中获取到数据;但是，即便如此，ZooKeeper下所有节点不可能保证任何时候都能缓存所有的服务注册信息。如果

ZooKeeper下所有节点都断开了，或者集群中出现了网络分割的故障(注：由于交换机故障导致交换机底下的子网间不能互访);那么ZooKeeper

会将它们都从自己管理范围中剔除出去，外界就不能访问到这些节点了，即便这些节点本身是逗健康地的，可以正常提供服务的;所以导致到达这些节点的服务请求

被丢失了。(注：这也是为什么ZooKeeper不满足CAP中A的原因)

　　更深层次的原因是，ZooKeeper是按照CP原则构建的，也就是说它能保证每个节点的数据保持一致，而为ZooKeeper加上缓存的做法

的

目的是为了让ZooKeeper变得更加可靠(available);但是，ZooKeeper设计的本意是保持节点的数据一致，也就是CP。所以，这样

一来，你可能既得不到一个数据一致的(CP)也得不到一个高可用的(AP)的Service发现服务了;因为，这相当于你在一个已有的CP系统上强制栓了

一个AP的系统，这在本质上就行不通的!一个Service发现服务应该从一开始就被设计成高可用的才行!

　　如果抛开CAP原理不管，正确的设置与维护ZooKeeper服务就非常的困难;错误会 经常发生，

导致很多工程被建立只是为了减轻维护ZooKeeper的难度。这些错误不仅存在与客户端而且还存在于ZooKeeper服务器本身。Knewton平台

很多故障就是由于ZooKeeper使用不当而导致的。那些看似简单的操作，如：正确的重建观察者(reestablishing

watcher)、客户端Session与异常的处理与在ZK窗口中管理内存都是非常容易导致ZooKeeper出错的。同时，我们确实也遇到过

ZooKeeper的一些经典bug： ZooKeeper-1159 与 ZooKeeper-1576;

我们甚至在生产环境中遇到过ZooKeeper选举Leader节点失败的情况。这些问题之所以会出现，在于ZooKeeper需要管理与保障所管辖服务

群的Session与网络连接资源(注：这些资源的管理在分布式系统环境下是极其困难的);但是它不负责管理服务的发现，所以使用ZooKeeper当

Service发现服务得不偿失。

　　做出正确的选择：Eureka的成功

　　我们把Service发现服务从ZooKeeper切换到了Eureka平台，它是一个开

源的服务发现解决方案，由Netflix公司开发。(注：Eureka由两个组件组成：Eureka服务器和Eureka客户端。Eureka服务器用作

服务注册服务器。Eureka客户端是一个java客户端，用来简化与服务器的交互、作为轮询负载均衡器，并提供服务的故障切换支持。)Eureka一开

始就被设计成高可用与可伸缩的Service发现服务，这两个特点也是Netflix公司开发所有平台的两个特色。(

他们都在讨论Eureka)。自从切换工作开始到现在，我们实现了在生产环境中所有依赖于Eureka的产品没有下线维护的记录。我们也被告知过，在云平

台做服务迁移注定要遇到失败;但是我们从这个例子中得到的经验是，一个优秀的Service发现服务在其中发挥了至关重要的作用!

　　首先，在Eureka平台中，如果某台服务器宕机，Eureka不会有类似于ZooKeeper的选举leader的过程;客户端请求会自动切

换

到新的Eureka节点;当宕机的服务器重新恢复后，Eureka会再次将其纳入到服务器集群管理之中;而对于它来说，所有要做的无非是同步一些新的服务

注册信息而已。所以，再也不用担心有逗掉队地的服务器恢复以后，会从Eureka服务器集群中剔除出去的风险了。Eureka甚至被设计用来应付范围更广

的网络分割故障，并实现逗0地宕机维护需求。当网络分割故障发生时，每个Eureka节点，会持续的对外提供服务(注：ZooKeeper不会)：接收新

的服务注册同时将它们提供给下游的服务发现请求。这样一来，就可以实现在同一个子网中(same side of

partition)，新发布的服务仍然可以被发现与访问。

　　但是，Eureka做到的不止这些。正常配置下，Eureka内置了心跳服务，用于淘汰一些逗濒死地的服务器;如果在Eureka中注册的服

务，

它的逗心跳地变得迟缓时，Eureka会将其整个剔除出管理范围(这点有点像ZooKeeper的做法)。这是个很好的功能，但是当网络分割故障发生时，

这也是非常危险的;因为，那些因为网络问题(注：心跳慢被剔除了)而被剔除出去的服务器本身是很地健康逗的，只是因为网络分割故障把Eureka集群分割

成了独立的子网而不能互访而已。

　　幸运的是，Netflix考虑到了这个缺陷。如果Eureka服务节点在短时间里丢失了大量的心跳连接(注：可能发生了网络故障)，那么这个

Eureka节点会进入地自我保护模式逗，同时保留那些逗心跳死亡逗的服务注册信息不过期。此时，这个Eureka节点对于新的服务还能提供注册服务，对

于地死亡逗的仍然保留，以防还有客户端向其发起请求。当网络故障恢复后，这个Eureka节点会退出地自我保护模式逗。所以Eureka的哲学是，同时保

留地好数据逗与地坏数据逗总比丢掉任何地好数据逗要更好，所以这种模式在实践中非常有效。

　　最后，Eureka还有客户端缓存功能(注：Eureka分为客户端程序与服务器端程序两个部分，客户端程序负责向外提供注册与发现服务接

口)。

所以即便Eureka集群中所有节点都失效，或者发生网络分割故障导致客户端不能访问任何一台Eureka服务器;Eureka服务的消费者仍然可以通过

Eureka客户端缓存来获取现有的服务注册信息。甚至最极端的环境下，所有正常的Eureka节点都不对请求产生相应，也没有更好的服务器解决方案来解

决这种问题时;得益于Eureka的客户端缓存技术，消费者服务仍然可以通过Eureka客户端查询与获取注册服务信息，这点很重要。

　　Eureka的构架保证了它能够成为Service发现服务。它相对与ZooKeeper来说剔除了Leader节点的选取或者事务日志机制，

这

样做有利于减少使用者维护的难度也保证了Eureka的在运行时的健壮性。而且Eureka就是为发现服务所设计的，它有独立的客户端程序库，同时提供心

跳服务、服务健康监测、自动发布服务与自动刷新缓存的功能。但是，如果使用ZooKeeper你必须自己来实现这些功能。Eureka的所有库都是开源

的，所有人都能看到与使用这些源代码，这比那些只有一两个人能看或者维护的客户端库要好。

　　维护Eureka服务器也非常的简单，比如，切换一个节点只需要在现有EIP下移除一个现有的节点然后添加一个新的就行。Eureka提供了一

个

web-based的图形化的运维界面，在这个界面中可以查看Eureka所管理的注册服务的运行状态信息：是否健康，运行日志等。Eureka甚至提供

了Restful-API接口，方便第三方程序集成Eureka的功能。

华为云平台服务器的业务节点简称为如下，

FC:cna：compute node agent

vna：virtual node agent

uvp：unified virtual platform

vrm：virtual resource manage

dvs：distributed virtual switch

ovs：open virtual switch

evs：enhance virtual switch

vsa：virtual service appliance

vsam：virtual service appliance manager

drs：dynamic resources schedule

dpm：dynamic power management

ha：high availablity

ft：fault-tolerant

vmdq：virtual manager device queue

sr-iov：single root -io virtual

FA:

ad：active directory

dns：domain name system

dhcp：dynamic host configuration protocol

wi：web interface

li：license

ita：it adaptor

hdc：huawei desktop controller

hdp：huawei desktop protocol

hda：huawei desktop agent

vlb：virtual load balance

vag：virtual access getway

db：data base

svn：

tc：thin clint

uns：unit name service

FS：

zk：zookeeper

mdc：mate data controller

vbs：virtual block system

osd：object storage device

fsa：fusionstorage agent

fsm：fusionstorage manager

cvm：cloud virtual machine

dht：distributed hash table

OPENSTACK:

vdc：virtual data center

vpc：virtual private cloud

az：availablity zone

cbs：cloudos boot service

cps：cloudos provision service 部署

dvr：distributed virtual router

om：operate management

rpo：recovery point objective

rto：recovery time objective

————————————————

版权声明：本文为CSDN博主「这都小意思」的原创文章，遵循CC 40 BY-SA版权协议，转载请附上原文出处链接及本声明。

原文链接：https://blogcsdnnet/qq_41788991/article/details/79445922

(1)配置管理

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

Zookeeper很容易实现这种集中式的配置管理，比如将APP1的所有配置配置到/APP1 znode下，APP1所有机器一启动就对/APP1这个节点进行监控(zkexist("/APP1",true)),并且实现回调方法Watcher，那么在zookeeper上/APP1 znode节点下数据发生变化的时候，每个机器都会收到通知，Watcher方法将会被执行，那么应用再取下数据即可(zkgetData("/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类型，这样每个节点会自动被编号，例如 zkcreate("/testRootPath/testChildPath1","1"getBytes(), IdsOPEN_ACL_UNSAFE,CreateModeEPHEMERAL_SEQUENTIAL);

zkcreate("/testRootPath/testChildPath2","2"getBytes(), IdsOPEN_ACL_UNSAFE,CreateModeEPHEMERAL_SEQUENTIAL);

zkcreate("/testRootPath/testChildPath3","3"getBytes(), IdsOPEN_ACL_UNSAFE,CreateModeEPHEMERAL_SEQUENTIAL);

// 创建一个子目录节点

zkcreate("/testRootPath/testChildPath4","4"getBytes(), IdsOPEN_ACL_UNSAFE,CreateModeEPHEMERAL_SEQUENTIAL);

Systemoutprintln(zkgetChildren("/testRootPath", false));

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

zkcreate("/testRootPath", "testRootData"getBytes(),IdsOPEN_ACL_UNSAFE, CreateModePERSISTENT);

// 创建一个子目录节点

zkcreate("/testRootPath/testChildPath1","1"getBytes(), IdsOPEN_ACL_UNSAFE,CreateModeEPHEMERAL);

zkcreate("/testRootPath/testChildPath2","2"getBytes(), IdsOPEN_ACL_UNSAFE,CreateModeEPHEMERAL);

zkcreate("/testRootPath/testChildPath3","3"getBytes(), IdsOPEN_ACL_UNSAFE,CreateModeEPHEMERAL);

// 创建一个子目录节点

zkcreate("/testRootPath/testChildPath4","4"getBytes(), IdsOPEN_ACL_UNSAFE,CreateModeEPHEMERAL);

Systemoutprintln(zkgetChildren("/testRootPath", false));

打印结果:[testChildPath2, testChildPath1, testChildPath4, testChildPath3]

我们默认规定编号最小的为master,所以当我们对/APP1SERVERS节点做监控的时候，得到服务器列表，只要所有集群机器逻辑认为最小编号节点为master，那么master就被选出，而这个master宕机的时候，相应的znode会消失，然后新的服务器列表就被推送到客户端，然后每个节点逻辑认为最小编号节点为master，这样就做到动态master选举。

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-345targz

$ cd zookeeper-345/src/c

$ /configure --prefix=/usr/

$ make

$ sudo make install

这样就会安装ZooKeeper的库和头文件。现在准备编译PHP扩展。

$ cd$ git clone https://githubcom/andreiz/php-zookeepergit

$ cd php-zookeeper

$ phpize

$ /configure

$ make

$ sudo make install

将“zookeeperso”添加到PHP配置中。

$ vim /etc/php5/cli/confd/20-zookeeperini

因为我不需要运行在web服务环境下，所以这里我只编辑了CLI的配置。将下面的行复制到ini文件中。

extension=zookeeperso

使用如下命令来确定扩展是否已起作用。

$ php -m | grep zookeeper

zookeeper

现在是时候运行ZooKeeper了。目前唯一还没有做的是配置。创建一个用于存放所有service数据的目录。

$ mkdir /home/you-account/zoo

$ cd$ cd zookeeper-345/

$ cp conf/zoo_samplecfg conf/zoocfg

$ vim conf/zoocfg

找到名为“dataDir”的属性，将其指向“/home/you-account/zoo”目录。

$ bin/zkServersh start

$ bin/zkClish -server 127001:2181[zk: 127001:2181(CONNECTED) 14] create /test 1

Created /test[zk: 127001:2181(CONNECTED) 19] ls /[test, zookeeper]

此时，你已成功连到了ZooKeeper，并创建了一个名为“/test”的znode（稍后我们会用到）。ZooKeeper以树形结构保存数据。这很类似于文件系统，但“文件夹”（译者注：这里指非最底层的节点）又和文件很像。znode是ZooKeeper保存的实体。Node（节点）的说法很容易被混淆，所以为了避免混淆这里使用了znode。

因为我们稍后还会使用，所以这里我们让客户端保持连接状态。开启一个新窗口，并创建一个zookeeperdemo1php文件。

<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('127001:2181');$zoo->get( '/test', array($zoo, 'watcher' ) );

while( true ) {

echo '';

sleep(2);}

现在运行该脚本。

$ php zookeeperdemo1php

此处应该会每隔2秒产生一个点。现在切换到ZooKeeper客户端，并更新“/test”值。

[zk: 127001: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文件，命名为workerphp。

<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( '127001:2181' );$worker->run();

打开至少3个终端，在每个终端中运行以下脚本：

# term1

$ php workerphp

I'm registred as: w-0000000001Nobody here, I'm the leader

Leading

# term2

$ php workerphp

I'm registred as: w-0000000002I'm watching w-0000000001

Working

# term3

$ php workerphp

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。由于文档和示例都做的很好，任何人都可以很容易的编写分布式软件。让我们开始吧，这会很有趣的。

用友系统无法连接SQL数据库的原因很多，建议以正确的方法安装。安装顺序也很重要。

1、安装IIS

2、安装SQL server 2000个人版

3、安装XP SP3补丁

4、安装SQL SP4补丁

5、安装用友通

当然这当中有些细节是需要注意的

搞不定可以Q我44268526