分布式事务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柔性事务开源实现:
码云:https://gitee.com/git.sy/Raincat
github:https://github.com/changmingxie/tcc-transaction/tree/master