多阶段提交协议是专用的共识协议，其中常见的是两阶段提交协议(2PC)和三阶段提交协议(3PC)。这些协议的目的是协调参与分布式原子事务的进程，决定是提交还是终止(回退)事务。由于这些算法能够处理整个系统网络或进程方面的故障，所以它们常被当作分布式数据存储或处理的解决方案。
2PC的基础算法由两个阶段构成。第一个阶段是表决阶段，即主存储设备或协调程序向所有参与者或其他存储设备发起“提交请求”。在提交前，所有参与者都处理事务，提交后参与者会告知主存储或协调程序它们能够提交了，或者投赞成票了。这就可以开始第二阶段了，即完成阶段，主存储设备给所有参与者发送提交信号，参与者们开始提交数据。只要有参与者提交失败，回退信号就会发送给所有参与者，事务将被终止。
到目前为止，该协议听起来相当不错，因为在分布式数据库环境中提供了事务的原子性。暂且不要这么早下结论。它在步骤A中发起了事务。那么在主数据库告知应用服务器事务完成(步骤C)前，所有的2PC步骤都要完成(步骤B)。在整个过程中，应用服务器上的线程都要等待SQL查询结束，且数据库响应了这一事务。这一示例非常常见，网络上几乎所有的用户购买、注册或竞价的事务，都可能用2PC实现。但是，把应用服务器锁住那么久，会造成可怕的后果。即使你可能认为自己的应用服务器还有充足的容量，或者由于应用服务器是商用硬件，可以用较低的成本扩展它们，但还要考虑锁定同样会发生在数据库端。在执行提交操作时，假设你采用的是行锁，那么在所有数据提交完之前，所有的数据行都会被锁住。如果采用的是块锁，结果会更糟我们已经大范围地实现了2PC协议，结果是灾难性的，这要完全归昝于该方法的锁定和等待特性。在实现2PC协议前，数据库最初每秒可以处理几千个读操作和写操作。在一小部分(少于20%)调用中引人了2PC后，整个站点能处理的事务量只有以前的1/4。即使我们能增加更多的应用服务器，但由于数据被锁定了，网站建设数据库也不能处理更多的查询。虽然2PC协议看起来是个比Y轴划分或乙轴划分更好的分割数据库的方法，但仔细考虑后就会发现很多问题。要用更好的办法拆分数据库表，而不是用多阶段提交协议延长单一数据库的生命。
本文地址：//www.gogoparty.cc//article/3498.html
