分布式系统一致性问题:CAP 和 BASE 原理

1,530 阅读4分钟

前言

小结一下分布式系统一致性问题。

CAP

先来介绍几个名词:

  1. Consistent(一致性)

    应用需要保证线性一致性

  2. Availability(可用性)

    非故障的节点在合理的时间内返回合理的响应(不是错误和超时的响应)

  3. Partition-Tolerance(分区容错性)

    网络分区时系统能够继续运行

请注意线性一致性这个名词,线性一致性的要求是:

一个系统看起来好像只有一个数据副本。一旦新的值被写入或读取,所有后续的读都会看到写入的值,直到它被再次覆盖。

即系统能保障读到的值是最新的。

考虑如下的一种情况:

首先看上面的图,如果是多主数据库(不考虑多主同时写入异步复制冲突问题)如图中的四个客户端在数据同步网络中断的情况下依然可以访问应用,此处假设应用程序的设计使得用户可以被正确的路由到对应的数据中心,但数据中心之间无法互相连接。由于在一个数据中心写入的数据是异步复制到另一个数据中心的,所以在恢复网络连接时,写入操作只是简单地排队并交换。

但是,对于单主数据库的情况,就没那么美好了。依然是上图,我们理解为主从同步模式。任何写入和线性一致的读请求都会被强制走主库。即连接数据中心 B 的客户端必须将写入操作转发至数据中心 A。此时,客户端的请求无法完成写入操作,虽然可以读取,但可能不是新鲜的数据。因此,这种模式网络中断迫使在线性一致性和可用性之间做出选择。

这个问题不仅仅是单主复制和多主复制的后果,任何不可靠的网络上,即使在同一个数据中心也存在这个问题。

泛化的说这是一个多数据副本在线性一致性和可用性之间做出选择的问题,而它们的面临的问题权衡如下:

  • 如果应用需要保证(线性一致性)强一致性,且某些副本因为网络原因和其它副本断开连接,那么这些副本掉线后无法处理请求,必须等待网络恢复。

  • 如果应用不需要保证线性一致性,且某些副本因为网络原因和其它副本断开连接,那么它们依然可以处理请求(比如多主复制)。此时,应用仍然是可用的。

CP 在网络分区下一致但不可用AP 在网络分区下可用但不一致。因此不需要线性一致性的应用对网络问题有更强的容错能力。这种见解通常被称为CAP定理。更好的表述为:在分区时要么选择一致,要么选择可用。由于CAP最初是做为一个经验法则提出的。所以我们就不用纠结有没有CA这种问题,因为这个设想是默认P必选的。

CAP 定理的正式定义仅限于很狭隘的范围,它只考虑了一个一致性模型(即线性一致性)和一种故障(网络分区,或活跃但彼此断开的节点)。它没有讨论任何关于网络延迟,死亡节点或其他权衡的事。 因此,尽管 CAP 在历史上有一些影响力,但对于设计系统而言并没有实际价值。

BASE

由于现在大规模的系统都是分布式节点,我们自然不能容忍服务不可用。在一定程度上放弃对线性一致性的执着,可以带来更好的系统设计体验。因此,BASE理论也就是一种偏向于程序设计的指导理论。

同样先来介绍几个名词:

  1. Basically Available(基本可用)

    允许损失部分可用性,但核心功能可用

  2. Soft State(软状态)

    允许系统存在中间状态,而该中间状态不会影响系统整体可用性

  3. Eventual Consistency(最终一致性)

    系统中的所有数据副本经过一定时间后,最终能够达到一致的状态

同样,这几点也非常好理解。常见的高负载系统基本可用的做法一般为服务降级,响应时间增长,最主要的是核心功能一定可用。软状态在支付系统中的体现为,处于一种中间状态。等待其它副本返回的终态完成最终一致性。

后语

基本可用和最终一致性符合大部分互联网公司的业务模型,也为系统的柔/弹性设计提供了机会。

参考资源