数据一致性有哪几种？数据一致性详解

说说数据一致性有哪几种？

分析&回答

一般来说，数据一致性模型可以分为强一致性和弱一致性，强一致性也叫做线性一致性，除此以外，所有其他的一致性都是弱一致性的特殊情况。弱一致性根据不同的业务场景，又可以分解为更细分的模型，不同一致性模型又有不同的应用场景。

强一致性

当更新操作完成后，任何多个后续进行访问时都会返回最新的值，就是用户刚提交就能看到更新了的数据，这对用户是最友好的。但根据CAP理论，这势必也要牺牲可用性。

弱一致性

系统在写入数据成功后，不承诺立即能读到最新的值，也不承诺什么时候能读到，但是过一段时间之后用户可以看到更新后的值。那么用户读不到最新数据的这段时间被称为“不一致窗口时间”。 「最终一致性」 最终一致性作为弱一致性中的特例，强调的是所有数据副本，在经过一段时间的同步后，最终能够到达一致的状态，不需要实时保证系统数据的强一致性。

最终一致性

Base 理论中我们讲过：最终一致性要求系统中数据副本最终能够一致，而不需要实时保证数据副本一致。

最终一致性可以分为客户端和服务端两个不同的视角。

从客户端的角度看

从客户端来看，一致性主要指的是多并发访问时更新过的数据如何获取的问题，最终一致性有以下 4 个变种。

一致性变种 说明

因果一致性： 如果进程 A 通知进程 B 它已更新了一个数据项，那么，进程 B 的后续访问将返回更新后的值，且一次写入将保证取代前一次写入。与进程 A 无因果关系的进程 C 的访问遵守一般的最终一致性规则。

会话一致性： 这是上一个模型的实用版本，它把访问存储系统的进程放到会话的上下文中。只要会话还存在，系统就保证“读己之所写”一致性。如果由于某些失败情形令会话终止，就要建立新的会话，而且系统保证不会延续到新的会话。

单调读一致性： 如果进程已经看到过数据对象的某个值，那么任何后续访问都不会返回在那个值之前的值。

单调写一致性： 系统保证来自同一个进程的写操作顺序执行。

从服务器的角度看

从服务端来看，如何尽快地将更新后的数据分布到整个系统，降低达到最终一致性的时间窗口，是提高系统的可用度和用户体验度非常重要的方面。

分布式数据系统有以下特性：

N 为数据复制的份数。

W 为更新数据时需要进行写操作的节点数。

R 为读取数据的时候需要读取的节点数。

如果 W+R>N，写的节点和读的节点重叠，则是强一致性。例如，对于典型的一主一备同步复制的关系型数据库（N=2, W=2,R=1），则不管读的是主库还是备库的数据，都是一致的。

如果 W+R≤N，则是弱一致性。例如，对于一主一备异步复制的关系型数据库（N=2,W=1,R=1），如果读的是备库，则可能无法读取主库已经更新过的数据，所以是弱一致性。对于分布式系统，为了保证高可用性，一般设置 N≥3。设置不同的N、W、R 组合，是在可用性和一致性之间取一个平衡，以适应不同的应用场景。

如果N=W 且 R=1，则任何一个写节点失效，都会导致写失败，因此可用性会降低。但是由于数据分布的 N 个节点是同步写入的，因此可以保证强一致性。

如果 N=R 且 W=1，则只需要一个节点写入成功即可，写性能和可用性都比较高。但是读取其他节点的进程可能不能获取更新后的数据，因此是弱一致性。在这种情况下，如果 W＜(N+1)/2，并且写入的节点不重叠，则会存在写冲突。

数据一致性详解

数据一致性介绍

如今对于一家企业特别是互联网企业来说，应用系统的数量和复杂度远高于以前。为了降低企业使用系统的成本，业界摸索出一套完整的解决方案，使得应用系统不依赖于昂贵的小型机，且能够保证高并发高可用、数据一致性以及可靠性需求的分布式系统。作为分布式系统的核心之一，数据一致性是分布式系统绕不开的话题，下面我们将详细介绍分布式系统在数据一致性的知识。对于分布式系统来说，数据一致性有的两种理解：事务数据一致性，即传统事务中所说的一致性（C）是指一个事务完成后数据是处于一种一致状态。最常见的就是转账，从一个账户转移到一个新的账户，两个账户的总额应该不变的，如果你有兴趣，可以了解一下财务方面的复式记账的知识，能够加深对事务一致性的理解。传统一致性属于ACID范畴，在分布式系统中，通过分布式事务实现；副本数据一致性，即分布式系统CAP理论中的一致性；

关于什么是事务等一系列话题已经是老生常谈谈了，本文就不再赘述，仅将事务的ACID原则罗列如下，便于各位参考。事务ACID原则： 原子性、一致性、独立性、持久性。

A（Atomicity）原子性

原子性即事务里的所有操作要么都成功，要么都失败。

C（Consistency）一致性

一致性也比较容易理解，也就是说数据要一直处于一致的状态，事务的运行不会改变数据原本的一致性约束。例如现有完整性约束a + b = 10，如果一个事务改变了a，那么必须得改变b，使得事务结束后依然满足a + b = 10，否则事务失败。或者serviceA 减少了10，者serviceB相应的增加了10。或者同一个变量，在并发情况下，不会出现更新丢失的情况。

