什么是数据库一致性状态(什么是数据库一致性检索)

作者|罗伯托·维蒂洛

译者|新月|编辑|屠敏

头部| CSDN下载自视觉中国

| csdn (ID: csdnnews)

以下是翻译:

想象一下，给一个变量赋值，然后马上读取，却发现刚刚写的根本不行。是不是很疯狂？

x = 42 asset(x = = 42)#抛出异常当使用具有弱一致性保证的分布式数据存储时，可能会发生这种情况。您可能会问，“等等，数据库不是应该为我解决一致性问题吗？”在更新操作之后，实际数据是立即更新还是等待一段时间，取决于数据库是否提供这种保证。

一些数据库提供的一致性保证有点违反直觉，但其目的是提供高可用性和高性能。还有一些数据库可以让你选择是想要更好的性能还是更强的保障，比如Azure的Cosmos DB和Cassandra。所以，你需要知道利弊。

数据库请求分析让我们来看看当您向数据库发送请求时接下来会发生什么。在理想情况下，你的请求会被立即执行:

然而，我们并不是生活在一个理想的世界里。您的请求需要发送到数据存储，然后进行处理，最后将响应发送给您。所有这些操作都需要一定的时间，不可能在一瞬间完成:

数据库能够提供的最好保证是在调用和完成之间的某个时间点执行请求。你可能认为这没什么大不了的。毕竟在编写单线程应用程序时，你已经习惯了这一点。比如给X赋值1，然后读取X的值，必然会得到1，前提是没有其他线程写同一个变量。然而，当您使用的数据存储为了实现高可用性和可伸缩性而将数据状态复制到多台计算机时，一切都变得未知。为了理解为什么会出现这种情况，让我们讨论一下系统设计者在分布式数据库的简化模型中实现读取时必须权衡的优缺点。

假设我们有一个分布式键值存储，它由一组副本组成。将在副本之间选择一个领导者，这是唯一可以接受写入的节点。领导者收到写入请求后，会将数据异步写入其他副本。尽管所有副本以相同的顺序接收相同的更新，但它们接收的时间点不同。

您的任务是提出一个策略来处理读取请求。你该怎么办？你可以从领导或其他副本中读取数据。如果所有读取都通过领导者，吞吐量将成为瓶颈，不能超过单个节点可以处理的数据量。如果服务请求可以读取任何副本，那么吞吐量可以大大提高，但在这种情况下，两个客户端(观察者)获得的系统状态可能不一致，因为leader和副本之间以及每个副本之间可能存在延迟。

简单来说，我们需要权衡观察者看到的系统的一致性与系统的性能和高可用性之间的优劣。为了理解这种关系，我们需要准确地定义一致性。我们可以参考一致性模型(https://jepsen.io/consistency)，它定义了系统状态观察者可能经历的系统状态视图。

强一致性如果客户端的读写操作只能发送给领导者，那么似乎每个请求都是在特定的时间点以原子的方式进行的，好像只有一个数据副本。不管有多少份，也不管每份多晚，只要客户直接查询领导，那么从他们的角度来说，只有一份数据副本。

因为请求不会立即得到服务，并且只有一个节点提供服务，所以请求必须在调用和完成期间执行。另一种思路是，请求完成后，所有观察者都能看到它的副作用:

由于在呼叫和请求完成之间，其他参与者可以看到请求，因此必须保证实时性能。这种保证有一个理论上的一致性模型，叫做线性一致性，也叫强一致性。线性一致性是系统可以为单个对象请求提供的最强一致性。

如果客户端向leader发送读取请求，但是请求到达时leader已经被废除，但是收到请求的服务器认为自己还是leader怎么办？如果是上一任领导处理请求，就无法保证系统的强一致性。为了防止这一点，这个假设的领导者首先需要接触大多数副本，以确认他是否仍然是领导者。只有当它仍然是领导者时，它才能执行请求并将响应发送回客户端。这个过程会大大增加阅读所需的时间。

一致性到此为止。我们讨论了领导按顺序处理阅读的做法。然而，这种方法会产生瓶颈，从而限制系统的吞吐量。最重要的是，领导还需要接触大部分的文案来处理阅读。为了提高读取性能，我们应该允许副本处理请求。

虽然副本将落后于前导码，但它接收更新的顺序与前导码相同。如果客户端A仅查询副本1，客户端B仅查询副本2，这两个客户端将在不同的时间点看到不同的状态，因为副本没有完全同步:

在这个一致性模型中，对于所有的观察者来说，操作的顺序都是一样的，但是当操作的副作用会被观察者看到的时候，这个模型就不能提供任何实时的保证了。这种模式被称为顺序一致性。顺序一致性和线性一致性的区别在于前者缺乏实时性保证。

该模型的一个简单应用是与队列同步的生产者/消费者系统:生产者节点负责写入队列，而消费者负责读取。生产者和消费者看到的队列项顺序相同，但消费者落后于生产者。

最终的一致性尽管我们设法提高了读取吞吐量，但我们不得不将客户端修复到拷贝。这时候复制失败了怎么办？为了提高存储的可用性，我们可以通过允许客户端查询任何副本。但是，从一致性来说，这一步需要付出很高的代价。假设有两个副本1和2，其中副本2落后于副本1。如果客户端查询副本2，然后查询副本1，它将看到过去的状态，这可能会非常混乱。客户端拥有的唯一保证是，如果系统的写入停止，所有副本将最终收敛到最终状态。这种一致性模型被称为最终一致性。

在最终一致的数据存储之上构建应用程序是非常困难的，因为它的行为不同于您习惯的编写单线程应用程序的行为。任何一个小的错误都可能逐渐扩散，很难调试和重现。但是，并不是所有的应用都需要线性一致性，所以最终的一致性也是有用的。您需要做出明智的选择，并仔细考虑您的数据存储提供的保证是否能够满足您的应用程序的需求。如果你想记录网站的访问量，那么最终的一致性会是你的首选，因为阅读返回的数字是否有些过时并不重要。但是对于支付系统来说，强一致性是绝对不可或缺的。

除了本文介绍的模型外，PACELC定理还有许多一致性模型。但背后的基本思想是一样的:一致性保证越强，单次操作等待时间越长，失败时存储的可用性越低。这种关系也被称为PACELC定理:当在分布式计算机系统中进行分区(P)时，我们必须在可用性(A)和一致性(C)之间进行选择，否则(Else，E)即使系统没有任何分区，我们也必须保持延迟(L)和一致性(C)

原文:https://robertovittillo . com/what-every-every-developer-should-know-about-database-consistency/

这篇文章是CSDN翻译的。转载请注明出处。