转载

分布式事务

分布式事务

分布式理论

单个数据库性能产生瓶颈的时候,可能会对数据库进行物理分区,升级为分布式数据库。

分布式数据库无法像单个数据库一样,事务保证ACID属性。只能遵循CAP原则

  • CAP原则:分布式环境下,无法同时拥有以下三个属性,只能三选二

    • 一致性:与单个数据库的一致性类似,只不过分布式环境,保证所有节点的

      数据均一致。

    • 可用性:每一个操作总是能够在一定时间内返回结果。

    • 分区容忍性:即使存在节点宕机,操作依然可以完成

  • BASE理论

    在分布式系统中,往往追求的是可用性,BASE理论是对CAP理论的一个扩充,主要支持实现高可用性

    • Basically Availabel(基本可用)
    • Soft state(软状态)
    • Ecentually consistent(最终一致性)
      • 强一致性:更新操作完成后,后续访问操作,均会返回更新过的值
      • 弱一致性:系统并不保证,后续访问操作能立刻访问到更新后的值
      • 最终一致性:系统保证没有后续更新操作的前提下,系统返回上一层更新操作的值

    BASE理论是对CAP中的一致性和可用性的一个权衡结果。理论的核心思想就是:无法做到

    强一致,但每个应用都可以根据自身的业务特点,采用适当的方式来使系统达到最终一致性

两阶段提交协议

? 二阶段提交Two-phaseCommit是指,在计算机网络以及数据库领域内,为了使基于分布式系统架构下的所有节点在进行事务提交时保持一致性而设计的一种算法(Algorithm)。通常,二阶段提交也被称为是一种协议(Protocol))。在分布式系统中,每个节点虽然可以知晓自己的操作时成功或者失败,却无法知道其他节点的操作的成功或失败。当一个事务跨越多个节点时,为了保持事务的ACID特性,需要引入一个作为协调者的组件来统一掌控所有节点(称作参与者)的操作结果并最终指示这些节点是否要把操作结果进行真正的提交

  • 第一阶段:准备阶段

    协调者向每个参与者发送prepare消息

    参与者根据自己是否能执行事务,返回OK/not OK

  • 第二阶段:提交阶段

    所有参与者返回OK,则协调者向每个参与者发送Commit消息,否则发送Abort消息

    参与者根据接受到Commit或Abort消息,提交事务或者执行回滚操作

  • 两阶段提交缺点

    • 同步阻塞问题,第二阶段,参与者一直会阻塞,直到收到commit/abort消息
    • 如果参与者返回OK后,协调者节点宕机,参与者则会进入阻塞状态,得不到唤醒。

三阶段提交协议

]

  • 第一阶段:准备阶段

    协调者向每个参与者发送prepare消息

    参与者根据自己是否能执行事务,返回Ready/Abort

    如果一旦有参与者返回Abort,直接进入第三阶段

  • 第二阶段:准备提交阶段

    如果第一阶段,如果所有参与者返回Ready,进入第二阶段

    由协调者发准备提交消息(Prepare to Commit)

    参与者收到该消息后写入运行记录(Log record)中,并回答确认消息OK。

  • 第三阶段:提交阶段

    协调者向所有参与者发送Commit或Abort消息

    参与者根据接受到Commit或Abort消息,提交事务或者执行回滚操作

    并返回ACK确认消息

  • 三次提交的优点

    在三次提交阶段,如果协调者在第三阶段失效后(没有发送commit或者abort消息),参与者并不会产生阻塞现象。参与者经过一段时间等待后,会推选出新的协调者,由于第二阶段,事务的状态都写入参与者的本地磁盘,所以参与者将状态发送给新的协调者,尝试进行事务提交。

正文到此结束
本文目录