• 为什么要有分布式事务 分布式事务解决的什么问题 一次解答


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

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

      比如张三转账给李四,张三-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种 留给未来...................

    一些相关的资料:

     消息方式的的实现原理:https://www.cnblogs.com/cxygg/p/9526401.html

    2pc 和 3pc 还有TCC 区别:https://www.cnblogs.com/cxygg/p/12525898.html

    分布式框架 TX-LCN 的使用: https://www.cnblogs.com/cxygg/p/12410294.html

    分布式事务解决方案:https://www.cnblogs.com/cxygg/p/12464016.html

    分布式事务 XA 两段式事务 X/open CAP BASE 一次分清 : https://www.cnblogs.com/cxygg/p/10813072.html

  • 相关阅读:
    获取账号所有联系人
    获取用户的初始信息展示
    pip升级的错误
    二维码长轮询获取登陆并获取用户基本信息
    获取微信二维码
    WebChat理清流程
    python的requests模块
    python的单例模式和__new__方法
    matplotlib 基础知识汇总
    pandas数据分析案例:美国2012年总统候选人政治献金数据分析
  • 原文地址:https://www.cnblogs.com/cxygg/p/12528315.html
Copyright © 2020-2023  润新知