挖掘机驾驶宝典

Appearance

Seata ​

CAP ​

  • C
  • A
  • P：分区容忍性
    • Tolerance (容错) ：在集群出现分区时，整个系统也要持续对外提供服务
    • 分布式系统节点通过网络连接，一定会出现分区问题(P)当分区出现时，系统的一致性(C)和可用性(A) 就无法同时满足

BASE ​

BASE理论是对CAP的一种解决思路

  • B：Basically Available
    • 分布式系统在出现故障时，允许损失部分可用性，即保证核心可用。
  • S：Soft State
    • 在一定时间内，允许出现中间状态，比如临时的不-致状态。
  • E：Eventually Constistent
    • 虽然无法保证强一致性，但是在软状态结束后，最终达到数据一致。

AP模式：各子事务分别执行和提交,允许出现结果不-致，然后采用弥补措施恢复数据即可，实现最终- -致。

CP模式：各个子事务执行后互相等待，同时提交，同时回滚,达成强一致。但事务等待过程中，处于弱可用状态。

重要组件 ​

  • TC 事务协调者：
    • 维护全局和分支事务的状态，协调全局事务提交或回滚
  • TM 事务管理器：
    • 定义全局事务的范围、开始全局事务、提交或回滚事务
  • RM 资源管理器：
    • 管理分支事务处理的资源，与TC交谈以注册分支事务和报告分支事务的状态，并驱动分支事务提交和回滚。

安装 ​

conf
registry {
  # file 、nacos 、eureka、redis、zk、consul、etcd3、sofa
  type = "nacos"

  nacos {
    application = "seata-server"
    serverAddr = "10.1.72.237:8848"
    group = "CLOUE_DEMO"
    namespace = "685bcf31-3ad8-4486-bd01-2a64a2cf97e6"
    cluster = "default"
    username = "nacos"
    password = "nacos"
  }
}

config {
  # file、nacos 、apollo、zk、consul、etcd3
  type = "nacos"

  nacos {
    serverAddr = "10.1.72.237:8848"
    namespace = "685bcf31-3ad8-4486-bd01-2a64a2cf97e6"
    group = "CLOUD_DEMO"
    username = "nacos"
    password = "nacos"
    dataId = "seataServer.properties"
  }
}
yaml
version: "3.1"

services:
  seata-server:
    image: seataio/seata-server:1.4.2
    hostname: seata-server
    ports:
      - 8091:8091
    environment:
      - SEATA_PORT=8091
    expose:
      - 8091
    volumes:
      - "./registry.conf:/seata-server/resources/registry.conf"
xml
<dependency>
    <groupId>com.alibaba.cloud</groupId>
    <artifactId>spring-cloud-starter-alibaba-seata</artifactId>
    <exclusions>
        <!--版本较低，1.3.0，因此排除-->
        <exclusion>
            <artifactId>seata-spring-boot-starter</artifactId>
            <groupId>io.seata</groupId>
        </exclusion>
    </exclusions>
</dependency>
<!--seata starter 采用1.4.2版本-->
<dependency>
    <groupId>io.seata</groupId>
    <artifactId>seata-spring-boot-starter</artifactId>
    <version>${seata.version}</version>
</dependency>
yaml
seata:
  registry: # TC服务注册中心的配置，微服务根据这些信息去注册中心获取tc服务地址
    # 参考tc服务自己的registry.conf中的配置
    type: nacos
    nacos: # tc
      server-addr: 127.0.0.1:8848
      namespace: ""
      group: DEFAULT_GROUP
      application: seata-tc-server # tc服务在nacos中的服务名称
      cluster: SH
  tx-service-group: seata-demo # 事务组，根据这个获取tc服务的cluster名称
  service:
    vgroup-mapping: # 事务组与TC服务cluster的映射关系
      seata-demo: SH

支持的模式 ​

  • XA：强一致性分阶段事务模式，牺牲了一定的可用性，无业务入侵
  • TCC：最终一致性的分阶段事务模式，有业务入侵
  • AT：最终一致性的分阶段事务模式，无业务入侵，默认模式
  • SAGA：长事务模式，有业务入侵
****XAATTCCSAGA
一致性强一致弱一致弱一致最终一致
隔离性完全隔离基于全局锁隔离基于资源预留隔离无隔离
代码侵入无无有，要编写三个接口要编写状态机和补偿业务
性能差好非常好非常好
场景对一致性、隔离性
有高要求的业务		基于关系型数据库的大多数分布式事务场景都可以对性能要求较高的事务。
有非关系型数据库要参与的事务。
业务流程长、业务流程多
参与者包含其它公司或遗留系统服务，无法提供TCC模式要求的三个接口

XA ​

XA规范是X/Open组织定义的分布式事务处理（DTP，Distributed Transaction Processing）标准，XA 规范描述了全局的TM与局部的RM之间的接口，几乎所有主流的数据库都对XA规范提供了支持。

  • RM一阶段
    • 注册分支事务到TC
    • 执行分支SQL但是不提交
    • 报告执行状态到TC
  • TC二阶段：TC检测各分支的事务执行状态
    • 如果都成功，通知所有的RM进行提交
    • 如果有失败，通知所有的RM回滚提交
  • RM二阶段
    • 接收TC指令，提交或回滚事务

优缺点 ​

XA模式的优点

  • 事务的强一致性,满足ACID原则。
  • 常用数据库都支持，实现简单，并且没有代码侵入

XA模式的缺点

  • 因为一阶段需要锁定数据库资源，等待二阶段结束才释放，性能较差
  • 依赖关系型数据库实现事务

实践 ​

yaml
seata:
  data-source-proxy-mode: XA # 开启数据源代理
java
@GlobalTransactional

AT ​

也是一个两阶段提价

  • RM一阶段
    • 注册事务分支
    • 记录undo-log
    • 执行业务SQL并提交
    • 报告事务状态
  • RM二阶段
    • 如果提交都成功，删除undo-log
    • 如果部分提交失败，则通过undo-log回滚

脏写问题，通过全局锁解决，当事务B获取同一条数据时，会不断重试

yaml
select for update

TCC ​

SAGA ​