分布式事务

什么是事务

事务是一种要么任何小的分步骤都不做,要么做全套的机制。
比如:下订单的时候,从你账户扣钱和给商家账号加钱这两个操作要么都成功,要么都失败,这个就可以称之为一个事务。

什么是本地事务

本地事务一般是通过数据库本身的事务特性来实现的,因此也叫做数据库事务。
数据库事务具有四大特性:

  • A(Atomic): 原子性,构成事务的操作要么全部执行,要么全部不执行。
  • C(Consistency):一致性,在事务执行前后,数据的状态都是正确的。
  • I(Isolation):隔离性,数据库里的事务一般都会生并发的,隔离性指并发的两个事务还行互不干扰。
  • D(Durability):事务完成之后,改事务对数据的更改会被持久化到数据库,且不会被回滚。

分布式事务

从单机单体服务到微服务的演进过程中,出现了各种操作分布在不同节点上,分布式系统就出现了,但同时需要保证ACID特性,这个时候分布式事务就出现了。比如创建订单减库存、银行转账等都是分布式事务。
分布式事务的参与者分布式在异步网络中,参与者通过网络通信达到分布式一致性,网络通信不可避免出现失败,超时问题。

分布式事务是什么

用于保证分布式系统中不同节点之间数据的一致性。分布式事务需要保证分布在不同服务器上的操作要么全部成功,要么全部失败,本质上来说就是为了保证不同数据库的数据一致性。

分布式理论

CAP

  • C(一致性):读到的总是最新的写操作。比如:数据分布在不同节点,如果某个节点数据更新,其他节点都能读到最新的数据,那么就是强一致,没有读到,就是分布式不一致。
  • A(可用性):非故障节点在合理的时间内返回合理的结果。 合理的时间主要是指请求不能无限的阻塞,合理的结果即正确的结果。
  • P(分区容错性):网络分区下,一个分区出现问题,其他的仍然能正常工作。
    CAP三者不可能共有,如果选择了CA而放弃了P,也就意味着当存在分区的时候,为了保证一致性,就需要去拒绝请求,这个时候会违反A,分布式系统中,P是必选项,所以分布式系统不可能选择CA架构,一般是CP和AP架构
    CP架构中,放弃了可用性,追求一致性和分区容错性,例如Zookeeper就是追求强一致的。
    AP架构中,放弃了一致性,追求分区容错性和可用性,很多分布式系统设计的时候选择的就是这个架构。

CAP 理论中是忽略网络延迟,也就是当事务提交时,从节点 A 复制到节点 B 没有延迟,但是在现实中这个是明显不可能的,所以总会有一定的时间是不一致。

BASE

BASE是Basically Available(基本可用)、Soft state(软状态)、Eventually consistent(最终一致性),是对CAP中AP的一个扩展。

  • 基本可用:分布式系统出现故障的时候,允许损失部分可用功能,保证核心可用
  • 软状态:允许系统存在中间状态,这个状态不影响系统可用性,即允许系统在多个不同节点的数据副本存在数据延迟。
  • 最终一致:指经过一段时间后,所有节点的数据都将会达成一致。
    BASE解决了CAP理论中无网络延迟,在BASE中用软状态和最终一致,保证了延后的一致性。
    BASE主要面向的是大型的、高可用、可扩展的分布式系统,和传统事务的ACID是相反的,通过牺牲ACID的强一致模型来获得可用性,允许数据有一段时间是不一致的。

分布式事务的场景

  • 跨服务
    微服务之间通过远程调用完成事务操作。
    例如:下单的时候,调用订单微服务,然后订单微服务调用库存微服务减库存。
    分布式事务_第1张图片

  • 跨数据库
    单体系统需要访问多个数据库实例时就会产生分布式事务。
    例如:需要删除用户信息及用户关联的订单两个信息,两个信息分属于不同的库,这个时候就产生了分布式事务。
    分布式事务_第2张图片

  • 跨服务访问同一个数据库
    跨服务之后本质就是跨JVM进程,两个服务持有的是不同的数据库连接进行的数据库操作。
    比如:订单服务远程调用库存服务,使用的是同一个数据库
    分布式事务_第3张图片

分布式事务实现

2PC

2PC不能不说数据库分布式事务的XA Transactions.
分布式事务_第4张图片
XA协议分为两阶段:

  • 事务管理器要求每个涉及到事务的数据库预提交此操作,并返回是否可以提交的消息
  • 事务管理器分析各个消息后,分析消息,根据是否有失败来决定发回滚命令还是提交命令

优点:

  • 尽量保证了数据的强一致性,实现成本低,各大主流数据库都有自己实现

缺点:

  • 单点问题:事务管理器在整个流程中扮演的角色很关键,如果其宕机在第一阶段完成,在第二阶段正准备开始的时候,那么资源管理器会一直阻塞,导致数据库无法使用。
  • 同步阻塞问题:准备就绪之后,也就是第一阶段结束,第二阶段开始的时候,资源管理器里的资源一直处于阻塞状态,直到提交完成,释放资源。
  • 数据不一致的问题。第二阶段中,协调者发出了事务Commit的通知,因为网络问题,仅被一部分参与者所收到并执行了Commit操作,其余的参与者因为没有收到通知一直处于阻塞状态。

XA协议实现简单,成本低,单点问题以及阻塞导致的不支持高并发是其一大缺点。

3PC

  • 未完成

TCC

分为三个阶段

  • Try阶段。对业务系统做检测、做资源预留。
  • Confirm阶段。确认真正执行业务,Confirm要求幂等,失败可以重试
  • Cancel阶段。取消执行,释放预留资源,也需要满足幂等性,失败可以重试
    分布式事务_第5张图片

本地消息表

  • 未完成

MQ事务

  • 未完成

Saga事务

  • 未完成

TCC和2PC的异同点

相同点:
不同点:

  • TCC面向业务,2PC面向资源。2PC的第一阶段的时候,对资源的更新没有执行,只是记录了一下日志,等待二阶段执行。TCC的第一阶段预留操作,实际上已经从业务层面来考虑了这个问题,对业务是有入侵的。
  • 强一致和最终一致。2PC执行过程中会独占资源,持有互斥锁,所以2PC效率较低。TCC虽然增加了代码的复杂性,但在业务层面避免了长时间占用资源,通过Confirm和Cancel的补偿机制来实现最终一致性。
  • 2PC在二阶段因为网络问题,会利用持久化的日志补偿处理把强一致变为最终一致,TCC一开始就是不维护强一致,遵循最终一致

注意事项:

  • 很多业务的大量拆分,导致了分布式事务的出现,这种拆分的合理性有待检验,实际业务中,要权衡利弊,尽量采用本地事务

你可能感兴趣的:(每天一道面试题)