zookeeper我已经设置分布式，为什么总显示是单机模式

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 >

zk通过Multi-Paxos思想实现分布式一致性，Multi-Paxos为了解决Paxos需要2轮RPC通讯(准备阶段和接受阶段)往返消息多、耗性能、延迟大的问题引入了Leader-Follower-Learner模式；考虑到高可用性，有Leader就会涉及选举Leader的问题，本节就来分析下zk是如何实现选主的；

以三个节点同时启动为例：

以3个节点中Server1作为Follower重启为例：

以4个节点中Server4作为Leader宕机为例：

Leader ：一个zk集群同一时刻只有一个Leader，所有写 *** 作必须通过Leader完成，然后再广播给其他服务器；
Follower ：一个zk集群同一时刻有多个Follower。Follower可以直接处理读请求，但是写请求需要转发给Leader处理，同时负责在Leader处理写请求时对请求进行投票；
Observer ：功能跟Follower类似，但是没有投票权；

Looking ：寻找Leader状态，处于该状态的服务器会发起选主；
Following ：跟随者状态，表明当前服务器是Follower；
Leading ：领导者状态，表明当前服务器是Leader;
Observing ：观察者状态，表明当前服务器是Observer;

Listenerrun 监听2888端口，阻塞在ServerSocketaccept，等待其他服务器请求创建连接；
RecvWorkerrun 阻塞在DataInputStreamread，获取对应服务器发送的投票信息；
SendWorkerrun 阻塞在ArrayBlockingQueuepoll，获取待发送消息，发送给对应服务器；
WorkerReceiverrun 阻塞在recvqueuepoll，获取RecvWorkerrun中接收的投票消息Notification；
WorkerSenderrun 阻塞在sendqueuepoll，获取待发送ToSend到SendWorkerrun进行处理；
QuorumPeerrun 集群模式启动过程中选举结束后，根据当前服务器状态进行之后的异步流程处理；

LinkedBlockingQueue<ToSend> sendqueue FastLeaderElection中的请求发送队列，存放的是ToSend；

LinkedBlockingQueue<Notification> recvqueue FastLeaderElection中的请求接受队列，存放的是Notification；

ConcurrentHashMap<Long, SendWorker> senderWorkerMap sid -> 当前服务器到该sid的SendWorker；每个服务器会跟比自己sid小的服务器创建一个SendWorker用于投票选主时发送投票信息；
ConcurrentHashMap<Long, ArrayBlockingQueue<ByteBuffer>> queueSendMap sid -> 当前服务器需要发送到该sid的投票消息的队列；WorkerSenderrun中会根据不同sid把对用的选票信息放入对应的ArrayBlockingQueue中；
ConcurrentHashMap<Long, ByteBuffer> lastMessageSent sid->最后一次发送到该sid的投票信息；
ArrayBlockingQueue<Message> recvQueue WorkerReceiverrun中接收到的投票信息，解析字节流转成Message放到recvQueue中；

zk选主涉及6个线程、多个集合，过程比较饶，必须要先把选主的流程和各个线程、集合的作用等搞清楚，不然理解起来比较难。下一节通过源码来具体分析选主的实现；
------ over ------

基本 *** 作
下面给出基本的 *** 作 ZooKeeper 的示例代码，这样你就能对 ZooKeeper 有直观的认识了。下面的清单包括了创建与 ZooKeeper 服务器的连接以及最基本的数据 *** 作：
ZooKeeper 基本的 *** 作示例
// 创建一个与服务器的连接
ZooKeeper zk = new ZooKeeper("localhost:" + CLIENT_PORT,
ClientBaseCONNECTION_TIMEOUT, new Watcher() {
// 监控所有被触发的事件
public void process(WatchedEvent event) {
Systemoutprintln("已经触发了" + eventgetType() + "事件！");
}
});
// 创建一个目录节点
zkcreate("/testRootPath", "testRootData"getBytes(), IdsOPEN_ACL_UNSAFE,
CreateModePERSISTENT);
// 创建一个子目录节点
zkcreate("/testRootPath/testChildPathOne", "testChildDataOne"getBytes(),
IdsOPEN_ACL_UNSAFE,CreateModePERSISTENT);
Systemoutprintln(new String(zkgetData("/testRootPath",false,null)));
// 取出子目录节点列表
Systemoutprintln(zkgetChildren("/testRootPath",true));
// 修改子目录节点数据
zksetData("/testRootPath/testChildPathOne","modifyChildDataOne"getBytes(),-1);
Systemoutprintln("目录节点状态：["+zkexists("/testRootPath",true)+"]");
// 创建另外一个子目录节点
zkcreate("/testRootPath/testChildPathTwo", "testChildDataTwo"getBytes(),
IdsOPEN_ACL_UNSAFE,CreateModePERSISTENT);
Systemoutprintln(new String(zkgetData("/testRootPath/testChildPathTwo",true,null)));
// 删除子目录节点
zkdelete("/testRootPath/testChildPathTwo",-1);
zkdelete("/testRootPath/testChildPathOne",-1);
// 删除父目录节点
zkdelete("/testRootPath",-1);
// 关闭连接
zkclose();
输出的结果如下：
已经触发了 None 事件！
testRootData
[testChildPathOne]
目录节点状态：[5,5,,,0,1,0,0,12,1,6]
已经触发了 NodeChildrenChanged 事件！
testChildDataTwo
已经触发了 NodeDeleted 事件！
已经触发了 NodeDeleted 事件！
当对目录节点监控状态打开时，一旦目录节点的状态发生变化，Watcher 对象的 process 方法就会被调用。

zookeeper宕机后，因为消费者会缓存提供者的信息，所以应用不会有问题。但是，此时提供者和消费者都无法重连zookeeper，因为dubbo貌似配置的zkclient不会重连zookeeper，所以一旦重启一台服务提供者，那么这台就从服务消费者的缓存中消失了，此时服务消费者又连不上zookeeper，所以如果同时重启，消费者就没有提供者可用了，所以只能重启一台提供者后，再重启一个消费者，交错重启。

---