Getting consensus for data replication: technical perspective

云计算系统中的数据应该具有高 可用性。换言之,无论你何时接入 系统,你在系统中保存的数据都应 随时可用。实现该功能的标准机 制——数据复制——需要维护每个 用户数据的多个副本。 复制数据本身并不能解决问 题,因为可用的数据副本可能是过 期的。具体的解释如下,假设系 统维护了文件 x 的三个副本:x1, x2,和 x3。假设 x1 和 x2 当前可用, 而 x3 不可用。如果程序更新 x,则 系统会把新值写入 x1 和 x2,但由于 x3 不可用,所以无法更新 x3。这不 会引发问题,因为系统仍然有两个 正确的副本。接下来,假设 x1 和 x2 发生故障,然后 x3 得以恢复。现 在,问题出现了。如果用户读取 x, 系统能提供的最佳结果是返回 x3 的 值。但是该副本是过期的——它没 有包含最近的更新值。 针对这一问题,早期的解决方 案为多数一致。 处理 x 的写入操 作时,系统会分配一个单调递增 的时间戳,然后在 x 的多数副本中 写入 x 的值和时间戳。处理 x 的读 取操作时,系统会读取 x 的多数副 本,然后返回具有最大时间戳的 值。由于任意两个多数副本的交 集至少会包含一个副本,所以每 次读操作能够返回之前在该数据 上写入的值。 在上文的例子中,读取操作只 读取了一个副本,并非三个副本中 的多数。因此,可能无法返回 x 的 最新状态。如果使用了多数一致, 系统就不得不等待第二个副本变为 可用,这样才能读够两个副本。接 下来,它会返回在读到的两个副本 中更接近当前时间的副本,因为该 副本的值必定是最新的。 Gifford 把多数的概念扩展为 加权多数,并将其称之为仲裁。每 个副本都会被赋予权重。读取操作 必须访问达到读取仲裁的副本—— 副本集合的权重至少达到 R。而写 操作则必须更新达到写入仲裁的副 本——副本集合的权重至少达到 W。设定 R+W 必须超过所有副本 的总权重 N 后,我们可以确保每次 读取均能读到在最近一次写入操作 中写入的值。 例如,设系统保存了 x 的四个 副本,即 x1-x4。我们可以把 x1 和 x2 的权重设为 1;若 x3 和 x4 位于更 可靠的服务器中,则把 x3 和 x4 的 权重设为 2。这样得到 N=6。如果 读取比写入更频繁,那么我们可以 设 R=3,W=4,这样读取执行的任 务会比写入少。因为 R+W>N,所 以每次读取均能读到之前在该数据 上写入的值。 按理说,每次写入操作都必须 更新数据的所有可用副本。但是, 读者也必须读多个副本,这颇为麻 烦,因为它增加了开销和延迟。如 果写入操作经常执行很快,这会特 别棘手,因为在这种情况下,即使 每次读取操作没有读取仲裁, 也极 有可能读到最新的副本。如果读到 过期数据的概率足够低,那么让读 者读取少于仲裁数量的副本或许是 可取的。实际上,某些云应用也正 是这么做的。 直到最近,这种通过猜测实现 的折中方法才有所改观。原来对于 读到的数据的过期性或承受某些过 期风险后可期望获得的延迟减少缺 乏界定。后面的论文阐述了一项突 破性进展,它抛开了猜测,用名为 概率有界过期性的原理分析取而代 之。给定 R、W 和 N,论文的作者 提出了一个公式用于计算读到的数 据不属于最近 K 次写入值之一的概 率。为了计算读到的数据不是在最 近Δ时间单位内写入的值的概率, 他们使用了基于时间参数的蒙特卡 罗模拟,且这些参数可以在运行的 系统中通过测量得出。不仅如此, 他们基于开源记录管理器实现了该 机制,让这种分析变得切实可行, 使得用户可以依据自己的判断对过 期性和延迟进行权衡。而原先的猜 测工作现在也变成了人们可以精心 策划的目标。