CN103973725A - 一种分布式协同方法和协同器 - Google Patents

Abstract

本申请提供一种分布式协同方法，包括：协同器接收到来自协同客户端的节点创建请求后，为所述协同客户端建立节点，并确定所述节点所属的域，其中，每个节点只属于一个域；以及，在节点发生变化或域发生变化时，所述协同器通知满足预设条件的协同客户端。本申请还提供一种协同器。本申请进行协同管理时，配置仅为域和节点两层，简化了配置，提高了性能。

Description

一种分布式协同方法和协同器

技术领域

本申请涉及计算机系统，尤其涉及一种分布式协同方法和协同器。

背景技术

大型分布式应用通常需要调度器、控制器、协同器等管理任务进程的资源分配和任务调度，为避免大多数应用将协同器嵌入在调度控制等实现中，造成系统扩充困难，开发维护成本高的问题，通常将协同器独立出来设计成为通用、可伸缩的协同系统。计算机集群中通常需要维持一个领导者的服务器，它负责进行集群管理和调度等职责，因此集群需要在启动和运行等各个阶段保证一个领导者提供服务，并且在故障和恢复后能重新选择领导者。

目前业界分布式协同系统的主要实现有Zookeeper和Chubby，Zookeeper实际上是Google的Chubby一个开源的实现。zookeeper的配置中心实现更像一个文件系统，文件系统中的所有文件形成一个树状结构，zookeeper维护着这样的树形层次结构，树中的节点称为znode，每个znode存储的数据有小于1M(兆)的大小限制。zookeeper对znode提供了几种类型，临时znode、持久znode、顺序znode等几种类型，用于不同的一致性需求。在znode发生变化时，通过观察(watch)机制可以让客户端得到通知。可以针对Zookeeper服务的“操作”来设置观察，该服务的其他操作可以触发观察。Zookeeper服务的“操作”包括一些对znode添加修改获取操作。Zookeeper采用一种类似Paxos的算法实现领导者选举，用于解决集群宕机的一致性和协同保障。总体上，Zookeeper提供了一个分布式协同系统，包括配置维护、名字服务、分布式同步、组服务等功能，并将相关操作接口提供给用户。

Zookeeper的结构如图1所示，其实现包括：

1、启动Zookeeper服务器集群环境后，多个Zookeeper服务器在工作前会选举出一个领导者(Leader)，在接下来的工作中这个被选举出来的Leader失活，而剩下的Zookeeper服务器会知道这个Leader失活，在正常运行的Zookeeper集群中会继续选出一个Leader，选举出leader的目的是为了可以在分布式的环境中保证数据的一致性。

2、另外，Zookeeper支持watch的概念。客户端可以在每个znode结点上设置一个观察。如果被观察服务端的znode结点有变更，那么watch就会被触发，这个watch所属的客户端将接收到一个通知包被告知结点已经发生变化。若客户端和所连接的Zookeeper服务器断开连接时，其他客户端也会收到一个通知，也就说一个Zookeeper服务器端可以对应多个客户端，当然也可以多个Zookeeper服务器端对应多个客户端。

Zookeeper作为一个chubby和paxos模仿品，存在以下缺点：

1、树型配置节点的繁琐复杂，性能低下。为了保证这种结构，Zookeeper需要维持一套虚拟文件结构的开销，对于目录结构深的树节点，造成性能影响。

2、watch机制的僵化设计：zookeeper没有获取最新版本信息的方法支持，它只能粗暴的在每次写入更新等方法时注册一个watch，当这些方法被调用后就回调，它不考虑信息内容是否变化，对于没有使信息内容发生改变的更新，zookeeper仍然会回调，并且zookeeper的回调比较呆板，它只能用一次，如果信息持续变化，必须又重新注册watch。

3、领导者选举机制实现的太过局限，集群只有两个节点，zookeeper无法进行领导者选举，zookeeper的领导者选举必须要奇数节点的奇怪限制。另外，Zookeeper的领导者选举实现虽然比原始的Paxos要简化，但是它仍然存在领导者(Leader)、跟随者(Follower)、观察者(observer)、学习者(Learner)等众多角色和跟随状态(Following)、寻找状态(Looking)、观察状态(Observing)、领导状态(Leading)等复杂状态。一个zookeeper的选举流程大致如下：

