目前可找到很多成熟的开源分布式事务解决方案,比较典型的方案如阿里的fescar,蚂蚁金服的Seata, LCN (https://github.com/codingapi/tx-lcn)的2 pc型无侵入事务。还有太极拳型如事务实现hmily (https://github.com/yu199195/hmily), tcc-transaction (https://github.com/changmingxie/tcc-transaction)等
Seata: https://github.com/seata/seata
fescar: https://github.com/alibaba/fescar
tcc-transaction: https://github.com/changmingxie/tcc-transaction
hmily: https://github.com/yu199195/hmily
LCN: https://github.com/codingapi/tx-lcn
分布式事务有个注明的盖理论:C, A, p无法同时全部满足,最多满足两个.Cassandra,发电机等,默认优先选择,弱化C; HBase, MongoDB等,默认优先选择CP,弱化A
基础模型包含个三个元素:
英航:基本上,基本可用
S:软状态,软状态,状态可以有一段时间不同步
E:最终一致,最终一致,最终数据是一致的就可以了,而不是时时保持强一致
基础模型与酸模型截然不同,满足盖理论,通过牺牲强一致性,获得可用性,一般应用在服务化系统的应用层或者大数据处理系统,通过达到最终一致性来尽量满足业务的绝大部分需求。
分布式事务的目的是保障分布式存储中数据一致性,而跨库事务会遇到各种不可控制的问题,如个别节点宕机,像单机事务一样的酸是无法奢望的。
1,两个/三个阶段提交
2 pc,中文叫两阶段提交。在分布式系统中,每个节点虽然可以知晓自己的操作时成功或者失败,却无法知道其他节点的操作的成功或失败。当一个事务跨越多个节点时,为了保持事务的酸特性,需要引入一个作为协调者的组件来统一掌控所有节点(称作参与者)的操作结果并最终指示这些节点是否要把操作结果进行真正的提交。两阶段提交的算法如下:
第一阶段:
协调者会问所有的参与者结点,是否可以执行提交操作。
各个参与者开始事务执行的准备工作:如:为资源上的锁,预留资源。
参与者响应协调者,如果事务的准备工作成功,则回应“可以提交”,否则回应“拒绝提交”。
第二阶段:
如果所有的参与者都回应“可以提交”,那么,协调者向所有的参与者发送”正式提交”的命令。参与者完成正式提交,并释放所有资源,然后回应“完成”,协调者收集各结点的“完成“回应后结束这个全局事务。
如果有一个参与者回应“拒绝提交”,那么,协调者向所有的参与者发送“回滚操作”,并释放所有资源,然后回应“回滚完成”,协调者收集各结点的“回滚”回应后,取消这个全局事务。
两段提交最大的问题就是第(3)项,如果第一阶段完成后,参与者在第二阶没有收到决策,那么数据结点会进入“不知所措”的状态,这个状态会阻止住整个事务。也就是说,协调者协调员对于事务的完成非常重要,协调员的可用性是个关键。
因些,我们引入三段提交,三段提交在维基百科上的描述如下,他把二段提交的第一个段打破成了两段:询问,然后再锁资源。最后真正提交。三段提交的核心理念是:在询问的时候并不锁定资源,除非所有人都同意了,才开始锁资源。但三阶段提交也存在一些缺陷,要彻底从协议层面避免数据不一致,可以采用Paxos或者筏算法。
目前两阶段提交,三阶段提交存在如下的局限性,并不适合在微服务架构体系下使用:
所有的操作必须是事务性资源(比如数据库,消息队列,EJB组件等),存在使用局限性(微服务架构下多数使用HTTP协议),比较适合传统的单体应用;
由于是强一致性,资源需要在事务内部等,待性能影响较大,吞吐率不高,不适合高并发与高性能的业务场景;
2,试着确认取消(太极拳)
一个完整的太极拳业务由一个主业务服务和若干个从业务服务组成,主业务服务发起并完成整个业务活动,太极拳模式要求从服务提供三个接口:尝试,确认、取消。
试题:完成所有业务检查,预留必须业务资源。
确认:真正执行业务,不作任何业务检查,只使用试阶段预留的业务资源,确认操作满足幂等性。
取消:释放试阶段预留的业务资源;取消操作满足幂等性。
整个太极拳业务分成两个阶段完成:
第一阶段:主业务服务分别调用所有从业务的尝试操作,并在活动管理器中登记所有从业务服务。当所有从业务服务的尝试操作都调用成功或者某个从业务服务的尝试操作失败,进入第二阶段。
