事务:2PC:修订间差异

来自WHY42
imported>Soleverlee
Riguz留言 | 贡献
 
(未显示2个用户的2个中间版本)
第1行: 第1行:
=简介=
=简介=
二阶提交协议(Two Phase Commitment Protocol)。二阶段提交(英语:Two-phase Commit)是指,为了使基于分布式系统架构下的所有节点在进行事务提交时保持一致性而设计的一种算法(Algorithm)。通常,二阶段提交也被称为是一种协议(Protocol)。在分布式系统中,每个节点虽然可以知晓自己的操作时成功或者失败,却无法知道其他节点的操作的成功或失败。当一个事务跨越多个节点时,为了保持事务的ACID特性,需要引入一个作为协调者的组件来统一掌控所有节点(称作参与者)的操作结果并最终指示这些节点是否要把操作结果进行真正的提交(比如将更新后的数据写入磁盘等等)。因此,二阶段提交的算法思路可以概括为:  
二阶提交协议(<span class="article-label">Two Phase Commitment Protocol</span>)。二阶段提交是指,为了使基于分布式系统架构下的所有节点在进行事务提交时保持一致性而设计的一种算法(Algorithm)。通常,二阶段提交也被称为是一种协议(Protocol)。在分布式系统中,每个节点虽然可以知晓自己的操作时成功或者失败,却无法知道其他节点的操作的成功或失败。当一个事务跨越多个节点时,为了保持事务的ACID特性,需要引入一个作为协调者的组件来统一掌控所有节点(称作参与者)的操作结果并最终指示这些节点是否要把操作结果进行真正的提交(比如将更新后的数据写入磁盘等等)。因此,二阶段提交的算法思路可以概括为: 参与者将操作成败通知协调者,再由协调者根据所有参与者的反馈情报决定各参与者是否要提交操作还是中止操作。
*参与者将操作成败通知协调者,再由协调者根据所有参与者的反馈情报决定各参与者是否要提交操作还是中止操作。
 
二阶段提交算法的成立基于以下假设:
二阶段提交算法的成立基于以下假设:
#该分布式系统中,存在一个节点作为协调者(Coordinator),其他节点作为参与者(Cohorts)。且节点之间可以进行网络通信。
#该分布式系统中,存在一个节点作为<span class="article-label">协调者(Coordinator)</span>,其他节点作为<span class="article-label">参与者(Cohorts)</span>。且节点之间可以进行网络通信。
#所有节点都采用预写式日志,且日志被写入后即被保持在可靠的存储设备上,即使节点损坏不会导致日志数据的消失。
#所有节点都采用预写式日志,且日志被写入后即被保持在可靠的存储设备上,即使节点损坏不会导致日志数据的消失。
#所有节点不会永久性损坏,即使损坏后仍然可以恢复。
#所有节点不会永久性损坏,即使损坏后仍然可以恢复。
=算法=
=算法=
==第一阶段(提交请求阶段)==
==第一阶段(提交请求阶段)==
第27行: 第28行:
有时候,第二阶段也被称作完成阶段,因为无论结果怎样,协调者都必须在此阶段结束当前事务。
有时候,第二阶段也被称作完成阶段,因为无论结果怎样,协调者都必须在此阶段结束当前事务。
=实现=
=实现=
二阶段提交算法的最大缺点就在于 它的执行过程中间,节点都处于阻塞状态。即节点之间在等待对方的相应消息时,它将什么也做不了。特别是,当一个节点在已经占有了某项资源的情况下,为了等待其他节点的响应消息而陷入阻塞状态时,当第三个节点尝试访问该节点占有的资源时,这个节点也将连带陷入阻塞状态。
2PC 存在的问题:
#阻塞问题
二阶段提交的第一阶段中,协调者需要等待参与者的响应,如果没有接收到任意参与者的响应,这时候进入等待状态,而其他正常发送响应的参与者,将进入阻塞状态,将无法进行其他任何操作,只有等待超时中断事务,极大的限制了系统的性能。
#单点问题
协调者处于一个中心的位置,一旦出现问题,那么整个二阶段提交将无法运转,更为严重的是,如果协调者在阶段二中出现问题的话,那么其他参与者将会一直处于锁定事务资源的状态中,将无法继续完成操作


