分布式介绍(一)

分布式介绍(一)

为什么使用分布式

一方面随着系统变得越来越复杂,集中式系统的成本越来越高,人力成本和机器成本.

另一方面集中式系统具有明显的单点问题,扩容困难.

什么是分布式

分布式系统是由一组通过网络进行通信、为了完成共同的任务而协调工作的计算机节点组成的系统。

分布式系统的出现是为了用廉价的、普通的机器完成单个计算机无法完成的计算、存储任务。其目的是利用更多的机器,处理更多的数据。

分布式系统是一个硬件或软件组件分布在不同的网络计算机上,彼此之间仅仅通过消息传递进行通信和协调的系统,具备分布性、对等性、并发性等特征。

分布式系统的难点:

第一,异构的机器与网络:

分布式系统中的机器,配置不一样,其上运行的服务也可能由不同的语言、架构实现,因此处理能力也不一样;

节点间通过网络连接,而不同网络运营商提供的网络的带宽、延时、丢包率又不一样。怎么保证大家齐头并进,共同完成目标,这四个不小的挑战。

第二,普遍的节点故障:

虽然单个节点的故障概率较低,但节点数目达到一定规模,出故障的概率就变高了。

分布式系统需要保证故障发生的时候,系统仍然是可用的,这就需要监控节点的状态,在节点故障的情况下将该节点负责的计算、存储任务转移到其他节点

第三,不可靠的网络:

节点间通过网络通信,而网络是不可靠的。可能的网络问题包括:网络分割、延时、丢包、乱序。

相比单机过程调用,网络通信最让人头疼的是超时:节点A向节点B发出请求,在约定的时间内没有收到节点B的响应,那么B是否处理了请求,这个是不确定的,这个不确定会带来诸多问题,最简单的,是否要重试请求,节点B会不会多次处理同一个请求。

分布式两个著名的理论

CAP理论  

CAP是Consistency、Availablity和Partition-tolerance的缩写。分别是指:

一致性(Consistency):每次读操作都能保证返回的是最新数据;

可用性(Availablity):任何一个没有发生故障的节点,会在合理的时间内返回一个正常的结果;

分区容错性(Partition-torlerance):当节点间出现网络分区,照样可以提供服务。

CAP理论的核心是:一个分布式系统不可能同时很好的满足一致性,可用性和分区容错性这三个需求,最多只能同时较好的满足两个。

BASE理论

BASE是Basically Available(基本可用)、Soft state(软状态)和Eventually consistent(最终一致性)三个短语的简写.

BASE是对CAP中一致性和可用性权衡的结果,其来源于对大规模互联网系统分布式实践的结论,是基于CAP定理逐步演化而来的,其核心思想是即使无法做到强一致性(Strong consistency),但每个应用都可以根据自身的业务特点,采用适当的方式来使系统达到最终一致性(Eventual consistency)。

BASE理论面向的是大型高可用可扩展的分布式系统,和传统事务的ACID(原子性、一致性、隔离性和持久性)特性是相反的,它完全不同于ACID的强一致性模型,而是提出通过牺牲强一致性来获得可用性,并允许数据在一段时间内是不一致的,但最终达到一致状态(弱一致性)。

一致性协议之2PC、3PC

当一个事务操作需要跨越多个分布式节点的时候(分布式事务),为了保持事务处理的ACID特性,就需要引入一个称为“协调者”的组件来统一调度所有分布式节点的执行逻辑,这些被调度的分布式节点则被称为“参与者”。

协调者负责调度参与者的行为,并最终决定这些参与者是否要把事务真正进行提交。基于这个思想,衍生出了2pc(二阶段提交)和3pc(三阶段提交)两种协议。

2PC

2PC(Two-Phase Commit),即二阶段提交,是计算机网络尤其是在数据库领域内,为了使基于分布式系统架构下的所有节点在进行事务处理过程中能够保持原子性和一致性而设计的一种算法。
二阶段提交是一个强一致性算法,目前,绝大部分的关系型数据库都是采用二阶段提交协议来完成分布式事务处理的,利用该协议能够非常方便地完成所有分布式事务参与者的协调,统一决定事务的提交或回滚,从而能够有效地保证分布式数据一致性。

