4

如何在分布式系统上获得高频、一致的读/写？通常不确定如何在大型系统上概念化一致性。

用例：防止用户在指定时间段内执行相同的操作。在滥用情况下，这可能是高频操作。

扩展问题：我将如何扩大此操作？Firestore 等系统如何在提供高可用性的同时提供一致性？Firestore 配额（例如每秒 1 个文档写入）告诉我们他们可能是如何构建系统的？

谢谢

4

1 回答 1

2

GCP 的 Firestore使用与Cloud Spanner 相同的技术来确保大规模的一致性。要了解有关 Cloud Spanner 及其 CAP 影响的更多信息，请查看此处的介绍：

就 CAP 而言，Spanner 声称尽管在广泛的区域内运行，但它既一致又高度可用 [...]。这是否意味着 Spanner 是 CAP 定义的 CA 系统？[...] 最纯粹的答案是“不”，因为分区可能发生并且实际上已经发生在 Google，并且在某些分区期间，Spanner 选择 C ​​并放弃 A。从技术上讲，它是一个 CP 系统。然而，没有一个系统提供 100% 的可用性，所以实际的问题是 Spanner 是否提供了如此高的可用性，以至于大多数用户都不担心它的中断。

因此，虽然从技术上讲是一个 CP 系统，但 Cloud Spanner（以及 Firestore）实际上是CAP，因为它的“5 个或更多 9”可用性保证足以让大多数用户忽略中断。

Firestore 等系统如何在提供高可用性的同时提供一致性？

首先，谷歌为此类服务运行自己的私有全球网络，这意味着它们能够提供更强大的保证，而不是依赖公共网络。

其次，这些系统利用同步时钟来确保一致性。在 Google 的案例中，归结为 TrueTime，这是一种全球同步的、基于 GPS 和原子钟的时钟，即使对于发生在地球另一端的交易，也能提供强大的时间语义（7 毫秒的有界不确定性）。时钟使得用本地计算取代通信成为可能：节点 N 无需询问另一个节点 M 是否存在某些属性，而是可以根据过去关于 M 的一些信息以及 N 时钟上的当前时间来推断答案（Liskov91）。

Cloud Spanner 依赖 TrueTime 生成单调递增的时间戳。Cloud Spanner 以两种方式使用这些时间戳。首先，它将它们用作写入事务的适当时间戳，而不需要全局通信。其次，它将它们用作强读的时间戳，这使得强读能够在一轮通信中执行，甚至是跨多台服务器的强读。资源

有关时钟如何帮助分布式系统设计的更多理论，请参阅Liskov 的论文。有关 Cloud Spanner 的更多信息，我强烈推荐原始 Spanner 论文以及后续论文中的这些摘要。

更新：好消息是您不需要原子钟、GPS 和专用全球网络来确保一致性和高可用性。受 Spanner 启发的开源 CockroachDB 实现了与其前身大致相同的效果，尽管代替 TrueTime 强大的时间确定性，它必须依赖更粗粒度且效率更低的同步，如以下精彩比较中所述：

Spanner 和 CockroachDB 之间对比的一个简单陈述是：Spanner 总是等待写入的时间间隔很短，而 CockroachDB 有时等待读取的时间间隔更长。

于 2019-08-09T17:36:24.847 回答