分布式一致性协议
2021-04-11 21:52:43 0 举报AI智能生成
分布式一致性协议2PC和3PC
作者其他创作
大纲/内容
前提
协调者
统一调度分布式系统的执行逻辑
参与者
被调度的分布式节点
2PC（two phase commit :二阶段提交缩写）
目的
为了使分布式架构下的所有节点在执行分布式事务过程中能够保证原子性和一致性而设计的一种算法，
通常二阶段提交协议也被称为一种一致性协议，用来保证分布式系统数据的一致性
通常二阶段提交协议也被称为一种一致性协议，用来保证分布式系统数据的一致性
说明
二阶段提交的协议是将事务的提交过程分成两个阶段来处理
阶段说明
阶段一（提交事务请求：投票阶段）
事务询问
协调者向参与者发送事务内容，询问参与者是否可以执行事务提交操作，并等待参与者响应
执行事务
各个节点的参与者开始执行事务，并将记录日志（undo，redo）
各参与者向协调者反馈事务询问的响应
成功执行事务操作 ，反馈给协调者 YES
未成功执行事务操作， 反馈给协调者 NO
阶段二（执行事务提交）
执行事务提交（协调者收到YES响应）
发送提交请求
协调者向所有参与者发送commit请求
事务提交
参与者收到commit请求后，正式执行事务提交操作，并在完成提交后释放整个事务过程中占用的资源
反馈事务提交结果
参与者完成提交后向协调者发送ACK
完成事务
协调者收到参与者的ACK消息后完成事务
中断事务（协调者收到NO响应或者超时无法获取参与者的反馈）
发送回滚请求
向节点发送rollback请求
事务回滚
根据一阶段中的undo日志中记录的事务信息进行回滚操作，在完成回滚后释放整个资源
反馈事务回滚结果
完成后滚后，向协调者发送ACK消息
中断事务
收到参与者的ACK信息后，中断事务
优缺点
优点
简单，方便
缺点
同步阻塞
所有参与该事务的操作都会处于阻塞
单点问题
协调者在任何一阶段出现问题，那么整个流程都会出现问题
数据不一致
协调者发送commit到参与者的时候，在发送到一半参与者的时候协调者自己挂了，未收到commit的节点则无法进行事务提交，最终导致数据不一致
保守
二阶段提交没有一个完善的容错机制，任何一个节点出现问题，都会导致整个事务失败
在协调者询问事务提交的过程中，如果参与者出现问题，导致协调者无法获取响应信息，
则协调者只能根据自己的机制判断是否需要终止事务
在协调者询问事务提交的过程中，如果参与者出现问题，导致协调者无法获取响应信息，
则协调者只能根据自己的机制判断是否需要终止事务
3PC(three phase commit)
说明
将二阶段提交协议中的（提交事务请求过程一分类二）
阶段
阶段一cancommit
事务询问
协调者向所有参与者发送cancommit的请求，询问是否可以执行事务操作并等待参与者响应
各个参与者反馈事务询问响应
参与者收到cancommit请求询问后，正常情况下认为可以顺利执行则响应YES，否则响应NO
阶段二precommit
执行事务预提交（协调者从所有的参与者获得的响应都是YES）
发送预提交请求
协调者向所有参与者发出precommit的请求，并进入prepared阶段
参与者收到precommit请求，执行事务操作，并记录日志（undo和redo）
各个参与者向协调者提交事务响应
成功执行事务操作后发送ACK响应，同时等待最终指令：commit 或者 abort
中断事务（任何一个参与者反馈NO，或者超时未得到响应）
发送中断请求
协调者向所有 参与者发送 终止（abort）请求
中断事务
无论是参与者是否成功收到abort还是超时参与者都会终止事务
阶段三docommit
真正的事务提交阶段
执行提交
发送提交请求（最终指令）
收到所有参与者的ACK响应后，将预提交转变为提交状态，并向所有的参与者发送 docommit请求
事务提交
参与者收到docommit请求，正式执行事务操作，完成后释放资源
反馈事务提交结果
完成提交后向协调者发送ACK
完成事务
协调者接收到ACK后，完成事务
中断事务
发送中断请求（最终指令）
向协调者发送abort
事务回滚
利用在阶段二中的undo日志，执行事务回滚，完成后释放资源
反馈事务回滚结果
回滚事务之后，向协调者发送ACK
中断事务
协调者收到ACK后，中断事务
故障
协调者出现故障
协调者和参与者出现网络故障
无论出现上述哪种故障，最终都会导致参与者无法收到协调者的docommit或者abort，针对以上情况，参与者最终都会提交事务
优缺点
降低参与者的阻塞范围
子主题
0 条评论
下一页
