分布式事务解决方案

分布式事务产生的原因

事务这个东西本质上是由数据库提供的，而当我们采用了分库的思想所以在一个service方法或同一个为服务中操作了不同的库，于是就产生了分布式事务的问题

事务的四个特性：原子性，一致性，隔离性，持久性

CAP

C：一致性--->数据需要是一致的

A：可用性--->只要一访问就要立刻响应

P：分区容错性--->因网络故障或其他原因导致分布式系统中的部分节点与其他节点失去连接，形成独立的分区

三者只能取其二，另一个只能弱一点

Base描述的是如果三者只能选其二，剩下一个应该做到什么样子

AP C：最终一致性

CP A：基本可用

分布式事务解决方案一：2PC

在第一阶段，tm会让rm进行事务方面的准备，将工作内容进行持久化，RM会根据他完成的情况给TM进行一个ok或者是no的响应。

第二阶段tm会根据收到的响应做出反应，如果tm收到了ok就会发起commit提交，让rm全部去提交事务，如果有人响应no则让rm进行工作内容的回滚

优点：尽可能的实现了强一致性(也不一定100%成功)

缺点：牺牲了可用性，性能损耗较大，不适合高并发场景，没有合适的补偿机制

分布式事务解决方案二TCC

tcc补偿机制有三个接口

try接口负责将资源进行锁定

confirm处理我们的核心逻辑

cancel是处理过程中失败了的话就有回滚逻辑

如果有人执行失败他会调用cancel让数据回滚到最开始时候的样子

优点：灵活性极强

缺点：一致性不如2pc、代码侵入性太强

消息最终一致性

我们在操作过程中要保证我们事务发起方在操作完基本的事务之后发出一条mq消息，这条消息一定要被消费者接收到，而且一定要被消费成功

所以我们就要在操作完本地事务之后添加一个本地日志表，通过定时器去定期把信息加载出来，发送mq消息，事务的参与方拿到消息之后去进行自己的逻辑，成功之后再将这个消息从本地日志表删除

我们还需要考虑消息幂等性问题，而幂等性问题我们可以通过setnx方法来解决，setnx如果数据不存在则插入成功，返回1；如果数据存在则返回0，我们可以通过返回值来判断这条消息是否被处理过还是正在被处理，但要注意setnx这个key需要给出一个过期时间