I（Isolation）独立性（隔离性）

所谓的独立性是指并发（多个用户同时操作）的事务之间不会互相影响，如果一个事务要访问的数据正在被另外一个事务修改，只要另外一个事务未提交，它所访问的数据就不受未提交事务的影响。

比如现有有个交易是从A账户转100元至B账户，在这个交易还未完成的情况下，如果此时B查询自己的账户，是看不到新增加的100元的。

D（Durability）持久性

持久性是指一旦事务提交后，它所做的修改将会永久的保存在数据库上，即使出现宕机也不会丢失。

在分布式系统中副本数据一致性是指，所有副本之间的数据状态是相同的。也就是说，所有的副本在任何时刻都应该具有相同的值。数据一致性是分布式系统中非常重要的一个概念，因为在分布式系统中，数据可能被同时写入多个节点，也可能被同时读取多个节点，因此必须确保所有节点上的数据是同步的。

副本数据一致性被分为五个级别，分别是：

强一致性（strong consistency）：任何时刻任何用户或节点都可以读到最近一次成功更新的副本数据。强一致性是程度最高的一致性要求；单调一致性（monotonic consistency）：任何时刻，任何用户一旦读到某个数据在某次更新后的值，这个用户不会再读到比这个值更旧的值。单调一致性是弱于强一致性却非常实用的一种一致性级别。因为通常来说，用户只关心从己方视角观察到的一致性，而不会关注其他用户的一致性情况。会话一致性session consistency）：任何用户在某一次会话内一旦读到某个数据在某次更新后的值，这个用户在这次会话过程中不会再读到比这个值更旧的值。会话一致性通过引入会话的概念，在单调一致性的基础上进一步放松约束，会话一致性只保证单个用户单次会话内数据的单调修改，对于不同用户间的一致性和同一用户不同会话间的一致性没有保障。实践中有许多机制正好对应会话的概念，例如PHP中的session概念。最终一致性（eventual consistency）：最终一致性要求一旦更新成功，各个副本上的数据最终将达到完全一致的状态，但达到完全一致状态所需要的时间不能保障。对于最终一致性系统而言，一个用户只要始终读取某一个副本的数据，则可以实现类似单调一致性的效果，但一旦用户更换读取的副本，则无法保障任何一致性。弱一致性（week consistency）：一旦某个更新成功，用户无法在一个确定时间内读到这次更新的值，且即使在某个副本上读到了新的值，也不能保证在其他副本上可以读到新的值。弱一致性系统一般很难在实际中使用，使用弱一致性系统需要应用方做更多的工作从而使得系统可用。

实现数据副本一致性的方案

为了实现副本一致性，业界做了许多尝试，曾经涌现许许多多的优秀解决方案，并且在某些场景下，很好的满足了用户的需求，比如主从异步复制、多数派读写、PAXOS、RAFT等。

接下来本文将介绍实现数据副本一致性的解决方案，包括PAXOS、RAFT和BASE理论。

最终一致性投票算法--Quorum

在讲PAXOS和RAFT算法之前，我们先了解一下Quorum机制，它是PAXOS和RAFT算法的基础。在分布式系统中，Quorum是指节点集合中必须满足的最小响应数或者最小节点数。Quorum通常用于实现一些分布式算法，比如分布式共识算法，保证在多个节点之间达成一致的状态。

在分布式系统中，Quorum通常用于以下两种场景：数据读取：在一个分布式系统中，数据通常会被复制到多个节点上。当一个客户端想要读取某个数据时，需要从某些节点中获取数据。由于分布式系统中可能存在网络分区、节点宕机等问题，因此需要在多个节点中选择一个Quorum（即满足最小响应数）来获取数据，保证数据的一致性。数据写入：当一个客户端想要写入数据时，需要在多个节点中进行数据复制，以保证数据的可靠性。在这种情况下，需要选择一个Quorum（即满足最小节点数）来进行数据复制，以确保数据被写入足够数量的节点中。

Quorum的选择通常是基于多数派原则，即如果一个节点集合中有N个节点，那么Quorum通常选择N/2+1个节点。这样可以保证当且仅当大多数节点达成一致意见时，分布式系统才能达成一致的状态。在分布式共识算法中，Quorum通常用于确保多个节点之间达成一致的状态。比如在Paxos算法中，需要选择一个Quorum来决定是否接受一个提案。如果有足够数量的节点接受了提案，那么提案就会被认为是被“批准”了，从而达成了共识。

副本数据强一致算法--PAXOS

Paxos 是分布式系统中著名的一致性协议，用于在不可靠的网络环境下，保证多个节点之间达成一致的状态。Paxos 协议的核心思想是使用消息传递机制，在多个节点之间进行投票和协商，以达成一致的决策结果。

Paxos 协议中，有三种角色：提议者（Proposer）、接受者（Acceptor）和学习者（Learner）。提议者负责向接受者发起提案（Proposal），接受者负责接收提案并投票决定是否接受提案，学习者则负责学习最终达成的一致性决策。

Paxos 协议保证了在任何时候只有一个提议者可以提交提案，同时保证了在多个节点之间达成一致的状态。Paxos 协议的核心思想被广泛应用于许多分布式系统的实现，比如分布式数据库、分布式锁、分布式共识等方面。

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。