作者
RobertoVitillo
译者
弯月，责编
屠敏
头图
CSDN下载自视觉中国
以下为译文：
想象一下，给变量赋值，然后立即读取，却发现刚刚的写入根本不起作用，是不是很抓狂？
x=42assert(x==42)#抛出异常
在使用一致性保证较弱的分布式数据存储时，就有可能遇到这种情况。你可能会问：“等等，难道数据库不是应该为我解决一致性的问题吗？”执行更新操作后，实际的数据会立即被更新还是需要等待一段时间，取决于数据库是否提供这种保证。
有些数据库提供的一致性保证有点违反直觉，但其目的是提供高可用性和高性能。还有一些数据库可以让你选择想要更好的性能还是更强的保证，例如Azure的CosmosDB和Cassandra。因此，你需要了解其中的利弊。
数据库请求剖析
下面我们来看看，当你将请求发送到数据库后，接下来会发生什么。在理想的情况下，你的请求会被立即执行：
但是，我们并非生活在理想世界中，你的请求需要送到数据存储，然后经过处理，最后再将响应发送给你。所有这些操作都需要一定的时间，无法在瞬间完成：
数据库可以提供的最佳保证是，在调用和完成之间的某个时间点上执行请求。你可能会认为这也没什么大不了，毕竟你在编写单线程应用程序时就习惯了这一点，例如将1赋给x，然后读取x的值，那么必然会得到1，当然前提是没有其他线程写入同一变量。然而，当你使用的数据存储为了实现高可用性和可伸缩性，将数据状态复制到多台计算机上，那么一切都变成了未知数。为了理解为什么会出现这种情况，我们来探讨一下在分布式数据库的简化模型中，系统设计师在实现读取的时候必须权衡的利弊。
假设我们有一个分布式键值存储，它由一组副本组成。副本之间会选出一个领导者，这是唯一可以接受写入的节点。在领导者收到写请求后，它会通过异步将数据写入到其他副本。尽管所有副本都以相同的顺序收到相同的更新，但是它们接收到的时间点不同。
你的任务是想出一种策略来处理读取请求，你该怎么办？你可以从领导者或其他副本中读取数据。如果所有读取都经由领导者，那么吞吐量就会成为瓶颈，无法超过单个节点可以处理的数据量。如果任何副本都可以服务请求读取，那么吞吐量就可以得到极大地提升，但这种情况下两个客户端（观察者）获取的系统状态就有可能不一致，因为领导者和副本之间以及各个副本之间可能出现延迟。
简单来说，我们需要在观察者看到的系统的一致性与系统的性能和高可用性之间进行权衡利弊。为了理解这种关系，我们需要准确地定义一致性。我们可以参考一致性模型（