数据一致性
对于数据库而言,事务的ACID这4个特性保证了一个事务的正确性。其中,一致性特征是指在事务开始之前和结束之后数据完整性不被破坏。对于集中式系统而言,实现数据的一致性是容易的,毕竟依赖于数据库自然就实现了ACID特征。然而,在分布式系统中,要想保证数据的一致性就没有那么简单了。
本章介绍分布式系统下的数据一致性概念及解决方案。
什么是CAP理论
ACID的应用场景是数据库事务,是针对并发事务对数据库数据一致性的保证。然而在分布式系统中,通过使用副本的方式来保证系统的可用性及扩展性,这势必会引入一个重要问题,那就是数据的复制。对数据进行复制一般是为了增强系统的可靠性和提升性能。举例来说,当一个数据库的副本被破坏以后,那么系统只需要转换到其他数据副本就能继续运行下去。另外一个例子,当访问单一服务器管理的数据的进程数不断增加时,系统就需要对服务器的数量进行扩充,此时,对服务器进行复制,随后让它们分担工作负载,就可以提升性能。但复制数据的同时也带来了一个难点,那就是如何保持各个副本数据的一致性。换句话说,更新其中任意一个副本时,必须确保同时更新其他副本,否则,数据的各个副本将不再相同(数据不一致)。CAP理论的出现,让我们对于分布式事务的一致性有了另外一种看法。
CAP理论(也称为Brewer定理)是由计算机科学家Eric Brewer在2000年提出的,其理论观点是,在分布式系统中不可能同时提供以下3个保证。
·一致性(Consistency):所有节点同一时间看到的是相同的数据。
·可用性(Availability):不管是否成功,确保每一个请求都能接收到响应。
·分区容错性(Partition Tolerance):系统任意分区后,当网络故障时,仍能操作。
CAP定理如图17-1所示。
图17-1 CAP定理
在2003年的时候,Gilbert和Lynch就正式证明了这3个特征确实是不可以兼得的。Gilbert认为这里所说的一致性其实就是数据库系统中提到的ACID的另一种表述。
·一个用户请求要么成功要么失败,不能处于中间状态(Atomic)。
·一旦一个事务完成,将来的所有事务都必须基于这个完成后的状态(Consistent)。
·未完成的事务不会互相影响(Isolated)。
·一旦一个事务完成,就是持久的(Durable)。
对于可用性,其概念没有变化,指的是对于一个系统而言,所有的请求都应该“成功”并且收到“返回”。分区容错性就是指分布式系统的容错性。节点崩溃或者网络分片都不应该导致一个分布式系统停止服务。
为什么CAP只能三选二
下面分别举例说明为什么说CAP只能三选二。
图17-2显示了在一个网络中,N1和N2两个节点,它们都共享数据块V,其中有一个值V0。运行在N1的A程序可以认为是安全的、无Bug、可预测的和可靠的。运行在N2的是B程序。在这个例子中,A将写入V的新值,而B从V中读取值。
图17-2 示例一
系统预期执行下面的操作,如图17-3所示。
·首先写一个V的新值V1。
·然后消息(M)从N1更新V的副本到N2。
·现在,从B读取返回的V1。
图17-3 示例二
如果网络是分区的,当N1到N2的消息不能传递时,执行图17-4中的第3步,会出现虽然N2能访问到V的值(可用性),但其实与N1的V的值已经不一致了(一致性)的情况。
图17-4 示例三
CAP常见模型
CAP理论已经证明了分区容错性、可用性、一致性三者不可能同时达成,在实际应用中,可以在其中的某一些方面来放松条件,从而达到妥协。下面是常见的3种模型。
牺牲分区容错性(CA模型)
牺牲分区容错性意味着把所有的机器搬到一台机器内部,或者放到一个“要死大家一起死”的机架上(当然机架也可能出现部分失效),这明显违背了我们希望的可伸缩性。
CA模型常见的例子。
·单站点数据库。
·集群数据库。
·LDAP。
·xFS文件系统。
实现方式如下。
·两阶段提交。
·缓存验证协议。
牺牲可用性(CP模型)
牺牲可用性意味着一旦系统中出现分区这样的错误,系统直接就停止服务。
CP模型常见的例子。
·分布式数据库。
·分布式锁定。·绝大部分协议。
实现方式如下。
·悲观锁。
·少数分区不可用。
牺牲一致性(AP模型)
AP模型常见的例子。
·Coda。
·Web缓存。
·DNS。
实现方式如下。
·到期/租赁。
·解决冲突。
·乐观锁。
本文给大家讲解的内容是分布式系统开发实战: 数据一致性,CAP常见模型
本文就是愿天堂没有BUG给大家分享的内容,大家有收获的话可以分享下,想学习更多的话可以到微信公众号里找我,我等你哦。