一致性和共识算法(2)-一致性保证和线性一致性

110 阅读4分钟

携手创作,共同成长!这是我参与「掘金日新计划 · 8 月更文挑战」的第24天,点击查看活动详情

1 一致性保证

数据库复制中发生的一些时序问题。同一时刻查看两个数据库节点,则可能在两个节点上看到不同的数据,因为写请求在不同的时间到达不同的节点。无论数据库使用何种复制方法(单主复制,多主复制或无主复制),都会出现这些不一致。

大多数复制的数据库至少提供最终一致性,即若停止向DB写并等待一段不确定时间,则最终所有读取请求都会返回相同值。即不一致现象只是暂时,最终会达到一致。最终一致性意味着收敛(convergence),即预期所有副本最终会收敛到相同值。

但这是个很弱保证,不知何时系统收敛。收敛前,读可能会返回任何值甚至读失败。如若你写入了一个值,然后立即再次读取,这并不能保证你能看到刚才写入的值,因为读请求可能会被路由到其它副本。

对于SE,最终一致性很难,和普通的单线程程序中变量读写行为很不同,若将一个值赋给某变量,再很快读取,不可能读到旧的值或读取失败。而DB表面上看起来像个可读写的变量,其实有更复杂的语义。

和只提供弱保证DB打交道时,需始终意识其局限性。当系统故障(如网络中断)或高并发时,最终一致性的边缘情况才会凸显。

因此,本文探索数据系统更强的一致性模型,可能会比保证较差系统具有更差性能或更低容错性。但更强的保证能吸引人,因为它们不容易出错。熟悉不同的一致性模型,才能更好地决定最适合的。

分布式一致性模型和之前讨论的事务隔离级别的层次结构有相似。尽管两者有一部分内容重叠,但它们大多是无关问题:事务隔离主要是为避免由于同时执行事务而导致的竞争状态,而分布式一致性主要关于在面对延迟和故障时如何协调副本间的状态。

本文涵盖广泛话题,但这些领域实际上紧密联系:

  • 最强的一致性模型:线性一致性(linearizability)
  • 然后检查分布式系统中事件顺序问题,特别是因果关系和全局顺序
  • 最后探讨如何原子地提交分布式事务,最终引领我们走向共识问题的解决方案

2 线性一致性

最终一致性DB,若同时查询两个不同副本,可能得到两个不同答案,这让应用层困惑。若DB能提供只有一个副本的假象,就简单多了。那么每个客户端都会有相同的数据视图,且不必担心复制滞后了。

这就是线性一致性思想(也称为原子一致性、强一致性、立即一致性或 外部一致性)。线性一致性的精确定义相当微妙。其基本想法是让一个系统看起来好像只有一个数据副本,且所有操作都是原子的。有此保证,即使实际中可能有多个副本,应用也无需担心。

线性一致系统中,只要一个客户端成功完成写,所有客户端的读请求一定能能看到刚写入的值。这种看似单一副本的假象意味它能保证读取最近最新值,而非过期的缓存。即线性一致性是个就近保证。看个非线性系统案例:

图-1 这个系统是非线性一致的,导致球迷困惑Alice 和 Bob 坐在同一房间里,盯着各自手机,关注世界杯决赛结果。最后得分公布后,Alice 刷新页面,看到宣布获胜者,并告诉 Bob。Bob 难以置信地刷新了自己手机,但他的请求路由到了一个落后的数据库副本,手机显示比赛仍在进行。

若Alice、Bob几乎同时刷新页面并获得两个不同结果,他们不知道服务器处理他们请求的精确时刻。然而 Bob 是在听到 Alice 惊呼最后得分后,点击刷新按钮(启动了他的查询),因此他希望查询结果至少与爱丽丝一样新。但他的查询返回过期结果,违背了线性一致性。