另外,协调者节点指示参与者节点进行提交等操作时,如有参与者节点出现了崩溃等情况而导致协调者始终无法获取所有参与者的响应信息,这时协调者将只能依赖协调者自身的超时机制来生效。但往往超时机制生效时,协调者都会指示参与者进行回滚操作。这样的策略显得比较保守。
[[Category:Distributed]]
[[Category:Programe]]

2021年5月2日 (日) 15:18的最新版本

简介

二阶提交协议()。二阶段提交是指,为了使基于分布式系统架构下的所有节点在进行事务提交时保持一致性而设计的一种算法(Algorithm)。通常,二阶段提交也被称为是一种协议(Protocol)。在分布式系统中,每个节点虽然可以知晓自己的操作时成功或者失败,却无法知道其他节点的操作的成功或失败。当一个事务跨越多个节点时,为了保持事务的ACID特性,需要引入一个作为协调者的组件来统一掌控所有节点(称作参与者)的操作结果并最终指示这些节点是否要把操作结果进行真正的提交(比如将更新后的数据写入磁盘等等)。因此,二阶段提交的算法思路可以概括为: 参与者将操作成败通知协调者,再由协调者根据所有参与者的反馈情报决定各参与者是否要提交操作还是中止操作。

二阶段提交算法的成立基于以下假设:

  1. 该分布式系统中,存在一个节点作为,其他节点作为。且节点之间可以进行网络通信。
  2. 所有节点都采用预写式日志,且日志被写入后即被保持在可靠的存储设备上,即使节点损坏不会导致日志数据的消失。
  3. 所有节点不会永久性损坏,即使损坏后仍然可以恢复。

算法

第一阶段(提交请求阶段)

  1. 协调者节点向所有参与者节点询问是否可以执行提交操作,并开始等待各参与者节点的响应。
  2. 参与者节点执行询问发起为止的所有事务操作,并将Undo信息和Redo信息写入日志。
  3. 各参与者节点响应协调者节点发起的询问。如果参与者节点的事务操作实际执行成功,则它返回一个"同意"消息;如果参与者节点的事务操作实际执行失败,则它返回一个"中止"消息。

有时候,第一阶段也被称作投票阶段,即各参与者投票是否要继续接下来的提交操作。

第二阶段(提交执行阶段)

成功

当协调者节点从所有参与者节点获得的相应消息都为"同意"时:

  1. 协调者节点向所有参与者节点发出"正式提交"的请求。
  2. 参与者节点正式完成操作,并释放在整个事务期间内占用的资源。
  3. 参与者节点向协调者节点发送"完成"消息。
  4. 协调者节点收到所有参与者节点反馈的"完成"消息后,完成事务。

失败

如果任一参与者节点在第一阶段返回的响应消息为"终止",或者 协调者节点在第一阶段的询问超时之前无法获取所有参与者节点的响应消息时:

  1. 协调者节点向所有参与者节点发出"回滚操作"的请求。
  2. 参与者节点利用之前写入的Undo信息执行回滚,并释放在整个事务期间内占用的资源。
  3. 参与者节点向协调者节点发送"回滚完成"消息。
  4. 协调者节点收到所有参与者节点反馈的"回滚完成"消息后,取消事务。

有时候,第二阶段也被称作完成阶段,因为无论结果怎样,协调者都必须在此阶段结束当前事务。

实现

2PC 存在的问题:

  1. 阻塞问题

二阶段提交的第一阶段中,协调者需要等待参与者的响应,如果没有接收到任意参与者的响应,这时候进入等待状态,而其他正常发送响应的参与者,将进入阻塞状态,将无法进行其他任何操作,只有等待超时中断事务,极大的限制了系统的性能。

  1. 单点问题

协调者处于一个中心的位置,一旦出现问题,那么整个二阶段提交将无法运转,更为严重的是,如果协调者在阶段二中出现问题的话,那么其他参与者将会一直处于锁定事务资源的状态中,将无法继续完成操作