第6章 分布式数据库中的可靠性4学习资料.ppt

判断2PC协议是终结协议的条件 至少有一个Site已收到结果命令（该Site可以告知其它参与者关于该事务的结果，并由它们来终结该事务） 没有一个参与者收到命令，并且只有协调者Site故障（此时，所有参与者站点都是可工作的，参与者可以选举一个新的协调者，然后继续） 3.5 事务阻断与终结协议 3 分布式数据库的可靠性协议 终结协议在协调者和参与者的定时器超时时发挥作用 超时处理技术 协调者超时 在等待状态超时，可以决定“全局撤销” 在撤销状态超时，重发“G-abort” 在提交状态超时，重发“G-commit” 参与者超时（被阻断时出现） 在初始状态超时，单方面Abort 在Ready状态超时，被阻断，等待事务最终处理结果 3.6 2PC协议的终结协议 3 分布式数据库的可靠性协议 协调者超时 I W C A F commit-申请 申请-prepare* ack* - ack* - _t_ abort any abort any commit _t_ commit _t_ abort* no abort* prepared* commit* t=timeout 参与者超时 I R C A 申请-prepare prepared 等价于结束状态 _t_ ping 申请-prepare no commit ack abort ack commit ack abort ack 设计终结协议 假定Pi是超时的参与者（询问Pj），其它Pj按如下响应 Pj处于初始状态，于是单方面Abort，并回送“建议abort”给Pi Pj处于Ready状态，此时不能帮助Pi终结 Pj处于Commit或Abort状态，此时向Pi发送“建议提交”或“建议Abort” 3.6 2PC协议的终结协议 3 分布式数据库的可靠性协议 Pi超时，可能有的解释 Pi收到Pj的“建议撤销”回答，此时Pi夭折 Pi收到Pj“建议撤销”回答，但是其它Pj处于Ready状态，此时Pi仍然Abort Pi收到Pj处于Ready状态，此时没有一个参与者有足够的信息恰当地终结事务 Pi收到其他所有的Pj”全局提交”或”全局夭折”消息，Pi可以根据消息终结 Pi收到某些Pj的“全局提交”，而另一些Pj处于Ready状态，Pi可以提交 3.6 2PC协议的终结协议 3 分布式数据库的可靠性协议 协调者站点失效 协调者在初始状态失效 发生在协调者初始化提交过程之前 因此，它将在恢复时启动提交过程 协调者在等待状态失效 这时协调者已经发送了“准备”命令 恢复时，协调者将从头开始启动提交过程，再次发送“准备”消息 协调者在提交状态或撤销状态失效 这时，协调者已经把它的决定通知了参与者，并终结了事务 在恢复时，如果它已经收到了所有的确认消息，就不需要做任何事情 否则，就要启动终结协议 3.7 2PC协议的恢复协议 3 分布式数据库的可靠性协议 参与者站点失效 一个参与者在初始状态失效 在恢复时，该参与者应该单方面撤销事务 一个参与者在就绪状态失效 这时协调者已经收到失效站点在失效前发送的肯定决定 恢复时，失效站点的参与者认为是在就绪状态发生了超时，于是启动终结协议来处理该事务 一个参与者在提交状态或撤销状态失效 这些状态表示了终结条件，所以在恢复时，参与者不需要采取任何专门的措施 附加情形（略） 3.7 2PC协议的恢复协议 3 分布式数据库的可靠性协议 提交协议是非阻断的充要条件是, 在其状态转换图中不存在: 没有状态是即与提交又与撤销状态“相邻” 不存在不可提交状态是与提交状态“相邻” 相邻 从一个状态直接转换到另一个状态 3.8 三阶段提交协议 3 分布式数据库的可靠性协议 2PC中的状态 C(提交)状态是可提交状态, 其它为不可提交状态 Ready 状态是不可提交状态 Wait状态是不可提交状态 它们都侵犯了非阻断协议的充要条件, 从而考虑改变2PC, 使其满足非阻断协议条件 在Wait 和 Commit 之间, 或者在Ready和Commit之间加入另一种状态作为缓冲状态, 从而有了3PC协议 3.8 三阶段提交协议 3 分布式数据库的可靠性协议 I W A C commit prepare vote-abort global-abort vote-commit prepare-to-commit I R A C prepare vote-commit global-abort ACK prepare-to-commit ready-to-commit prepare vote-abort 3PC中事务的状态转换图 PC PC ready-to-commit global-commit global-commit ACK (a) 协调者 (b) 参