zookeeper理解转Word文件下载.docx
《zookeeper理解转Word文件下载.docx》由会员分享，可在线阅读，更多相关《zookeeper理解转Word文件下载.docx（14页珍藏版）》请在冰豆网上搜索。
server.3=devcluster06:
注明：
2555端口号是zookeeper服务之间通信的端口，而3555是zookeeper与其他应用程序通信的端口。
２、myid（在zoo.cfg配置的dataDir目录下，此处为/home/nutch/zookeeper-3.1.1/zookeeper-data）
注意：
Myid中的值与server的编号相同：
devcluster01上的myid：
1
devcluster05上的myid：
2
devcluster06上的myid：
3
zookeeper
到每台zookeeperserver的目录下,执行：
启动
./bin/zkServer.shstart
关闭./bin/zkServer.shstart
的使用
zookeeper启动之后，不需要执行命令，只需查看批准的状况，命令如下：
１、ruok-Theserverwillrespondwithimokifitisrunning.Otherwiseitwillnotrespondatall.
２、kill-Whenissuedfromthelocalmachine,theserverwillshutdown.
３、dump-Liststheoutstandingsessionsandephemeralnodes.Thisonlyworksontheleader.
４、stat-Listsstatisticsaboutperformanceandconnectedclients.
例如：
$echoruok|nc127.0.0.13355
Imok$
和zookeeper的关系
zookeeper是针对分布式应用的分布式协作服务，它的目的就是为了减轻分布式应用从头开发协作服务的负担。
它的基本功能是命名服务（naming），配置管理（configurationmanagement），同步（synchronization）和组服务（groupservices）。
在此基础上可以实现分布式系统的一致性，组管理，Leader选举等功能。
一个zookeeper机群包含多个zookeeper服务器，这些Server彼此都知道对方的存在。
Zookeeper系统结构图如图2所示：
图2
zookeeper系统结构图
l、所有的Server都保存有一份目前zookeeper系统状态的备份；
2、在zookeeper启动的时候，会自动选取一个Server作为Leader，其余的Server都是Follower；
3、作为Follower的Server服务于Client,接受Client的请求，并把Client的请求转交给Leader，由Leader提交请求。
4、Client只与单个的zookeeper服务器连接。
Client维护一个持久TCP连接，通过其发送请求,获取响应和事件,并发送心跳信息。
如果Client到Server的TCP连接中断,Client将会连接到另外一个Server。
5、zookeeper集群的可靠性是我们使用它的原因，只要不超过半数的服务器当机（如果正常服务的服务器数目不足一半，那么原有的机群将可能被划分成两个信息无法一致的zookeeper服务），该服务就能正常运行。
的虚拟文件系统
Zookeeper允许多个分布在不同服务器上的进程基于一个共享的、类似标准文件系统的树状虚拟文件系统来进行协作。
虚拟文件系统中的每个数据节点都称作一个znode。
每个znode都可以把数据关联到它本身或者它的子节点.如图3所示：
图3zookeeper的虚拟文件系统目录结构
1、每个znode的名称都是绝对路径名来组成的，如“/katta/index/index_name”等。
2、读取或写入znode中的数据都是原子操作，read会获取znode中的所有字节,write会整个替换znode中的信息.每个znode都包含一个访问控制列表（ACL）以约束该节点的访问者和权限.
3、有些znode是临时节点.临时节点在创建它的session的生命周期内存活,当其session终止时，此类节点将会被删除.
4、zookeeper提供znode监听器的概念.Client可以在某个znode上设置监听器以监听该znode的变更.当znode有变更时,这些Client将会收到通知,并执行预先敲定好的函数。
那么Zookeeper能为我们做什么事情呢?
简单的例子:
假设这样一个系统：
1）
20个搜索引擎的服务器（每个服务器负责一部分索引的搜索任务），每个搜索引擎的服务器有时提供搜索服务有时生成索引,但不能同时做这两件事；
2）一个总服务器（负责向这20个搜索引擎的服务器发出搜索请求并合并结果集）；
3）一个备用的总服务器（负责当总服务器宕机时替换总服务器）；
4）一个web的cgi（向总服务器发出搜索请求）。
使用Zookeeper可以保证：
1.总服务器自动感知有多少台服务器可以提供搜索服务，并向这些服务器发出搜索请求；
2.总服务器当机时自动启用备用的总服务器；
3.Web的cgi能够自动地获知总服务器的网络地址变化。
这些都可以通过zookeeper的虚拟文件系统来实现，把这些状态信息，配置，位置等信息都保存于znode中，znode是被所有服务器共享的，通过znode及其数据的变化来完成服务器之间的协作。
与zookeeper的关系
l、Katta使用zookeeper保证Master主节点和Node子节点的有效性，在Master主节点和Node子节点之间传递消息，保存一些配置信息，保证文件读取的一致性等。
2、Master管理服务器,Node检索服务器和Client服务器之间的通信就是通过zookeeper来实现的。
3、Client服务器可以直接从zookeeper服务中读取Node检索服务器列表，并向Node检索服务器发送检索请求，最后从Node检索服务器得到结果，不必经过Master管理服务器。
Zookeeper分布式安装手册
一、安装准备
1、下载zookeeper-3.3.1，地址：
http:
//www.apache.org/dist/hadoop/zookeeper/zookeeper-3.3.1/
2、JDK版本：
jdk-6u20-linux-i586.bin
3、操作系统：
Linux
4、默认前提是安装完hadoop0.20.2版本：
192.168.3.131namenode
192.168.3.132datanode
192.168.3.133datanode
二、操作步骤（默认在namenode上进行）
1、拷贝以上文件到Linux的“/usr/”目录下。
同时新建目录“/zookeeper-3.3.1”。
2、安装JDK，此步省略...
3、解压zookeeper到/zookeeper-3.3.1目录下。
tar-zxvfzookeeper-3.3.1.tar.gz-C/
zookeeper-3.3.1
4、将“/zookeeper-3.3.1/conf”目录下zoo_sample.cfg修改名称为“zoo.cfg”
5、打开zoo.cfg文件，修改配置如下：
dataDir=/usr/zookeeper-3.3.1/data
dataLogDir=/usr/zookeeper-3.3.1/log
clientPort=2181
initLimit=10
syncLimit=5
tickTime=2000
server.1=192.168.3.131:
2888:
3888
server.2=192.168.3.132:
server.3=192.168.3.133:
3888
6、创建dataDir参数指定的目录（这里指的是“/zookeeper-3.3.1/data”），并在目录下创建文件，命名为“myid”。
7、编辑“myid”文件，并在对应的IP的机器上输入对应的编号。
如在192.168.3.131上，“myid”文件内容就是1，
在192.168.3.132上，内容就是2
8、在profile.d下面生成zookeeper.sh文件设置如下：
#zookeeperpath
ZOOKEEPER=/usr/zookeeper-3.3.2
PATH=$PATH:
$ZOOKEEPER/bin
exportPATH
然后应用
../zookeeper.sh
9、将“/usr/zookeeper-3.3.1”目录分别拷贝到192.168.3.132和192.168.3.133下。
同时修改对应的“myid”文件内容。
10、至此，安装步骤结束，接下来启动zookeeper。
三、启动zookeeper
1、在三台机器上分别执行shell脚本。
“sh/jz/zookeeper-3.3.1/bin/zkServer.shstart”
2.启动客户端脚本：
“zkCli.sh-server192.168.1.132:
2181”
3、执行完成之后输入“jps”命令，查看进程如下：
namenode上显示如下：
29844JobTracker
29583NameNode
31477HMaster
29762SecondaryNameNode
32356Jps
31376HQuorumPeer
datanode：
16812DataNode
17032HRegionServer
17752HQuorumPeer
16921TaskTracker
18461Jps
3、通过输入“sh/jz/zookeeper-3.3.1/bin/zkServer.shstatus”检查是否启动，一般返回内容如下：
leader：
JMXenabledbydefault
Usingconfig:
/jz/zookeeper-3.3.1/bin/../conf/zoo.cfg
Mode:
leader
follower：
follower
4、通过在控制台输入命令检查集群zookeeper启动状态。
命令如“echoruok|nc192.168.3.1312181”，
控制台输出“imok”
四、注意事项
通过shell脚本在每个机器上启动zookeeper的时候，可能会显示错误信息“CannotopenchanneltoXatelectionaddress”。
这是由于zoo.cfg文件中指定的其他zookeeper服务找不到所导致。
所有机器的zookeeper服务启动之后该错误提示将会消失。
Zookeeper入门
ZooKeeper是什么？
ZooKeeper顾名思义动物园管理员，他是拿来管大象（Hadoop）
、
蜜蜂（Hive）
小猪（Pig）
的管理员，ApacheHbase和ApacheSolr以及LinkedInsensei
等项目中都采用到了Zookeeper。
ZooKeeper是一个分布式的，开放源码的分布式应用程序协调服务，ZooKeeper是以FastPaxos算法为基础，实现同步服务，配置维护和命名服务等分布式应用。
ZooKeeper如何工作？
ZooKeeper是作为分布式应用建立更高层次的同步（synchronization）、配置管理（configurationmaintenance）、群组（groups）以及名称服务（naming）。
在编程上，ZooKeeper设计很简单，所使用的数据模型风格很像文件系统的目录树结构，简单来说，有点类似windows中注册表的结构，有名称，有树节点，有Key（键）/Value（值）对的关系，可以看做一个树形结构的数据库，分布在不同的机器上做名称管理。
Zookeeper分为2个部分：
服务器端和客户端，客户端只连接到整个ZooKeeper服务的某个服务器上。
客户端使用并维护一个TCP连接，通过这个连接发送请求、接受响应、获取观察的事件以及发送心跳。
如果这个TCP连接中断，客户端将尝试连接到另外的ZooKeeper服务器。
客户端第一次连接到ZooKeeper服务时，接受这个连接的ZooKeeper服务器会为这个客户端建立一个会话。
当这个客户端连接到另外的服务器时，这个会话会被新的服务器重新建立。
启动Zookeeper服务器集群环境后，多个Zookeeper服务器在工作前会选举出一个Leader，在接下来的工作中这个被选举出来的Leader死了，而剩下的Zookeeper服务器会知道这个Leader死掉了，在活着的Zookeeper集群中会继续选出一个Leader，选举出leader的目的是为了可以在分布式的环境中保证数据的一致性。
如图所示：
另外，ZooKeeper支持watch（观察）的概念。
客户端可以在每个znode结点上设置一个观察。
如果被观察服务端的znode结点有变更，那么watch就会被触发，这个watch所属的客户端将接收到一个通知包被告知结点已经发生变化。
若客户端和所连接的ZooKeeper服务器断开连接时，其他客户端也会收到一个通知，也就说一个Zookeeper服务器端可以对于多个客户端，当然也可以多个Zookeeper服务器端可以对于多个客户端，如图所示：
你还可以通过命令查看出，当前那个Zookeeper服务端的节点是Leader，哪个是Follower，如图所示：
我通过试验观察到Zookeeper的集群环境最好有3台以上的节点，如果只有2台，那么2台当中不管那台机器down掉，将只会剩下一个leader，那么如果有再有客户端连接上来，将无法工作，并且剩下的leader服务器会不断的抛出异常。
内容如下：
.ConnectException:
Connectionrefused
atsun.nio.ch.Net.connect（NativeMethod）
atsun.nio.ch.SocketChannelImpl.connect（SocketChannelImpl.java:
507）
atjava.nio.channels.SocketChannel.open（SocketChannel.java:
146）
atorg.apache.zookeeper.server.quorum.QuorumCnxManager.connectOne（QuorumCnxManager.java:
347）
atorg.apache.zookeeper.server.quorum.QuorumCnxManager.connectAll（QuorumCnxManager.java:
381）
atorg.apache.zookeeper.server.quorum.FastLeaderElection.lookForLeader（FastLeaderElection.java:
674）
atorg.apache.zookeeper.server.quorum.QuorumPeer.run（QuorumPeer.java:
611）
2010-11-1500:
31:
52,031–INFO[QuorumPeer:
/0:
0:
2181:
FastLeaderElection@683]–Notificationtimeout:
12800
并且客户端连接时还会抛出这样的异常，说明连接被拒绝，并且等待一个socket连接新的连接，这里socket新的连接指的是zookeeper中的一个Follower。
org.apache.zookeeper.ClientCnxn$SendThread.startConnect（ClientCnxn.java:
1000）Openingsocketconnectiontoserver192.168.50.211/192.168.50.211:
2181
org.apache.zookeeper.ClientCnxn$SendThread.primeConnection（ClientCnxn.java:
908）Socketconnectionestablishedto192.168.50.211/192.168.50.211:
2181,initiatingsession
org.apache.zookeeper.ClientCnxn$SendThread.run（ClientCnxn.java:
1118）Unabletoreadadditionaldatafromserversessionid0×
0,likelyserverhasclosedsocket,closingsocketconnectionandattemptingreconnect
1000）Openingsocketconnectiontoserverlocalhost/127.0.0.1:
2010-11-1513:
56,626WARNorg.apache.zookeeper.ClientCnxn$SendThread.run（ClientCnxn.java:
1120）Session0×
0forservernull,unexpectederror,closingsocketconnectionandattemptingreconnect
记得在大约在2006年的时候Google出了Chubby来解决分布一致性的问题（distributedconsensusproblem），所有集群中的服务器通过Chubby最终选出一个MasterServer，最后这个MasterServer来协调工作。
简单来说其原理就是：
在一个分布式系统中，有一组服务器在运行同样的程序，它们需要确定一个Value，以那个服务器提供的信息为主/为准，当这个服务器经过n/2+1的方式被选出来后，所有的机器上的Process都会被通知到这个服务器就是主服务器Master服务器，大家以他提供的信息为准。
很想知道GoogleChubby中的奥妙，可惜人家Google不开源，自家用。
但是在2009年3年以后沉默已久的Yahoo在Apache上推出了类似的产品ZooKeeper，并且在Google原有Chubby的设计思想上做了一些改进，因为ZooKeeper并不是完全遵循Paxos协议，而是基于自身设计并优化的一个2phasecommit的协议，如图所示：
ZooKeeper跟Chubby一样用来存放一些相互协作的信息（Coordination），这些信息比较小一般不会超过1M，在zookeeper中是以一种hierarchicaltree的形式来存放，这些具体的Key/Value信息就store在treenode中，如图所示：
当有事件导致node数据，例如：
变更，增加，删除时，Zookeeper就会调用triggerWatch方法，判断当前的path来是否有对应的监听者（watcher）,如果有watcher，会触发其process方法，执行process方法中的业务逻辑，如图所示：
应用实例
ZooKeeper有了上述的这些用途，让我们设想一下，在一个分布式系统中有这这样的一个应用：
2个任务工厂（TaskFactory）一主一从，如果从的发现主的死了以后，从的就开始工作，他的工作就是向下面很多台代理（Agent）发送指令，让每台代理（Agent）获得不同的账户进行分布式并行计算，而每台代理（Agent）中将分配很多帐号，如果其中一台代理（Agent）死掉了，那么这台死掉的代理上的账户就不会继续工作了。
上述，出现了3个最主要的问题：
1.TaskFactory主/从一致性的问题
2.TaskFactory主/从心跳如何用简单+稳定或者2者折中的方式实现。
3.一台代理（Agent）死掉了以后，一部分的账户就无法继续工作，需要通知所有在线的代理（Agent）重新分配一次帐号。
怕文字阐述的不够清楚，画了系统中的TaskFactory和Agent的大概系统关系，如图所示：
OK，让我们想想ZooKeeper是不是能帮助我们去解决目前遇到的这3个最主要的问题呢？
解决思路
1.任务工厂TaskFactory都连接到ZooKeeper上，创建节点，设置对这个节点进行监控，监控方法例如：
event=newWatchedEvent（EventType.NodeDeleted,KeeperState.SyncConnected,"
/TaskFactory"
）;
这个方法的意思就是只要TaskFactory与zookeeper断开连接后，
升级会员 