【转载】Zookeeper 的学习与运用 - 开源中国社区
当前访客身份：游客 [
当前位置：
云计算越来越流行的今天，单一机器处理能力已经不能满足我们的需求，不得不采用大量的服务集群。服务集群对外提供服务的过程中，有很多的配置需要随时更新，服务间需要协调工作，这些信息如何推送到各个节点？并且保证信息的一致性和可靠性？
众所周知，分布式协调服务很难正确无误的实现，它们很容易在竞争条件和死锁上犯错误。如何在这方面节省力气？Zookeeper是一个不错的选择。 Zookeeper背后的动机就是解除分布式应用在实现协调服务上的痛苦。本文在介绍Zookeeper的基本理论基础上，用Zookeeper实现了一 个配置管理中心，利用Zookeeper将配置信息分发到各个服务节点上，并保证信息的正确性和一致性。
Zookeeper是什么？
引用官方的说法：“Zookeeper是一个高性能，分布式的，开源分布式应用协调服务。它提供了简单原始的功能，分布式应用可以基于它实现更高级 的服务，比如同步，配置管理，集群管理，名空间。它被设计为易于编程，使用文件系统目录树作为数据模型。服务端跑在java上，提供java和C的客户端 API”。
Zookeeper总体结构
Zookeeper服务自身组成一个集群(2n+1个服务允许n个失效)。Zookeeper服务有两个角色，一个是leader，负责写服务和数据同步，剩下的是follower，提供读服务，leader失效后会在follower中重新选举新的leader。
Zookeeper逻辑图如下，
客户端可以连接到每个server，每个server的数据完全相同。
每个follower都和leader有连接，接受leader的数据更新操作。
Server记录事务日志和快照到持久存储。
大多数server可用，整体服务就可用。
Zookeeper数据模型
Zookeeper表现为一个分层的文件系统目录树结构（不同于文件系统的是，节点可以有自己的数据，而文件系统中的目录节点只有子节点）。
数据模型结构图如下，
圆形节点可以含有子节点，多边形节点不能含有子节点。一个节点对应一个应用，节点存储的数据就是应用需要的配置信息。
Zookeeper 特点
顺序一致性：按照客户端发送请求的顺序更新数据。
原子性：更新要么成功，要么失败，不会出现部分更新。
单一性 ：无论客户端连接哪个server，都会看到同一个视图。
可靠性：一旦数据更新成功，将一直保持，直到新的更新。
及时性：客户端会在一个确定的时间内得到最新的数据。
Zookeeper运用场景
数据发布与订阅 （我的业务用到这个特性，后面会有详细介绍）
应用配置集中到节点上，应用启动时主动获取，并在节点上注册一个watcher，每次配置更新都会通知到应用。
名空间服务
分布式命名服务，创建一个节点后，节点的路径就是全局唯一的，可以作为全局名称使用。
分布式通知/协调
不同的系统都监听同一个节点，一旦有了更新，另一个系统能够收到通知。
Zookeeper能保证数据的强一致性，用户任何时候都可以相信集群中每个节点的数据都是相同的。一个用户创建一个节点作为锁，另一个用户检测该节点，如果存在，代表别的用户已经锁住，如果不存在，则可以创建一个节点，代表拥有一个锁。
每个加入集群的机器都创建一个节点，写入自己的状态。监控父节点的用户会受到通知，进行相应的处理。离开时删除节点，监控父节点的用户同样会收到通知。
Zookeeper在我们业务逻辑上的运用
我们公司做极光推送，Push 业务平台有大量的逻辑服务器，按业务类型分组。逻辑服务的运行依赖于配置，并且配置会在线调整，需要一个集中的配置项管理中心。Zookeeper的发布 与订阅特性以及发送更新通知的机制很好的满足了我们的需求。Zookeeper的容灾特性也免去了我们相关的大量管理工作。
下面我主要和大家分享一下Zookeeper在我们内部服务中的应用。
a. 我们的逻辑服务器包含两类配置。
一种为Acl（访问控制列表），用户的消息消费后，按照列表中的条件走向下一个逻辑服务器。另一种只是单独的算法逻辑的外提，称为Agl（访问算法列表），但是其中某些判断条件会经常变化。这两类配置被收集到了配置管理中心（即Zookeeper）。
逻辑图如下，
用户编辑好策略配置信息（xml格式），通过客户端加载到Zookeeper。Zookeeper立即通知其下的逻辑服务器（BLx），逻辑服务器 下载最新的配置策略，并应用新的策略。新的策略有可能改变某一段id范围内用户的数据流向，或越过原来的逻辑服务器，或指向新加入的逻辑服务器。
b. 数据模型设计
同一类型的逻辑服务在Zookeeper上创建一个节点，共享相同的配置信息。 该节点下面为策略配置项，分为Acl和Agl两类，如下图：（以代理逻辑服务为例）
Acl1, Acl2, Acl3, Agl1, Agl2分别存有策略配置信息。变化后会通知监听Proxy节点的逻辑服务器，Proxy逻辑服务器下载最新策略，并应用该策略。新节点的加入和退出也会通知到Proxy逻辑服务器。
c. 业务处理流程如下图
逻辑服务监听自己类型节点（本例如前图Proxy节点）
编辑新策略,加载策略到Zookeeper（策略保存在Proxy/Acls/Acl[1..n]，或Proxy/Agls/Agl1[1..n]）
Zookeeper通知各逻辑节点
各逻辑节点下载新策略到本地，并应用新策略
原文地址/index.php/push_zookeeper_study_usage/
共有15个评论
<span class="a_vote_num" id="a_vote_num_
听说过zookeeper，一直没研究过来着
<span class="a_vote_num" id="a_vote_num_
引用来自“fruitcake”的答案听说过zookeeper，一直没研究过来着可以参考下本文章
<span class="a_vote_num" id="a_vote_num_
感谢分享，学习下新知识了
<span class="a_vote_num" id="a_vote_num_
是不是在server上更新文件，follower会自动更新？
<span class="a_vote_num" id="a_vote_num_
没怎么看明白
--- 共有 1 条评论 ---
需要研究这块领域就再来看这篇文章吧
(3年前)&nbsp&
<span class="a_vote_num" id="a_vote_num_
zookeeper的相关文章好少
<span class="a_vote_num" id="a_vote_num_
接下来想好好看一下这个
<span class="a_vote_num" id="a_vote_num_
没怎么看明白
<span class="a_vote_num" id="a_vote_num_
要好好看，不知道能不能研究懂
<span class="a_vote_num" id="a_vote_num_
Zookeeper表现为一个分层的文件系统目录树结构
--- 共有 1 条评论 ---
啥意思 是如何存储的吗
(6个月前)&nbsp&
更多开发者职位上
有什么技术问题吗？
类似的话题74897人阅读
ZooKeeper是Hadoop Ecosystem中非常重要的组件，它的主要功能是为分布式系统提供一致性协调(Coordination)服务，与之对应的Google的类&#20284;服务叫Chubby。今天这篇文章分为三个部分来介绍ZooKeeper，第一部分介绍ZooKeeper的基本原理，第二部分介绍ZooKeeper提供的Client API的使用，第三部分介绍一些ZooKeeper典型的应用场景。
ZooKeeper基本原理
1. 数据模型
如上图所示，ZooKeeper数据模型的结构与Unix文件系统很类&#20284;，整体上可以看作是一棵树，每个节点称做一个ZNode。每个ZNode都可以通过其路径唯一标识，比如上图中第三层的第一个ZNode, 它的路径是/app1/c1。在每个ZNode上可存储少量数据(默认是1M, 可以通过配置修改, 通常不建议在ZNode上存储大量的数据)，这个特性非常有用，在后面的典型应用场景中会介绍到。另外，每个ZNode上还存储了其Acl信息，这里需要注意，虽说ZNode的树形结构跟Unix文件系统很类&#20284;，但是其Acl与Unix文件系统是完全不同的，每个ZNode的Acl的独立的，子结点不会继承父结点的，关于ZooKeeper中的Acl可以参考之前写过的一篇文章《》。
2.重要概念&
前文已介绍了ZNode, ZNode根据其本身的特性，可以分为下面两类：
ZNode还有一个Sequential的特性，如果创建的时候指定的话，该ZNode的名字后面会自动Append一个不断增加的SequenceNo。
2.2 Session
Client与ZooKeeper之间的通信，需要创建一个Session，这个Session会有一个超时时间。因为ZooKeeper集群会把Client的Session信息持久化，所以在Session没超时之前，Client与ZooKeeper Server的连接可以在各个ZooKeeper Server之间透明地移动。
在实际的应用中，如果Client与Server之间的通信足够频繁，Session的维护就不需要其它额外的消息了。否则，ZooKeeper Client会每t/3 ms发一次心跳给Server，如果Client 2t/3 ms没收到来自Server的心跳回应，就会换到一个新的ZooKeeper Server上。这里t是用户配置的Session的超时时间。
2.3 Watcher
ZooKeeper支持一种Watch操作，Client可以在某个ZNode上设置一个Watcher，来Watch该ZNode上的变化。如果该ZNode上有相应的变化，就会触发这个Watcher，把相应的事件通知给设置Watcher的Client。需要注意的是，ZooKeeper中的Watcher是一次性的，即触发一次就会被取消，如果想继续Watch的话，需要客户端重新设置Watcher。这个跟epoll里的oneshot模式有点类&#20284;。
3. ZooKeeper特性&
3.1 读、写(更新)模式
在ZooKeeper集群中，读可以从任意一个ZooKeeper Server读，这一点是保证ZooKeeper比较好的读性能的关键；写的请求会先Forwarder到Leader，然后由Leader来通过ZooKeeper中的原子广播协议，将请求广播给所有的Follower，Leader收到一半以上的写成功的Ack后，就认为该写成功了，就会将该写进行持久化，并告诉客户端写成功了。
3.2 WAL和Snapshot
和大多数分布式系统一样，ZooKeeper也有WAL(Write-Ahead-Log)，对于每一个更新操作，ZooKeeper都会先写WAL, 然后再对内存中的数据做更新，然后向Client通知更新结果。另外，ZooKeeper还会定期将内存中的目录树进行Snapshot，落地到磁盘上，这个跟HDFS中的FSImage是比较类&#20284;的。这么做的主要目的，一当然是数据的持久化，二是加快重启之后的恢复速度，如果全部通过Replay WAL的形式恢复的话，会比较慢。
对于每一个ZooKeeper客户端而言，所有的操作都是遵循FIFO顺序的，这一特性是由下面两个基本特性来保证的：一是ZooKeeper Client与Server之间的网络通信是基于TCP，TCP保证了Client/Server之间传输包的顺序；二是ZooKeeper Server执行客户端请求也是严&#26684;按照FIFO顺序的。
3.4 Linearizability
在ZooKeeper中，所有的更新操作都有严&#26684;的偏序关系，更新操作都是串行执行的，这一点是保证ZooKeeper功能正确性的关键。
ZooKeeper Client API
ZooKeeper Client Library提供了丰富直观的API供用户程序使用，下面是一些常用的API：
ZooKeeper典型应用场景
1. 名字服务(NameService)&
分布式应用中，通常需要一套完备的命令机制，既能产生唯一的标识，又方便人识别和记忆。 我们知道，每个ZNode都可以由其路径唯一标识，路径本身也比较简洁直观，另外ZNode上还可以存储少量数据，这些都是实现统一的NameService的基础。下面以在HDFS中实现NameService为例，来说明实现NameService的基本布骤:
2. 配置管理(Configuration Management)&
在分布式系统中，常会遇到这样的场景: 某个Job的很多个实例在运行，它们在运行时大多数配置项是相同的，如果想要统一改某个配置，一个个实例去改，是比较低效，也是比较容易出错的方式。通过ZooKeeper可以很好的解决这样的问题，下面的基本的步骤：
3. 组员管理(Group Membership)&
在典型的Master-Slave结构的分布式系统中，Master需要作为“总管”来管理所有的Slave, 当有Slave加入，或者有Slave宕机，Master都需要感知到这个事情，然后作出对应的调整，以便不影响整个集群对外提供服务。以HBase为例，HMaster管理了所有的RegionServer，当有新的RegionServer加入的时候，HMaster需要分配一些Region到该RegionServer上去，让其提供服务；当有RegionServer宕机时，HMaster需要将该RegionServer之前服务的Region都重新分配到当前正在提供服务的其它RegionServer上，以便不影响客户端的正常访问。下面是这种场景下使用ZooKeeper的基本步骤：
4. 简单互斥锁(Simple Lock)&
我们知识，在传统的应用程序中，线程、进程的同步，都可以通过操作系统提供的机制来完成。但是在分布式系统中，多个进程之间的同步，操作系统层面就无能为力了。这时候就需要像ZooKeeper这样的分布式的协调(Coordination)服务来协助完成同步，下面是用ZooKeeper实现简单的互斥锁的步骤，这个可以和线程间同步的mutex做类比来理解：
5. 互斥锁(Simple Lock without Herd Effect)&
上一节的例子中有一个问题，每次抢锁都会有大量的进程去竞争，会造成羊群效应(Herd Effect)，为了解决这个问题，我们可以通过下面的步骤来改进上述过程：
这里需要补充一点，通常在分布式系统中用ZooKeeper来做Leader Election(选主)就是通过上面的机制来实现的，这里的持锁者就是当前的“主”。
6. 读写锁(Read/Write Lock)&
我们知道，读写锁跟互斥锁相比不同的地方是，它分成了读和写两种模式，多个读可以并发执行，但写和读、写都互斥，不能同时执行行。利用ZooKeeper，在上面的基础上，稍做修改也可以实现传统的读写锁的语义，下面是基本的步骤:
7. 屏障(Barrier)&
在分布式系统中，屏障是这样一种语义: 客户端需要等待多个进程完成各自的任务，然后才能继续往前进行下一步。下用是用ZooKeeper来实现屏障的基本步骤：
8. 双屏障(Double Barrier)
双屏障是这样一种语义: 它可以用来同步一个任务的开始和结束，当有足够多的进程进入屏障后，才开始执行任务；当所有的进程都执行完各自的任务后，屏障才撤销。下面是用ZooKeeper来实现双屏障的基本步骤：
进入屏障：
离开屏障：
转载地址：
数据发布与订阅（配置中心）
发布与订阅模型，即所谓的配置中心，顾名思义就是发布者将数据发布到ZK节点上，供订阅者动态获取数据，实现配置信息的集中式管理和动态更新。例如全局的配置信息，服务式服务框架的服务地址列表等就非常适合使用。
注意：在上面提到的应用场景中，有个默认前提是：数据量很小，但是数据更新可能会比较快的场景。
这里说的负载均衡是指软负载均衡。在分布式环境中，为了保证高可用性，通常同一个应用或同一个服务的提供方都会部署多份，达到对等服务。而消费者就须要在这些对等的服务器中选择一个来执行相关的业务逻辑，其中比较典型的是消息中间件中的生产者，消费者负载均衡。
消息中间件中发布者和订阅者的负载均衡，linkedin开源的KafkaMQ和阿里开源的都是通过zookeeper来做到生产者、消费者的负载均衡。这里以metaq为例如讲下：
生产者负载均衡：metaq发送消息的时候，生产者在发送消息的时候必须选择一台broker上的一个分区来发送消息，因此metaq在运行过程中，会把所有broker和对应的分区信息全部注册到ZK指定节点上，默认的策略是一个依次轮询的过程，生产者在通过ZK获取分区列表之后，会按照brokerId和partition的顺序排列组织成一个有序的分区列表，发送的时候按照从头到尾循环往复的方式选择一个分区来发送消息。
消费负载均衡：
在消费过程中，一个消费者会消费一个或多个分区中的消息，但是一个分区只会由一个消费者来消费。MetaQ的消费策略是：
在某个消费者故障或者重启等情况下，其他消费者会感知到这一变化（通过 zookeeper watch消费者列表），然后重新进行负载均衡，保证所有的分区都有消费者进行消费。
命名服务(Naming Service)
命名服务也是分布式系统中比较常见的一类场景。在分布式系统中，通过使用命名服务，客户端应用能够根据指定名字来获取资源或服务的地址，提供者等信息。被命名的实体通常可以是集群中的机器，提供的服务地址，远程对象等等——这些我们都可以统称他们为名字（Name）。其中较为常见的就是一些分布式服务框架中的服务地址列表。通过调用ZK提供的创建节点的API，能够很容易创建一个全局唯一的path，这个path就可以作为一个名称。
阿里巴巴集团开源的分布式服务框架Dubbo中使用ZooKeeper来作为其命名服务，维护全局的服务地址列表，查看Dubbo开源项目。在Dubbo实现中：
服务提供者在启动的时候，向ZK上的指定节点/dubbo/${serviceName}/providers目录下写入自己的URL地址，这个操作就完成了服务的发布。
服务消费者启动的时候，订阅/dubbo/${serviceName}/providers目录下的提供者URL地址， 并向/dubbo/${serviceName} /consumers目录下写入自己的URL地址。
注意，所有向ZK上注册的地址都是临时节点，这样就能够保证服务提供者和消费者能够自动感应资源的变化。
另外，Dubbo还有针对服务粒度的监控，方法是订阅/dubbo/${serviceName}目录下所有提供者和消费者的信息。
分布式通知/协调
ZooKeeper中特有watcher注册与异步通知机制，能够很好的实现分布式环境下不同系统之间的通知与协调，实现对数据变更的实时处理。使用方法通常是不同系统都对ZK上同一个znode进行注册，监听znode的变化（包括znode本身内容及子节点的），其中一个系统update了znode，那么另一个系统能够收到通知，并作出相应处理
总之，使用zookeeper来进行分布式通知和协调能够大大降低系统之间的耦合
集群管理与Master选举
利用ZooKeeper有两个特性，就可以实时另一种集群机器存活性监控系统：
例如，监控系统在 /clusterServers 节点上注册一个Watcher，以后每动态加机器，那么就往 /clusterServers 下创建一个 EPHEMERAL类型的节点：/clusterServers/{hostname}. 这样，监控系统就能够实时知道机器的增减情况，至于后续处理就是监控系统的业务了。
在分布式环境中，相同的业务应用分布在不同的机器上，有些业务逻辑（例如一些耗时的计算，网络I/O处理），往往只需要让整个集群中的某一台机器进行执行，其余机器可以共享这个结果，这样可以大大减少重复劳动，提高性能，于是这个master选举便是这种场景下的碰到的主要问题。
利用ZooKeeper的强一致性，能够保证在分布式高并发情况下节点创建的全局唯一性，即：同时有多个客户端请求创建 /currentMaster 节点，最终一定只有一个客户端请求能够创建成功。利用这个特性，就能很轻易的在分布式环境中进行集群选取了。
另外，这种场景演化一下，就是动态Master选举。这就要用到?EPHEMERAL_SEQUENTIAL类型节点的特性了。
上文中提到，所有客户端创建请求，最终只有一个能够创建成功。在这里稍微变化下，就是允许所有请求都能够创建成功，但是得有个创建顺序，于是所有的请求最终在ZK上创建结果的一种可能情况是这样： /currentMaster/{sessionId}-1 ,?/currentMaster/{sessionId}-2 ,?/currentMaster/{sessionId}-3 ….. 每次选取序列号最小的那个机器作为Master，如果这个机器挂了，由于他创建的节点会马上小时，那么之后最小的那个机器就是Master了。
分布式锁，这个主要得益于ZooKeeper为我们保证了数据的强一致性。锁服务可以分为两类，一个是保持独占，另一个是控制时序。
分布式队列
队列方面，简单地讲有两种，一种是常规的先进先出队列，另一种是要等到队列成员聚齐之后的才统一按序执行。对于第一种先进先出队列，和分布式锁服务中的控制时序场景基本原理一致，这里不再赘述。
第二种队列其实是在FIFO队列的基础上作了一个增强。通常可以在 /queue 这个znode下预先建立一个/queue/num 节点，并且赋&#20540;为n（或者直接给/queue赋&#20540;n），表示队列大小，之后每次有队列成员加入后，就判断下是否已经到达队列大小，决定是否可以开始执行了。这种用法的典型场景是，分布式环境中，一个大任务Task A，需要在很多子任务完成（或条件就绪）情况下才能进行。这个时候，凡是其中一个子任务完成（就绪），那么就去 /taskList 下建立自己的临时时序节点（CreateMode.EPHEMERAL_SEQUENTIAL），当
/taskList 发现自己下面的子节点满足指定个数，就可以进行下一步按序进行处理了。
参考知识库
* 以上用户言论只代表其个人观点，不代表CSDN网站的观点或立场
访问：349843次
积分：2993
积分：2993
排名：第8596名
原创：46篇
转载：37篇
评论：22条
(3)(2)(1)(1)(1)(1)(1)(4)(1)(1)(2)(3)(2)(2)(1)(1)(8)(1)(6)(3)(4)(7)(1)(1)(3)(3)(3)(1)(1)(5)(2)(5)(1)(2)分布式（2）
Dubbo建议使用Zookeeper作为服务的注册中心。
1.&& Zookeeper的作用：
&&&&&&& zookeeper用来注册服务和进行负载均衡，哪一个服务由哪一个机器来提供必需让调用者知道，简单来说就是ip地址和服务名称的对应关系。当然也可以通过硬编码的方式把这种对应关系在调用方业务代码中实现，但是如果提供服务的机器挂掉调用者无法知晓，如果不更改代码会继续请求挂掉的机器提供服务。zookeeper通过心跳机制可以检测挂掉的机器并将挂掉机器的ip和服务对应关系从列表中删除。至于支持高并发，简单来说就是横向扩展，在不更改代码的情况通过添加机器来提高运算能力。通过添加新的机器向zookeeper注册服务，服务的提供者多了能服务的客户就多了。
2.& dubbo：
&&&&& 是管理中间层的工具，在业务层到数据仓库间有非常多服务的接入和服务提供者需要调度，dubbo提供一个框架解决这个问题。
&&&&& 注意这里的dubbo只是一个框架，至于你架子上放什么是完全取决于你的，就像一个汽车骨架，你需要配你的轮子引擎。这个框架中要完成调度必须要有一个分布式的注册中心，储存所有服务的元数据，你可以用zk，也可以用别的，只是大家都用zk。
3. zookeeper和dubbo的关系：
&&&&& Dubbo的将注册中心进行抽象，是得它可以外接不同的存储媒介给注册中心提供服务，有ZooKeeper，Memcached，Redis等。
&&&&& 引入了ZooKeeper作为存储媒介，也就把ZooKeeper的特性引进来。首先是负载均衡，单注册中心的承载能力是有限的，在流量达到一定程度的时候就需要分流，负载均衡就是为了分流而存在的，一个ZooKeeper群配合相应的Web应用就可以很容易达到负载均衡；资源同步，单单有负载均衡还不够，节点之间的数据和资源需要同步，ZooKeeper集群就天然具备有这样的功能；命名服务，将树状结构用于维护全局的服务地址列表，服务提供者在启动的时候，向ZK上的指定节点/dubbo/${serviceName}/providers目录下写入自己的URL地址，这个操作就完成了服务的发布。其他特性还有Mast选举，分布式锁等。
参考知识库
* 以上用户言论只代表其个人观点，不代表CSDN网站的观点或立场
访问：1342次
排名：千里之外
转载：65篇
(45)(21)(1)(1)<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
您的访问请求被拒绝 403 Forbidden - ITeye技术社区
您的访问请求被拒绝
亲爱的会员，您的IP地址所在网段被ITeye拒绝服务，这可能是以下两种情况导致：
一、您所在的网段内有网络爬虫大量抓取ITeye网页，为保证其他人流畅的访问ITeye，该网段被ITeye拒绝
二、您通过某个代理服务器访问ITeye网站，该代理服务器被网络爬虫利用，大量抓取ITeye网页
请您点击按钮解除封锁&47908人阅读
建议参考资料：
先把zookeeper在本地给安装好，
安装方法参考：
这里的话讲述了两个工程一个工程是提供服务的，一个工程是调用服务的，因为dubbo是跟spring进行无缝连接的，故功能配置在spring的配置文件中，跟spring进行整合开发
1、工程是以maven进行构建的，使用的jar包如下：
2、服务提供者的工程
a、dubbo-demo-api& 定义接口
public interface IProcessData {
public String deal(String data);
b、dubbo-demo-provider&服务提供者
public class ProcessDataImpl implements IProcessData {
* @see com.xxx.bubbo.provider.IProcessData#deal(java.lang.String)
public String deal(String data) {
Thread.sleep(1000);
} catch (InterruptedException e) {
e.printStackTrace();
return &Finished:& +
c、applicationProvider.xml配置
&?xml version=&1.0& encoding=&UTF-8&?&
&beans xmlns=&http://www.springframework.org/schema/beans&
xmlns:xsi=&http://www.w3.org/2001/XMLSchema-instance& xmlns:dubbo=&/schema/dubbo&
xsi:schemaLocation=&http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans.xsd
/schema/dubbo
/schema/dubbo/dubbo.xsd
&!-- Application name --&
&dubbo:application name=&hello-world-app& /&
&!-- registry address, used for service to register itself --&
&dubbo:registry address=&zookeeper://127.0.0.1:2181& /&
&!-- expose this service through dubbo protocol, through port 20880 --&
&dubbo:protocol name=&dubbo& port=&20880& /&
&dubbo:protocol name=&dubbo& port=&9090& server=&netty&
client=&netty& codec=&dubbo& serialization=&hessian2& charset=&UTF-8&
threadpool=&fixed& threads=&100& queues=&0& iothreads=&9& buffer=&8192&
accepts=&1000& payload=&8388608& /&
&!-- Service interface
Concurrent Control
&dubbo:service interface=&com.huangjie.dubbo_Service.service.IProcessData&
ref=&demoService& executes=&10& /&
&!-- Default Protocol --&
&dubbo:protocol server=&netty& /&
&!-- designate implementation --&
&bean id=&demoService& class=&com.huangjie.dubbo_Service.service.impl.ProcessDataImpl& /&
d、启动服务
public class DubboProviderMain {
public static void main(String[] args) throws Exception {
ClassPathXmlApplicationContext context = new ClassPathXmlApplicationContext(
new String[]{&applicationProvider.xml&});
context.start();
System.out.println(&Press any key to exit.&);
System.in.read();
3、服务调用者的工程
public class ConsumerThd implements Runnable {
* @see java.lang.Runnable#run()
public void run() {
ClassPathXmlApplicationContext context = new ClassPathXmlApplicationContext(
new String[]{&applicationConsumer.xml&});
context.start();
IProcessData demoService = (IProcessData) context.getBean(&demoService&); // get
// service
// invocation
String hello = demoService.deal(&nihao&); // do invoke!
System.out.println(Thread.currentThread().getName() + & &+hello);
public static void main(String[] args) {
new Thread(new ConsumerThd()).start();
* 输出结果：
* Thread-0 Finished:nihao
b、applicationConsumer.xml配置
&?xml version=&1.0& encoding=&UTF-8&?&
&beans xmlns=&http://www.springframework.org/schema/beans&
xmlns:xsi=&http://www.w3.org/2001/XMLSchema-instance& xmlns:dubbo=&/schema/dubbo&
xsi:schemaLocation=&http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans.xsd
/schema/dubbo
/schema/dubbo/dubbo.xsd
&!-- consumer application name --&
&dubbo:application name=&consumer-of-helloworld-app& /&
&!-- registry address, used for consumer to discover services --&
&dubbo:registry address=&zookeeper://127.0.0.1:2181& /&
&dubbo:consumer timeout=&5000&/&
&!-- which service to consume? --&
&dubbo:reference id=&demoService& interface=&com.huangjie.dubbo_Service.service.IProcessData& /&
&/beans& 4、最后需要把zookeeper的服务给启动，在zookeeper安装文件夹下面的bin目录里面的zkServer.cmd给点击运行。不要关闭窗口，保持服务运行
这样整个调用就完成了，这样的好处是只要远程提供ip地址及端口号，以及对外调用的类，客户端就可以调用，客户端不必知道服务端的地址之类的
而且服务端可以开多个zookeeper服务，这样如果其中一个zookeeper 服务死掉了，其他服务还能正常运行
工程下载路径：
参考知识库
* 以上用户言论只代表其个人观点，不代表CSDN网站的观点或立场
访问：1107692次
积分：9931
积分：9931
排名：第1221名
原创：180篇
转载：129篇
评论：164条
(2)(8)(6)(3)(1)(3)(1)(2)(5)(2)(9)(11)(8)(4)(4)(18)(24)(1)(19)(4)(2)(3)(11)(14)(2)(7)(18)(4)(5)(11)(5)(6)(46)(7)(20)(13)}