主动提交事务_为什么要有分布式事务 分布式事务解决的什么问题 一次解答

可以这么认为，分布式事务是在分布式环境下能保证数据一致性程序单元

在说说什么是数据一致性，数据一致性是相对的，是复合逻辑的数据统一。

　　比如张三转账给李四，张三-100，李四+100. 这是一致。

　　比如 张三消费100 块 获取1000 积分， 金额-100，积分+1000. 这也是一致的。

　　如果我们认为 张三每消费 100 ，李四就奖励 10 元， 张三 -100 ,李四 +10 这也是 一致的。

　　如果我们认为 张三 送个 李四 100 元，李四就得到 1 块钱，张三 -100 ，李四+1 ，也是一致的。

上面你的 例子，如果 我们认为的 正确合理的 数据处理片段，正确的执行，我们就认为 是一致的。如果 一个完成一个不完成，我们就认为是不一致。

传统事务，一个程序里面执行 只需要传统事务 就可以 实现强一致性。

　　　　方法A 里面 调用 方法B ，然后调用了方法C ，只要在 A 方法上面加上事务，B，C 不开启新的事务，使用A的 事务 那么不管 A ，B，C 任何地方异常都会让事务回滚，并且 A,B，C 的数据变动会 一起提交。ACB 的 为提交 数据，相互可见。

分布式事务，还是 上面 A，B,C 的例子

　　但是 A，B ，C是 3 个独立的程序了， A ，B，C中 不是本地调用，而是 RPC 调用( 不管是 什么RPC 都是走的网络 ，不是本地调用(指的本程序内，不需要过网络 ，不过需要过IP地址 ))，

　　这时候本地事务明显不生效了。

　　在来模拟 服务的 A 方法里面调用了 ，B服务的 B方法，然后调用的 C服务的 C方法。

　　然后，

　　　　1 如果 A 调用 B ，C 之前报错，A 被事务回滚 ，B ，C 没有调用， 这没问题。

　　　　2 如果是 A 调用 了 B，C 以后 A 抛出异常， 那么 A 回滚了 ，B ，C 执行了 就提交了。 数据 不一致了

　　　　3 如果 A 调用 B ，然后调用 C ，C 报错了 ，C 回滚，C 调用异常 被 A 感知，A 也会回滚，B 执行完就自己提交了，不会跟着一起回滚，数据不一致。　　

　有人会说 我避免 3 个服务相互调用 ，我每次 只有2 个服务相互联系

　　 　我 只会 A 调用 B ，然后 B 调用C

　　　 1 A 调用 B ，在方法的最后面 ，A 前面如果报错 了，B不会被调用 ，如果前面没有出错 ，调用B，B失败了，B回滚，异常传递个A，A 也回滚 ， A B 之间的数据就 一致了 ，B,C 同理。　　　　

　　　　上面说的没错，理想环境下，如果只保持 2 层调用，并且调用 下一个服务 都在 事务提交前一刻执行 那么完全没问题，但是 网络环境 有一种极端情况。

　　　　A 发起一次调用B 可以拆分成几部，A请求B ---> B 收到请求 做自己的 ---> 然后B 响应 A --> A 收到 B 的响应

　　　　这时候 如果 B做了，提交了自己， 然后响应B的时候超时， A 那边抛出响应超时， A 不知道 B 是 做了 还是 没做 ，A 收到 超时异常 就回滚，然后 数据就不一致了。

　　　　有人又说了，我们是是内网 无限带宽 几乎不会出络异常，不考虑。网络不考虑，但是如果 B 做了提交了事务，然后B挂了，A 依旧没有收到响应，依旧要回滚，还是 会出数据不一致的问题。即便这些都是 小概率，然后 服务 只能保持 2 层调用，在大型 系统中依旧 明显不适用 ，因为这样会 链 会很长，调用会很不方便，然后 这个 链还必须是同步执行的。效率差。

解释 分布式环境 为什么会出 一致性问题，所以分布式事务就是来解决这些问题的。

　　分布式事务 在我看来有4种

　　 第1种 2pc事务,3pc事务，包括 TX-LCN 的 LCN 模式， 可以叫做 长锁定多段式分布式事务

　　第2中 TCC 这种补偿事务， 可以叫做短锁定多段式分布式事务，特地额 try 阶段 会独立提交，不会多个节点相互 等待，comfrom 阶段 也是相互独立的。 比第一种效率高，但是 一个方法写三遍，一个逻辑 分三个方向写，编码麻烦。

　　第3中，基于消息：效率没有 长锁定多段式分布式事务 那么低， 编码没有 TCC 那么麻烦。 但是需要注意的编程细节也挺多的。 总的来说算一种比较综合的解决方案，消息机制 有个 很明显的缺陷，它强调保证最终一致性，并不能同时回滚。 A 服务 发送给B服务的的消息,或者发出去的确认消息，只能完成， B 做失败了，只能重试(并且保持幂等)， 不能让 A 一起回滚。 只有 主动 发起方可以终止 和回滚 这个分布式事务，入股A 提交以后，只能硬着头皮走到底。

　　第4种 留给未来...................