选举线程由当前Follower发起选举的线程担任，其主要功能是对投票结果进行统计，并选出推荐的Follower；选举线程首先向所有Follower发起一次询问(包括自己)；选举线程收到回复后，验证是否是自己发起的询问(验证zxid是否一致)，然后获取对方的id(myid)，并存储到当前询问对象列表中，最后获取对方提议的leader相关信息(id，zxid)，并将这些信息存储到当次选举的投票记录表中；收到所有Follower回复以后，就计算出zxid最大的那个Follower，并将这个Follower相关信息设置成下一次要投票的Follower；线程将当前zxid最大的Follower设置为当前Follower要推荐的Leader，如果此时获胜的Follower获得n/2+1的Follower票数，设置当前推荐的leader为获胜的Follower，将根据获胜的Follower相关信息设置自己的状态，否则，继续这个过程，直到leader被选举出来。通过流程分析我们可以得出：要使Leader获得多数Follower的支持，则Follower总数必须是奇数2n+1，且存活的Follower的数目不得少于n+1。

发明内容

本申请要解决的技术问题是提供一种分布式协同方法和协同器，提高分布式协同性能。

为了解决上述问题，本申请提供了一种分布式协同方法，包括：

协同器接收到来自协同客户端的节点创建请求后，为所述协同客户端建立节点，并确定所述节点所属的域，其中，每个节点只属于一个域；

以及，在节点发生变化或域发生变化时，所述协同器通知满足预设条件的协同客户端。

上述方法还可具有以下特点，所述节点创建请求中还携带节点的值，所述协同器为所述协同客户端建立所述节点时，还保存所述节点的值。

上述方法还可具有以下特点，所述协同器接收到协同客户端的设置节点监听请求后，从所述设置节点监听请求中获取发送该设置节点监听请求的协同客户端监听的节点；和/或，接收到协同客户端的设置域监听请求后，从所述设置域监听请求中获取发送该设置域监听请求的协同客户端监听的域；

在节点发生变化或域发生变化时，所述协同器通知满足预设条件的协同客户端包括：

在节点发生变化或域发生变化时，所述协同器通知监听所述发生变化的节点或域的协同客户端。

上述方法还可具有以下特点，所述设置节点监听请求或者所述设置域监听请求中还携带是否连续响应的指示信息；

如果所述设置节点监听请求或者所述设置域监听请求中携带连续响应的指示信息，则所述协同器在所述节点或域每次发生变化时，均通知所述满足预设条件的协同客户端；

如果所述设置节点监听请求或者所述设置域监听请求中携带不连续响应的指示信息，则所述协同器在接收到所述设置节点监听请求或者所述设置域监听请求后，仅在所述节点或域首次发生变化时通知所述满足预设条件的协同客户端。

上述方法还可具有以下特点，所述协同器还用于执行如下之一或其组合：

接收到所述协同客户端的节点更新请求后，使用所述节点更新请求中携带的值对所述节点更新请求中指定的节点的值进行更新；

接收到所述协同客户端的获取节点信息请求后，将所述节点信息请求中指定的节点的值返回给所述协同客户端；

接收到所述协同客户端的节点删除请求后，删除所述节点删除请求中指定的节点；

接收到所述协同客户端的域删除请求后，删除所述域删除请求中指定的域及其下的所有节点；

接收到所述协同客户端的域获取请求后，返回所述域获取请求中指定的域中所有节点的值。

上述方法还可具有以下特点，所述协同器为多个协同器中的协同器领导者，所述多个协同器中除所述协同器领导者外的为协同器候选者，所述协同器领导者上的域及其下的节点信息与所述协同器候选者同步。

上述方法还可具有以下特点，在领导者选举触发条件满足时，所述多个协同器中被触发的协同器判断自己是否为协同器领导者，如果是，返回自己是协同器领导者；

否则，所述被触发的协同器查询其余协同器中是否有协同器领导者，如果有，则返回查询到的协同器领导者；如果所有协同器均不是协同器领导者，则被触发的协同器将自己设置为协同器领导者并返回。

上述方法还可具有以下特点，所述领导者选举触发条件包括如下之一或其组合：

集群启动初始化时，所述集群为所述协同器所管理的协同客户端的集合；

所述集群重启时；

所述协同器为协同器候选者且接收到协同客户端的操作请求，且当前的协同器领导者不能提供服务。

本申请还提供一种协同器，包括：

