可以这么认为,分布式事务是在分布式环境下能保证数据一致性程序单元
在说说什么是数据一致性,数据一致性是相对的,是复合逻辑的数据统一。
比如张三转账给李四,张三-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种 留给未来...................