zookeeper集群搭建完成后查看状态zkServer.sh status 报错 - Hadoop - ITeye群组
以下是我用zkServer.sh status 后报的错，我从网上手了 都说zkServer.sh 里的nc问题但是我的就没有
JMX enabled by defaultUsing config: /usr/local/zk/bin/../conf/zoo.cfgError contacting service. It is probably not running.
下面是我zkServer.sh里的部分：
# -q is necessary on some versions of linux where nc returns too quickly, and no stat result is output
STAT=`$JAVA "-Dzookeeper.log.dir=${ZOO_LOG_DIR}" "-Dzookeeper.root.logger=${ZOO_LOG4J_PROP}" \
-cp "$CLASSPATH" $JVMFLAGS org.apache.zookeeper.client.FourLetterWordMain localhost \
$(grep "^[[:space:]]*clientPort" "$ZOOCFG" | sed -e 's/.*=//') srvr 2& /dev/null
| grep Mode`
if [ "x$STAT" = "x" ]
echo "Error contacting service. It is probably not running."
echo $STAT
fi;刚开始学zookeeper该怎么解决啊
CSS基础教程17篇
此教程共17篇，由浅到深、循序渐进的讲述CSS知识。
对初学者有很大的学习价值，对已入门的朋友也有重要的参考价值。
1、CSS的应用
2、CSS Selectors,Properties,and Values 选择器 、属性、值
3、CSS的color颜色
4、CSS的Text 文本
5、Margin和Padding
补充：CSS盒模型（Box Model）问题详解
6、CSS的Border边框
7、CSS属性结合起来使用
8、CSS的Class以及ID选择器
9、CSS的Grouping and Nesting分组和嵌套
10、CSS的Pseudo Classes 伪类
11、CSS的属性缩写
12、CSS的Background Images 背景图片
13、CSS的display属性
14、CSS网页布局Page Layout
15、CSS的At-Rules@规则
16、CSS的伪元素Pseudo Elements
17、CSS的优先级特性Specificity&
这是你的zkserver& 没有启动.启动先执行:zkServer.sh start通过:zkServer.sh status 可以查看zk集群状态.正常情况下一个zk集群中会有一个lader,其它的都为flolwer.通过:zkServer.sh stop 停止集群
呵呵，我这几天也在学习这个，也是遇到你这样的问题，不过还是没有解决，你可以看下Bin文件目录下的zookeeper.out里面的日志！ 我现在一直在报failed to register with JMX& ,我怀疑是JDK的问题 ！不过现在还没有换，还不知后面是怎么情况！
我现的的环境是： jdk1.5& zookeeper:3.4.5
到时咱们可以一起交流下
hi,我的zookeeper已经安装成功，主要问题是JDK版本问题！1.5老是报jmx错误，换成1.6 启动成功
hadoop要求jdk版本是1.6及以上的吧zookeeper（12）
1 客户端API简单使用
1.1 demo案例
一个最简单的demo如下：
package com.king.
import java.io.IOE
import java.util.concurrent.CountDownL
import org.apache.zookeeper.WatchedE
import org.apache.zookeeper.W
import org.apache.zookeeper.ZooK
public class ZookeeperConstructorSimple implements Watcher {
private static CountDownLatch connectedSemaphone=new CountDownLatch(1);
public static void main(String[] args) throws IOException {
ZooKeeper zooKeeper=new ZooKeeper(&127.0.0.1:2181&,5000,new ZookeeperConstructorSimple());
System.out.println(zooKeeper.getState());
connectedSemaphone.await();
} catch (Exception e) {}
System.out.println(&ZooKeeper session established&);
System.out.println(&sessionId=&+zooKeeper.getSessionId());
System.out.println(&password=&+zooKeeper.getSessionPasswd());
public void process(WatchedEvent event) {
System.out.println(&my ZookeeperConstructorSimple watcher Receive watched event:&+event);
if(Event.KeeperState.SyncConnected==event.getState()){
connectedSemaphone.countDown();
使用的maven依赖如下：
org.apache.zookeeper
对于目前来说，ZooKeeper的服务器端代码和客户端代码还是混在一起的，估计日后能改吧。
使用的ZooKeeper的构造函数有三个参数构成：
Zookeeper集群的服务器地址列表
该地址是可以填写多个的，以逗号分隔。如&127.0.0.1:.0.1:.0.1:2183&,那客户端连接的时候到底是使用哪一个呢？先随机打乱，然后轮询着用，后面再详细介绍。
sessionTimeout
最终会引出三个时间设置：和服务器端协商后的sessionTimeout、readTimeout、connectTimeout。
服务器端使用协商后的sessionTimeout：即超过该时间后，客户端没有向服务器端发送任何请求（正常情况下客户端会每隔一段时间发送心跳请求，此时服务器端会从新计算客户端的超时时间点的），则服务器端认为session超时，清理数据。此时客户端的ZooKeeper对象就不再起作用了，需要再重新new一个新的对象了。
客户端使用connectTimeout、readTimeout分别用于检测连接超时和读取超时，一旦超时，则该客户端认为该服务器不稳定，就会从新连接下一个服务器地址。
作为ZooKeeper对象一个默认的Watcher，用于接收一些事件通知。如和服务器连接成功的通知、断开连接的通知、Session过期的通知等。同时我们可以看到，一旦和ZooKeeper服务器连接建立成功，就会获取服务器端分配的sessionId和password，如下：
sessionId=84594
password=[B@4de3aaf6
2 客户端建立连接的过程
2.1 大体连接过程概述
首先与ZooKeeper服务器建立连接，有两层连接要建立：
客户端与服务器端的TCP连接；在TCP连接的基础上建立session关联；
建立TCP连接之后，客户端发送ConnectRequest请求，申请建立session关联，此时服务器端会为该客户端分配sessionId和密码，同时开启对该session是否超时的检测。
当在sessionTimeout时间内，即还未超时，此时TCP连接断开：服务器端仍然认为该sessionId处于存活状态。此时，客户端会选择下一个ZooKeeper服务器地址进行TCP连接建立，TCP连接建立完成后，拿着之前的sessionId和密码发送ConnectRequest请求，如果还未到该sessionId的超时时间，则表示自动重连成功，对客户端用户是透明的，一切都在背后默默执行，ZooKeeper对象是有效的。
如果重新建立TCP连接后，已经达到该sessionId的超时时间了（服务器端就会清理与该sessionId相关的数据）：则返回给客户端的sessionTimeout时间为0，sessionid为0，密码为空字节数组。客户端接收到该数据后，会判断协商后的sessionTimeout时间是否小于等于0，如果小于等于0，则使用eventThread线程先发出一个KeeperState.Expired事件，通知相应的Watcher，然后结束EventThread线程的循环，开始走向结束。此时ZooKeeper对象就是无效的了，必须要重新new一个新的ZooKeeper对象，分配新的sessionId了。
2.2 ZooKeeper对象
它是面向用户的，提供一些操作API。它又两个重要的属性：
ClientCnxn cnxn：负责所有的ZooKeeper节点操作的执行ZKWatchManager watchManager：负责维护某个path上注册的Watcher
如创建某个node操作（同步方式）：
ZooKeeper对象负责创建出Request，并交给ClientCnxn来执行，ZooKeeper对象再对返回结果进行处理。
下面来看下异步回调的方式创建node：
同步方式提交一个请求后：开始循环判断该请求包的状态是否结束，即处于阻塞状态，一旦结束则继续往下走下去，返回结果。
异步方式则提交一个请求后：直接返回，对结果的处理逻辑包含在回调函数中。一旦对该请求包响应完毕，则取出回调函数执行相应的回调方法。
至此简单了解了，ZooKeeper对象主要封装用户的请求以及处理响应等操作。用户请求的执行全部交给ClientCnxn来执行，那我们就详细看下ClientCnxn的来源及大体内容。
先看看ClientCnxn是怎么来的：
第一步：为ZKWatchManager watchManager设置一个默认的Watcher；
第二步：将连接字符串信息交给ConnectStringParser进行解析，连接字符串比如： &192.168.12.1:.12.2:.12.3:2181/root&。解析结果如下：
得到两个数据String chrootPath默认的跟路径和ArrayList&InetSocketAddress& serverAddresses即多个host和port信息。
第三步：根据上述解析的host和port列表结果，创建一个HostProvider，有了ConnectStringParser的解析结果，为什么还需要一个HostProvider再来包装下呢？主要是为将来留下扩展的余地，来看下HostProvider的详细接口介绍：
HostProvider主要负责不断的对外提供可用的ZooKeeper服务器地址，这些服务器地址可以是从一个url中加载得来或者其他途径得来。同时对于不同的ZooKeeper客户端，给出就近的ZooKeeper服务器地址等。
来看下默认的HostProvider实现StaticHostProvider：
有三个属性，一个就是服务器地址列表（经过如下方式随机打乱了）：
Collections.shuffle(this.serverAddresses)
另外两个属性用于标记，下面来具体看下，StaticHostProvider是如何实现不断的对外提供ZooKeeper服务器地址的：
代码也很简单，就是在打乱的服务器地址列表中，不断地遍历，到头之后，在从0开始。
上面的spinDelay是个什么情况呢？
正常情况下，currentIndex先加1，然后返回currentIndex+1的地址，当该地址连接成功后会执行onConnected方法，即lastIndex = currentIndex了。然而当返回的currentIndex+1的地址连接不成功，继续尝试下一个，仍不成功，仍继续下一个，就会遇到currentIndex=lastIndex的情况，此时即轮询了一遍，仍然没有一个地址能够连接上，此时的策略就是先暂停休息休息，然后再继续。
第四步：为创建ClientCnxn准备参数并创建ClientCnxn。
首先是通过getClientCnxnSocket()获取一个ClientCnxnSocket。来看下ClientCnxnSocket是主要做什么工作的，专门用于负责socket通信的，把一些公共部分抽象出来，其他的留给不同的实现者来实现。如可以选择默认的ClientCnxnSocketNIO，也可以使用netty等。
来看下getClientCnxnSocket()的获取ClientCnxnSocket的过程：
首先获取系统参数&zookeeper.clientCnxnSocket&,如果没有的话，使用默认的ClientCnxnSocketNIO，所以我们可以通过指定该参数来替换默认的实现。
参数准备好了，ClientCnxn是如何来创建的呢？
首先就是保存一些对象参数，此时的sessionId和sessionPasswd都还没有。然后就是两个timeout参数：connectTimeout和readTimeout。在ClientCnxn的发送和接收数据的线程中，会不断的检测连接超时和读取超时，一旦出现超时，就认为服务不稳定，需要更换服务器，就会从HostProvider中获取下一个服务器地址进行连接。
最后就是两个线程，一个事件线程即EventThread，一个发送和接收socket数据的线程即SendThread。
事件线程EventThread呢就是从一个事件队列中不断取出事件并进行处理：
看下具体的处理过程，主要分成两种情况，一种就是我们注册的watch事件，另一种就是处理异步回调函数：
可以看到这里就是触发我们注册Watch的，还有触发上文提到的异步回调的情况的。明白了EventThread是如何来处理事件的，需要知道这些事件是如何来的：
对外提供了三个方法来添加不同类型的事件，如SendThread线程就会调用这三个方法来添加事件。其中对于事件通知，会首先根据ZKWatchManager watchManager来获取关心该事件的所有Watcher，然后触发他们。
再来看看SendThread的工作内容：
sendThread = new SendThread(clientCnxnSocket);
在SendThread的run方法中，有一个while循环，不断的做着以下几件事：
任务1：不断检测clientCnxnSocket是否和服务器处于连接状态，如果是未连接状态，则从hostProvider中取出一个服务器地址，使用clientCnxnSocket进行连接。
和服务器建立连接成功后，开始发送ConnectRequest请求，把该请求放到outgoingQueue请求队列中，等待被发送给服务器。
任务2：检测是否超时：当处于连接状态时，检测是否读超时，当处于未连接状态时，检测是否连接超时。
一旦超时，则抛出SessionTimeoutException，然后看下是如何处理呢？
可以看到一旦发生超时异常或者其他异常，都会进行清理，并设置连接状态为未连接，然后发送Disconnected事件，至此又会进入任务1的流程。
任务3：不断的发送ping通知，服务器端每接收到ping请求，就会从当前时间重新计算session过期时间，所以当客户端按照一定时间间隔不断的发送ping请求，就能保证客户端的session不会过期。发送时间间隔如下：
clientCnxnSocket.getIdleSend()：是最后一次发送数据包的时间与当前时间的间隔。当readTimeout的时间已经过去一半多了，都没有发送数据包的话，则执行一次Ping发送。或者过去MAX_SEND_PING_INTERVAL（10s）都还没有发送数据包的话，则执行一次Ping发送。
ping发送的内容只有请求头OpCode.ping的标示，其他都为空。发送ping请求，也是把该请求放到outgoingQueue发送队列中，等待被执行。
任务4：执行IO操作，即发送请求队列中的请求和读取服务器端的响应数据。
首先从outgoingQueue请求队列中取出第一个请求，然后进行序列化，然后使用socket进行发送。
读取服务器端数据如下：
分为两种：一种是读取针对ConnectRequest请求的响应，另一种就是其他响应，先暂时不说。
先来看看针对ConnectRequest请求的响应：
首先进行反序列化，得到ConnectResponse对象，我们就可以获取到服务器端给我们客户端分配的sessionId和passwd，以及协商后的sessionTimeOut时间。
首选要根据协商后的sessionTimeout时间，重新计算readTimeout和connectTimeout值。然后保留和记录sessionId和passwd。最后通过EventThread发送一个SyncConnected连接成功事件。至此，TCP连接和session初始化请求都完成了，客户端的ZooKeeper对象可以正常使用了。
至此，我们便了解客户端与服务器端建立连接的过程。
3 服务器端处理连接的过程
服务器端情况分很多种，先暂时说最简单的单机版。同时也不再给出服务器端的启动过程（后面的文章再来详细说明）。
首先介绍下服务器端的大体概况：
首先是服务器端的配置文件，有tickTime、minSessionTimeout、maxSessionTimeout相关属性。默认情况下，tickTime是3000ms，minSessionTimeout是2倍的tickTime，maxSessionTimeout是20倍的tickTime。
服务器端默认采用NIOServerCnxnFactory来负责socket的处理。每来一个客户端socket请求，为该客户端创建一个NIOServerCnxn。之后与该客户端的交互，就交给了NIOServerCnxn来处理。对于客户端的ConnectRequest请求，处理如下：
1. 首先反序列化出ConnectRequest
2. 然后开始协商sessionTimeout时间
即判断用户传递过来的sessionTimeout时间是否在minSessionTimeout、maxSessionTimeout之间。协商完成之后，根据用户传递过来的sessionId是否是0进行不同的处理。客户端第一次请求，sessionId为0。当客户端已经连接过一个服务器地址，分配了sessionId，然后如果发生超时等异常，客户端会去拿着已经分配的sessionId去连接下一个服务器地址，此时的sessionId不为0。
sessionId为0，则代表着要创建session。sessionId不为0，则需要对该sessionId进行合法性检查，以及是否已经过期了的检查。
我们先来看看sessionId为0的情况：
大体上分三大步：
使用sessionTracker根据sessionTimeout时间创建一个新的session；根据sessionId创建出密码；提交这个创建session的请求到请求处理器链，最终将sessionId和密码返回给客户端；
下面来分别详细的说明这三个过程：
3.1 使用sessionTracker创建session
SessionTracker是用来创建删除session，执行session的过期检查的。
直接看下默认使用的SessionTrackerImpl：
先看下session有哪些属性：
final long sessionId：session的唯一标示
final int timeout：这个session的timeout时间（即上文中客户端和服务器端商定下来的timeout时间）
long tickTime：这个session的下一次超时时间点（随着客户端不断的发送PING请求，就会不断的刷新该时间，不断的往后变化）
boolean isClosing：session的标示符，用于标示session是否还被正常使用
Object owner：创建该session的owner。会在客户端更换所连接的服务器的时候用到（之后详细说明）
然后再来看看SessionTracker的几个数据：
HashMap&Long, SessionImpl& sessionsById：很简单，以sessionId存储session
ConcurrentHashMap&Long, Integer& sessionsWithTimeout：以sessionId存储每个session的timeout时间
HashMap&Long, SessionSet& sessionSets：某个时间点上的session集合（用于session过期检查）
long nextSessionId：初始的sessionId，之后创建的sessionId就在此基础上自增
nextExpirationTime：下一次过期时间点，每当到该时间点就会进行一次session的过期检查
expirationInterval：session过期检查的周期
要搞清楚的内容有：（1） 创建session的过程；（2） session过期检查的过程；
先来看看创建session的过程：
代码很简单，就是创建一个SessionImpl对象，然后存储到SessionTracker中，同时开始计算session的超时时间。这里有一个内容就是sessionId的来历，我们可以看到就是根据nextSessionId来的，并且是不断自增的。
sessionId是一个客户端的重要标示，是全局唯一的，先来看看单机版的nextSessionId初始化：
单机版的服务器使用1通过计算来初始化nextSessionId。而集群版对应的id则分别是每个机器指定的sid。计算过程如下：
第一步：就是取当前时间，为 00011 为41为二进制。
第二步：long有64位，左移24位，其实是除掉了前面的1，后面补了24位的0。
第三步：第二步的结果可能是正数也可能是负数，目前是正数，之后可能就是负数了，你可以算一下需要多少年，哈哈。为了保证右移的时候，进行补0 操作，需要使用无符号右移，即&&&。这里使用了无符号右移8位。
第四步：将传过来的id这里即1左移56位。然后再与第三步的正数结果进行或操作，得到最终的基准nextSessionId，所以当这里的id值不是很大的话，一般几台机器而已，也保证了sessionId是一个正数，同时前八位就是机器的sid号。所以每台机器的的前八位是不同的，保证了每台机器中不会配置相同的sessionId，每台机器的sessionId又是自增操作，所以单台机器内sessionId也是不会重复的。
综上所示保证了sessionId是唯一的，不会出现重复分配的情况。搞清楚了sessionId的分配，接下来就要弄清楚如何进行session的过期检查问题：
我们先看下，session激活过程是怎么处理的：
首先获取这个session数据，然后计算它的超期时间。
long expireTime = roundToInterval(System.currentTimeMillis() + timeout);
private long roundToInterval(long time) {
return (time / expirationInterval + 1) * expirationI
即是拿当前时间加上这个session的timeout时间，然后对其进行取expirationInterval的整，即始终保持是expirationInterval的正数倍，即每个session的过期时间点最终都会落在expirationInterval的整数倍上。
如果原本该session的超期时间就大于你所计算出的超期时间，则不做任何处理，否则设置该session的超期时间为上述计算结果的超期时间。
取出原本该session所在的超期时间，从集合里面删除。
重新获取现在超期时间所在的集合，添加进去。
综上所述，session的激活其实就是重新计算下超时时间，最终取expirationInterval的正数倍，然后从之前时间点的集合中移除，然后再添加到新的时间点的集合中去。
至此，session的检查就方便多了，只需要在expirationInterval整数时间点上取出集合，然后一个个标记为过期即可。而那些不断被激活的session，则不断的从一个时间点的集合中换到下一个时间点的集合中。
SessionTrackerImpl也是一个线程，该线程执行内容就是session的过期检查,如下所示：
3.2 根据sessionId创建出密码
回到创建session的三大步骤：
来看下密码是如何来产生的：
Random r = new Random(sessionId ^ superSecret);
r.nextBytes(passwd);
其中superSecret为常量：
static final private long superSecret = 0XB3415C00L;
使用Random的方式来随机生成字节数组。但是该字节数组，只要参数即sessionId相同，字节数组的内容就相同。即当我们知道了sessionId，就可以利用上述方式算出对应的密码，我感觉密码基本上没什么用。
再看下当客户端带着sessionId和密码进行连接的时候，这时会进行密码的检查：
看了上面的代码，就再次验证了密码没什么鸟用，知道了sessionId，就完全知道了密码。所以这一块有待改进吧，应该不能由sessionId完全决定吧，如再加上当前时间等等，让客户端造不出来密码，同时服务器端存储加密后的密码。
3.3 提交这个创建session的请求到请求处理器链
本文内容已太多，这里就先简单描述下，之后再详细的讲解：
如果是成功创建session，则把sessionTimeout、sessionId、passwd传递给客户端。如果没有成功创建，上述三者的值分别是0,0,new byte[16]。之后客户端处理该响应的过程，上面已经说了，可以回头再看下。
参考知识库
* 以上用户言论只代表其个人观点，不代表CSDN网站的观点或立场
访问：46561次
排名：千里之外
转载：284篇
(1)(12)(1)(3)(3)(12)(7)(68)(168)(21)zookeeper+dubbo+dubbo管理集群的简要配置[单机] -
- ITeye技术网站
注：zookeeper集群是myid文件是没有后缀名的。
转自：
/demo_c353_i4119.html
/demo_c196_i554.html
导读：考虑到单机部署运行，在此文档中RegisterGroup 是单例的Zookeeper，部署集群模式的registerGroup请参考Zookeeper集群/view/649b.html
dubbo是阿里的一个开源soa框架，详细介绍/wiki/display/dubbo/Home-zh
zookeeper是Hadoop的子项目，主要功能基于paxos算法对分布式系统的请求进行调度，详细介绍/developerworks/cn/opensource/os-cn-zookeeper/
考虑到单机部署运行，在此文档中RegisterGroup 是单例的Zookeeper，部署集群模式的registerGroup请参考Zookeeper集群 /view/649b.html
代码下载[不含 app的lib]http://download.csdn.net/detail/goliathray/5048969
需要的工具 eclipse tomcat
ProviderGroup：可以存在多个ProviderGroup，每个Group由多台Node组成，每个Node需要保证以下配置
1.&&&&& 采用相同的application name
2.&&&&& 保证provider的连接地址互不相同（在单机上部署多个provider需要保证端口不同）
3.&&&&& 注册中心地址一致
ConsumerGroup：可以存在多个ConsumerGroup，每个Group由多台Node组成，每个Node需要保证能网络连接到所需业务的Provider并保证以下配置
1.&&&&& 采用相同的application name
2.&&&&& 注册中心地址一致
ProviderNode可以作为ConsumerNode调用别的ProviderGroup组的业务，相对的ConsumerNode也可以作为ProviderNode
RegisterGroup：注册中心组作为服务调用的分配者，每个RegisterNode监听除自身以外所有节点是否存活和健康（包括其RegisterGroup），本文档以Zookeeper单例部署为例子说明。
DubboAdmin：管理节点，可选节点，只作为一个管理者和观察者。
部署说明：
1.&&&&& 在Eclipse中引入DubboConsumerNode1 - 3 和DubboProviderNode1 -3 共6个项目
2.&&&&& 将DubboAdmin中的文件复制到apache-tomcat\webapps\ROOT下
3.&&&&& Zookeeper已经做了基础配置，只需在 \zookeeper-3.4.4\bin启动 zkServer.cmd
Zoo.cfg配置说明
#tickTime：这个时间是作为 Zookeeper 服务器之间或客户端与服务器之间维持心跳的时间间隔，也就是每个 tickTime 毫秒时间就会发送一个心跳。
tickTime=2000
#dataDir：Zookeeper 保存数据的目录，默认情况下，Zookeeper 将写数据的日志文件也保存在这个目录里。
dataDir=/tmp/zookeeper
#dataLogDir:日志文件保存的位置（未配置）
dataLogDir=/tmp/zookeeper/log
#clientPort：这个端口就是客户端连接Zookeeper 服务器的端口，Zookeeper 会监听这个端口，接受客户端的访问请求。
clientPort=2181
#initLimit：这个配置项是用来配置 Zookeeper接受客户端（这里所说的客户端不是用户连接 Zookeeper 服务器的客户端，而是 Zookeeper 服务器集群中连接到 Leader 的 Follower 服务器）初始化连接时最长能忍受多少个心跳时间间隔数。
#当已经超过 10 个心跳的时间（也就是tickTime）长度后 Zookeeper 服务器还没有收到客户端的返回信息，那么表明这个客户端连接失败。总的时间长度就是 10*2000=20 秒。
initLimit=10
启动顺序：
这个部署并不严格要求启动的前后顺序，建议启动顺序
1.&&&&& 启动Zookeeper ，显示
2.&&&&& 启动Tomcat，若先启动Tomcat则会一直监听Zookeeper服务是否启动，当Zookeeper启动后才会加载完成，启动完成后访问127.0.0.1:8080，以root/root 登陆，显示
3.&&&&& 启动Provider，在eclipse中找到Provider1-3.java,直接运行main方法，每启动一个节点，显示
同时在提供者列表中会增加一个节点信息
3个Provider全启动后
4.&&&&& 启动Consumer, 在eclipse中找到Consumer1-3.java,直接运行main方法，每启动一个节点，可以见到console有输出
在Provider的Console中有显示
同时在消费者列表有新增节点信息
3个Consumer全启动后
节点的异常：
ProviderNode异常：当某台ProviderNode宕机后，Register无法再获取此Provider的信息，但是在进行initLimit个心跳连接之前，Register会认为这个Node只是暂时出错，并不会把他剔除出Provider的列表，Consumer的调用会报错（在未配置容错的情况下），某台Consumer可能会显示
但是在经过initLimit次的心跳后，此节点会被剔除出Provider列表，访问恢复
ConsumerNode异常：除非存在P-C-P的循环，不会对此部署产生影响，在经过initLimit次的心跳后，在Consumer列表中被剔除
RegisterNode异常：参考Zookeeper集群异常
异常恢复：对于每个ProviderNode和ConsumerNode，只需要重启动后连接上Register，既可以恢复原有的服务状态。
DubboAdmin管理：
DubboAdmin本身的配置采用的是文件的方式保存配置信息，配置的结果信息会由各个节点保存到临时文件，以保证在重启服务后恢复到原有状态
权重负载均衡：默认采用的是随机权重的负载均衡，对于第一次加载的Provider服务，权重为100，服务的访问率为（节点服务权重/服务重权重）*100%，可以通过增减权重的方式改变节点的访问几率，在对1号节点增加4倍权重后，1号节点的访问概率变为66.7%，可以在3个Provider节点的Console中看到信息的增幅速度明显改变，1号节点的速度远大于其他2个节点。
自定义的负载均衡：可以新增负载均衡的规则，优先于默认的负载均衡，有随机，伦循，按最小并发3种规则，可以细化到方法。
消费者的容错：在Provider端出现异常时，可以默认返回一个容错值，默认为Null，可以自己配置，通过对Provider的Service设置mock类
启动容错后若Provider端出错，返回Null，优先于禁用
可以看到Consumer的Console报错
消费者的禁用：对于ConsumerNode，禁用后则不能访问任何Provider
若设置了容错，则返回NULL
若无容错，则返回调用异常
恢复后显示数据可以正常访问
提供者的禁用：禁止此Provider提供服务，（对下次启动生效），在重启动这个服务后显示
服务无法被访问，在点击启用后服务恢复
上一篇 Blueprint入门之四 下一篇 使用UFT进行接口测试(Web Service、REST)
总结：权重负载均衡：默认采用的是随机权重的负载均衡，对于第一次加载的Provider服务，权重为100，服务的访问率为（节点服务权重/服务重权重）*100%，可以通过增减权重的方式改变节点的访问几率，在对1号节点增加4倍权重后，1号节点的访问概率变为66.7%，可以在3个Provider节点的Console中看到信息的增幅速度明显改变，1号节点的速度远大于其他2个节点。
浏览 28199
ahua186186
浏览: 195068 次
来自: 深圳
请问图片还能找的会吗？你的图片和原文的图片都挂了，，，如果有图 ...
yngwiet 写道楼主，有一个地方不太明白，为什么要用“ge ...
楼主，有一个地方不太明白，为什么要用“getChildAt(p ...