一致性保证

强一致性

任何依次读的数据都是最新的。

弱一致性

最终一致性

分布式事务

两阶段提交

分为2部分

1. vote, prepare

   第一个阶段需要保证每个参与者都可以执行操作

2. commit or rollback

   在参与者都OK的情况下，执行事务提交。或者事务回滚。

2pc-success

状态变化

2pc-state

站在协调者的角度，在发起投票之后就进入了 WAIT 状态，等待所有参与者回复各自事务执行状态，并在收到所有参与者的回复后决策下一步是发送 commit 或 rollback 信息。

站在参与者的角度，当回复完协调者的投票请求之后便进入 READY 状态（能够正常执行事务），接下去就是等待协调者最终的决策通知，一旦收到通知便可依据决策执行 commit 或 rollback 操作。

存在的问题

• 单点问题

  协调着是一个单体服务，所以他的稳定性没法保证。

• 同步阻塞

  参与者在执行阶段是一个同步阻塞的状态，

• 超时问题 -> 导致数据不一致

  比如协调着没有收到commit请求等

三阶段提交

针对上述问题，引出了三阶段提交。

1. CanCommit

   这是一个轻量的询问，咨询是否可以。如果不行，也就没必要继续了。这样，我们就没必要一直占着很多资源了。

2. PreCommit

   类似于二阶段提交的Vote

3. DoCommit

   类似于二阶段提交的commit。

除了上述之外，引入了超时

1. precommit阶段，如果参与者发送no之后没有收到反馈，进行rollback
2. docommit阶段，自行提交。

宕机恢复

1. cancommit阶段，未同意，未发出vote ,自行中止
2. precommit阶段，如果是同意，则自行commit
3. cancommit, commit

单点问题

1. 启动watchdog

TCC

在这里插入图片描述

try

业务实现，2pc 资源实现。

confirm

cancel

MySQL的事务提交保证