在NoSQL数据库的分布式算法的深度分析（图文详解图）
虽然NoSQL运动不到分布式数据处理带来根本性的技术变革，它还导致了压倒性的研究与实践对各种协议和算法。在这篇文章中，我将给出的NoSQL数据库的分布式特征进行系统的描述。系统的可扩展性是促进NoSQL运动发展的主要原因，包括分布式系统的协调，故障转移，资源管理和许多其他特性。这使得NoSQL听起来像一个大筐，什么都可以停留在NoSQL运动。虽然不到分布式数据处理带来根本性的技术变革，它仍然会导致绝大多数的研究和实践，对各种协议和算法。正是通过这些努力，一些有效的数据库建设方法已逐步总结。在这篇文章中，我将给出的NoSQL数据库的分布式特征进行系统的描述。
接下来，我们将研究一些分布式策略，如故障检测中的复制。这些策略用黑体字标出，分为三段：
1。数据consistency.nosql需要平衡的一致性，容错性和性能，低延迟和分布式系统的高可用性。一般来说，数据一致性是必要的选项，因此本节主要是关于数据复制和数据恢复。
2。数据放置。数据库产品应该能够应对不同的数据分布，集群拓扑和硬件配置。在这一节中，我们将讨论如何分配和调整数据的分布情况，为及时解决问题，提供持续的保证，有效地查询和确保资源在集群的均衡使用，如内存和硬盘空间。
三.对等系统。技术如领导人选举已被用于多个数据库产品实现的容错性和数据一致性强。然而，即使分散的数据库（无中心）应遵循他们的全局状态，检测故障和拓扑结构的变化，本节介绍了几种技术，使系统保持一致。
数据一致性
众所周知，分布式系统经常遇到网络隔离或延迟。在这种情况下，隔离部分不可用。因此，它是不可能保持高可用性而不牺牲一致性。这个事实经常被称为CAP理论。然而，一致性是分布式系统中一个非常昂贵的东西，所以我们经常需要做出一些让步，不仅可用性，也为各种trade-offs.in为了研究这些权衡，我们注意到，分布式系统的一致性问题是通过数据隔离和复制引起的，所以我们将开始复制的特点。
可用性 u3002in网络隔离的情况下，其余部分仍然可以响应读写请求。
读写延迟，读写请求可以在短时间内处理。
读和写的可塑性。阅读和写作的压力可以通过多个节点的平衡。
容错。读写请求的处理不依赖于任何特定的节点。
数据持久性：特定条件下的节点失效不会导致数据丢失。
均匀 u3002consistency比以前复杂得多的功能，我们需要详细讨论一些不同的观点。但我们不会覆盖许多一致性和并发模型，因为这超出了本文的范围。我只会使用一些简单的功能来形成一个流线型的系统。
从读写的角度看，数据库的基本目标是使副本的收敛时间尽可能短，即将更新交付给所有副本的时间，以保证最终的一致性，除了这个弱保证，还有更强的一致性特征：
写后写一致性。写在数据项x上的效果总是可以在随后的x上的读操作中看到。
读后读取一致性。在读取数据项x之后，x的后续读操作应该返回与第一个返回值相同或更新的值。
写入一致性。分区数据库中经常出现写冲突。数据库应该能够处理这种冲突，并确保不同的分区不处理多个写请求：
原子被写入。如果数据库提供API，写操作只能是一个单独的原子赋值。避免冲突的方法是找出每个数据的最新版本，这使得所有节点在更新结束时得到相同的版本，但与更新后的顺序无关。网络故障和延误引起的节点不同的订单更新。数据的版本可以通过时间戳或值由用户指定的代表。这是卡桑德拉用它的方式。
雾化的读写应用程序的变化。有时需要读-修改-写入顺序操作而不是单独的原子写操作。如果两个客户端读取相同的数据的版本，修改和写入修改后的数据返回到它，根据原子的写作模式，更新时间将覆盖以前的时间。在某些情况下，这种行为是不正确的（例如，两个客户端添加新值相同的列表值）。数据库提供了至少两种解决方案：
预防冲突。读-修改-写的可以被认为是一个特殊的案例，所以分布式锁，或如Paxos一致的协议，可以解决这个问题。这项技术支持原子读改写语义和任意的隔离级别的事务。另一种方法是避免分布式并发写操作，而写操作的具体数据项目的一个节点（可全球主节点或分区的主节点）。为了避免冲突，数据库必须牺牲网络隔离的可用性。这种方法经常用于许多系统提供强一致性保证（例如，大多数关系型数据库、HBase、MonDB）。
冲突检测，数据库跟踪并发更新和选择回滚其中之一或两版本保持由客户自行解决。并发更新通常与向量时钟跟踪（这是一种乐观锁），或一个完整的版本的版本历史保持。采用这种方法的危险，Voldemort，CouchDB。
现在让我们仔细看看常用的复制技术和分类，根据特征描述。第一幅图描绘了不同的技术和不同的技术之间的权衡协调的系统的一致性，可扩展性之间的逻辑关系，可用性和延迟。二图纸详细描述每种技术。
复合因子为4，读/写协调器可以是外部客户机或内部代理节点。
我们将根据各方的共识，从弱到强的技术：
在策略上，（a，反熵）一致性最弱，在写操作时选择任何节点更新。在读取时，如果新数据没有被传输到节点，通过背景反熵协议读取，那么旧数据仍然被读取（下一节将详细介绍反熵协议）：
过度的传播延迟，使得它很难使用的数据同步，因此，典型的用法是检测和维修的计划性的辅助功能。卡桑德拉用一个反熵算法调用数据库的拓扑结构和一些其他的元数据信息，每个节点之间。
一致性保证是薄弱的：即使在没有失败的情况下，也会出现写冲突和读写之间的分歧。
网络隔离下的高可用性和健壮性，异步批处理被一一替换，性能优良。
持久性较弱，因为新数据最初只是一个副本。
（b）对上述模式的一种改进是异步地向所有可用节点发送更新，同时任何节点接收更新数据请求，这也被视为方向反熵。
与单纯的反熵相比，这种方法大大提高了一致性，只牺牲了少量性能，但形式一致性和持久性保持不变。
如果由于网络故障或节点故障而无法获得某些节点，则最终将通过反熵传播过程将更新传递给该节点。
（c）在以前的模式，迅速转移技术的使用可以更好地处理一个节点的操作失败，无效节点的更新记录在额外的代理节点，表明更新传递到节点一旦特征节点可用。这提高了一致性并减少复制时间。
（d，一次性读写），因为在更新更新之前，提示切换的节点也可能失败。在这种情况下，必须通过所谓的读修复来确保一致性，每个读操作将启动一个异步过程，并向存储该数据的所有节点请求数据摘要（如签名或散列）。如果我们发现每个节点返回的摘要不一致，每个节点的数据版本将被统一，我们命名为一种技术，用一次性、读写的方法将a、b、c和d组合起来。他们没有提供严格的一致性保证，但是作为一种自我提供的方法，它已经被应用到实践中。
以上策略（E，读一些写的）是一个启发式的增强降低复制的收敛时间。为了保证更大的一致性，这是必要的牺牲可用性保证了一定的重叠的阅读和写作。通常的做法是在代替一个同时写W份，读R拷贝时阅读。
首先，您可以配置写入拷贝数w > 1。
其次，由于R+W >是绑定的节点和节点之间的重叠的读写，所以会出现在数据的多个副本至少多了一个新的数据读取（W = 2，r = 3，n = 4）。这样，当读写请求的执行接着，他们可以确保一致性（读写单用户的一致性），但他们不能保证全球一致性。根据实例下图中，R = 2，W = 2，n = 3，因为两份写作作业的更新是非交易。当更新未完成时，可以读取两个旧值或一个新值。
对于某些读延迟，设置r和w的不同值可以调整写延迟和写持续时间，反之亦然。
如果WN / 2可以确保检测到冲突时原子读改写是在反转模式。
严格地说，这种模型可以容忍单个节点的失效，但是网络隔离的容错性不好，在实际中，这种近似方法常常被用来牺牲某些一致性来提高某些场景的可用性。
读取数据时，通过读取所有拷贝（读取数据或检查摘要）可以减轻阅读一致性问题。这就确保了只要至少一个节点上的数据更新，读者可以看到新的数据。但在网络隔离的情况下，这种保证将不起作用。
（G，主从）这种技术通常用来提供读写为原子书写或冲突检测水平持续改写，以达到预防冲突的水平，有必要使用一个集中的管理模式或锁。最简单的策略是复制一个master-slave.all异步写操作的特定数据项的路由到一个中央节点和顺序执行的。在这种情况下，主节点会成为瓶颈，所以我们必须把数据分成独立的部门（不同片不同大师），以提供可扩展性。
（H，事务读写群体和群体的读一写）更新多个副本的方法可以避免使用事务控制技术写冲突。著名的方法是使用两阶段提交协议。但两阶段提交是不完全可靠的，因为人的失败可能导致资源阻塞Paxos的提交。协议是一个更可靠的选择，但它会损失一点性能，在此基础上进一步的小步骤是读所有的副本的副本，将副本的更新在一个事务中，它提供了较强的容错性，但会失去一些性能和可用性。
上述分析中的一些权衡需要再次强调。
一致性和可用性，CAP理论给出了严格的权衡，在网络隔离的情况下，数据库既可以设置数据，也可以接受数据丢失的风险。
一致性和可扩展性，可以看出，即使是一致的读写保证也降低了副本集的可扩展性。只有在原子的写作模式我们可以处理写作在一个相对可扩展的方式冲突。原子读改写模型避免了冲突增加临时全局锁的数据。这说明数据或操作之间的依赖性，即使在很小的范围内或很短的一段时间，也会损害的可扩展性。因此精心设计的数据模型和数据分开存储的数据的可扩展性很重要。
一致性和延迟，如上所述，当数据库需要提供很强的一致性或持久性时，它应该偏向于读取和编写所有的复制技术，但显然与请求延迟一致，与拷贝数成反比，因此使用该技术将是更客观的措施。
故障转移和一致性/可扩展性/延迟。有趣的是，容错性和一致性，冲突性，延迟不是暴力。通过合理放弃一些性能和一致性，集群能够容忍节点故障多达上。这种妥协在两阶段提交和Paxos协议之间的区别是很明显的。另一个例子，这种妥协是增加特定的一致性保证，如使用严格的会话进程读写，但这增加了故障转移的复杂性。
反熵协议、谣言传播算法
让我们从以下几点开始：
有多个节点，每个节点上都有一个副本，每个节点可以分别处理更新请求，每个节点定期与其他节点同步。在此期间，所有副本将趋于一致。同步过程是如何完成的什么时候开始同步如何选择同步对象你怎样交换数据我们假设两个节点总是用新版本的数据覆盖旧数据，或者为应用层处理保留两个版本。
这个问题在等场景的数据一致性维护和集群状态同步是常见的，如集群成员信息传播。虽然负责人介绍了监测数据库和同步方案可以解决这一问题，分散的数据库能够提供更好的容错性。集中的主要方法是使用精心设计的传染的协议，这是比较简单，但提供了一个很好的收敛时间，而且可以忍受任何节点失效和网络隔离。虽然有很多感染类型的算法，我们只注意反熵协议因为NoSQL数据库是使用它。
反熵协议假定同步将按照一个固定的时间表执行。每个节点定期选择另一个节点交换数据，消除差异，根据一定的规则，有三个反熵的反熵协议：推，拉和组合，推动协议的原则是简单地选择一个随机的节点发送数据的状态，过去。这显然是把所有的数据在实际应用中愚蠢的，所以节点一般工作在下面显示的方式。
节点，作为同步引发剂、准备数据的摘要，其中包含在A的数据指纹接收汇总后，节点B比较数据与本地数据和返回的数据差异为总结回到最后的总结，一个发送到B，B一个更新，然后更新数据。拉模式和混合方法之间的协议类似，如上图所示。
反熵协议提供了足够好的收敛时间和可扩展性。下面的图显示了在100个节点的集群中传播更新的结果。在每次迭代中，每个节点只与随机选择的对等点相关联。
可以看出，拉模式的收敛比的推送方法，理论上可以证明，还有一个问题，收敛到尾。经过多次迭代，虽然几乎所有的节点都走过，仍然有一部分是不受影响的混合方法。比单纯的推拉方式更有效，所以通常在实际应用中，反熵是可扩展的，平均转换时间的增加在集群规模的对数函数形式。
虽然这些技术看起来很简单，仍然有许多研究专注于反熵协议在不同的约束条件下的性能，其中使用一个更有效的使用网络拓扑结构来代替随机选择。调整传输速率有限的网络带宽下或使用高级规则选择数据同步。总结计算也面临着挑战，和数据库将保持最近更新日志来汇总计算。
最终一致的数据类型最终一致的数据类型
在最后一节中，我们假设两个节点总是合并它们的数据版本，但是解决更新冲突并不容易，而且所有副本最终都能达到语义上正确的值并不奇怪。
我们假设一个例子来说明这个问题：数据库维护一个逻辑的全局计数器，每个节点可以增加或减少的数量。虽然每个节点可以保持局部的自身价值，这些地方不能用简单的加减合并。假设的一个例子是，有三个节点A，B，和C，每个节点执行额外的操作。如果从B的值并将其添加到本地副本，然后C得到值B，然后C获取值，然后对C的最终值是4，这是不对的。这个问题的解决方案是使用一个数据结构类似于一个向量时钟保持每个节点对计数器。
类反{
int加}
int减去
国际node_id
增量（）{
node_id加{ } + +
}
减量（）{
node_id减{ } + +
}
获取（）{
返回和（和）-和（减号）
}
合并（计数器其他）{
我在1。max_id {
加{ i max = max（加{ }，其他。加{ }）
减去最大值（减去{，}，另一个，减去{ }）
}
}
}
卡桑德拉被以类似的方式，一个更复杂的最终一致的数据结构还可以用一个状态或基于复制理论进行设计，例如，提到一系列这样的数据结构，包括：
计数器（加减法）
集合（添加和删除操作）
图（添加一个边或一个顶点，去掉一个边或一个顶点）
列表（插入或删除一个位置）
最终一致数据类型的功能通常是有限的，并且带来额外的性能开销。
数据布局
这部分重点讨论控制分布式数据库中数据放置的算法，这些算法负责将数据项映射到适当的物理节点、在节点之间迁移数据和资源（如内存）的全局分配。
平衡数据
我们从一个简单的协议，提供群集节点之间的数据无缝迁移。这往往是在集群扩展时（如添加新的节点（节点故障转移），一些停机时间）或平衡数据（节点间数据分布不均衡）这样的场景。场景描述图一如下-三节点和三节点的数据是随机分布的（假设数据都是核心价值）。
如果数据库不支持数据的内部平衡，数据库实例是发表在每个节点，如图B所示。这需要手动集群扩展停止迁移的数据库实例，它转移到新节点，并开始在新的节点，如图虽然数据库监控每一个记录，很多系统包括mondb，Oracle Coherence和Redis集群仍然使用自动均衡技术，将数据切成片，将每个数据片为迁移的最小单位，它是基于效率。很明显，段数将超过节点的数量，和数据层能够均匀的分布在节点。根据简单的协议，可以实现无缝数据迁移。该协议将数据迁移节点和移动节点时，数据迁移片段。下面的图描述了一个状态机来获得（关键）在Redis集群实现的逻辑。
假设每个节点知道集群的拓扑结构，它可以映射任何键对应的数据切片和数据映射到节点。如果节点确定所请求的密钥属于局部层，它会被发现（上面在上面），如果节点确定的关键要求：到另一个节点x，他会送一个永久重定向命令给客户端（下面的框上的数字）。永久重定向意味着客户端可以缓存切片和节点之间的映射关系。如果分段迁移正在进行中，移民的节点和移动节点将相应的片和锁带锁后的数据块移动。出口节点将首先定位的关键局部，如果没有找到，将客户重定向到移动节点，如果密钥已被迁移。这种重定向是一次性的，不可缓存的。迁移节点处理重定向本地，但定期查询永久重定向在迁移之前没有完成。
动态环境下的数据分块与复制
我们关注的另一个问题是如何将记录映射到物理节点，更直接的方法是用表记录每个范围中键和节点之间的映射关系。一个范围键对应一个节点，或者从密钥散列值和节点号获得的值作为节点ID，但在集群变化的情况下，散列取取的方法不太好，因为增加或减少节点将导致数据在集群中彻底重新排列，这使得复制和恢复变得困难。
有许多方法来提高复制和故障恢复的角度看，最著名的是一致性哈希。有很多一致性哈希在线介绍，所以在这里我只提供一个基本的介绍，只是对文章内容的完整性。下图描绘了一致性哈希的基本原则：
一致性哈希从根本上来说是一种键-值映射结构——它将密钥（通常是散列）映射到物理节点，密钥经过散列后的值空间是有序的固定长度二进制字符串。显然，在这个范围内的每个密钥将被映射到一个三节点，B和C在图A的复制品，价值空间封闭成环，沿环顺时针直到所有副本映射到相应的节点，如图B，换句话说，你将位于节点B，因为它在B的范围内，第一个副本应放置在C，和第二副本放置在一个，等等。
这种结构的优点是增加或减少一个节点，因为它只会在相邻的区域中的数据保持平衡。如图C所示，节点D的加入只会影响数据项X和Y上有没有影响，同样，节点B的去除（或B只有失败）影响Y和X的拷贝，并且不影响X本身。然而，这种方法既有优点也有缺点，那就是，经济负担是由相邻节点承担，这将移动大量的数据。每个节点映射到一个范围而不是一个范围，这一问题的不利影响可以减轻到一定程度，如图D，这是一个权衡所示。在重新平衡数据时避免过载。然而，与基于模块的映射相比，它使总体均衡的数量适当减少。
保持完全一致的一大簇哈希环是不容易的。这是没有问题的一个比较小的数据库集群，和有趣的是研究如何数据放置和对等网络中的路由网络的结合。一个更好的例子是Chord算法，使环的完整性的承认单个节点的搜索效率。Chord算法还采用环映射关键节点的思想，这是在这方面的一致性哈希很相似。不同的是，一个特定的节点维护一个列表，列表中的节点和环上的逻辑位置是成倍增加（如下图所示），这使得它可以使用一个两点搜索来定位关键W只有少数网络跳转。
这张图片是一个由16个节点组成的集群，它描述了A节点如何寻找放置在节点D上的密钥。（a）描述路由，（b）描述了节点A、B和C的环的局部图像，在参考中，有更多关于分散系统中数据复制的内容。
根据多个属性进行数据碎片
当哈希是用来访问数据，一致性的数据放置策略是有效的，但它会更复杂时，查询多个属性，一个简单的方法（使用mondb）是使用一个主键分配的数据而不考虑其他属性。结果是基于主键的查询可以被路由到一个合适的节点，但处理其他查询要遍历的群集的所有节点，查询效率的不平衡会导致以下问题：
有一个数据集，其中每个数据有许多属性和相应的值。是否有一种允许尽可能少地执行任意多个属性的查询的数据分布策略
的hyperdex数据库提供了一个解决方案。其基本思路是将每个属性为多维空间中的一个轴，映射的区域在空间上的物理节点，查询将被匹配到一个由多个相邻的区域空间中的超平面，所以只有这些地区的查询相关的。让我们来在参考的例子看看。
每个数据是一个用户的信息，有三个属性，名字，姓氏和电话号码。这些属性被视为一个三维空间中，一个可行的数据分布策略地图的每个象限一个物理节点，查询名字=约翰对应一个平面贯穿4个象限，，是的，只有4个节点参与查询的处理。一个有两个属性约束查询对应的直线，穿过两象限，在最后的图所示，只有2个节点将介入处理。
这种方法的问题是空间象限将属性个数的指数函数增加。因此，只有几个属性限制的查询将被投射到许多空间区域，即许多服务器，更多的属性数据项分成若干子项目相对较少的属性，和每个子项映射到而不是整个数据映射到多维空间的一个独立的空间，可以缓解这一问题，在一定程度上。
该映射可以为节点提供更好的查询，但增加了集群协调的复杂性，因为这种情况下的数据将分散在多个独立的子空间中，每个子空间对应若干物理节点，数据更新必须考虑问题。
钝化的副本
一些应用程序有很强的随机阅读需求，这就要求所有的数据都存储在内存中。在这种情况下，它通常是超过两次将数据复制从掌握每一段的奴隶，因为每个数据在主节点和从节点的一部分，以取代主节点失败，从节点的内存大小应为主要节点相同。如果系统可以容忍短暂的中断或性能下降，当节点失效时，它也可以是不可分的。
下图描述了4个节点上的16个段，每个节点在内存中有一个部分，硬盘上存在一个副本。
灰色箭头突出在节点2上分段复制。其他节点上的片也复制。红色箭头描述了一个副本加载到内存时，节点2失败。集群中的副本分布均匀，能够储存活性份在只有少量的内存保留节点失败的情况，在上图中，集群仅保留1 / 3内存故障可以承受单一节点。特别指出复制激活（从硬盘加载到内存）需要一定的时间，这将导致短时间内性能下降或部分数据服务中断，恢复。
系统的协调
在本节中，我们将讨论这两种技术是系统协调相关。分布式协调是一个比较大的地区，许多人已经研究的深度几十年。在这篇文章中，只有两个实用技术有牵连。分布式锁、内容一致性协议，以及其他一些基本的技术可以在许多书籍或网络资源发现。
故障检测
故障检测与容错的分布式系统的基本功能。事实上，所有基于心跳故障检测协议的通信机制，原理很简单，部件定期发送心跳监测信息，监测过程（或通过监控组件监控轮询过程），如果有一段时间没有收到心跳信息被认为是失败的。另外，有一个真正的分布式系统的一些其他的功能要求。
self-adaptive.fault检测应该能够应付临时网络故障和延迟，以及集群的拓扑结构，改变负载和带宽。但这是非常困难的，因为没有办法知道长时间没有响应过程到底是不是一个真正的失败，因此，故障检测和故障识别的需要权衡的时间（需要多长时间来确定一个真正的失败，这是一个失去响应过程后多长时间会被认为是失败）和重量的误报率之间的权衡因素。这应该自动adjusted.flexibility.at第一眼，故障检测只需要输出一个布尔值，指示是否监测过程是工作或没有，但它不是E在实际应用中受。让我们看看MapReduce的参考实例看，有一个分布式应用程序由一个主节点和多个工作节点。主节点维护一个工作清单和分配工作列表中的工作节点，主节点可以区分不同程度的失败之间。如果主节点怀疑工作节点挂，他将不分配工作再到节点。其次，随着时间的推移，如果该节点心跳信息没有收到，主节点会重新分配工作运行在该节点到其他节点。最后，主节点确认节点失败和所有相关的资源被释放。可扩展性和鲁棒性。故障检测，作为一个系统的功能，应能与系统的扩大。他应该是强大的和一致的，那就是，即使在通信故障时，在系统中的所有节点阀杆应该具有一致的视图（即，所有节点都应该知道哪些节点不可用，这些节点是可用的，而不是冲突的，认知节点不能出现在节点A不可用的节点的一部分，而节点的其他部分不知道情况）
所谓的累积故障检测器可以解决第一个问题，卡桑德拉已经做了一些修改，并将其应用于产品的基本工作过程如下：
每个监测资源，检测器记录的心跳信息到达时间，计算了在统计预测范围到达时间的均值和方差。假定到达时间的分布是已知的（下图包括一个正态分布的公式），我们可以计算心跳延迟的概率（当前时间t_now最后到达时间TC之间的差异），并使用这个概率来判断是否有故障。对数函数可以用来调整以提高可用性。在这种情况下，输出1意味着判断错误的概率（节点失效）是10%，2是1%，等等。
根据不同程度的重要性，我们应按层次组织监测区域。该地区是谣言的通信协议或中央容错库同步，能够满足可扩展性的要求，防止心跳信息在网络中泛滥。如下图所示，6的故障检测器，形成两个地区，这是通过谣言传播协议或一个强大的图书馆像动物园管理员联系。
协调运动
协调活动是强一致性数据库的一项重要技术，其一是利用主从结构对系统中主节点的故障恢复进行组织，二是在网络隔离的情况下，将节点的少数部分断开，避免冲突。
欺负算法是一个相对简单的协调运动algorithm.mondb使用该算法来确定一个主要的副本集，欺负算法的主要思想是，集群中的每个成员可以声明它是协调并通知其他节点，其他节点可以选择接受这一索赔或拒绝进入协调员的竞争。节点的所有其他节点接受可以协调，节点判断谁应该赢根据某些属性，这个属性可以是一个静态的ID和可以衡量的更新像上次事务ID（最新的节点会赢）。
下面的示例演示了欺负算法的执行。使用静态ID作为度量，较大的ID节点将获胜：
在初始集群5个节点，而节点5是一个公认的协调员。假定节点5和节点2挂，3节点都在同一时间发现。两节点开始发送消息的ID。选节点4节点2节点的大了3，3消除节点2和节点。在这个时间节点1节点5发送选举失败的感知信息所有较大的ID的节点。节点2, 3，4节点1节点4全部消除。发送选举信息节点5，节点5没有响应，所以节点4宣布当选宣布这个消息其他节点。
协调活动将涉及的节点的数量，保证至少一半的集群中的节点参与竞选。这确保了只有一部分的节点可以在网络协调器选择的网络隔离（假设将网络划分为不同的区域，互不联通，选举结果的协调员将导致节点数量，面积相对较多的是课程协调员，前提是在可用的节点的面积比集群中的节点数为原来的一半，如果群集分离成若干块，没有一块比原来的节点，总人数更多的节点协调器不能E选择。当然，预计在这种情况下，集群可以继续提供服务。