了解分布式系统中的一致性

Question

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

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

扩展问题:如何扩展此操作？像Firestore这样的系统如何在提供一致性的同时提供高可用性？Firestore配额(例如每秒1个文档写入)告诉我们他们可能是如何构建系统的？

谢谢

Answer 1

GCP的Firestore uses the same technology作为云扳手，以确保规模上的一致性。要了解有关云扳手及其CAP含义的更多信息，请查看the introduction here

在CAP方面，扳手声称是一致的和高度可用的，尽管操作范围很广……这是否意味着扳手是CAP定义的CA系统？纯粹主义者的回答是“不”，因为分区可能会发生，而且实际上已经在Google发生了，在某些分区期间，Spanner选择了C并放弃了A。从技术上讲，它是一个CP系统。然而，没有一个系统提供100%的可用性，所以实用的问题是Spanner是否提供了如此高的可用性，以至于大多数用户都不担心它的停机。

因此，虽然从技术上讲是CP系统，但Cloud Spanner (以及Firestore)实际上是CAP，因为它的"5个或更多个9“可用性保证足够高，足以让大多数用户忽略停机。

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

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

其次，这些系统利用同步时钟来确保一致性。在谷歌的案例中，这归结为TrueTime，这是一个全球同步的全球定位系统和基于原子钟的时钟，它提供了强大的时间语义(7ms的有界不确定性)，即使是发生在地球两端的交易也是如此。时钟使得用本地计算代替通信成为可能:代替节点N询问另一个节点M是否具有某些属性，它可以根据过去关于M的一些信息以及N的时钟上的当前时间(Liskov91)来推断答案。

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

有关时钟如何帮助分布式系统设计的更多理论，请参阅Liskov's paper here。关于云扳手的更多信息，我强烈推荐在the original Spanner paper和the follow-up paper上的这些摘要。

更新：好消息是，您不需要原子钟、全球定位系统和专用全球网络来确保一致性和高可用性。受扳手启发的开源CockroachDB实现了与其前身相同的功能，尽管它必须依赖于this fantastic comparison中概述的更粗粒度和效率更低的同步，而不是TrueTime强大的时间确定性：

与CockroachDB之间对比的一个简单陈述是: Spanner始终等待写入的时间间隔较短，而CockroachDB有时等待读取的时间间隔较长。