分布式事务解决方案 、 一致性协议

分布式事务解决方案 、 一致性协议


(一)分布式事务

分布式事务就是指事务的参与者、支持事务的服务器、资源服务器以及事务管理器分别位于不同的分布式系统的不同节点之上。


1.特性

  1. A:原子性。事务操作要么全部完成,要么全部不完成,不存在只完成部分的中间状态。
  2. C:一致性。
  3. I:隔离性。事务与事务之间不会相互影响,一个事务的中间状态不会被其他事务感知。
  4. D:持久性。一旦事务完成,其对数据做出的更改就保存在了数据库中。

2.解决方案

(1)TCC:补偿型事务解决方案

TCC指的是Try(尝试)、Confirm(确认)、Cancel(取消)。其核心思想是:针对每一个操作,都需要注册一个与其相对应的确认和取消操作

  1. Try:对业务系统做检测及资源预留 —— 类似于2PCPrecommit准备阶段。
  2. Confirm:对业务系统做确认提交 —— 类似于2PCCommit提交阶段。
  3. Cancel:在业务执行错误时,需要回滚的状态下,取消业务,释放预留资源

比如A向B转账:
1.在Try阶段,首先将A和B的钱冻结起来。
2.在Confirm阶段,转账,转账成功则解冻两个账户。
3.如果第2步执行失败,在Cancel阶段,将两个账户解冻。

  • 优点:和2PC相比,流程简单
  • 缺点:数据一致性弱于2PC,且在第2/3步都可能失败

