如何在分布式系统上获得高频、一致的读/写？通常不确定如何在大型系统上概念化一致性。
用例：阻止用户在指定时间段内执行相同的操作。在滥用情况下，这可能是一种高频操作。
扩展问题：我将如何扩大此操作的规模？ Firestore 等系统如何在提供高可用性的同时提供一致性？ Firestore 配额（例如每秒 1 个文档写入）告诉我们他们可能是如何构建系统的？
谢谢
【问题讨论】：
标签： google-cloud-firestore distributed-computing consistency eventual-consistency cap-theorem
GCP 的 Firestore uses the same technology 作为 Cloud Spanner 以确保大规模的一致性。要了解有关 Cloud Spanner 及其 CAP 影响的更多信息，请查看the introduction here：
就 CAP 而言，Spanner 声称尽管在广泛的区域内运行 [...]，但仍具有一致性和高可用性。这是否意味着 Spanner 是 CAP 定义的 CA 系统？ [...] 最纯粹的答案是“不”，因为分区可能发生并且实际上已经发生在 Google，并且在某些分区期间，Spanner 选择 C 并放弃 A。从技术上讲，它是一个 CP 系统。然而，没有一个系统提供 100% 的可用性，所以实际的问题是 Spanner 是否提供了如此高的可用性，以至于大多数用户都不担心它的中断。
因此，虽然技术上是一个 CP 系统，但 Cloud Spanner（因此也是 Firestore）实际上是 CAP，因为它的“5 个或更多 9”可用性保证足够高让大多数用户忽略中断。
Firestore 等系统如何在提供高可用性的同时提供一致性？
首先，Google 为此类服务运行自己的全球私有网络，这意味着与依赖公共网络相比，它们能够提供更强大的保证。
其次，这些系统利用同步时钟来确保一致性。在 Google 的案例中，归结为 TrueTime，这是一种全球同步的、基于 GPS 和原子钟的时钟，即使对于发生在地球另一端的交易，也能提供强大的时间语义（7 毫秒的有界不确定性）。时钟使得用本地计算代替通信成为可能：节点 N 不再询问另一个节点 M 是否存在某些属性，而是可以根据过去关于 M 的一些信息以及 N 时钟上的当前时间来推断答案（Liskov91 )。
Cloud Spanner 依赖 TrueTime 生成单调递增的时间戳。 Cloud Spanner 以两种方式使用这些时间戳。首先，它将它们用作写入事务的适当时间戳，而不需要全局通信。其次，它将它们用作强读的时间戳，这使得强读能够在一轮通信中执行，甚至是跨多个服务器的强读。 source
有关时钟如何帮助分布式系统设计的更多理论，请参阅Liskov's paper here。有关 Cloud Spanner 的更多信息，我强烈推荐 the original Spanner paper 和 the follow-up paper 上的这些摘要。
更新：好消息是您不需要原子钟、GPS 和专用全球网络来确保一致性和高可用性。受 Spanner 启发的开源 CockroachDB 实现了与其前身大致相同的效果，尽管代替 TrueTime 强大的时间确定性，它必须依赖更粗粒度且效率更低的同步，如 this fantastic comparison 所述：
关于 Spanner 和 CockroachDB 之间对比的简单陈述是：Spanner 总是等待写入的时间间隔很短，而 CockroachDB 有时等待读取的时间间隔更长。
【讨论】：