关于分布式事务BASE模型和柔性事务TCC

分布式事务CAP问题

分布式系统面临的问题是CAP问题。CAP具体含义如下：
1、consistency：一致性，保持数据同步更新

2、availability：可用性，良好的响应性能

3、partition tolerance：分区容错性，可靠性

定理：任何分布式系统只可同时满足二点，没法三者兼顾。忠告：一般3种特性不能同时满足，而是应该取舍与折中。

一般来说，当数据分布在不同的机器（或者实体集，或者虚拟机，或者跨机房等）上，具体的好处有很多，通常可以拿来作为各种指标的总结如下：

1、数据分布

2、负载平衡

3、备份

4、高可用性

5、容错

BASE模型是CAP牺牲强一致性、保证可用性的折中方案：

1、basically available-基本可用

分布式系统发生不可预知的故障时，允许损失部分可用性，如服务降级等等

2、soft state-弱状态

分布式系统不同节点间某个时刻数据允许存在中间状态，不同节点的数据副本之间进行同步时可能存在时延，如主从同步

3、eventually consistent-最终一致

分布式系统不同节点的所有数据副本，在经过一段时间数据同步后，最终达到一致状态，即保证最终一致性，不保证实时一致性

我们通常接触的常见中间件，如mysql、zookeeper、redis、elasticsearch等都是基于BASE理论建立的

柔性事务TCC

在有些场景下，我们根据自己的真是需要，并不需要纯粹的2PC，比如你只关心数据的原子性和最终一致性，2PC的阻塞是你不能忍受的，那就有聪明的人想到了一种新的方法，就是柔性事务TCC。

今天说的柔性事务，「柔」主要是相对于「传统」ACID的刚而言，柔性事务只需要遵循BASE原则，而TCC是柔性事务的一种实现。TCC是三个首字母，Try-Confirm-Cancel，具体描述是将整个操作分为上面这三步。两个微服务间同时进行Try，在Try的阶段会进行数据的校验，检查，资源的预创建，如果都成功就会分别进行Confirm，如果两者都成功则整个TCC事务完成。如果Confirm时有一个服务有问题，则会转向Cancel，相当于进行Confirm的逆向操作。

tcc型业务服务

整个柔性事务有多种实现的思想，例如：

柔性事务实现方式

使用哪一种方式，根据具体项目业务来选择。

tcc柔性事务开源实现：

码云：https://gitee.com/git.sy/Raincat

github：https://github.com/changmingxie/tcc-transaction/tree/master