(3)使用一致性协议(比如2PC

第(二)节


(2)基于【可靠消息表】的最终一致性解决方案

如:订单系统创建订单成功后,库存系统需要扣减相应库存。

订单系统
  1. 创建订单前,创建预发送消息,保存到消息表中,此时消息状态为:未发送
  2. 创建订单,如果失败则将消息表预发消息删除
  3. 创建订单成功,修改消息表消息状态为:发送中,并将消息发送至MQ
  4. 消息发送失败,则订单回滚,在消息表中删除对应消息;发送成功则OK
库存系统
  1. MQ监听并消费消息,同时根据消息ID查询消息是否被消费,保证幂等性
  2. 如果消息未被消费(消息表中存在此消息),则库存系统扣减库存;如果消息已经被消费(消息表中无此消息),则不做处理
  3. 库存系统扣减库存成功,则删除消息表中消息;失败则不做处理
  4. 定时任务会定时扫描消息表中超时未被消费的消息,然后尝试重发,如果超过最大重试次数后仍未被消费,则记录日志通知人工补偿

(二)一致性协议

1.2PC(也称XA

2PC即二阶段提交协议,在数据库中的应用即XA协议:

  1. 第一阶段(准备阶段,Precommit):事务协调器要求每个事务参与者锁定资源、执行事务,但是不提交事务,而是只反映是否可以提交
  2. 第二阶段(提交阶段,Commit/Rollback):①如果所有事务参与者反映可以提交,则提交事务,释放锁定的资源;②如果有事务参与者反馈不可提交,则回滚事务,同样释放锁定资源

2PC的特点

  1. 强一致性:牺牲了部分可用性,换取数据的强一致性
  2. 先斩后奏:先锁定资源、执行事务,再根据反馈决定提交还是回滚

2PC的缺点

  1. 阻塞:任何一次指令必须收到明确的响应才会执行下一步,否则一直处于阻塞状态,锁住的资源也不会释放

    3PC引入超时机制解决了阻塞问题。

  2. 单点问题:一旦协调者宕机,参与者没有协调者指挥,会一直阻塞

  3. 脑裂:协调者二阶段发送Commit,有的节点收到了消息提交了事务,有的节点没有收到就没有提交事务,多个参与者之间数据不一致


2.3PC

3PC即三阶段提交协议:

  1. 询问阶段:协调者询问事务参与者是否可以执行事务,参与者只需要回答Yes/No,不需要真正执行

    询问阶段 超时 导致中止!

  2. 准备阶段:①如果所有事务参与者反馈可以执行事务,协调者向所有参与者发送执行请求,参与者锁定资源、执行事务,但是不提交,只反馈是否可以提交;②如果有事务参与者反馈不可用执行、或是超时没有收到某些事务参与者的反馈,那么协调者向参与者发送中止事务请求

    准备阶段相当于2PC的PreCommit阶段,这阶段 超时 默认成功!

  3. 提交阶段:①如果所有事务参与者反映可以提交、或是超时没有收到某些参与者的反馈,则默认执行成功、提交事务,释放锁定的资源;②如果有事务参与者反馈不可提交,则回滚事务,同样释放锁定资源

    提交阶段相当于2PC的Commit/Rollback阶段

3PC的缺点

  • 仍然可能存在脑裂:试想协调者提交阶段发送Commit,有的节点收到了消息提交了事务,有的节点没有收到就没有提交事务,多个参与者之间仍然会数据不一致

3.Paxos(超过半数)

核心:超过半数

即所谓的Quorum机制:
要求机器数量是奇数,每次需要有超过半数的机器ACK,操作方才会认为操作成功。ZK集群用的就是这种方式。

ZooKeeperZAB协议

崩溃恢复
  • Leader宕机,集群恢复后发现已有新Leader被选举出来,那么原Leader会变为新LeaderFollower,同步新的Leader

4.Raft(日志复制、更多)

Raft是一种管理复制日志的分布式一致性算法。

参考自http://ifeve.com/raft/

节点3种状态

每个节点有3个状态,可以相互切换(选举流程):

  1. Leader:主节点,用于写数据
  2. Candidate:候选节点
  3. Follower:从节点,用于读数据
任期

每个Leader都有自己的任期

  1. 任期结束后如果没有新的Candidate参与选举,那么Leader可以连任
  2. 如果任期结束有新的Candidate参与选举,那么两者进行选举,选票更多的成为Leader
选举流程

  1. 节点状态初始都是Follower每个Follower会记录其Leader,然后和Leader之间维持一个心跳
  2. Follower100-300ms没有收到Leader的心跳回复,Follower就变成Candidate
  3. Candidate给所有节点发送选票,获得更多Follower选票的Candidate就有资格成为Leader
  4. 如果多个Candidate获得的票同样多,那么两个Candidate会重新发选票,直到票数较多的节点当选Leader

日志复制流程

  1. 只有Leader才能接收客户端的写请求
  2. 每次Leader收到写请求,都会先记录日志
  3. Leader将日志同步给所有Follower节点进行复制
  4. Leader等待超过半数Follower节点写日志成功后才提交数据,反馈客户端提交成功

集群中断

当集群之间的部分节点失去通讯时,Leader的日志不能复制给多个Follower就不能进行提交。

崩溃恢复

  1. 集群恢复后,如果Leader发现自己的票数不是最多的,就会变成Follower,并回滚自己的日志
  2. 最后Leader会将自己的日志同步给所有Follower,保证主从数据一致性

RaftPaxos崩溃恢复的区别:
Paxos的集群恢复是原Leader无论如何都变成新LeaderFollower
②而Raft不同于Paxos,集群恢复后原Leader不是直接变为Follower,而是和新Leader进行比较,票更多的才当选新Leader

-------------本文结束感谢您的阅读-------------

本文标题:分布式事务解决方案 、 一致性协议

文章作者:DragonBaby308

发布时间:2019年09月06日 - 21:01

最后更新:2020年02月14日 - 15:12

原始链接:http://www.dragonbaby308.com/Transaction-Consistency/

许可协议: 署名-非商业性使用-禁止演绎 4.0 国际 转载请保留原文链接及作者。

急事可以使用右下角的DaoVoice,我绑定了微信会立即回复,否则还是推荐Valine留言喔( ఠൠఠ )ノ
0%