节点管理模块，用于接收到来自协同客户端的节点创建请求后，为所述协同客户端建立节点，并确定所述节点所属的域，其中，每个节点只属于一个域；

通知模块，用于在节点发生变化或域发生变化时，通知满足预设条件的协同客户端。

上述协同器还可具有以下特点，所述节点管理模块还用于：为所述协同客户端建立所述节点时，获取并保存所述节点创建请求中携带的所述节点的值。

上述协同器还可具有以下特点，所述节点管理模块还用于：接收到协同客户端的设置节点监听请求后，从所述设置节点监听请求中获取发送该设置节点监听请求的协同客户端监听的节点；和/或，接收到协同客户端的设置域监听请求后，从所述设置域监听请求中获取发送该设置域监听请求的协同客户端监听的域；

所述通知模块在节点发生变化或域发生变化时，通知满足预设条件的协同客户端包括：

在节点发生变化或域发生变化时，通知监听所述发生变化的节点或域的协同客户端。

上述协同器还可具有以下特点，所述节点管理模块还用于：保存所述设置节点监听请求或者所述设置域监听请求中携带的是否连续响应的指示信息；

所述通知模块还用于：如果所述指示信息为连续响应，则在所述节点或域每次发生变化时，均通知所述满足预设条件的协同客户端；如果所述指示信息为不连续响应，则仅在接收到所述设置节点监听请求或者所述设置域监听请求后，所述节点或域首次发生变化时通知所述满足预设条件的协同客户端。

上述协同器还可具有以下特点，所述节点管理模块还用于执行如下之一或其组合：

接收到所述协同客户端的节点更新请求后，使用所述节点更新请求中携带的值对所述节点更新请求中指定的节点的值进行更新；

接收到所述协同客户端的获取节点信息请求后，将所述节点信息请求中指定的节点的值返回给所述协同客户端；

接收到所述协同客户端的节点删除请求后，删除所述节点删除请求中指定的节点；

接收到所述协同客户端的域删除请求后，删除所述域删除请求中指定的域及其下的所有节点；

接收到所述协同客户端的域获取请求后，返回所述域获取请求中指定的域中所有节点的值。

上述协同器还可具有以下特点，所述协同器为多个协同器中的协同器领导者，且所述协同器领导者上的域及其下的节点信息与协同器候选者同步，所述协同器候选者为所述多个协同器中除所述协同器领导者外的协同器。

上述协同器还可具有以下特点，所述协同器还包括：领导者选举模块，用于：在领导者选举触发条件满足且所述协同器被触发时，判断所述协同器是否为协同器领导者，如果是，返回所述协同器是协同器领导者；否则，所述协同器查询其余协同器中是否有协同器领导者，如果有，则返回查询到的协同器领导者；如果所有协同器均不是协同器领导者，则所述被触发的协同器设置为协同器领导者并返回。

上述协同器还可具有以下特点，所述领导者选举触发条件包括如下之一或其组合：

集群启动初始化时，所述集群为所述协同器所管理的协同客户端的集合；

所述集群重启时；

所述协同器为协同器候选者且接收到协同客户端的操作请求，且当前的协同器领导者不能提供服务。

本申请包括以下优点：

1、本申请对协同客户端进行协同管理时，配置仅为域和节点两层，简化了配置，提高了性能。

2、本申请事件处理可以自由控制是否持续响应信息变化。

3、本申请的领导者选举，只存在领导者和候选者两种角色，同一时刻只有一个协同器处于领导状态，其余处于候选状态，领导者的选举快捷，易于实现。

当然，实施本申请的任一产品并不一定需要同时达到以上所述的所有优点。

附图说明

图1是现有Zookeeper算法实现示意图；

图2是本申请实施例分布式协同方法示意图；

图3是本申请实施例领导者选举示意图；

图4是本申请实施例1示意图；

图5是本申请实施例协同器框图。

具体实施方式

为使本申请的目的、技术方案和优点更加清楚明白，下文中将结合附图对本申请的实施例进行详细说明。需要说明的是，在不冲突的情况下，本申请中的实施例及实施例中的特征可以相互任意组合。

另外，虽然在流程图中示出了逻辑顺序，但是在某些情况下，可以以不同于此处的顺序执行所示出或描述的步骤。

本申请提出一种分布式协同方法，采用精简的两层结构的配置中心和更直观的容易保证业务逻辑完整性的内容变化事件以及状态轮循，以及简化的领导者选举算法实现。

