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

转载请注明出处 http://www.paraller.com
原文排版地址 点击获取更好阅读体验

事务及分布式事务

ACID

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

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

主要流程

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

1、同步阻塞操作,必然会非常大地影响性能。

2、另外是超时问题,比如,

  • 如果第一阶段中,参与者没有收到询问请求,或是参与者的回应没有到达协调者。那么,需要协调者做超时处理,一旦超时,可以当作失败,也可以重试。
  • 如果第二阶段中,正式提交发出后,如果有的参与者没有收到,或是参与者提交/回滚后的确认信息没有返回,一旦参与者的回应超时,要么重试,要么把那个参与者标记为问题结点剔除整个集群,这样可以保证服务结点都是数据一致性的。
  • 糟糕的情况是,第二阶段中,如果参与者收不到协调者的 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 算法实现框架

参考网站

CAP 定理和数据一致性

你可能感兴趣的:(transaction)