分布式事务二阶段、三阶段提交

http://blog.jobbole.com/95632/   (关于分布式事务、两阶段提交协议、三阶提交协议)网络

1、 两阶段提交分布式

   1. 准备阶段。性能

       协调者向参与者发出执行的询问请求,参与者执行事务操做,写undo/redo日志,而且返回给协调者ack消息,全部参与者反馈成功或者失败。日志

  这时候参与者锁住事务资源。blog

   2. 提交阶段事务

      根据参与者反馈的信息,若是有失败,则回滚每一个参与者的操做;若是所有成功,则向全部参与者发送commit命令。资源

     参与者接收到commit或者rollback命令,释放事务资源。get

   两阶段提交的问题:同步

  1.同步阻塞:在提交阶段以前,参与者会锁住事务资源,其余想获取资源的就会被阻塞;it

      2.单点故障:若是协调者挂了,那么参与者锁住的资源就不会释放,若是经过心跳选择了新的协调者,也没法解决这个问题,毕竟链接已经断开了)

      3.数据不一致:若是协调者发送commit命令过程当中,由于网络等缘由,致使只有一部分参与者收到了消息,这样就会产生数据不一致(每一个节点的数据在同一时间没有保持该有的正确性

2、三阶段提交

  在两阶段的基础上作了以下改动:

    1.将两阶段中的准备阶段一分为二,细分为 请求询问、预提交、最终提交阶段,

  2. 引入超时机制,协调者和参与者都加入超时机制。

    具体以下:

  1.询问阶段: 参与者校验一下是否能够执行协调者发送的请求。(避免了二段式直接预执行,写了redo/undo日志,锁定了资源,若是遇到回滚则性能低下)

    2.预提交阶段: 协调者通过询问阶段后,这时候第二阶段预提交的失败率大大下降,

  开始将命令预提交给参与者执行,协调者若是等待超时或者收到了一条no的反馈,则向全部参与者发送中断事务命令,

  当参与者迟迟收不到协调者的commit或者rollback,则自动回滚,很大程度解决了单点问题,

  而上面两点好处则很大程度解决了同步阻塞的问题,包括询问阶段的存在也会减轻同步阻塞。

   3.最终提交 

相关文章
相关标签/搜索