本申请实施例提供一种分布式协同方法，包括：

协同器接收到来自协同客户端的节点创建请求后，为所述协同客户端建立节点，并确定所述节点所属的域，其中，每个节点只属于一个域；

以及，在节点发生变化或域发生变化时，所述协同器通知满足预设条件的协同客户端。

在本实施例的一种备选方案中，所述节点创建请求中还携带节点的值，所述协同器为所述协同客户端建立所述节点时，还保存所述节点的值。

在本实施例的一种备选方案中，还包括：

所述协同器接收到协同客户端的设置节点监听请求后，从所述设置节点监听请求中获取发送该设置节点监听请求的协同客户端监听的节点；和/或，接收到协同客户端的设置域监听请求后，从所述设置域监听请求中获取发送该设置域监听请求的协同客户端监听的域；

在节点发生变化或域发生变化时，所述协同器通知满足预设条件的协同客户端包括：

在节点发生变化或域发生变化时，所述协同器通知监听所述发生变化的节点或域的协同客户端。通知的方式可以是事件响应。也可以通过其他方式通知。

在本实施例的一种备选方案中，所述设置节点监听请求或者所述设置域监听请求中还携带是否连续响应的指示信息；

如果所述设置节点监听请求或者所述设置域监听请求中携带连续响应的指示信息，则所述协同器在所述节点或域每次发生变化时，均通知所述满足预设条件的协同客户端；

如果所述设置节点监听请求或者所述设置域监听请求中携带不连续响应的指示信息，则所述协同器在接收到所述设置节点监听请求或者所述设置域监听请求后，仅在所述节点或域首次发生变化时通知所述满足预设条件的协同客户端。

在本实施例的一种备选方案中，所述协同器还用于执行如下之一或其组合：

接收到所述协同客户端的节点更新请求后，使用所述节点更新请求中携带的值对所述节点更新请求中指定的节点的值进行更新；

接收到所述协同客户端的获取节点信息请求后，将所述节点信息请求中指定的节点的值返回给所述协同客户端；

接收到所述协同客户端的节点删除请求后，删除所述节点删除请求中指定的节点；

接收到所述协同客户端的域删除请求后，删除所述域删除请求中指定的域及其下的所有节点；

接收到所述协同客户端的域获取请求后，返回所述域获取请求中指定的域中所有节点的值。

在本实施例的一种备选方案中，所述协同器为多个协同器中的协同器领导者，所述多个协同器中除所述协同器领导者外的为协同器候选者，所述协同器领导者上的域及其下的节点信息与所述协同器候选者同步。

在本实施例的一种备选方案中，还包括：

在领导者选举触发条件满足时，所述多个协同器中被触发的协同器判断自己是否为协同器领导者，如果是，返回自己是协同器领导者；

否则，所述被触发的协同器查询其余协同器中是否有协同器领导者，如果有，则返回查询到的协同器领导者；如果所有协同器均不是协同器领导者，则被触发的协同器将自己设置为协同器领导者并返回。

在本实施例的一种备选方案中，所述领导者选举触发条件包括如下之一或其组合：

集群启动初始化时，所述集群为所述协同器所管理的协同客户端的集合；

所述集群重启时；

所述协同器为协同器候选者且接收到协同客户端的操作请求，且当前的协同器领导者不能提供服务。

在存在多个协同器时，协同客户端可以通过查询方式获知协同器领导者，当然，也可以由协同器领导者告知协同客户端哪个协同器是协同器领导者。

下面通过一个实施例进一步说明本申请。

本申请提供的分布式协同系统，包括协同器和协同客户端，协同器上建立一个domain(域)，node(节点)两层结构的节点信息。其中，domain可以是分类或者包，node可以是具体属性，domain和node可以根据需求设计命名，比如可以将domain命名为“a.b.c...”表示一个树型类目。一个domain下可以有很多个node，每个node只指定一个domain，可以通过domain返回它下面所有的node。domain不需要单独建立，通常在建立node时，如果不存在domain会自动创建。如果domain下没有node了，该domain会自动删除。如果删除domain，该domain下面node也都会删除。每个node下可以存放一个值，可以是任意对象。

所有的节点信息存放在协同器领导者和协同器候选者(也称备份者)里，协同客户端上安装有协同器代理，通过协同器代理与协同器交互，实现对协同器的操作。如图2所示。

