一致性问题

一致性问题

在分布式系统中，一致性（Consistency，早期也叫Agreement）是指系统中多个服务节点对给定的一系列操作，在协议的保证下（往往通过某种共识算法），试图使它们一致 处理结果达到了一定程度的一致。

如果分布式系统能够做到“一致性”，就可以作为一个“虚拟处理节点”出现，功能正常，性能和稳定性会好很多。

例如，某影视公司在西单和中关村拥有两家电影院，均销售某张电影票，共有10000张票。 那么，当顾客到电影院买票时，售票员应该如何决定是否卖票，以免超售？ 电影院多了怎么办？

在人间，这个问题似乎并没有那么难。 你看，英国人不就是通过投票达成了“某种共识”吗？

注意：一致性不是指结果正确与否，而是系统呈现的状态是否一致。 比如所有节点都达到故障状态也是一种一致性。

挑战

在实际的计算机集群系统（看似强大的计算机系统，很多地方比人类世界要脆弱得多）中，存在以下问题：

为了解决这些挑战，愿意动脑筋的读者可能会很快想出一些好点子。

为了简化理解，我们还是以两家电影院一起卖票为例。 可能有以下解决方案：

这些想法大体上是可行的。 事实上，这些方法背后的思想是将可能导致不一致的并行操作序列化，这是处理计算机系统分布式一致性问题的基本思想和唯一秘诀。 只是因为计算机系统比较笨，需要综合考虑； 而人们希望计算机系统能够更快、更稳定地工作，因此需要将算法设计得更加精细。

要求

规范地说，理想的分布式系统一致性应该满足：

第一点很容易理解，这是可以使用计算机系统的前提。 应该注意的是，这在现实生活中并不总是得到保证。 比如ATM有时会处于“服务中断”状态比特币系统的一致性，电话有时会“无法接通”。

第二点看似简单，却隐藏了一些底层信息。 算法考虑了任何情况比特币系统的一致性，一旦把一切推广到任何情况，往往会出现一些惊人的结果。 比如现在只剩下一张票，而中关村和西单的电影院刚刚确认了这张票的存在，然后一个顾客同时来到两家电影院要买票。 第一个到达……我们如何才能就结果达成共识？ 记住我们唯一的秘诀：核心是两个东西需要排序，而且这个排序必须是大家一致同意的。

第三点看似啰嗦，其实更容易理解，即实现的结果一定是节点执行操作的结果。 还是以售票为例，如果两家影院各售出1000张票，那么结果就是还剩8000张票，不能算售罄。

约束一致性

做过分布式系统的读者应该知道，强一致性（Strong Consistency）的绝对理想是非常昂贵的。 除非没有故障，否则所有节点之间的通信不需要任何时间。 这时候，它其实就相当于一台机器。 事实上，更强的一致性要求往往意味着更弱的性能。

一般来说，强一致性主要包括以下两类：

目前，高精度石英钟的漂移率为

，人类最精确的原子振荡器时钟的漂移率为

. 谷歌在其分布式数据库Spanner中使用了基于原子钟和GPS的“TrueTime”方案，可以将不同数据中心的时间偏差控制在10ms以内。 该方案简单、粗暴、有效，但存在成本高的问题。

高度一致的系统通常难以实施。 很多时候，人们发现实际需求并没有那么强烈，可以适当放宽一致性要求，以降低系统实施的难度。 例如，在一定的约束条件下实现所谓的最终一致性（Eventual Consistency），即系统总会有一个时刻（而不是立即）达到一致状态，这对大多数Web系统来说已经足够了。 这种弱化的一致性一般称为弱一致性（Weak Consistency）。

难道分布式领域也存在不确定性原理？ 为什么这个世界上有这么多的限制？