|
|
知识路径： > 数据库主流应用技术 > 数据库主流应用技术 > 数据库主流应用技术 > 分布式数据库 > 分布事务管理 >
|
|
相关知识点：14个
|
|
|
|
|
所谓事务的阻塞是指一个场地的子事务本来是可以执行结束的，然而由于分布式数据库的故障，它必须等待故障恢复以后得到需要的信息后才可以做出决定，而故障情况是不可以预料的，该子事务又占有一些系统资源不能释放，无法继续执行，这时称之为事务进入阻塞状态。
|
|
|
|
事务出现阻塞的原因可能很多，例如：当参与者等待协调者的回答时，可能因为网络故障或协调者故障使之收不到回答信息而出现等待超时，这时事务进入阻塞状态，重发“建议提交”信息，要求协调者给予回答，直到网络故障或协调者恢复并给予回答，参与者才做出决定继续执行（提交或撤销），若一直收不到回答，则事务一直处于阻塞状态而挂在相应的场地上，因此，阻塞降低了事务的可用性。
|
|
|
|
如何使一提交协议成为非阻塞的提交协议呢？在2PC协议中，参与者的提交是在它知道了其他所有的参与者均发出了“建议提交”的报文以后进行的。若在2PC中增加一段使得参与者的提交不仅要等到它知道所有的参与者均发出了“建议提交”的报文，而且还知道所有参与者的状态（如它们是处于故障状态，还是已经恢复）以后才执行。这时2PC即变成3PC协议，即三阶段提交协议。在3PC协议中，报文有三次接收和发送，协调者第二次向参与者发出的报文不是“全局提交”报文，而是提交前的“全局预提交”报文，告诉所有的参与者均可以进入准备提交状态，而参与者的回答也不是提交子事务，而是发出“准备就绪”报文。在第三阶段中，当协调者收到全部的“准备就绪”的回答时才向所有的参与者发“全局提交”报文。此时，所有的参与者均知道其他的参与者已经进入“准备提交”状态。达到这一点，每个参与者均可以自己做出决定，撤销或提交，而不必因等待协调者的回答而进入阻塞状态，因为即使此时发生故障，系统的恢复机制迟早会恢复到故障前一刻的状态，即各参与者的子事务总会提交。因此，参与者可以自行决定先执行下去而不是处于等待状态，从而减少了阻塞。3PC协议的提交过程为：
|
|
|
|
第一阶段，协调者向所有的参与者发“准备提交”报文，由每个参与者据自己的情况进行投票，只有所有的参与者回答“建议提交”才进入第二阶段。
|
|
|
|
第二阶段，协调者向所有的参与者发“全局预提交”报文，参与者收到该报文后若已经准备好提交，则回答“准备就绪”报文，否则进行撤销处理。
|
|
|
|
第三阶段，协调者收到所有的参与者“准备就绪”回答后，就向所有的参与者发“全局提交”报文，此时每个参与者都知道其他的参与者赞成提交，因此它可以收到“全局提交”报文后进行提交。
|
|
|
|
3PC可以避免阻塞是基于一定的故障模型的，如果发生了网路分割故障，采用3PC协议同样存在问题，没有一种协议能够解决所有的故障，3PC协议仅仅是降低了阻塞发生的可能性，但不是完全的非阻塞协议。
|
|
|