从图2可以看到，协同器提供domain，node的两层配置信息结构管理，以及同步备份、领导者选举等功能。集群中可以有一个协同器领导者和多个协同器候选者，它们的配置信息(即域及其下的节点信息，包括节点的值)是同步复制的，该配置信息可以以内存的方式保存在协同器内，当然也可以非内存的方式保存。当然，也可以只存在一个协同器，此时，该协同器即为协同器领导者。

协同客户端上安装的协同器代理提供对节点进行一系列的交互操作，并且结合协同器的领导者选举等功能，共同来实现众多分布式协同功能，协同器代理提供的操作包括但不局限于：

1、创建node：通过提供domain和node的名称，以及值，进行创建节点；

2、更新node：通过提供domain和node的名称，对指定的域下的节点的值进行更新；

3、获取node：通过提供domain和node的名称，获取node的值；

4、获取domain下所有node：通过提供domain，获取该domain下所有node的值；

5、删除node：通过提供domain和node的名称，对node进行删除；

6、删除domain：通过提供domain的名称，对domain下所有node进行删除；

7、设置node监听：当node发生变化时(包括node的值变化，node删除等)，提供事件响应，并可指定是否连续响应；

8、设置domain监听：当domain发生变化时(包括：domain下任意一个node值发生变化，domain下有node增加或删除等)，提供事件响应，并可指定是否连续响应。

当协同器领导者出现宕机等故障时，协同器候选者继续提供服务，领导者选举流程如图3所示，包括：

当领导者选举触发条件满足后，会首先对一台协同器进行询问，该协同器会判断自己是否为协同器领导者，如果是就返回，说明已经存在协同器领导者；如果不是，就需要进一步逐个询问其他协同器是否为协同器领导者，如果其中一个是，那么返回查询到的协同器领导者；如果所有协同器都不是协同器领导者，最初接受询问的那台协同器就将自己设置为协同器领导者，完成领导者选举，该协同器领导者为协同客户端提供服务。

在本实施例的一种备选方案中，领导者选举触发条件包括但不限于：集群启动初始化时，集群重启时，协同器领导者不能提供服务，协同器候选者接收到来自协同客户端的请求时。具体的，当集群初始化启动时，需要选取一台服务器作为领导者，当出现故障重新启动和维护时也需要重新选举，或者当原有的领导者故障不能提供服务时，协同器候选者接收到请求时，也要进行领导者选举。

协同器领导者不能提供服务，协同器候选者接收到来自协同客户端的请求时触发的领导者选举流程具体包括：协同客户端发现无法与协同器领导者建立连接，则发送请求至协同器候选者，协同器候选者开始领导者选举过程；或者，协同客户端发送请求至协同器领导者，协同器领导者无法提供服务时，将请求转发至协同器候选者，协同器候选者开始领导者选举过程。

协同器客户端和协同器交互时，会进行查询，并由查询到的协同器领导者与协同器客户端交互。

下面通过具体实施例进一步说明本申请的应用。

实施例1

将本申请提供的分布式协同方法应用到集群管理。

对于像淘宝这样上万台服务器集群环境的大型互联网应用，通常面临这样一种需求：需要一个集群管理者管理集群里的服务器，同一个集群中任何一台服务器宕机，其他服务器都能感知。如果是集群管理者宕机，集群中所有的服务器不能受任何影响，能实时切换到备份管理者上被提供服务。如图4所示。图4中的主管理者相同于协同器领导者，备管理者相当于协同器候选者。

集群管理者(主管理者和备管理者)内部提供一个“集群组”(group)和“服务器”(server)的配置信息，相当于本申请中的域和节点，分别用来表示不同的集群和它包含的服务器。这里的集群管理者采用一个或者多个协同器实现。

当集群中的服务器(相当于协同客户端)启动时，会通过协同器代理向集群管理者进行注册，在集群管理者的配置信息中建立一个该服务器的节点信息，当该服务器故障时，集群管理者会实时删除该服务器的节点信息。服务器注册后，会对该集群组进行监听，这里采用domain监听实现，当集群组的配置信息有变更时，也就是其他服务器启动或者死去时，服务器都会通过变化事件实时感知。

集群管理者包括主、备两个实例，这里采用协同器领导者和协同器候选者实现，它们之间数据是同步的，也就是主集群管理者的配置信息发生变化时，备管理者上的配置信息也会实时发生更新，如果主管理者故障宕机，备管理者会马上提供管理服务，服务器可以从备管理者获取集群的实时信息。

