分布式一致性原理
分布式一致性问题通常存在于分布式文件系统、缓存系统和数据库等大型存储系统中。
分布式系统另外一个要解决的问题是数据的复制,原因在于:一是提高系统的可用性,防止单点故障引起的系统宕机;二是提升系统性能,通过负载均衡技术,让分布在不同地方的数据副本能均衡提供服务。
分布式一致性问题简单讲,即在分布式环境中引入数据复制机制后,不同数据节点中可能出现的数据不一致问题。也就是对一个副本数据进行更新时,必须保证其他副本也能顺利更新。
强一致性:可以理解为任意时刻节点中的数据都是一致的,此情形用户体验最好,但往往对系统的性能影响最大。
弱一致性:不保证多长时间后数据能达到一致,但会尽可能在某个时间级(如秒级别)后数据达到一致。弱一致性还可以分为:
会话一致性:只保证对于写入的值,同一客户端会话中可以立即读到一致的值,其他会话不能保证。
用户一致性:只保证对于写入的值,同一用户可以立即读到一致的值,其他会话不能保证。
最终一致性:它是弱一致性的一个特例,系统会保证在一定时间内,能够达到数据一致的状态。是目前常用的一致性解决方案。
分布式系统:一个硬件或软件组件分布在不同的网络计算机中,彼此之间通过消息传递进行通信和协调工作。
它的几个特征:
分布性: 多台计算机在空间上任意分布
对等性:分布式系统中计算机无主从之分,即没有控制整个系统的主机,也没有被控制的从机,所有计算机节点都是对等的。副本是分布式系统对数据和服务提供的一种冗余方式,数据副本指不同节点持久化同一份数据,当某节点数据丢失时,可以从副本读取该数据。服务副本是指多个节点提供同样的服务,每个节点都有能力接收外部请求并处理请求。
并发性:例如同一个分布式系统的多个节点可能并发地操作一些共享资源,如数据库或分布式存储等。如何高效地协调分布式并发操作也是分布式系统设计要考虑的问题之一。
分布式系统常见各种问题
通信异常:网络因素或通讯时延引起的问题,因此消息丢失和延迟的问题容易出现。
网络分区:当网络异常时,部分节点之间时延越来越大,最终导致只有部分节点能正常通信,形成网络分区现象,系统会出现局部小集群。
三态:分布式系统的每一次响应可能的结果成功、失败、超时。当出现超时时,通常有以下两类情况:一是消息并没有发出去,在发送途中丢失;二是消息成功发送,但反馈响应丢失。
节点故障:组成分布式系统的某一节点出现故障导致不能正常运行。
分布式系统事务处理和数据一致性的挑战
事务的ACID特性
事务(Transaction)是指一系列对数据的访问与更新操作所组成的程序执行逻辑单元,狭义上指数据库事务。一方面多个应用程序并发访问数据库时,事务可以在这些应用程序中提供一个隔离方法,防止彼此相互干扰;另一方面,事务为数据库操作序列提供了一个从失败恢复到正常状态的方法。
事务的ACID特性:原子性(Atomicity),一致性(Consistency),隔离性(Isolation),持久性(Durability)。
原子性:事务必须是一个原子的操作序列单元,其包含的各项操作要么全部成功,要么全部失败。任何一项操作失败将导致事务的失败,同时其他已成功执行的操作将被撤销、回滚。
一致性:事务的执行不能破坏数据库数据的完整性和一致性,一个事务在执行之后数据库的状态从一个一致性状态转到另一个一致性状态。
隔离性:并发环境中,并发的事务是相互隔离的,一个事务的执行不能被另一个事务干扰。即使不同事务并发操作相同数据,每个事务都有各自完整的数据空间。现有sql规范定义的四种事务隔离级别:未授权读取,授权读取,可重复读取,串行化。
隔离级别
脏读
可重复读
幻读
未授权读取
Y
N
Y
授权读取
N
N
Y
可重复读取
N
Y
Y
串行化
N
Y
N
持久性:事务一旦提交,它对数据的变更就应该是永久性的,即使系统出现故障,也能恢复到事务成功时的状态。
分布式事务
分布式事务是指事务的参与者、支持事务的服务器、资源服务器以及事务管理器分别位于分布式系统的不同节点上。通常一个分布式事务中会涉及对多个数据源或业务系统的操作。
一个分布式事务可看作是多个分布式操作序列组成,通常将这一系列的分布式操作称为子事务。
对于高访问量、高并发的互联网分布式系统来说,容易在系统的一致性和可用性之间出现冲突。如何兼顾可用性和一致性是构建一个分布式系统必须考虑的难题。
CAP定理:一个分布式系统不可能同时满足一致性(C:Consistency)、可用性(A:Availability)、分区容错性(P:Partition tolerance)这三个基本需求,最多只能同时满足其中两项。
一致性:是指数据在多个副本之间能否保持一致。对于一个将数据副本分布在不同节点的系统来说,如果第一个节点数据更新后,对第二个节点执行读操作,那么获得的数据是老数据,如此则出现数据不一致问题。
可用性:是指系统提供的服务必须一直处于可用的状态,对于用户的每一个操作请求都能在有限的时间内返回结果。
分区容错性:分布式系统遇到任何网络分区故障时,仍然能够保证对外提供满足一致性和可用性的服务,除非整个网络出现故障。
BASE理论:BASE理论是基本可用(Basically Available)、软状态(Soft state)、最终一致性(Eventually consistent)三个短语的缩写。
基本可用:是指分布式系统出现故障后,允许瞬时部分可用性,例如响应时间上的损失、功能上的损失等
软状态:也称弱状态,是指允许系统中的数据存在中间状态,并认为该中间状态的存在不会影响系统的整体可用性,即允许系统在不同节点的数据副本间进行数据同步的过程存在时延。
最终一致性:强调系统中所有数据副本在经过一段时间的同步后,最终能达到数据一致的状态,不需要保证系统数据的强一致性。
2PC:即二阶段提交,将事务的提交分为两个阶段来处理:
阶段一提交事务请求,近似看作协调者组织各参与者对一次事务操作的投票表态过程,即各参与者表明是否要继续执行事务提交过程。包括事务询问,执行事务,各参与者向协调者反馈事务询问的响应。
事务询问:协调者向所有参与者发送事务内容,询问是否可以执行事务提交过程,并开始等待各参与者的响应。
执行事务:各参与者执行事务操作,并将信息记录至事务日志。
反馈响应:参与者向协调者反馈事务执行成功与否。
阶段二执行事务提交,协调者根据各参与者的反馈情况决定最后是否要进行事务提交。包括执行事务提交、中断事务两种状态。
执行事务提交:所有参与者都反馈事务执行结果为YES,则提交事务。
中断事务:加入任一个参与者向协调者反馈NO响应,或响应等待超时,那么就会中断事务。
二阶段提交协议的优点:原理简单,实现方便。
缺点:同步阻塞,单点问题,脑裂,过于保守等。
3PC:三阶段提交
阶段一:CanCommit
事务询问:协调者向所有参与者发送包含事务内容的canCommit请求,询问是否可以执行事务提交处理。
各参与者反馈事务询问响应:参与者接到canCommit请求后,判断自己能否执行事务,并反馈Y/N信息。
阶段二:PreCommit
两种可能:事务预处理或中断事务(有参与者反馈No信号,或等待超时后,协调者无法接收到所有参与者的反馈信号)
发送预提交请求:协调者向所有参与者发出perCommit请求,并进入Prepared阶段。
事务预提交:参与者接收到preCommit请求后,会执行事务操作,并记录事务日志信息。
反馈事务执行的响应:如果参与者成功执行了事务操作,则反馈给协调者ACK响应,同时等待最终的指令:提交或终止。
阶段三:doCommit
两种可能:执行事务提交或中断事务(任一参与者反馈No信号,或等待超时后协调者无法接收所有参与者的反馈信号)
发送提交请求:协调者接收到所有参与者的ack响应,从“预提交”转换到“提交”状态,并向所有参与者发送doCommit请求。
事务提交:参与者接收到doCommit请求后,正式执行事务提交操作,并在提交完成后释放掉占用的事务资源。
反馈事务提交结果:参与者在事务正式提交之后,向协调者反馈ACK信息。
完成事务:协调者接收到所有参与者反馈的ACK信息,完成事务。
在阶段三中,可能出现的故障是协调者出现故障或协调者与参与者之间网络出现故障,那么会导致参与者无法及时收到doCommit信息,这样参与者在等待超时之后会继续进行事务提交。
三阶段提交的优点:降低参与者的阻塞范围,并能在单节点出现故障后继续达成一致。
三阶段提交的优点:如果参与者接收到preCommit信号之后,出现网络分区,协调者和参与者无法正常通信,这种情况下参与者依然会进行事务提交,此时必然会出现数据不一致。
缺点: