zoukankan      html  css  js  c++  java
  • 分布式事务 XA 两段式事务 X/open CAP BASE 一次分清

    分布式事务:

      分布式事务是处理多节点上 的数据保持 类似传统 ACID 事物特性的 一种事物。

    XA:是一种协议,一种分布式事务的协议,核心思想是2段式提交。 1 准备阶段  2 提交阶段。XA协议是 Tuxedo 首先提出的

      

      XA 的 原理 ,XA分了 几个角色,RM ,TM ,AP 等

      RM:资源管理器。他记录着XA的 事物的全部 状态(在事物结算之前不会丢失)。

      XA事物成功的流程:

        1准备阶段 RM 告诉 相关的 几个 TM(事物管理器), 最一些事情,但是别提交。这时候修改数据还不可见(除了RM 以外或者说 TM外 不可见)

        2 如果所有的 TM都告诉 RM 我可以做这个事情。那么就 通知 所有 TM  commit

        3 如果所有的 TM commit 都成功,那么这个XA 事物完成。 RM 可以忘记关于这个XA事物的数据了。

      XA事物失败的流程:

        1准备阶段 RM 告诉 相关的 几个 TM(事物管理器), 最一些事情,但是别提交。

        2 如果任何一个TM  commit 告诉 RM 我不能执行( 预提交阶段就失败 )

        3 RM 通知 这个事物涉及到的 TM  rollback

      

      XA事物极端流程: 需要补偿机制(正常不会出,除非极端情况,因为前面预处理阶段已经把数据写入了,后面 commit 只是 修改一个状态 ,让别的事物可以读到 )

        1准备阶段 RM 告诉 相关的 几个 TM(事物管理器), 最一些事情,但是别提交。

        2 如果所有的 TM都告诉 RM 我可以做这个事情。那么就 通知 所有 TM  commit

        3 如果部分 TM commit 成功,只有一个失败了。因为 RM  记录了事物的完整信息。所以可以在 做一些补偿机制,比如包刚才的 失败部分 在做一次。

      

    X/open: XA协议是 Tuxedo 首先提出XA ,并交给X/Open组织,作为资源管理器(数据库)与事务管理器的接口标准. 所以 X/open 是组织 XA 的 一个机构。

    CAP :

      

    CAP是三个理想的状态。但是只能3 选2 ,不能全部达到。

    C:

    • Consistency 强一致性    描述数据要完全的一致,A加了 100,B 就减去100 。同时发生,一起发生。就是强一致性

    A:

    • Availability 高可用 在一定的时间内正确的响应 客户端的请求。不会长时间等待挥着阻塞,不会 服务器不可用。

    P:

    • Partition tolerance 分区容错性  分布式环境中如果出现了网络分区,依旧是可以正常工作。每次加入节点的变动都可以看做特殊网络分区。

      网络分区的解释:因为网络原因,集群节点部分 分成多块,每块之间的网络不能通信。

    上面三个条件。在分布式环境中,网络分区,必然要考虑。所以P必选。 现在的分布式框架都是  CA 2 选1 +P。

     

     2 段是事务:如果你是事务是 先预提交,然后在确认提交 分成2 段的就叫做2 段式事务。  比如 XA 协议规定的 分布式事务 就是2 段式事务。 比如 MQ 的预消息机制。 比如 给予mq 和 本地事务 实现的消息机制。

        mq 和 本地事务 实现的消息机制原理:  变 a b 两个 分布式子事物 为 插入 2 条 本地记录 一条消息A,和消息B,,如果 正常执行 A,B 两条插入记录被转个给 MQ ,如果 任何失败,A B被丢弃。

    BASE: 

      BASE是Basically Available(基本可用)、Soft state(软状态)和Eventually consistent(最终一致性)三个短语的缩写

      BASE理论是对CAP中一致性和可用性权衡的结果。我们不都舍弃,找一个折中 的办法。 不能同时拥有,也不想放弃任何一个。那就一个区一半吧。

      

      

      Basically Available(基本可用): 在异常的时候允许适当的延长响应时间。 在并发太高的时候允许部分不是成功,而且不是全部都堵死在哪里。

      Soft state(软状态): 可以存在中间状态: A +100, B -100 如果不能同时完成,那么就让 A +100 并且B冻结 记录里面 写入100 把。这样 一个转账中的状态。

      Eventually consistent(最终一致性): 上面的 中间状态不可能让他一直存在,最终我们会让他一致的,比如,修改同一个 余额字段 ,并发太高,那么就插入冻结记录。不用锁这个字段,但是最后我们要报这个冻结 在余额 里面扣掉(在系统缓,或者一个延时队列慢慢做)。

    分布式解决方案实现原理:https://www.cnblogs.com/cxygg/p/9526401.html

  • 相关阅读:
    接口自动化架构-获取用例
    Windows性能监控工具Perfmon使用指南
    接口自动化架构1-setting
    多进程
    线程锁、守护线程
    多线程
    xlrd模块
    封装写日志的类
    封装redis
    继承
  • 原文地址:https://www.cnblogs.com/cxygg/p/10813072.html
Copyright © 2011-2022 走看看