实施例2，

将本申请提供的分布式协同方法应用到配置信息的统一。

在分布式多台机器环境下，维持统一的配置信息是最常见的需求，当配置信息改变时，所有的机器能实时获取并更新。例如淘宝的业务服务需求，每个业务系统如商品、交易对外都提供的有服务地址，而且依赖其他业务系统的服务，那么服务地址是一个公共使用的配置信息，如果服务地址变换，应该所有的业务系统能实时获知并响应变换。

假如商品业务系统需要注册自己的服务地址，则在协同器上建立一个“domain＝商品，node＝服务，value＝地址1、地址2、地址3...”的节点；

如果交易业务系统依赖商品的服务，则可以对“domain＝商品，node＝服务”进行节点监听，如果商品业务系统的服务地址有变化(即节点的value发生变化)，协同器会通知交易业务系统，从而交易业务系统能够实时获知并响应变化。

如果协同器领导者出现故障，交易业务系统仍然能找到协同器候选者，触发领导者选举过程，选取协同器领导者后，继续获取商品业务系统的服务地址信息，而不受任何影响。

实施例3，分布式锁的应用

分布式环境下，多个业务系统争抢一个公共资源时，通常需要分布式锁的控制，比如淘宝的一个数据下载系统，如果太多的业务系统并发的进行数据下载，造成大量的压力导致缓慢，可以通过分布式锁进行控制。

首先，数据下载系统在协同器上建立一个锁的domain，然后各业务系统通过协同器代理在该domain下建立一个自己的node用来排队，并监听该domain的变化信息。

某个业务系统如果发现自己的node满足预设条件，比如自己的node排在首位，便下载数据，下载完成后删除该node达到释放锁的目的，这样domain的信息发生变化，协同器发送事件给监听该domain的业务系统，其余的业务系统收到事件，检查自己的node是否轮到了首位，如果发现自己的node排在首位，便下载数据，否则继续等待，这样通过分布式锁依次执行完成所有的数据下载。

对于上面所述的淘宝数据下载系统场景，假设共有10台计算机，都需要从一台服务器上下载数据，这台服务器的带宽资源有限，无法支持10台计算机多个进程同时请求下载，可以通过上述分布式锁进行维持次序。

首先协同器建立一个domain用于代表锁，然后10台计算机分别监听该domain的变化，10台计算机按照上面所述，依次在该domain下建立各自的node，该node相当于一个令牌。然后各计算机检查自己是否处在第一位，如果是，就下载数据，当自己完成下载后，将该node删除，然后第二位开始下载...直到10台计算机全部下载完为止。

本申请实施例还提供一种协同器，如图5所示，包括：

节点管理模块501，用于接收到来自协同客户端的节点创建请求后，为所述协同客户端建立节点，并确定所述节点所属的域，其中，每个节点只属于一个域；

通知模块502，用于在节点发生变化或域发生变化时，通知满足预设条件的协同客户端。

在本实施例的一种备选方案中，所述节点管理模块501还用于：为所述协同客户端建立所述节点时，获取并保存所述节点创建请求中携带的所述节点的值。

在本实施例的一种备选方案中，所述节点管理模块501还用于：接收到协同客户端的设置节点监听请求后，从所述设置节点监听请求中获取发送该设置节点监听请求的协同客户端监听的节点；和/或，接收到协同客户端的设置域监听请求后，从所述设置域监听请求中获取发送该设置域监听请求的协同客户端监听的域；

所述通知模块502在节点发生变化或域发生变化时，通知满足预设条件的协同客户端包括：

在节点发生变化或域发生变化时，通知监听所述发生变化的节点或域的协同客户端。

在本实施例的一种备选方案中，所述节点管理模块501还用于：保存所述设置节点监听请求或者所述设置域监听请求中携带的是否连续响应的指示信息；

所述通知模块502还用于：如果所述指示信息为连续响应，则在所述节点或域每次发生变化时，均通知所述满足预设条件的协同客户端；如果所述指示信息为不连续响应，则仅在接收到所述设置节点监听请求或者所述设置域监听请求后，所述节点或域首次发生变化时通知所述满足预设条件的协同客户端。

在本实施例的一种备选方案中，所述节点管理模块501还用于执行如下之一或其组合：

