paxos-simple_中文翻译_20.pdfVIP

1 简介 Paxos算法作为容错的分布式系统实现已经广泛的被认为是难理解的，这可能由于 之前的描述对于许多读者来说不容易读懂。实际上，它是最简单和最显而易见的分布式 算法之一。它实际上是一致性算法 “会议”算法的一种。在下个章节将展示这个一致性 算法无法避免的属性，而这些属性我们想让他满足的。最后的章节中通过构建一个状态 机取得一致性的分布式系统的简单程序，来解释完全的paxos算法，当然这个方法是众 所周知的，因为这个可能是最经常在分布式理论里提及的主题 【4 】。 2 一致性算法 2.1 问题 假设一个可以进行建议的进程的集合。一个一致性算法要保证在所有被建议的值中 只有一个单一的值可以被选定。如果没有值被建议，当然也就没有值被选定。如果一个 值已经被选定了，则这些进程应该能够了解到这个被选定的值. 一致的安全要求如下： 1. 仅仅一个被建议的值才可能被选定 2. 仅仅一个单一的值被选定 3. 一个进程不会去了解一个值，除非他已经被实际的选定了 我们将不尝试去详细说明精确的活性需求。无论如何，目标是确保一些被建议的值 最终被选定，并且如果一个值被选定了，然后一个进程最终能够学习到这个值。我们让 这三个一致性算法中的三个角色扮演三种代理人类型，建议者，同意者，学习者。在算 法实现中，一个单一的进行可能会扮演超过一种类型的代理人，但是，在这里我们并不 关心代理人到进程的映射。 假设代理人们能够通过发送消息彼此通信。 我们使用通常的异步的非拜占庭模型，即： 1.代理人以任意速度进行操作，也许中止后失败，也许重启。由于所有的代理人在 一个值被选定后也许失败，并且然后重启，所以如果一些信息不被一个失败的重启的代 理人记录下来的话，那么任何一个解决方法都是不可能的。 2消息可能花费任意长的时间去传输，也可能重复，丢失，但他们的内容会是正确 的。 2.2 选择一个值 选择一个值的最简单的方式是只有一个单独的同意者。一个建议者发送一个建议给 同意者，同意者会选定他所接收的第一个建议值。虽然简单，但这个解决方案不能令人 满意，因为这个同意者的故障会是使任何的更进一步的处理成为不可能。所以，让我们 尝试另一种选定值的方法。作为单一同意者的替代，让我们使用多个同意者代理人。一 个建议者发送一个建议值给一组同意者集合。一个同意者也许同意这个值。当同意者集 合中的足够多的成员同意了这个值，那么这个值就被选定了。多大才是足够大呢？为了 确保仅仅一个单一的值被选定，我们能够让代理人中的大多数组成这个足够大的同意者 集合。因为任意两个大多数集合至少有一个共公共的同意者，如果同意者最多只能同意 一个值的话，那么这个将是有效的。 (最初在 【3】中，有一个对 “大多数”显而易见 的概括，这个已经被众多的论文提及。) 在不会失败和消息丢失的情况下，我们想让一个值被选定，即使只有一个值被单一 一个建议者提出。这个表明了如下的要求： P1.一个同意者必须同意他接收到的第一个建议 但这个要求引发了一个问题。几个值能够被不同的建议者差不多同时建议，这个导 致了一种情况：每个同意者已经同意了一个值，但没有一个值是大多数的人同意。即使 对于仅仅两个建议值，如果每个都被差不多一半的同意者所同意，一个单一的同意者的 失败，会使知道那个值是被选定的成为不可能。P1 和 仅当被大多数同意者同意的值才 能被选定的要求，意味着一个同意者必须被允许同意超过一个建议。我们通过对每一个 建议分派一个自然数序号的方式来记录一个同意者可能同意的不同的建议，所以一个建 议包含一个建议序号和一个值。为了避免混淆，我们需要不同的建议有不同的序号。这 个如何做到，依赖于实现，以至于我们现在仅仅只能假设他。当一个携带着值的单一的 建议被大多数同意者同意时，这个值就被选定了。在这种情况下，我们认为这个建议（还 有他的值）被选定了。 我们能够允许多个建议被选定，但是我们必须保证这些所有被选定的建议有同样的 值。通过基于建议序号的归纳，这足够保证： P2.如果一个值v 的建议被选定，则每个被选定的更高序号的建议都有值v. 因为序号 是完全顺序的，条件p2保证了严格的安全属性，即仅一个单一的值被选定了。为了被选 定，一个建议必须被至少一个同意者同意。所以我们能够满足p2,通过满足： P2a 如果带有值v 的建议被选定，则每个被任意同意者同意的更高序号的建议拥有 值v. 我们一直维护着p1去确保一些建议被