顾名思义,二阶段提交协议是将事务的提交过程分成了两个阶段来进行处理,其执行流程如下:
协调者发起一个提议,协调者向所有的参与者发送事务内容,询问是否可以执行事务提交操作,并开始等待各参与者的响应。
各参与者节点执行事务操作,并将Undo和Redo信息记入事务日志中。
如果参与者成功执行了事务操作,那么就反馈给协调者Yes响应,表示事务可以执行;如果参与者没有成功执行事务,那么就反馈给协调者No响应,表示事务不可以执行。

假如协调者从所有的参与者获得的反馈都是Yes响应,协调者向所有参与者节点发出Commit请求.参与者接收到Commit请求后,会正式执行事务提交操作,并在完成提交之后释放在整个事务执行期间占用的事务资源。参与者在完成事务提交之后,向协调者发送Ack消息。协调者接收到所有参与者反馈的Ack消息后,完成事务.

假如任何一个参与者向协调者反馈了No响应,或者协调者尚无法接收到所有参与者的反馈响应,那么协调者向所有参与者节点发出Rollback请求,参与者接收到Rollback请求后,会利用其在阶段一中记录的Undo信息来执行事务回滚操作,并在完成回滚之后释放在整个事务执行期间占用的资源.参与者在完成事务回滚之后,向协调者发送Ack消息.协调者接收到所有参与者反馈的Ack消息后,完成事务中断

优点:原理简单,实现方便
缺点:同步阻塞(执行过程中,所有参与节点都是事务阻塞型的)、单点问题(由于协调者的重要性,一旦协调者发生故障。参与者会一直阻塞下去)、数据不一致(一部分收到commit请求,一部分没收到)

3pc

3PC(Three-Phase Commit),即三阶段提交,是2PC的改进版,其将二阶段提交协议的“提交事务请求”过程一分为二,形成了由CanCommit、PreCommit和do Commit三个阶段组成的事务处理协议。

CanCommit:
协调者向所有的参与者发送一个包含事务内容的canCom-mit请求,询问是否可以执行事务提交操作,并开始等待各参与者的响应.

参与者在接收到来自协调者的canCommit请求后,正常情况下,如果其自身认为可以顺利执行事务,那么会反馈Yes响应,并进入预备状态,否则反馈No响应.

PreCommit
假如协调者从所有的参与者获得的反馈都是Yes响应,那么就会执行事务预提交:

协调者向所有参与者节点发出preCommit的请求,并进入Prepared阶段。

参与者接收到preCommit请求后,会执行事务操作,并将Undo和Redo信息记录到事务日志中。

假如任何一个参与者向协调者反馈了No响应,或者协调者无法接收到所有参与者的反馈响应,那么就会中断事务.
协调者向所有参与者节点发出abort请求。

无论是收到来自协调者的abort请求,或者是在等待协调者请求过程中出现超时,参与者都会中断事务。

doCommit
也分为两者情况,协调者从所有的参与者获得的反馈都是Yes响应,则执行提交:

进入这一阶段,假设协调者处于正常工作状态,并且它接收到了来自所有参与者的Ack响应,那么它将从“预提交”状态转换到“提交”状态,并向所有的参与者发送doCommit请求。

参与者接收到doCommit请求后,会正式执行事务提交操作,并在完成提交之后释放在整个事务执行期间占用的事务资源。
参与者在完成事务提交之后,向协调者发送Ack消息。

协调者接收到所有参与者反馈的Ack消息后,完成事务。

任何一个参与者向协调者反馈了No响应,或者在等待超时之后,协调者会中断事务:

协调者向所有的参与者节点发送abort请求。

参与者接收到abort请求后,会利用其在阶段二中记录的Undo信息来执行事务回滚操作,并在完成回滚之后释放在整个事务执行期间占用的资源。

参与者在完成事务回滚之后,向协调者发送Ack消息。

协调者接收到所有参与者反馈的Ack消息后,中断事务。

备注:在doCommit阶段,如果参与者无法及时接收到来自协调者的doCommit或者rebort请求时,会在等待超时之后,会继续进行事务的提交。

优点:相较于二阶段提交协议,三阶段提交协议最大的优点就是降低了参与者的阻塞范围,并且能够在出现单点故障后继续达成一致(原因结合上面的备注)。

缺点:三阶段提交协议在去除阻塞的同时也引入了新的问题,那就是在参与者接收到preCommit消息后,如果网络出现分区,此时协调者所在的节点和参与者无法进行正常的网络通信,在这种情况下,该参与者依然会进行事务的提交,这必然出现数据的不一致性。
由于2pc和3pc都不能解决一致性问题,那么就有了Paxos算法.