接收到所述协同客户端的节点更新请求后，使用所述节点更新请求中携带的值对所述节点更新请求中指定的节点的值进行更新；

接收到所述协同客户端的获取节点信息请求后，将所述节点信息请求中指定的节点的值返回给所述协同客户端；

接收到所述协同客户端的节点删除请求后，删除所述节点删除请求中指定的节点；

接收到所述协同客户端的域删除请求后，删除所述域删除请求中指定的域及其下的所有节点；

接收到所述协同客户端的域获取请求后，返回所述域获取请求中指定的域中所有节点的值。

在本实施例的一种备选方案中，所述协同器为多个协同器中的协同器领导者，且所述协同器领导者上的域及其下的节点信息与协同器候选者同步，所述协同器候选者为所述多个协同器中除所述协同器领导者外的协同器。

在本实施例的一种备选方案中，所述协同器还包括：领导者选举模块503，用于：在领导者选举触发条件满足且所述协同器被触发时，判断所述协同器是否为协同器领导者，如果是，返回所述协同器是协同器领导者；否则，所述协同器查询其余协同器中是否有协同器领导者，如果有，则返回查询到的协同器领导者；如果所有协同器均不是协同器领导者，则将所述被触发的协同器设置为协同器领导者并返回。

在本实施例的一种备选方案中，所述领导者选举触发条件包括如下之一或其组合：

集群启动初始化时，所述集群为所述协同器所管理的协同客户端的集合；

所述集群重启时；

所述协同器为协同器候选者且接收到协同客户端的操作请求，且当前的协同器领导者不能提供服务。

本领域普通技术人员可以理解上述方法中的全部或部分步骤可通过程序来指令相关硬件完成，所述程序可以存储于计算机可读存储介质中，如只读存储器、磁盘或光盘等。可选地，上述实施例的全部或部分步骤也可以使用一个或多个集成电路来实现。相应地，上述实施例中的各模块/单元可以采用硬件的形式实现，也可以采用软件功能模块的形式实现。本申请不限制于任何特定形式的硬件和软件的结合。

Claims (16)

1.一种分布式协同方法，其特征在于，包括：

协同器接收到来自协同客户端的节点创建请求后，为所述协同客户端建立节点，并确定所述节点所属的域，其中，每个节点只属于一个域；

以及，在节点发生变化或域发生变化时，所述协同器通知满足预设条件的协同客户端。

2.如权利要求1所述的方法，其特征在于，所述节点创建请求中还携带节点的值，所述协同器为所述协同客户端建立所述节点时，还保存所述节点的值。

3.如权利要求1所述的方法，其特征在于，所述方法还包括：

所述协同器接收到协同客户端的设置节点监听请求后，从所述设置节点监听请求中获取发送该设置节点监听请求的协同客户端监听的节点；和/或，接收到协同客户端的设置域监听请求后，从所述设置域监听请求中获取发送该设置域监听请求的协同客户端监听的域；

在节点发生变化或域发生变化时，所述协同器通知满足预设条件的协同客户端包括：

在节点发生变化或域发生变化时，所述协同器通知监听所述发生变化的节点或域的协同客户端。

4.如权利要求3所述的方法，其特征在于，所述设置节点监听请求或者所述设置域监听请求中还携带是否连续响应的指示信息；

如果所述设置节点监听请求或者所述设置域监听请求中携带连续响应的指示信息，则所述协同器在所述节点或域每次发生变化时，均通知所述满足预设条件的协同客户端；

如果所述设置节点监听请求或者所述设置域监听请求中携带不连续响应的指示信息，则所述协同器在接收到所述设置节点监听请求或者所述设置域监听请求后，仅在所述节点或域首次发生变化时通知所述满足预设条件的协同客户端。

5.如权利要求2所述的方法，其特征在于，所述协同器还用于执行如下之一或其组合：

接收到所述协同客户端的节点更新请求后，使用所述节点更新请求中携带的值对所述节点更新请求中指定的节点的值进行更新；

接收到所述协同客户端的获取节点信息请求后，将所述节点信息请求中指定的节点的值返回给所述协同客户端；

接收到所述协同客户端的节点删除请求后，删除所述节点删除请求中指定的节点；

接收到所述协同客户端的域删除请求后，删除所述域删除请求中指定的域及其下的所有节点；

接收到所述协同客户端的域获取请求后，返回所述域获取请求中指定的域中所有节点的值。

6.如权利要求1所述的方法，其特征在于，所述方法还包括：所述协同器为多个协同器中的协同器领导者，所述多个协同器中除所述协同器领导者外的为协同器候选者，所述协同器领导者上的域及其下的节点信息与所述协同器候选者同步。

7.如权利要求6所述的方法，其特征在于，所述方法还包括：

在领导者选举触发条件满足时，所述多个协同器中被触发的协同器判断自己是否为协同器领导者，如果是，返回自己是协同器领导者；

否则，所述被触发的协同器查询其余协同器中是否有协同器领导者，如果有，则返回查询到的协同器领导者；如果所有协同器均不是协同器领导者，则被触发的协同器将自己设置为协同器领导者并返回。

8.如权利要求7所述的方法，其特征在于，所述领导者选举触发条件包括如下之一或其组合：

集群启动初始化时，所述集群为所述协同器所管理的协同客户端的集合；

所述集群重启时；

所述协同器为协同器候选者且接收到协同客户端的操作请求，且当前的协同器领导者不能提供服务。

9.一种协同器，其特征在于，包括：

节点管理模块，用于接收到来自协同客户端的节点创建请求后，为所述协同客户端建立节点，并确定所述节点所属的域，其中，每个节点只属于一个域；

通知模块，用于在节点发生变化或域发生变化时，通知满足预设条件的协同客户端。

10.如权利要求9所述的协同器，其特征在于，所述节点管理模块还用于：为所述协同客户端建立所述节点时，获取并保存所述节点创建请求中携带的所述节点的值。

11.如权利要求9所述的协同器，其特征在于，

所述节点管理模块还用于：接收到协同客户端的设置节点监听请求后，从所述设置节点监听请求中获取发送该设置节点监听请求的协同客户端监听的节点；和/或，接收到协同客户端的设置域监听请求后，从所述设置域监听请求中获取发送该设置域监听请求的协同客户端监听的域；

所述通知模块在节点发生变化或域发生变化时，通知满足预设条件的协同客户端包括：

在节点发生变化或域发生变化时，通知监听所述发生变化的节点或域的协同客户端。

12.如权利要求11所述的协同器，其特征在于，

所述节点管理模块还用于：保存所述设置节点监听请求或者所述设置域监听请求中携带的是否连续响应的指示信息；

所述通知模块还用于：如果所述指示信息为连续响应，则在所述节点或域每次发生变化时，均通知所述满足预设条件的协同客户端；如果所述指示信息为不连续响应，则仅在接收到所述设置节点监听请求或者所述设置域监听请求后，所述节点或域首次发生变化时通知所述满足预设条件的协同客户端。

13.如权利要求10所述的协同器，其特征在于，所述节点管理模块还用于执行如下之一或其组合：

接收到所述协同客户端的节点更新请求后，使用所述节点更新请求中携带的值对所述节点更新请求中指定的节点的值进行更新；

接收到所述协同客户端的获取节点信息请求后，将所述节点信息请求中指定的节点的值返回给所述协同客户端；

接收到所述协同客户端的节点删除请求后，删除所述节点删除请求中指定的节点；

接收到所述协同客户端的域删除请求后，删除所述域删除请求中指定的域及其下的所有节点；

接收到所述协同客户端的域获取请求后，返回所述域获取请求中指定的域中所有节点的值。

14.如权利要求9所述的协同器，其特征在于，所述协同器为多个协同器中的协同器领导者，且所述协同器领导者上的域及其下的节点信息与协同器候选者同步，所述协同器候选者为所述多个协同器中除所述协同器领导者外的协同器。

15.如权利要求14所述的协同器，其特征在于，所述协同器还包括：领导者选举模块，用于：在领导者选举触发条件满足且所述协同器被触发时，判断所述协同器是否为协同器领导者，如果是，返回所述协同器是协同器领导者；否则，所述协同器查询其余协同器中是否有协同器领导者，如果有，则返回查询到的协同器领导者；如果所有协同器均不是协同器领导者，则所述被触发的协同器设置为协同器领导者并返回。

16.如权利要求15所述的协同器，其特征在于，所述领导者选举触发条件包括如下之一或其组合：

集群启动初始化时，所述集群为所述协同器所管理的协同客户端的集合；

所述集群重启时；

所述协同器为协同器候选者且接收到协同客户端的操作请求，且当前的协同器领导者不能提供服务。