事务及分布式事务概念介绍

转载请注明出处 http://www.paraller.com
原文排版地址 点击跳转算法

事务及分布式事务

ACID

  • 原子性 (Atomicity) :事务是数据库的逻辑工做单位,事务中包括的诸操做要么全作,要么全不作。
  • 一致性 (Consistency):事务执行的结果必须是使数据库从一个一致性状态变到另外一个一致性状态。一致性与原子性是密切相关的。
  • 隔离性 (Isolation):一个事务的执行不能被其余事务干扰。
  • 持续性/永久性 (Durability):一个事务一旦提交,它对数据库中数据的改变就应该是永久性的。

应用场景:在分布式系统中,每一个节点虽然能够知晓本身的操做时成功或者失败,却没法知道其余节点的操做的成功或失败。
当一个事务跨越多个节点时,为了保持事务的 ACID 特性,须要引入一个做为协调者的组件来统一掌控全部节点(称做参与者)的操做结果并最终指示这些节点是否要把操做结果进行真正的提交(好比将更新后的数据写入磁盘等)。数据库

主要流程

第一阶段 | Vote
  • 协调者会问全部的参与者结点,是否能够执行提交操做。
  • 各个参与者开始事务执行的准备工做:如:为资源上锁,预留资源,写 undo/redo log……
  • 参与者响应协调者,若是事务的准备工做成功,则回应“能够提交”,不然回应“拒绝提交”。
第二阶段 | Decision
  • 若是全部的参与者都回应“能够提交”,那么,协调者向全部的参与者发送“正式提交”的命令。参与者完成正式提交,并释放全部资源,而后回应“完成”,协调者收集各结点的“完成”回应后结束这个 Global Transaction。
  • 若是有一个参与者回应“拒绝提交”,那么,协调者向全部的参与者发送“回滚操做”,并释放全部资源,而后回应“回滚完成”,协调者收集各结点的“回滚”回应后,取消这个 Global Transaction。
出现的问题

一、同步阻塞操做,必然会很是大地影响性能。网络

二、另外是超时问题,好比,框架

  • 若是第一阶段中,参与者没有收到询问请求,或是参与者的回应没有到达协调者。那么,须要协调者作超时处理,一旦超时,能够看成失败,也能够重试。
  • 若是第二阶段中,正式提交发出后,若是有的参与者没有收到,或是参与者提交/回滚后的确认信息没有返回,一旦参与者的回应超时,要么重试,要么把那个参与者标记为问题结点剔除整个集群,这样能够保证服务结点都是数据一致性的。
  • 糟糕的状况是,第二阶段中,若是参与者收不到协调者的 commit/fallback 指令,参与者将处于“状态未知”阶段,参与者彻底不知道要怎么办,好比:若是全部的参与者完成第一阶段的回复后(可能所有 yes,可能所有 no,分布式

    可能部分 yes 部分 no),若是协调者在这个时候挂掉了。那么全部的结点彻底不知道怎么办(问别的参与者都不行)。为了一致性,要么死等协调者,要么重发第一阶段的 yes/no 命令。
改进: 三阶段提交
  • 把二阶段提交的第一个段 break 成了两段:询问,而后再锁资源和最后真正提交。
  • 三段提交的核心理念是:在询问的时候并不锁定资源,除非全部人都赞成了,才开始锁资源。

(事务及分布式事务)[http://blog.daocloud.io/micro...]性能

CAP 定理和数据一致性

CAP 定理

CAP 定理:一个分布式系统最多只能同时知足一致性(Consistency)、可用性(Availability)和分区容错性(Partition tolerance)这三项中的两项。网站

一致性

一致性指更新操做成功后,全部节点在同一时间的数据彻底一致。常见的一致性类别:搜索引擎

  • Weak(弱一致性):当你写入一个新值后,读操做在数据副本上可能读出来,也可能读不出来。好比:某些 cache 系统。
  • Eventually(最终一致性):当你写入一个新值后,有可能读不出来,但在某个时间窗口以后保证最终能读出来。好比:DNS,电子邮件、Amazon S3,Google 搜索引擎这样的系统。
  • Strong(强一致性):新的数据一旦写入,在任意副本任意时刻都能读到新值。好比:文件系统,RDBMS,Azure Table 都是强一致性的。

Paxos

  • Paxos 算法是基于消息传递且具备高度容错特性的一致性算法,是目前公认的解决分布式一致性问题最有效的算法之一。
  • 常见的分布式系统中,总会发生诸如机器宕机或网络异常(包括消息的延迟、丢失、重复、乱序,还有网络分区)等状况。设计

    Paxos 算法须要解决的问题就是如何在一个可能发生上述异常的分布式系统中,快速且正确地在集群内部对某个数据的值达成一致,而且保证不论发生以上任何异常,都不会破坏整个系统的一致性。

Raft

Raft是斯坦福的 Diego Ongaro、John Ousterhout 两我的以易懂(Understandability)为目标设计的一致性算法,在 2013 年发布了论文:In Search of an Understandable Consensus Algorithm
从 2013 年发布到如今不过只有两年,到如今已经有了十多种语言的 Raft 算法实现框架code

参考网站

CAP 定理和数据一致性

相关文章
相关标签/搜索