一致性问题
在分布式系统中,一致性(Consistency
,早期也叫 Agreement
)是指对于系统中的多个服务节点,给定一系列操作,在协议(往往通过某种共识算法) 保障下,试图使得它们对处理结果达成某种程度的一致。
存在的挑战
- 节点之间的网络通讯是不可靠的,包括任意延迟和内容故障;
- 节点的处理可能是错误的,甚至节点自身随时可能宕机;
- 同步调用会让系统变得不具备可扩展性。
一致性条件
- 可终止性(
Termination
) :一致的结果在有限时间内能完成; - 共识性(
Consensus
) :不同节点最终完成决策的结果应该相同; - 合法性(
Validity
) :决策的结果必须是其它进程提出的提案。
CAP原理
- 一致性(
Consistency
) - 可用性(
Availability
) - 分区容忍性(
Partition tolerance
)
CAP原理指的是,这三个要素最多只能同时实现两点,不可能三者兼顾
最终一致性(eventually consistent
)
对于一致性,可以分为从客户端和服务端两个不同的视角。从客户端来看,一致性主要指的是多并发访问时更新过的数据如何获取的问题。从服务端来看,则是更新如何复制分布到整个系统,以保证数据最终一致。
从客户端角度,多进程并发访问时,更新过的数据在不同进程如何获取的不同策略,决定了不同的一致性。对于关系型数据库,要求更新过的数据能被后续的访问都能看到,这是强一致性 。如果能容忍后续的部分或者全部访问不到,则是弱一致性 。 如果经过一段时间后要求能访问到更新后的数据,则是最终一致性。
最终一致性总会存在一个时刻,系统达到一致的状态
把故障(不响应) 的情况称为“非拜占庭错误”,恶意响应的情况称为“拜占庭错
误”(对应节点为拜占庭节点)
FLP不可能性原理
FLP 不可能原理:在网络可靠,存在节点失效(即便只有一个) 的最小化异步模型系统中,不存在一个可以解决一致性问题的确定性算法。
两阶段提交2PC
二阶段提交(
Two-phaseCommit
)是指,在计算机网络以及数据库领域内,为了使基于分布式系统架构下的所有节点在进行事务提交时保持一致性而设计的一种算法(Algorithm
)。通常,二阶段提交也被称为是一种协议(Protocol
))。在分布式系统中,每个节点虽然可以知晓自己的操作时成功或者失败,却无法知道其他节点的操作的成功或失败。当一个事务跨越多个节点时,为了保持事务的ACID
特性,需要引入一个作为协调者的组件来统一掌控所有节点(称作参与者)的操作结果并最终指示这些节点是否要把操作结果进行真正的提交(比如将更新后的数据写入磁盘等等)。因此,二阶段提交的算法思路可以概括为:参与者将操作成败通知协调者,再由协调者根据所有参与者的反馈情报决定各参与者是否要提交操作还是中止操作。
所谓的两个阶段是指:第一阶段:准备阶段(投票阶段)和第二阶段:提交阶段(执行阶段)。
两阶段提交和三阶段提交