分布式一致性（2pc/3pc/tcc/GTS）--极简总结

CAP：

一致性

可用性

分区容错性

最多只能满足2个，

 

BASE：

Basic Avialle / Sofe state/consistent

可用、0.5ms  变成1-2秒

软状态：中间状态，事后补齐数据

一致性：最终一致性

 

 

2PC

第一阶段：预提交，参与者写redo undo /更新数据，但是不提交事务（事务等待，可能会造成大事务）

第二阶段：提交数据

3PC

第一阶段：准备阶段，做一些校验得的事情（超时终止）

第二阶段：预提交（超时自动提交）

第三阶段：提交（）

这里与两阶段提交协议有两个主要的不同：

• 增加了一个询问阶段，询问阶段可以确保尽可能早的发现无法执行操作而需要中止的行为，但是它并不能发现所有的这种行为，只会减少这种情况的发生。
• 增加了等待超时的处理逻辑，如果在询问阶段等待超时，则自动中止；如果在准备阶段之后等待超时，则自动提交。这也是根据概率统计上的正确性最大。

来自 <https://blog.51cto.com/14528283/2446329>

 

TCC

Try-confirm-cancel

1:try:检查并预留资源

如有资源不够的，则调用cancel;

2:如果都检查OK，则直接提交所有事务（一次性提交，不会有事务等待造成的大事务问题）

3：如果comfirm失败一个，则调用所有的cancel

4：网络原因等导致没有收到响应，则重试，重试一定次数还失败的，事务补充

 

总结一下，相比于二阶段提交协议，TCC 主要有以下区别：

• 2PC 位于资源层而 TCC 位于服务层。
• 2PC 的接口由第三方厂商实现，TCC 的接口由开发人员实现。
• TCC 可以更灵活地控制资源锁定的粒度。
• TCC 对应用的侵入性强。业务逻辑的每个分支都需要实现 try、confirm、cancel 三个操作，应用侵入性较强，改造成本高。

 

来自 <https://blog.51cto.com/14528283/2446329>

 

GTS

https://yq.aliyun.com/articles/737742?spm=a2c4e.11153940.0.0.51ea38beXYr537

gts是阿里云的一个分布式事务产品：GTS 开创性地把分布式事务问题从业务中剥离出来，作为一个独立的技术切面来单独管理，以服务的形式给构建在云上的应用提供简单、易用、高效的分布式事务解决方案。

GTS 把全局事务分为两个阶段：执行阶段 和 完成阶段 。

执行阶段：

GTS 的 JDBC 数据源代理通过对业务 SQL 的解析，把业务数据在更新前后的数据镜像组织成回滚日志，利用 本地事务 的 ACID 特性，将业务数据的更新和回滚日志的写入在同一个 本地事务 中提交。

这样，可以保证：任何提交的业务数据的更新一定有相应的回滚日志存在。

基于这样的机制，分支的本地事务便可以在全局事务的 执行阶段 提交，马上释放本地事务锁定的资源。

完成阶段：

• 如果 TM 发出的决议是全局提交，此时分支事务此时已经完成提交，不需要同步协调处理（只需要异步清理回滚日志），完成阶段 可以非常快速地完成。
• 
  如果 TM 发出的决议是全局回滚，RM 收到协调器发来的回滚请求，通过 XID 和 Branch ID 找到相应的回滚日志记录，通过回滚记录生成反向的更新 SQL 并执行，以完成分支的回滚。

最后，GTS 通过事务协调器集群以及对业务应用节点的容错，实现一个拒绝单点故障的高可用服务。

高可用：

一方面，GTS 服务集群机制，保障任意服务节点宕机，可以其他节点无缝接管。
另一方面，应用任意节点的宕机，相应事务分支的请求也会路由到连接相同数据库的其他节点上，不影响全局事务的完整执行。

写法类似：

 @TxcTransaction(timeout = 60000)
    void dataUpdate(Connection con1, Connection con2) { 
        update1(con1);
        update2(con2);
    }

缺点：需要将事务日志放到业务DB中